コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第117回　ユーザースペースのプラグイン型タスクスケジューラ「ghOSt」（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第117回　ユーザースペースのプラグイン型タスクスケジューラ「ghOSt」（パート1） (中井悦司) 2021年11月

はじめに

　今回からは、2021年に公開された論文「ghOSt: Fast and Flexible User-Space Delegation of Linux Scheduling」を元にして、Googleのエンジニアが開発したプラグイン型のタスクスケジューラ「ghOSt」を紹介します。ここで言うタスクスケジューラは、OS上で実行するプロセスを選択するLinuxカーネルの機能にあたります。今回は、Googleのエンジニアが独自のタスクスケジューラを開発した背景とghOStのアーキテクチャの概要を紹介します。

Linuxのタスクスケジューラ

　はじめに前提知識として、Linuxのタスクスケジューラの役割を簡単に説明します。Linuxはマルチタスク型のOSで、複数のプロセスをマイクロ秒やナノ秒といった単位の時間間隔で切り替えながら実行することにより、1つのCPUコア上で複数のプロセスを並列に実行しているように見せかけることができます。この時、複数のプロセスに対して、CPUコアの処理時間を順に割り当てていく機能を提供するのがタスクスケジューラの役割になります。タスクスケジューラの機能は、Linuxカーネルに実装されており、現在は、CFS（Completely Fair Scheduler）が標準的に利用されています。
　CFSは、CPU負荷の高いプロセスやユーザーとの対話的処理を行うプロセス（つまり、ユーザーからの入力待ち時間が多いプロセス）など、広い範囲のプロセスについて公平にCPU処理時間を割り当てるように設計されています。一方、特定のワークロードに特化したスケジューラを利用することで、サーバー上で稼働するアプリケーションの性能を向上したいという場合もあります。Linuxカーネルには、「スケジューリングクラス」と呼ばれる仕組みがあり、原理的には、プロセスごとに異なるスケジューラを適用することもできます。しかしながら、新しいスケジューリングポリシーを実装する場合は、Linuxカーネルを再ビルドして入れ替える必要があります。とりわけ、Googleのデータセンターのように多数のサーバーが稼働している環境では、さまざまなスケジューリングポリシーを自由に入れ替えるというのは簡単なことではありません。
　そこで、Googleのエンジニアは、アプリケーション開発者が独自のスケジューリングポリシーを簡単に実装して、Linuxカーネルを稼働したまま、ダイナミックにスケジューリングポリシーを入れ替えられる仕組みとして、ghOStを開発しました。スケジューリングポリシー自体は、ユーザー空間のエージェントによって実行されるため、Linuxカーネルの動作に影響を与える事なく、安全にポリシーを入れ替えることが可能になります。

ghOSt のアーキテクチャ概要

　ghOStのアーキテクチャの概要は、図1のようになります。ghOStは、Linuxカーネル標準のスケジューラと共存しており、スケジューリングクラスの指定により、明示的にghOStの管理下においたプロセスのスケジューリングを行います。それ以外のプロセスは、Linuxカーネル標準のスケジューラによるスケジューリングが行われます。ghOStの管理下にあるプロセスの状態が変化すると、Linuxカーネルは、メッセージキューを用いて、ユーザー空間のエージェントに通知を行います。エージェントは、独自のロジックで次に実行するべきプロセスを決定して、その結果をLinuxカーネルに通知します。

fig01

図1 ghOSt のアーキテクチャ概要（論文より抜粋）

　エージェントが用いるポリシーは、専用のライブラリを用いることにより、比較的容易に実装することができます。カーネル空間のスケジューラを実装する場合のように、Linuxカーネルに関する知識は必要としません。また、ユーザー空間のエージェントが障害で停止した場合は、Linuxカーネル標準のスケジューラが代わりに用いられるため、スケジューラの不具合により、サーバー全体が停止する危険性もありません。
　また、従来のタスクスケジューラは、CPUコアごとに実行待ちのプロセスがグループ化される「per-CPUモデル」が用いられます。つまり、次に実行するべきプロセスを選択する処理は、CPUコアごとに独立して行われます。一方、最近の研究によると、比較的長い時間単位（マイクロ秒単位）で実行時間が割り当てられるワークロードの場合は、複数のCPUコアをまとめた単位でスケジューリングした方が全体的な実行効率が向上する場合があります。ghOStは、このようなスケジューリング方式にも対応しており、複数のCPUをまとめた「Enclave」を定義して、Enclaveごとにスケジューリングを行うことができます（図2）。

fig02

図2 Enclaveを用いたスケジューリング処理（論文より抜粋）

　図2の左は、CPUコアごとにスケジューリングを行う場合で、それぞれのCPUコアに対してスケジューリング処理を行うエージェントが割り当てられています。図2の右は、Enclaveを用いて複数のCPUコアをグループ化した場合です。この場合、Enclaveに含まれるそれぞれのCPUコアに対してエージェントが割り当てられていますが、その中の1つがグローバルエージェントとして、スケジューリング処理を行います。その他のエージェントは、スリープして待機した状態になります。

次回予告

　今回は、2021年に公開された論文「ghOSt: Fast and Flexible User-Space Delegation of Linux Scheduling」を元にして、Googleのエンジニアが開発したプラグイン型のタスクスケジューラ「ghOSt」について、アーキテクチャの概要を紹介しました。次回は、Linuxカーネルとユーザー空間のエージェントの通信方法など、より詳細なアーキテクチャを説明していきます。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