AWSに最近紹介されたので、本当に好きでした。しかし、私はマルチリージョンのアーキテクチャについていくつか質問しています(それはばかげているかもしれません)。マルチリージョンのAWSアーキテクチャ
たとえば、ヨーロッパ人とアジア人がアプリケーションを使用しているとします。私の最初のアイデアは、欧州ではEC2インスタンスを追加するだけでなく、静的データを保持するS3バケットとヨーロッパではSQSキューとElastiCacheを追加することでした。ヨーロッパ人にとっては驚くほど速くなるが、アジア人にとっては遅くなるだろう。
これを解決するには、静止画像データにCloudFrontを追加して、アジア人向けに画像をすばやく配信できるようにします。しかし、サーバへのリクエスト(Ajaxリクエスト...)にはまだまだ待ち時間があるので、解決策はEC2インスタンスをシンガポール/東京地域に追加することです。
しかし、新しい問題が発生します:東京EC2インスタンスにリクエストがディスパッチされた場合、ヨーロッパに保管されているSQSからメッセージを受信する必要があるか、ElastiCacheデータにアクセスします。 。だから、アジアにもSQSとElastiCacheを追加する必要がありますか?
多分、私は何かを見逃しています。また、AWSの要求は超高速ですが、私が理解したところでは、マルチリージョンの高速体験を望むならば、基本的にすべての地域をすべて複製しなければなりませんS3はCloudFrontを使用できるので、アジアのSQSの仕事がヨーロッパのS3リソースにアクセスする必要がある場合は、レイテンシを保つことができます。
とにかく、私はこれを正しく理解しましたか?マルチリージョンをターゲットとするアプリケーションのアーキテクチャーに関するリソースはありますか?
ありがとうございました:)
あなたの答えをありがとう。 2つのSQSキュー(東京地域とアイルランドに1つずつ)があるため、EC2で2つの異なるアプリケーションを適切なSQSキューに接続する必要がありますか?または、ルート53は、場所に基づいて正しいSQSキューにディスパッチするのに十分なほどスマートですか? –
SQSへの生産はルート53を経由しないため、アプリケーション内から正しいキューを生成する必要があります。 Route 53は、レイテンシに基づいて最寄りのエンドポイントにリクエストを送信します(これを設定する方法を前提とします)。アプリケーションは両方のキューから消費することができますが、リモート領域にあるキューの方が時間がかかります。 –