ロードバランサーは AWS システムの重要なコンポーネントであり、最適なオプションを選択すると混乱するユーザーもいます。 適切なオプションを選択すると、ユーザーはさまざまなタスクをリソース全体に分散できるため、プロセスが最適化されます。 ロード バランサーを使用せずにネットワークを運用すると、ユーザー リクエストが急増したときに Web サービスで大幅な遅延が発生する可能性があります。
現代のデジタル時代は、ソーシャル メディアの使用や IoT 操作からのユーザー リクエストの大幅な増加につながり、Web トラフィック管理の重要なコンポーネントとしてのロード バランサーの重要性が高まっています。
基本的に、適切なロード バランサーは、クライアント デバイスとバックエンド サーバー間のゲートキーパーまたは接点として機能し、アプリケーションの応答性、スケーラビリティ、および可用性を向上させながら、トラフィックの過負荷のリスクを軽減します (つまり、フォールト トレランスの向上)。
ロード バランサーは、さまざまな複雑さを持つ事前設定されたアルゴリズムに従い、サーバー間での要求の分散を決定します。 最も広く使用されているアルゴリズムには、ラウンドロビン、 ハッシュ方法, 最短応答時間、およびカスタム ロード。
ALB (Application Load Balancer) について
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 は、主にネットワーク負荷を分散します。 パブリッククラウド 可用性と安定性を最適化します。 ALB は、OSI モデルの第 XNUMX レイヤー内のアプリケーションの正常性を監視し、特に正常な登録済みターゲットにトラフィックをルーティングします。
具体的には、ALB は HTTP および HTTPS ヘッダーで識別されるデータ パケットを評価し、発生した特定のコードと HTTP 関連のエラーを拡大する各チェックの詳細なレポートを開発者に提供します。
AWS ユーザーは、AWS EC2 インスタンス、アプリケーション (Rest API 経由)、またはコンテナーの前で内部負荷分散を介して ALB を適用できます。 複雑な環境内の複数のサービスは、アプリケーションのニーズに基づいて異なるサーバー クラスターにルーティングするなど、パスベースのルーティングを通じて単一の ALB ロード バランサーを共有する場合があります。 ユーザーは、10 つの ALB の背後で最大 XNUMX 個のアプリケーションをルーティングできます。
ALB のコアコンセプト
ALB には、最適化されたネットワーク構成のためにユーザーが熟知する必要があるさまざまなコンポーネントが含まれています。 これらには、ルール、ターゲット、優先順位、および条件が含まれます。 ALB のルールは、特定の条件またはパス パターンを満たすことによって、クライアントの要求に一致する目的のアクションを設定します。 ALB は、昇順の数値に従って、優先度に基づいてルールの実行順序を決定します。
ELB (Elastic Load Balancer) について
2009 年に AWS によって導入された ELB (クラシック ロード バランサーとも呼ばれます) は、複数のターゲット間でトラフィック分散プロセスを自動化するソフトウェア ベースのロード バランスです。 これらのターゲットには、コンテナーと IP アドレスが含まれる場合があります。
ELB は、OSI モデルの第 XNUMX 層 (トランスポート層) から動作し、TCP または IP の適用プロトコルに基づいて要求を転送し、同様のバックエンド ターゲットとリンクします。 たとえば、ELB が TCP ポートからクライアント リクエストを受信すると、ロード バランサーのセットアップ中に事前設定されたルールに基づいてリクエストをルーティングします。
クラシック ロード バランサーは、アプリケーション スタックのセキュリティを強化し、管理を容易にし、信頼性を高めるためのさまざまな機能を提供します。
具体的には、ELB は Web ネットワークに次のような機能を提供します。
- 公開鍵によるユーザー認証
- SSL証明書の一元管理
- 登録された正常なインスタンス間のトラフィック分散
- IPv4 および IPv6 のサポート
ELB は、EC2 インスタンスのユーザーに単一のエントリ ポイントを提供し、利用可能なターゲット間でトラフィックを効率的に分散します。 構成されたヘルス チェックを使用すると、ELB は登録された各ターゲットの状態を綿密に監視し、トラフィックの分散を正常な場所に制限して、フォールト トレランスを向上させることができます。
ELB のしくみ
通常、クラシック ロード バランサーでは、ユーザーは有効なアベイラビリティ ゾーン (AZ) 内にロード バランサー ノードを作成するときに、インスタンスをロード バランサーに直接登録します。
リージョン内の AZ の背後に複数のサーバーを配置すると、ネットワークの可用性が向上し、ELB はアクセスできないときにトラフィックを利用可能な AZ に再ルーティングできます。 ELB は、デフォルト設定中に AZ 間でトラフィックを均等にルーティングします。 ただし、サーバーがリクエストに応答しない場合、デフォルト設定は過負荷/負荷の不均衡につながる可能性があります。
クロスゾーン負荷分散を有効にすると、各バランサー ノードは、有効なすべての AZ の登録済みターゲットにトラフィックを分散できます。 または、クロスゾーン負荷分散を無効にすると、各バランサー ノードが特定の AZ にトラフィックを分散するように制限されます。 そのため、ゾーン間の負荷分散により、潜在的な負荷の不均衡のリスクが軽減されます。
ALB と ELB の比較
ALB と ELB は、特殊な機能にもかかわらず、いくつかのコア機能と機能を共有しています。 まず第一に、それらは高可用性とスケーラビリティを備えており、ユーザーは、アプリケーションからの全体的な要求フローを中断することなく、必要に応じてリソースを追加または削除することを選択できます。 ALB と ELB は、以下を含む主要な機能をサポートしています。
- スティッキー セッション — システムは、Cookie と IP 追跡を介してユーザーに属性を割り当てます。
- SSL ターミネーション — 登録されたターゲットに配布する前に、暗号化されたトラフィックを復号化します。
- アイドル セッションの終了 — ロード バランサーは、事前に構成された非アクティブ期間が経過すると、セッションを自動的に閉じます。
- コネクション ドレイン — クライアント接続を早期に終了することなく、ユーザーがインスタンスを安全に削除できるようにする機能。
- ヘルス チェック — ヘルス チェックを提供してインスタンスの異常を特定し、さらなるアクションを実行します。
ALB と ELB の違い
2016 年、AWS はオリジナルの ELB プログラムを ALB で改良し、ユーザーに追加機能と拡張機能を提供しました。
たとえば、ELB では優先順位の変更に応じてユーザーがリスナーを追加および削除できますが、ALB ではリスナーのルーティング ルールを表示および編集する追加機能が提供されます。 そのため、ユーザーはルートを事前定義されたターゲット グループに簡単に転送できます。
ALB は、次のような ELB の制限の一部も修正します。
- インスタンスごとに複数のポートにトラフィックを転送するサポートされていない機能
- Fargate で実行される EKS サーバーとの非互換性
- IP アドレスにトラフィックを配信できないため、AWS 外部のターゲットへのトラフィックが妨げられます
- WebSocket と HTTP/2 のサポートの欠如
- 許可されたドメイン名を XNUMX つだけ提供する
ALB と ELB の最も大きな違いの XNUMX つは、ルーティング プロセスのシステムにあります。 ELB はルーティング番号に基づいてトラフィックをルーティングするだけですが、ALB はクエリ文字列境界、送信元 IP、ポート番号、ホスト名、パスなど、複数の参照に基づいてコンテキスト駆動型ルーティングを容易にします。
さらに、ALB は Server Name Indication (SNI) をサポートしているため、単一のドメイン名を提供するという ELB の従来の制限を回避できます。 ALB は、単一の接続を介して配信される複数のリクエストを介して、HTTP/2 および WebSocket のネイティブ サポートをユーザーに提供します。
ALB は組み込み機能を提供します
ELB は単一のポートを介したルーティングのみを許可しますが、ALB は複数のポートを介した配信をサポートし、 ラムダ関数. Lambda 関数を使用すると、ユーザーはさまざまな機能を管理および実行し、サーバーレス コーディングを使用して Web サイトを構築し、サーバーレス メソッドを使用してカスタマイズされた ALB ターゲットを作成できます。
ALB は、高度なタスクをプログラムから直接実行することで、サーバー機能をオフロードして最適化します。これには、事前構成されたリダイレクトや固定応答、LDAP、Microsoft AD、Google によるユーザー認証が含まれます。 追加されたロード バランサ機能により、アプリケーションはビジネス ロジックに集中してパフォーマンスを向上させることができます。
その他の注目すべき組み込み ALB 機能には、次のものがあります。
- コンテナベースのアプリケーション サポート、単一のインスタンスが、同じターゲット グループの背後でネットワーク トラフィックをリッスンする複数のコンテナーをホストできるようにします。
- ポート レベルできめ細かいヘルス チェックを実行する機能。 具体的には、ALB はタグ、リソース、およびリソースベースのアクセス許可によるフィルタリングをコンソールでサポートしているため、ユーザーは IAM ポリシーを使用してきめ細かな制御を実装できます。
- 圧縮形式で安全に保存された詳細なアクセス ログを提供します。
アクセスログ
ALB のアクセス ログには、元の HTTP 応答と、クライアント リクエストの転送に必要な時間、リクエスト タイプ、およびタイム スタンプを決定する response_processing_time で構成される情報の詳細な内訳が含まれます。
ALB と ELB のまとめ
ユーザーは、HTTP/HTTPs Web トラフィックの負荷を特定のパスまたはコンテキスト駆動型の要求を駆動するホストベースのルーティングで分散する際に、ALB を適用することが有利であることに気付く場合があります。 これらは、マイクロサービス ランドスケープなどの複雑な環境でプロセスを促進するのに役立ちます。
ALB は従来の ELB の完全なアップグレードのように見えるかもしれませんが、各負荷分散ソリューションには推奨される用途があります。 たとえば、複雑なアプリケーションの迅速かつ信頼性の高い配布を必要とするマイクロサービスの台頭などの最新のトレンドに対応するために、ALB はコンテンツベースのルーティングでより適切に機能します。
URL とサービス間の直接リンクを使用して各サーバー用に慎重に定義されたロード バランサーを備えたネットワークから操作するユーザーは、トラフィックのニーズを処理する際に従来の ELB を適用する方が費用対効果が高く、実用的であることに気付くでしょう。
また、古い AWS アカウントを持つユーザーは、ELB が動作する唯一のロード バランサーであることに注意する必要があります。 EC2-クラシック アプリケーション定義のスティッキー セッション Cookie をサポートします。 ただし、ELB/クラシック ロード バランサーのユーザーは、AWS がプログラムの新しい更新をリリースしていないことに注意する必要があります。 2 年 15 月 2022 日までに ECXNUMX-Classic を廃止するであるため、ユーザーは VPC への体系的な移行を検討する必要があります。これにより、既存のワークロードが中断されなくなります。
効率的な負荷分散で期待できること
従来のロード バランサーからアップグレードすると、全体的な負荷を最適化する幅広いメリットがユーザーにもたらされます。 ネットワークのパフォーマンス.
強化されたセキュリティ
最新のロードバランサーは、SSL/TLS 復号化やユーザー検証などの複数のセキュリティ機能をサポートする VPC と互換性があります。 システム管理者は、次の方法でプライベート接続を確立できます。 AWS プライベートリンク VPC エンドポイントを介して VPC とロード バランサーの間で、安全なオフライン トラフィック分散を可能にします。
さらに、最新のロード バランサーには、次のようなより多くの TLS ポリシーが引き続き含まれています。 ELB セキュリティ ポリシー FS 2018 06、TLS および暗号スイートを制御します。 これらの実装は、アプリケーションの負荷分散全体で前方秘匿性を最適化します (つまり、セッション キーのセキュリティを保護します)。
比類のない可用性
ユーザーは、複数の AZ 全体で複数の正常なターゲット間でトラフィックが中断されず、最適化された効率でリクエストとデータを実行し続けることが期待できます。
新たな多様性
最新の負荷分散により、ユーザーは単一のロード バランサーを介して AWS とオンプレミス システム全体で機能できます。 システム管理者は、必要に応じて管理、移行、または制御 (フェイルオーバー) をオンプレミス リソースに移管する際に直面する摩擦が少なくなります。
柔軟性の向上
更新された負荷分散により、ユーザーはさまざまなアプリケーション ワークロードに応じて効果的に自動スケーリングできます。 さらに、ユーザーは、アプリケーション間の通信を最適化するために個々のセキュリティ グループを維持しながら、単一のインスタンスから複数のアプリケーションをホストできます。
閉じた思考
AWS は引き続き負荷分散オプションを拡張し、効率的なサーバー機能のためにトラフィックを分散する際の柔軟性をユーザーに提供します。 同社はその ネットワーク ロード バランサー (NLB) 2017 年に、XNUMX 秒あたり数百万のリクエストを処理することを目指しました。 NLB は、要求の厳しい IoT、ゲーム、メッセージング アプリケーション、およびフェールオーバー サポートを強化する長時間接続を含む、幅広いトラフィック管理の改善をユーザーに提供します。
システム開発者は、コストの削減、スケーラビリティの向上、および効率の最適化のために、AAA コンピューター セキュリティ ソリューションを介して認証、承認、およびアカウンティングを管理するための専用サービスも作成しました。
各負荷分散ソリューションの料金は似通っているため、価格が最適なソリューションを決定する要因となることはほとんどありません。 最終的に、どの負荷分散方法を選択するかは、ワークロードが機能する基盤となる場所によって異なります。 ただし、ALB の使用に向けた完全な進歩は、地平線内で明らかであるように思われます。
全体として、AWS のロード バランサーは他のサービスとシームレスに統合されています。 最適なローダーの選択は、最終的には既存の複雑さに依存します。 ネットワークインフラ、環境、および要求。
ユーザー登録 無制限のデバイスで AWS ネットワーク全体の包括的な監視とアラートにアクセスできます。