「Microsoft Connected Cache for Enterprise and Education（以下、Microsoft Connected Cache for E/E）」は、LinuxまたはWindowsに展開できる、ソフトウェアベースのキャッシュソリューションです。前回（vol.132）の最後に指摘したように、Windowsに慣れ親しんだ人にとっては、何がどうなっているのか、ブラックボックスのようで分かり難いと思います。Linuxに慣れた人にとっては、Windows向けのサービスをLinuxで動かすことに疑問を持つかもしれません。その疑問を解消するには、Microsoft Connected Cache for E/Eのアーキテクチャを理解することが早道だと思います。
LinuxとWindows、2種類のキャッシュノード
Microsoft Connected Cache for E/Eは、Azure上のリソースとオンプレミスに展開するキャッシュノードで構成されます。Azureのリソースは、キャッシュノードのデプロイと監視に使用され、キャッシュノードはWindows 10以降のネイティブ機能である「配信の最適化（Delivery Optimization《DO》」のキャッシュサーバーとして機能します。企業や組織は、デバイス数やネットワークトポロジに応じて、必要な数のキャッシュノードをオンプレミスに展開することができます。
配信の最適化というと、ピアツーピア（P2P）技術に基づいたキャッシュ機能で、同じローカルネットワーク上の各デバイスがキャッシュを保持して、相互に利用することで、ネットワーク帯域の削減とダウンロードの高速化を実現するものとイメージするかもしれません。確かにWindows 10以降は既定でそのように動作します。しかし、配信の最適化は、Microsoft Connected Cache（Microsoft接続キャッシュ）のキャッシュノードをキャッシュサーバーとして使用するように構成することもできます（画面1）。キャッシュサーバーが利用できない場合、配信の最適化クライアントは、通常のCDNにフォールバックするため、キャッシュサーバーの可用性はさほど重要ではありません。メンテナンスや障害でキャッシュサーバーがオフラインになることがあっても、キャッシュが利用されないだけで、更新のダウンロードには影響しません。
配信の最適化とは｜Windows（Microsoft Learn）
画面1 Windows 10以降の配信の最適化は、Microsoft Connected Cacheのキャッシュサーバーを使用するように構成することができる（キャッシュサーバーは直接指定の他、DHCPオプションで自動検出させることも可能）
Microsoft Connected Cache for E/Eのキャッシュノードは、ソフトウェアベースのキャッシュサーバーであり、LinuxまたはWindowsに展開することができます。しかし、LinuxとWindowsのそれぞれに対応したソフトウェアが提供されているわけではありません。LinuxとWindowsのどちらに展開する場合でも、コアのキャッシュエンジンは共通のものです。そして、そのキャッシュエンジンは、Linuxベースのコンテナーとして実装されています。
Linuxキャッシュノード
Microsoft Connected Cache for E/Eは、以下のLinuxディストリビューションへの展開をサポートしています。
- Ubuntu 24.04 LTS
- Red Hat Enterprise Linux（RHEL） 8.* または 9.*
図1は、Microsoft Connected Cache for E/EのキャッシュノードをLinuxに展開した場合のアーキテクチャ図です。この図に示したように、Microsoft Connected Cache for E/Eのキャッシュエンジンは、Linuxにインストールするパッケージの類ではありません。キャッシュエンジンは、Azure IoT Edgeの展開サービスを通じて提供される、Dockerコンテナーランタイム（moby-engine）上で動作するAzure IoT Edgeコンテナー（コンテナー名: MCC）として展開され、実行されます（画面2）。このコンテナーは、指定された更新サイクル（既定は「Fast」、即座に更新）に従って、更新バージョンに入れ替えられるため、キャッシュエンジンソフトウェアの更新に介入する必要はありません。
キャッシュストレージとしては、Linuxファイルシステム（ext4）のディレクトリ（デプロイスクリプト生成時の指定例は/cachenode/node01、100GB～）が使用されます。
図1 Linuxキャッシュノードのアーキテクチャ。キャッシュエンジンは、Azure IoT Edgeで展開、自動更新されるMCCコンテナーとして動作
画面2 Linuxマシンのコンテナーランタイム（moby-engine）上に展開されたAzure IoT EdgeのMCCコンテナー
Windowsキャッシュノード
Microsoft Connected Cache for E/EのWindowsへの展開では、以下のWindowsバージョンがサポートされています。これらのOSでは、前提条件としてWindows Subsystem for Linux 2（WSL 2）およびHyper-Vの機能が必要です。なお、Hyper-Vについては、少なくとも管理ツール（Hyper-V PowerShellモジュール）が利用可能であればよいようです（インストールスクリプトでConvert-VHDを使用するため）。
- Windows Server 2022（OSビルド20348.2227）以降のデスクトップエクスペリエンス
- Windows 11（OSビルド22631.3296）以降
図2は、Microsoft Connected Cache for E/EのキャッシュノードをWindowsマシンに展開した場合のアーキテクチャ図です。図2だけを見るとレイヤーが多くて複雑に見えるかもしれません。しかし、図1と比較すればすぐわかるように、図1のLinuxキャッシュノードと同等のものを、WSL 2上に展開した形になります。WSL 2で動作するUbuntu 24.04 LTSの中で、Azure IoT EdgeのMCCコンテナーが動作します。キャッシュストレージとしては、Linuxファイルシステム（ext4）のディレクトリ（/var/mcc、固定）が使用されます。
そして、MMCコンテナーを含むLinuxディストリビューションのイメージは、容量固定VHDXとしてWindowsマシンのディスク上に配置されます（既定はC:¥mccwsl01￥Ubunru-24.04-Mcc-Converted.Vhdx）。そのため、配置先には少なくとも100GB以上（キャッシュサイズは最小100GB～）の空き領域が必要になることに注意が必要です。なお、WindowsとLinuxのどちらの場合でも、キャッシュストレージ用の空き領域を確保できない場合、セットアップが途中で中止されます。
キャッシュノードをWindowsマシンに展開した場合、WSL 2のLinuxインスタンスは、デプロイ時に指定した実行アカウントのコンテキストで実行されます。そのため、別のユーザー（例えば、ログイン中のビルドインAdministrator）から、そのLinuxインスタンスの実行状態を参照することはできません（画面3）。その点を理解していないと、デプロイが成功したのか失敗したのか判断が付かない、動いているらしいけど、どこで動いているのかわからない、デプロイしたのに最後に消えてしまったなど、悩むことになるでしょう。
図2 Windowsキャッシュノードのアーキテクチャ。Linuxキャッシュノードと同等の環境を、WSL 2上に展開し、実行する
画面3 WindowsマシンのWSL 2上で実行されるLinux（Ubuntu-24.04-Mcc）と、そのLinu内で実行されるMCCコンテナー
キャッシュノードのサイジング
Microsoft Connected Cache for E/EはLinuxとWindowsのどちらにも展開できますが、展開するものは、同じLinuxベースのソフトウェアキャッシュであり、WindowsではWSL 2を利用することで、それを可能にしています。同じキャッシュ機能を、既存のインフラストラクチャにあるWindowsマシンやLinuxマシン、物理マシン、仮想マシン（VM）のどこにでも柔軟に導入できることは、 Microsoft Connected Cache for E/Eの利点の1つです。
そして、WindowsとLinuxのどちらに展開する場合でも、キャッシュノードのハードウェア要件は、利用可能な空きメモリ4GBと少なくとも100GBのディスク空き領域です。必要なディスク空き領域は、デプロイ時のキャッシュサイズの指定（最小100GB）に従います。利用シナリオによって、以下のようにCPUコア数、メモリ、ディスク、ネットワークの目安が示されています。
| 支店 | 中小企業 | 大企業 | |
| CPUコア数 | ４コア | 8コア | 16コア |
| メモリ | 8GB（空き4GB） | 16GB（空き4GB） | 32GB（空き4GB） |
| ディスク | 空き100GB | 空き500GBの空き領域 | 2×200～500GBの空き領域 |
| ネットワーク |
1Gbps |
5Gbps | 10Gbps |
| クライアント数 | 10～50台 | 50～500台/拠点 | 500～5,000台/拠点 |
配信の最適化クライアントは、キャッシュサーバーが利用できない場合、本体のCDNにフォールバックするため、高可用性はさほど重要ではありません。そのため、ほとんどの企業や組織では、少なくとも拠点ごとにキャッシュノードを1台導入すればよいでしょう。サーバーを設置していない/できない支店では、Windows 11クライアントデバイスの1台にキャッシュノードをデプロイすることができます。
LinuxとWindows Serverの両方にキャッシュノードを展開し、両方を使用してみた経験から言うと、シンプルな実装であるLinuxのキャッシュノードのほうが、圧倒的に導入が簡単で、OS自身のリソース使用量（OSディスク、CPU、メモリ）が効率的で、さらにレイヤーが少ない分（WSL 2に相当する部分がない）、軽量な印象を受けました。
