せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

JJUGナイトセミナー「Jakarta EE, MicroProfile, Payara が目指すもの」へ行ってきた

風邪気味の金曜日、そして週末胃腸炎。ちょっと回復したのでようやく書けた・・・。

EE4J

Jakarta EE

今後のロードマップ

未定のこと

  • ライセンスはできるだけオープンにして欲しいとは言われてる
    • しかし、EE4Jほどにはならないと思われる
  • ワーキンググループに参加するためのFee
    • Java EEOracle時代)はとても高かったので、お手頃にしたいと思っている
  • Glassfishの扱いが未定
    • 参照実装になるかも未定・・・
    • ピックアップする人が出るか
  • リリース頻度をあげたい
    • でも、半年ごとというJavaのリリース速度に合わせると、Jakarta EEが管理しきれないから、それよりは遅くなる
  • すでにある仕様の取り扱い
    • 法的に持ってこれないものも多い・・・
    • その場合スクラッチで構築しなければいけない
  • javaxパッケージの取り扱い

Microprofile

  • 2.0がリリース
  • Payara MicroやOracleのHelidon等がある

Helidon

  • 日本ではあまり知られてない
    • 海外でもまだこれからっぽい

雑感

  • EE4JとJakarta EEの関係が不安
    • Jakarta EEの方はベンダーの思惑とかが入ってくると思われる
    • EE4Jが純粋な開発者が欲しいものを追求した時に問題になりそう
  • そもそも、Jakarta EEが複数のベンダーでやっていけるのか
    • PayaraのようなJakarta EEがほぼ全てのベンダーと、Oracle富士通のようなそれ以外もあるベンダーの温度差
    • Springのように1ベンダーが主体になった方が速度は向上しそうだけど・・・
  • 個人的にはMicroprofileとEE4Jがいい感じに連携していくといいなーと思う

JJUG ナイトセミナー 「Elasticsearch特集」メモ①

とりあえず、1セッション目のメモ。 2つ目はきっと明日には・・・。

Elastic Stackで始めるJavaアプリのパフォーマンス監視

スライドはこちら

Elastic Stackで始めるJavaアプリのパフォーマンス監視 / Intro Elastic Stack and Elastic APM Java - Speaker Deck

elastic社は2012年創業。アメリカとアムステルダムに ElasticsearchはCEOの奥さんのレシピ検索のために作った

Elastic Stack

Beats、LogStash、Elasticsearch、Kibanaの組み合わせ。 公式のデモもある。

https://demo.elastic.co/

Beats

Go言語で書かれた軽量データシッパー(データ収集エージェント) 収集したデータの送信先はLogstash、Kafka、Elasticsearch等 大規模(数百台)だと、Kafkaを挟むことおすすめ 簡単なフィルター(INFO以下のログは送信しないとか)はあるが、変換とかパースはLogstash 採取したいデータがあるサーバーに設置 収集対象は様々で、公式・コミュニティで40種類以上のBeatがある k8sの場合、Beats系はDaemonSetで指定。

Logstash

データ加工パイプライン 元々はBeatsの役割も兼ねていたが、JRubyで書かれているため、起動に時間がかかる、メモリを食う等で評判悪かった。

Elasticsearch

分散型、高可用性の特性を持つ全文検索エンジン Wikipediaの検索もElasticsearch

Kibana

Elasticsearchに接続する解析と分析のView

APM

Java等のアプリケーションの情報収集ができる(Javaはまだベータ版・・・) 収集の流れはAPMエージェント→APMサーバー→Elasticsearch。 ViewはKibana。

Javaアプリの実行時に-javaagentで導入する。 Springの場合、Controllerの時間とその中で発行されたSQLを収集。 中の処理の時間を取得したい場合のAPIもある。

QAとか

PacketbeatでDBのアクセス情報が取得できる。 ・クエリの種類 ・発行されたクエリ SQLを分析し、インデックス貼ってないカラムへのSELECTとかを見つけるのに役立つ MySQLであれば3306のポートをウォッチしてるだけなので、DBに手を入れる必要なし

Elastic stackをk8sで動かすのは非推奨。 コンテナはステートレスであるべき。

