JJUGナイトセミナー「Jakarta EE, MicroProfile, Payara が目指すもの」へ行ってきた
風邪気味の金曜日、そして週末胃腸炎。ちょっと回復したのでようやく書けた・・・。
EE4J
- Eclipseトップレベルプロジェクト。Eclipseのルールで開発する。
- SpecLead、Comitterやコントリビュータ
- 普通のOSSに近い?
- マイグレーションはだいたい80%
- CDI、JavaBatchはEE4Jに含まれない
- MicroProfileは今の所EE4Jには入ってない
- EE4Jで開発したものでも、Jakarta EEに入るとは限らない
Jakarta EE
今後のロードマップ
- 年末くらいにJava EE 8のTCKをEclipse Glassfishに通るようにする
- Jakarta EE 8の仕様を策定してTCK作る
- 極力 Java EE 8に近いものになる想定
- その後Jakarta EE 9の開発
未定のこと
- ライセンスはできるだけオープンにして欲しいとは言われてる
- しかし、EE4Jほどにはならないと思われる
- ワーキンググループに参加するためのFee
- Glassfishの扱いが未定
- リリース頻度をあげたい
- すでにある仕様の取り扱い
- 法的に持ってこれないものも多い・・・
- その場合スクラッチで構築しなければいけない
- javaxパッケージの取り扱い
Microprofile
- 2.0がリリース
- Payara MicroやOracleのHelidon等がある
- 日本ではあまり知られてない
- 海外でもまだこれからっぽい
雑感
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の組み合わせ。 公式のデモもある。
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
でも辛いところもある
ペイロードのバリデーションで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で実装したのは↓
まとめ
ちょっとしたハックから普段の工夫まで色々な話が聞けてよかったです
来月もJSUG勉強会は開催予定なので楽しみ
JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に行ってきた
花粉症つらい・・・
お知らせ
JavaDayTokyo2018
5/17(木)に決定。
キーノートはMark Reinhold(初来日?)
登録サイトは近日オープン(多分、今週後半くらいとのこと)
JJUG CCC 2018 CfP募集中
JDKリリースモデル変更について(おさらい) by 伊藤 敬さん(Oracle)
Java 10はおそらく初めて予定通りリリースされたJava。
リリースノートには削除予定のAPIも記載されているので確認しておくこと。
JDK10の追加機能解説 - JEP286/ローカル変数の型省略(var記法)を中心に
ローカル変数の型推論
冗長な変数の型の宣言をvarに置き換えられる。
動的言語になるわけじゃない。
メソッドの引数・戻り値には使えない。
また、匿名クラスにも使えない。
varは予約語ではないキーワード。
そのかわり、クラスやインターフェースでは使えなくなった。
(非互換だけど、流石に使ってる人いないよね・・・)
変数やフィールド、メソッドでは使えるからこれはOK。(絶対やるなよ的な・・・)
var var = var();
varの使いどころは、読みやすさが向上する箇所。
Javaの書きやすさより読みやすさを重視している文化は破っちゃダメ。
型をタイプするのが面倒とかそんな理由で使ってはダメ。
IDEがなくても理解できる状態で使うべき。
マウスポインタを上に乗っければわかるはNG。
varのガイドラインも出ている。
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年後だった。
それが比較的すぐに手に入る。
でも、アップデートに追従するコストが大変。
新しいバージョンへの対応方法
新しいバージョンの変更箇所は、以下の
- JEPから新機能
- 最新のJRSからAPIの変更点
- リリースノートから非互換
STSで非推奨化・削除と続くと、LTSから次のLTSにいきなり移った時に、サイレント削除が発生する可能性がある
Class-Data Sharing
元々はコマーシャル機能。
クラスデータを複数のプロセスで共有する。
バッチとかのプロセスをたくさん起動するアプリで利用できる
読み込むクラスの量が多いほど効果的
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のような仕組みは取り入れる予定。
OracleはJava 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の特徴
利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSにHTTPSで送信。
- 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言語に対応
遅いトランザクションや直近のアラートが観れる
- アラートは集中管理。通知チャネルや設定条件が豊富
ダイナミックベースラインアラート
- 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
内部サービスの呼び出し階層が観れる
- 一覧で赤いとアラートが発生している
インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨
デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる
- デプロイ前後のパフォーマンスが比較
- デプロイした時刻が残るので調査に役立つ
応用編
ソースコードを修正することで、さらなる情報取得が可能
カスタム属性
- 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
- ショップごとにパフォーマンス追跡が可能
- 入れない場合、アプリ全体でしか見れない
カスタム計測
- メソッドに指定することでトランザクションのトレースをより詳細に見るために必要
まとめ
-
- パフォーマンスに売り上げに繋がるサービスで多く採用
ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる
最新動向としては、AIに注力
- 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
NewRelicを導入して開発とインフラのコミュニケーションが改善
- インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
- 開発もパフォーマンスに対する意識が高くなった
Elastic Stackによるログの監視入門
ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一
昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立
Beat
- Go言語エージェント。
- データがあるところに仕込むと取り出してくれる
- 送り先はSearchかLogstsh
- File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々
Logstash
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にお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.