Windows Server コンテナーのパフォーマンス チューニング
はじめに
Windows Server 2022 以降、Windows Server コンテナーと Hyper-V コンテナーという 2 種類のコンテナーを使用できるようになりました。 どちらの種類のコンテナーでも、Windows Server 2022 の Server Core または Nano Server SKU のいずれかがサポートされます。
これらの構成には、さまざまなパフォーマンス上の影響があります。これについては、お客様のシナリオにどちらが適しているかを知る上で役立つように、以下で詳細に説明します。 さらに、パフォーマンスに影響する構成について詳しく説明し、これらの各オプションのトレードオフについても説明します。
Windows Server コンテナーと Hyper-V コンテナー
Windows Server コンテナーと Hyper-V コンテナーは、移植性と一貫性に関しては多くの点で同じですが、分離の保証とパフォーマンス特性の点で異なります。
Windows Server コンテナーは、プロセスと名前空間の分離テクノロジによってアプリケーションを分離します。 Windows Server コンテナーは、コンテナー ホストとそのホストで実行されているすべてのコンテナーと、カーネルを共有します。
Hyper-V コンテナーは、高度に最適化された仮想マシンで各コンテナーを実行することで、Windows Server コンテナーによって提供される分離性を拡張します。 この構成では、コンテナー ホストのカーネルが Hyper-V でコンテナーと共有されません。
Hyper-V コンテナーによって提供される追加の分離は、主にコンテナーとコンテナー ホストの間の分離のハイパーバイザー レイヤーによって実現されます。 これは、Windows Server コンテナーとは異なり、システム ファイルとバイナリの共有が少なくなる可能性があるため、コンテナー密度に影響し、ストレージとメモリの使用量が全体的に大きくなります。 さらに、一部のネットワーク、ストレージ IO、 CPU のパスでは、追加のオーバーヘッドが予想されます。
Nano Server と Server Core
Windows Server コンテナーと Hyper-V コンテナーには Server Core のサポートが用意されています。詳しくは、コンテナーの基本イメージのオプションを参照してください。
Nano Server は、プライベート クラウドとデータセンター向けに最適化されたリモート管理サーバー オペレーティング システムです。 Nano Server は Server Core モードの Windows Server に似ていますが、サイズが大幅に小さく、ローカル ログオン機能がありません。さらに、64 ビットのアプリケーション、ツール、およびエージェントのみがサポートされます。 Windows Server と比べて Nano Server の場合は、使用されるディスク領域がかなり小さくなり、セットアップが大幅に速くなり、必要とされる更新と再起動の回数がずっと少なくなります。 再起動も非常に高速化されています。
コンテナーの起動時間
コンテナーの起動時間は、コンテナーが最大のメリットを提供するシナリオの多くで重要な指標となっています。 そのため、コンテナーの起動時間を最適化するための最良の方法を理解することが重要です。 起動時間を改善するために理解しておくべきチューニングのトレードオフを次に示します。
最初のログオン
Microsoft は、Nano Server と Server Core の両方の基本イメージを出荷しています。 Server Core 用に出荷される基本イメージは、最初のログオン (OOBE) に関連するスタートアップ時間のオーバーヘッドを排除することによって最適化されています。 これは、Nano Server の基本イメージには当てはまりません。 しかし、少なくとも 1 つのレイヤーをコンテナー イメージにコミットすることで、このコストを Nano Server ベースのイメージから取り除くことができます。 そのイメージから起動する後続のコンテナーでは、最初のログオンのコストは発生しません。
スクラッチ領域の場所
コンテナーは、既定では、実行されているコンテナーの存続期間中、コンテナー ホストのシステム ドライブ メディア上の一時スクラッチ領域をストレージに使用します。 これはコンテナーのシステム ドライブとして機能します。そのため、コンテナー稼働中に行われる書き込みと読み取りの多くはこのパスをたどります。 回転ディスク磁気メディア (HDD) 上にシステム ドライブが存在するが、より高速なストレージ メディア (より高速な HDD または SSD) が利用できるホスト システムについては、コンテナーのスクラッチ領域を別のドライブに移動できます。 これを行うには、dockerd –g コマンドを使用します。 このコマンドはグローバルであり、システムで実行されているすべてのコンテナーに影響を及ぼします。
入れ子になった HYPER-V コンテナー
Windows Server 2022 の Hyper-V は、入れ子になったハイパーバイザーをサポートしています。 つまり、仮想マシン内から仮想マシンを実行できます。 これにより、多くの有用なシナリオが実現可能になりますが、物理ホスト上で実行されている 2 つのレベルのハイパーバイザーがあるため、ハイパーバイザーがパフォーマンスに及ぼす影響も強調されます。
コンテナーについては、仮想マシン内で HYPER-V コンテナーを実行するときにこれが影響を及ぼします。 HYPER-V コンテナーはそれ自体とコンテナー ホスト間のハイパーバイザー レイヤーを使用して分離を提供するため、コンテナー ホストが HYPER-V ベースの仮想マシンである場合、コンテナーの起動時間、ストレージ IO、ネットワーク IO とスループット、および CPU の点でパフォーマンスのオーバーヘッドが発生します。
記憶域
マウントされたデータ ボリューム
コンテナーには、コンテナー ホストのシステム ドライブをコンテナーのスクラッチ領域に使用できる機能があります。 ただし、コンテナーのスクラッチ領域の存続期間は、コンテナーの存続期間と同じです。 つまり、コンテナーが停止すると、そのスクラッチ領域および関連付けられているすべてのデータが削除されます。
しかし、コンテナーの存続期間に関係なくデータを保持することが必要になるシナリオが多数あります。 このような場合は、コンテナー ホストからコンテナーへのデータ ボリュームのマウントがサポートされています。 Windows Server コンテナーの場合、マウントされたデータ ボリュームに関連する IO パスのオーバーヘッドはごくわずかです (ネイティブに近いパフォーマンス)。 ただし、HYPER-V コンテナーにデータ ボリュームをマウントすると、そのパスの IO パフォーマンスが多少低下します。 さらに、仮想マシン内で HYPER-V コンテナーを実行しているときに、この影響は大きくなります。
スクラッチ領域
Windows Server コンテナーと HYPER-V コンテナーの両方で、コンテナーのスクラッチ領域に 20 GB の容量可変の VHD が既定で提供されます。 どちらの種類のコンテナーでも、コンテナー OS はその領域の一部を占有します。これは開始されたすべてのコンテナーに当てはまります。 したがって、開始されたすべてのコンテナーはストレージにいくらかの影響を及ぼし、そのワークロードに応じて最大 20 GB の補助ストレージ メディアに書き込むことができる点に留意することが重要です。 サーバー ストレージの構成は、この点を考慮して設計する必要があります。
ネットワーク
Windows Server コンテナーと Hyper-V コンテナーには、さまざまなネットワーク構成のニーズに最適な各種のネットワーク モードが用意されています。 これらのオプションはそれぞれ独自のパフォーマンス特性を示します。
Windows ネットワーク アドレス変換 (WinNAT)
各コンテナーは、内部のプライベート IP プレフィックス (例: 172.16.0.0/12) から IP アドレスを取得します。 コンテナー ホストからコンテナー エンドポイントへのポート フォワーディングおよびマッピングがサポートされています。 Docker は、dockerd の初回実行時に、既定で NAT のネットワークを作成します。
これら 3 つのモードのうち、NAT 構成は最も高価なネットワーク IO パスですが、必要な構成量は最も少なくなります。
Windows Server コンテナーでは、仮想スイッチへの接続に Host vNIC を使用します。 HYPER-V コンテナーでは、仮想スイッチへの接続に (ユーティリティ VM には公開されていない) 統合 VM NIC を使用します。 コンテナーが外部ネットワークと通信している場合、アドレス変換が適用された WinNAT を介してパケットがルーティングされるため、いくらかのオーバーヘッドが発生します。
透過
各コンテナーのエンドポイントは、物理ネットワークに直接接続されています。 物理ネットワークの IP アドレスは、外部の DHCP サーバーを使用して静的または動的に割り当てることができます。
透過モードは、ネットワーク IO パスの点で最もコストがかからず、外部パケットはコンテナー仮想 NIC に直接渡され、外部ネットワークに直接アクセスできます。
L2 ブリッジ
各コンテナーのエンドポイントは、コンテナー ホストと同じ IP サブネット内にあります。 IP アドレスは、コンテナー ホストと同じプレフィックスから静的に割り当てる必要があります。 ホスト上のすべてのコンテナーのエンドポイントは、レイヤー 2 のアドレス変換のために同じ MAC アドレスとなります。
L2 ブリッジ モードでは、外部ネットワークへの直接アクセスが提供されるため WinNAT モードよりもパフォーマンスが高くなりますが、MAC アドレス変換が導入されるため、透過モードよりもパフォーマンスが低くなります。