[レポート]NET404 – Elastic Load Balancing: Deep Dive and Best Practices #reinvent

本記事は、AWS re:Invent 2018 のセッション 「NET404 - Elastic Load Balancing: Deep Dive and Best Practices」 のレポートです。

Elastic Load Balancing (ALB & NLB) automatically distributes incoming application traffic across multiple Amazon EC2 instances for fault tolerance and load distribution. In this session, we go into detail on ELB configuration and day-to-day management. We also discuss its use with Auto Scaling, and we explain how to make decisions about the service and share best practices and useful tips for success. Finally, Netflix joins this session to share how it leveraged the authentication functionality on Application Load Balancer to help solve its workforce identity management at scale.

• スピーカー
  • Pratibha Suryadevara - GM, Load Balancing, AWS
  • Will Rose - Senior Security Engineer, Netflix

レポート

• L4、L7 の違い
• L4
  • TCP をサポート
  • 受信クライアント接続はサーバー接続にバインドされる
  • ヘッダの変更なし
  • ヘッダまたはプロキシプロトコルに保存されているソース IP は、送信元と宛先のIPとリクエストするポートを先頭に付ける
• L7
  • HTTP と HTTPS をサポート
  • 接続はロードバランサで終了し、サーバーにプールされる
  • ヘッダーを変更することができる
  • x-forwarded-for ヘッダーには、クライアントの IP アドレスが含まれている

Deeper Look（ALB）

• API モデル
• ルーティング
• セキュリティ
• 可用性
• スケーラビリティと統合
• モニタリング
• 価格
• 移行

API モデル

• ターゲットグループには EC2、IP、ECS（コンテナ）などがあり、ルールによって振り分け

ルーティング

• IP をターゲットにする
  • ロードバランサの VPC 内のターゲットに対して、ロードバランサの VPC CIDR から IPv4 アドレスを使用
  • ロードバランサの VPC の外側にあるターゲットの RFC6598 範囲（100.64.0.0/10）および RFC1918範囲（10.0.0.0/8,172.16.0.0/12、および192.168.0.0/16）の任意のIPアドレスを使用。これには、ピア接続された VPC、EC2-Classic、および DirectConnectまたは VPN 経由で到達可能なオンプレミスのターゲットが含まれます
• コンテンツベースのルーティング
  • HTTP ヘッダに基づくルート
  • 1つのロードバランサーでマルチドメインに対応
  • 各パスまたはホスト名を別のターゲットグループにルーティング
• リダイレクト in ALB
  • HTTP to HTTP
  • HTTP to HTTPS
  • HTTPS to HTTPS
• 固定レスポンス
  • アプリケーションフリートによって提供されるべきクライアント要求を制御
  • ロードバランサは、コンテンツベースのルーティングルールでサポートされている基準に基づいて、HTTP リクエストに自動的に応答
  • HTTP レスポンスコードとカスタムエラーメッセージをクライアントに返すように設定できる
• スロースタート
  • スロースタートでは、リクエストの Flood に圧倒されることなく新しいターゲットを追加することができる
  • ロードバランサは、新しいターゲットに送信されたリクエスト数を、公平な共有まで直線的に増加させます
  • リクエストの分配を受け取る前にターゲットの暖気するとができます
  • 最適なパフォーマンスのためにキャッシュウォーミングに依存するアプリケーションに役立ちます
• IPv6 サポート

セキュリティ

• ACM を使ったパターン
• 定義済みセキュリティポリシー
• ALB with WAF
  • Web リクエストを監視し、ロードバランサの悪質なリクエストから Web アプリケーションを保護する
  • IP アドレスなどの条件に基づいてリクエストをブロックまたは許可する
  • SQL インジェクションやクロスサイトスクリプティングなどの一般的な攻撃を阻止するための保護機能を備えている
  • AWS WAF コンソール から WebACLs とルールを設定し、それらをロードバランサに適用する
• SNI
• ALB での認証
  • アプリケーションにアクセスするユーザーを認証します
  • 任意の OIDC 準拠の IDP とのネイティブな統合
  • Amazon Cognito とのアイデンティティ統合を認証する
  • SAML を使用してエンタープライズ IDP で認証する

Netflix 事例

ここから NETFLIX の方が登壇

• NETFLIX ID プラットフォーム
  • Workforce identity-as-a-service
  • すべてのものを連携させる
  • 開発者セルフサービス
  • シングルサインオンのユーザーエクスペリエンス
• 背景
  • 何百ものアプリケーションが毎日成長している
  • 言語とフレームワークが豊富にある
  • それらは、大きな自由をもって来る
  • とても変わりやすい
