Chonaso's Commentary

InternetやIT技術などについて知ったこと、試したこと、考えたことを書いていきます。

JJUG CCC 2018 Fallに行ってきました #jjug_ccc

ここのところ、仕事の大半がPHPなのでJavaの話題に触れたい&刺激をもらいにJJUG CCC 2018 Fallに足を運びました。 所用があったので後半からでしたが非常に興味深い内容ばかりでした。


Deep dive into instanceof #ccc_a5

Deep dive into instanceof

広告配信システムを担当している登壇者が指摘された 「ハイパフォーマンスが求められる環境においてinstanceofは悪手、そもそもdowncastはoop的に設計が間違っているケースが多いのでは」 というレビューコメントを端緒にJavaVMのコードを追ってみた、という内容で、 単なるループで回している(辿る)わけではなく、実際にはinstanceofに耐えうるKlassのクラス設計(紛らわしい)や継承/実装の違いやツリーの深さなどでアルゴリズムを変えるなどのそれなりの考慮がなされているということでした。

Javaとは縁遠いプログラムカウンタやスタックポインタなどを知らないと即死するような内容でしたが、 デバッガを使っているとたまによく見るKlassが出てきたり、 instanceofのパフォーマンス向上についてはそれなりの紆余曲折があった*1のだな、ということを知りました。

思えば学生時代はC言語のライブラリのソースコードを読んでいたのにJVMのソースとか読む気が起きたことがなかったなぁ。 (PHPは必要にかられて読むことがある…)

ただ、あの内容だと場合によってはレビューコメント論破できる(instanceofでもいい)ケースもあるのでは?という気もしなくない(笑)


オイラ大地の18年拡張し続けているECサイトをSpring Bootとk8s on Azureでマイクロサービス化する事例 #ccc_a6

オイラ大地の18年拡張し続けているECサイトをSpring Bootとk8s on Azureでマイクロサービス化する事例

  • 品質の維持
  • ローンチスピード
  • スケーラビリティ

この3つを満たすシステムを開発・保守していくにはという問題に対し、マイクロサービスアーキテクチャでアプローチしていくことを決め、 kubernetes on Azureに辿り着いて絶賛マイグレーション中です、という内容。

自分も以前とある死にかけの会社にブチこまれて上記3課題を解決するよう命ぜられ、マルチクラウド移行やマイクロサービス(当時はこの呼び方はまだなかった)を絡めたシステム移行を手がけたので色々思うところがありました。 そしてECでJavaでモノリシックでOracleで…とこれまた構成も似てて「歴史のあるJavaシステムってなんだか知らないけどOracle多いよね!」と色々と思い出しました。

マルチクラウドあるあるとしては「サービスがクラウド越えするのでレスポンスが悪化する(下手すりゃ複数回往復する)」「これまで磨き上げたCD(継続的デリバリ)が使えない」など、マイクロサービス化あるあるとしては「トランザクションが越えられない」「今まではDB上でjoinしてた」などあり、これらの問題は、個々に少しづつ解決・移行していっているとのこと。

マイクロサービス化のフレームワークとしてのSpring bootは割愛だったのでもはやJavaとは直接関係ないセッションになっていましたが、Javaを使う会社は硬い感じがするので一度動いてるシステムに手をいれるということに難色を示す非エンジニアリング部署(ともすればシステム担当も)との云々も多いでしょうから皆感じ入るところが多かったのではないでしょうか。


GCを発生させないJVMとコーディングスタイル #ccc_a7

GCを発生させないJVMとコーディングスタイル

タイトルからすると「こういう処理はこういうコードを書けばGCは起こらない!」的な内容に見えますが、このセッションではJVM(GC)の種類やコンパイラオプションによってどのように変わるかという内容でした。

昔とあるJavaの勉強会で何度かJavaのメモリ設定やGCについての内容を発表したことがありますが、その辺とはレベルが全く異なり2つ前のセッション同様PCやSP、ニーモニックが普通に出てくる内容でした。 また、デモが多かったのですがJVMオプションを手打ちでバシバシ入れていく姿はさすがJVM開発者ですね...

恥ずかしながらTLAB(Thread-Local Allocation Buffer)やEscape Analysis(EA)は初めて知りました。 説明は非常にわかりやすかったです。 ただ、正直この動きを読みながらチューニングしたりできるかと言われると・・・今度Javaシステムのお世話をした時に妙なGC挙動があったとき思い出せればいいなと思います。

つまるところGC抑止の唯一無二の策というものは存在せずJVMの種類やインライン状況によってはGCが発生したりしなかったりするもので、コンパイラの動きを予測してトリッキーなコードを書くのではなく「まずは見やすいコードを」とのことでした。 おそらく見やすい素直なコードが日々進化していくJVM進化の恩恵を一番受けやすいということなのでしょう。


※発表スライドが公開されたら更新します