負荷を分散する動的サービス作成

Question

背景

私たちが直面している問題は、ビデオエンコードを行い、クラスタ内の複数のノードに負荷を分散したいということです。

特定のノードのビデオエンコードジョブの数を最大限に制限したいと考えています。小さなビデオエンコーディングジョブをクラスタ内の特定のノードグループに送信し、長いビデオエンコーディングジョブをクラスタ内の別のノードグループに送信することもできます。

これは、大きなジョブを別々のノードのプールに分割することで、クライアント間の公平性を維持することを目的としています。これにより、小さなエンコードジョブが長いエンコードジョブを実行している1人のテナントによってブロックされたり抑制されたりしないようになります。サービスファブリック

を使用して

は、我々は、ビデオ符号化のためのASFサービスを使用する予定。これを念頭において、各ジョブのサービスを動的に作成するアイデアがありました。配置制約を使用して、ジョブを実行するノードのプールを決定できます。メモリ使用量、CPU使用率に基づくカスタムメトリックノード上のアクティブ・ジョブの数を制限するために使用できます。

この方法では、ジョブを配布するノードは、配置制約とメトリックを満たす新しいサービスを現在作成できるかどうかをポーリングする必要があります。

質問

• サービスがノード上に置くことができないときはどうなりますか？ （私はCreateServiceAsyncを使用しますか？）
• このポーリングは非常に高価でしょうか？

• 私たちのビデオエンコード実行ファイルは、約80MBのサービスと共にパッケージ化されています。これにより、新しいサービスのスピンアップには長い時間がかかりますか？ （分/秒）

• これに代わる方法として、大きなジョブプールが1つのキューからプルし、小さなジョブプールが別のキューからプルする信頼性の高いキューベースのシステムを使用できます。これはもっと簡単な方法ですが、Service Fabricの機能のいくつかを逃していないことを確認するために、すべてのオプションを調べたいと思います。あなたが提案する別のよりよい方法がありますか？

Answer 1

私はプレースメントの制約とダイナミックサービスに関する経験がないので、私はそれについて話すことはできません。

perfカウンタのポーリングは非常に高価ではなく、自由な操作ではないと言われています。 1秒間のポーリング間隔は、妥当な程度の分解能を提供しながら、巨大な鉛の影響を引き起こすべきではありません。

サービスがスピンアップするのではなく、展開時にサービスパッケージが各ノードにコピーされるため、展開が少し遅くなりますが、サービスの作成には影響しません。

あなたは構造化された方法で信頼できるコレクションにジョブデータを入れたいと思っていますが、問題はどのようなものかです。私が今考えていたのは、ジョブ処理サービスを分割サービスにして、エンジニアリングジョブのサイズやテナントに基づいてパーティショニング戦略を立てることです。同じテナントからの大きなジョブが同じキューに滞留し、他の人のための仕事は他の場所に行く。

私が過去に扱ったことの1つは、SFリモーティングが送信されたメッセージのサイズを制限し、そのサイズが大きすぎるとスローすることです。そのため、ビデオファイルがサービスからサービスに渡されている場合は、サービス間通信のためのページング戦略を検討したいと考えています。