AWSスケーラブルアーキテクチャ設計

Question

現在、AWSインフラストラクチャを利用し、基本を学ぶ私の最初のWebアプリケーションを実装しています。私は設計上の問題にぶつかったので、私の問題を説明するために以下のシナリオが出てきました：

ウェブサイトをpdfとして保存/印刷してS3に保存するWebアプリケーションを作っていたとします。フロントエンドは単一のフォームを持っています。ユーザーは、pdfに保存するサイトのURLを入力し、[送信]をクリックします。アプリケーションは、指定されたURLのページをpdfに印刷し、そのファイルをユーザーに提示する必要があります。

アプリをスケーラブルにするには、送信をクリックすると、処理するURLを持つキューにSQSメッセージが送信されると想像してください。次に、この待ち行列から労働者の群が消費され、pd32 &がS3に格納され、S3キー/パスがSimpleDBに格納されます。私が抱えている問題は、ワーカーがWebアプリケーションに処理が完了したことを通知する方法です。

デザイン例：

私は、S3キーのエントリまで、Webアプリケーションは可能性が継続的にポーリングのSimpleDBを想像しかし、この解決策は少し不器用なようです表示されます。私はこれが一般的に遭遇するパターン/問題だと感じています。誰かがこれに対処する共通の方法を提供できますか？

さらに、クラウド内の一般的なデザインパターンに推奨されるリソースは、非常に有益です。

Answer 1

WebSocketのようなものを使用していない限り、私は問題ではありません。ユーザーがリクエストを行うと、Webアプリケーションは処理が完了したかどうか（またはエラーがあった場合）、SimpleDBを（前述のように）ポーリングします。 WebSocketのようなものでは、処理が完了したときに通知を受けるためにWebアプリケーションが購読する別のキューを持つことができ、それが完了したことをブラウザに通知することができます。

Answer 2

先ほどお話したように、フロントエンド以外のすべての問題を基本的に解決しました。バックエンドAPIをポーリングしてメディアが準備完了しているかどうかを確認する必要があります。私の会社では、上記のようにWebページのスクリーンショットをレンダリングするだけでなく、PDF、オフィスドキュメント、ビデオとオーディオをエンコードするjpgスナップショットも作成しています。

私たちはアップデートにajaxを使用し、1秒に数回pingしてから1秒に1回、数秒に1回、フォールバックするように設定してください。他の答えは、Websocketを使用することです。これは、データを「プッシュ」および「プル」できるサーバーへの永続的な接続です。しかし、ほとんどの人がajaxポーリングのアプローチを採用しています。 Apacheのような古い技術では、これは何千もの接続にとって大きな問題になるかもしれませんが、Nginx、Node、および中間キャッシュのようなものでは大したことではありません。

Answer 3

S3にオブジェクト（マーカーのような）を格納してから、単純なDBではなくS3をポーリングすることができます。こうすることで、SimpleDBに負荷がかかるのを避けることができ、ポーリングのパフォーマンスが向上します。

あなたはこのアプローチをWebアプリケーションインスタンスからポーリングしたり、ajaxレイヤーからポーリングしたりすることができます。 （後者は最良の選択ではありませんが、これらの呼び出しのエラーはサーバーに記録されません）