【AWS ELB（Elastic Load Balancing）】

ELBは理解することが多くて大変。
実務にて、ECS, Fargate, CodePipelineをCloudFormationで構築しています。
ALBの理解も必要なので基本的なところから勉強し直しました。

なぜELB（Elastic Load Balancing）が必要？？

冗長化、可用性
- 高可用性：複数AZにある複数のターゲットの中から正常なターゲットにのみ振り分け可能
負荷分散、スケール
- スケーラブル：複数のEC2インスタンスやECSコンテナなどに負荷分散
  - ELB自体も負荷に応じてキャパシティを自動増減
  - ALBがスケールする時は、IPアドレスが変化する。
    - 負荷が高まってスケールすると、IPアドレスが増えることがある。
    - 自動でスケールする機能が確認できる。
    - くろかわさん　ありがとうございます!
  - ELBヘアクセスするときには必ずDNS名でおこなう。
- 従量課金で利用可能
- マネージドサービスなので管理が不要
- AWSの他のリソースとの連携が可能
  - CloudFormation, Auto Scaling ...etc

ELBの種類

ALB（Application Load Balancer）
NLB（Network Load Balancer）
CLB（Classic Load Balancer）

ELBの使い方

VPC内、AZに設置
- パブリックサブネットに指定する。
  - 主にALB。
  - （NLBをプライベートサブネットに配置するパターンもよくある。）
- AZごとに1つのサブネットを指定
- 可用性を高めるに、2つ以上のAZからサブネットを指定する。
ICMP Echo Request/Replyを許可すれば、pingにも応答する。
ALBには、セキュリティグループの指定が可能

ALB（ELB）の用語

リスナー
- クライアントからの処理を受ける機能
- トラフィックを受け付けるプロトコル（HTTP, HTTPSなど）とポート番号（1~65535）を設定
- トラフィックをターゲットグループへの接続用のプロトコルとポート番号などを設定
ターゲット
- トラフィックを転送するEC2インスタンスなどのリソースやエンドポイント
ターゲットの種類
- IPアドレス
- インスタンスID
- Lambda関数
ターゲットグループ
- EC2インスタンスなどのターゲットの集合
- ターゲットグループ内でリクエストは負荷分散される。
- インスタンス側：インスタンスで公開するポート、プロトコル、設定を含む。

※ ALBが使えなくなった場合、ターゲットグループを確認
　→ ヘルスチェックステータスを確認しよう。

ALBの高可用性と負荷分散ゾーンごとのフェイルオーバー

2段階での負荷分散
- DNSラウンドロビンで各AZ内のELB(ロードバランサーノード)に振り分け
- 負荷が均等になるようにバックエンドへのルーティングアルゴリズムで振り分け
  - ALB：ラウンドロビンルーティング
ALBはクロスゾーン負荷分散がデフォルトで有効になっている。
- リージョン内の複数AZに負荷分散が可能
  - 複数リージョンへの負荷分散にはRoute53を併用できる。
- AZごとにEC２インスタンスなどの数が違っていても、負荷を均等にできる。
ALBは同一インスタンスで複数ポートに負荷分散可能
- 同一インスタンス上で複数のコンテナサーバーを運用する時に有用
- ECSを利用する場合は、動的ポートマッピング機能を利用できる。
  - ECSのタスク(サービス)をターゲットグループに登録することで、各タスクに対して負荷分散
  - 各タスクに割り振られたECSクラスタ上のポートをターゲットグループに自動的に登録

ALB（ELB）のモニタリングログ

ヘルスチェック
- 正常なターゲットにのみトラフィックをルーティング
- 設定値に基づき、ターゲットに対してヘルスチェックを定期的に行い、正常なターゲットかを判定
- 正常判定が厳しすぎると、インスタンスが使えるまでに時間がかかる
- 異常判定が厳しすぎても、過負荷時に処理できるインスタンスを減らしてしまうことになる

ヘルスチェック設定

プロトコル（HealthCheckProtocol）
- ターゲットでヘルスチェックを実行するときに使用
  - Status200が返るのを確認（成功）
