AWS ELB によるロードバランシング

こんにちは、みんな！ 今日からコースが始まります 「開発者のためのAWS」これに関連して、ELB レビューに特化した対応するテーマ別ウェビナーを開催しました。 バランサーの種類を確認し、バランサーを使用していくつかの EC2 インスタンスを作成しました。 他の使用例についても検討しました。

ウェビナーを聞いた後、 あなたはするであろう：

• AWS ロード バランシングとは何かを理解する。
• Elastic Load Balancer の種類とそのコンポーネントを理解する。
• 実践で AWS ELB を使用してください。

そもそもなぜこれを知る必要があるのでしょうか？

• AWS 認定試験を受ける予定がある場合に役立ちます。
• これはサーバー間で負荷を分散する簡単な方法です。
• これは、Lambda をサービス (ALB) に追加する簡単な方法です。

公開授業を実施しました リシャット・テレグロフ, ウェブサイトの開発とサポートを担当するマーケティング会社のシステムエンジニア。

導入

Elastic Load Balancer が何であるかは、簡単な例を示す以下の図でわかります。

ロード バランサーはリクエストを受け入れ、インスタンス間でリクエストを分散します。 個別のインスタンスが XNUMX つあり、Lambda 関数があり、AutoScaling グループ (サーバーのグループ) があります。

AWS ELB の種類

1.主な種類を見てみましょう:

クラシックロードバランサー。 AWS の最初のバランサーは、OSI レイヤー 4 と 7 の両方で動作し、HTTP、HTTPS、TCP、SSL がサポートされています。 これは、複数の Amazon EC2 インスタンス間で基本的な負荷分散を提供し、リクエスト レベルと接続レベルの両方で機能します。 開いてみましょう (灰色で強調表示されています)。

このバランサーは時代遅れであると考えられているため、特定の場合にのみ使用することをお勧めします。 たとえば、EC2‑Classic ネットワーク上に構築されたアプリケーションの場合です。 原則として、私たちがそれを作成するのを止める人は誰もいません。

2. ネットワークロードバランサー。 重いワークロードに適しており、OSI レイヤ 4 で動作し (EKS および ECS で使用可能)、TCP、UDP、TLS がサポートされています。

Network Load Balancer は、Amazon VPC 内のターゲットにトラフィックをルーティングし、超低レイテンシーで XNUMX 秒あたり数百万のリクエストを処理できます。 さらに、負荷が突然変化するトラフィック パターンを処理できるように最適化されています。

3. アプリケーションロードバランサー。 レイヤー 7 で動作し、Lambda をサポートし、ヘッダーとパス レベルのルールをサポートし、HTTP と HTTPS をサポートします。
マイクロサービスやコンテナなどの最新のアーキテクチャに基づいて構築されたアプリケーションの配信に重点を置いた高度なリクエスト ルーティングを提供します。 リクエストの内容に基づいて、Amazon VPC 内のターゲットにトラフィックを送信します。

TCP は HTTP ほど一般的ではないため、多くのユーザーにとって、Application Load Balancer が Classic Load Balancer に代わる最初の選択肢でした。

これも作成してみましょう。その結果、すでに XNUMX つのロード バランサーが存在することになります。

負荷分散コンポーネント

一般的な負荷分散コンポーネント (すべてのバランサーに共通):

• アクセスログポリシー

— ELB アクセス ログ。 設定を行うには、「説明」に移動して「属性の編集」ボタンを選択します。

次に、S3Bucket (Amazon オブジェクト ストレージ) を指定します。

• スキーム

— 内部バランサーまたは外部バランサー。 重要なのは、ロードバランサーが外部からアクセスできるようにするために外部アドレスを受信する必要があるのか​​、それとも内部ロードバランサーでもよいのかということです。

• セキュリティグループ

— バランサーへのアクセス制御。 本質的に、これは高レベルのファイアウォールです。

• サブネット

— VPC 内のサブネット (およびそれに応じてアベイラビリティーゾーン)。 サブネットは作成時に指定されます。 VPC がリージョンによって制限されている場合、サブネットはアベイラビリティ ゾーンによって制限されます。 ロード バランサーを作成するときは、少なくとも XNUMX つのサブネットに作成することをお勧めします (XNUMX つのアベイラビリティーゾーンで問題が発生した場合に役立ちます)。

• リスナー

— バランサープロトコル。 前述したように、Classic Load Balancer の場合は HTTP、HTTPS、TCP、SSL、Network Load Balancer の場合は TCP、UDP、TLS、Application Load Balancer の場合は HTTP および HTTPS になります。

クラシック ロード バランサーの例:

ただし、Application Load Balancer では、インターフェイスがわずかに異なり、一般的にロジックも異なります。

ロード バランサ v2 コンポーネント (ALB および NLB)

次に、バージョン 2 のバランサーである Application Load Balancer と Network Load Balancer を詳しく見てみましょう。 これらのバランサーには独自のコンポーネント機能があります。 たとえば、ターゲットグループのような概念、つまりインスタンス（および関数）が登場しました。 このコンポーネントのおかげで、どのターゲット グループにトラフィックを誘導するかを指定することができます。

