[レポート] さまざまなワークロードに対してElastic Load Balancingを最大限に活用する #NET407 #reinvent

AWS re:Invent 2019
#Elastic Load Balancing (ELB)
#AWS
中川翔太
2019.12.03
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事はAWS re:Invent 2019のセッション「NET407-R : Get the most from Elastic Load Balancing for different workloads」のレポートになります。
 セッションについて 概要Elastic Load Balancing automatically distributes incoming application traffic across multiple application targets for fault tolerance and load distribution. In this session, we do a deep-dive and cover everything you ever wanted to know about using Application Load Balancers and Network Load Balancers. We go over some interesting use cases and cover topics such as picking the right load balancer, architectural best practices, and load balancing principles. We also go into detail about configuration and day-to-day management and discuss how you can analyze your applications using Amazon CloudWatch metrics and ELB access logs and their integration with the broader AWS ecosystem.
Elastic Load Balancingは、フォールトトレランスと負荷分散のために、着信アプリケーショントラフィックを複数のアプリケーションターゲットに自動的に分散します。 このセッションでは、Application Load BalancerとNetwork Load Balancerの使用について知りたいことをすべて詳しく説明します。 いくつかの興味深いユースケースを検討し、適切なロードバランサーの選択、アーキテクチャのベストプラクティス、ロードバランシングの原則などのトピックを取り上げます。 また、設定と日常の管理について詳しく説明し、Amazon CloudWatchメトリックスとELBアクセスログを使用してアプリケーションを分析する方法と、より広範なAWSエコシステムとの統合について説明します。
 スピーカーJon Zobrist - Systems Development Manager, Amazon Web Services
Narayan Subramaniam - Senior Manager Technical Product and Program Management, Amazon Web Services
 レポート アジェンダリクエストルーティング
クライアント接続性
ヘルスチェック
モニタリング
 リクエストルーティング、接続性ELBから得られるメリットは何でしょうか？
弾力性
自動でスケールアップやスケールアップをする

セキュリティ
アプリケーション化rあロードバランサにSSLをオフロード

エコシステムとの統合
ECSやEKSの自動スケーリングなど、他のAWSサービスをインテグレーションしている
CloudWatchメトリクスやAWSConfigと統合されている

費用対効果
マネージドインスタンスなので管理が簡単


ELBファミリーについて（ALB、NLB、CLBの機能表を見せながら）
application load blancer
レイヤ7でHTTPとHTTPSのトラフィックをバランシグする

network load balancer
レイヤ4で動作し、TCPとUDPトラフィックを扱う

classic load balancer
多くのワークロードで推奨していない

機能要求の違い
ALBはHTTP2、webソケットをサポート
極端なパフォーマンスをもとめられるときはNLB

ターゲットの違い
IPベースでターゲットをサポート
ALBはラムダ関数をサポートする


 クライアント接続性 ベストプラクティスクライアントが接続失敗したときに複数回接続すること
DNSを更新できるようにする
Exponential Back-ff & jitter
DNSから2つめのIPを取得し、接続を失敗したときに2つめのIPアドレスへ接続できるようにする
TTLを超えている場合は、その時点でDNSを更新するようにする
2つのIPに対しての接続が失敗し、複数回再接続する場合は、Exponential backoffとJitterアルゴリズムを使うようにする
バックオフの必要性を決定することは重要

DNSがTTLを更新する時間を尊重し、複数可の再試行が失敗したときはExponential backoffを使用して、ジッター再接続を追加する
 ALBリスナー
例
/analytics →lambda
/auth → Cognito
/dashboard → ekl


ルーティングルール
メソッドの場所、クエリ文字列をもつパス、ホストのヘッダなどの条件にもづいてルールを構成し、ルーティングする
リダイレクト（80を443へ）
固定のレスポンス応答が可能

SNI
同じロードバランサーで複数のドメインをホスト
25証明書まで可能

重み付けターゲットグループ 【new】
ユースケース
Blue/Greenデプロイ
Hybrid deployment, クラウド移行
A/Bテスト


Leatest outstanding request routing 【new】
未処理の要求をラウンドロビンまたはスロースタートで選択できるようになった

ALB Ingress Controller for Kubernetes
Lambda関数のターゲット
制限に気をつける
リクエストボディが1MBを超えないように
ラムダは同じアカウント内にあること


ターゲットのベストプラクティス
オフロード
TLS終端
多くのTLS policy
TLS1.2以降のみを使用可能

ACMを使用した自動証明書更新
ターゲットはELBのSGを許可するように設定
WAF連携
AWS Managed Rules

認証のオフロード
OIDCベースのIDPと通信するロードバランサーで認証機能をオフロードする場合に、Cognitoと統合


 NLBALBとの主な違いはリスナーの後ろにルールがないこと
UDPフローを処理、ルーティングしているため

静的IPアドレスを使用する
アカウントからElastic IPを1つ割り当てる
ロードバランサを削除しても同じIPを保持できる

内部NLBを作成するときに各サブネットのNLBのプライベートIPを指定できる
新しいサブネットを追加する機能を実現

NLB接続のルーティング例
ソースIPは保持されることに注意

パブリックLBはクライアントのIPをファイアウォールまで保持できる
AWS Hyperplaneを使用している
長期間接続を分散されたメモリストアに保存している
IoTのようなワークロードで役立つ
数百万のデバイスを双方向の接続を可能にする
NLBを使用すると数週間、数ヶ月間の接続を有効にできる

瞬間スケーリング可能
クライアントが接続するIPアドレスを変更することがない
クライアントは変更や影響なしにトラフィックを送り続けられる


Kubenetesでメディアとストリーミング処理の例
 ヘルスチェック外部ヘルスチェック (Route53)
Route 53は外部ビュー
Route53のヘルスチェックに失敗したIPはDNSから取り除く
クロスゾーンは可用性を向上する

内部ヘルスチェック
TCP
TLS/SSL
HTTP/HTTPS
HTTPアプリケーションの起動を確認


 MonitoringCloudWatchメトリクス
ワークロードメトリクス
RequestCounts
ProcessedBytes
ConsumedLCU

ELBメトリクス
Response codes
Connections

ターゲットヘルスチェックメトリクス
Healthy and unhealthy targets
Response time and connection errors


CloudWatchダッシュボードに統合する
 さいごに基本的なELBのおさらいから、ベストプラクティについて説明していただき、各ELBの特徴では、基本から最新のアップデートを網羅する形で話を聞けました。私個人としては、Exponential Back-offについて理解していなかったため、勉強になりました。

ヘルスチェックやモニタリングのコツについての解説もあり、ELBの実践的なセッションだったと思いました。