• ID チャレンジ
  • クライアントライブラリを使用して連携するだけ！
    • 新しい言語やフレームワークに常に追いついている
    • さまざまな品質と完全性のオープンソースオプション
    • 開発者の設定まわりの摩擦
  • 認証プロキシを使用するだけ！
    • 維持するための追加の重要なインフラストラクチャ
    • 運用に必要なインフラストラクチャの追加コスト
    • 潜在的なボトルネックと新たな障害モードに対処する必要がある
  • 選択したのは上記のどれでもなかった
  • CrayzyTalk
    • なぜ ALB ではないのでしょうか？
    • auth == 区別されていない力仕事
    • Amazon と話しましょう
  • Alphabet soup
    • AWS アカウント x1
    • ALB x1
    • OIDC x1
    • 6ヶ月間 煮てみた（シミュレートした、ってことだと思います）
    • すべてのサーバ
  • Under the Hood
    • 1.認証されていない要求。
    • 2.OpenIDプロバイダにリダイレクトする
    • 3.ユーザーを認証する
    • 4.認証された要求
    • 5.アイデンティティヘッダー

• 採用
  • ネイティブな Spinnaker の統合
  • わずか数回のクリックで完全にセルフサービスを提供します
  • すべての言語で同じ統合エクスペリエンスを提供します
  • 新しいインフラストラクチャは必要ありません
  • すべてのアプリケーションに推奨される統合パス

AWS の方に戻ってつづき

• コンソールのタグによるフィルタリング
  • ロードバランサとターゲットグループをタグでフィルタリングします
  • あなた、またはあなたのグループが担当するリソースだけを表示できます
  • 間違ったロードバランサまたはターゲットグループに変更を加えることによる人的ミスを軽減します
• リソースレベルとタグベースのアクセス許可
  • IAM ポリシーを使用してロードバランサリソースに対してきめ細かなアクセス制御を実装します
  • リソース ARN またはリソース上の特定のタグに基づいてポリシーを作成します
  • ロードバランサ、リスナー、ルール、またはターゲットグループのアクセス制御ポリシーを作成します

可用性

• クロスゾーンロードバランシング
  • リクエストは複数の AZ に均等に分散されます
  • ロードバランサは DNS キャッシングの影響を吸収します
  • バックエンドインスタンスの使用率の不均衡を解消します
  • クロスゾーントラフィックのための追加の帯域幅課金はありません
  • デフォルトではすべての ALB で有効になります。
• ヘルスチェックでは、トラフィックを失敗したインスタンスから外すことができます
• ヘルスチェック
  • HTTP および HTTPS ヘルスチェックのサポート
  • 頻度と失敗をカスタマイズ
  • あなたのヘルスチェックの深さと正確さを考慮してください
  • 成功したレスポンスコードのリストをカスタマイズします。例えば200-300です。
  • ヘルスチェックの失敗の詳細が API および管理コンソールから返されるようになりました

スケーラビリティと統合

• Amazon EC2 Auto Scaling
  • 構成された EC2 の起動 = 分単位

• Amazon Elastic Container Service

• コンテナ：Kubernetes / EKSとALBの統合
  • ALB ingress コントローラ
    • Kubernetesクラスタへのホストまたはパスベースのルーティングを可能にします。
      • ALBは複数のサービスに直面し、「スマート・ルータ」またはKubernetesクラスタへの入り口ポイントとして機能します。
      • ALBの豊富なレイヤ7ルーティング機能
  • https://github.com/kubernetes-sigs/aws-alb-ingress-controller
• ALB w/ Amazon ECS || Amazon EKS Scaling
  • Start RUN = 秒単位

監視：メトリックとアクセスログ

• Amazon CloudWatch のメトリクス
  • 各ロードバランサに提供される CloudWatch メトリクス
  • ロードバランサとアプリケーションスタックの状態を詳細に把握できます
  • CloudWatch アラームは、メトリクスが許容範囲外になった場合に通知またはアクションを実行するように設定できます
  • すべてのメトリクスは1分単位で提供されます
• アクセスログ
  • ロードバランサによって処理される各リクエストの詳細情報を提供します
  • リクエスト時間、クライアントIPアドレス、待ち時間、要求パス、およびサーバー応答が含まれます
  • 5分または60分ごとに Amazon S3 バケットに配送されます。

価格

• ALB プライシング
  • ALB が稼働している時間または部分時間ごと、および1時間あたりに使用されているロードバランサ容量単位（LCU）の数が請求されます。
    • ALB 時間（または部分時間）あたり $0.0225
    • LCU 時間（または部分時間）あたり $0.008
  • CLB より10％安い
• ロード・バランサのキャパシティー・ユニット(LCU)
  • LCU は、ALB がトラフィックを処理するディメンションを測定します（平均して1時間以上）。
  • 測定される4つのディメンションは以下の通り
    • 新しい接続： 毎秒最大 25 の新しい接続
    • アクティブな接続： 最大 3000 のアクティブな接続
    • 帯域幅：最大 2.22 Mbps（1GB/時）
    • 1000 ルールの評価

移行

• アプリケーションロードバランサへの移行
  • クラシックから ALB に移行する場合、顧客が価格を見積もることを可能にする CLB の LCU メトリクスを公開しています。
  • 新しいアプリケーションロードバランサを作成し、ターゲットを登録し、新しい CNAME を指すように DNS を更新するだけで簡単に移行できます
  • CLB または ALB の移行ユーティリティ
    • https://github.com/aws/elastic-load-balancing-tools

