GthulhuとeBPFでLinuxカーネルを手なずける
標準的なLinuxスケジューラが特定のワークロードで「窒息し始める」状況を経験したことはありますか?例えば、マイクロ秒が重要な高頻度取引や、すべてのCPUリソースを消費するヘビーなビッグデータ分析を考えてみてください。Linuxカーネルの標準タスクスケジューラ(CFS/EEVDF)は優秀で公平ですが、この「公平性」こそが特殊なクラウドアプリケーションの障害になることがよくあります。すべての人を同時に満足させようとして、結局誰も最適なパフォーマンスを得られません。
つい最近まで、開発者には2つの選択肢がありました。制限を受け入れるか、カーネルソースコードの奥深くに飛び込み、パッチを書いてシステムを再構築し、何かがKernel Panicでクラッシュしないことを祈ることです。しかし、sched_extテクノロジーの出現で世界が変わりました。そして今日、私たちはカーネルのリソース管理を制御可能で、さらには洗練されたタスクに変換するGthulhuプロジェクトを探ります。
Gthulhuとは?なぜ重要なのか
Gthulhuは、eBPFとGolangで構築されたCloud Nativeシステム向けの分散オーケストレーションスケジューラです。簡単に言えば、Kubernetesクラスタ全体のCPU時間配分のルールを動的に変更できる「触腕」です。
プロジェクト名はCthulhu(クトゥルフ)への洒落た参照です。多くの触腕を持つ神話上の生物のように、Gthulhuはタスク管理を「掴み取り」、最も効率的に実行できる場所にそれらを誘導します。そして「G」プレフィックスはGoの使用を透明に示唆しており、モダンなDevOpsエンジニアやバックエンド開発者に親しみやすいプロジェクトにしています。
豆知識:このプロジェクトはqumunフレームワークに基づいています。台湾の先住民族言語で、この言葉は「心」を意味します。そしてこれは非常に正確な比喩です。なぜなら、スケジューラは本当にOSの心臓だからですね。
なぜ標準スケジューラではもう不十分なのか
正直に言えば:Linuxは汎用システムとして設計されました。そのスケジューラは、バックグラウンドでコードコンパイルが実行されている間にブラウザのLAGを防ぐという点で優れた仕事をします。しかし、クラウド環境には特有の課題があります:
- 低レイテンシ:取引システムやゲームサーバーはキューでの「公平な」待機ではなく、瞬時の応答を必要とします。
- 高スループット:ビッグデータはインターフェース対話性など気にしません—計算リソースから最大限のパフォーマンスを引き出す必要があります。
- 分散本質:標準カーネルはクラスタ内の隣接ノードで何が起きているか知りません。Gthulhuは全体像を把握します。
内部動作の仕組み
Gthulhuのアーキテクチャは、すべてのコンポーネントが自分の場所を知っている、調整された механизмのように見えます。
システムの中央には、Kubernetes APIと通信しMongoDBにデータを保存するManager(中央管理)があります。しかし、最も興味深いことはノード上で起こります:
- Decision Maker:特定のノードでのタスク分散に関する決定を下します。
- sched_ext(eBPFスケジューラ):実行中のカーネルを再起動せずにスケジューリングロジックを直接注入できる実際の「魔法」です。
eBPF 덕분에、セキュリティ(コードはカーネルベリファイアによって検証される)と信じられないほどの速度の両方を手にできます。
Gthulhuの主要機能
1. REST APIによるプログラム可能性
システムプログラミングの達者である必要はありません。Gthulhuは通常のAPIリクエストを通じてスケジューリング戦略を設定できます。Control Planeはこれらの戦略を自動的にクラスタ内のすべてのノードに配布します。
2.箱出しのKubernetesサポート
このプロジェクトはHelmチャートを提供しており、K8sへのデプロイは数分で完了します。APIを通じてPod情報をクエリし、実際のクラスタ負荷に基づいてリソースを調整できます。
3.カーネルでの安全な実験
sched_extテクノロジーの使用は、カスタムスケジューラが「暴走」した場合、シンプルに標準Linuxスケジューラにロールバックすることを意味します。「ブルースクリーン」や无尽の再起動サイクルはありません。
4.クロスプラットフォームと移植性
開発者は、Gthulhuが異なるカーネルバージョン(6.12以降)で動作することを重視しています。リポジトリには毎日の移植性テストが設定されており、将来のLinuxリリース(6.17まで)との互換性をチェックしています。
実践例:起動して試す方法
まず、カーネルがsched_extをサポートしていることを確認してください(バージョン6.12+が必要です)。準備ができたら、ビルドプロセスはGoプロジェクトにとって標準的です:
システムにインストールせずにプロジェクトを быстроテストしたい場合は、Dockerを使用できます:
--privilegedフラグとホストPIDアクセスが必要です。なぜなら、eBPFプログラムはシステムカーネルと直接やり取りする必要があるからです。
秩序を愛する人のために、schedctlのサポートがあります—スケジューラを管理するための便利なユーティリティです:
これが本当に役立つ場面
私の実践では、5Gコアや高負荷プロキシなどのネットワークアプリケーションが、スケジューラのマイクロ遅延のためにパケットドロップを開始する場面に頻繁に出会います。Gthulhuはすでにfree5gcプロジェクトと組み合わせてテストされており、カスタムeBPFスケジューラがネットワークパフォーマンスを大幅に改善しました。
また、次のような用途に最適です:
- MLエンジニア:GPUワーカーのデータ準備に対するCPU優先アクセスを保証するために。
- SREスペシャリスト:「うるさい隣人」状況を防止するために、1つのコンテナが制限を超えていなくても他のコンテナを間接的に遅らせる状況です。
結論:試す価値はあるか?
Gthulhuは単なる別のシステムツールではありません—それはハイレベルのクラウド開発の世界とカーネルの低レベルの魔法の間の架け橋です。標準的なKubernetesやLinuxツールがハードウェアから最大限を引き出せなくなっていると感じている場合、または単に最新のeBPFがどのように機能するか的好奇心があるなら—このプロジェクトは確かにGitHubでスターに値します。
もちろん、このプロジェクトはモダンなカーネルを必要とし、これは保守的なエンタープライズ環境にとっては制限になる可能性があります。しかし、テクノロジーの最前線にいる人々にとって、Gthulhuはアプリケーション性能に対する前例のないレベルの制御を提供します。
有用なリソース:
クラスタ全体にあなたのCthulhu解き放つ準備はできていますか?試してみてください、そしてタスクスケジューリングはもう二度と「ブラックボックス」ではないかもしれません。
関連プロジェクト