Azure Files のメタデータ キャッシュとローカル支店キャッシュの比較

VPN 経由の低速な Azure Files アクセスに対して二つの変更が提案されており、それぞれ短縮する対象が異なります。サービス側のメタデータ キャッシュは、対象となる操作をサーバーにとって安くします。ローカル支店キャッシュは、バイトと操作をユーザーの近くに移動させます。価格表やプレスリリースで両者を選ぶと、共有はベンチマークでは速くなり、朝九時には変わらない、という結果になります。

二つのキャッシュ、二つの異なるレイテンシ

どちらの選択肢もキャッシュという言葉の下に現れ、そこから混乱が始まります。両者はネットワークの反対側に位置します。

Microsoft の SMB パフォーマンス ガイダンス では、対象となる SSD 共有のメタデータ キャッシュと、それに伴う登録手順が説明されています。対象条件と機能の状態は実際のストレージ アカウントに依存するため、二年前のプレビュー告知ではなく現在のページを読んでください。

待ち時間を三つに分ける

遅いディレクトリ一覧には三つのコスト要素があり、それぞれ異なる対策に反応します。要求ごとのサービス処理時間、VPN をまたぐ依存した往復の回数、そして移動させる必要のあるペイロードです。サービス側のキャッシュは一つ目に働きかけます。サーバー側の何も二つ目には働きかけません。

そのため、ユーザーのファイル選択画面が八秒間固まったままでも、共有はより良いサービス メトリックを示すことがあります。

それぞれの選択肢が生きる場面

ワークロードがメタデータ中心で、対象となる SSD 共有に対して多数のオープン、stat 呼び出し、ディレクトリ列挙があるなら、サービス側のキャッシュは安価な実験です。新しいインフラも、ユーザーが共有に到達する方法の変更も必要ありません。

ワークロードが対話型でレイテンシに縛られているなら、文書化された同期モデルを備えたサポート対象のローカル サーバー設計が誠実な選択肢です。これは独自の運用コストを持つ別のアーキテクチャであり、スイッチではありません。

どちらの選択肢も変えないもの

SMB の署名と暗号化は引き続き適用され、引き続きコストがかかります。アクセス制御は依然としてユーザーごとに解決されるため、キャッシュされたコピーは承認を単純化しません。サイト間の整合性には依然として定義されたモデルが必要です。支店ローカルの読み取りとクラウド側の書き込みが何かについて合意する必要があるからです。そしてオフライン アクセスはクライアントの設定のままであり、サーバー機能の副作用ではありません。

サービスの機能が WAN の往復をなくすと誰かが約束するなら、それが最初に検証すべき主張です。

ユーザーが不満を言う操作に対して測定する

合成コピーではなく、正確な操作を計測します。Measure-Command { Get-ChildItem \\files\projects -Recurse } を支店クライアントで実行すると前後で比較できる数値が得られ、Get-SmbMultichannelConnection はクライアントが複数のパスを使っているかどうかを示します。それを同じ時間帯のサービス側のレイテンシ メトリックと並べてください。

共有、クライアントの場所、VPN パス、セキュリティ ポリシーを一定に保ってください。そうしないと、機能ではなく変更ウィンドウを測定することになります。ファイル数とサイズ分布も記録してください。小さいファイルのワークロードと一括コピーでは、効くレバーがまったく異なるからです。

持つ価値のある結果は、実際に遅かった境界に合わせた変更であり、その運用コストと整合性コストが書き留められたものです。スライド上の大きなストレージ IOPS の数字は、その結果ではありません。