ポート（HealthCheckPort）
- ヘルスチェックを実行するときに使用
パス（HealthCheckPath）
- ヘルスチェックの送信先であるpingパス
- デフォルトは、/
タイムアウト時間
- ヘルスチェックを失敗と見なす、ターゲットからレスポンスがない時間
- 2〜120秒
正常のしきい値（HealthyThresholdCount）
- 異常なターゲットが正常と見なされるまでに必要なヘルスチェックの連続成功回数
非正常のしきい値（UnhealthyThresholdCount）
- ターゲットが異常と見なされるまでに必要なヘルスチェックの連続失敗回数
間隔
- 個々のターゲットのヘルスチェックの概算間隔

CloudWatchによって、メトリクスを６０秒間隔で監視可能
最短5分間隔でアクセスログを取得可能
　→　指定してS3バケットへ簡単にログを自動保管

ALB（ELB）のコネクション

無通信状態が続くとそのコネクションを自動で切断する
- ALBは、デフォルトではコネクションタイムアウト値は60秒
ALBのコネクションタイムアウト値は変更可能
- 1〜4000秒の間で設定可能
Connection Draining（登録解除の遅延）
- デフォルトで有効
- タイムアウト300秒
スティッキーセッション
- 同じユーザから来たリクエストを全て同じEC2インスタンスなどに送信
- デフォルトで無効
- アプリケーションでのセッション情報、一時ファイルなどを保持する構成に必要
- HTTP/HTTPSでのみ利用可能

※ EC2インスタンスなどの増減を柔軟にできるように、セッション情報などは別のDBサーバやキャッシュサーバに持たせるのが望ましい
　→　スティッキーセッションは不要になる。

ALB（ELB）のセキュリティ

SSL/TLSターミネーション
- ALB（ELB）側でSSL/TLS認証（基本的にはTLSプロトコルを使用）
- ALB（ELB）にTLSサーバ証明書をアタッチすることで、通信の暗号化・複合を担ってくれる。
  - ACM（AWS Certificate Manager）で作成すれば、無料利用可能
    - ACMと統合されているELB, CloudFront, API Gatewayのみ。
  - 証明書のリクエスト、管理、更新、プロビジョニングが容易に実行可能
  - 証明書は自動更新、失効の心配がない。

ALBの特徴!!　L7ロードバランサー

コンテンツベースのルーティング（高度なリクエストルーティング）
- パスベースのルーティング
  - リクエストURLのパスパターンに基づいたルーティング
  - パス部分のパターンでターゲットグループに振り分ける。
- ホストベースのルーティング
  - HTTPヘッダーのHostフィールドに基づいてクライアントのリクエストをルーティング
  - 同一のロードバランサーから複数のドメインへのルーティングが可能
  - ホスト名のパターンでターゲットグループに振り分ける。
- HTTPヘッダーベースのルーティング
  - 各リクエストのHTTPヘッダーに基づいたルーティング
  - 例）Version1用のサーバーとVersion2用のサーバーに振り分ける。
- HTTPメソッドベースのルーティング
  - 標準またはカスタムのHTTPメソッドに基づいてクライアントのリクエストをルーティング
- クエリ文字列パラメータベースのルーティング
  - キーと値のペアまたはクエリストリングの値に基づいたルーティング
  - 例）Chrome用サーバーとSafari用サーバーに振り分ける。
- 送信元IPアドレスCIDRベースのルーティング
  - リクエスト元のソースIPアドレスCIDRに基づいてクライアントのリクエストをルーティング

ALBとAWS WAFの連携

以下の条件を利用して、ALBを保護可能
- リクエストレートによるアクセス権限
- 特定のIPアドレスや地域からのアクセスを制限
- クロスサイトスクリプティングやSQLインジェクションから保護
- HTTPヘッダー、HTTP本文、URI文字列に対するサイズ制約や正規表現でのマッチング

オンプレでWAFを導入するとコストがかかるが、クラウドだとスモールスタートできてコストメリットがある！

参考

おわりに。

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com

過去記事

AWS ELB（ALB, NLB）の違い
転職活動中にロードバランサーについて聞かれて、こんなものを書いていた。

AWS ELB（Elastic Load Balancing）