VPN ファイル共有のための BranchCache：効くとき、効かないとき

チームの誰かが「VPN 経由のファイル共有が遅い」と言い、最初の提案は必ずキャッシュになります。BranchCache をリモートアクセス設計に加える前に、その不満を三つの形のどれかに分けてください。未変更コンテンツの繰り返しダウンロード、アップロード、あるいは数千件のエントリを持つフォルダーをめぐるメタデータの多い閲覧です。BranchCache が対応するのは一番目の形だけで、しかもサポート対象のコンテンツに限られます。残り二つには何の役にも立ちません。これは回避すべき制約ではなく、導入に一週間を費やす前にやっておくべき比較です。

同じ共有、三つの異なる不満

支社で八人が同じ未変更の研修動画を開く——これがこの機能の想定場面です。最初の取得は WAN を越え、コンテンツは読む人の近くにキャッシュされ、同じ未変更ファイルの二回目以降の取得はローカルで処理されます。効果は確かにありますが狭いものです。同じコンテンツ、未変更、複数の読者。

自宅回線から新しい録音をアップロードするノート PC は逆のケースです。まだ存在しないファイルのキャッシュ済みコピーはないので、アップロードはこれまでどおり制約された経路を通ります。ダウンロード用キャッシュはアップロードを消しませんし、配置の選択でそれが変わることもありません。

三つ目の形が人を失望させるのは、ダウンロードの問題に見えるからです。数万件のファイルがあるディレクトリを開き、並べ替え、メタデータを読むのは小さな操作の連続であって、大きなオブジェクトの繰り返し転送ではありません。ファイル本体をキャッシュしても列挙には何の効果もありません。

分散キャッシュ：VPN プールは支社 LAN ではない

分散モードでは、クライアント コンピューター同士がキャッシュしたコンテンツを共有します。Microsoft はこのモードを単一サブネット内で動作するものとして文書化しています。VPN クライアント プールは、たとえすべてのアドレスが連続して見えても、その意味でのサブネットではありません。ピア検出、クライアント間の到達性、キャッシュ データを交換する許可はそれぞれ別の問いであり、通常のリモートアクセス設計は三つすべてに「いいえ」と答えます。

クライアント間の通信を許可すればプールを支社 LAN のように振る舞わせられますが、それはセキュリティ上の判断であり、キャッシュの判断ではありません。ほとんどのリモートアクセス設計がクライアント同士を分離するのは、侵害されたノート PC が別の端末に届かないようにするためです。その分離と引き換えにキャッシュ ヒットを得るのは、ピア同士がすでに信頼できる対等な関係でない限り、悪い取引です。

単独のモバイル ユーザーにとって、分散モードには共有する相手がいません。キャッシュはその一台のクライアントの繰り返し読み取りには役立ちますが、それはクライアント側のキャッシュの利点であり、支社配置の利点ではありません。オフィスが速くなると誰かが期待する前に、そう言っておく価値があります。

ホスト型キャッシュ：配置が効果を決める

ホスト型キャッシュは共有キャッシュをサーバー上に置きます。サブネットをまたいで意味があるのはこのモードだけで、クライアント同士が通信できない場合に機能するのもこれだけです。最初の問いは、そのサーバーがどこにあるかです。ホスト型キャッシュが送信元と同じ制約されたリンクを越えてアクセスされるなら、バイトを移動しただけで、問題は動いていません。

読む人の近くに置き、所有者を決め、ディスクは共有全体ではなく作業セットに合わせて見積もってください。Microsoft のBranchCache の概要では、両方のモードとクライアントの動作が説明されています。見落とされがちな点も含まれます。クライアントはキャッシュ データを使う前に、認可とコンテンツ情報のために送信元へ問い合わせます。

導入は三つの役割をまとめて計画するもので、チェックボックス一つではありません。送信元サーバーがコンテンツのハッシュを公開し、ホスト型キャッシュが有効化されて検出可能になり、クライアントがそれを使うよう構成されます。サーバー側では PowerShell でそれが分かります。

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

クライアント側では、名前付きサーバーを指定するか、サービス接続ポイントによる検出に任せます。そのうえで、ポリシーが適用されたと決めつけず、実際に選ばれたモードを確認してください。

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

それでも送信元に届くもの

キャッシュは認可をなくしません。あるファイルを読む権限のないクライアントが、他の誰かがキャッシュしたからといってアクセスできるようにはなりません。送信元は認可の問いに答え、キャッシュ参照を可能にするコンテンツ情報を提供し続けます。送信元に到達できなければ、キャッシュされたコピーだけがオフライン共有になるわけではありません。

コンテンツの変更も、この前提を静かに崩します。再保存、再エンコード、あるいはバックアップ製品による操作を受けたファイルは、キャッシュされたハッシュと一致しなくなり、次の読み取りは送信元へ戻ります。これは正しい動作であり、作業セットが一時間ごとに変わるキャッシュがほとんど効果を出さない理由でもあります。

追い出しが三つ目の限界です。キャッシュは有限なので、大きな作業セットは古いコンテンツを押し出します。効果は、追い出しの前に再読み取りが起きるかどうかにかかっています。共有全体に合わせてキャッシュを見積もるのは、技術的には正しかった導入に失望するいつもの方法です。

二回の取得と一回のアップロードで受け入れる

正しい三つの流れを試し、それぞれが何を示すかを書き留めます。クライアントからの代表的なファイルの最初の取得を、送信元リンクと利用者の時計の両方で測ります。同じ配置グループの二台目のクライアントから、同じ未変更ファイルを取得します。新しいファイルのアップロード一回は、改善を示さないはずで、キャッシュが決してしていないことの功績にされていないことを確かめます。

二回目の取得でもバイトの大部分が送信元リンクを越えるなら、キャッシュは使われていません。原因は通常、誤ったモードのクライアント、送信元でのハッシュ公開の欠落、あるいは制約されたリンクの反対側にあるホスト型キャッシュです。これは三つの異なる対処であり、ネットワーク配置に関わるのは一つだけです。

そのうえで、最初の不満と同じ形で結論を述べてください。この送信元からこれらの読者への、未変更コンテンツの繰り返しダウンロードは、このキャッシュが担う。共有についてそれ以外のことは変わっておらず、アップロード、フォルダー列挙、そしてオフラインの話は、それぞれ別の答えが必要なままです。