稼働7年目のリアルタイムコメントシステム改善に向き合う、地道なSREアプローチ

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackC-4

Transcript

1. 稼働7年目のリアルタイム コメントシステム改善に向き合う、 地道なSREアプローチ REALITY株式会社 エンジニア 小田 大輔
2. 小田 大輔 / Daisuke Oda REALITY株式会社 エンジニア 2 • 主なお仕事 ◦ 開発生産性改善 ◦ インフラ費用削減・維持 ◦ パフォーマンス改善
3. 目次・アジェンダ • REALITYのご紹介 • リアクティブな対応による功罪 • コメントシステム改善の全体象 • 改善事例のご紹介 • 得られた教訓 3
4. REALITYについて 4
5. • スマホひとつでアバターライブ配信などを楽しめるアプリ • 12言語対応で63の地域で配信中 5 REALITYのご紹介
7. 7 売上高 65億円 営利 13億円
8. REALITYの 配信コメントシステム 8
9. 9 ←視聴者のコメント
10. コメントシステムについて 10 • システム構成 ◦ GKEで提供 ◦ WebSocketでのリアルタイム投稿・表示 • コメントで投稿されるデータ ◦ ユーザのテキスト入力 ◦ システムコメント群 ▪ ギフティング・フォロー・ミッション達成など • その他の機能 ◦ 裏で同時接続数などの配信属性を記録している システムコメント
11. 今までのコメントシステム への向き合い方 11
12. コメントシステムはリアクティブに問題改善していた 12
13. リアクティブな対応により起きていた問題 • 目指すべき方向を見失いがちで、負債も溜まってきた ◦ こういう部分から間接的に経済合理性も損なわれる • 事前対処の練度が下がる • 改善の余地がある場合でも、優先度が上がりづらい / 体系的 にどう改善したら良いか把握しづらい ◦ コアなシステムなのに 13
14. REALITYが10xする前に 体系的に改善する機構にしたい 14
15. 各分野で目標値を決め、制御工学的に健全性を保つ 例えば • 障害判定のラインを決める • トラフィックあたりの目安 料金 / スペック値を決める • 「テストカバレッジを上げる」のような指針を決める 15
17. • これによって目指すべき方向が明らかになり、システ ムの健全性がわかりやすく • 心理的にも安心感が生まれる • 体系的にシステムに向き合えることで価値提供がしや すくなるはず 17
18. 18 (コメントシステムのビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 テストを 書きやすい環境 BlueGreenデプロイ導入 可用性指標 の策定と計測 パフォーマ ンス改善
19. 取り組み 一挙ご紹介 19
20. 20 (ビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 テストを 書きやすい環境 可用性指標 の策定と計測 パフォーマ ンス改善 BlueGreenデプロイ導入
21. 21 コメントシステムのアーキテクチャ 全Podが全配信の コメントを受信 Node.js
22. Redis Pub/Subアーキテクチャのボトルネックについて • 全ユーザのコメントが全Podを経由するようになっていた ◦ 視聴者が誰もいない配信でも、全Podがその配信のコメントを Subscribeする • それにより負荷逼迫。残念ながらややユーザ影響が出ている • 接続中の最低限のPodのみ経由するようにしたい 22
23. Redis Pub/Subアーキテクチャ改善方針 • ユーザの接続実態があるPodだけ当該配信のRedis Channel にSubscribeするように変更 • 注意したこと ◦ Redisのコマンド計算量の変化を細かく見積もった ▪ キャパシティプランニングの意味で 23
25. 改善後のアーキテクチャ 25 Node.js
26. ついでに負荷分散の強化 • 一定以上のCPU利用率になったらk8s readiness probeを失 敗させて均等に負荷分散するように ◦ WebSocketで長時間接続し続ける特性上、このような機 構に ◦ 他のWebSocket系サーバで実装している仕組みを輸入 26
27. パフォーマンス改善幅 27 PodのCPU 66%DOWN & メモリ90% Down イベントループラグ安定 Pub/Sub用のRedisのCPU負荷半減 さらにPod数も改善前の 3分の1で済むように
28. また、Redis Pub/Subも水平分割することで 理論上は無限水平スケールが可能に 28
29. 29 (ビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 テストを 書きやすい環境 パフォーマ ンス改善 可用性指標 の策定と計測 ※SREプラクティスでいうSLAや エラーバジェットの策定に近い
30. 可用性指標の策定と計測 • パフォーマンスの健全性を管理するため策定 ◦ デプロイ頻度も上がってきたので事故率を可視化したい という意図がある • 以下の項目を可用性指標としました ◦ 1. WebSocket接続直後のコメントデータレスポンスレイテンシ ◦ 2. コメント投稿から他ユーザがSubscribeするまでのレイテンシ 30
31. 可用性指標の計測方針 • OpenTelemetryでレイテンシ計測していく ◦ メトリクスはGoogle Cloud Monitoringに保存 • まず当時、Node.jsのバージョンを12から18に上げた。 ◦ OpenTelemetry JavaScript SDKの安定版が当該Node.jsバージョンに 対応していなかったので。 31
32. 可用性指標の計測の実装 • 接続時の初期データレスポンスレイテンシの計測方法 ◦ WebSocket handshake完了時のtimestampを記録 ◦ レスポンス直前のtimestampとの差分をレイテンシとして記録 • コメント投稿レイテンシの計測方法 ◦ コメント投稿時のpublishデータにtimestampを記録 ◦ Redis subscribeでデータを受け取った時点との差分をレイテンシとする 32
33. 可用性ダッシュボード 一定値以上になるとアラートが飛ぶ。 「一定の閾値に保つ」というフィードバックループを回せるようになった 33
34. 34 (ビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 テストを 書きやすい環境 パフォーマ ンス改善 可用性指標 の策定と計測 BlueGreenデプロイ導入
35. WebSocket + GKE + IstioでのBlueGreenデプロイ • リリース時にGreen環境を作成 • HTTPヘッダーベースで、開発者のみGreen環境にアクセス して動作確認できるように 35
36. 具体的には • WebSocketハンドシェイク時の HTTPリクエストのヘッダの値を元 にIstioのVirtualServiceでトラ フィック振り分け(つまりL7) 36
37. イメージ図 37
38. • 使い方を細かくドキュメント化し、不安感をやわら げながら展開 • GKE + IstioでWebSocketサーバをトラフィック制 御している事例が少ない ◦ 国内でも有数の事例になった 38
39. 39 (ビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 パフォーマ ンス改善 可用性指標 の策定と計測 テストを 書きやすい環境 BlueGreenデプロイ導入
40. • 人によってテストを書いたり書かなかったり まちまち • テストカバレッジ不明 • データストアと通信するテストが書きづらい 40 コメントシステムのテストの課題点
41. 1. Jestの導入 2. コンテナでテスト実行するように 3. Redisをテストコンテナで動かすように ◦ モックではなく実物で動かしたい 41 [やったこと1]まずテストを実行しやすい環境づくり
42. [やったこと2]テストカバレッジの可視化 42
43. [やったこと2]テストカバレッジの可視化 43 1. Github Actionsでカバレッジデータ生成 2. Cloud Storageにアップロード 3. Looker Studioで2をデータソースにして グラフとしてダッシュボード化
44. 44 (ビジネスオーダー) 信頼性維持 素早く価値提供 パフォーマ ンス改善 可用性指標 の策定と計測 テストを 書きやすい環境 ソフトウェア アーキテクチャ改善 BlueGreenデプロイ導入
45. コメントシステムのコードベースの課題 • 起きていた現象 ◦ ロジックが入り組み肥大化 & 凝集度が低下してきている部 分が多々ある • 生じた課題 ◦ ドメイン知識が把握しづらい / 開発に時間がかかる 45
46. コードベースの改善の進め方 • 改善に興味のある有志メンバーでキックオフした ◦ 課題の炙り出し / 優先度付 / 目線合わせの実施 ◦ 有志メンバー = DevOpsチーム + サーバチーム • 優先度が高い & 抽象度の高い課題は ◦ 特に関心が高いメンバーで話し合って詳細方針を決めた 46
47. 良い改善は良い問いから Q.ソフトウェアアーキテクチャを なぜ改善するのか？ 47
48. 良い改善は良い問いから A. 機能ドメインが整理され、価値 提供しやすくなるから 48 さらに言うと この改善幅が大きいから
49. キックオフ実施 49 実際の議事録
51. チケット化してみんなで消化 51
52. “コードベース改善の取り組み”で得られた効果 • コメントサーバの機能開発がしやすくなった ◦ APIハンドラをRESTのリソースごとにファイル分割した ◦ APIハンドラと同じ場所に定義されていたドメインロジック群も 専用の層に分離した、など • コメントサーバについて詳しいメンバーが増えるという副次 効果も 52
53. 全体像まとめ 53
54. 54 (コメントシステムのビジネスオーダー) 信頼性維持 素早く価値提供 ソフトウェア アーキテクチャ改善 テストを 書きやすい環境 BlueGreenデプロイ導入 可用性指標 の策定と計測 パフォーマ ンス改善
55. 全体を通して得られた教訓 • 相変わらず銀の弾丸は無いが、SRE文化が発展してきたこと により参考にしやすい事例が増えた • 最初に抽象的なものをコアメンバーで潰し、協力者に具体タ スクとして展開していく方法がワークした • ついでにNode.jsのランタイム知見が得られた 55
56. Goodbye, Silver Bullet! 56
57. ご清聴ありがとうございました 57