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

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

ローカルユーザーが重視するのは、通常、低遅延とDirect Playです。一方、リモートユーザー向けには、パブリックネットワークからの到達性、アップロード帯域幅、クライアントごとの差異、トランスコードの頻度増加も考慮する必要があります。サーバーの状態管理とストレージの層は共通化し、2つの配信経路は分けて検証しましょう。そうすることで、リモートアクセスのための回避策によってローカル再生が遅くなったり、不要な変換を強いられたりするのを防げます。

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

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

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

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

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

リモートクライアントがNAT越しにサーバーへ接続するには、明示的な方法が必要です。プロキシやプライベートトンネルを使う方法もあります。選択によって、ファイアウォール、検出、証明書、トラブルシューティングの対応範囲が変わります。

Plexへの直接リモートアクセスは、NATの条件、ポートフォワーディングのルール、外部ネットワークからの検証に左右されます。

主要なリモート接続経路を1つ選び、ユーザーを招待する前に、モバイル回線または別の外部ネットワークから接続できることを確認してください。経路が文書化されていない代替接続やリレーに依存している場合は、リモート画質を調整する前に到達性の問題を解決してください。

アップロード速度とトランスコード負荷をまとめて見積もる

リモート側の帯域幅制限によってストリームの画質が下がり、サーバーのトランスコード負荷が増す場合があります。そのため、WANとコンピューティングの各レイヤーを1つの経路として容量テストする必要があります。

リモートでの4K Plexストリーミングには、安定して確保できるアップロード速度が必要で、サーバー側での変換が発生する場合もあります。

想定される最高画質のリモートストリームを、一般的なローカルストリームの再生中に実行し、アップロード速度、CPU/GPUの使用状況、再生の安定性を測定します。ローカルでの再生を止めたときにしかリモートの画質が安定しない場合、共有ホストまたはWANリンクには、両方を同時に処理する余力がありません。既知のPlexリモートストリーミングの負荷をWANのテストに使い、同じサーバーでローカルのDirect Playセッションを続けることができます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

リモートユーザーには、物理ストレージの構成を変えずに、異なるライブラリアクセス権、画質制限、サポート体制が必要になる場合があります。ユーザーIDとネットワークルールを分けておけば、メディアを見られるユーザーと、Plexへのパケットの到達経路が意図せず連動するのを防げます。

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

同じメディアをローカルアカウントとリモートアカウントでそれぞれテストし、アクセス権限と再生経路の両方を記録します。ユーザーポリシーの変更によってネットワークの動作が予期せず変わる場合は、共有範囲を広げる前に、その依存関係を記録してください。