私は、多くの CPU バウンド バックグラウンド処理を伴うレガシー システムへの Web アプリケーション フロントエンドに取り組んでいます。アプリケーションはサーバー側でもステートフルであり、ドメイン オブジェクトは、ユーザーが Web ベースのインターフェイスを介して操作するため、セッション全体にわたってメモリに保持される必要があります。各フィルターがサーバー側で実行されるのに 20 ～ 30 秒かかる可能性がある、Photoshop の Web UI フロント エンドのようなものと考えてください。そのため、ユーザーが待機している間、アプリはリアルタイムでユーザーとやり取りする必要があります。
主な問題は、サーバーの各インスタンスが一度に各「ワークスペース」の約 4 ～ 8 個のインスタンスしかサポートできず、一度に数百人の同時ユーザーをサポートする必要があることです。自動スケーリング機能を利用するために、これを Amazon EC2 で構築します。要約すると、システムは次のとおりです。
- レガシー バックエンド システムへの Web アプリケーション フロントエンド
- 実行されるタスクは CPU バウンドです
- ステートフル、ほとんどの呼び出しはある種の RPC になります。ユーザーは、サーバー側のメモリに保持されているステートフル オブジェクトと対話する複数のアクションを実行します。
- ほとんどのタスクはセミリアルタイムであり、20 ～ 30 秒間実行し、同じセッションで結果をユーザーに返す必要があります。
- amazon aws Auto Scaling を使用する
このようなシステムを分散型にする最善の方法は何だろうと思っています。
明らかに、ブラウザーと対話し、CPU にバインドされたタスクを Web サーバーからバックグラウンド処理を行う一連の専用サーバーに送信するには、Web サーバーが必要です。問題は、私の特定のニーズに合わせて 2 つの層を最適に接続する方法です。
私は rabbitMQ などのメッセージ キュー システムを見てきましたが、これらはワーカー ノードが単純にキューからジョブを取得して実行し、状態を忘れることができる 1 回限りのタスクを対象としているようです。たとえば、ステップ 1 がノード 1 で開始された場合、同じワークスペースのステップ 2 は同じワーカー プロセスに移動する必要があります。
私が目にするもう 1 つの問題は、ほとんどのワーカー キュー システムが、私が扱っているユーザー フィードバックを提供しなければならないシステムではなく、いつでも処理できるバックグラウンド タスクを対象としているように見えることです。
私の質問は、スケーリング可能なシステムを簡単に構築できる、このようなものに対する既製のソリューションはありますか? ご意見をお待ちしております。