■ はじめに
* AWSのロードバランササービスである ELB (Elastic Load Balancing) のALB (Application Load Balancer)を扱う
目次
【１】ELB (Elastic Load Balancing) 【２】ELBの種類 １）ALB / CLB との比較 【３】ALB (Application Load Balancer) １）ターゲットグループの作成 ２）ターゲットグループの設定 ３）スティッキーセッション の設定 ４）アクセスログ ５）料金 ６）Cloud Watchでの確認/監視
【１】ELB (Elastic Load Balancing)
* Elastic : しなやかな、融通性のある * ロードバランサ => 複数の EC2 インスタンスを、自動的に負荷分散してくれる
【２】ELBの種類
| 略語 | 正式名 | Memo |
|---|---|---|
| ALB | Application Load Balancer | 今回のテーマ |
| NLB | Network Load Balancer | |
| GLB | Gateway Load Balancer | |
| CLB | Classic Load Balancer | すでにレガシーで非推奨 |
１）ALB / CLB との比較
* 以下の比較を見ると、ALBでいいじゃんってなるが、スティッキーセッション の場合、 「アプリケーションによって生成された Cookie の維持を有効化」がなくなっている => 個人的には困る。 * まずは、「ALB」を使ってみて、様子を見るって感じでいいのかと
| 項目 | 結果 | 補足 |
|---|---|---|
| 機能面 | ALB の方が豊富 | パスベースのルーティング |
| 料金 | ALB の方が若干安い |
機能面に関するドキュメント
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
料金に関するドキュメント
https://aws.amazon.com/jp/elasticloadbalancing/classicloadbalancer/pricing/
https://aws.amazon.com/jp/elasticloadbalancing/applicationloadbalancer/pricing/
【３】ALB (Application Load Balancer)
* 詳細は以下の公式ページを参照。
https://aws.amazon.com/jp/elasticloadbalancing/applicationloadbalancer/
動画
* 古いけど、大体の流れが把握できる
http://dotinstall.com/lessons/basic_aws/9514
１）ターゲットグループの作成
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/create-target-group.html
２）ターゲットグループの設定
* EC2をロードバランサに紐付ける
[1] AWSログイン後に 「ロードバランシング」配下の[ターゲットグループ]を選択 [2] [ターゲット]-[編集]を選択 [3] 該当の対象EC2インスタンスをチェックを付け、「登録済みに追加」ボタン押下 [4] 「保存」ボタン押下
３）スティッキーセッション の設定
[1] AWSログイン後に [EC2]を選択 [2] [ロードバランサ]-[説明]-[属性の説明]を選択 [3] 「ロードバランサーによって生成されたCookieの維持を有効か」を選択し、「保存」 => 通信ログから、クッキー値「AWSLAB」が付加されることが確認できる
４）アクセスログ
* デフォルトは無効（AWSマネジメントコンソールから簡単に有効化可能)
５）料金
アクセスログに対する追加料金はありません。 Amazon S3 のストレージコストは発生しますが、 Amazon S3 にログファイルを送信するために Elastic Load Balancing が使用する帯域については料金は発生しません。 ストレージコストの詳細については、Amazon S3 料金表を参照してください。
６）Cloud Watchでの確認/監視
* HealthyHostCount/UnHealthyHostCountなどで確認及び監視可能
https://qiita.com/mechamogera/items/7898331efafc973f9ed8
https://dev.classmethod.jp/cloud/aws/elb-and-cloudwatch-metrics-in-depth/
https://dev.classmethod.jp/cloud/aws/elb-using-cloudwatch-alarm/
７）使用上の注意
[1] ヘルスチェックについて
* ロードバランサに紐付けた後に、ロードバランサは対象のEC2に対して、 一定時間、リクエストを送り続け、EC2から コード 200 を返せば、正常と見なされる => ヘルスチェック通らないと、割り振られない(502 Bad Gatewayなど）
access.log より
... "-" "ELB-HealthChecker/2.0" "-"
解決策
トップページに index.html（空ファイルでもOK） など を作成しておく必要がある
[2] エフェメラル ポートについて
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports
より抜粋 ～～～～～～～ Elastic Load Balancing が送信元のリクエストは、ポート 1024～65535 を使用します ～～～～～～～
[3] その他のトラブルシューティング
* 以下の公式サイト参照
* 以下の関連記事を参照のこと。
ELB に関するトラブル「HTTP 502: Bad Gateway」が表示
https://dk521123.hatenablog.com/entry/2018/01/13/212430
参考文献
http://qiita.com/papix/items/2b9949a61924c02628c9
関連記事
ELB / ALB ～ パスベースのルーティング ～
https://dk521123.hatenablog.com/entry/2017/02/27/234919
ELB / ALB ～ Auto Scaling ～
https://dk521123.hatenablog.com/entry/2019/10/19/212241
ELB / ALB に関するトラブル「HTTP 502: Bad Gateway」が表示
https://dk521123.hatenablog.com/entry/2018/01/13/212430
