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

by gree_tech

Slide 1

Slide 1 text

稼働7年目のリアルタイムコメントシステム改善に向き合う、地道なSREアプローチ REALITY株式会社エンジニア小田大輔

Slide 2

Slide 2 text

小田大輔 / Daisuke Oda REALITY株式会社エンジニア 2 ● 主なお仕事 ○ 開発生産性改善 ○ インフラ費用削減・維持 ○ パフォーマンス改善

Slide 3

Slide 3 text

目次・アジェンダ ● REALITYのご紹介 ● リアクティブな対応による功罪 ● コメントシステム改善の全体象 ● 改善事例のご紹介 ● 得られた教訓 3

Slide 4

Slide 4 text

REALITYについて 4

Slide 5

Slide 5 text

● スマホひとつでアバターライブ配信などを楽しめるアプリ ● 12言語対応で63の地域で配信中 5 REALITYのご紹介

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 売上高 65億円営利 13億円

Slide 8

Slide 8 text

REALITYの配信コメントシステム 8

Slide 9

Slide 9 text

9 ←視聴者のコメント

Slide 10

Slide 10 text

コメントシステムについて 10 ● システム構成 ○ GKEで提供 ○ WebSocketでのリアルタイム投稿・表示 ● コメントで投稿されるデータ ○ ユーザのテキスト入力 ○ システムコメント群 ■ ギフティング・フォロー・ミッション達成など ● その他の機能 ○ 裏で同時接続数などの配信属性を記録しているシステムコメント

Slide 11

Slide 11 text

今までのコメントシステムへの向き合い方 11

Slide 12

Slide 12 text

コメントシステムはリアクティブに問題改善していた 12

Slide 13

Slide 13 text

リアクティブな対応により起きていた問題 ● 目指すべき方向を見失いがちで、負債も溜まってきた ○ こういう部分から間接的に経済合理性も損なわれる ● 事前対処の練度が下がる ● 改善の余地がある場合でも、優先度が上がりづらい / 体系的にどう改善したら良いか把握しづらい ○ コアなシステムなのに 13

Slide 14

Slide 14 text

REALITYが10xする前に体系的に改善する機構にしたい 14

Slide 15

Slide 15 text

各分野で目標値を決め、制御工学的に健全性を保つ例えば ● 障害判定のラインを決める ● トラフィックあたりの目安料金 / スペック値を決める ● 「テストカバレッジを上げる」のような指針を決める 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

● これによって目指すべき方向が明らかになり、システムの健全性がわかりやすく ● 心理的にも安心感が生まれる ● 体系的にシステムに向き合えることで価値提供がしやすくなるはず 17

Slide 18

Slide 18 text

