最新のアプリの需要とクラウドのシンプルさのバランスを取ろうとする場合、Application Load Balancer (ALB) と Elastic Load Balancer (ELB) のどちらを選択するかは混乱を招く可能性があります。
どうして？
ELB は一般的な用語であると同時にレガシー オプションでもあるのに対し、ALB はスケーラブルなマイクロサービス駆動型環境向けに特別に構築されているためです。
ALB に切り替えた組織では、分散ワークロード全体でルーティング効率が向上し、リソース利用率が向上します。
この記事では、ALBとELBを比較し、それぞれをいつ使うべきか、そしてどのように回避するかを説明します。
| 機能 | ALB | ELB（クラシック） |
| OSI層 | レイヤー7（アプリケーション） | レイヤー4（トランスポート） |
| ルーティング方法 | ホスト、パス、クエリ文字列 | IPアドレス、ポートのみ |
| プロトコルサポート | HTTP、HTTPS、WebSocket、HTTP/2 | TCP、SSL |
| ターゲットタイプ | EC2、コンテナ、Lambda、IP | EC2、IP |
| セキュリティ機能 | AWS WAF、シールド、SNI | SSL終了のみ |
| 監視 | 詳細なアクセスログ、CloudWatch | 基本メトリクス、CloudWatch |
| ユースケース | マイクロサービス、API、モダンアプリ | レガシーアプリケーション |
成長を続けるeコマースウェブサイトを運営しているとしましょう。ホームページ、商品リスト、チェックアウトサービス、管理ダッシュボードがすべて複数のサーバーにホストされています。フラッシュセール中にトラフィックが急増すると、ホームページは問題なく、チェックアウトサービスに過負荷がかかる可能性があります。
AWS 環境では、適切なロードバランサーが各リクエストを適切なサーバーグループにルーティングすることでこの混乱を管理し、遅延やダウンタイムを回避します。
これを行うには、ラウンドロビンや最小応答時間などのアルゴリズムを使用して、各リクエストの送信先を決定します。
しかし、ロード バランサがないと、ユーザー リクエストが少しでも急増すると、ボトルネックが発生し、顧客がチェックアウト ページで行き詰まるなど、ユーザー エクスペリエンスが低下する可能性があります。
どうして？
バックエンドの容量や目的に関係なく、すべてのトラフィックが同じエントリ ポイントに到達するためです。
デジタル トラフィックが急増するにつれ、インテリジェントなトラフィック管理はもはやオプションではなく、必須になっています。
ALB は、アプリケーション層または OSI の第 XNUMX 層 (Open Systems Interconnections) モデル。複数のシステム間の通信を促進します。 ALB はリクエストを受け取り、リスナー (接続リクエストをチェックするプロセス) ルールを優先順位に従って評価します。基本的には、コンテンツに基づいてリクエストを特定のサブグループにルーティングします。
ユーザーは、リスナー ルールのアルゴリズムを個別に異なるターゲット グループにルーティングすることを選択できます。 さらに、システム管理者は、プロジェクトや組織の優先順位や要求の変化に応じて、アプリケーションが受け取る全体的な要求を中断することなく、ターゲット グループを簡単に追加または削除できます。
ユーザーは、ALB を他のさまざまな AWS サービスと組み合わせて、アプリケーションの可用性とスケーラビリティを最適化できます。 これらのサービスには、AWS Certificate Manager、Amazon EC2、Amazon Route 53、AWS WAF、および Amazon CloudWatch が含まれる場合があります。
たとえば、Amazon CloudWatch はユーザーにリアルタイムのサービスを提供します。 アプリケーション監視機能提供 迅速なエラー検出 システムの異常やパフォーマンスの遅延に対応するトラブルシューティング。 Amazon Route 53 を使用すると、ユーザーはエイリアス レコードを作成し、DNS リクエストに応答するための複数の IP アドレスを一覧表示できます。これは、地理的に分散したサーバーを管理するための効果的なウェブ ソリューションです。
ALB は、主にネットワーク負荷を分散します。 パブリッククラウド 可用性と安定性を最適化します。 ALB は、OSI モデルの第 XNUMX レイヤー内のアプリケーションの正常性を監視し、特に正常な登録済みターゲットにトラフィックをルーティングします。
具体的には、ALBは、 HTTP および HTTPS ヘッダーにより、開発者は各チェックの詳細なレポートを入手し、発生した特定のコードと HTTP 関連のエラーに焦点を当てて確認できます。
AWS ユーザーは、AWS EC2 インスタンス、アプリケーション (Rest API 経由)、またはコンテナーの前で内部負荷分散を介して ALB を適用できます。 複雑な環境内の複数のサービスは、アプリケーションのニーズに基づいて異なるサーバー クラスターにルーティングするなど、パスベースのルーティングを通じて単一の ALB ロード バランサーを共有する場合があります。 ユーザーは、10 つの ALB の背後で最大 XNUMX 個のアプリケーションをルーティングできます。
高度なルーティング
ALBはコンテンツに基づいてスマートなルーティング決定を行います。ホストベース、パスベース、さらにはクエリ文字列パラメータを使用してトラフィックを誘導できます。これは、 複雑なマイクロサービスの管理 アーキテクチャを構築したり、ユーザーを地域固有のコンテンツに誘導したりします。
最新のアプリケーションには最新のプロトコルが必要です。ALBは、リアルタイムの双方向通信を実現するWebSocketと、より高速で効率的なネットワーク接続を実現するHTTP/2の両方をサポートしています。これにより、バックエンドに大きな変更を加えることなく、アプリケーションの応答性が向上します。
ALB は AWS Web Application Firewall (WAF) および AWS Shield と直接統合され、一般的なウェブエクスプロイトや DDoS 攻撃からアプリケーションを保護します。追加のインフラストラクチャオーバーヘッドなしで、セキュリティポリシーの適用やトラフィックの潜在的な脅威の監視を簡単に行うことができます。
ALBはEC2インスタンスに限定されません。トラフィックをコンテナ（ECSやEKS上で実行されているものなど）、IPアドレス、さらにはAWS Lambda関数にルーティングできます。そのため、最新のサーバーレス環境やコンテナ化された環境に最適です。
ALB は、ロードバランサーで直接ユーザー認証を処理することで、時間を節約し、バックエンドの複雑さを軽減します。Amazon Cognito、Microsoft AD、Google と統合できるほか、組み込みのリダイレクトアクションや固定レスポンスアクションを使用することで、トラフィック管理を簡素化できます。
適切なロード バランサはトラフィックを誘導し、ビジネスをフルスピードで進めます。
2009 年に AWS によって導入された ELB (クラシック ロード バランサーとも呼ばれます) は、複数のターゲット間でトラフィック分散プロセスを自動化するソフトウェア ベースのロード バランスです。 これらのターゲットには、コンテナーと IP アドレスが含まれる場合があります。
ELB は、OSI モデルの第 XNUMX 層 (トランスポート層) から動作し、TCP または IP の適用プロトコルに基づいて要求を転送し、同様のバックエンド ターゲットとリンクします。 たとえば、ELB が TCP ポートからクライアント リクエストを受信すると、ロード バランサーのセットアップ中に事前設定されたルールに基づいてリクエストをルーティングします。
クラシック ロード バランサーは、アプリケーション スタックのセキュリティを強化し、管理を容易にし、信頼性を高めるためのさまざまな機能を提供します。
具体的には、ELB は Web ネットワークに次のような機能を提供します。
ELB は、EC2 インスタンスのユーザーに単一のエントリ ポイントを提供し、利用可能なターゲット間でトラフィックを効率的に分散します。 構成されたヘルス チェックを使用すると、ELB は登録された各ターゲットの状態を綿密に監視し、トラフィックの分散を正常な場所に制限して、フォールト トレランスを向上させることができます。
AWSは廃止されたようですが 2年のEC2022-ClassicネットワークClassic Load Balancer は引き続きサポートされます。Classic Load Balancer が既に VPC 内にデプロイされている場合は、変更は必要ありません。EC2-Classic に関連付けられている場合は、VPC 環境への移行を推奨します。
Classic Load Balancer は OSI モデルのレイヤー 4 で動作し、TCP および IP プロトコルに基づいてトラフィックを管理します。Classic Load Balancer を作成する際は、バックエンドインスタンスを直接 Classic Load Balancer に登録し、XNUMX つ以上のアベイラビリティーゾーン (AZ) に割り当てます。
リージョン内の AZ の背後に複数のサーバーを配置すると、ネットワークの可用性が向上し、ELB はアクセスできないときにトラフィックを利用可能な AZ に再ルーティングできます。 ELB は、デフォルト設定中に AZ 間でトラフィックを均等にルーティングします。 ただし、サーバーがリクエストに応答しない場合、デフォルト設定は過負荷/負荷の不均衡につながる可能性があります。
クロスゾーン負荷分散を有効にすると、各バランサー ノードは、有効なすべての AZ の登録済みターゲットにトラフィックを分散できます。 または、クロスゾーン負荷分散を無効にすると、各バランサー ノードが特定の AZ にトラフィックを分散するように制限されます。 そのため、ゾーン間の負荷分散により、潜在的な負荷の不均衡のリスクが軽減されます。
レイヤー4負荷分散
ELB は TCP および IP プロトコルに基づいてトラフィックをルーティングするため、コンテンツ認識ルーティングを必要としないシンプルなアプリケーションやレガシー アプリケーションに最適です。
ELBは登録されたターゲットに対して定期的なヘルスチェックを実行し、正常なインスタンスにのみトラフィックをルーティングします。これにより、アプリケーションの可用性が維持され、ユーザーがリクエストを処理できないリソースに誘導されることがなくなります。
ロードバランサー上で SSL 証明書を集中管理することで、各バックエンド サーバーで直接証明書を構成することなく、安全な通信のための暗号化を簡素化できます。
ELB は IPv4 と IPv6 の両方をサポートしているため、アプリケーションは追加の構成なしで最新の IP トラフィック標準を処理できます。
クロスゾーン負荷分散を有効にすると、各ELBノードは、有効化されたすべてのアベイラビリティゾーン内の正常なインスタンス全体にトラフィックを均等に分散できます。これにより、インスタンス障害時やトラフィック量が多い時間帯における過負荷を防ぎ、フォールトトレランスを向上させます。
ALB と ELB は、それぞれ特殊な機能を備えているにもかかわらず、いくつかのコア機能と機能を共有しています。
ALBとELBはコア機能の一部を共有していますが、大きな違いもあります。違いを見ていきましょう。
| 機能 / 制限 | アプリケーション ロード バランサー (ALB) | エラスティックロードバランサー（ELB / クラシック） |
| 導入された年 | 2016 | 2009 |
| リスナー管理 | リスナールーティングルールの表示と編集をサポート | リスナーの追加/削除のみを許可します |
| ルーティングロジック | ホスト名、パス、クエリ文字列、IP、ポートに基づくコンテキスト認識ルーティング | TCP ポートに基づくルート (コンテンツベースのロジックなし) |
| 複数ポート転送 | サポート | サポートされていません |
| ターゲットタイプの互換性 | Fargate 上の EKS、IP ベースのターゲット、コンテナと互換性があります | FargateおよびIPベースのルーティングと互換性がない |
| WebSocket と HTTP/2 のサポート | 完全にサポート | サポートされていません |
| ドメイン名の取り扱い | 複数のドメインのサーバー名表示（SNI）をサポート | 単一ドメインに限定 |
| 基盤プロトコルのサポート | HTTP、HTTPS、HTTP/2、WebSocket | TCP、HTTP、HTTPS |
| 高度な機能 | 複数の同時リクエスト、高度なルーティング、動的なルール更新のネイティブサポート | 基本的な負荷分散機能 |
両方のロードバランサーの類似点と相違点がわかったので、それぞれをいつ使用すべきかを確認しましょう。
次の場合は ALB を選択してください:
次の場合は ELB を選択します。
トラフィックを単一のポート経由でしかルーティングできないELBとは異なり、ALBは複数のポートにまたがるルーティングやAWSへのルーティングもサポートします。 ラムダ関数これにより、ALB はサーバーレス アーキテクチャに最適となり、サーバーを管理せずにバックエンド ロジックを実行したり、API を構築したり、Web アプリを提供したりできるようになります。
ALBは、ロードバランサーレベルでより高度なタスクを直接実行し、アプリケーションサーバーの負荷を軽減します。具体的には以下のとおりです。
ALB はこれらの機能を上流で処理することにより、アプリケーションがコアビジネス ロジックに集中できるようにし、効率とパフォーマンスを向上させます。
ALB のその他の優れた機能は次のとおりです。
まだ Classic Load Balancer を使用している場合は、ALB に移行することがアーキテクチャの最新化に向けた賢明な動きです。
どうして？
ALB は、高度なルーティング、向上したパフォーマンス、クラウドネイティブ アプリケーションをより適切にサポートする組み込みの統合を提供するためです。
しかし、移行をスムーズかつ低リスクにするには、慎重に検討した移行計画が必要です。
現在ELBに依存しているアプリケーションを特定します。次のような主要な設定を文書化します。
これにより、明確なベースラインが得られ、移行中に予期せぬ事態が発生するのを回避できます。
次のような ALB のレイヤー 7 機能がワークロードにメリットをもたらすかどうかを判断します。
アプリのアーキテクチャが最新であるか、その方向へ進んでいる場合は、ALB の方が適している可能性があります。
ALB はほとんどの ELB 機能をサポートしていますが、一部の機能はより高度であり、更新が必要になる場合があります。
つまり、複製ではなく最適化にこの時間を使用してください。
ALBの設定とテストが完了したら、Route 53（またはDNSプロバイダ）を更新して、トラフィックが新しいロードバランサーに送信されるようにしてください。この段階で、慎重に切り替えを行い、実際のトラフィックを監視してください。
さらなる安全性のために:
すべてがスムーズに動作すると確信できた場合にのみ、ELB を廃止してください。
組み込みのダッシュボード、リアルタイム メトリック、自動アラートを備えた LogicMonitor は、クラウド環境がどんなに複雑になっても、トラフィックの急増に先手を打って対応し、トラブルシューティングを迅速化し、自信を持って拡張するために必要なすべてを提供します。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
