JJUG CCC 2022 Spring に参加しました。オンライン開催。簡単に所感をまとめます。
所感
久しぶりにリアルタイムで参加しました。質疑応答ができるのがリアルタイムのいいところ。時間の都合上、4セッションくらいしか参加できなかったけど、他にも気になるセッションがあるのであとでアーカイブを見直そう。
PayPay祭の事例ですが、負荷対策は自分としても気になるところなので興味深い内容でした。毎週、負荷試験してるのはすごい。やっぱり自動化してるんだろうなと思いますが、そのあたりのノウハウも知りたい。
リモートワークの話、オンボーディングのドキュメントは新規メンバーごとに用意しているらしい。環境セットアップの手順だけではなく、直近のオンボーディングタスク (簡単な修正タスク) まで書いてあるとよさそう。ドキュメントを継続的にメンテするのはなかなかハードル高いけど、リモートワークがデフォルトの環境で非同期コミュニケーションのメリットをフルに生かすなら乗り越えないといけない課題。このあたりは会社の文化として醸成する必要がありそう。
TiDB はどうなんだろう。MySQL プロトコル互換で導入はしやすそうかもしれないけど、運用まで見据えるとなんとなくもう少し検証しないといけないことが多そうな印象。
以下、メモから抜粋。セッション資料が公開されたらリンクを追記します。
クラウドネイティブ環境におけるJavaチューニングの進め方 - 超PayPay祭の事例
- どのシステムで問題が発生しているか
- システム間の相互作用が影響しているかも
- マイクロサービスだと構成するコンポーネントが多い
- どこに原因があるか特定しにくい
- Metrics, Traces, Logs
- 全体負荷試験
- シナリオベース
- 常時負荷試験
- 毎週夜間に全体負荷試験の7割程度の負荷をかける
- ポイント計算APIシステム
- Full GC 頻発
- リソース使用量は変えたくない
- G1GC > CMSGC
- Java 11 のデフォルトは G1GC
- G1GC はヒープサイズ6GB以上でパフォーマンス発揮する
- リソース使用量は抑えたい
- CMSGC はヒープサイズが低くても性能が出やすい
- New 領域で GC を完結させたい
- ヒープのうち New 領域の割合を拡大
- MaxTenuringThreshold
- 最小ヒープサイズ = 最大ヒープサイズ
- 稼働中にヒープ確保しない
- OOM で exit させるように
- k8s のオートヒーリングで自動復旧させる
- 10000rps くらいから Pod ダウン
- Sidecar がボトルネックに
- OOM でコンテナ Kill
- sidecar 形式 > クライアントライブラリ形式に
- リソース制限を考慮して
- Sidecar がボトルネックに
- 同じ条件で負荷試験を実施する
- すべての構成要素のメトリクスを確認する
- 全体負荷試験はメンテナンスモードにして実施
- 負荷対策チーム
- 年度始めにチームを構成する
- 通常の業務をやりながら負荷対策の役割が与えられるイメージ
- 負荷試験で目標超えられなかったら
- ポイント計算APIシステムで流量制限する
Lauchableで僕が学んだ働き方 〜リモートワークで会社もプロダクトも１から作る経験〜
- エンジニアリングをデータドリブンに
- 営業や企画はデータドリブンに仕事している
- エンジニアは今でも経験や勘に頼っているところが多い
- ドキュメント
- オンボーディング
- 入社から1週間分くらいのやることがまとまっている
- 設計書は書かない
- デザインドキュメントとして書く
- ドキュメントでは How だけでなく Why (問題背景) を共有するのが大事
- 仕様レビュー > ドキュメント
- 実装レビュー > PR
- コラボレーションマニフェスト
- Swim Lanes
- 自分の役割に対して説明責任がある
- 透明性
- 決定の内容や経緯が見えるように
- 発見可能
- Connected
- アンバサダー
- Writing Matters
- 書くコストは高いが読む方は時間を節約できる
- 会議を最後の手段に
- 書くプロセスは考えることが必要
- 非同期コミュニケーション/集中
- 他者の時間を奪わないように
- メンテ
- 古い情報を見つけた人が直す
- 不要なものはアーカイブする
分散データベースTiDB Cloudで構築するWebアプリケーション
- PingCAP
- MySQLプロトコル互換
- TiDB
- SQL解析
- クエリ増加に応じてスケールアウト
- TiKV
- データ容量やI/O増加に応じてスケールアウト
- どのサーバーに接続しても最新データにアクセス可
- アプリケーション側でアクセス先を判断する必要なし
- シャーディング
- 内部でリージョン単位で分割
- キー不要
- スケールアップ
- Spring Data JPA + Hibernate ORM
- 外部キーはない
- MySQL57Dialect
- TiDBDialect
- TiDB Cloud
- TiFlash
- スケールアップ
- 載せ替え？
- スケールアウト
- TiUp？
- 5-10分
- TiKV だとデータの再バランスは少し時間かかりそう
RDRA + JavaによるレジャーSaaSプロダクトの要件定義と実装のシームレスな接続
- 業務, BUC, アクティビティ
- 情報
- 関連する情報をどのようなユースケースで操作するのか
- 情報は状態を持つ
- どのUCが状態を遷移させるか
- バリエーション/条件
- システムがバリエーションごとにどのように振る舞いを変えるか
- UCごとに条件 (ビジネスルール) を明確化
- 消費税などは状態がないビジネスルールとして扱う
- 情報 → 概念モデル
- 情報の関連付けを整理する
- オブジェクトモデル (具体例)
- UC複合表
- 外部システムの定義の網羅性を spreadsheet の関数で見つける
- RDRA, 3層+ドメイン層アーキテクチャ
- 1UC-1サービス
- 状態を判断するのはドメインロジック
- 状態を伝えるのは enum
- UC実装
- 条件を定義するのはドメインロジック
- 条件を発動する (呼び出す) のは Validation, Controller, Service, ...
- RDRA-Java の整合チェックは JIG ドキュメント