fluentdとLogstashは使いやすい方を使えばいい。 データ取得でBeatsを使い、fluentdに送ることもできる。

JSUG勉強会 2018年その3 LT大会に行ってきたしん!

興味深かったところをメモ

Kotlin

  • IDEAのktファイルにJavaソースを貼り付けると変換してくれる?
  • Dataクラスが1行で書ける
  • NPEに遭遇しなくなる
  • 書籍はKotlin in Actionおすすめ

バナー

Spring Bootのバナーを生成するサイトがある

Spring Boot banner.txt generator

何でも貼れるけど、エラーメッセージはやめた方がいい(新人がみたらパニックになる)

2.0でアニメーションgif対応

Spring Bootの起動を早くする話

本番では使えないけど階層型コンパイルバイトコード検証オフで起動が早くなる IDEAで実行する場合は自動的に指定される

GraphQL

RESTに変わるAPI

github.com

でも辛いところもある

ペイロードのバリデーションでBeanValidationが使えない クライアントサイドでやれという思想らしい

エラー時に何でもかんでも500返してしまうので自前で実装

Spring MVCの外のライブラリ。 AOPとかは使えるけど、Spring MVCの機能は使えない

Spring Data JDBC

Spring Dataだけど、DBアクセスの実装は提供しない
CRUDRepositoryの実装をMyBatisとかから選択できる
デフォルトはSpringJDBC
ストラテジーを自分で定義すれば、好きなORMを使える

宣伝

SpringFest 10/31
会場は両国KFC

Spring Securitでハードウェアトーク

Web AuthorizationがW3Cで標準化
FIDOを利用して2FAとかできる

Web Authorizationはユーザーとクライアントプラットフォーム、クライアントプラットフォームとサーバーで認証が分かれるからセキュア

SpringSecurityで実装したのは↓

github.com

まとめ

ちょっとしたハックから普段の工夫まで色々な話が聞けてよかったです
来月もJSUG勉強会は開催予定なので楽しみ

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に行ってきた

花粉症つらい・・・

お知らせ

JavaDayTokyo2018

5/17(木)に決定。
キーノートはMark Reinhold(初来日?)
登録サイトは近日オープン(多分、今週後半くらいとのこと)

JJUG CCC 2018 CfP募集中

JJUG CCC 2018 Spring

JDKリリースモデル変更について(おさらい) by 伊藤 敬さん(Oracle)

Java 10はおそらく初めて予定通りリリースされたJava
リリースノートには削除予定APIも記載されているので確認しておくこと。

JDK10の追加機能解説 - JEP286/ローカル変数の型省略(var記法)を中心に

ローカル変数の型推論

冗長な変数の型の宣言をvarに置き換えられる。
動的言語になるわけじゃない。
メソッドの引数・戻り値には使えない。
また、匿名クラスにも使えない。

varは予約語ではないキーワード。
そのかわり、クラスやインターフェースでは使えなくなった。
(非互換だけど、流石に使ってる人いないよね・・・)

変数やフィールド、メソッドでは使えるからこれはOK。(絶対やるなよ的な・・・)

var var = var();

varの使いどころは、読みやすさが向上する箇所。
Javaの書きやすさより読みやすさを重視している文化は破っちゃダメ。
型をタイプするのが面倒とかそんな理由で使ってはダメ。

IDEがなくても理解できる状態で使うべき。
マウスポインタを上に乗っければわかるはNG。

varのガイドラインも出ている。

orablogs-jp.blogspot.jp

GCの変更

G1のパラレルFullGCが追加された。
でも、G1GCを使っている時にFull GCを起こした時点で負けなので、恩恵を受けないような運用が理想。

Garbage-Collector Interfaceの追加で、GCをモジュールとして追加削除できるようになる。

ZGC

https://wiki.openjdk.java.net/display/zgc/Main

4TB(!)までのヒープに対応。
ヒープサイズに関わりなく、Stop The Worldを10ms以下に抑えるのがゴール。

Java 10でぼくたちの生活は どうかわるの?

今まではすぐにでも欲しい便利な機能でも、追加されるのが3年後だった。
それが比較的すぐに手に入る。
でも、アップデートに追従するコストが大変。

