メインコンテンツに移動

builders.flash

AWS グラレコ解説

アプリケーションへのトラフィックを効率的に負荷分散。 Application Load Balancer をグラレコで解説

2022-11-02 | Author : 米倉 裕基 (監修 : 荒木 靖宏)

はじめに

builders.flash 読者のみなさん、こんにちは ! テクニカルライターの米倉裕基と申します。

本記事では、ネットワークトラフィックをあらかじめ指定したルールに応じて、複数のサーバーに振り分けて負荷分散するロードバランシングサービスについて取り上げます。現在、AWS が提供するロードバランシングサービスは Elastic Load Balancing があり、本記事では特に Elastic Load Balancing が提供するロードバランサーの 1 つである Application Load Balancer (以下、ALB) を中心に、ロードバランサーがアプリケーションの裏側で果たす役割について説明します。

※ 本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。awsgeek.com は 、Jerry Hargrove 氏が運営しているサイトです。


X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 
今すぐ登録 »

目次

ALB の主な機能や特徴を、以下の項目に分けてご説明します。

  • Elastic Load Balancing

  • 高可用性

  • DDoS 攻撃対策

  • コンテンツベースのルーティング

  • リスナーとターゲット

  • 処理フロー

  • 料金体系

それでは、項目ごとに詳しく見ていきましょう。

Elastic Load Balancing

AWS では現在、4 種類のロードバランサーを提供しています。これらのロードバランサーを総称して、Elastic Load Balancing (以下、ELB) と呼びます。ここでは、ELB が提供するロードバランサーの種類と特徴を説明します。

ロードバランサーの動作環境

ELB が提供する 4 種類のロードバランサーは、それぞれ OSI 参照モデルにおけるレイヤーやプロトコルなど、異なる環境で動作します。ユーザーは負荷分散を行いたいプロトコルなどの要件に応じて、最適なロードバランサーを選択できます。

OSI 参照モデルとは:

国際標準化機構 (ISO) で策定されたネットワーク構造を機能別に階層化した標準モデルです。

物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層 の 7 つの階層でネットワーク構造を定義しています。ELB が提供する 4 つのロードバランサーは、それぞれ異なるレイヤーで動作します。

Diagram comparing AWS Elastic Load Balancing types: Classic Load Balancer (CLB), Application Load Balancer (ALB), and Network Load Balancer (NLB), including supported protocols, layers, and VPC compatibility.

ロードバランサーの種類と特徴

4 種類のロードバランサーの機能と特徴は以下のとおりです。一般的なウェブサイトやウェブアプリケーションの負荷分散には主に ALB が利用されますが、高い負荷が予想される場合は NLB を利用するなど要件に応じて自由に選択できます。

  • Classic Load Balancer (CLB)
    トランスポート層 (レイヤー 4) およびアプリケーション層 (レイヤー 7) で動作します。前世代のロードバランサーのため、古いアーキテクチャを利用するなど特別な理由がない限り ALB または NLB の利用が推奨されます。

  • Application Load Balancer (ALB)
    アプリケーション層 (レイヤー 7) で動作し、HTTP または HTTPS トラフィックを負荷分散します。マイクロサービスやコンテナを含む、さまざまなアプリケーションに対してトラフィックのルーティング機能を提供します。

  • Network Load Balancer (NLB)
    トランスポート層 (レイヤー 4) で動作し、TCP、UDP または TLS トラフィックの負荷分散に利用します。大規模なトラフィックを高速に負荷分散できます。

  • Gateway Load Balancer (GLB)
    ネットワーク層 (レイヤー 3) で動作します。AWS 上で提供されるサードパーティのセキュリティ製品のデプロイ、スケール、管理を行います。GLB は、2019 年にサービスを開始した ELB が提供する最も新しいロードバランサーです。

ロードバランサーごとの機能や特徴について詳しくは、「製品の比較」をご覧ください。

高可用性

AWS が提供するロードバランサーは、受信トラフィックを複数のアベイラビリティーゾーン (AZ) にある Amazon EC2 インスタンスに分散することで、月間 99.99% 以上の高可用性を実現できます。ユーザーからのアクセスを複数のターゲット (トラフィックの転送先) に自動で振り分けることで、トラフィックが急増 (スパイク) した場合でも安定したシステムの稼働が可能になります。

