アプリケーションのデプロイとテスト戦略の種類
はじめに
Google CloudのProfessional Cloud Developerの取得に向けて勉強中です。
アプリケーションのデプロイ・テスト戦略手法についてまとめます。
Cloudアーキテクチャセンターの以下の記事を参考にしています。
デプロイ戦略
再作成
デプロイの再作成では、新規のアプリケーションのバージョンをデプロイする際に、既存のアプリケーションのバージョンを完全にダウンさせてから、新規のアプリケーションのバージョンをデプロイします。
インプレースアップデートとも呼ばれます。
- メリット
- シンプルなデプロイ手法
- 複数のアプリケーションのバージョンを管理する必要がないため、データやアプリケーションの下位互換性の問題を回避することができる
- デプロイ時間が短い
- デメリット
- ダウンタイムが必ず発生する
- ミッションクリティカルなシステムの場合はSLAを満たすことができないので別のデプロイ手法を検討する必要がある。
ローリングアップデート
ローリングアップデートは、アプリケーションを同時に更新するのではなく、実行中のアプリケーションのサブセットを更新し段階的にデプロイします。
KubernetesのDeploymentによるPodのデプロイはローリングアップデートが使用されています。
- メリット
- ダウンタイムがない
- 指定したウィンドウサイズに応じてアプリケーションを段階的にデプロイします。新規のアプリケーションがトラフィックを受け入れる準備ができてからトラフィックを転送します。
- 影響を受けるユーザが少ない
- 新規のアプリケーションに対して徐々にトラフィックが転送されるため、新規のアプリケーションにバグがあった場合、一部のユーザにしか影響しません。
- ロールバックが可能
- 新規のアプリケーションに不具合があった場合は、既存のアプリケーションにロールバックすることができる。
- ダウンタイムがない
- デメリット
- デプロイに時間がかかる
- 新規のアプリケーションを段階的にデプロイしていくため、デプロイにかかる時間が長くなってしまう。また、デプロイ時に問題があった場合もロールバックに時間がかかる。
- 下位互換性が必要
- ローリングアップデート中に新しいバージョンと古いバージョンが混在してしまうため、ユーザがアクセスした際にランダムでどちらかのバージョンにリクエストされます。その際に、互換性がない場合は、サービス障害が発生してしまいます。
- デプロイに時間がかかる
Blue/Greenデプロイ
Blue/Greenデプロイは、新規のアプリケーションをデプロイする新環境（Green環境）を作成し、新環境に新規のアプリケーションをデプロイします。そのあと、ロードバランサのトラフィックを既存のアプリケーションがデプロイされている旧環境（Blue環境）から新環境（Green環境）に切り替えます。
デプロイの成功した後は、旧環境（Blue環境）を削除したり、または保持することもできます。デプロイの失敗した場合は、旧環境（Blue環境）に切り戻したりすることもできます。
- メリット
- ダウンタイムがない
- ユーザトラフィックを一気に切り替えるため、ダウンタイム無しでデプロイできます。
- 即時ロールバックが可能
- 新規のアプリケーションに不具合があった場合は、ロードバランサを調整することで一気に既存のアプリケーションにロールバックすることができる。
- 環境の分離
- 既存のアプリケーション環境と新規のアプリケーション環境が分離されるため、デプロイ時のリスクが軽減されます。
- ダウンタイムがない
- デメリット
- コストがかかる
- Blue/Greenデプロイは、旧環境（Blue環境）同じ構成の新環境（Green環境）が必要になるため、運用上のオーバヘッドとコストがかかってしまいます。
- 下位互換性が必要
- 旧環境と新環境において下位互換性がない場合、共通に利用するデータに不可逆な変更を与えてしまう可能性があります。その場合、旧環境への切り戻しが不可能になる可能性があります。
- コストがかかる
テスト戦略
カナリアテスト
カナリアテストは、新しいバージョンをある一部の特定ユーザーにのみ公開し、本番環境でのテストを行ってから全体に展開する手法です。Blue/Greenとは、異なり実際にユーザーが本番環境で使用できるという点があります。
特定のユーザーの選定についてはロードバランサやプロキシ単位、アプリケーション上の設定やユーザーの地理情報といった情報をもとにコントロールすることが可能です。
- メリット
- 本番環境のトラフィックでテストが可能
- テスト用のトラフィックではなく、実際の本番トラフィックでテストが行える。
- 即時ロールバックが可能
- 新規のアプリケーションに不具合があった場合は、トラフィックの割合を既存のアプリケーションにすることでロールバックすることができる。
- 本番環境のトラフィックでテストが可能
- デメリット
- ロールアウトが遅い
- リリース中に徐々に各段階でモニタリングが必要なるため、全体としてのリリースに時間がかかってしまいます。
- 下位互換性が必要
- ローリングアップデートと同様に、複数のバージョンのアプリケーションが環境内で実行されるため下位互換性とセッションの永続性にリスクがあります。
- ロールアウトが遅い
A/Bテスト
A/Bテストは、アプリケーションが旧バージョン（A）と新バージョン（B）でどちらがビジネス上効果があるのか検証するテスト手法です。デザインや広告などマーケティングで主に利用されます。位置情報やユーザーエージェントなどの情報に基づいてトラフィックをルーティングします。
- メリット
- データに基づいた意思決定が可能になる。
- A/Bテストツール等を用いることによって統計データからどちらがビジネス上優位か判断してより良い結果のバージョンを本番環境に展開します。
- データに基づいた意思決定が可能になる。
- デメリット
- テストにかかる時間とコストが多い
- A/Bテストを実施するには、十分な量のトラフィックを集める必要があり分析にかかる時間も多くなってしまいます。
- テストにかかる時間とコストが多い
シャドーテスト
シャドーテストは、本番トラフィックをミラーリングしてテスト環境で再現されます。
- メリット
- 本番環境への影響がない
- トラフィックは複製されているため、シャドーデータを処理しているサービスで発生するバグは本番環境には影響しません。
- 本番環境の負荷を利用したテストが可能
- Twitter社（現X）が公開しているリグレッションテストツールのOSSであるDiffyを利用することで、本番環境のトラフィックに対するサービスの動作を測定できます。
- 本番環境への影響がない
- デメリット
- コストと運用オーバヘッドがかかる
- シャドーテストでは、Blue/Greenデプロイと同様に、旧環境と新環境が必要になるため、運用上のオーバヘッドとコストがかかってしまいます。
- サードパーティ製ツールとの連携時に不具合を起こす可能性がある
- ショッピングカートプラットフォームの支払いサービスに対してシャドーテストすると、トラフィックを複製しているため、注文に対して2回の支払いを行うことになる可能性があります。
- コストと運用オーバヘッドがかかる
まとめ
今回は、アプリケーションのデプロイ・テスト戦略手法について整理しました。
どのデプロイ・テスト手法を選択するかはシステム要件やSLAをもとに検討いただければと思います。
参考
Discussion