ユーザーを場所に基づいて別のサーバーにリダイレクトするにはどうすればよいですか？

ASP.NETを使用して開発されたWebサイトがあり、MY DBはMySQLです。現在、USAサーバーでホストされています。しかし、インドの近くでアクセスしようとすると、動的コンテンツの読み込みが遅すぎます。リクエストは世界の別の側に行かなければならないので、それは受け入れられます。アメリカでは本当に速いです。このサイトはすでにcloudflare CDNに接続しています。ただし、CDNは静的コンテンツに役立ちます。私のすべてのページはほとんど動的なコンテンツを持っています。

だから私はこのウェブサイトをスケーリングしたいと思います。したがって、リクエストがアメリカから来た場合、USAサーバーからのリクエストを処理し、ASIAからリクエストが来た場合、ASIANサーバーから処理したいとします。ただし、リダイレクト先のコンテンツが2つのサーバー上で同じであることを忘れないでください。（2つのサーバーを同期する必要があります）

では、このアーキテクチャを実現するにはどうすればよいでしょうか。

グーグル、フェイスブック、ヤフーはこれをどのように行うのですか？彼らはどのようにして世界中に奉仕しますか 彼らはすべての大陸にデータセンターを持っていると思います。それらはどのように互いに同期しますか？

@ Gabriel-Talaveraの回答に加えて、いくつかのメモを追加します。

• ネットワークルーティングと地理的負荷分散は、異なるサーバー間の「データ同期」とはまったく無関係です。それらは、非常に多くの非常に異なるテクノロジーで対処される2つの問題です。

質問のタイトルはネットワーキング側に集中しているようなので、最初の部分（ネットワークルーティングの問題）に集中します。

• 厳密なネットワーキングの観点から、「エニーキャストアドレッシング」を使用すると、複数の場所/データセンターに負荷を分散できます。エニーキャストに関する有用な議論は、この他のSFの投稿で取得できます。
  • 「エニーキャスト」とは何ですか？どのように役立ちますか？
  • エニーキャストIPを使用するには何が必要ですか？

ご自分でお分かりのように、小規模なICT企業では要件を満たすのは困難です。しかし、「グローバル」企業（OPで言及した企業など）は、それを採用しても問題ありません。

余談ですが、私が初めて「エニーキャスト」について聞いたのは、CloudFlare BLOGの投稿のおかげでした（彼らは（他の多くのものの中で）、どのようにエニーキャストもD-への対策として採用できるのか）について話し合いました。 DOS攻撃。

BINDを外部DNSサーバーとして使用している場合は、BINDビューで場所に基づいて選択的なDNS応答を提供できます。Windows Serverの新しいバージョンのテクニカルプレビューには、DNSポリシーと呼ばれる機能があり、非常に有望に見えます。

クライアントの場所とユーザーエージェントやスケジュールなどの他の基準に基づいてコンテンツを提供するために、F5にはグローバルトラフィックマネージャーと呼ばれるアプライアンスがあり、ロードバランサーと組み合わせて使用​​することで目的の機能を実現します。クラウド環境では、AmazonのRoute 53でも同じことができます。

データの同期を維持するには、同期レプリケーションを実行できるストレージバックエンドを用意するか、MySQLによって提供されるレプリケーションを使用する必要があります。これにより、レプリケーションデータの一貫性が維持されます。

あなたがしたい状況があります：

• データの整合性により、シリアライズ可能なトランザクションが保証されます。
• ユーザーはグローバルにデータを更新できます。
• データは低レイテンシで更新できます。

残念ながら、上記のすべてを組み合わせることは物理的に不可能です。あなたは光の速度によって制約されます。

代わりに、正確な要件を検討する必要があります。一部のデータでは、制限された精度で十分です。YouTubeビデオのビューカウンターを検討してください。ほとんどの人は、ビューカウンターが一時的に少しずれていても気にしません。世界の反対側で10秒前に発生したビューがまだ含まれていないが、5秒前に近くで発生したビューが含まれている場合でも、十分に正確です。ビューカウンターの整合性でリラックスしている場合は、2人の異なる人物が両方とも、その特定のビデオの視聴者数100であると考える可能性があります。しかし、ほとんどの人はそれによって引き起こされる害は無視できると考えます。

他の場合では、データの整合性がより重要です。2人が同じユーザー名で同時にサインアップしようとしていると考えてください。両方のユーザーにユーザー名を取得したことを伝えることは受け入れられないため、このような状況では、より完全性の高い低速のアプローチを選択します。ユーザー名が取得されたことを両方の人に伝えることは許容されます。したがって、可能なアプローチは、各レプリカでユーザー名を予約して、レプリカの50％以上で成功した場合にのみ成功を報告することです。このアプローチでは、ユーザーが応答を受け取るまで0.5秒待機する可能性があります。しかし、ユーザーは、この遅延を気にするほど頻繁にこのプロセスを実行することはありません。

さらに他のケースでは、完全性と高速な更新が必要な場合がありますが、この特定のデータを更新できるのは1人だけです。その場合、そのユーザーの近くにあると思われるサーバーにデータの信頼できるコピーを配置し、他のサーバーにキャッシュバージョン（ほとんどが最新）を持たせることができます。