ユーザーがファイルをアップロードして処理できる Web アプリケーションを計画しています。アプリケーションの詳細は私の質問には関係ありませんが、アプリケーションが mp3 オーディオ ファイルを処理すると仮定しましょう。アプリケーションをフロントエンドとバックエンドの 2 つの部分に分割します。
フロントエンド アプリケーションは、HTML ページをユーザーに提供する通常の Web アプリケーションです。通常、ユーザーは自分のファイルをアップロードし、html フォームに記入して、ファイルに対して実行したい操作を指定します。ファイルは最初に Amazon S3 などのストレージ施設にアップロードされ、後でバックエンド サーバーによって処理されます。私は Play 2.0.4 フレームワークを使用してフロントエンド アプリケーションを開発していますが、これは非常にうまくいっています。私はなんとかユーザー認証を実装し、ほとんどの UI を作成し、S3 へのファイルアップロードも実装しました。アプリケーションは現在、問題なく Heroku にデプロイされています。
私のバックエンド サーバーでは、もう一度 Play 2 フレームワークを使用することを検討しています。バックエンド サーバーは、フロントエンド サーバーから新しいジョブの作成に関する通知 (http 要求) を受け取ります。ジョブ仕様には、ストレージ内の元のユーザー ファイルへのリンクと、ジョブを説明する引数が含まれます。ジョブをキューに追加する必要があります。ここで最も重要な部分は、実際の処理ジョブをサードパーティ プログラムに委任することです。これは、SoXなどのコンパイル済みコマンド ライン ユーティリティであることが最も確実です。オーディオ処理の場合は、善良な人々が自分の選んだプログラミング言語を使用して作成します。私が知る限り、Java から外部プログラムを呼び出し、コマンド ライン引数を渡して結果を収集することが可能です。処理が完了すると、バックエンド サーバーは処理されたファイルをストレージにアップロードし、通知 (http 要求) をフロントエンド アプリケーションに送信します。フロントエンド アプリケーションは、処理されたファイルへのリンクを保存し、後でそれをユーザーに表示します。時間。コマンド ライン ユーティリティを使用できるようにするために、Typesafe スタック インストールを使用してバックエンド アプリケーションを Amazon EC2 インスタンスにデプロイします。
この基本計画に関する質問は次のとおりです。
- Play 2 はバックエンドの合理的な選択ですか、それとも別の方法を検討する必要がありますか? それらの 1 つが CGI であると思われます。ウィキペディアによると、これは「Web サーバー ソフトウェアが Web コンテンツの生成を実行可能ファイルに委任するための標準的な方法です」。残念ながら、私はその経験がありません。
- Play でジョブ キューを実装しても問題はないのでしょうか?
- コマンド ライン ユーティリティを EC2 にインストールして Play から呼び出すことはできますか?
- Typesafe スタックを EC2 にインストールする際に問題が発生することは予想できますか? この投稿では、私が何をしようとしているのかを簡単に説明しています https://www.assembla.com/spaces/bufferine/wiki/Typesafe_stack_on_Amazon_EC2
- 将来的にアプリケーションが成長すると仮定すると、EC2 上の複数のインスタンス間でジョブをどのように分割できますか? フロントエンドとバックエンドの間に別のジョブ バランシング アプリケーションを作成する必要がありますか?
アドバイスをいただければ幸いです。ありがとう！
注: 私は Scala 言語に慣れていないため、Play 2 フレームワークには Java API を使用しています。