新しいバージョンへの対応方法
  1. とりあえず動かして見る
  2. コンパイルして動かして見る
  3. 非互換・非推奨APIを見つけ出す(jdeps、jdeprscan)
  4. 機能テストを行う

新しいバージョンの変更箇所は、以下の

  • JEPから新機能
  • 最新のJRSからAPIの変更点
  • リリースノートから非互換

STSで非推奨化・削除と続くと、LTSから次のLTSにいきなり移った時に、サイレント削除が発生する可能性がある

Java 8からJava 9への移行がとにかく大変。
そこを乗り切ること。

Class-Data Sharing

元々はコマーシャル機能。
クラスデータを複数のプロセスで共有する。
バッチとかのプロセスをたくさん起動するアプリで利用できる
読み込むクラスの量が多いほど効果的

APIの変更

OptionalにorElseThrowが追加。
getよりこちらを利用すべきと書かれている。

List、Set、MapにcopyOfメソッドが追加。
変更不可のコピーを返却する。
引数が変更不可の場合は引数をそのまま返す。

プロセスIDが取れるようになった。

Javadocにサマリーを出力するアノテーションと、ヘッダーとフッターの編集が追加。
会社で使うときとか便利そう。

感想

Java 9から半年だけど、機能追加が非常に多い印象。
Java 8からJava 11に移行すると死ねる未来が見えるので、それまでのどこかでは試しておかないといけないなぁ・・・。

あとはJavaとは関係ないですけど、神宮球場の桜がいい感じに綺麗でした

Spring Fest 2017に行って来た

Springの祭典! JJUG CCCの興奮冷めやらぬ中(?)のイベントに参加して来ました。 詳細はqiitaにまとめるとして、セッションの感想を中心に

詳細なまとめはすでに誰かがやってくれてるので・・・

セッションの感想

Introduction to Spring WebFlux

Spring WebFluxをSpring MVCとの違いを絡めつつわかりやすく説明したセッション
JDBC使うときはWebFluxにしない方がいい等の、移行する際のポイントもきちんと抑えて説明があった

Spring Security 5 解剖速報

Spring Security 5の変更ポイントに絞った解説

ドメイン駆動設計のためのSpringの上手な使い方

エンジニアならコードを書け!
Excelパワポ作るんじゃなくてコードを書け!

Quick start Spring Boot on OpenShift

Kubernetesを使うかOpenShiftを採用するかどうかプロジェクトで決めないといけないので聞く。
Spring要素はあまりなく、OpenShiftの紹介だった気がする。

The Road to Serverless

なんか、コレジャナイ感があった Fnのように、実行環境とファンクションが分かれてるのではなく同一のJarにパッケージング?
それサーバーレスなの?

Spring BootとSpring Cloudで始めるマイクロサービス

一通り通した解説や考え方が盛り込まれていてわかりやすかった
でも、セッションの中で初心者向け(?)と言っていたけど、初心者ついてこれないっしょと聴きながら思った
守破離の守を再確認させてくれるけど、守にすらたどり着いてない人orこれから入門する人には辛いかも?

全体通しての感想(というか気になったこと)

会場も広く、去年のようなすぐに会場がいっぱいということもないし、セッションはいずれも高品質だった。 個人としては不満はないし、むしろこんな素晴らしいイベントを開催してもらって感謝の念しかない。

個人じゃなくてもう少し広い観点で考えてみる。

Java EEの停滞や脱Struts、マイクロサービス等の理由でSpringは非常に注目を浴びているフレームワークである。
このイベントには、Springを知らない人や移行先の候補としてのSpringを知りたいという理由で参加してる人も多かったのではないか? でも、Springをある程度知っている開発者じゃないとついていけないセッションも多かった気がする。
例えばSpring Security 5の話もSpring Securityを理解してないとピンと来ない。

Springをこれから始める人向けに、Springの目指すとことか考え方的な説明をする本当にSpring知らない人向けセッションがあってもいいと思った。
(なら、お前やれよ?でも、僕もSpring3から入った新参なので許してクレメンス・・・)

最後に偉そうなこと言っちゃってますが、自分にとっては最高すぎるイベントでした。

JavaOne 2017 報告会へ行ってきた

ようやく風邪から治ったので初投稿です。

Javaの方向性