また、物理的に離れた AZ にターゲットを分散することで、特定の AZ で災害などの障害が発生した場合でも、残りのターゲットに負荷を分散することで、サービスを停止することなくアプリケーションの稼働を継続することが可能です。

ルーティングアルゴリズム

ELB では、受信トラフィックを効率的に負荷分散するために、デフォルトでラウンドロビンと呼ばれるルーティングアルゴリズムが使用されます。

ラウンドロビンは、各ターゲットにトラフィックを均等に振り分けるルーティングアルゴリズムで、ターゲットの処理能力に差がない場合に適しています。ターゲットの処理能力に差がある場合は、最小のターゲットに基づいて未処理のリクエストのルーティングをリバランスする最小の未処理のリクエストを選択することも可能です。

ELB のルーティングアルゴリズムについて詳しくは、「ルーティングアルゴリズム」をご覧ください。

A high availability architecture diagram showing AWS Elastic Load Balancing distributing traffic to multiple Elastic Cloud Compute (EC2) instances, with labeling in Japanese and English, illustrating round-robin traffic distribution among servers.

DDoS 攻撃対策

ウェブアプリケーションは、常にさまざまな外部からの脅威にさらされています。そのため、アプリケーションを構成するインフラは、あらかじめあらゆる種類の攻撃に備えておく必要があります。

ロードバランサーの重要な役割の一つは、サーバーへの過剰なアクセスを的確に分散させることで、DDoS 攻撃に代表される物量的なアクセス攻撃に対する耐久性を提供することです。

DDoS 攻撃とは、複数のコンピューターが同時に特定のウェブサイトやサーバーにアクセスしたり、データを送信することで、意図的にサーバーに過重な負荷をかけるサイバー攻撃です。

ALB を使うことで、DDoS 攻撃による異常なトラフィック増大 (スパイク) に対しても効率的に負荷分散し、アプリケーションに耐久性を持たせることができます。

ALB を Amazon VPC 内に配置することで、プライベート IP アドレスを使用してターゲットにトラフィックをルーティングする内部ロードバランサーとして利用することもできます。この場合、各ターゲットは直接外部のインターネットと接続していないため、モニタリングやヘルスチェックで異常なトラフィックを見つけた際、パブリックサブネット内でルーティングを遮断するなどの対策が可能です。

また、ALB はファイアウォールサービス「AWS WAF」と緊密に連携しており、AWS WAF で作成したウェブ ACL を ALB に割り当てることで、DDoS 攻撃を含むさまざまなネットワーク攻撃からアプリケーションを保護することができます。

その他 DDoS 攻撃に対して耐久性を持つアーキテクチャについて詳しくは、ホワイトペーパー「AWS Best Practices for DDoS Resiliency (英語のみ)」をご覧ください。

A network diagram in Japanese illustrating AWS DDoS protection within a Virtual Private Cloud (VPC), showing how SYN flood and web traffic are handled between public and private subnets.

コンテンツベースのルーティング

ALB の代表的な機能として、コンテンツベースのルーティングが挙げられます。

コンテンツベースのルーティングは、リクエストの内容 (コンテンツ) に応じて、トラフィックの転送先を振り分けるルーティング方式です。たとえば、リクエスト URL に含まれるパスやホスト名に応じて、トラフィックを複数の転送先に振り分けることができます。

前世代のロードバランサーである CLB では、指定したプロトコルのリクエストを単一のターゲットに転送するのみで、リクエストの内容に応じて複数のターゲットに振り分ける高度なルーティングはできませんでした。これに対し、ALB は 1 つのロードバランサーで複数のターゲットにトラフィックを振り分けることができるため、サーバーレスやコンテナベースアプリケーションのような、複数のマイクロサービスを組み合わせたモダンなアーキテクチャを持つアプリケーションの負荷分散に適しています。

A hand-drawn style diagram in Japanese illustrating content-based routing using Amazon Load Balancer (ALB). The diagram shows users accessing different applications (APP1, APP2, APP3) on multiple hosts based on URL paths, with labels and routing paths annotated in Japanese.

リスナールールの条件

ALB では、パスやホスト名などリクエスト URL に基づくルーティング以外にも、さまざまなリスナールールの条件を指定できます。また、HTTP メソッドベースおよび IP アドレスベースのルーティング以外の条件では、ワイルドカード (* と ?) を使った値を使用できます。

リスナールールの条件

内容

パスベースのルーティング

