私たちは何年もの間、Microsoft が Linux 用 Windows サブシステムに膨大なリソースを注ぎ込むのを見てきました。これは、長い間 Linux を好んできた私たちにとって、最終的に Windows を第一級市民にするための偉大なイコライザー、架け橋として位置づけられていました。
WSL は間違いなく印象的です。 Linux カーネルを Windows と並行して実行し、このレベルの統合を実現することは、エンジニアリングの偉業です。しかし、Linux には非常に基本的な機能があり、そのアーキテクチャに深く組み込まれているため、最も洗練された仮想化レイヤーですらその優雅さを再現することができません。
これは派手な UI や流行のフレームワークではなく、シンプルなファイルシステム インターフェイスを介して公開される、cgroup を介したプロセス リソースに対するネイティブで詳細かつ透過的な制御です。この機能は最新のコンテナ化の基礎であり、システムの透明性のレベルを表しており、リソース管理に対する Windows のアプローチが異なって見えるだけでなく、比較すると本当に恥ずかしいものになります。
cgroup ファイルシステム
単純なファイルを通じてリソースを制御する
Cgroup を使用すると、プロセスのグループ全体で CPU、メモリ、I/O などのシステム リソースを割り当て、制限し、監視することができます (通常関心のあるすべてのもの)。ほとんどのオペレーティング システムはリソース制御のための何らかのメカニズムを提供しているため、これ自体は珍しいことではありません。
Linux の特徴は、このコントロールがどのように公開されるかです。 Cgroup はファイルシステムとして表示され、通常は次の場所にマウントされます。 /sys/fs/cgroup。リソースの管理はファイルとディレクトリとの対話となり、制約された環境を作成するには、ディレクトリを作成し、制御ファイルに値を書き込み、そのディレクトリにプロセスを割り当てます。
コンパイル、API 呼び出し、またはスキャフォールディングを必要とせずに、いくつかのシェル コマンドを使用して、プロセスを固定の CPU クォータとメモリの上限に制限できます。システムは即座に予測どおりに応答します (これは必要以上にまれです)。これは便利なだけでなく、システムに対する考え方も変わります。リソース管理は、ツールのレイヤーの背後に隠されたものではなく、直接実験できるものになります。
Windows では、これに最も近いのはジョブ オブジェクトです (ほとんどの人が存在を漠然と覚えている部分です)。プロセスをグループ化し、制限を適用することができますが、インターフェイスはまったく異なります。対話は Windows API を通じて行われ、C、C++、または .NET のコードが必要です。 CreateJobObject や SetInformationJobObject などの関数を呼び出し、管理し、エラーを明示的に処理する必要があります。
単純な制約であっても、重要な設定が必要です。コマンドラインの使用は間接的であり、通常は PowerShell またはカスタム ユーティリティを通じてラップされます。その結果、ほとんどの開発者はこれらのプリミティブに直接関与することはありません。彼らは、基礎となるメカニズムを曖昧にする高レベルのツールに依存しています。
コンテナの基礎
コンテナが Linux 上でネイティブに感じられる理由
Cgroup は独立した機能ではありません。名前空間とともに、コンテナーの基礎を形成します。コンテナーが Linux 上で実行される場合、制限を強制する追加の抽象化レイヤーはありません (ボックスの中に追加のボックスはありません)。コンテナー ランタイムは cgroup を作成し、制約を書き込み、その中にプロセスを配置します。残りの作業はカーネルが行います。
Windows では、コンテナ化は別のパスをたどります。多くの展開は Hyper-V 分離に依存しており、インターフェイスが軽量なものを示唆している場合でも、仮想マシン層が導入されます。
これにより分離が実現しますが、複雑さとオーバーヘッドが追加されます。プロセス分離モードであっても、Windows は、統合インターフェイスとして設計されていないジョブ オブジェクトと他のサブシステムの組み合わせに依存します。断片は存在しますが、一貫したモデルを提示していません。開発者は、単一のディレクトリを移動してリソース制限をリアルタイムで監視することはできません。代わりに、情報は API や管理ツール全体に分散しています (薄く分散しています)。
この違いはデバッグ時に明らかになります。 Linux では、リソース制約はファイルシステムを通じて表示および編集可能です。 Windows では、これらの制約を理解するには、単純な検査用に設計されていないツールを操作する必要があります。
透明性とシステム設計
さまざまな哲学が体験を形作る
Linux は、シンプルで一貫したインターフェイスを通じてカーネル機能を公開する傾向があります。ファイルシステムの抽象化は、構成可能で馴染みやすいため、繰り返し使用されます。これにより、参入障壁が低くなり、基本的なシェル コマンドを理解している開発者はリソース制限をすぐに試すことができます。 Windows は歴史的に抽象化を好んでおり、複雑さは API やマネージド インターフェイスの背後に隠されています。これにより、研磨された表面が生成されますが、直接的な制御は制限されます。
ジョブ オブジェクト システムは強力ですが、理解するには努力 (そしてかなりの忍耐) が必要です。パフォーマンス データは入手可能ですが、多くの場合、パフォーマンス カウンターや WMI などの断片化されたシステムを通じて入手されます。これらの部分は個別に開発されたものであり、統一されたモデルはありません。
その結果、機能は存在するものの、簡単に発見したり構成したりできないシステムが生まれ、開発者はシステム自体ではなくツールを操作することになります。 Linux を使用しているときにプロセスが動作しなくなった場合、その cgroup をすぐに覗いて、何が制限に達しているのかを正確に確認できます。 Windows では、同じ調査が面倒に感じられ、同じ答えを見つけるためにいくつかの異なるツールをナビゲートする必要があります。
WSL のパラドックス
Windows 内の Linux がその点を証明する
WSL は、Windows 内に Linux を組み込むことで、このギャップを埋めようとします。 Linux ツールへのアクセスを提供することに成功しましたが、根本的な制限も浮き彫りにしました。 WSL 内でコンテナを実行する場合、Windows リソース管理は使用しません。仮想化環境で実行されている Linux カーネル内で Linux cgroup を使用しています。
WSL は良いですが、Windows に戻るにはまだ十分ではありません
Copilot を我慢できるようになるには、仮想 Linux マシン以上のものが必要です。
Windows ホストは独立したままであり、そのネイティブ メカニズムはそのワークフローの一部ではありません。開発者が期待する環境を提供するために、Windows は独自のモデルを拡張するのではなく、Linux をインポートします。 Docker Desktop にも同じパターンが反映されます。コンテナーは Linux 仮想マシン内で実行されます。エクスペリエンスはネイティブに感じられますが、基礎となる機能は Windows 自体によって提供されません。
- ブランド
-
フレームワーク
- CPU
-
AMD Ryzen AI Max 300 シリーズ
実際的な影響
この違いが実際に現れる場所
これらの違いは、日々の開発に現れています。 Linux を使用している場合、kind や Minikube などのツールはホスト カーネルを直接使用するため、ローカル Kubernetes クラスターの実行は簡単です。リソース制限は本番環境とまったく同じように動作し、標準のシステム ツールを使用してすべてをデバッグできます。 Windows では、通常、同じセットアップが仮想マシン内に組み込まれることになり、ワークロードとハードウェアの間の追加レイヤーを常に考慮する必要があり、これがリソースの実際の動作に必然的に影響します。
Minikube を使用してローカル Kubernetes クラスターを開始する方法
Minikube は、ローカル開発で使用するために設計された最小限の Kubernetes ディストリビューションです。
何かが失敗した場合、コンテナだけを見ることはできません。オーケストレーション システム全体と仮想化環境を同時に考慮する必要があります。 CI システムでも同じパターンが見られます。 Linux では、ほぼゼロのオーバーヘッドで cgroup を介して制限を適用し、単純なスクリプトで構成を管理できます。
対照的に、Windows ランナーは常に追加のセットアップが必要なようです。特殊な API、追加のスクリプト レイヤ、または完全な仮想化のいずれであっても、システムは機能しますが、それほど直接的ではありません。時間が経つにつれて、その摩擦は増大するため、シンプルなシステムのほうが保守や推論がはるかに簡単です。
構造的な違い
このギャップを埋めるのが難しい理由
Windows にとって cgroup 機能が特に厄介なのは、この機能がクラウド コンピューティングとコンテナ化の時代におけるオペレーティング システム設計の軌跡に関する基本的な何かを明らかにしていることです。
Linux は、(一般に信じられていることに反して) 最初からコンテナを念頭に置いて設計されたわけではありません。 cgroup 機能は、シンプルなインターフェイスを通じてきめ細かいリソース制御を提供することの価値を認識したカーネル開発者によって追加され、段階的に登場しました。しかし、この機能は Linux の哲学に非常に自然に適合しており、まるで以前から存在していたかのように感じられます。
実際の Bash スクリプトが実際に使用する 6 つのテスト パターン
ファイルが本当にファイルであるかどうか、文字列に何かが含まれているかどうか、そしてこれらの重要なパターンでプログラムを実行できるかどうかを確認してください。
ファイルシステム インターフェイス、テキストベースの制御ファイル、単純なスクリプトで機能を構成する機能、これらすべての特性は、Linux が継承し拡張した Unix の伝統と完全に一致しています。 Windows には、リソース管理とコンテナ化に関してこの一貫性が欠けています。これらの機能は、何らかの形でシステム全体に散在して存在しますが、Linux cgroup を非常に強力でアクセスしやすくする統一されたビジョンと一貫したインターフェイスが欠けています。
無視できない実際的な現実
Microsoft は、Windows コンテナの開発、Docker 統合の改善、WSL の構築に膨大なリソースを投資してきましたが、これらの取り組みは数十年前に行われた基本的なアーキテクチャ上の決定を克服することはできません (歴史には勢いがあります)。同社は基本的に、異なる時代向けに設計されたシステムに最新のコンテナ化機能を改修しようとしているのに対し、Linux はコンテナ化の動きとともに進化し、開発者が必要とする機能を自然かつ一貫した方法で増加させてきました。
私は Microsoft が Unix の哲学を反映するために NT カーネルを書き直すとは期待していません。何十年にもわたる勢いから抜け出すのは困難です。私の主なシステム操作が、プロセスが壁にぶつかっている理由を確認するためだけに抽象化レイヤーをナビゲートすることである限り、Windows 開発に対する「ファーストクラス」というラベルは、技術的な現実というよりはマーケティング目標のように感じられます。 WSL は素晴らしい架け橋ですが、最終的には、ホスト独自のプリミティブが現在の作業方法に合わせて構築されていないことを告白することになります。