Javaのキーワードにnimbleが新しく追加。
nimbleは軽量、素早さ。
ITの変化の速さに対応していく。

Javaのリリースについて

まず、OracleJDKとOpenJDKの技術差を1年かけてなくす。
ソースコードは一本化。

OpenJDKは6ヶ月ごとのリリース。
LTSはなしで、6ヶ月ごとに最新版にアップデートして使う。
OracleJDKと技術的な差分がないバイナリ配布。

OracleJDKの無償版は18.3まで。
18.9以降は3年ごとに8年間のLTSがある有償版。

http://www.oracle.com/technetwork/jp/java/eol-135779-ja.html

次の機能リリースであるJava SE 18.3スケジュールや追加される機能は

http://openjdk.java.net/projects/jdk/18.3/

Java EE

間違えやすいけど、EE4Jは移管プロジェクト名。
ブランド名はこれから決める。
速度が落ちるのでJCPのような仕様策定の標準化はしないけど、JSRのような仕組みは取り入れる予定。

OracleJava EEサポートに関する既存のベンダー(日本だとNEC富士通とか)との契約は尊重。 ライセンスやJava EEの認定も引き続きサポート。
Java EE 8は2025年まではサポートするので、ベンダーはその間にEE4Jへの移行方針を決めてほしい。

その他

IntelがPM(Persistent Memory)に合わせてJavaに力を入れている。
PMはDRAMより大容量で価格が安い代わりに速度は遅い。
Javaでは揮発するヒープとしても、永続化先としても使える。
揮発するヒープとしての用途はビッグデータやインメモリDBのような大容量を使うアプリ。

マイクロサービス関連は細かい実装よりも取り組んだ事例や組織面のセッションが多かったらしい。
フレームワークやライブラリは自前で開発したりラッピングするものではなく、consumeするもの。
それよりも、「サービス」という部品をどう協調させていくかが重要。

コミュニティ関連やフォトセッション、LTは非常に面白かった。
ただ、写真で見るのと現地に行ってその場の空気を感じるのは大きく違うと思うので、機会があれば是非行きたい。

Mackerel / NewRelic / Elasticsearch Seminarに行ってきた

奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。

ご挨拶

モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮=ビジネスの特性等を把握.

Linux OSから見るMackerelのパフォーマンスモニタリング

何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング

  • Mackerelの特徴

    • もともとははてブはてなブログを監視するツール。10年前から使っている
    • 3年前からSaaSとして公開。はてな自身がエンドユーザーでもあるのでUIには凝ってる
  • 利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSHTTPSで送信。

    • Mackerelからエージェントを導入したサーバーにアクセスすることはないからセキュア

Linuxモニタリング

ロードアベレージ

  • 実行待ちのプロセス数とディスクIO待ちのプロセス数の合計
    • 高い場合はCPUやディスクIOが詰まってる状態
    • uptimeやtop等で確認できる
  • uptimeの数値は1分間、5分間、10分間の平均
  • Mackerelは標準で5分平均をサポート

CPUの使用率

100%の場合、どこが使っているかを知るのが重要

  • topコマンドのCPU使用率は全コアの合計。1を押すとコア別に見れる

モリーディスクioFSは省略.
Mackerel本を読んでね.

モニタリングしたものをどう活躍するか

根本原因をどうやって見つけるか

  • ロードアベレージのアラートは処理がさばききれてない可能性。ただ、即障害とは限らない
    • スパイクなら問題ない
    • 負荷がかかっているコアが1個なのか全部なのか
    • 継続的に見ないとダメ
  • 「実際にさばいている処理<捌くべき処理数」の状態が継続していないか?
    • 高まり続けているのは処理待ちがたまり続けてる
    • 高い場合でもコア数を確認するのが重要
  • CPUかディスクがボトルネック
    • CPUのメトリックから原因を読み取る
  • ディスクIOの場合はSSDに換装する 

  • userが高い場合はアプリケーションのループや処理が原因

    • 金の弾丸(コアを追加、コアのスペック向上)で解決できる場合も
    • 1個のCPUで止まっているなら、コアのスペック向上
  • CPUが常に低い場合はサーバーがオーバースペック。コストダウンのチャンス。