18 (コメントシステムのビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善テストを書きやすい環境 BlueGreenデプロイ導入可用性指標の策定と計測パフォーマンス改善

Slide 19

Slide 19 text

取り組み一挙ご紹介 19

Slide 20

Slide 20 text

20 (ビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善テストを書きやすい環境可用性指標の策定と計測パフォーマンス改善 BlueGreenデプロイ導入

Slide 21

Slide 21 text

21 コメントシステムのアーキテクチャ全Podが全配信のコメントを受信 Node.js

Slide 22

Slide 22 text

Redis Pub/Subアーキテクチャのボトルネックについて ● 全ユーザのコメントが全Podを経由するようになっていた ○ 視聴者が誰もいない配信でも、全Podがその配信のコメントを Subscribeする ● それにより負荷逼迫。残念ながらややユーザ影響が出ている ● 接続中の最低限のPodのみ経由するようにしたい 22

Slide 23

Slide 23 text

Redis Pub/Subアーキテクチャ改善方針 ● ユーザの接続実態があるPodだけ当該配信のRedis Channel にSubscribeするように変更 ● 注意したこと ○ Redisのコマンド計算量の変化を細かく見積もった ■ キャパシティプランニングの意味で 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

改善後のアーキテクチャ 25 Node.js

Slide 26

Slide 26 text

ついでに負荷分散の強化 ● 一定以上のCPU利用率になったらk8s readiness probeを失敗させて均等に負荷分散するように ○ WebSocketで長時間接続し続ける特性上、このような機構に ○ 他のWebSocket系サーバで実装している仕組みを輸入 26

Slide 27

Slide 27 text

パフォーマンス改善幅 27 PodのCPU 66%DOWN & メモリ90% Down イベントループラグ安定 Pub/Sub用のRedisのCPU負荷半減さらにPod数も改善前の 3分の1で済むように

Slide 28

Slide 28 text

また、Redis Pub/Subも水平分割することで理論上は無限水平スケールが可能に 28

Slide 29

Slide 29 text

29 (ビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善テストを書きやすい環境パフォーマンス改善可用性指標の策定と計測 ※SREプラクティスでいうSLAやエラーバジェットの策定に近い

Slide 30

Slide 30 text

可用性指標の策定と計測 ● パフォーマンスの健全性を管理するため策定 ○ デプロイ頻度も上がってきたので事故率を可視化したいという意図がある ● 以下の項目を可用性指標としました ○ 1. WebSocket接続直後のコメントデータレスポンスレイテンシ ○ 2. コメント投稿から他ユーザがSubscribeするまでのレイテンシ 30

Slide 31

Slide 31 text

可用性指標の計測方針 ● OpenTelemetryでレイテンシ計測していく ○ メトリクスはGoogle Cloud Monitoringに保存 ● まず当時、Node.jsのバージョンを12から18に上げた。 ○ OpenTelemetry JavaScript SDKの安定版が当該Node.jsバージョンに対応していなかったので。 31

Slide 32

Slide 32 text

可用性指標の計測の実装 ● 接続時の初期データレスポンスレイテンシの計測方法 ○ WebSocket handshake完了時のtimestampを記録 ○ レスポンス直前のtimestampとの差分をレイテンシとして記録 ● コメント投稿レイテンシの計測方法 ○ コメント投稿時のpublishデータにtimestampを記録 ○ Redis subscribeでデータを受け取った時点との差分をレイテンシとする 32

Slide 33

Slide 33 text

可用性ダッシュボード一定値以上になるとアラートが飛ぶ。「一定の閾値に保つ」というフィードバックループを回せるようになった 33

Slide 34

Slide 34 text

34 (ビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善テストを書きやすい環境パフォーマンス改善可用性指標の策定と計測 BlueGreenデプロイ導入

Slide 35

Slide 35 text

WebSocket + GKE + IstioでのBlueGreenデプロイ ● リリース時にGreen環境を作成 ● HTTPヘッダーベースで、開発者のみGreen環境にアクセスして動作確認できるように 35

Slide 36

Slide 36 text

具体的には ● WebSocketハンドシェイク時の HTTPリクエストのヘッダの値を元にIstioのVirtualServiceでトラフィック振り分け(つまりL7) 36

Slide 37

Slide 37 text

イメージ図 37

Slide 38

Slide 38 text

● 使い方を細かくドキュメント化し、不安感をやわらげながら展開 ● GKE + IstioでWebSocketサーバをトラフィック制御している事例が少ない ○ 国内でも有数の事例になった 38

Slide 39

Slide 39 text

39 (ビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善パフォーマンス改善可用性指標の策定と計測テストを書きやすい環境 BlueGreenデプロイ導入

Slide 40

Slide 40 text

● 人によってテストを書いたり書かなかったりまちまち ● テストカバレッジ不明 ● データストアと通信するテストが書きづらい 40 コメントシステムのテストの課題点

Slide 41

Slide 41 text

1. Jestの導入 2. コンテナでテスト実行するように 3. Redisをテストコンテナで動かすように ○ モックではなく実物で動かしたい 41 [やったこと1]まずテストを実行しやすい環境づくり

Slide 42

Slide 42 text

[やったこと2]テストカバレッジの可視化 42

Slide 43

Slide 43 text

[やったこと2]テストカバレッジの可視化 43 1. Github Actionsでカバレッジデータ生成 2. Cloud Storageにアップロード 3. Looker Studioで2をデータソースにしてグラフとしてダッシュボード化

Slide 44

Slide 44 text

44 (ビジネスオーダー) 信頼性維持素早く価値提供パフォーマンス改善可用性指標の策定と計測テストを書きやすい環境ソフトウェアアーキテクチャ改善 BlueGreenデプロイ導入

Slide 45

Slide 45 text

コメントシステムのコードベースの課題 ● 起きていた現象 ○ ロジックが入り組み肥大化 & 凝集度が低下してきている部分が多々ある ● 生じた課題 ○ ドメイン知識が把握しづらい / 開発に時間がかかる 45

Slide 46

Slide 46 text

コードベースの改善の進め方 ● 改善に興味のある有志メンバーでキックオフした ○ 課題の炙り出し / 優先度付 / 目線合わせの実施 ○ 有志メンバー = DevOpsチーム + サーバチーム ● 優先度が高い & 抽象度の高い課題は ○ 特に関心が高いメンバーで話し合って詳細方針を決めた 46

Slide 47

Slide 47 text

良い改善は良い問いから Q.ソフトウェアアーキテクチャをなぜ改善するのか？ 47

Slide 48

Slide 48 text

良い改善は良い問いから A. 機能ドメインが整理され、価値提供しやすくなるから 48 さらに言うとこの改善幅が大きいから

Slide 49

Slide 49 text

キックオフ実施 49 実際の議事録

Slide 50

Slide 50 text

Slide 51

Slide 51 text

チケット化してみんなで消化 51

Slide 52

Slide 52 text

“コードベース改善の取り組み”で得られた効果 ● コメントサーバの機能開発がしやすくなった ○ APIハンドラをRESTのリソースごとにファイル分割した ○ APIハンドラと同じ場所に定義されていたドメインロジック群も専用の層に分離した、など ● コメントサーバについて詳しいメンバーが増えるという副次効果も 52

Slide 53

Slide 53 text

全体像まとめ 53

Slide 54

Slide 54 text

54 (コメントシステムのビジネスオーダー) 信頼性維持素早く価値提供ソフトウェアアーキテクチャ改善テストを書きやすい環境 BlueGreenデプロイ導入可用性指標の策定と計測パフォーマンス改善

Slide 55

Slide 55 text

全体を通して得られた教訓 ● 相変わらず銀の弾丸は無いが、SRE文化が発展してきたことにより参考にしやすい事例が増えた ● 最初に抽象的なものをコアメンバーで潰し、協力者に具体タスクとして展開していく方法がワークした ● ついでにNode.jsのランタイム知見が得られた 55