NLB

• レイヤ4 ロードバランシングプラットフォーム
• 接続ベースの負荷分散
• TCPプロトコル
• ハイパフォーマンス
  • 毎秒何百万というリクエストを処理できます
• 静的 IP サポート
  • 長時間接続を使用するアプリケーションに最適です
  • AZごとに1つのIPが自動的に割り当てられます
  • AZごとにEIPを割り当てて静的IPを取得します
  • ファイアウォールのホワイトリスト作成とゼロ金請求の使用例を支援します
• ALB と同じリソース
  • 改善された ELB API
  • リスナー
  • ターゲットグループ
  • ターゲット
• EIP アドレスを割り当てる
  • EIP を割り当てると、変更されないロードバランサごとに 1 つの AZ ごとに 1 つの IP アドレスが提供されます
• ソースIPを保持する
  • クライアント IP をバックエンドに保存します
  • ロギングやその他のアプリケーションに使用できます
  • プロキシプロトコルの必要性を取り除きます。
  • IP アドレスへのロードバランシング時にプロキシプロトコルV2をサポート
• ファイアウォールの NLB の例
  • 外部 NLB のアドレス数が少ない
    • ファイアウォール、プロキシ、またはサードパーティのロードバランサに使用されます
  • Geo-IP ブロッキングのような機能を備えたファイアウォールを支援するソース IP を保護します
  • 内部 NLB は IP を変更しない
    • ファイアウォール、WAF、およびプロキシが NAT の単一アドレスを維持できるようにします

• ヘルスチェック
  • ネットワークターゲットとアプリケーションターゲットの両方のヘルスチェックをサポートします
  • ネットワークヘルスチェック
    • 通常のトラフィックに対するターゲットの全体的な応答に基づいています
    • ミリ秒単位で無応答のターゲットに失敗します
  • アプリケーションレベルのヘルスチェック
    • HTTP、HTTPS、TCP
    • 頻度、障害のしきい値をカスタマイズします
• AZ フェイルオーバー

モニタリング：メトリックとフローログ

• トラフィックと容量のメトリック
  • ActiveFlowCount
    • クライアントからターゲットへの同時TCPフロー（または接続）の合計数
  • NewFlowCount
    • クライアントからターゲットに確立された新しいTCPフロー（または接続）の総数
  • ProcessedBytes
    • ロードバランサによって処理された合計バイト数。
• ResetCounts
  • TCPClientResetCount
    • クライアントからターゲットに送信されたリセット（RST）パケットの数。
  • TCPELBResetCount
    • ロードバランサによって生成されたリセット（RST）パケットの数。
  • TCPTargetResetCount
    • ターゲットからクライアントに送信されたリセット（RST）パケットの数。
• バックエンドの健全性
  • HealthyHostCount
    • 健康とみなされる標的の数。
  • UnHealthyHostCount
    • 健康でないとみなされる標的の数。
• フローログ
  • 特定のキャプチャウィンドウに対して、特定の5倍のネットワークフローをキャプチャします。
    • パケット
    • バイト
    • キャプチャウィンドウの開始と終了
    • アクション - Accepted または Rejected
    • ステータス
    • ログのステータス

価格

• NLBが稼働している時間または部分時間ごと、および時間あたりに使用されているロード・バランサ・キャパシティー・ユニット（Load Balancer Capacity Unit：LCU）の数が請求されます。
  • NLB 時間（または部分時間）あたり $0.0225
  • LCU 時間（または部分時間）あたり $0.005ドル
• 時間料金は CLB より 10％ 安く、データ処理料金は CLB および ALB よりも 25% 安い
• ロードバランサキャパシティユニット - TCP
  • LCUは、NLB がトラフィックを処理するディメンション（1時間以上の平均）を測定します。
  • 測定された3つの寸法は以下の通りである。
    • 新しい接続： 毎秒最大800の新しい接続
    • アクティブな接続： 最大100,000のアクティブな接続
    • 帯域幅：最大2.22 Mbps（1 GB /時）
  • その時間に最も高い使用率のディメンションにのみ課金されます

移行

• NLBに移行する
  • 移行は新しいNLBを作成し、ターゲットを登録し、DNSを更新して新しいCNAMEを指すようにするだけで簡単です
  • CLBからNLBへの移行ユーティリティ
    • https://github.com/aws/elastic-load-balancing-tools

どのロードバランサを選ぶべきですか？

• VPC の TCP の場合は、NLB を使用します。
• VPC の他のすべてのユースケースでは、ALB
• クラシックネットワーキングの場合、CLB を使用します

さいごに

ELB の Deep Dive セッションということで参加しました。内容的には ELB の概要をおさらいした感じになってしまいましたが、ひとまず re:Invent 1本目の記事をあげれてよかったです。これからバンバン書いていきます！

以上！大阪オフィスの丸毛（@marumo1981）でした！