View a markdown version of this page

PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する - AWS Well-Architected Framework
実装のガイダンスリソース

PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する

トラフィックを複数のリソースやサービスに分散させ、ワークロードがクラウドの伸縮性を活用できるようにします。また、ロードバランシングを使用して暗号化ターミネーションをオフロードし、パフォーマンスと信頼性を向上させ、トラフィックを効率的に管理およびルーティングすることもできます。

一般的なアンチパターン:

  • ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。

  • パフォーマンスの最適化のためにロードバランサー機能を活用していない。

  • ワークロードがロードバランサーなしで直接インターネットに公開されている。

  • 既存のロードバランサーを介して、すべてのインターネットトラフィックをルーティングしている。

  • 汎用 TCP ロードバランシングを使用して、各コンピューティングノードが SSL 暗号化を処理するようにしている。

このベストプラクティスを活用するメリット: ロードバランサーは、単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにおけるアプリケーショントラフィックのさまざまな負荷を処理し、ワークロードの高可用性、自動スケーリング、効率的な使用を可能にします。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

ロードバランサーは、ワークロードのエントリポイントとして機能し、そこからコンピューティングインスタンスやコンテナなどのバックエンドターゲットにトラフィックを分散して使用率を改善します。

適切なロードバランサーの種類を選択することが、アーキテクチャを最適化するうえでの最初のステップとなります。まず、プロトコル (TCP、HTTP、TLS、または WebSocket など)、ターゲットの種類 (インスタンス、コンテナ、またはサーバーレスなど)、アプリケーション要件 (長時間実行される接続、ユーザー認証、またはスティッキーなど) や配置 (リージョン、ローカルゾーン、アウトポスト、ゾーン分離など) のワークロードの特性をリストアップすることから始めます。

AWS は、アプリケーションでロードバランシングを使用するためのモデルを複数提供しています。Application Load Balancer は、HTTP トラフィックと HTTPS トラフィックのロードバランシングに最適です。マイクロサービスやコンテナといった最新のアプリケーションアーキテクチャを対象とした高度なリクエストルーティングを実現できます。

Network Load Balancer は、きわめて高いパフォーマンスが要求される TCP トラフィックのロードバランシングに最適です。超低レイテンシーを維持しながら 1 秒あたり数百万件ものリクエストを処理することができ、突発的、または変動しやすいトラフィックパターンを処理するために最適化されています。

Elastic Load Balancing は、統合された証明書管理と SSL/TLS 復号化を提供するため、ロードバランサーの SSL 設定を一元的に管理し、CPU に負荷のかかる SSL/TLS 処理をお客様のワークロードからオフロードすることができます。

適切なロードバランサーを選択したら、ロードバランサーの機能を活用して、バックエンドが必要とするトラフィック処理のための労力を削減できます。

例えば、Application Load Balancer (ALB) と Network Load Balancer (NLB) の両方を使用して、SSL/TLS 暗号化オフロードを実行できます。これにより、CPU 負荷が高い TLS ハンドシェイクのターゲットによる終了を回避して、証明書管理を改善する機会が得られます。

ロードバランサーで SSL/TLS オフロードを設定すると、暗号化されていないトラフィックをバックエンドに配信すると同時に、クライアントとの間のトラフィックの暗号化の役目を果たすため、バックエンドリソースが解放され、クライアントにとっての応答時間が改善されます。

Application Load Balancer は、ターゲットでのサポートを必要とせずに HTTP2 トラフィックを処理することもできます。このようなシンプルな決断をすることで、HTTP2 は TCP 接続をより効率的に使用するようになり、アプリケーションの応答時間を改善できます。

アーキテクチャを定義する際は、ワークロードのレイテンシー要件を考慮する必要があります。例えば、レイテンシーの影響を受けやすいアプリケーションがある場合、非常に低レイテンシーを実現する Network Load Balancer を使用するよう決定することができます。または、Application Load Balancer を  AWS Local Zones 、あるいは  AWS Outposts で活用して、ワークロードをより顧客の近くに配置する方法を採用することもできます。

レイテンシーの影響を受けやすいワークロードに関して考慮すべきもう 1 つの点は、クロスゾーン負荷分散です。クロスゾーン負荷分散を使用すると、各ロードバランサーノードは許可されたすべてのアベイラビリティーゾーン内の登録済みターゲットにトラフィックを分散します。

ロードバランサーと統合された Auto Scaling を使用します。パフォーマンス効率に優れたシステムの重要な側面の 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 オフロードを使用します

  • 適切なルーティングアルゴリズムを選択します (ALB のみ)。

    • ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。たとえば、ALB には以下の 2 つのルーティングアルゴリズムのオプションがあります。

    • 最小未処理リクエスト: アプリケーションのリクエストの複雑性が異なる場合や、ターゲットの処理能力が異なる場合に、バックエンドターゲットへのロードバランシングを改善するために使用します。

    • ラウンドロビン: リクエストとターゲットが同様の場合、またはリクエストをターゲット間で均等に分散する必要がある場合に使用します。

  • クロスゾーンまたはゾーン分離を検討します。

  • HTTP ワークロードの HTTP キープアライブをオンにします (ALB のみ)。この機能を使用すると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できるため、HTTP リクエストと応答時間が改善され、バックエンドターゲットでのリソース使用率も低減します。Apache と Nginx でこれを実行する方法の詳細については、 「ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。」を参照してください。

  • ロードバランサーのモニタリングをオンにします。

リソース

関連するドキュメント:

関連動画:

関連する例: