動的で静的なコンテンツを配信するための分散アーキテクチャの仕組み

Question

これは私のシナリオです。

マップタイルサーバーでは、さまざまなズームレベルで数千のマッピングタイルが作成されています。現在、これは1つのEC2インスタンスで実行されています。私はAWSに固執したいと思います。

現在のワークフロー - タイルの要求が来ると、nginxはそのタイルがキャッシュに存在するかどうかを確認します。タイルが存在する場合、それはそれを提供する。存在しなければ、要求をタイル作成スクリプトに渡します。タイル作成スクリプトは、新しく作成されたタイルをユーザーに提供し、将来使用するためにキャッシュします。これは、たくさんのタイルを作成する必要があるときに、動きが激しくなり始めています。

これは、タイルがs3から提供され、存在しない場合、タイルを作成してs3にキャッシュする任意の数のセロリのタスクによってレンダリングされます。

私の最初の考えは、物のタイル作成側にELBを設定し、タイルキャッシュ用にs3を設定することでした。問題は、レンダリングするためにELBに送る前にs3にタイルが存在するかどうかをチェックする方法です。 ELBの前にs3を確認するためのtry_filesディレクティブでnginxを設定しようとしました。これはうまくいきませんでしたが、私はs3でタイルをプロキシすることができました。

私の質問は、このようなユースケースは通常AWSアーキテクチャで管理されていますか？要求が到着し、保管場所が存在しない場合は保管場所がチェックされ、作成されて返却されます。

ありがとうございました。

Answer 1

Nginxがどのように設定されているかは完全にはわかりませんが、マップタイルがまだ存在するかどうかを確認できる動的なバックエンドプロセスを常に実行するように設定する必要があるようです。そのプロセスは、存在しない場合はタイルを作成し、次にタイルを返します。 HTTP応答をキャッシュして、同じタイルが何度も存在するかどうかをチェックすることなくプロセスが停止することを防ぐことができます。

このようなプロジェクトを最初から開始していたのであれば、恐らくDynamoDBの各マップタイルに関する情報を格納するデータベースを作成することになります。そのデータベースには、作成された各タイルのレコードが含まれます。リクエストを受け取ったら、まずデータベースルックアップを実行して、タイルのS3位置を取得します。データベースレコードを返さない場合は、タイルを作成し、それをs3にアップロードし、データベーステーブルを更新してタイルを返します。ロードバランサの背後でこれらのサーバをたくさん稼働させ、負荷が増えるにつれて追加することができます。

私はRedis（ElastiCache）を使用してデータベースクエリ結果を保存して、同じタイルの後続要求を高速化します。私はまた、CloudFrontやCloudFlareのようなCDNを、すべてのものの前に置いて、実際にキャッシュをアップして、同じタイルに対する後続のリクエストがあなたのサーバにも届かないようにします。