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

2022-11-02
AWS グラレコ解説

Author : 米倉 裕基 (監修 : 荒木 靖宏)

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

これまでのグラレコ解説はこちら »

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

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


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

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


Elastic Load Balancing

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

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

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

OSI 参照モデルとは:

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

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

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

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 のルーティングアルゴリズムについて詳しくは、「ルーティングアルゴリズム」をご覧ください。


DDoS 攻撃対策

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

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

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

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

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

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

クリックすると拡大します

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


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

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

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

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

リスナールールの条件

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 のターゲットグループ」をご覧ください。

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 のリスナールール」をご覧ください。


料金体系

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

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

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

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


まとめ

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

システムの可用性を維持し、アプリケーションを安定的に稼働するためには、ネットワークトラフィックの負荷を効率的に分散するロードバランサーの存在は欠かせません。

ALB は、WebSocket や HTTP/2 通信のサポート、Amazon CloudWatch メトリクス などを使ったロードバランサーのモニタリング、Amazon Elastic Container Service (ECS)と連携したコンテナベースアプリケーションのサポートなど、本記事では紹介しきれない多彩な機能を備えています。

本記事を読んで ALB を含む AWS のロードバランシングサービス ELB に興味を持たれた方、実際に使ってみたいと思われた方は、ぜひ製品ページの「Elastic Load Balancing」も合わせてご覧ください。

AWS グラレコ解説のその他の記事はこちら

選択
  • 選択
  • 今話題のブロックチェーンをAWSで実現する仕組みをグラレコで解説 »
  • サーバーレスって何が便利なの ? AWS でサーバーレスを構築するためのサービスをグラレコで解説 »
  • 機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説 »
  • 外部から AWS のバックエンドサービス利用を実現する仕組みをグラレコで解説 »
  • AWS でデプロイの自動化を実現するベストプラクティスをグラレコで解説 »
  • コンテナを使ってモノリスを分割する方法をグラレコで解説 »
  • クラウドへ移行する理由とそのステップをグラレコで解説 »
  • Windows ワークロードをクラウドへ移行するためのベストプラクティスをグラレコで解説 »
  • サーバーレスのイベントバスって何 ? Amazon EventBridge をグラレコで解説 »
  • サーバーレスで SaaS を構築する方法をグラレコで解説 »
  • 「あなたへのおすすめ」はどう生成するの ? Amazon Personalize で簡単に実現する方法をグラレコで解説 »
  • クラウド設計・運用のベストプラクティス集「AWS Well-Architectedフレームワーク」をグラレコで解説 »
  • 特定の顧客セグメントにメッセージ送信。「Amazon Pinpoint」の仕組みをグラレコで解説 »
  • アプリにユーザー認証機能を簡単に追加できる「Amazon Cognito」をグラレコで解説 »
  • わずか数分で WordPress サイトを構築できる「Amazon Lightsail」をグラレコで解説 »
  • 異なるアプリケーション同士の疎結合を実現。「Amazon SQS」をグラレコで解説 »
  • Web アプリを高速に開発できる「AWS Amplify」をグラレコで解説 »
  • 機械学習の知識ゼロでもテキストデータを分析。Amazon Comprehend をグラレコで解説 »
  • ビジネスデータをまとめて可視化 & 分析。Amazon QuickSight をグラレコで解説
  • 人工衛星の地上局を 1 分単位で利用。AWS Ground Station をグラレコで解説
  • カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説
  • GraphQL API を簡単に作成 & 運用。AWS AppSync をグラレコで解説
  • IoT 環境を必要な機能を選択するだけで構築。AWS IoT をグラレコで解説
  • 高い可用性と耐久性のオブジェクトストレージ。Amazon S3 をグラレコで解説
  • サーバーレスでイベント駆動型アプリケーションを実現。AWS Lambda をグラレコで解説
  • データサイエンス教育の強い味方。Amazon SageMaker Studio Lab をグラレコで解説
  • 高速で柔軟な NoSQL データベースサービス。Amazon DynamoDB をグラレコで解説
  • リレーショナルデータベースを簡単・迅速に実現。Amazon RDS をグラレコで解説
  • アプリのワークフローを視覚的に構成。 AWS Step Functions をグラレコで解説
  • データ保護に使う暗号化キーを一元管理。AWS KMS をグラレコで解説
  • アプリケーションへのトラフィックを効率的に負荷分散。Application Load Balancer をグラレコで解説
  • AWS で簡単にコンテナアプリケーションを構築 ! Amazon ECS をグラレコで解説
  • 大規模データセットも簡単クエリ! Amazon Athena をグラレコで解説
  • キャッシュ機能でアプリの高速化を実現 ! Amazon ElastiCache をグラレコで解説
  • 使い慣れたプログラミング言語でクラウド環境を構築 ! AWS CDK をグラレコで解説
  • ストリーミングデータを簡単にキャプチャ、処理、保存 ! Amazon Kinesis Data Streams をグラレコで解説
  • AWS で始める機械学習はじめの一歩 ! AWS の主要な AI/ML サービスをグラレコで解説
  • リレーショナルデータベースをサーバーレス化 ! Amazon Aurora Serverless をグラレコで解説
  • ML 駆動の検索エンジンで企業の情報管理を革新! Amazon Kendra をグラレコで解説
  • オンプレミス、エッジ、どこでも楽々コンテナ管理 ! Amazon EKS Anywhere をグラレコで解説
  • 生成 AI アプリケーション開発をもっと身近に、簡単に ! Amazon Bedrock をグラレコで解説

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

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

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

監修者プロフィール

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

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

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する