はじめに
GoogleCloudの Professional Cloud Developer、Professional Cloud Architect の試験対策をしていると、デプロイ・テスト戦略についての知識が問われる事が多かった為、整理しておこうと思います。
デプロイ戦略
①インプレースデプロイ
既存の環境に対して新しいバージョンを上書きしてリリースする手法。
新規のアプリケーションのバージョンをデプロイする際には、既存のアプリケーションのバージョンを完全にダウンさせてから、新規のアプリケーションのバージョンをデプロイします。
【メリット】
- シンプルなデプロイ手法
- 複数のアプリケーションのバージョンを管理する必要がないため、データやアプリケーションの下位互換性の問題を回避することができる
- 低コスト
- デプロイ時間が短い
【デメリット】
- ダウンタイムが発生する
- 新しいバージョンに不具合が見つかった場合のロールバックが大変
- 大規模なリリースには向いていない
②Blue/Greenデプロイ
稼働中環境（Blue環境）とは別に新環境（Green環境）を用意し、新環境に対して新バージョンをデプロイする方法です。
動作確認が問題なければ、稼働中サーバー（Blue環境）を切り離して、新環境（Green環境）に接続して新バージョンを公開します。
【メリット】
- ユーザトラフィックを一気に切り替えるため、ダウンタイム無しでデプロイできる
- 新規バージョンに不具合があった場合は、旧バージョンにロールバックすることができる
- 既存環境と新環境が分離されるため、デプロイ時のリスクが軽減される
【デメリット】
- 旧環境と新環境が必要になるため、高コストであり運用上のオーバヘッドがかかる
- 下位互換性が必要となる
旧環境と新環境において下位互換性がない場合、共通に利用するデータに不可逆な変更を与えてしまう可能性があり、その場合、旧環境への切り戻しが不可能になる可能性がある
データベースの扱いが難易度高い
③イミュータブルデプロイ
Blue/Greenデプロイと同じく既存環境と新環境、２つの環境を用意しますが、新環境へと切り替えが済んだ際には既存環境は削除します。
【メリット】
- 古い環境を運用し続けるコストがかからない
【デメリット】
- ロールバックする場合は再度旧バージョンをデプロイする必要がある
すぐに元には戻せない
④カナリアリリース（カナリーデプロイ）
Blue/Greenデプロイと同じく既存環境と新環境、２つの環境を用意し、新しいバージョンを一部の特定ユーザーのみルーティングし公開することで、様子見をしながら徐々に全体に展開する手法。
リリースに関わるトラブルのリスク軽減が目的です。
特定のユーザーの選定についてはロードバランサやプロキシ単位、アプリケーション上の設定やユーザーの使用地域といった情報をもとにコントロールすることも可能です。
Google と Netflix によって共同開発されたオープンソースとして、カナリアリリース分析ツール「Kayenta」があります。
【メリット】
- ダウンタイムが無い
- 本番環境でのテストが可能
- リスクを最小限に抑えながら早期のエラー発見
- 旧バージョンも動いているためロールバックがすぐに可能
【デメリット】
- 新バージョンの完全な公開までに時間がかかる
- 新旧バージョンの管理や公開範囲の管理が必要となり、運用コストが高い
- 下位互換性が必要となる
⑤ローリングアップデート
サーバーを一つずつ順番に切り離して、段階的に順次デプロイを実施していく方法です。
KubernetesのDeploymentによるPodのデプロイはローリングアップデートが使用されています。
【メリット】
- ダウンタイム無し
- 新規のアプリケーションにバグがあった場合、一部のユーザにしか影響がない
- 旧バージョンも動いているためロールバックがしやすい
【デメリット】
- 新旧バージョンが混在するため、バージョン管理のコストが高くなる
- ユーザがどちらのバージョンにもアクセスする可能性があり、新旧バージョンでの下位互換性が必要
- デプロイに時間がかかる
- デプロイ時に問題があった場合ロールバックに時間がかかる
⑥シンボリックリンクデプロイ
Blue/Greenデプロイやイミュータブルデプロイとは異なり、1つのサーバーのみを使用します。
サーバー環境は1つですが、その中に既存環境と新規環境の仮想環境を2つ作るデプロイ手法です。
デプロイが一通り完了した後に、「Symbolic link」により、環境を新規環境へ移行します。
【メリット】
- リソースが少なく済み、運用コストが削減できる
- デプロイ作業の自動化が容易に行える
【デメリット】
- サーバーの再起動が必要な場合があり、場合によってはダウンタイムが発生する
- 稼働中のサーバに対して作業を行うため、作業のミスにより複数のシステムへの影響が生じる可能性あり
テスト戦略
①A/Bテスト
同時に複数バージョンを公開し、結果を基に最も効果的なバージョンを選択するテスト方法です。
デザインや広告などマーケティングで主に利用されます。
位置情報やユーザーエージェントなどの情報に基づいてトラフィックをルーティングします。
カナリアリリースとの違いは、A/Bテストは「どのバージョンがユーザーに最も良い反応を示すか」を比較するのに対し、カナリアリリースは「新バージョンに問題がないか」を検証する手法です。
つまり、カナリアリリースとA/Bテストは補完的な関係にあり、同時に使用することで効果的なアプリケーション改善が可能となります。
【メリット】
- 運用がしやすい
複数パターンを作成し、それらを比較して、どちらがより高いエンゲージメント率やCVRを出すのかを容易に確認できる - コストがかかりづらい
Webページなどの現状を一部変更して実施できるので、他の施策と比べてコストが低いと言えます
【デメリット】
- 検証に時間がかかる
ある程度のサンプル数がないとデータの正確性を確保できない - 有益な結果が得られない可能性がある
仮説の内容によっては誤った方向へサイトを運営してまう
②シャドーテスト（シャドウトラフィックテスト/シャドーイング）
本番トラフィックを検証環境へミラーリング(分割 or 転送)することで、負荷テスト・リグレッションテストを実施できる。
A/Bテストをシステムテスト特化したものと考えれば良い。
【メリット】
- 本番環境への影響がない
- 本番環境の負荷を利用したテストが可能
【デメリット】
- コストと運用オーバヘッドがかかる
Blue/Greenデプロイと同様に、旧環境と新環境が必要になるため、運用上のオーバヘッドとコストがかかる - サードパーティ製ツールとの連携時に不具合を起こす可能性がある
ショッピングカートプラットフォームの支払いサービスに対してシャドーテストすると、トラフィックを複製しているため、注文に対して2回の支払いを行うことになる可能性がある
最後に
最後まで読んで頂きありがとうございます。
無事に、 Professional Cloud Developer、Professional Cloud Architect の２つの試験に合格する事ができました。
参考
https://sreake.com/blog/release-engineer/
https://zenn.dev/hi_ka_ru/articles/deploy-test-pattern-20240513
https://www.softbank.jp/biz/blog/cloud-technology/articles/202303/deployment/