まとめ

  • パフォーマンスモニタリングは難しい
  • 見るべき値や条件はサービスやサーバーの役割でちがう(Webサーバー、DBサーバー)
  • 勉強しておけばアプリエンジニアとしての付加価値に
    • スパイクなのか少しずつ上昇しているかを知るためには時系列データが必要
    • 過去のデータは取れないからモニタリングツールは重要
    • 問題が起こる前兆もわかる

QA

  • Q:コマンドで監視できるけどMackerelを導入する理由は?

    • A:コマンドを打たなくてもよくなる。毎分実行、加工、失敗した時云々・・・。DB、グラフ、分析を自分でやらなくていい。
  • Q:HinemosとかZabbixとのちがい?

    • A:セルフマネージドは監視対象が増えた場合のチューニング等のメンテナンスを自分でしないと行けない。 また、Zabbixを監視するZabbixとかも必要になる。 MackerelはSaaSなので何もしなくていいし、他のツールやサービスと連携できる

New Relic によるアプリケーションパフォーマンス監視入門

New RelicはSaaS型のパフォーマンス分析ツール。
パフォーマンス、アラート、障害分析機能(切り分け)等様々

APM

  • APM=ApplicationPerfomanceMonitoring

    • エージェントをインストール
    • Java、Go等の7言語に対応
  • 遅いトランザクションや直近のアラートが観れる

    • アラートは集中管理。通知チャネルや設定条件が豊富
  • ダイナミックベースラインアラート

    • 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
  • トランザクションタイムからどのトランザクションが遅いかわかるので深掘りすることが可能

    • アプリのどの部分で時間がかかっているか
    • SQLの場合、発行されたSQLと時間
    • 外部サービスにかかった時間も観れる
  • 内部サービスの呼び出し階層が観れる

    • 一覧で赤いとアラートが発生している
  • インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨

  • デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる

    • デプロイ前後のパフォーマンスが比較
    • デプロイした時刻が残るので調査に役立つ

応用編

ソースコードを修正することで、さらなる情報取得が可能

  • カスタム属性

    • 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
    • ショップごとにパフォーマンス追跡が可能
    • 入れない場合、アプリ全体でしか見れない
  • カスタム計測

まとめ

  • NewRelicはAdobe、Sansan、楽天

    • パフォーマンスに売り上げに繋がるサービスで多く採用
  • ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる

  • 最新動向としては、AIに注力

    • 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
  • NewRelicを導入して開発とインフラのコミュニケーションが改善

    • インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
    • 開発もパフォーマンスに対する意識が高くなった

Elastic Stackによるログの監視入門

ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一

昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立

Beat

  • Go言語エージェント。
    • データがあるところに仕込むと取り出してくれる
    • 送り先はSearchかLogstsh
    • File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々

Logstash

  • Rubyで書かれている
    • JRubyで実装されているため、Javaが必要だった
    • フィルタリングのようなパイプライン処理が可能

ElasticSearch

Kibana

  • nodejs
    • ElasticStackの窓口

導入とか

  • 大規模な場合はBeats→kafka→Logstashの構成でElasticsearchの負荷を下げる

  • nginxやApache2のログは、ファイルの場所とElasticsearchを指定するだけ

  • PacketBeatsはプロトコルを監視

  • パケットを指定するだけなので再起動は不要で後から差し込める。

    • オーバーヘッドがそこそこある。本番ではパケットをミラーリングして監視するといい
  • FilebeatやLogstashは1行1データではなく複数の行も観れる

    • パターンマッチを利用する(先頭がスペースだと複数行のデータとして扱う)
  • X-PackはClosedソース

    • 検索のクエリでアラートが可能(Kibanaにはアラートがない)
    • 例:10秒以内にエラーが5件
  • 機械学習でパフォーマンスを予測した曲線

    • NewRelicと被ってる
  • Elasticsearchは検索エンジンなので、パターンでログを検索して、それ以外のログが出たらアラートといった使い方のできる

感想

あまり情報を追いかけていない分野だったけど、サービスのクオリティが非常に高いと思った。

どのツールも得意な分野があるので組み合わせて使うのがいい感じ
先日のioドメイン障害といったリスクもあるけど、SaaSにお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.