JJUG ccc 2018 fall の感想、まとめ
今年は Python で自動化スクリプトを書いたり、インフラも含めたトラブルシューティングがメインで、 Java は 100行くらいしか書いていないのですが、JJUG ccc に行きました。結果としてはメチャメチャ勉強になりました。 振り返りとして、聞いたセッションのサマリや感想を書きたいと思います。
セッション一覧(午後から参加しました)
- 思考停止しないアーキテクチャ設計 - 川島義隆さん
- Serverless Architecture in the Java Ecosystem - PRATIK PATEL(IBM)さん
- Migration Guide from Java 8 to Java 11 - KUBOTA Yujiさん
- 秒間 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 - Hironobu Isodaさん(ウルシステムズ)& @nappa (Ryosuke Yamazaki)さん
- Scala とマイクロサービスでつくる証券会社とスタートアップ - 村上拓也さん(FOLIO)
思考停止しないアーキテクチャ設計 - 川島義隆さん
セッション資料: 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
アーキテクチャ設計とは
- アーキテクチャ: 設計上の重要な意思決定のこと。後からの変更が困難。
- アーキテクチャ設計は非機能要求を起点に考える
- 品質特性シナリオ: 非機能の品質特性(可用性、機能性...)ごとに作られたシナリオ
- それぞれのシナリオを満たすための戦略を考える
- それぞれの品質特性の間でトレードオフがある(具体例: ETC割引 - 柔軟性 vs テスト可能性)
- 戦略のパッケージが「アーキテクチャパターン」
- レイヤード、イベント駆動、マイクロカーネル...
- それぞれのアーキテクチャパターンの間にもトレードオフがある
アーキテクチャ設計のやり方
- どれくらい時間をかけるか？: コード規模によるが、20%くらい？
- 設計のコストと、やり直しのコストの総和が最小になるところ
- どのように評価するか？: 各品質特性シナリオをどの程度満たせているか
- どのようにメンテナンスしていくか？: ADR(Architecture Design Records) をソースコードの隣に残す
それでも考慮漏れは発生する
- 思考停止しない
- 機能要求からもアーキテクチャ要求は生まれる
- 機能要求から、データストア、キャッシングなどを見直す必要性
- 機能要求と非機能要求 のそれぞれを考慮する
- ビジネス環境とアーキテクチャのずれにより溜まる技術的負債
- 金銭的に定量評価し、優先順位をつけて対応する
感想
安定の @kawasima さん。アーキテクチャ設計というぼんやりした話を分かりやすく理解できた。 「なんとなくわかってること」を綺麗に言語化してくれた感じです。そして参考文献を読んでみたいと思いました。
Serverless Architecture in the Java Ecosystem - PRATIK PATEL(IBM)さん
セッション資料(関連動画): Serverless in the Java Ecosystem - YouTube
Serverless Architecture について
- サーバをプロビジョニング、管理せずにプログラムを実行する
- FAAS(Function As A Service) を利用したアーキテクチャ
メリット
- コスト: 実際にプログラムが動いている時間に対する課金
- スケーラブル
- サーバのプロビジョニングにかかるスキル、コスト、時間を節約できる
流れで捉える
アーキテクチャ設計において気をつけること
各Function を"小さく"保つ
- 実行時間を短くする: コスト、FAASの制約
- ランタイムで依存するライブラリ: 起動時間を短くする
- イベント駆動にする
- ステートレスにする
実際のデモ
- デプロイは CLI から簡単に行える
- ランタイムが小さければ起動は早くなる
- 連続する処理: それぞれの処理は小さく保ちたいが、連続性を保ちたいケース
感想
IBM の @prpatel さんによる英語でのセッション。内容としては基本的だなぁという印象。ただプレゼンテーションとスライドが素晴らしかった。
ステートや一時データを外出しするには、フロントエンドやデータ管理のところでより気をつける必要が有りそうだなぁと思いました。
「きれいなコード」じゃないと動かなくなるので、インフラを気にしなくて良くなる分、アプリも気をつけなきゃ行けなくなるのかなと。
Migration Guide from Java 8 to Java 11 - KUBOTA Yujiさん
セッション資料: Migration Guide from Java 8 to Java 11 #jjug
Java 11 移行のステップ
- ランタイムを 11 にしてテスト
- コンパイラを 11 にしてテスト
- (必要に応じて) モジュール化 - 今回は触れない
ランタイムを11 にして起こること
メリット
- Java8 は完全サポート
- flight recorder, TLS1.3 などの新機能を使える
- G1GC が Parallel Full GC になる, ZGC などの新しいGCを使える
- VM のパフォーマンス向上
互換性によるエラー
- JVM オプションがいくつか消えている
- loggin 周りのオプションは大きく変更されている
- oracleJDK では JavaFX が消えている
- JDK の内部APIが消えたり動いていたりしている
- Applet, Java-ws も消えている
- JDKのモジュール化によって起こるエラー: 大抵はオプションで回避できる
非機能の変更
- コンテナサポート: コンテナに割り当てられたリソースに応じて使用量を変える
- デフォルトGC が G1GC になっている
機能/挙動の変更(自分が気になったものPickUp)
- 数字/日付/時刻 のフォーマットが変わる
- Reference::clone 廃止
- Nashornがdeprecated
- Swing の見た目が変わる
- java.nio.channels.*Channel がリファクタされてBlocking/NonBlocking処理が分離
コンパイラを11にして起こること
基本方針は「エラーは諦めて11に対応する」「deprecated はコストと見合い、ただ消えることは覚悟しろ」
メリット
デメリット
- Java8 サポートが難しくなる
- 依存ライブラリのアップデート
- ビルド/CI環境のアップデート
実作業
- ビルド、CIツール変更
- mavan は 3.5.4以上
- FindBugs -> SpotBugs, Cobertula -> JaCoCo
- Applet, java-ws に代替するライブラリ導入
- ほとんどのライブラリ/プラグインはバージョンアップ必須
感想
OpenJDK 開発者の久保田さんによる裏話も交えたJava11移行の話。 なかなか大変そうだけど、やってみたいな...弊社でJava11チャレンジしたプロジェクトあるのかしら...
秒間 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 - Hironobu Isodaさん(ウルシステムズ)& @nappa (Ryosuke Yamazaki)さん
セッション資料: 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
広告RTBの概要
- SSP からのリクエストに対して100ms以内にBidを入れる必要がある
- ネットワークレイテンシも含めた100msなので、光速が遅くて大変。
- Bid処理にかけられる時間は数ms -> Logicad は平均 3ms
- スループットとレイテンシを向上させる必要がある
- メインはレイテンシ向上について
パフォーマンスチューニング
- とにかく測定
- 測定してホットスポットを見つけてアプローチ
- デプロイ前の性能テストで性能デグレを防ぐ
- 測定結果を可視化するのも大事
- perf でデータ取得、FrameGraphで可視化、JMeterで負荷をかける
FrameGraph
- perf でデータを取得、perf-map-agent でJavaメソッドとの対応を紐付け、FrameGraphでグラフ化
- メソッドの呼び出し関係、それぞれの所要時間がわかる
- 正規表現で該当箇所の検索ができる
- 幅を取っているところに注目する
- 修正前後の比較で性能デグレを検知できる
Real World でのチューニング
- Java 以外にもレイテンシの発生源はいっぱいある
- システム全体をみてチューニングする必要がある
- Java VM は疑われがち
- Looking Glass: ping/traceroute をたたけるツールでネットワークを検証
- Nginx: Nginx のログとJavaプロセスのログを突き合わせる
- 色んなツールを試すことで新たな発見がある
- FlameScope: CPUの使用率をモニタリング
- 1 core しか使っていない時間が見つかる
- logback のローテーション
- pmap になんかやられてる
- コスパ大事。経済合理性を意識して、ハマりすぎない。
- (質疑応答) system_call の回数を減らして strace からでも何から実行されたか分かるようにしている
感想
2016 spring で個人的に一番おもしろかった @nappa さん。 内容はその時のセッションの内容も含んでいたので、割と分かりやすかった。
セッション資料: https://www.slideshare.net/nappa_zzz/java-70326737
チューニングはシステム全体を見てやるべき、は完全同意。
Java の無罪を証明するのもJavaエンジニアの役目はパンチラインですね。
Scala とマイクロサービスでつくる証券会社とスタートアップ - 村上拓也さん(FOLIO)
セッション資料: Scala と Microservices でつくる 証券会社とスタートアップ / FOLIO in JJUG CCC 2018 Fall - Speaker Deck
Scala を選んだ理由
型システムの表現力
- case class で primitive をラップして名前をつける
- 何の数字/文字列なのかを宣言的に記述することで間違いをへらす
- 置き間違いを防ぐ(firstName, lastName)
- 意味の違う数字が混ざらないようにする(UnrealizedPnL, RealizedPnL)
- 暗号化してる/してないの表現
- 中置記法により、simple な記述で安全な演算を行う
- JPY + JPY はOK, JPY * JPY はNG
- 何の数字/文字列なのかを宣言的に記述することで間違いをへらす
- IDE サポートによりパッケージ構造の変更が簡単
MicroServices
- 前提
- 性格の違う業務を幅広く多数あわせ持つ
- 外接の多さ
- 高いサービス継続性が求められる
- MicroServices にすることで
- ドメイン知識を深める
- QA/リリース の方式を分ける
- 腐敗防止層をつくる
- 障害範囲の局所化
Domain Driven Development
MicroServices を支えるツール/フレームワーク
- Finagle: RPC フレームワーク
- IDL(thrift) を用いたRPC
Finatra: アプリケーションフレームワーク
- 豊富なメトリクスを取得できる
- 分散トレーシング
- Jenkins: ビルドだけでなく、バッチもJenkinsで(JP1がわり)
- Config as Code で Prod/Stg の環境差分を防ぐ、管理する
- folicon-bot: Consul に問い合わせるslackbot
- 各環境の状況をslackで共有できるように
感想
テーマ投資のスタートアップ Folio 村上さんのセッション。 Scala + MicroServeices + DDD が上手くハマって開発を進められていることが伝わってきます。 自社の仕事と同じドメインであることもあり、case class のメリットはすごく分かる...
終わりに
アーキテクチャ設計、サーバレス、Java11移行、チューニング、Scala と幅広く話を聞けて勉強になりました。 正直、こんなに楽しめると思っていなかったけど、ほんとに学びと刺激を貰えた一日でした。
特に最後の Scala の話は同業界ということもあり、非常に刺激がありました。
とにかく、行ってよかった！！
