# PERF05-BP04 ロードバランシングと暗号化のオフロードを活用する
<a name="perf_select_network_encryption_offload"></a>

ロードバランサーを使用して、ターゲットリソースの最適なパフォーマンス効率を実現し、システムの応答性を向上します。

 **期待される成果:** トラフィックを処理するコンピューティングリソースの数を低減します。ターゲットにおけるリソース消費の不均衡を回避します。高度なコンピューティング集約型タスクをロードバランサーにオフロードします。クラウドの伸縮性と柔軟性を活用して、パフォーマンスを向上し、アーキテクチャを最適化します。 

 **一般的なアンチパターン:** 
+ ロードバランサーの種類を選択する際にワークロードの要件を考慮していない。
+ パフォーマンスの最適化のためにロードバランサー機能を活用していない。
+  ロードバランサーを介さずにワークロードをインターネットに直接公開している。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

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

 ロードバランサーは、ワークロードのエントリポイントとして機能し、そこからコンピューティングインスタンスやコンテナなどのバックエンドターゲットにトラフィックを分散します。適切なロードバランサーの種類を選択することが、アーキテクチャを最適化するうえでの最初のステップとなります。 

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

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

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

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

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

 ロードバランサーを使用すると、コンテナやサーバーレスなどのさまざまな種類のバックエンドにトラフィックを分散させて、アーキテクチャの柔軟性を向上することもできます。例えば、ヘッダー、メソッド、パターンなどのリクエストパラメータに基づいてトラフィックをさまざまなターゲットグループに転送する[リスナールール](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html)を使用するように Application Load Balancer を設定できます。 

 アーキテクチャを定義する際は、ワークロードのレイテンシー要件を考慮する必要もあります。例えば、レイテンシーの影響を受けやすいアプリケーションがある場合、非常に低レイテンシーを実現する 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 桁ミリ秒単位で増加する場合があるとはいえ、可用性が改善します。 

 最後に、ALB と NLB の両方により、ログやメトリクスなどのモニタリングリソースが提供されます。モニタリングを適切に設定すると、アプリケーションのパフォーマンスに関するインサイトの収集に役立ちます。例えば、ALB アクセスログを使用して、他のものより応答時間がかかるリクエストや、パフォーマンスの問題を引き起こしているバックエンドターゲットを検出できます。 

 **実装手順** 

1.  ワークロードに適したロードバランサーを選択します。 

   1.  HTTP/HTTPS のワークロードには、Application Load Balancer を使用します。 

   1.  TCP または UDP で実行される HTTP 以外のワークロードには、Network Load Balancer を使用します。 

   1.  両方の製品の機能を活用したい場合は、両方を組み合わせて ([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) に公開する場合に使用します。 

   1.  すべてのロードバランサー製品の比較については、「[ELB の製品の比較](https://aws.amazon.com/elasticloadbalancing/features/)」を参照してください。 

1.  SSL/TLS オフロードを使用します。 

   1.  [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 リスナーを設定します。 

   1.  ワークロードによっては、コンプライアンス上の理由で、エンドツーエンドの暗号化が必要になる場合があることに注意します。この場合は、ターゲットで暗号化を有効にする必要があります。 

   1.  セキュリティのベストプラクティスについては、「[SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html)」を参照してください。 

1.  適切なルーティングアルゴリズムを選択します。 

   1.  ルーティングアルゴリズムは、バックエンドターゲットの使用状況に変化をもたらし、パフォーマンスへの影響を左右します。例えば、ALB には、以下の[2 つのルーティングアルゴリズムのオプション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm)があります。 

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

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

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

   1.  レイテンシーの改善とゾーンの障害ドメイン対策として、クロスゾーンをオフ (ゾーン分離) で使用します。NLB ではデフォルトでオフになっていますが、[ALB ではターゲットグループごとにオフに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)。 

   1.  可用性と柔軟性の向上のためには、クロスゾーンをオンにします。ALB ではデフォルトでクロスゾーンはオンになっています。[NLB ではターゲットグループごとにオフに設定できます](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html)。 

1.  HTTP ワークロードの HTTP キープアライブをオンにします。 

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

1.  コンピューティングリソースのオーケストレーションを改善するには、Elastic Load Balancing 統合を使用します。 

   1.  ロードバランサーと統合された Auto Scaling を使用します。パフォーマンス効率に優れたシステムの重要な側面の 1 つに、バックエンドリソースのサイズの適切な設定があります。これを実現するには、バックエンドターゲットリソースのロードバランサー統合を利用できます。Auto Scaling グループと統合したロードバランサーを使用することで、受信トラフィックに対応して、必要に応じてターゲットがロードバランサーに追加されたり削除されたりします。 

   1.  コンテナ化されたワークロードには、ロードバランサーを Amazon ECS および Amazon EKS と統合できます。 
      + [Auto Scaling グループ内のインスタンス全体にトラフィックを分散するには、Elastic Load Balancing を使用します](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.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)

1.  ロードバランサーをモニタリングして、パフォーマンスのボトルネックを検出します。 

   1.  [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) のアクセスログを有効にします。 

   1.  ALB の場合に考慮すべき主なフィールドは以下のとおりです。 `request_processing_time`、`request_processing_time`、 `response_processing_time`. 

   1.  NLB の場合に考慮すべき主なフィールドは以下のとおりです。 `connection_time` および `tls_handshake_time`. 

   1.  必要な際にログをクエリできるように準備を整えておきます。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)の両方をクエリできます。 

   1.  [ALB の`TargetResponseTime`](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) などのパフォーマンス関連メトリクスのアラームを作成します。 

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

 **関連するベストプラクティス:** 
+  [SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html) 

 **関連するドキュメント:** 
+ [ ELB 製品の比較](https://aws.amazon.com/elasticloadbalancing/features/)
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [ Improving Performance and Reducing Cost Using Availability Zone Affinity ](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/) (アベイラビリティーゾーンのアフィニティを使用したパフォーマンスの向上とコストの削減)
+ [ Step by step for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/amazon-athena-for-elb)(Amazon Athena を使用したログ分析の詳しい手順)
+ [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)

 **関連動画:** 
+ [AWS re:Invent 2018: [REPEAT 1] Elastic Load Balancing: Deep Dive and Best Practices (NET404-R1) ](https://www.youtube.com/watch?v=VIgAT7vjol8)(AWS re:Invent 2018: [リピート 1] Elastic Load Balancing: ディープダイブとベストプラクティス (NET404-R1))
+ [AWS re:Invent 2021 - How to choose the right load balancer for your AWS workloads ](https://www.youtube.com/watch?v=p0YZBF03r5A)(AWS re:Invent 2021 - AWS のワークロードに適切なロードバランサーを選択する方法)
+ [AWS re:Inforce 2022 - How to use Elastic Load Balancing to enhance your security posture at scale (NIS203) ](https://www.youtube.com/watch?v=YhNc5VSzOGQ)(AWS re:Inforce 2022 - セキュリティ体制の大規模な強化のために Elastic Load Balancing を使用する方法 (NIS203))
+ [AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads (NET407-R2) ](https://www.youtube.com/watch?v=HKh54BkaOK0)(AWS re:Invent 2019: さまざまなワークロードに Elastic Load Balancing を最大限に活用する (NET407-R2))

 **関連する例:** 
+ [ CDK and CloudFormation samples for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/log-analysis-elb-cdk-cf-template) (Amazon Athena を使用したログ分析の CDK とCloudFormation の例)