PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する
トラフィックを複数のリソースやサービスに分散させ、ワークロードがクラウドの伸縮性を活用できるようにします。また、ロードバランシングを使用して暗号化ターミネーションをオフロードし、パフォーマンスと信頼性を向上させ、トラフィックを効率的に管理およびルーティングすることもできます。
一般的なアンチパターン:
-
ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。
-
パフォーマンスの最適化のためにロードバランサー機能を活用していない。
-
ワークロードがロードバランサーなしで直接インターネットに公開されている。
-
既存のロードバランサーを介して、すべてのインターネットトラフィックをルーティングしている。
-
汎用 TCP ロードバランシングを使用して、各コンピューティングノードが SSL 暗号化を処理するようにしている。
このベストプラクティスを活用するメリット: ロードバランサーは、単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにおけるアプリケーショントラフィックのさまざまな負荷を処理し、ワークロードの高可用性、自動スケーリング、効率的な使用を可能にします。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
ロードバランサーは、ワークロードのエントリポイントとして機能し、そこからコンピューティングインスタンスやコンテナなどのバックエンドターゲットにトラフィックを分散して使用率を改善します。
適切なロードバランサーの種類を選択することが、アーキテクチャを最適化するうえでの最初のステップとなります。まず、プロトコル (TCP、HTTP、TLS、または WebSocket など)、ターゲットの種類 (インスタンス、コンテナ、またはサーバーレスなど)、アプリケーション要件 (長時間実行される接続、ユーザー認証、または維持性など) や配置 (リージョン、ローカルゾーン、アウトポスト、ゾーン分離など) のワークロードの特性をリストアップすることから始めます。
AWS は、アプリケーションでロードバランシングを使用するためのモデルを複数提供しています。Application Load Balancer は、HTTP および HTTPS トラフィックのロードバランシングに最適で、マイクロサービスとコンテナを含めたモダンアプリケーションアーキテクチャの実現を目的とする高度なリクエストルーティングを提供します。
Network Load Balancer は、きわめて高いパフォーマンスが要求される TCP トラフィックのロードバランシングに最適です。超低レイテンシーを維持しながら 1 秒あたり数百万件ものリクエストを処理することができ、突発的、または変動しやすいトラフィックパターンを処理するために最適化されています。
Elastic Load Balancing
適切なロードバランサーを選択したら、ロードバランサーの機能を活用して、バックエンドが必要とするトラフィック処理のための労力を削減できます。
例えば、Application Load Balancer (ALB) と Network Load Balancer (NLB) の両方を使用して、SSL/TLS 暗号化オフロードを実行できます。これにより、CPU 負荷が高い TLS ハンドシェイクのターゲットによる終了を回避して、証明書管理を改善する機会が得られます。
ロードバランサーで SSL/TLS オフロードを設定すると、暗号化されていないトラフィックをバックエンドに配信すると同時に、クライアントとの間のトラフィックの暗号化の役目を果たすため、バックエンドリソースが解放され、クライアントにとっての応答時間が改善されます。
Application Load Balancer は、ターゲットでのサポートを必要とせずに HTTP/2 トラフィックを処理することもできます。このようなシンプルな決断をすることで、HTTP/2 は TCP 接続をより効率的に使用するようになり、アプリケーションの応答時間を改善できます。
アーキテクチャを定義する際は、ワークロードのレイテンシー要件を考慮する必要があります。例えば、レイテンシーの影響を受けやすいアプリケーションがある場合、非常に低レイテンシーを実現する Network Load Balancer を使用するよう決定することができます。AWS Local Zones
レイテンシーの影響を受けやすいワークロードに関して考慮すべきもう 1 つの点は、クロスゾーン負荷分散です。クロスゾーン負荷分散を使用すると、各ロードバランサーノードは許可されたすべてのアベイラビリティーゾーン内の登録済みターゲットにトラフィックを分散します。
ロードバランサーと統合された自動スケーリングを使用します。パフォーマンス効率に優れたシステムの重要な側面の 1 つに、バックエンドリソースのサイズの適切な設定があります。これを実現するには、バックエンドターゲットリソースのロードバランサー統合を利用できます。Auto Scaling グループと統合したロードバランサーを使用することで、受信トラフィックに対応して、必要に応じてターゲットがロードバランサーに追加されたり削除されたりします。コンテナ化されたワークロードには、ロードバランサーを Amazon ECS および Amazon EKS と統合できます。
実装手順
-
トラフィック量、可用性、アプリケーションのスケーラビリティなど、ロードバランシングの要件を定義します。
-
アプリケーションに適したロードバランサータイプを選択します。
-
HTTP/HTTPS ワークロードには Application Load Balancer を使用します。
-
TCP または UDP で実行される HTTP 以外のワークロードには、Network Load Balancer を使用します。
-
両方の製品の機能を活用する場合は、両方の組み合わせ (ALB を NLB のターゲット)
を使用します。例えば、NLB の静的 IP を ALB からの HTTP ヘッダーベースのルーティングと組み合わせて使用する場合や、HTTP のワークロードを AWS PrivateLink に公開する場合は利用します。 -
すべてのロードバランサーの比較については、「ELB 製品比較
」を参照します。
-
-
可能であれば SSL/TLS オフロードを使用します。
-
AWS Certificate Manager
と統合された Application Load Balancer と Network Load Balancer の両方を使用して HTTPS/TLS リスナーを設定します。 -
ワークロードによっては、コンプライアンス上の理由で、エンドツーエンドの暗号化が必要になる場合があることに注意します。この場合は、ターゲットで暗号化を許可する必要があります。
-
セキュリティのベストプラクティスについては、「SEC09-BP02 伝送中に暗号化を適用する」を参照してください。
-
-
適切なルーティングアルゴリズムを選択します (ALB のみ)。
-
ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。例えば、ALB には 2 つのルーティングアルゴリズムオプションがあります。
-
最小未処理リクエスト: アプリケーションのリクエストの複雑性が異なる場合や、ターゲットの処理能力が異なる場合に、バックエンドターゲットへのロードバランシングを改善するために使用します。
-
ラウンドロビン: リクエストとターゲットが同様の場合、またはリクエストをターゲット間で均等に分散する必要がある場合に使用します。
-
-
クロスゾーンまたはゾーン分離を検討します。
-
レイテンシーの改善とゾーンの障害ドメイン対策として、クロスゾーンをオフ (ゾーン分離) で使用します。NLB ではデフォルトでオフになっており、ALB ではターゲットグループごとにオフにできます。
-
可用性と柔軟性の向上のために、クロスゾーンをオンにします。クロスズーンは ALB ではデフォルトでオフになっており、NLB ではターゲットグループごとにオフにできます。
-
-
HTTP ワークロードの HTTP キープアライブをオンにします (ALB のみ)。この機能を使用すると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できるため、HTTP リクエストと応答時間が改善され、バックエンドターゲットでのリソース使用率も低減します。Apache と Nginx での実現方法については、「ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。
」を参照してください。 -
ロードバランサーのモニタリングをオンにします。
-
Application Load Balancer および Network Load Balancer のアクセスログを有効にしてください。
-
ALB の場合に考慮すべき主なフィールドは
request_processing_time
、request_processing_time
、およびresponse_processing_time
です。 -
NLB の場合に考慮すべき主なフィールドは
connection_time
およびtls_handshake_time
です。 -
必要な際にログをクエリできるように準備を整えておきます。Amazon Athena を使用して、ALB ログと NLB ログの両方をクエリできます。
-
TargetResponseTime
for ALB などパフォーマンス関連のメトリクス用アラームを作成します。
-
リソース
関連ドキュメント:
関連動画:
関連する例: