ローカルユーザーとリモートユーザーの両方に対応するPlexの設計方法

ローカルユーザーとリモートユーザー向けのPlex環境では、LAN再生とWAN配信を、メディアと状態を共有しながらもボトルネックが異なる2つの経路として扱う必要があります。

ローカルユーザーは通常、低遅延とダイレクト再生を重視します。一方、リモートユーザーでは、パブリックな到達性、アップロード帯域幅、クライアントの多様性、トランスコードの増加といった要素が加わります。サーバーの状態管理とストレージのレイヤーは1つにまとめ、そのうえで2つの配信経路を個別に検証しましょう。これにより、リモートアクセスの回避策によってローカル再生が低下したり、不要な変換が発生したりするのを防げます。

LAN経路はシンプルかつ高速に保つ

ローカルクライアントは、パブリックプロキシやWAN経路に依存せずにPlexへ接続できるようにします。これにより、インターネット経路に問題が発生しても再生を継続でき、ダイレクト再生の診断も容易になります。

ローカルPlexアクセスは通常のリモートアクセスとは依存関係が異なるため、個別にテストする必要があります。

パブリック経路を意図的に利用できない状態にして、ローカルDNS、サーバーへの直接到達性、既知のダイレクト再生対応ファイルをテストします。WANレイヤーを取り除くとローカル再生に失敗する場合は、リモート機能を追加する前に、検出とルーティングをシンプルにしましょう。

WAN経路には独自の到達性設計を用意する

リモートクライアントがサーバーへ接続するには、NAT、プロキシ、プライベートトンネルのいずれかを通じた明確な方法が必要です。選択した方法によって、ファイアウォール、検出、証明書、トラブルシューティングに関する責任範囲が変わります。

Plexの直接リモートアクセスは、NATの条件、転送ルール、外部ネットワークからの検証に依存します。

主要なリモート経路を1つ選び、ユーザーを招待する前に、携帯電話回線または別の外部ネットワークから検証します。経路が文書化されていないフォールバックやリレーに依存している場合は、リモート品質を調整する前に到達性の問題を解決しましょう。

アップロード帯域幅とトランスコードを合わせて見積もる

リモートの帯域幅制限によってストリーム品質を下げる必要が生じると、サーバーのトランスコード負荷が増えることがあります。そのため、WANレイヤーとコンピュートレイヤーは、1つの経路として容量テストを行う必要があります。

リモート4K Plexストリーミングには、持続的なアップロード帯域幅が必要であり、サーバー側の変換が発生することもあります。

想定される最高品質のリモートストリームを、一般的なローカルストリームが動作している状態で実行し、アップロード帯域幅、CPU/GPU使用率、再生の安定性を測定します。ローカルのアクティビティを停止したときだけリモート品質が安定する場合、共有ホストまたはWANリンクには、両方を同時に処理するための余裕がありません。既知のリモートPlexストリーミングのワークロードをWANテストとして使用し、同じサーバー上ではローカルのダイレクト再生セッションを継続できます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ユーザーポリシーとネットワークポリシーを分ける

リモートユーザーには、物理的なストレージ構成を変更せずに、異なるライブラリアクセス、品質制限、サポート要件を設定する必要がある場合があります。ID管理とネットワークルールを分離しておくと、メディアを閲覧できるユーザーと、Plexへパケットを届ける方法が意図せず結び付くのを防げます。

Plexユーザーの制限では、基盤となるサーバー経路を変更せずに、アカウントごとにライブラリアクセスを変えられます。

1つのローカルアカウントと1つのリモートアカウントを、同じメディアに対してテストし、アクセス権限と再生経路の両方を記録します。ユーザーポリシーの変更によってネットワーク動作が予期せず変わる場合は、共有範囲を拡大する前に依存関係を文書化しましょう。