アプリのデプロイパターンの選定ポイント

Posted at 2024-11-11

AWS CodeDeployには、LambdaやECSなどのデプロイに使用できるさまざまなデプロイ方法があります。

それぞれのデプロイ方式の使い分けを調べてみました～

All-at-once (一斉デプロイ)

新しいバージョンがすべてのユーザーに即時適用されます。

デプロイが高速で、シンプルです。
環境が少数であればデプロイ管理が容易。

新しいバージョンにバグがある場合、全ユーザーに影響します。
ロールバックが発生すると、全ユーザーが影響を受けるため、慎重にリリースする必要があります。

開発環境やテスト環境などでのデプロイ。
サービス影響が小さいバグ修正。
システムが単純で、障害に強いアーキテクチャの場合。

現行バージョン (Blue) を保持しつつ、別の環境に新バージョン (Green) をデプロイします。新バージョンの検証後に切り替え、問題があれば簡単に旧バージョンに戻せます。

現行環境を維持したまま新しいバージョンをテストでき、問題が発生した場合にすぐロールバック可能です。
低リスクでの切り替えができ、サービスダウンタイムが少ないです。

リソースコストが増加しやすい（別環境の準備が必要）。
切り替えのオーバーヘッドが増加する場合がある。

ミッションクリティカルなアプリケーション。
ダウンタイムを最小限に抑えたいプロダクション環境。
大きなアップデートやリリースの前に慎重な検証が必要な場合。

新バージョンを一部の「ユーザー」にだけ公開し、段階的に全ユーザーに適用していく方式です。設定した割合でデプロイの進行を管理できます。

問題が発生した場合、影響を最小限に抑えられるため、バグ検出が容易。
ロールバックが迅速で、影響範囲を小さく抑えられます。

デプロイに時間がかかる場合がある。
ユーザーが異なるバージョンのアプリケーションを使用するため、一貫性に注意が必要。

新機能やバージョンを慎重にリリースしたい場合。
一部のユーザーでのフィードバックを得ながらリリースを進めたい場合。
バグや不具合の早期発見を重要視するプロダクション環境。

新しいバージョンを一定の「割合(リソース)」で段階的に公開していく方式。
設定した時間間隔で徐々にデプロイが進みます。

安定的かつ計画的に全ユーザーへのデプロイを行うことが可能です。
Canary デプロイと同様に、途中で異常が発生すれば中止・ロールバックが可能です。

デプロイ完了までに時間がかかります。
中途での切り戻しが必要になった場合に時間がかかります。

サービス全体に影響を与える可能性のある機能変更。
大規模なユーザーを持つアプリケーションで、慎重にデプロイしたい場合。
アップデートの信頼性を重視するプロダクション環境。