Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

gree_tech
October 13, 2023

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

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

gree_tech

October 13, 2023
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. 9

  2. 1. 機能のリリース a. 中程度以上の機能はメンテナンス中にリリースすることが多い 2. インフラリソース調整 a. Google Kubernetes Engineクラスタのアップグレード

    b. CloudSQLのメンテナンスウィンドウなど 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 12 メンテナンス中に何をしている?
  3. 1. 機能のリリース a. 中程度以上の機能はメンテナンスにリリースすることが多い 2. インフラリソース調整 a. CloudSQLのメンテナンスウィンドウなど b. Google

    Kubernetes Engineクラスタのアップグレード i. サージアップグレード (同時更新台数)設定で、無停止更新も可能ではある 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 13 メンテナンス中に何をしている?
  4. 1. 機能のリリース a. 中程度以上の機能はメンテナンスにリリースすることが多い 2. インフラリソース調整 a. CloudSQLのメンテナンスウィンドウなど b. Google

    Kubernetes Engineクラスタのアップグレード 3. 運用系 a. 新規ガチャやワールドのリリース &動作確認 14 メンテナンス中に何をしている?
  5. • ユーザ視点 ◦ 1時間の間、全ての機能を利用できなくなる ◦ アプリ利用中の場合は全ての操作が強制終了し、メンテナンス画面に飛ばされる • 運営側視点 ◦ 1時間ユーザがいなくなることによる売上の損失

    ◦ ユーザへのお知らせやチーム間の連携コストなど ◦ 前日のメンテナンス作戦会議やメンテナンス直前の準備 MTGなど、シンプルに準備の時間がかかる 15 メンテナンスをすると何が起こるか
  6. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかった ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない •

    A2. マイクロサービス間の生合成担保のため ◦ 複数マイクロサービスを同時にリリースすることができない ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 17
  7. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかったから ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない •

    A2. マイクロサービス間の整合性担保のため ◦ 複数マイクロサービスを同時にリリースする仕組みがない。 ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 18
  8. Q. なぜメンテナンスが必要だったか • A1. メンテナンス中にしか新機能の動作確認ができなかったから ◦ 一部は開発者限定の動作確認モードを使えることができる ◦ 全ての機能に限定公開モードを実装するのは現実的ではない •

    A2. マイクロサービス間の生合成担保のため ◦ 複数マイクロサービスを同時にリリースすることができない ◦ 片方だけ先に出ると壊れてしまうような変更はメンテナンスでリリース • A3. インフラリソースの更新で必要 ◦ GKEクラスタのアップグレード ◦ DBのアップグレードなど 19
  9. 実現したい要件 • 前提 ◦ stable環境 = ユーザの目に触れる環境 ◦ preview環境 •

    リリース対象マイクロサービスだけ、preview環境を適用できるように • preview環境への接続は、可能な限り少ない手間で • previewとstableの切り替えも同様、単純な手順で • 事故が起きた時はすぐロールバックできるように 29
  10. デプロイメント部分 • 役割 ◦ preview環境へのデプロイ ◦ previewとstable環境の切り替え • 今回は Argo

    Rollouts を採用 ◦ ArgoCDとの親和性が高い ◦ Web UI上でArgo Rolloutsの操作ができる 31
  11. トラフィック制御部分 • 役割 ◦ 特定のリクエストヘッダなどに応じて、任意の環境へ接続先を振り分けるルータ • k8sの場合、Istioを使うことが多い • Google Kubernetes

    Engineでホストしているので、GCPが提供しているマ ネージドサービスメッシュであるAnthos Service Meshを採用 ◦ 内部でIstioを利用 33
  12. Kubernetes Service Istioとは • Istioは、マイクロサービス同士の通信を一元管理・監視するためのツール ◦ いわゆるサービスメッシュ ◦ 各Podにプロキシコンテナ •

    マイクロサービスの通信ルートやポリシーを制御 ◦ 例えばBlueGreenのトラフィック制御にも使える 34 Service A Pod Service B Pod Istioプロキシ Istioプロキシ Istio コントロールプレーン Cloud Load Balancing 内部通信
  13. 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
  14. 実装当初起きた問題点 • リクエスト途中でクライアントの接続が切れた際、処理中の内部リクエストが全て中断 されてしまった。 ◦ 高頻度で発生した ◦ 本来はこれで正しい ↓どんな問題が起こる? •

    Write系の処理で不整合が起こる可能性がある ◦ つまりクライアントがリクエスト途中で切断しても、裏側の処理は atomicに完了してほしい 51
  15. 70