REALITYアプリのメンテナンスなしでの機能リリースを実現する、Istio導入とB/Gデプロイ実現の取り組み

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

Transcript

1. はじめまして
2. 2 REALITY株式会社 エンジニア Oda Daisuke • 主なお仕事 ◦ DevOps改善の取り組み ◦ グロース系の施策開発 ◦ パフォーマンス改善
3. REALITYアプリのメンテナンスなしでの 機能リリースを実現する、Istio導入と B/Gデプロイ実現の取り組み REALITY株式会社 小田 大輔
4. おしながき 1. サービスのご紹介 2. サーバの機能リリースについて 3. なぜメンテナンスが必要だったか 4. BlueGreenデプロイメントによる解決 5. 導入の苦労 6. 得られた効果 7. 今後の課題・展望 8. まとめ 4
5. 1. サービスのご紹介 2. サーバの機能リリースについて 3. なぜメンテナンスが必要だったか 4. BlueGreenデプロイメントによる解決 5. 導入の苦労 6. 得られた効果 7. 今後の課題・展望 8. まとめ 5
6. REALITYのご紹介 • スマホひとつでアバター作成、ライブ配信などを楽しめるアプリ • 12言語対応で63の地域で配信中 6
7. ユーザ数・DL数も成長中 7
8. リクエスト数もストレージも成長中 8
10. 2. サーバの機能リリースについて 10
11. REALITYでは 毎週水曜日 14:00〜15:00 定期メンテナンスをしていました 11
12. 1. 機能のリリース a. 中程度以上の機能はメンテナンス中にリリースすることが多い 2. インフラリソース調整 a. Google Kubernetes Engineクラスタのアップグレード b. CloudSQLのメンテナンスウィンドウなど 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 12 メンテナンス中に何をしている？
13. 1. 機能のリリース a. 中程度以上の機能はメンテナンスにリリースすることが多い 2. インフラリソース調整 a. CloudSQLのメンテナンスウィンドウなど b. Google Kubernetes Engineクラスタのアップグレード i. サージアップグレード (同時更新台数)設定で、無停止更新も可能ではある 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 13 メンテナンス中に何をしている？
14. 1. 機能のリリース a. 中程度以上の機能はメンテナンスにリリースすることが多い 2. インフラリソース調整 a. CloudSQLのメンテナンスウィンドウなど b. Google Kubernetes Engineクラスタのアップグレード 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 14 メンテナンス中に何をしている？
15. • ユーザ視点 ◦ 1時間の間、全ての機能を利用できなくなる ◦ アプリ利用中の場合は全ての操作が強制終了し、メンテナンス画面に飛ばされる • 運営側視点 ◦ 1時間ユーザがいなくなることによる売上の損失 ◦ ユーザへのお知らせやチーム間の連携コストなど ◦ 前日のメンテナンス作戦会議やメンテナンス直前の準備 MTGなど、シンプルに準備の時間がかかる 15 メンテナンスをすると何が起こるか
16. 3. なぜメンテナンスが必要だったか 16
17. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかった ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない • A2. マイクロサービス間の生合成担保のため ◦ 複数マイクロサービスを同時にリリースすることができない ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 17
18. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかったから ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない • A2. マイクロサービス間の整合性担保のため ◦ 複数マイクロサービスを同時にリリースする仕組みがない。 ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 18
19. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかったから ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない • A2. マイクロサービス間の生合成担保のため ◦ 複数マイクロサービスを同時にリリースすることができない ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 19
20. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかったから 20 ↑こちらのテーマを重点的に話していきます
21. REALITYのサーバアーキテクチャ 21
22. REALITYのサーバアーキテクチャ 22
23. 改善前のリリースフロー 23 画像引用 https://argo-cd.readthedocs.io ArgoCDで、更新のあるサーバーだけ新しいイメージの Podと入れ替える
24. 改善前のリリースフロー 24 画像引用 https://argo-cd.readthedocs.io/en/stable/ ここでデプロイした瞬間、本番に反映される。 本番特有の問題が起きた際ユーザ影響が発生。
25. 4. リリース時の問題点、 BlueGreenデプロイメントで 解決しました 25
26. 理想とするBlueGreenデプロイメント.1 26 内部のユーザのみがアクセス可能 (Green環境) 通常のユーザのアクセス (Blue環境)
27. 理想とするBlueGreenデプロイメント.2 27 一般ユーザのアクセスを Greenに移行
28. 実現したい要件 • 前提 ◦ stable環境 = ユーザの目に触れる環境 ◦ preview環境 = 動作確認で使う運営限定環境 28
29. 実現したい要件 • 前提 ◦ stable環境 = ユーザの目に触れる環境 ◦ preview環境 • リリース対象マイクロサービスだけ、preview環境を適用できるように • preview環境への接続は、可能な限り少ない手間で • previewとstableの切り替えも同様、単純な手順で • 事故が起きた時はすぐロールバックできるように 29
30. [構想編]どのような 構成でBlueGreen デプロイを実現するか • デプロイメント部分 • トラフィック制御部分 30
31. デプロイメント部分 • 役割 ◦ preview環境へのデプロイ ◦ previewとstable環境の切り替え • 今回は Argo Rollouts を採用 ◦ ArgoCDとの親和性が高い ◦ Web UI上でArgo Rolloutsの操作ができる 31
32. Argo Rollouts とは • BlueGreenデプロイやカナリアリリースなどのプログレッシブデプロイをサポート している、Kubernetesのカスタムコントローラ • 何ができるの？ ◦ k8sのDeploymentの仕組みを拡張してプログレッシブデプロイが行える ◦ Deploymentの代替として動かすものです。 32
33. トラフィック制御部分 • 役割 ◦ 特定のリクエストヘッダなどに応じて、任意の環境へ接続先を振り分けるルータ • k8sの場合、Istioを使うことが多い • Google Kubernetes Engineでホストしているので、GCPが提供しているマ ネージドサービスメッシュであるAnthos Service Meshを採用 ◦ 内部でIstioを利用 33
34. Kubernetes Service Istioとは • Istioは、マイクロサービス同士の通信を一元管理・監視するためのツール ◦ いわゆるサービスメッシュ ◦ 各Podにプロキシコンテナ • マイクロサービスの通信ルートやポリシーを制御 ◦ 例えばBlueGreenのトラフィック制御にも使える 34 Service A Pod Service B Pod Istioプロキシ Istioプロキシ Istio コントロールプレーン Cloud Load Balancing 内部通信
35. どのように実装したか 35
36. Anthos Service Meshをインストール • GCPのガイドに従い、GKEクラスタにAnthos Service Meshをインストール ◦ 以降の細かい手順は割愛 36 参照 https://cloud.google.com/service-mesh/docs/unified-install/install-anthos-service-mesh?hl=ja#install_anthos_service_mesh
37. Istio IngressGatewayをインストール 37 • IngressGatewayの役割 ◦ 外部からのトラフィックを LB経由で受付 ◦ VirtualServiceのルーティング設定をもとに送信先の Serviceなどを決定 ◦ 主にL7(HTTPなど)でルーティング
38. Istio IngressGatewayをインストール • セットアップについて ◦ GCPの公式Docsに沿って、専用のnamespaceにBackendConfigやIngress一式を反映 ◦ namespace作成時、istio-injection=enabledで作成することで、各サービスのPod作成時に サイドカーコンテナ(プロキシ)が自動で注入される。 38
39. preview環境作成の下準備 1. DeploymentをArgo Rolloutsに置き換える a. まずは一つのマイクロサービスに導入 39
40. 1. 2. HorizontalPodAutoscalerの対象ワークロードを切り替え a. 先ほど作成したRolloutに書き換えます preview環境作成の下準備 40
41. preview環境の作成 Anthos Service Mesh関連リソース一式を作成 1. Preview環境用のServiceを作成 a. 実態はKubernetesのService 41
42. preview環境の作成 1. 2. VirtualService a. Istio の機能 b. Header-basedルーティングで 42 トラフィック制御を行う
43. previewとstableの切り替え Argo Rollouts標準のダッシュボードを導入してGUIでできるようにしました 43
44. トラフィック制御の実装 • サーバ側 ◦ Gatewayサーバから内部のサーバにリクエストする際、クライアントのリクエストヘッダを継承す るようにしました。 ▪ 内部サービス間の通信でも継承 44
45. トラフィック制御の実装 • アプリ側 ◦ 社内専用アプリで、BlueGreenデプロイメント用のリク エストヘッダを自由に on/offできる仕組みを作りました 45
46. BlueGreenデプロイメントアーキテクチャ 46 2. 内部のユーザのみがアクセス可能 (最終的にこちらがstableになる) 1. 通常のユーザのアクセス
47. 5. 導入の工夫と苦労話 47
48. [導入時の工夫] Kubernetesマニフェスト • 多数のマイクロサービスがあるため、共通して参照できるようにkustomizeの componentとしてワークロード一式を定義しました • 利用する際は、それをインポートしてサービス特有のlocal-configを少し書き換 えるだけで済むように 48
49. 49 共通設定をインポート
50. [苦労話1] ヘッダの引き継ぎが大変でした • Go言語で対応 • リクエストでトラフィック制御用のヘッダを受け取り、その値によって参照する環境 (preview or stable)を切り替えていた • 内部のサーバ間通信の際も、クライアントから受け取ったトラフィック制御用ヘッダ を流用。 50
51. 実装当初起きた問題点 • リクエスト途中でクライアントの接続が切れた際、処理中の内部リクエストが全て中断 されてしまった。 ◦ 高頻度で発生した ◦ 本来はこれで正しい ↓どんな問題が起こる？ • Write系の処理で不整合が起こる可能性がある ◦ つまりクライアントがリクエスト途中で切断しても、裏側の処理は atomicに完了してほしい 51
52. なぜこの問題が起きていたのか 52
53. 当初はこのように実装.1 Requestが来るたびにhttp.Request.Context経由でcontextを生成 ※つまりrequest scopeなContext 53
54. 当初の実装.2 別サーバにリクエストするとき、自前のhttp.RoundTripper内で1.のcontextからトラ フィック制御ヘッダをrequest headerの設定 ※middlewareのようなイメージ 54
55. 当初の実装.3 2.をcontext.WithTimeout(1のctx, {時間})でラップしてリクエスト。 55
56. context canceledが起きていた原因 1. 内部サービスへのリクエストはcontext.Contextを継承した context.WithTimeoutで行っていた 2. context.WithTimeoutは親のcontextを継承してしまう 3. http.Request.Contextがキャンセルされると、その子のcontext.WithTimeout を使ったリクエストもキャンセルされてしまう。 　　＝context canceledの伝播 ※Istio導入前は、context.Background()でグローバルコンテキストを使っていた。こ の場合はcancelが発生しないので今まで問題はなかった。 56
57. context.Backgroundを元にすることで解決 • なぜこれで解決するのか ◦ context.WithTimeoutは、受け取ったcontextを継承する ◦ context.Background()はcancelが発生しないので、Background()を元にcontextを生 成すればOK 57
58. 最終的なコードの要約 58 1. Requestが来るたびにcontext.Background経由で、トラフィック制御用の 値を持ったrequest scopedなcontextを生成。 2. 別サーバへのリクエスト時、http.RoundTripper内で1.のcontextからトラ フィック制御ヘッダを取得し、request headerに設定
59. [苦労話2] Anthos Service Mesh(ASM)のログが爆発 • 既存のリクエストログに加え、ASMのリクエストログも吐き出されており、ログデー タ量が2倍になったことでログ料金が増えた • Cloud Loggingログルータの設定で、ASMのログをGCPに取り込まないように することで解決 59
60. 6. BlueGreenデプロイメントの 導入により得られた効果 60
61. 今までメンテナンスに依存していた 作業が、メンテナンス不要で できるように 61 この成果により、
62. メンテナンス回数が激減した 62
63. メンテナンス回数が激減した 63 ※0回になってない理由は後述
64. リリーススケジュールが柔軟に • メンテナンスを待つ必要がなくなった • メンテナンスを待たずして、任意のタイミングで以前より高速でリリースできるよう に 64
65. 事故の予防がしやすくなった • ユーザ影響のない環境(preview)が生まれたことにより、「preview環境で不具 合が起きたらリリースを中止する」という新たな選択肢が生まれた 65
66. 既存のリリースの課題の大部分を改善する ことができました 66
67. 7. 残された課題もあります 67
68. 残された課題点もいくつかあります • CloudSQLのアップグレードやスペック調整のタイミングでメンテナンスが必要に なる • 外部APIとの連携はpreview環境と疎通できない場合がある ◦ 例えばSNSログインや、グリーグループ共通の認証基盤など ◦ 後者は調整可能ではある 68
69. まとめ • 正攻法(サービスメッシュの導入)により大きな成果を得ることができた ◦ REALITY流の工夫はありつつ、ユーザ & ビジネス双方で。 ◦ できるだけ難しいことをしない。まずは凡事徹底。 • BlueGreen以外にも応用できるものが生まれた ◦ カナリアリリースなど ◦ 開発体験向上にも流用する予定 69