Amazon Web Services ブログ
新機能 – 加重ターゲットグループの使用によって Application Load Balancer がデプロイメントをシンプルに
クラウドコンピューティングのメリットのひとつは、インフラストラクチャをプログラム的に作成し、必要なくなったら破棄する可能性です。これは、アプリケーションをデプロイする方法を、開発者が根本的に変えることを可能にします。オンプレミスでアプリケーションをデプロイしていた頃、開発者はアプリケーションの新しいバージョンのために既存のインフラストラクチャを再利用しなければなりませんでした。クラウドでは、開発者がアプリケーションの新しいバージョンのために新しいインフラストラクチャを作成し、古いバージョンを破棄する前にしばらく並行して実行させておきます。この手法はブルー/グリーンデプロイメントと呼ばれます。これは、アプリケーションの 2 つのバージョン間のトラフィックを漸進的に切り替え、新しいバージョンでのビジネスメトリクスと運用メトリクスを監視して、問題が発生した場合にはトラフィックを前のバージョンに戻すことを可能にします。
ブルー/グリーンデプロイメントを導入するために、AWS のお客様は 2 つの戦略を導入します。最初の戦略は 2 番目のアプリケーションスタックの作成で構成されており、これには 2 番目のロードバランサーが含まれます。開発者は、DNS などの何らかの加重ルーティング手法を使用して、トラフィックの一部を各スタックに送ります。2 つ目の戦略は、ロードバランサーの背後にあるインフラストラクチャの交換で構成されています。どちらの戦略も、クライアントマシン上の DNS TTL およびのキャッシングに応じてバージョン間でのトラフィックの移動に遅延を生じさせる場合があります。これらは、追加のロードバランサーを実行するための追加コストと、追加のロードバランサーをウォームアップするための遅延の可能性を生じ得ます。
ターゲットグループはロードバランサーに、トラフィックを EC2 インスタンス、固定 IP アドレス、または AWS Lambda 関数などのどこに送るかを指示します。ロードバランサーを作成する時は、1 つ、または複数のリスナーを作成し、1 つのターゲットグループにトラフィックを送るためのリスナールールを設定します。
本日、AWS は Application Load Balancer のための加重ターゲットグループを発表します。これは、開発者がアプリケーションの複数バージョンにトラフィックをどのように分散させるかを制御できるようにします。
複数の加重ターゲットグループ
複数のターゲットグループをリスナールールの forward アクションに追加し、各グループの重みを指定することができるようになりました。例えば、8 および 2 の重みを持つ 2 つのターゲットグループがあるルールを定義すると、ロードバランサーはトラフィックの 80% を最初のターゲットグループに、20% をもう一方のターゲットグループにルーティングします。
今すぐ加重ターゲットグループで実験するには、この CDK コードを使用できます。これは、EC2 インスタンスと、それらの前にある Elastic Load Balancer で 2 つの Auto Scaling グループを作成します。また、インスタンスにサンプルのウェブアプリケーションもデプロイします。ウェブアプリケーションのブルーバージョンはブルーインスタンスに、グリーンバージョンはグリーンインスタンスにデプロイされます。インフラストラクチャはこのようになります。
CDK プロジェクト を git clone
し、npm run build && cdk bootstrap && cdk deploy
と入力して上記のインフラストラクチャをデプロイできます。ロードバランサーの設定方法を示すため、CDK コードは Auto Scaling、ロードバランサー、および汎用ターゲットグループを作成します。手動で設定を終了して、アプリケーションの各バージョンに 1 つずつ、合計 2 つの加重ターゲットグループを作成しましょう。
まず、EC2 コンソールに移動して [ターゲットグループ] を選択し、[ターゲットグループの作成] ボタンをクリックします。green
という名前のターゲットグループを作成します。正しい Amazon Virtual Private Cloud を選択するようにしてください。これは名前が「AlbWtgStack...
」で始まる CDK スクリプトによって作成されたものです。次に [作成] をクリックします。
操作を繰り返して blue
ターゲットグループを作成します。私の [ターゲットグループ] コンソールはこのようになっています。
次に、blue
および green
の各ターゲットグループにポイントするように 2 つの Auto Scaling グループを変更します。AWS マネジメントコンソールで [Auto Scaling グループ] をクリックし、名前に注意しながら (「green」または「blue」のどちらかが含まれます) 2 つの Auto Scaling グループのいずれかを選択して、[操作]、[編集] とクリックします。
[詳細の編集] 画面で、CDK スクリプトによって作成されたターゲットグループを削除し、Auto Scaling グループの名前 (green
または blue
) に一致するターゲットを追加します。画面最下部の [保存] をクリックして、もう 1 つの Auto Scaling グループのために操作を繰り返します。
次に、リスナールールを変更して、それぞれが独自の重みを持つこれら 2 つのターゲットグループを追加します。EC2 コンソールで、左側にある [ロードバランサー] を選択し、CDK コードによって作成されたロードバランサーを検索します (名前は「alb」で始まります)。[リスナー]、[ルールの表示/編集] とクリックします。
CDK スクリプトによって作成されたルールが 1 つあります。最上部の [編集] アイコンをクリックしてから、もう一度ルールの左側にある [編集] アイコンをクリックしてこれを変更します。ゴミ箱アイコンをクリックして 転送先 ルールを削除します。
次に [+ アクションの追加] をクリックして 2 つの転送先ルールを追加します。これらにはそれぞれ 1 つのターゲットグループ (blue
と green
) があり、50 と 50 で重み付けされています。
最後に、右側の [更新] をクリックします。これで加重ロードバランシングをテストする準備が整いました。
ブラウザをロードバランサーの DNS 名にポイントします。ウェブアプリケーションのグリーンまたはブルーのバージョンのどちらかが表示されます。ブラウザでページを強制的に再ロードさせて、リクエストの 50% をグリーンアプリケーションに、50% をブルーアプリケーションに送信する動作中のロードバランサーを観察します。一部のブラウザでは、ページがキャッシュされ、定義した重みが反映されない場合があります。この練習では Firefox よりも Safari と Chrome が使いやすいでしょう。
ここで、AWS マネジメントコンソールで重みを 80 と 20 に変更し、ブラウザを更新し続けます。ブルーバージョンが平均で 10 回中 8 回表示されるのがわかります。
重みは、ALB ModifyListener API、AWS コマンドラインインターフェイス (CLI)、または AWS CloudFormation から調整することもできます。
例えば、AWS コマンドラインインターフェイス (CLI) はこのように使用します。
aws elbv2 modify-listener \
--listener-arn "<listener arn>" \
--default-actions \
'[{
"Type": "forward",
"Order": 1,
"ForwardConfig": {
"TargetGroups": [
{ "TargetGroupArn": "<target group 1 arn>",
"Weight": 80 },
{ "TargetGroupArn": "<target group 2 arn>",
"Weight": 20 }
]
}
}]'
または、この JSON extract で AWS CloudFormation を使用します。
"ListenerRule1": {
"Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
"Properties": {
"Actions": [{
"Type": "forward",
"ForwardConfig": {
"TargetGroups": [{
"TargetGroupArn": { "Ref": "TargetGroup1" },
"Weight": 1
}, {
"TargetGroupArn": { "Ref": "TargetGroup2" },
"Weight": 1
}]
}
}],
"Conditions": [{
"Field": "path-pattern",
"Values": ["foo"]
}],
"ListenerArn": { "Ref": "Listener" },
"Priority": 1
}
}
ロードバランサーを管理するために外部のサービスやツールを使用している場合は、Application Load Balancer で加重ルーティング設定をサポートするようにプロバイダーがその API を更新するまで待つ必要があるかもしれません。
その他の用途
ブルー/グリーンデプロイメントに加えて、AWS のお客様はクラウド移行、または異なる AWS コンピューティングリソース間の移行という 2 つの別のユースケースに加重ターゲットグループを使用することができます。
オンプレミスアプリケーションをクラウドに移行するときは、アプリケーションがオンプレミスのデータセンターとクラウドの両方で実行されている期間を作って、移行を漸進的に行うとよいでしょう。最終的に、クラウドバージョンが十分に機能することを確認したら、オンプレミスのアプリケーションを完全に廃止することができます。
同様に、例えば EC2 インスタンスから AWS Fargate で実行される Docker コンテナにワークロードを移行する場合も、新しいターゲットグループで新しいアプリケーションスタックを立ち上げ、ターゲットグループの重みを変更することによってトラフィックを徐々に移動させて、エンドユーザーへのダウンタイムなしで簡単に移行することができます。Application Load Balancer は、ターゲットとして EC2、コンテナ (Amazon ECS、Amazon Elastic Kubernetes Service、AWS Fargate)、AWS Lambda 関数などのさまざまな AWS のリソース、および IP アドレスをサポートしているため、これらすべての間でトラフィックを移動させることができます。
ターゲットグループの維持設定
クライアントに同じバージョンのアプリケーションを指定した期間経験させたい、または現在アプリケーションを使用しているクライアントが、セッション中新しくデプロイされた (グリーン
) バージョンに切り替わらないようにしたいという状況があります。これらのユースケースのために、AWS はターゲットグループの維持設定も導入しました。ターゲットグループの維持設定が有効化されていると、クライアントからのリクエストは、指定された期間中すべて同じターゲットグループに送信されます。その期間が過ぎると、リクエストは重みに従ってターゲットグループに分散されます。ALB は、ターゲットグループの維持設定を維持するためにクッキーを発行します。
ターゲットグループの維持設定は、すでに存在するターゲットの維持設定 (スティッキーセッションとも呼ばれます) とは異なることに注意してください。スティッキーセッションは、クライアントからのリクエストが常にターゲットグループ内の特定のターゲットに維持されることを確実にします。ターゲットグループの維持設定は、リクエストが特定のターゲットグループに送信されることを確実にするだけです。スティッキーセッションは、ターゲットグループレベルの維持設定と併用できます。
AWS コマンドラインインターフェイス (CLI) からターゲットグループの維持設定を追加または設定するには、以下のような TargetGroupStickinessConfig
パラメータを使用します。
aws elbv2 modify-listener \
--listener-arn "<listener arn" \
--default-actions \
'[{
"Type": "forward",
"Order": 1,
"ForwardConfig": {
"TargetGroups": [
{"TargetGroupArn": "<target group 1 arn>", "Weight": 20}, \
{"TargetGroupArn": "<target group 2 arn>", "Weight": 80}, \
],
"TargetGroupStickinessConfig": {
"Enabled": true,
"DurationSeconds": 2000
}
}
}]'
可用性
Application Load Balancer はリスナーのルールごとに最大 5 つのターゲットグループをサポートし、グループにはそれぞれに重みが付けられいます。重みは、API のしきい値上限まで、必要に応じて何度でも調整することができます。実際のトラフィックの重みが更新されるまで、わずかな遅延が発生する場合があります。
加重ターゲットグループは、本日すべての AWS リージョンで利用可能になります。Application Load Balancer での加重ターゲットグループの使用に追加のコストはかかりません。
PS: AWS 料金が増えないようにするため、このブログ記事用に作成したインフラストラクチャ例を忘れずに削除してください。CDK によって作成されたインフラストラクチャを手動で変更したため、シンプルな cdk destroy
が直ちに返ります。その代わりに AWS CloudFormation コンソールに接続して、AlbWtgStack
を削除してください。EC2 コンソールで blue
および green
の各ターゲットグループを手動で削除する必要もあります。