デプロイ・テスト戦略を整理する

# はじめに
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/