Elastic Load Balancing(ELB)
# Elastic Load Balancing(ELB)
https://d1.awsstatic.com/webinars/jp/pdf/services/20191029_AWS-Blackbelt_ELB.pdf
## ELB の基本
- スケーラブル
- 高い可用性
- マネーイドサービス
- 豊富な連携機能
- ELBの種類
- ALB
- L7
- NLB
- L4
- CLB
- 現在は非推奨(特段の理由がなければ使わない方がいい)
- 対応プロトコル
- スケーラブル
- ALB,CLBがスケールアップする際にはIPが変更される
- 構成
- VPC内(AZ)に配置。
- AZごとに一つのサブネットを指定
- 使い方
## ELBの機能
- 高可用性と負荷分散
- 複数AZに分散
- ルーティングアルゴリズムはELBの種類によって違う
- クロスゾーン負荷分散
- ALBとCLBはデフォルトで有効
- 同一インスタンスの別ポートに負荷分散
- スケールが間に合わない場合は一時的に503を返す
- モニタ・ロギング
- ヘルスチェック
- ヘルスチェックを厳しくすると、ELB側から置き換えするように命令されてしまい、パフォーマンスが悪化する可能性がある。
- モニタリング
- CloudWatch で60秒間隔で監視可能
- アクセスログの間隔
- 5分間隔で取得可能
- 指定したS3バケットにログを出力可能
- コネクション
- 無通信状態が続くとコネクションを自動で切断する
- Connection Draining
- スティッキータセッション
- セキュリティ
## ALB の特徴と固有の機能
- 基本的な特徴
- コンポーネント
- リスナー: リッスンポートとプロトコル
- ルール: パスベースでどこにルーティングするか
- ターゲット(またはターゲットグループ): どこのリソースに対してルーティングするか
## NLBの特徴と固有の機能
- L4のバランサー
- 固定IPアドレスを持つ
- 暖気なしで急激なスパイクに対応可能
- AWS PrivateLinkのサポート
- セキュリティグループの設定がない
- 単一AZ構成も可能
- Source IP/Port がターゲットまで保持
- IP target やPrivateLink の場合はNLBからの通信となる(それを避けたい場合はDirect Connect)
## CLBを選択する場合
- 基本的にはALB/NLBで十分
- アプリケーション生成のクッキーを利用したスティッキーセッション
- カスタムセキュリティポリシー
- TCPおよびSSLリスナーのサポート
- EC2-Classicのサポート
## 他サービスとの連携
- Auto Scaling との連携
- インスタンスの増減に対応
- ECSとの連携
- ECSのタスクをターゲットグループに登録できる
- NLBにはセキュリティグループの設定ができないためECSのコンテナインスタンス側でセキュリティグループの設定を行う。ポートが動的に設定されるので注意が必要
- AWS WAFとの連携
- ALBが連携可能
- Global Accelerator との連携
- Lambda 関数をターゲットにする
## 雑感
SSL/TLS TerminatingやパスベースのルーティングやAuto Scaling との連携などで業務でお世話になっている。L7のLBといえばNginx などがあるが、マネージドで行えて、さらにAWSの他リソースとの連携がされているのでAWSを利用していて、LBどうするかということになったらELBを利用するというのが第一の選択肢になるだろう。
基本的にはALBが選択され、用途に合わせてNLBを選択するという感じ。リフトアンドシフトする場合アプリケーションの機構上、CLBを選択する場合があるかもしれない。
また2019.08のAWS障害もあるので(https://aws.amazon.com/jp/message/56489/)ALBに必要な2AZを満たしていてもELBがエラーを返す可能性はある。その場合は3AZにして1AZ切り離すことなどが解決方法として提示されていたりしている。
ELBの裏側にどのようなターゲットがおかれ、スケールした時にどのように伝えて解決しているかや、ルーティングについては実際に触わってみるのが良さそう。