簡単に言えば、ターゲット グループでトラフィックが来るインスタンスを指定します。 同じ Classic Load Balancer で単に Intensity をバランサーにすぐに接続する場合は、Application Load Balancer で最初に次の操作を行います。

• ロードバランサーを作成します。
• ターゲットグループを作成します。
• 必要なポートまたはロード バランサ ルールを介して必要なターゲット グループに直接送信します。
• [ターゲット グループ] でインスタンスを割り当てます。

この動作ロジックは複雑に見えるかもしれませんが、実際はより便利です。

次のコンポーネントは リスナーのルール (ルーティングのルール)。 これは、Application Load Balancer にのみ適用されます。 Network Load Balancer で単純にリスナーを作成し、それが特定のターゲット グループにトラフィックを送信する場合、Application Load Balancer ではすべて もっと楽しく、もっと便利に.

さて、次のコンポーネントについて少しお話しましょう - エラスティックIP (NLB の静的アドレス)。 ルーティング ルールのリスナー ルールが Application Load Balancer にのみ影響する場合、Elastic IP は Network Load Balancer にのみ影響します。

ネットワーク ロード バランサーを作成しましょう。

そして、作成プロセス中に、Elastic IP を選択する機会が与えられていることがわかります。

Elastic IP は、時間の経過とともにさまざまな EC2 インスタンスに関連付けることができる単一の IP アドレスを提供します。 EC2 インスタンスに Elastic IP アドレスがあり、そのインスタンスが終了または停止された場合は、新しい EC2 インスタンスを Elastic IP アドレスにすぐに関連付けることができます。 ただし、実際の EC2 が変更された場合でも、アプリケーションは引き続き同じ IP アドレスを認識するため、現在のアプリケーションの動作が停止することはありません。

ここで 別の使用例 Elastic IP が必要な理由について説明します。 3 つの IP アドレスが表示されていますが、これらは永遠にここに存在するわけではありません。

Amazon は時間の経過とともに、おそらく 60 秒ごとに変更します (もちろん、実際にはそれほど頻繁ではありません)。 これは、IP アドレスが変更される可能性があることを意味します。 また、Network Load Balancer の場合は、IP アドレスをバインドし、ルールやポリシーなどで指定するだけです。

結論を出す

ELB は、複数のターゲット (コンテナ、Amazon EC2 インスタンス、IP アドレス、Lambda 関数) 間で受信トラフィックを自動的に分散します。 ELB は、単一のアベイラビリティーゾーン内および複数のアベイラビリティーゾーン全体の両方で、さまざまな負荷を持つトラフィックを分散できます。 ユーザーは、高可用性、自動スケーリング、優れた保護を提供する XNUMX 種類のバランサーから選択できます。 これらはすべて、アプリケーションの耐障害性を確保するために重要です。

主な利点：

• 高可用性。 サービス契約では、ロード バランサーの可用性が 99,99% であることを前提としています。 たとえば、複数のアベイラビリティーゾーンにより、トラフィックが正常なオブジェクトによってのみ処理されることが保証されます。 実際、リージョン全体で負荷のバランスをとり、トラフィックをさまざまなアベイラビリティーゾーンの正常なターゲットにリダイレクトできます。
• セキュリティ。 ELB は Amazon VPC と連携して、統合された証明書管理、ユーザー認証、SSL/TLS 復号化などのさまざまなセキュリティ機能を提供します。 これらをすべて組み合わせると、TLS 設定の一元的かつ柔軟な管理が可能になります。
• 弾性。 ELB は、ネットワーク トラフィックの突然の変化に対処できます。 また、Auto Scaling との緊密な統合により、負荷が変化した場合でも手動介入を必要とせずにアプリケーションに十分なリソースが提供されます。
• 柔軟性。 IP アドレスを使用して、リクエストをアプリケーションのターゲットにルーティングできます。 これにより、ターゲット アプリケーションを仮想化する際の柔軟性が向上し、単一のインスタンスで複数のアプリケーションをホストできるようになります。 アプリケーションは単一のネットワーク ポートを使用し、個別のセキュリティ グループを持つことができるため、たとえばマイクロサービス ベースのアーキテクチャを使用すると、アプリケーション間の通信が簡素化されます。
• 監視と監査。 Amazon CloudWatch 機能を使用して、アプリケーションをリアルタイムで監視できます。 私たちはメトリクス、ログ、リクエスト追跡について話しています。 簡単に言えば、問題を特定し、パフォーマンスのボトルネックを正確に特定できるようになります。
• ハイブリッド負荷分散。 同じロードバランサーを使用してオンプレミスのリソースと AWS の間で負荷分散できる機能により、オンプレミスのアプリケーションをクラウドに移行または拡張することが簡単になります。 クラウドを利用することで障害対応も簡素化されます。

詳細に興味がある場合は、Amazon 公式 Web サイトからさらに便利なリンクをいくつか紹介します。

1. 弾性負荷分散.
2. Elastic Load Balancing 機能。

出所： habr.com