192-AWS SAP AWS 「理論・実践・一問道場」

type

status

date

slug

summary

理論

1. 段階的なデプロイメントとカナリアリリース

新しいアプリケーションのバージョンを展開する際、カナリアリリース（canary release）戦略を使用して、最初に一部のユーザーに新しいバージョンを提供し、その後のフィードバックを基にリリースを進める方法が有効です。この戦略により、リリース後の問題を早期に検出し、全ユーザーへの展開を進める前に修正することができます。

AWSでは、次のような方法を使って段階的なデプロイメントを実現できます：

ターゲットグループの重み付け: ALB（Application Load Balancer）でターゲットグループを重み付けして、新しいバージョンのアプリケーションに一定の割合（例：10%）のトラフィックを分配します。この方法により、テストウィンドウ中のユーザーにのみ新しいロジックを提供できます。

ALBのターゲットグループスティッキネス: スティッキネスを設定することで、顧客はテスト期間中に同じバージョンのアプリケーションを使い続けることが保証されます。セッションごとに特定のターゲットにトラフィックを送るため、一貫した体験が提供されます。

2. AWSのターゲットグループとALBの利用

ALBでは、複数のターゲットグループにトラフィックを分配することができます。この仕組みを活用して、異なるバージョンのアプリケーションを異なるターゲットグループにデプロイし、トラフィックを重み付けで分割することが可能です。

ターゲットグループの管理: ALBのリスナーでターゲットグループに基づくルーティングを設定することで、トラフィックを特定のインスタンス群に分配できます。

ルールの設定: ALBリスナーで、特定の条件（HTTPステータスコード、パスベースルーティングなど）に基づいて、ターゲットグループを動的に切り替えることもできます。

3. Route 53とWeighted Routing

Amazon Route 53の重み付けルーティングを使用すると、トラフィックの配分を細かく管理できます。例えば、特定のドメイン（api.example.com）に対して、トラフィックを10%ずつ分けて、新しいバージョンのアプリケーションに切り替えることが可能です。

Weighted Routing Policy: これにより、特定のエンドポイントにトラフィックを動的に振り分け、徐々に新しいロジックに切り替えることができます。

4. ローリングアップデート

Auto Scalingグループのローリングアップデート機能を使用して、EC2インスタンスの更新を段階的に行うことも可能です。これにより、アプリケーションの更新が全インスタンスに一度に適用されることを避け、負荷を軽減しながら新しいバージョンを展開できます。

MaxBatchSizeを設定することで、一度に更新されるインスタンス数を制御し、段階的にリリースを進めることができます。

5. セッションの一貫性

新しいバージョンに移行する際、ユーザーのセッションが中断されることなく、同じバージョンを使用し続けられるようにするために、セッションスティッキネスを活用することが重要です。これにより、同じユーザーは常に同じバックエンドインスタンスにリダイレクトされ、セッション状態を維持できます。

結論

この問題に関連する本質的な知識は、AWSのALB（Application Load Balancer）やRoute 53を活用して、段階的なデプロイメントやトラフィックの分割、セッション管理を行う方法です。AWSのこれらのツールをうまく組み合わせることで、リスクを最小化し、柔軟でスケーラブルな更新を実現できます。

実践

略

一問道場

質問 #192

トピック 1

ある会社はAWSクラウドでアプリケーションを実行しています。コアビジネスロジックは、Auto Scalingグループ内の一連のAmazon EC2インスタンスで実行されています。Application Load Balancer（ALB）がEC2インスタンスにトラフィックを分配しています。Amazon Route 53のレコード「api.example.com」はALBを指しています。会社の開発チームはビジネスロジックの主要な更新を行います。会社には、変更がデプロイされる際、テストウィンドウ中に新しいロジックを受け取るのは顧客の10%のみとするというルールがあります。また、テストウィンドウ中、顧客は同じバージョンのビジネスロジックを使用し続ける必要があります。この要件を満たすように更新をどのようにデプロイすべきですか？

