リソース負荷の高いアプリ向けに1台のPlexホストを設計する方法

1台のPlexホストでリソース負荷の高いアプリを共有することはできますが、レイアウトは総合的な利用率を最大化する前に、再生とPlexの状態を保護できるように設計すべきです。

最もすっきりした設計は、役割を分離することから始まります。Plexの再生とアプリデータ、大容量メディア、ダウンロードまたはインデックス作成のジョブ、バックアップ、そしてCPUまたはGPU負荷の高いサービスを分けます。役割が明確になれば、共有できるリソース、制限が必要なリソース、異なる時間帯に実行すべきワークロードを判断できます。

リソース制限を設定する前に役割を割り当てる

各サービスに、区別のないコンテナの集合ではなく、明確なワークロードを定義すると、共有サーバーは運用しやすくなります。Plexには予測可能なアプリデータのレイテンシと、トランスコード処理の短時間のバーストが必要になる一方、ダウンローダーやバッチジョブは遅延を許容できます。

ダウンローダー、インデクサー、リクエストツールの隣にPlexを配置する複数サービスのメディアスタックでは、共有ストレージパスとワークフローのタイミングが明確になります。

通常時で最も忙しい時間帯に、各サービスがCPU、メモリ、ストレージ、ネットワーク、アクセラレーターへかける可能性のある負荷を書き出します。2つの役割が同時に実行される場合にのみ競合するなら、ハードウェアの分離が必要になる前に、スケジューリングで問題を解決できる可能性があります。

Plexのレイテンシ経路を保護する

Plexの再生は、アプリデータの経路がリソース不足になるよりも、ホスト全体がビジー状態になることのほうが許容しやすい場合があります。データベース、メタデータ、キャッシュの処理は、大容量メディアのコピーよりも小規模でレイテンシに敏感なため、バックアップやダウンロードによる書き込みと無制限に競合させるべきではありません。

Dockerはデフォルトでは公平なリソース共有を行いません。明示的なCPU、メモリ、I/Oの制限を設定すれば、バースト発生時に1つのサービスがホストのリソースをすべて消費するのを防げます。

Plexの状態データは予測可能なデバイスに配置し、代表的なストリーム再生中のストレージレイテンシを測定します。その後、最も負荷の高い関連ジョブを実行しながら同じテストを繰り返します。CPUやネットワークが飽和する前にアプリデータの経路が遅くなる場合は、まずそのストレージの役割を分離してください。

ハードウェアを分割する前にバースト処理をスケジュールする

バックアップ、メディアスキャン、ローカルAIジョブ、大規模なインポートは、限られた時間帯に大量のリソースを必要とすることがあります。瞬間的なレイテンシよりも完了時間が重要なため、これらはスケジュール実行に適しています。

ホスト全体の利用率、飽和度、エラーの確認を行うと、同時実行されるすべてのジョブに別のマシンが必要だと決めつけるのではなく、実際にCPU、メモリ、ストレージ、ネットワークの処理がキューに入っているかを特定できます。

バースト処理のジョブを1つ、通常の視聴時間帯以外に移動し、同じPlexワークロードを再度実行します。スケジューリング後も安定する設計は、早すぎる2ホスト構成への分割よりもシンプルです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

一方の役割がもう一方を繰り返し劣化させる場合はホストを分割する

必要な高負荷サービスが、適切なスケジューリングとリソース制御を行ってもPlexの性能を低下させる場合、または両方のワークロードを同時にピーク状態で実行する必要がある場合は、分離する価値があります。

メディアサーバーのコンピューティングと高負荷ワークロードを分離するトポロジーなら、コンピューティングの要件が変わるたびにメディアライブラリを移動することなく、それぞれの役割を個別にアップグレードできます。

ピーク時のテストが、合意したレイテンシと再生の目標範囲内に収まるなら、単一ホストを維持してください。同じ測定済みの競合がスケジューリングと制限を行っても解消されない場合にのみ、コンピューティング、ストレージ、またはアクセラレーターの役割を分離します。