翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ロードバランサーの維持戦略の選択
*Ryan Griffin、Amazon Web Services (AWS）*
*2024 年 7 月* ([ドキュメント履歴](doc-history.md)）
*スティッキー*とは、ロードバランサーの機能を記述して、複数の送信先間でトラフィックのバランスをとるのではなく、クライアントから単一の送信先にトラフィックを繰り返しルーティングするために使用される用語です。例えば、クライアント A からのトラフィックは特定のサーバーに継続的にルーティングできるため、サーバーはセッション状態データを維持できます。クライアント A からのトラフィックが 2 つの異なるサーバーにルーティングされる場合、各サーバーには他のサーバーで利用できる重要な情報が欠落している可能性があります。
したがって、ロードバランサーを介して一貫したクライアント接続を維持する必要があることがよくあります。維持には、スティッキーセッションとターゲットグループの維持の 2 種類があります。
+ **スティッキーセッション** – インスタンスがセッション状態情報をローカルで維持またはキャッシュできるため、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでローカルセッションデータを維持し、アプリケーションアーキテクチャを簡素化したり、アプリケーションのパフォーマンスを向上させたりします。 AWS は現在、アプリケーション Cookie とロードバランサー Cookie の 2 種類のスティッキーセッションを提供しています。
+ **ターゲットグループの維持** – ブルー/グリーンデプロイでは、アプリケーションの複数のバージョンがデプロイされている場合があり、セッション中にクライアントが同じバージョンのアプリケーションを引き続き使用したい場合があります。この場合、ターゲットグループの維持を使用して、クライアントからのすべての通信を、同じ EC2 インスタンスではなく同じターゲットグループにルーティングできます。
これら 2 つの維持戦略は、個別に使用することも、一緒に使用することもできます。
このガイドでは、戦略の選択に役立つ、さまざまなタイプのロードバランサーの維持と適用可能なユースケースについて説明します。このガイドには、各戦略を説明する AWS CloudFormation テンプレートが含まれています。
## 「サンプルコード」
このガイドでは、4 つの AWS CloudFormation テンプレートを含む .zip ファイルが添付されています。これらのテンプレートをデプロイして、基本的なアーキテクチャを構築し、各維持戦略を試すことができます。これらのテンプレートをラボ環境にデプロイして、各アプローチをテストすることをお勧めします。
[ サンプルコードをダウンロードする](samples/stickiness.zip)
ダウンロードには、次のテンプレートが含まれています。
+ `basic.yml` – 維持せずに Application Load Balancer を設定します。
+ `targetgroupstickiness.yml` – ターゲットグループに基づいて維持を示します。
+ `stickysessionslb.yml` – ロードバランサーが生成した Cookie を使用したスティッキーセッションを示します。
+ `stickysessionsapp.yml` – アプリケーションベースの Cookie を使用したスティッキーセッションを示します。
これらのテンプレートをデプロイするには、アクティブな :AWS account と [CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)へのアクセスが必要です。CloudFormation テンプレートをデプロイするstep-by-stepsについては、 CloudFormation ドキュメントの[「スタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。