A. 2番目のALBを作成し、新しいロジックを新しいAuto Scalingグループ内のEC2インスタンスにデプロイします。ALBがEC2インスタンスにトラフィックを分配するように設定します。Route 53のレコードを更新して、重み付けルーティングを使用し、2つのALBの両方を指すようにします。

B. 2番目のターゲットグループを作成し、そのターゲットグループをALBで参照します。この新しいターゲットグループに新しいロジックをデプロイします。ALBリスナーのルールを更新して、重み付けターゲットグループを使用するようにし、ALBターゲットグループのスティッキネスを設定します。

C. Auto Scalingグループのために新しいローンチ設定を作成します。ローンチ設定を使用してAuto Scalingのローリングアップデートポリシーを指定し、MaxBatchSizeオプションを10に設定します。ローンチ設定をAuto Scalingグループに置き換え、変更をデプロイします。

D. 2番目のAuto Scalingグループを作成し、ALBで参照します。この新しいAuto Scalingグループに新しいロジックをデプロイします。ALBのルーティングアルゴリズムを最小の未処理リクエスト（LOR）に変更します。ALBのセッションスティッキネスを設定します。

解説

この質問では、アプリケーションの更新を段階的に、かつ特定のルールに従って配信する方法を問うています。要件は、顧客がテストウィンドウ中に一貫して同じバージョンのビジネスロジックを使用し、10%の顧客にのみ新しいロジックが配信されるようにすることです。各選択肢の解説を行います。

A. 2番目のALBを作成して重み付けルーティングを使用

2番目のALBを作成し、新しいロジックを新しいAuto Scalingグループにデプロイする方法です。このALBにトラフィックを分配させ、Route 53の重み付けルーティングを使って、新しいALBと既存のALBの間で10%/90%のトラフィック配分を実現するという方法です。

メリット: 重み付けルーティングによって、顧客の10%に新しいロジックを配信することができます。また、ALBがトラフィックを処理するため、スケーラビリティと可用性も確保できます。

デメリット: 2つのALBを管理する必要があるため、運用のオーバーヘッドが増えます。

B. 2番目のターゲットグループとスティッキネス

2番目のターゲットグループを作成し、新しいロジックをそのターゲットグループにデプロイします。その後、ALBリスナーのルールを設定して、重み付けターゲットグループを使用し、スティッキネスを設定します。

メリット: ALBを1つだけ使用し、ターゲットグループを分けて、テスト中のトラフィックを10%に制限できます。スティッキネスを設定することで、顧客が同じバージョンを使い続けることが保証されます。

デメリット: ALBリスナーの設定とターゲットグループの管理が必要ですが、ALB自体は1つで済むため、Aよりは簡便です。

C. Auto Scalingのローリングアップデートポリシー

Auto Scalingのローリングアップデートポリシーを使用して、新しいロジックを段階的にデプロイします。MaxBatchSizeを10に設定し、更新を10%ずつ進めます。

メリット: EC2インスタンスの更新を段階的に行うため、ダウンタイムを最小限に抑えることができます。

デメリット: ただし、この方法では、顧客に特定のバージョンを保証することが難しく、テストウィンドウ中に同じバージョンのロジックを使い続ける保証がありません。

D. 最小の未処理リクエスト（LOR）とセッションスティッキネス

*最小の未処理リクエスト（LOR）**を使用してトラフィックを分配します。この方法では、ALBが現在処理中のリクエスト数が少ないインスタンスに新しいリクエストを割り当てます。セッションスティッキネスを使用することで、顧客は同じインスタンスで処理され続けます。

メリット: スケーラビリティとセッションの一貫性を確保できます。

デメリット: 10%の顧客に新しいロジックを提供するという要件を確実に満たすためには、より細かい制御が必要です。LORとセッションスティッキネスだけでは、目標通りにトラフィックを分けることは難しいです。

正解

Bが最も適切な選択肢です。

重み付けターゲットグループとスティッキネスを利用することで、顧客がテスト中に一貫して同じバージョンを使用できることを保証し、10%の顧客に新しいロジックを配信する要件を満たすことができます。また、ALBを1つだけ使用するため、運用負荷も最小限に抑えることができます。