本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。

最新の情報については、AWS 公式ドキュメントをご参照ください。

elb

Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。さらに、登録されているターゲットの状態をモニタリングし、正常なターゲットにのみトラフィックをルーティングします。

【AWS Black Belt Online Seminar】Elastic Load Balancing (ELB)(YouTube)(1:08:05)

blackbelt_elb

【AWS Black Belt Online Seminar】Gateway Load Balancer(YouTube)(54:06)

blackbelt_glb

Elastic Load Balancing 概要

Elastic Load Balancing ドキュメント

Elastic Load Balancing のよくある質問

Elastic Load Balancing 料金

CLB:Classic Load Balancer

AWS ドキュメント > Classic Load Balancer とは?

ALB:Application Load Balancer

AWS ドキュメント > Application Load Balancer とは?

NLB:Network Load Balancer

AWS ドキュメント > Network Load Balancer とは?

GLB:Gateway Load Balancer

AWS ドキュメント > Gateway Load Balancer とは?

Elastic Load Balancing 料金表

料金は、各ロードバランサーが起動している時間と、ロードバランサーキャパシティーユニット (LCU) の使用時間で課金されます。

ALB は LCU、NLB は NLCU、GLB は GLCU と呼ばれるメトリクスがあります。

これは、新しい接続、アクティブ接続、処理タイプ、ルール評価のうち、消費量が最大のリソースで定義されます。

1 つの LCU には次のものが含まれます。

詳しい計算方法は、Elastic Load Balancing 料金表の料金の例を参照してください。

AWS ドキュメント > Elastic Load Balancing > ロードバランサーのサブネット

ELB を配置するサブネットの CIDR は最小で 「27」が必要であり、8 個以上の IP アドレスの空きが必要です。

ELB_CIDR

AWS ドキュメント > Application Load Balancer のスティッキーセッション

AWS ドキュメント > Network Load Balancer > スティッキーセッション

ロードバランサーが生成した Cookie（AWSALB）を使用して同じターゲットにルーティングする機能です。クロスオリジンリソース共有 (CORS) リクエストの場合、「AWSALBCORS」を生成します。 ロードバランサーが生成する AWSALB は、ローテーションキーを使用して暗号化されており、復号することは出来ません。また、中身が同じ内容なのかも分かりません。

ロードバランサーが生成する Cookie の他に、アプリケーションによって生成する Cookie を指定することも可能です。Cookie 名は自由に指定することができますが、ロードバランサーが予約している名称は使用できません（AWSALB、AWSALBAPP、または AWSALBTG など）

可能であれば、セッション管理などは、Amazon ElastiCache や Amazon Aurora などのデータベースで保持しておくほうが ELB が振り分けるノードに障害があった場合にも影響を受けにくくなります。

複数 AZ に跨るノードに対しても均等にトラフィックを分散するようにできるオプションです。

どういうことかというと、 ELB が２つの AZ に配置されている場合は、ラウンドロビンルーティングによって、それぞれの ELB に 50%のトラフィックが分散されます。 次のようにノードが等しくなるような構成の場合、それぞれのノードは 25%のトラフィックを処理します。

elb_normal

ELB 配下にあるノードが異なっている場合には以下のようにトラフィックが偏ります。 この例の場合は、1 台のノードが 50%のトラフィックを処理している状態になります。

xz_off_1

実際は、各 AZ に 1 台ずつ ELB が存在し、ELB に対してはラウンドロビンルーティングによって、50％ずつに振り分けられます。ELB は、自身と同じ AZ に存在するノードのみに振り分けを行うことからこのような偏りが発生します。

xz_off_2

これを解消し、以下のように均等にトラフィックを分散させるためのオプションが、クロースゾーン負荷分散です。クロースゾーン負荷分散が有効になっている場合、全てのノードの数に応じて均等に分散されます。ALB ではデフォルトで有効になっているため、意識しないで利用しています。

xz_on_1

実際は、以下のようになっており、各 ELB が AZ を跨いだノードに対して分散させるためトラフィックが均等になります。

xz_on_2

ただし、赤色の線は、AZ を跨いだ通信となっており、データ容量で課金される部分です。 この課金有無は、ELB の種類で異なっています。 「よくある質問」にも以下のように記載があり、ALB のみ課金されません。

xz_faq

ELB の配下のノードを切り離す場合、いきなり切り離されると、ノードで実行中だった場合にアプリケーション側でエラーが出てしまいます。 そのため、切り離し対象のノードへのリクエストが終わるまで一定時間切り離しを待機してくれる機能です。 この機能は、デフォルトで有効化されています。 待機時間のデフォルトで 300 秒となっており、最大で 3,600 秒まで設定できます。 指定された待機時間に達した場合は、強制的に切り離しが実施されます。

ELB のアクセスログは、S3 に出力することができます。アクセスログは 5 分ごとに出力されます。

出力されるログファイルのキーは、次のようになっています。

bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_app.load-balancer-id_end-time_ip-address_random-string.log.gz

ロードバランサーのアクセスログを出力する AWS アカウント ID はリージョンで異なるため、S3 バケットのバケットポリシーを設定する場合は注意が必要です。 リージョンとアカウント ID の対応は次のドキュメントを参照します。

東京リージョンの場合は、アカウント ID「582318560864」を指定して、次のように記述します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::582318560864:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
    }
  ]
}

AWS ドキュメント > S3 バケットにポリシーをアタッチする

出力されたアクセスログは、Amazon Athena を利用することで簡単に分析することができます。

分析のためのテーブル作成やクエリについては、下記ドキュメントで説明があります。

AWS ドキュメント > Application Load Balancer ログのクエリ

AWS ドキュメント > Network Load Balancer のログのクエリ

AWS ドキュメント > Classic Load Balancer ログのクエリ