AWSでのリージョン間でのシャーディングとアプリケーションルーティング
現在、SQL SERVERバックエンド（AWSのEC2でホストされているセルフ）を備えた非常にシンプルなマルチテナントモノリスと、クラシックAWS ELBの背後にある1つのDBと通信する複数のアプリケーションサービスがあります。さまざまな地域での増加とレイテンシの問題に加え、ダウンタイムメンテナンスウィンドウの考慮事項により、データベースを地域ごとのテナントごとに分割することを検討しているところまで成長しました。また、既存のリンクなどにより、両方のリージョンで同じDNS ... www.domain.comを維持したいと考えています...
今検討中
- Cloudfrontを使用して、一種のエッジプロキシとして、サービスの前で地理ベースのルーティングと基本的なcdnキャッシングを実行します。
- テナントの場所に基づいて、2つの主なリージョン、つまりオーストラリアと北米にシャードSQLサーバー。
- アプリケーションサービスは、別々のデータベースを持つ両方のリージョンに存在します。
- 断片テーブルがdynamodbグローバルテーブルまたはs3のどこかにある場合、テナントが数百未満であり、ほとんど不変であるため、長期間キャッシュできます。
メインの灰色の領域、ルートが間違った地域/データベースに行く場合、どうすればよいですか？
たとえば、私が持っていると言う
- オーストラリアのテナント1〜10
- 米国のテナント11〜20
テナント1は休暇中にアメリカに行き、ジオルーティングに基づいてwww.domain.comにアクセスしようとしました。彼はアメリカのデータセンターにルーティングされ、アメリカのデータベースには彼のデータが含まれていません。私が考えていた
- ログインユーザーに基づいて、（アプリケーションサービスで）テナントを特定できるため、シャードテーブルの検索に基づいて、彼が間違ったリージョンにログインしている場合は、304リダイレクトに応答します。 、それでおそらくクラウドフロントは、追加のリダイレクトロジックを読み取って実行できるEdgeのラムダで？それが可能か、それとも良い解決策かはまだはっきりしていません。
その周りのベストプラクティスは何ですか？私はそれが解決された問題だと思いますが、ググリングのスキルが悪い例ではこれ以上実用的なものを見つけることができません。それらのほとんどはシャードテーブルの理論などです...
何かアドバイスをいただければ幸いです。
メインの灰色の領域、ルートが間違った地域/データベースに行く場合、どうすればよいですか？
それらを正しいDBに再ルーティングします。シンプルに思えます。だが...
テナント1は休暇中にアメリカに行き、ジオルーティングに基づいてwww.domain.comにアクセスしようとしましたが、彼はアメリカのデータセンターにルーティングされ、アメリカのデータベースには彼のデータが含まれていません。
...氷山の一角です。あなたがその問題を解決したとしましょう。その後...
テナント2は米国に行き、それを気に入って滞在することに決めました。しかし、今そして永遠に、あなたのサービスが本当に遅れていることに気付くでしょう。
必要なのは、ジオルーティングの失敗を自宅への再ルーティングに変え、一定量のジオルーティングの失敗後にデータを移行するシステムです。このようにして、真に分散されたシステムを持たないことによって本当にいらいらする人々は、頻繁にチラシになります。
どの時点で、「頻繁なチラシをどれだけ気にしますか？」と尋ねる必要があります。