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

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エコシステムとの統合について説明します。

スピーカー

レポート

アジェンダ

  • リクエストルーティング
  • クライアント接続性
  • ヘルスチェック
  • モニタリング

リクエストルーティング、接続性

  • 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はラムダ関数をサポートする

クライアント接続性

ベストプラクティス

  1. クライアントが接続失敗したときに複数回接続すること
  2. DNSを更新できるようにする
  3. 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と統合

NLB

  • ALBとの主な違いはリスナーの後ろにルールがないこと
    • 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アプリケーションの起動を確認

Monitoring

  • CloudWatchメトリクス
    • ワークロードメトリクス
      • RequestCounts
      • ProcessedBytes
      • ConsumedLCU
    • ELBメトリクス
      • Response codes
      • Connections
    • ターゲットヘルスチェックメトリクス
      • Healthy and unhealthy targets
      • Response time and connection errors
  • CloudWatchダッシュボードに統合する

さいごに

基本的なELBのおさらいから、ベストプラクティについて説明していただき、各ELBの特徴では、基本から最新のアップデートを網羅する形で話を聞けました。私個人としては、Exponential Back-offについて理解していなかったため、勉強になりました。 ヘルスチェックやモニタリングのコツについての解説もあり、ELBの実践的なセッションだったと思いました。