Plexのスケーラビリティを実際に決めるものとは？

Plexは、必要な共有リソースのいずれかが長時間飽和し、再生やバックグラウンド処理、コントロールプレーンの応答性に支障をきたすまでスケールします。

Direct Play、トランスコード、ライブラリ処理、リモートアクセス、コンパニオンサービスはそれぞれ異なる経路に負荷をかけるため、「Plexのスケーラビリティ」を示す単一の数値はありません。まず通常時の最も負荷が高いシナリオを定義し、コンピュート、メモリ、アプリデータストレージ、メディアストレージ、ネットワークをまとめて観測します。繰り返し発生する最初のボトルネックが、次に行うアップグレードの有効性を決めます。

再生パターンから始める

Direct Playが消費するサーバーリソースは、動画変換が必要なセッションとは大きく異なります。そのため、再生パターンを考慮しないユーザー数は、最も重要な変動要因を隠してしまいます。

マルチユーザーのストリーミングシステムは、共有容量が同時に発生する需要を満たせなくなると制約を受けます。そのため、マルチユーザーストリーミングの競合は、固定されたユーザー上限ではなく、ワークロードの問題として扱う方が適切です。

同時に発生するDirect Playセッションとトランスコードセッションを分けて数え、そこに重なるバックグラウンドジョブを加えます。このマトリクスが、以降のすべてのスケールテストで再現すべき基準になります。

すべての共有リソースで飽和を測定する

アプリデータストレージにキューが発生している一方でCPUに余裕がある場合や、ソフトウェアトランスコードが1つの実行経路を使い切っている一方でネットワーク帯域幅に余裕がある場合があります。1つの使用率グラフだけを見ていると、実際の制約要因を見落とす可能性があります。

使用率・飽和度・エラーの手法は、リソースごとに「処理中」である状態と「これ以上の処理を受け入れられない」状態を区別する方法を提供します。容量計画で重要なのは、この違いです。

ピーク時のワークロードを、安定した動作を観測できる十分な時間実行し、最初にキューやエラーが発生するリソースを記録します。他の場所に容量を追加する前に、繰り返し制約となるリソースをアップグレードします。

構成によって限界となるリソースは変わる

ハードウェアアクセラレーション、トランスコードの配置、ライブラリ構成、ネットワークモード、コンパニオンサービスによって、CPU、GPU、ストレージ、ネットワーク間で処理の移動が起こります。そのため、同じハードウェアでも構成が異なれば限界値も変わります。

測定されたコンテナのI/Oオーバーヘッドはワークロードによって変動します。これは、Plexのバイナリが同じでも、分離方法やストレージ経路の選択によってリソースプロファイルが変わり得ることを示しています。

2台のサーバーを比較する前に、処理経路を大きく変える設定を記録してください。Plexのハードウェア要件チェックリストが役立つのは、ワークロードと構成を固定した後です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

復旧能力もスケーラビリティの一部

再生の需要はかろうじて満たせても、許容できる時間内にバックアップ、アップグレード、復旧を実行できないサーバーは、すでに実用上の限界に近づいています。成長すると、アクティブなセッションだけでなく、メンテナンス作業も増加します。

バックアップシステムでは、ストレージ容量と処理作業に対して、復旧時間、復旧時点、バージョン履歴のバランスを取る必要があります。復旧ポイントの選択により、バックアップを容量不要の処理として扱うのではなく、このメンテナンス面を明確にできます。

スケールテストには、バックアップのリハーサルを1回、復元のリハーサルを1回含めてください。再生より先に通常の復旧作業が目標を達成できなくなった場合、ストリームの再生が開始できていても、アーキテクチャは運用上の限界に達しています。