# PERF04-BP04 ロードバランシングを使用してトラフィックを複数のリソースに分散する
<a name="perf_networking_load_balancing_distribute_traffic"></a>

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

 **一般的なアンチパターン:** 
+  ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。
+  パフォーマンスの最適化のためにロードバランサー機能を活用していない。
+  ワークロードがロードバランサーなしで直接インターネットに公開されている。
+  既存のロードバランサーを介して、すべてのインターネットトラフィックをルーティングしている。
+  汎用 TCP ロードバランシングを使用して、各コンピューティングノードが SSL 暗号化を処理するようにしている。

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

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

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

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

 AWS は、アプリケーションでロードバランシングを使用するためのモデルを複数提供しています。[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) は、HTTP および HTTPS トラフィックのロードバランシングに最適で、マイクロサービスとコンテナを含めたモダンアプリケーションアーキテクチャの実現を目的とする高度なリクエストルーティングを提供します。

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

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

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

 例えば、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](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) または [AWS Outposts](https://aws.amazon.com/outposts/rack/) で Application Load Balancer を利用して、ワークロードをユーザーに近づけることも検討できます。

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

 ロードバランサーと統合された自動スケーリングを使用します。パフォーマンス効率に優れたシステムの重要な側面の 1 つに、バックエンドリソースのサイズの適切な設定があります。これを実現するには、バックエンドターゲットリソースのロードバランサー統合を利用できます。Auto Scaling グループと統合したロードバランサーを使用することで、受信トラフィックに対応して、必要に応じてターゲットがロードバランサーに追加されたり削除されたりします。コンテナ化されたワークロードには、ロードバランサーを [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) および [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) と統合できます。
+  [Amazon ECS - サービスの負荷分散](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) 
+  [Amazon EKS でのアプリケーション負荷分散](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) 
+  [Amazon EKS でのネットワークロードバランシング](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html) 

### 実装手順
<a name="implementation-steps"></a>
+  トラフィック量、可用性、アプリケーションのスケーラビリティなど、ロードバランシングの要件を定義します。
+  アプリケーションに適したロードバランサータイプを選択します。
  +  HTTP/HTTPS ワークロードには Application Load Balancer を使用します。
  +  TCP または UDP で実行される HTTP 以外のワークロードには、Network Load Balancer を使用します。
  +  両方の製品の機能を活用する場合は、両方の組み合わせ ([ALB を NLB のターゲット)](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) を使用します。例えば、NLB の静的 IP を ALB からの HTTP ヘッダーベースのルーティングと組み合わせて使用する場合や、HTTP のワークロードを [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html) に公開する場合は利用します。
  +  すべてのロードバランサーの比較については、「[ELB 製品比較](https://aws.amazon.com/elasticloadbalancing/features/)」を参照します。
+  可能であれば SSL/TLS オフロードを使用します。
  +  [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) と統合された [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) と [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html) の両方を使用して HTTPS/TLS リスナーを設定します。
  +  ワークロードによっては、コンプライアンス上の理由で、エンドツーエンドの暗号化が必要になる場合があることに注意します。この場合は、ターゲットで暗号化を許可する必要があります。
  +  セキュリティのベストプラクティスについては、「[SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html)」を参照してください。
+  適切なルーティングアルゴリズムを選択します (ALB のみ)。
  +  ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。例えば、ALB には [ 2 つのルーティングアルゴリズムオプション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm)があります。
  +  **最小未処理リクエスト:** アプリケーションのリクエストの複雑性が異なる場合や、ターゲットの処理能力が異なる場合に、バックエンドターゲットへのロードバランシングを改善するために使用します。
  +  **ラウンドロビン:** リクエストとターゲットが同様の場合、またはリクエストをターゲット間で均等に分散する必要がある場合に使用します。
+  クロスゾーンまたはゾーン分離を検討します。
  +  レイテンシーの改善とゾーンの障害ドメイン対策として、クロスゾーンをオフ (ゾーン分離) で使用します。NLB ではデフォルトでオフになっており、[ALB ではターゲットグループごとにオフにできます](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)。
  +  可用性と柔軟性の向上のために、クロスゾーンをオンにします。クロスズーンは ALB ではデフォルトでオフになっており、[NLB ではターゲットグループごとにオフにできます](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html)。
+  HTTP ワークロードの HTTP キープアライブをオンにします (ALB のみ)。この機能を使用すると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できるため、HTTP リクエストと応答時間が改善され、バックエンドターゲットでのリソース使用率も低減します。Apache と Nginx での実現方法については、「[ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/apache-backend-elb/)」を参照してください。
+  ロードバランサーのモニタリングをオンにします。
  +  [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html) および [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) のアクセスログを有効にしてください。
  +  ALB の場合に考慮すべき主なフィールドは `request_processing_time`、`request_processing_time`、および `response_processing_time` です。
  +  NLB の場合に考慮すべき主なフィールドは `connection_time` および `tls_handshake_time` です。
  +  必要な際にログをクエリできるように準備を整えておきます。Amazon Athena を使用して、[ALB ログ](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html)と [NLB ログ](https://docs.aws.amazon.com/athena/latest/ug/networkloadbalancer-classic-logs.html)の両方をクエリできます。
  +  [`TargetResponseTime` for ALB](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) などパフォーマンス関連のメトリクス用アラームを作成します。

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [ELB 製品の比較 ](https://aws.amazon.com/elasticloadbalancing/features/) 
+  [AWS グローバルインフラストラクチャ ](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [アベイラビリティーゾーンのアフィニティを使用してパフォーマンス向上とコスト削減を実現](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/) 
+  [Amazon Athena でのログ分析ステップバイステップガイド](https://github.com/aws/elastic-load-balancing-tools/tree/master/amazon-athena-for-elb) 
+  [Application Load Balancer ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) 
+  [Application Load Balancer を監視する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html) 
+  [Network Load Balancer を監視する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-monitoring.html) 
+  [Elastic Load Balancing を使用して Auto Scaling グループ内のインスタンス全体にトラフィックを分散させる](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 

 **関連動画:** 
+  [AWS re:Invent 2023: アプリケーションに対するネットワーキングの利点](https://www.youtube.com/watch?v=tUh26i8uY9Q) 
+  [AWS re:Inforce 2022: Elastic Load Balancing を使用してセキュリティ体制を大規模に向上する方法](https://www.youtube.com/watch?v=YhNc5VSzOGQ) 
+  [AWS re:Invent 2018: Elastic Load Balancing: 詳細とベストプラクティス](https://www.youtube.com/watch?v=VIgAT7vjol8) 
+  [AWS re:Invent 2021: AWS ワークロードに最適なロードバランサーの選定方法](https://www.youtube.com/watch?v=p0YZBF03r5A) 
+  [AWS re:Invent 2019: さまざまなワークロードでの Elastic Load Balancing の活用方法](https://www.youtube.com/watch?v=HKh54BkaOK0) 

 **関連する例:** 
+  [Gateway Load Balancer](https://catalog.workshops.aws/gwlb-networking/en-US) 
+  [Amazon Athena を使用したログ分析の CDK と CloudFormation サンプル](https://github.com/aws/elastic-load-balancing-tools/tree/master/log-analysis-elb-cdk-cf-template)