0

AWSの複数の領域に展開する必要のある単純なWebアプリケーションを作成しています。アプリケーションには、別のサービスによって管理されるいくつかの動的構成が必要です。このサービスを通じて設定が変更された場合、これらの変更をすべての地域のすべてのWebアプリケーションインスタンスに伝播する必要があります。S3を使用してアプリケーション構成ファイルを保存する

これを行うには、DynamoDBでクロスリージョンレプリケーションを使用することを検討しましたが、すべてのリージョンとレプリケーションコンソールでDynamoDBを実行するための追加コストがかかりません。それから、本質的に交差領域であるS3を使用するという考えが私に起こりました。

基本的に、設定サービスはすべての設定を静的なJSONファイルとしてS3に書き込みます。各Webアプリケーションインスタンスは、最後にチェックされた設定ファイルが変更されたかどうかを定期的に確認し、必要に応じて新しい設定をダウンロードします。設定の変更は時間の影響を受けないため、5/10分ごとに変更をポーリングすれば十分です。

以前にアプリの設定を管理するために同様のアプローチを使用したことがありますか?これは賢明な解決策だと思いますか、それとも良い推奨事項はありますか?

+2

S3は「本質的に交差領域」ではありません。すべてのバケットは特定の領域にあり、そのバケットからのオブジェクトの要求は、その領域内のエンドポイントからのみ提供されます。 'bucket-name.s3.amazonaws.com'構造は統一されたサービスの外観を示しますが、それはS3が独自のDNSを更新して各バケットのサブドメインを実際の正しい地域エンドポイントに向けるためです。また、必要に応じて地域ごとにすべてのサービスにアクセスすることができますが、待ち時間やデータ転送料金が懸念されます。 –

答えて

1

この構成に適したツールは、構成のサイズと必要な細かさによって異なります。

単一領域内のDynamoDBとS3の両方を使用して、すべての領域でアプリケーションを処理できます。すべてのリージョンからS3の設定ファイルを読み込み、すべてのリージョンから1つのDynamoDBテーブルから設定レコードを読み取ることができます。世界中の距離に起因するレイテンシがありますが、設定を読むためにはそれほど大きな問題ではありません。

設定をロードするたびに設定全体が必要な場合は、S3を使用する方が適切な場合があります。しかし、大規模な構成の小さな部分を、アプリケーションのさまざまな部分で異なる時間とスケジュールで読み込む必要がある場合は、DynamoDBに格納する方が理にかなっています。

どちらのオプションでも、S3のテキストファイルのコストとそのファイルへの取得コストがほとんどないため、構成のコストはわずかです。 DynamoDBでは、わずか数KBのデータしかなく、1秒あたりの読み取り回数が非常に少ないため、同じ低コストが期待されます(1秒あたり5読み取り容量で十分です)。データをすべての地域に複製することを決定したとしても、それはまだほとんど無料です。

1

私が書いたアプリケーションは、あなたが提案した方法とまったく同じ方法で動作しますが、それは素晴らしいものです。それが指摘したように、S3は「本質的にクロスリージョン」ではありませんが、複数のアベイラビリティゾーンにわたって本質的に耐久性があり、クロスリージョンレプリケーションと組み合わせても十分です。

私の場合でも、アプリケーションは設定の変更に時間的に敏感ではありませんが、アプリのポーリングは定期的に実行されます(私の場合、1時間に1回または長時間実行されるすべてのジョブ)、私はまた、各アプリケーションをSNSエンドポイントに購読させて、S3で設定ファイルが変更されたときにSNSイベントが発生し、変更が発生したことをアプリケーションに通知する場合があります。何らかの理由でSNSイベントを直ちに処理できない場合、サーバが再起動したときや最悪の場合、S3を60分ごとにポーリングすることによって、毎時の最上位に「追いつく」でしょう。

関連する問題