複数のロードバランサーを使用してトラフィックをアプリケーションサーバーにリダイレクトすることはできますか？

ロードバランシングは初めてですが、複数のロードバランサーを使用してトラフィックをアプリケーションサーバーにリダイレクトできるかどうか疑問に思っています。どうすればいいのか分かりません。ドメイン名は、特定のサーバーのIPアドレス（この場合は1つのロードバランサーのIP）と1対1で一致する必要はありませんか？各ロードバランシングサーバーのIPが異なる場合、両方のロードバランサー（または10ロードバランサーまたは50または100）がリクエストをどのように受信できますか？

ラウンドロビンDNSの使用は、高可用性にとってそれほど優れたものではありません。1つのサーバーがオフラインになった場合でも、クライアントはそのサーバーに接続しようとしてタイムアウトを待ちます。

これを達成する他の方法があります。
1）アクティブ/パッシブロードバランサー
基本的に、1つのロードバランサーが1つのIPアドレスのすべてのトラフィックを処理します。
そのバランサーがダウンすると、パッシブノードが飛び込み、IPを引き継ぎます。
ロードバランサーはほとんどトラフィックを転送するだけなので、中小規模のサイトでは問題なく機能することに注意してください。

2）アクティブ/アクティブロードバランサー
両方（またはそれ以上）のロードバランサーで同じトラフィックIPが構成されます。
着信トラフィックはすべてのロードバランサーに送信されますが、アルゴリズムは応答するバランサーを選択し、他のすべてはそのトラフィックを破棄します。
簡単に考えると、ロードバランサーは2つあります。
要求元のIPが偶数で終わる場合、ロードバランサーAが応答し、そうでない場合、ロードバランサーBが応答します。

もちろん、インフラストラクチャがこれをサポートする必要があり、トラフィックが送信されても​​破棄されるためオーバーヘッドが発生します。
詳細は、たとえばここ：http : //community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

ロードバランサーによる高可用性は、複数のホスト（ロードバランサー）がいくつかの可能な方法（アクティブ/パッシブ、アクティブ/アクティブのバリエーション）の1つで1つの共通IPアドレスに応答できるようにする仮想IPアドレス（VIP）プロトコルを使用して実装されます。 。

これらのプロトコルにはかなりの数がありますが、通常のロードバランサーで最もよく見られるのはVRRPとNLBです（アプライアンスの多くの説明のないブラックボックスプロトコルも同様です）。ルーターやファイアウォールに拡張すると、たとえばCARP、HRSP、GLSPに遭遇することもあります。

この戦略には、DNS負荷分散よりも多くの利点があります。これは、より単純な戦略です（別の答えで対処されます）。

DNSロードバランシングは、たとえば次のような負荷がかかります。

• DNSキャッシングメカニズムのターンオーバーが遅い
• 制限された負荷分散アルゴリズム（通常はラウンドロビンのみ）
• クライアントへの負荷分散決定のアウトソーシング（dnsレコードのキャッシングによる）
• サーバー（つまり、ロードバランサー）がローテーションから外れると、サービスキューのドレインが遅くなります（ISPおよびクライアントによって処理される DNSレコードTTLに基づく）
• ロードバランサー障害時のフェイルオーバーが遅い

HAに仮想IPプロトコルを使用すると、たとえば、次のことを実現するための選択肢があります。

• ロードバランサー間のロードバランシングアルゴリズムの選択
• サーバー中心の負荷分散の決定（たとえば、サービスの状態に基づく測定とルーティングを容易にする）
• ロードバランサーがローテーションから外されたときのサービスキューのより速いドレイン。
• ロードバランサー障害時のインスタントフェイルオーバー

シナリオに最も適した戦略とプロトコルを知っているのはあなただけです。

要件：クラウドまたはハードウェアロードバランサー、BGPプロトコルなどにアクセスできない、あらゆる種類の環境で機能する実用的なソリューションを用意します。

アプリケーションの収入要求数は不明ですが、増加する負荷の期待に恐れずに応えるのに十分な高さである必要があります。

ログストアや検索アプリなど、同様の負荷の性質を持つアプリケーションを見つけましょう。私が見つかりましたものを。

彼らが望むこと：

1. コレクタ間で負荷を分散する
2. フォールトトレランスを提供し、コレクターの1つが停止した場合や問題が発生した場合でもデータの取り込みを継続できるようにします
3. ログ量の増加に合わせて水平方向にスケーリングします

彼らはELBについて何を試して学びましたか：

1. 期待どおりに機能しない
2. 負荷の増加による待ち時間の問題
3. 十分な監視機能がない
4. 制限が多すぎる（開いているポートとプロトコルの数）

Route53を選択した理由：

1. 「ラウンドロビンはかなり基本的な負荷分散ですが、効率の観点からはうまく機能します」
2. 「Route 53フェイルオーバーヘルスチェックを利用しています。」
3. 「コレクターに問題がある場合、Route 53は自動的にそれをサービスから除外します。お客様には影響がありません。」
4. Route 53では事前ウォームアップは不要

Route 53は、膨大なログボリューム、予測できない変動、およびビジネスの絶え間ない成長を考えると、Logglyが高性能コレクターを活用するための最良の方法であることが判明しました。これは、コレクターの主要な目的と一致します。ネットワーク回線速度でデータをゼロの損失で収集し、Logglyで使用するすべてのAWSサービスの弾力性から利益を得ることができます。

この特定の例は、一部のシナリオ（ログコレクター、広告サービスなど）でロードバランサーが冗長であり、「DNSヘルスチェックラウンドロビンソリューション」が非常にうまく機能することを示しています。

AWS が DNSフェイルオーバーについて言っていることを見てみましょう。

DNSフェールオーバーを使用すると、Route 53はWebサイトの停止を検出し、エンドユーザーを指定した代替またはバックアップの場所にリダイレクトできます。Route 53 DNSフェイルオーバーは、世界中の複数の場所から定期的にアプリケーションエンドポイントにインターネット要求を行うヘルスチェックに依存して、アプリケーションの各エンドポイントがアップしているかダウンしているかを判断します。

その手法はまた、ELB（メモのためだけに必要ではない）をより堅牢にします。これも、RR +ヘルスチェックに基づいています。

Route 53 DNSフェイルオーバーは、舞台裏でELBと統合することにより、これらすべての障害シナリオを処理します。Route 53が有効になると、個々のELBノードのヘルスチェックが自動的に構成および管理されます。

それが舞台裏でどのように機能するか見てみましょう。明らかな問題は、DNSキャッシングの処理方法です。

ただし、クライアントとRoute 53の間のすべてのレイヤーでTTLが尊重されていない場合、DNSキャッシングはここでも問題になる可能性があります（「ロングテール」問題がカバーされている以前の投稿を参照）。次に、「キャッシュ無効化」手法を適用できます。固有のドメインにリクエストを送信する

("http://<unique-id>.<your-domain>") 

ワイルドカードリソースを定義します

Record "*.<your-domain>" to match it.

Algolia は、「クライアント再試行戦略」を導入しました。これは、クライアント（あなたの場合はJS）がそれを処理できる場合に非常にうまく機能します。

最終的に、APIクライアントに基本的な再試行戦略を実装しました。各APIクライアントは、3つの異なるマシンにアクセスできるように開発されました。各ユーザーを表す3つの異なるDNSレコード：USERIDID-1.algolia.io、USERID-2.algolia.ioおよびUSERID-3.algolia.io。最初の実装では、レコードの1つをランダムに選択し、失敗した場合は別のレコードで再試行しました。