このページでは、永続ワーカーの使用方法、メリット、要件、ワーカーがサンドボックス化に与える影響について説明します。
永続ワーカーとは、Bazel サーバーによって開始される長時間実行プロセスのことです。永続ワーカーは、実際のツール（通常はコンパイラ）のラッパー、またはツール自体として機能します。永続ワーカーを活用するには、ツールが一連のコンパイルをサポートし、ツールの API と以下で説明するリクエスト/レスポンス形式を変換するラッパーが必要です。同じワーカーは、同じビルド内で --persistent_worker フラグの有無にかかわらず呼び出される可能性があり、ツールを適切に起動して通信し、終了時にワーカーをシャットダウンします。各ワーカー インスタンスには、<outputBase>/bazel-workers の下にある個別の作業ディレクトリが割り当てられます（ただし、chroot 権限はされません）。
永続ワーカーの使用は実行戦略の一つです。これにより、起動オーバーヘッドが削減され、JIT コンパイルが増加し、アクション実行時の抽象構文ツリーなどのキャッシュ保存が可能になります。この戦略では、複数のリクエストを長時間実行プロセスに送信することで、これらの改善を実現しています。
永続ワーカーは、Java、Scala、Kotlin など、複数の言語で実装されています。
NodeJS ランタイムを使用するプログラムでは、@bazel/worker ヘルパー ライブラリを使用してワーカー プロトコルを実装できます。
永続ワーカーの使用
Bazel 0.27 以降では、ビルドの実行時にデフォルトで永続ワーカーが使用されますが、リモート実行が優先されます。永続ワーカーをサポートしていないアクションの場合、Bazel はアクションごとにツール インスタンスを起動するようにフォールバックします。永続ワーカーを使用するようにビルドを明示的に設定するには、該当するツールのニーモニックに worker
戦略を設定します。ベスト プラクティスとして、次の例では worker 戦略のフォールバックとして local を指定しています。
bazel build //my:target --strategy=Javac=worker,local
ローカル戦略ではなくワーカー戦略を使用すると、実装によってはコンパイル速度が大幅に向上します。Java の場合、ビルドは 2 ～ 4 倍速くなり、増分コンパイルの場合はそれ以上速くなります。Bazel のコンパイルは、ワーカーを使用した場合の約 2.5 倍の速さです。詳細については、ワーカー数の選択をご覧ください。
ローカルのビルド環境と一致するリモートビルド環境もある場合は、リモート実行とワーカー実行を競合させる試験運用版の動的戦略を使用できます。動的戦略を有効にするには、--experimental_spawn_scheduler フラグを渡します。この戦略ではワーカーが自動的に有効になるため、worker 戦略を指定する必要はありませんが、フォールバックとして local または sandboxed を使用できます。
ワーカー数の選択
ニーモニックあたりのデフォルトのワーカー インスタンス数は 4 ですが、worker_max_instances フラグを使用して調整できます。使用可能な CPU の有効活用と、JIT コンパイルとキャッシュ ヒットの量はトレードオフの関係にあります。ワーカーが多いほど、JIT されていないコードの実行やコールド キャッシュのヒットが発生するため、ターゲットも起動コストを支払うことになります。ビルドするターゲットの数が少ない場合、単一のワーカーでコンパイル速度とリソース使用量のトレードオフが最適になる可能性があります（たとえば、問題 #8586 を参照）。worker_max_instances フラグは、ニーモニックとフラグセットごとのワーカー インスタンスの最大数を設定します（下記参照）。このため、混合システムでは、デフォルト値のままにすると、大量のメモリを使用することになります。増分ビルドの場合、複数のワーカー インスタンスのメリットはさらに小さくなります。
このグラフは、64 GB の RAM を搭載した 6 コア ハイパー スレッド Intel Xeon 3.5 GHz Linux ワークステーションでの Bazel（ターゲット //src:bazel）のゼロからコンパイル時間を示しています。ワーカー構成ごとに 5 つのクリーンビルドが実行され、最後の 4 つのビルドの平均が取得されます。
図 1. クリーンビルドのパフォーマンス向上のグラフ。
この構成では、2 つのワーカーのほうがコンパイルが最速ですが、1 つのワーカーの場合と比べて改善はわずか 14% です。使用するメモリを減らしたい場合は、1 つのワーカーをおすすめします。
一般的に、増分コンパイルの方が大きなメリットがあります。クリーンビルドは比較的まれですが、特にテスト駆動開発では、コンパイルの合間に単一のファイルを変更することが一般的です。上記の例には、Java 以外のパッケージ化アクションもあります。これにより、増分コンパイル時間が無視される可能性があります。
AbstractContainerizingSandboxedSpawn.java で内部文字列定数を変更した後に Java ソースのみ（//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar）を再コンパイルすると、速度が 3 倍になります（1 つのウォームアップ ビルドが破棄され、平均 20 個の増分ビルド）。
図 2. 増分ビルドのパフォーマンス向上のグラフ。
速度の速さは、変更内容によって変わります。上記の状況でよく使用される定数が変更されたときに、係数 6 の高速化が測定されます。
永続ワーカーの変更
--worker_extra_flag フラグを渡して、起動フラグをワーカーに指定できます。キーはニモニックです。たとえば、--worker_extra_flag=javac=--debug を渡すと、Javac に対してのみデバッグが有効になります。worker フラグは、このフラグの使用ごとに 1 つだけ設定できます。また、1 つのニーモニックに対してのみ設定できます。ワーカーは、ニモニックごとに個別に作成されるだけでなく、起動フラグのバリエーションごとにも作成されます。ニーモニック フラグと起動フラグの各組み合わせが WorkerKey に結合され、WorkerKey ごとに最大 worker_max_instances 個のワーカーを作成できます。アクション構成でセットアップ フラグも指定する方法については、次のセクションをご覧ください。
--high_priority_workers フラグを使用すると、通常の優先度のニーモニックに優先して実行されるニモニックを指定できます。これにより、常にクリティカル パスに存在するアクションを優先できます。優先度の高いワーカーが 2 つ以上ある場合、他のワーカーはすべて実行されません。このフラグは複数回使用できます。
--worker_sandboxing フラグを渡すと、各ワーカー リクエストのすべての入力に個別のサンドボックス ディレクトリが使用されます。sandboxのセットアップは、特に macOS の場合に時間がかかりますが、正確性の保証が向上します。
--worker_quit_after_build フラグは、主にデバッグとプロファイリングに役立ちます。このフラグを指定すると、ビルドが完了すると、すべてのワーカーが強制的に終了します。また、--worker_verbose を渡して、ワーカーの動作に関するより多くの出力を取得することもできます。このフラグは WorkRequest の verbosity フィールドに反映されるため、ワーカーの実装をより冗長にすることもできます。
ワーカーは、ログを <outputBase>/bazel-workers ディレクトリ（/tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log など）に保存します。ファイル名には、ワーカー ID とニーモニックが含まれています。1 つのニーモニックに複数の WorkerKey が存在する可能性があるため、1 つのニーモニックに複数の worker_max_instances ログファイルが表示されることがあります。
Android ビルドの詳細については、Android ビルド パフォーマンスのページをご覧ください。
永続ワーカーの実装
ワーカーの作成方法については、永続ワーカーの作成ページをご覧ください。
次の例は、JSON を使用するワーカーの Starlark 構成を示しています。
args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
output = args_file,
content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
mnemonic = "SomeCompiler",
executable = "bin/some_compiler_wrapper",
inputs = inputs,
outputs = outputs,
arguments = [ "-max_mem=4G", "@%s" % args_file.path],
execution_requirements = {
"supports-workers" : "1", "requires-worker-protocol" : "json" }
)
この定義では、このアクションを初めて使用する場合は、コマンドライン /bin/some_compiler -max_mem=4G --persistent_worker を実行します。Foo.java をコンパイルするリクエストは次のようになります。
注: プロトコル バッファの仕様では「スネークケース」（request_id）を使用しますが、JSON プロトコルでは「キャメルケース」（requestId）を使用します。このドキュメントでは、JSON の例でキャメルケースを使用しますが、プロトコルに関係なくフィールドについて説明する場合はスネークケースを使用します。
{
"arguments": [ "-g", "-source", "1.5", "Foo.java" ]
"inputs": [
{ "path": "symlinkfarm/input1", "digest": "d49a..." },
{ "path": "symlinkfarm/input2", "digest": "093d..." },
],
}
ワーカーは、これを改行区切りの JSON 形式で stdin で受け取ります（requires-worker-protocol が JSON に設定されているため）。次に、ワーカーがアクションを実行し、JSON 形式の WorkResponse を stdout で Bazel に送信します。次に、Bazel でこのレスポンスを解析し、手動で WorkResponse proto に変換します。JSON ではなくバイナリエンコードされた protobuf を使用して関連するワーカーと通信するには、次のように requires-worker-protocol を proto に設定します。
execution_requirements = {
"supports-workers" : "1" ,
"requires-worker-protocol" : "proto"
}
実行要件に requires-worker-protocol が含まれていない場合、Bazel はデフォルトで protobuf を使用するようにワーカー通信を行います。
Bazel は、ニーモニックと共有フラグから WorkerKey を取得しているため、この構成で max_mem パラメータの変更が許可されている場合、使用される値ごとに個別のワーカーが生成されます。バリエーションが多すぎると、メモリが過剰に消費される可能性があります。
現在のところ、各ワーカーは一度に 1 つのリクエストしか処理できません。試験運用版のマルチプレックス ワーカー機能では、基盤となるツールがマルチスレッドであり、これを理解するようにラッパーが設定されている場合、複数のスレッドを使用できます。
この GitHub リポジトリでは、Java と Python で記述されたワーカー ラッパーの例を確認できます。JavaScript や TypeScript で作業している場合は、@bazel/worker パッケージと nodejs ワーカーのサンプルが役に立つかもしれません。
ワーカーはサンドボックスにどのように影響しますか？
デフォルトでは、worker 戦略を使用すると、local 戦略と同様に、sandboxではアクションは実行されません。--worker_sandboxing フラグを設定して、サンドボックス内のすべてのワーカーを実行することで、ツールの各実行で想定されている入力ファイルのみを認識させることができます。ただし、キャッシュなどを通じて、リクエスト間の情報が内部的に漏洩する可能性があります。dynamic 戦略を使用する場合、ワーカーをサンドボックス化する必要があります。
ワーカーでコンパイラ キャッシュを正しく使用できるように、各入力ファイルとともにダイジェストが渡されます。したがって、コンパイラまたはラッパーは、ファイルを読み取ることなく、入力がまだ有効かどうかを確認できます。
不要なキャッシュを防ぐために入力ダイジェストを使用する場合でも、サンドボックス化されたワーカーは、純粋なサンドボックスよりも厳密なサンドボックス化を行いません。これは、このツールが以前のリクエストの影響を受けた他の内部状態を保持する可能性があるためです。
Multiplex ワーカーは、ワーカーの実装でサポートされている場合にのみサンドボックス化できます。このサンドボックス化は、--experimental_worker_multiplex_sandboxing フラグを使用して個別に有効にする必要があります。詳細については、設計ドキュメントをご覧ください。
参考資料
永続ワーカーの詳細については、以下をご覧ください。
- 元の永続ワーカーに関するブログ投稿
- Haskell 実装の説明 {: .external}
- Mike Morearty によるブログ投稿{: .external}
- Bazel を使用したフロントエンド開発: Asana を使用した Angular / TypeScript と永続ワーカー {: .external}
- Bazel 戦略の説明 {: .external}
- bazel-discuss メーリング リストにおける、情報豊かな従業員戦略の議論 {: .external}