ロードバランサーは、トラフィック分散の維持や、サーバー問題の検出、利用可能なサーバーに対するクライアント要求のダウンタイムなしのリダイレクトにより、Amazon Web Services（AWS）システムにおいてきわめて重要な役割を果たします。アプリケーションのパフォーマンスおよびスケーラビリティの最適化に不可欠であるため、適切なAWSロードバランサーの選択が複雑になってしまうことも珍しくありません。
ユースケースにより、 Elastic Load Balancer（ELB） が最適となる場合も、逆に Application Load Balancer（ALB） の方がニーズに適しているという場合もあります。これらの機能には共通点があるものの、AWS ALBは、AWSインフラストラクチャによってはより適切となる特殊な機能を提供します。さて、どちらがよりAWS環境に適しているかをどのように判断すればよいのでしょうか？
AWS Elastic Load Balancer（ELB）とは
2009年にAWSによってリリースされたAWS ELBは、複数のAmazon EC2インスタンスに受信トラフィックを分散するソフトウェアベースの ロードバランサー です。これは、 Amazon EC2インスタンスを持つユーザーのための単一のエントリポイントとして機能します。
また、ELBはトラフィック分散のほかに、サービスにおける信頼性の維持を行います。登録されたすべてのターゲットに対するヘルスチェックを継続的に実行し、トラフィックがアクティブかつ正常なインスタンスにのみルーティングされるようにすることで、ダウンタイムを最小限に抑え、アプリケーションのパフォーマンスを向上させます。
AWS監視の詳細についてはこちらをご覧ください。
AWS Application Load Balancer（ALB）とは
2016年、AWSはClassic ELBに Application Load Balancer（ALB）という新機能を追加しました。Classic ELBとALBの機能には共通点がありますが、ALBはユーザーに強化された機能を提供することを念頭に設計されています。
Classic ELBの機能に加え、ALBはユーザー定義のルールに基づいてルーティングを管理します。単一のALBは、ホストベースまたはパスベースのルールに基づき受信トラフィックを複数サービスに誘導できるため、最新のクラウドアプリケーションに最適となります。
ELBとALBにおける要求の管理およびルーティング方法の違い
AWS ELBとALBにおける根本的な違いは、要求の処理およびルーティング方法にあり、これは Open Systems Interconnection（OSI）モデルを考慮することで最も適切に把握することができます。OSIモデルは、7つの層に分割することで異なるコンピューティングシステム間の通信を容易にする概念フレームワークです。
OSIモデルの各層は、その下の層によってサポートされます。このモデルには、伝送媒体（光ファイバー、CAT-5ケーブルなど）を表す物理層である第1層から、Webアプリケーションによって要求の処理が行われるアプリケーション層の第7層までが存在します。
Classic ELBは、TCP/IPまたはUDPプロトコルに基づきネットワークトラフィックの管理を担当するトランスポート層の第4層で動作します。ネットワークデバイスとして機能するClassic ELBは、受信要求のプロトコルとポートを読み取り、1つ以上のバックエンドAmazon EC2インスタンスに転送します。このため、Classic ELBは、要求の内容ではなくネットワークレベルのパラメータに基づくトラフィック分散など、シンプルな負荷分散に適しています。
一方、AWS ALBはアプリケーション層である第7層にて動作し、要求の内容に基づいてトラフィックをリダイレクトします。ALBは、受信要求のURLパス、ヘッダー、およびクエリ文字列を分析し、その内容に応じてトラフィックをルーティングします。すべてのトラフィックを同種のバックエンドサーバーの単一プールに誘導する代わりに、ALBはアプリケーション固有のルールに基づき、複数のターゲットグループに対して要求を転送することができます。
Classic ELB：AWSのオリジナル製品
Classic ELBは、シンプルで効果的なロードバランサーです。設定が簡単なため、AWSの機能に精通したエンジニアの間でも人気があります。定義が明確で、特定のアドレスにマッピングされたサービスにより構成されている環境においては、Classic ELBが論理的な選択肢となるでしょう。
より高度なALBと同様、Classic ELBも次の機能をサポートしています。
- SSL終了
- スティッキーセッション
- アイドルセッションの終了
- 異常であるとマークされつつあるインスタンスに対する要求の完了。
ALB：コンテンツベースルーティングのための理想的な選択肢
あらゆる組織がマイクロサービスアーキテクチャやコンテナベースのインフラストラクチャを採用し始めるにつれ、単一アドレスの特定サービスへのマッピングは複雑化し、維持することが困難になってきています。プロトコルとポートのみに基づいて要求をルーティングするClassic ELBとは異なり、ALBは要求の内容に基づいてルーティングを行います。
ALBの機能
AWS ALBの設定が完了したら、AWSマネジメントコンソール内で詳細設定にアクセスすることができるようになります。 EC2ホームページのロードバランサーセクションから、ロードバランサーの作成や変更を必要に応じて行うことができます。
Classic ELBと同様、ALBでもリスナーを追加してあらゆるターゲットに向けることが可能です。しかし、ルーティングロジックの管理を可能とするルール表示／編集の存在から、ALBが一歩先を進んでいるといえるでしょう。
ルール表示／編集のリンクをクリックすることで、ルーティングルールを追加、編集、および削除することができます。これらのルールはパスベースまたはヘッダーベースにすることが可能であり、各要求は定義されたターゲットグループに送信されます。デフォルトのアクションでは、前のルールに一致しない要求は事前定義済みのターゲットグループにルーティングされます。
ALBとELB：適切な選択肢の検証
AWS ALBとELBのどちらを選択すべきかは、特定のAWS環境とアプリケーション要件によって異なります。
個別のサービスがそれぞれ異なるURLにマッピングされているインフラストラクチャにおいて、基本的な負荷分散のみが必要となる場合、Classic ELBが適切な選択肢であるといえるでしょう。シンプルかつ効果的であり、AWSエンジニアに広く使用されている選択肢です。
マイクロサービスやコンテナ化されたアプリケーションを扱う場合や、高度なルーティング機能が必要となる場合には、ALBがより適切な選択肢となります。コンテンツベースのルーティングや複数のターゲットグループ、そしてより緊密なAWSサービス統合により、ALBは最新のクラウドネイティブ環境に柔軟性とスケーラビリティを提供します。
ALBとELBに対していえるのは、どちらもアプリケーションのパフォーマンスおよび可用性を向上させる強力なツールであり、Sumo Logicアカウント内でサポートされているということです。
適切なロードバランサーを選択することで、トラフィック分散とシステム効率の最適化が実現します。
これらのロードバランサーを今すぐお試しください。 30日間の無料トライアルにより、Sumo Logicの使用を開始しましょう。
