AWS Blackbeltの内容をメモしました。
ELBの種類
互換性などの理由がなければALB, NLBを選ぶのが良い。
- ALB
- NLB
- CLB
ELBの全体イメージ
- xxx.elb.amazonaws.com（DNS名）
- ALBはスケールするとIPアドレス変わるのでDNS名に対してアクセスする！
- リスナー
- ロードバランサがlistenするプロトコルとポート番号
- ロードバランサからターゲットへの接続用プロトコルとポート番号
- ターゲット
- LBが通信を転送する先のEC2など
ELBの使い方
- ELB自体をVPC内、AZ内に配置
- ALB, CLBに任意のセキュリティグループを指定可能
- NLBはセキュリティグループと関連付けられない
- ICMP Echo Request/Replyを許可すれば、ELBがping応答
- バックエンドのEC2インスタンスはELBからのみリクエストを受け付ける設定推奨
- リスナー ポート番号(1～65535)
- ターゲットの種類
- インスタンスID
- IPアドレスでターゲットを指定（CLB以外）
- Lambda関数をターゲットに指定（ALBのみ）
- ELBへは基本DNS名でアクセス
- 独自ドメインを利用する場合
- Route53を使用する場合はエイリアスレコードで登録（CNAMEも可能）
- Route53以外ではCNAMEで登録
- Zone Apexの場合
- DNSサーバのCNAME設定不可（理由はよくわからん）
- Route 53のエイリアスレコードで設定可能
- 独自ドメインを利用する場合
ELBの基本機能
高可用性と負荷分散
複数AZに分散
2段階での負荷分散
- DNSラウンドロビンで各AZ内のELBに振り分け
- 負荷が均等になるようにバックエンドのEC2にそれぞれのルーティングアルゴリズムで振り分け
- ALB ラウンドロビンルーティング
- ELB フローハッシュアルゴリズムによるルーティング
- CLB
- TCP ラウンドロビン
- HTTP/HTTPS least outstanding
AZとバックエンドキャパシティ
クロスゾーン負荷分散 複数AZで負荷が均等にできる
- ALB デフォルトで有効
- NLB デフォルト無効
同一インスタンスで複数ポートに負荷分散可能
コンテナを用いる際には、同一インスタンス上で複数のコンテナを運用する必要があるので有用
IPアドレスをターゲットに設定
- ALB/NLBが対応
- オンプレミスのサーバをIPターゲットに設定できる
ELB自体のスケーリング
ELBは負荷に応じて自動スケール
- ALB/CLBはリクエストが急増してスケーリングが間に合わない場合、HTTP 503を返す
- 回避方法は事前にALB/LCBをスケールさせる
- Pre-Warming（暖気）申請をサポートで行う
- 自前で負荷をかけてすけーるさせておく
- NLBは暖気不要。突発的なリクエストもさばける。
モニタリング・ログ
ヘルスチェック
- 正常なターゲットにのみトラフィックをルーティング
- 設定値に基づきターゲットに対してヘルスチェックを行い、正常なターゲットかを判定する
運用のモニタリング
CloudWatchによりメトリクスを60秒間隔で監視可能
メトリクスの例
- Healthyhostcount 正常なバックエンドのホスト数
- UnHealthyhostcount 異常なバックエンドのホスト数
アクセスログの記録
- 最短5分間隔でELBのアクセスログ取得可能
- 指定したS3バケットにかんたんにログを自動補完
- ELBの種類によってアクセスログの出力フィールドも異なる
コネクションについて
ELBのコネクションタイムアウト
- 無通信状態が続くとそのコネクションを自動切断
- ALB/CLBのコネクションタイムアウト値は変更可能
- NLBは固定
Connection Draining（登録解除の遅延）
- スケールインや異常が発生したときにEC2からELBが登録解除したり、ヘルスチェックが失敗したときに新規リクエストの割り振りは中止。処理中のリクエストが終わるまで一定期間待つ。
- （便利な機能だと思った）
- デフォルトで有効
スティッキーセッション
- ※注意事項 EC2を増減させやすいようにセッション情報はDBやキャッシュなどに置く方が推奨構成。
- 同じユーザから来たリクエストをすべて同じEC2インスタンスに送信
- HTTP/HTTPSでのみ利用可能
- スティッキーセッションの有効期限
- LBによって生成されるクッキー（ALB/CLB対応）
- アプリ生成のクッキー（CLBのみ）
セキュリティ
SSL/TLS Termination
ELB側でSSL/TLS認証ができる
通信パターン。
- ELBでSSL Terminationし、バックエンドとはSSLなし（このパターンが推奨）
- バックエンドのEC2でSSL処理せずに済むため負荷をオフロードできる
- 例. HTTPS → HTTP
- ELBでSSL Terminationし、バックエンドとは別途SSLなし
- 例. HTTPS → HTTPS
- SSLをバイパスしてバックエンドにTCPで送信
- クライアント証明書認証などを利用するためにTCPとして扱う
- 例. TCP→TCP
事前定義されたセキュリティポリシー
SSL/TLS利用時には事前定義されたセキュリティポリシーを利用する
HTTPS利用時のTLSサーバ証明書
AWS Certificate Managerを使用すれば、設定用意
- 無料で証明書を利用可能
- ELBに対する証明書の設定がかんたん。
- 証明書の更新が自動。失効の心配がない。
- ドメイン認証タイプの証明書のみ対応。上位の証明書はサードパーティ。
SNIでの複数TLSスマートセレクション
- 複数のTLS証明書を1つのALB/NLBのListenerに設定可能
- ALBごとに25使える
ALBの特徴と固有の機能
- ルール リクエストがどのように転送されるかを条件とアクションで定義
- ターゲットグループ ターゲットの集合。
- 例. URIベースの分散が可能
- パスベースのルーティング
- HTTPヘッダーベース
- HTTPメソッドベース
- ホストベース
- etc・・・
- 例. URIベースの分散が可能
ALBのコンテンツベースルーティング
if(条件)→THEN(アクション）
-
パスベース
- example.com/order, example.com/products
-
ホストベース
- order.example.com, products.example.com
-
HTTPヘッダーベース
- User-Agent="Chrome", User-Agent="Safari"
-
クエリ文字列ベースのルーティング
-
アクション
- 転送アクション
- リダイレクト
- 固定レスポンスアクション
- Cognito認証アクション(HTTPSリスナーのみ）
- OIDC認証アクション(HTTPSリスナーのみ）
ALBのユーザー認証機能
最初にALBにアクセスするとCognitoやOIDC IdPの認証画面にリダイレクト
ALB利用時のIPアドレス取得
X-FOrwared-FOrヘッダーを使用して可能
NLBの機能
特徴と機能
- TCP(L4)のバランサとして機能
- 固定IP
- Internet-facing, InternalともにIPアドレスが固定
- NLB作成時に自動割当されたIPもしくは、EIP
- 送信元IPアドレスの保持
- Targetはクライアントと直接通信しているかのようにみえる
- 行きも帰りもNLBを通っている
- TargetのセキュリティグループでクライアントIPの接続を許可する必要あり。
- 暖気なし
- VPCエンドポイント(Private linkのサポート）
CLB
- EC2 Classic
- アプリ生成のクッキーを使用
- カスタムセキュリティポリシー
ELBと他のサービス連携
Auto Scalingとの連携
動的ポートマッピング（マニアックな内容）
- ECSコンテナインスタンス側でセキュリティグループ設定
- ポートの範囲を意識する必要がある。
ALBとAWS WAFの連携
- 特定のiPアドレス 地域からのアクセス制限
- リクエストレートによるアクセス制限
- 1ユーザー1分間あたりxxリクエストまでの制限とか。
- クロスサイトスクリプティングやSQLインジェクションからの保護
Global Accelerator
- ユーザーは近いエッジロケーションからAmazon Global Networkを経由して最も近いリージョンにアクセス可能
Lambda関数をターゲットにする
ALBのみLambdaをターゲットにするリスナールールが設定可能
所感
ElBの全体像について学ぶことができ有意義な講演だったように思う。