サーバーがダウンしたときのダウンタイムを短縮するために、Amazon Elastic Load Balancing (ELB) の使用を検討しています。基本的に、関連する DNS レコードを変更して DNS が世界中に伝播するのを待つのではなく、トラフィックを自分のアプリを提供する別のマシンにリダイレクトしたいだけです。
ただし、私のサーバーのほとんどは EC2 インスタンスではなく、Amazon とは何の関係もない会社の VPS または専用サーバーです。
Amazon のサービス (特に ELB) を組み合わせて使用し、ドメイン名を Elastic Load Balancer にポイントし、Amazon ネットワーク外の 1 ～ 2 台のサーバーにリクエストを転送することは可能ですか?
バランサーのIPが変更された場合、これは明らかに機能しません（ルートドメイン名を指定できません）。ただし、バランサーにエラスティックIPを割り当てて、それからドメイン名をそれにポイントし、リクエストを Non-Amazon-PrivateServer1 および Non-Amazon-PrivateServer2 に転送するように設定しますか?
答え1
ELB は EC2 インスタンスにのみトラフィックを送信します。
実際のサーバーへのトラフィックを ELB プロキシする背後に nginx EC2 インスタンスをいくつか配置することもできますし、単純な方法で DNS TTL を 10 分程度に下げて変更をより迅速に反映させることもできます。
答え2
2017年8月31日現在、アプリケーションロードバランサーは、インスタンスIDに加えてIPアドレスをターゲットとしてサポートします。:
アプリケーション ロード バランサーが、インスタンス ID に加えて IP アドレスをターゲットとして使用して、AWS リソースにトラフィックを分散できるようになりました。また、ロード バランサーをホストしている VPC の外部のリソースに IP アドレスをターゲットとして使用して負荷分散することもできます。これには、ピアリングされた VPC、EC2-Classic、および AWS Direct Connect または VPN 接続経由でアクセスできるオンプレミスの場所にあるリソースが含まれます。同じロード バランサーを使用して AWS とオンプレミスのリソース間で負荷分散を行うと、クラウドへの移行、クラウドへのバースト、またはクラウドへのフェイルオーバーが簡単になります。
答え3
これには、ヘルスチェック機能を備えた Route53 を使用しないのはなぜでしょうか?
まず、各サーバーに対して IP ベースのヘルス チェックを作成します。これらのチェックは単純なもので、特定のリクエストの HTTP 200 ステータスを監視するだけのものもあれば、リクエスト結果内の特定の文字列を検索するより高度なチェックを作成するものもあります。
次に、まだ行っていない場合は、Route53 で使用しているドメインのホストゾーンを作成し、ドメインのレジストラに Route53 が割り当てた DNS サーバーを提供します。
それが完了したら、リクエストを分散するサーバーごとに、たとえば「重み付け」タイプ、短い TTL (60 以下) を使用してレコード セット (作成したホスト ゾーン内) を作成し、「ヘルス チェックとの関連付け: はい」を選択して、レコードを作成する特定のサーバー/IP に対応する上記で作成したヘルス チェックを選択します。再度、各サーバー/IP に対してこれを繰り返します。
最終的に、それぞれ 1 つの IP を持つ複数のレコード セットが作成され、すべてが Route53 内の同じドメインに関連付けられます。DNS 要求があると、Route53 は、割り当てられた重みと各ヘルス チェックの現在のステータスに基づいて、それらの 1 つを返します。ヘルス チェックが失敗すると、その特定の IP は省略されます。
他の Route53 レコード セット タイプを使用してこれを行うこともできます。たとえば、「フェイルオーバー」では、1 つ以上のプライマリ IP と 1 つ以上のセカンダリ IP があります。Route53 は、プライマリ IP のヘルス チェックが失敗しない限り、常にプライマリ IP の 1 つを返し、その後、セカンダリ IP の 1 つに切り替えます。
また、Route53 には、レイテンシー、ジオロケーション、マルチ値など、ヘルスチェックと組み合わせることができるより複雑なレコードタイプもあります。これらはすべて、AWS ドキュメントで非常にわかりやすく説明されています。