architecture - マルチリージョン時の AWS アーキテクチャ

Question

最近 AWS を紹介されましたが、本当に気に入りました。ただし、マルチリージョンのアーキテクチャについて、いくつかの質問 (ばかげているかもしれません) を自問しています。

アプリケーションがヨーロッパ人とアジア人によって使用されているとしましょう。私の最初のアイデアは、ヨーロッパに EC2 インスタンスを追加することと、ヨーロッパに静的データと SQS キューと ElastiCache を保持するための S3 バケットを追加することでした。ヨーロッパ人にとっては非常に速いですが、アジア人にとっては遅くなります。

これを解決するには、静的データ用の CloudFront を追加して、アジア人にも画像がすばやく提供されるようにします。ただし、サーバーへのリクエスト (Ajax リクエストなど) にはまだ遅延が発生するため、解決策は、シンガポール/東京リージョンにも EC2 インスタンスを追加することです。

ただし、新しい問題が発生します。リクエストが東京の EC2 インスタンスにディスパッチされた場合、ヨーロッパに保存されている SQS からメッセージを受信する必要がある場合、または ElastiCache データにアクセスする必要がある場合 => 再度のレイテンシ + リージョン間転送のコスト。では、アジアにも SQS と ElastiCache を追加する必要がありますか?

多分私は何かを見逃しており、リージョン間の AWS リクエストは超高速ですが、私が理解していることから、マルチリージョンで高速なエクスペリエンスが必要な場合は、基本的にすべてのサービスをすべてのリージョンで複製する必要があります (S3 を除く)。そのために CloudFront を使用できます。また、アジアの SQS ジョブがヨーロッパの S3 リソースにアクセスする必要がある場合、レイテンシーに耐えることができると思います)。

とにかく、私はこれを正しく理解しましたか？マルチリージョンを対象とするアプリケーションを構築する方法に関するリソースはありますか?

ありがとう ：）

Answer 1

これらはまったくばかげた質問ではありません。この部分は完全に正しいです：

Maybe I miss something, and cross-regions AWS requests are super-fast, but from
what I've understood, if we want fast experience for multi-regions, we basically
need to duplicate all services too every regions

リージョン間のリクエストは、光の速度とリージョン間のネットワーク トポロジによって制限されます。アジアからのリクエストは、約 1/4 秒の往復でヨーロッパのアプリケーションに到達すると予想されます。ほとんどのリクエストは高速になりますが、すべてが高速になるとは限らないため、それに応じて設計する必要があります。それが十分に高速でない場合は、はい、より近いリージョンにデプロイし、ユーザーを適切なリージョンにルーティングする必要があります。往復が必要な回数は、アプリケーションのアーキテクチャ次第です。Elasticache または SQS に多くのリクエストがある場合、これらの 1/4 秒はすぐに加算されます。リクエストをバッチ処理できる場合は、許容できる可能性があります。

ユーザーを適切なリージョンにルーティングするには、AWS ファミリーの別の部分である Route 53を確認する必要があります。Route 53 に関するこの発表では、必要になるリージョン間のレイテンシーベースのルーティングについて説明しています。ユーザーが適切な EC2 インスタンスにルーティングされたら、デプロイ先の各リージョンを分離する必要があります。EC2、SQS、Elasticache、およびすべてヨーロッパ リージョン (eu-west-1) から提供されるその他の AWS サービスを使用して、ヨーロッパのデプロイを構成します。アジアのデプロイでは、すべてを ap-southeast-1 リージョンでホストする場合があります。Route 53 がアジアのユーザーを ap-southeast-1 内の EC2 インスタンスに接続すると、SQS、Elasticache などへのリクエストは同じリージョン内にあるため、非常に高速になります。