リクエスト URL のパスパターン (例:/img/*/pics) に基づいてルーティングを行う。

ホストベースのルーティング

リクエスト URL のホスト名 (例:*.example.com) に基づいてルーティングをする。

HTTP ヘッダーベースのルーティング

リクエストの HTTP ヘッダー (例:*Chrome*) に基づいてルーティングする。

HTTP メソッドベースのルーティング

リクエストの HTTP リクエストメソッド (例:CUSTOM-METHOD) に基づいてルーティングする。

クエリ文字列パラメータベースのルーティング

クエリ文字列の条件を使用して、キー/値 のペア (例:version=v1) またはクエリ文字列 (例:*example*) 内の値に基づいてリクエストをルーティングする。

送信元 IP アドレスベースのルーティング

リクエストの送信元 IP アドレス (例:192.0.2.0/24) に基づいてリクエストをルーティングする。

ALB が提供するリスナールールについて詳しくは、「ルールの条件のタイプ」をご覧ください。

リスナーとターゲット

コンテンツベースのルーティングを実現するリスナールールは、リスナーという機能に設定します。リスナーは、ALB が受信するトラフィックを常時監視し、プロトコルとポート、およびリスナールールの条件を満たす場合は、指定した転送アクションを行います。

トラフィックは対象のターゲットに直接転送される訳ではなく、一度ターゲットグループへ転送され、ターゲットグループから対象のターゲットへルーティングされます。

ALB のターゲットグループについて詳しくは、「Application Load Balancer のターゲットグループ」をご覧ください。

A hand-drawn diagram in Japanese explaining the relationship between listeners and targets in AWS Application Load Balancer (ALB), including protocols, ports, rules, SSL certificates, and supported targets such as EC2, Lambda, and IP addresses.

ALB のコンポーネント

上記のとおり ALB の主なコンポーネントは、リスナー、リスナールール、ターゲット、ターゲットグループの 4 つで構成されています。各コンポーネントの役割は以下のとおりです。

コンポーネント

役割

リスナー

ロードバランサーが監視 (リッスン) するプロトコルやポート、リスナールールを設定する。

リスナールール

トラフィックを転送する条件と、転送アクションを定義する。

ターゲット

トラフィックの最終的な転送先。設定可能なターゲットの種類は、EC2 インスタンス、Lambda 関数、および IP アドレスの 3 種類。なお、パブリックにルーティングできる IP アドレスは使用できない。

ターゲットグループ

1 つ以上のターゲットをまとめたグループ。リスナールールでは、このターゲットグループをトラフィックの転送先として指定する。トラフィックは、ターゲットグループから最終的に対象のターゲットへルーティングされる。

ターゲットとしての Lambda 関数

2018 年 11 月以降、EC2 インスタンスや IP アドレスに加えて、Lambda 関数を ALB のターゲットとして選択できるようになりました。これにより、ALB へのトラフィックをトリガーにして直接 Lambda 関数を実行できます。また、ALB のコンテンツベースのルーティング機能を使って、リクエストの内容に応じて複数の Lambda 関数にトラフィックを振り分けることができるため、複雑なサーバーレスアプリケーションを簡単に構築できるようになります。

ALB のターゲットとして Lambda 関数を登録する方法について詳しくは、「ターゲットとしての Lambda 関数」をご覧ください。

SSL/TLS サーバー証明書

ALB では、HTTP と HTTPS の 2 つのプロトコルをサポートしています。HTTPS リスナーを使用する場合は、ロードバランサーに SSL/TLS サーバー証明書を少なくとも 1 つデプロイする必要があります。SSL/TLS サーバー証明書は、AWS Certificate Manager(ACM) で作成できるほか、AWS Identity and Access Management (IAM) にアップロードした証明書や独自の証明書をインポートして利用することもできます。

また、ALB は Server Name Indication (SNI) をサポートしており、複数の SSL/TLS サーバー証明書を 1 台のロードバランサーに紐付けることが可能です。SNI を利用することで、ドメインごとに異なるサーバー証明書をデプロイできるため、単一のサーバーで複数のドメインを含むアプリケーションであっても、簡単にセキュアな HTTPS 通信を導入することができます。

ALB にデプロイする SSL/TLS サーバー証明書について詳しくは、「SSL 証明書」をご覧ください。

処理フロー

これまでに紹介した ALB の各種機能をもとに、ALB がクライアントからのリクエストを受け取った後の一連の処理フローを見ていきます。

以下の手順では、ALB に HTTPS プロトコルのリスナーを追加し、リクエストパスに /API が含まれる場合に指定したターゲットグループへ転送するリスナールールを指定した場合を想定します。

  1. ALB が接続リクエスト (ここでは、https://www.abc.com/api へのアクセス) を受け取る。

  2. 接続リクエストが、あらかじめリスナーに設定したプロトコルとポート (ここでは、HTTPS: 443) に一致していることをチェックする。

  3. 接続リクエストが、リスナールールの条件 (ここでは、リクエストパスに /API が含まれる) に一致していることをチェックする。

  4. 接続リクエストをターゲットグループに転送する。

上記は、あらかじめ指定したパス条件に従ってターゲットグループへ転送する比較的シンプルな処理フローの例です。

リスナールールは複数追加することができ、それぞれのルールに優先順位を設定することもできます。図内の例では、第一条件であるリクエストパスに /AUTH を含む条件には一致せず、第二条件の /API を含む条件に一致しています。

また、リスナールールの条件に一致した際のアクションについても、ターゲットグループへの転送だけでなく、特定の URL へのリダイレクトや、固定レスポンスの返却など複数のアクションを選択できるため、上記の手順よりもさらに複雑な処理フローを設定することが可能です。

ALB のリスナールールについて詳しくは、「Application Load Balancer のリスナールール」をご覧ください。

A diagram illustrating the processing flow of an AWS Application Load Balancer (ALB), with Japanese labels, showing request reception, listener specification, path condition matching, and request forwarding to a target group.

料金体系

ELB の各種ロードバランサーのコストは、1 時間単位または 1 時間未満の使用料金と、ロードバランサーキャパシティユニット(LCU)の使用量の合計金額が課金されます。

LCU は、1 秒あたりの新規接続数や、1 分あたりのアクティブ接続数など、ロードバランサーの使用量を示す複数の要素の中から最も使用率が高い要素に対して課金されます。図内の 4 つの LCU の要素は ALB によるもので、これらの要素はロードバランサーの種類により異なります。

図内の料金は、2022 年 11 月現在のアジアパシフィック(東京)リージョンのものです。

ALB を含む ELB の利用料金について詳しくは、「Elastic Load Balancing 料金表」をご覧ください。

A Japanese-language diagram explaining AWS Application Load Balancer (ALB) pricing for the Asia Pacific (Tokyo) region, including hourly charges and LCU (Load Balancer Capacity Unit) breakdowns for new connections, active connections, processed traffic, and rule evaluations.

まとめ

最後に、本記事で紹介した機能の全体図を見てみましょう。

システムの可用性を維持し、アプリケーションを安定的に稼働するためには、ネットワークトラフィックの負荷を効率的に分散するロードバランサーの存在は欠かせません。
ALB は、WebSocket や HTTP/2 通信のサポート、Amazon CloudWatch メトリクス などを使ったロードバランサーのモニタリング、Amazon Elastic Container Service (ECS)と連携したコンテナベースアプリケーションのサポートなど、本記事では紹介しきれない多彩な機能を備えています。
本記事を読んで ALB を含む AWS のロードバランシングサービス ELB に興味を持たれた方、実際に使ってみたいと思われた方は、ぜひ製品ページの「Elastic Load Balancing」も合わせてご覧ください。

全体図

筆者・監修者プロフィール

A portrait of a person with short brown hair, wearing round glasses and a gray sweater, against a light blue background.

筆者プロフィール

米倉 裕基
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター・イラストレーター

日英テクニカルライター・イラストレーター・ドキュメントエンジニアとして、各種エンジニア向け技術文書の制作を行ってきました。
趣味は娘に隠れてホラーゲームをプレイすることと、暗号通貨自動取引ボットの開発です。
現在、AWS や機械学習、ブロックチェーン関連の資格取得に向け勉強中です。

A portrait of a smiling man outdoors, wearing a teal jacket, with a blurred sky background.

監修者プロフィール

荒木 靖宏
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 エマージングテクノロジー本部長

AWS Japan の最古参メンバーです。AWS ではネットワークやコンテナ、開発の話をすることが多いです。
昔は自宅ラック勢でしたが、研究所にいたころに移動させ、AWS にはいったらゼロになりました。COVID-19 下になって、ラスパイお家サーバーが復活しました。

今日お探しの情報は見つかりましたか?

ぜひご意見をお寄せください。ページのコンテンツ品質の向上のために役立てさせていただきます