Nomad クラスタの操作の概要
CircleCI Server version 2.x は、リリースのサポートが終了しています。 リリースがサポートされているバージョンへのアップグレードについては、お客様のアカウントチームにご相談ください。 |
CircleCI では、プライマリジョブスケジューラとして Nomad を使用します。 ここでは、CircleCI Server で Nomad クラスタを操作する方法をご理解いただくための Nomad の基本的な概要について説明します。
基本的な用語とアーキテクチャ

-
Nomad サーバー: Nomad サーバーは、Nomad クラスタの "頭脳" です。 ジョブを受け取り、Nomad クライアントに割り当てます。 CircleCI では、Nomad サーバーは Docker コンテナとしてサービスマシンで実行されます。
-
Nomad クライアント: Nomad クライアントは、Nomad サーバーによって割り当てられたジョブを実行します。 通常、Nomad クライアントは専用のマシン (多くの場合は VM) 上で実行されるため、マシンの能力を最大限に活用できます。 複数の Nomad クライアントで 1つのクラスタを構成することができ、Nomad サーバーはスケジュールアルゴリズムに従ってクラスタにジョブを割り当てます。
-
Nomad ジョブ: Nomad ジョブは、ユーザーによって提供される仕様で、Nomad のワークロードを宣言します。 Nomad ジョブは、CircleCI ジョブの実行に対応しています。 たとえば 10個の並列実行を使用するジョブの場合、Nomad は 10個のジョブを実行します。
-
ビルドエージェント: ビルドエージェントは CircleCI によって記述された Go プログラムで、ジョブ内のステップを実行し、結果を報告します。 ビルドエージェントは、Nomad ジョブ内部のメイン処理として実行されます。
基本的な操作
ここでは、CircleCI での Nomad クラスタの基本的な操作について説明します。
nomad
CLI は Service インスタンスにインストールされます。 Nomad クラスタとやり取りするようにあらかじめ設定されているため、nomad
コマンドを使用して、以下で説明するコマンドを実行できます。
ジョブステータスの確認
クラスタ内のすべてのジョブのステータス一覧を表示するには、以下のコマンドを実行します。
nomad status
Status
は、出力内容のうち最も重要なフィールドで、以下のステータスタイプが定義されています。
-
running
: Nomad でジョブの実行が開始されています。 このステータスは通常、CircleCI 上のジョブが開始されたことを意味します。 -
pending
: クラスタ内に、ジョブを実行するためのリソースが不足している状態です。 -
dead
: Nomad でジョブの実行が終了しました。 対応する CircleCI のジョブまたはビルドが成功したか失敗したかにかかわらず、ステータスはdead
になります。
クラスタのステータスの確認
Nomad クライアントの一覧を表示するには、以下のコマンドを実行します。
nomad node-status
nomad node-status コマンドを実行すると、現在稼働中の Nomad クライアント (ステータスが active ) と、クラスタから除外された Nomad クライアント (ステータスが down ) の両方が報告されます。 したがって、現在のクラスタの容量を知るには、ステータスが active の Nomad クライアントの数を数える必要があります。 |
特定のクライアントの詳細情報を表示するには、そのクライアントで以下のコマンドを実行します。
nomad node-status -self
上記の手順を行うと、クライアント上で実行中のジョブの数や、クライアントのリソースの利用状況などの情報が表示されます。
ログの確認
Nomad ジョブのセクションで前述したように、このジョブは CircleCI ジョブの実行と対応しています。 そのため、CircleCI ジョブで問題が発生した場合、Nomad ジョブのログを確認すると、そのジョブのステータスを理解するのに役立つことがあります。 特定のジョブのログを表示するには、以下の手順を行います。
nomad logs -job -stderr <nomad-job-id>
-stderr フラグは必ず指定してください。 これにより、ほとんどのビルドエージェントのログが表示されます。 |
nomad logs -job
コマンドは便利ですが、-job
フラグは指定されたジョブのランダム割り当てを使用するため、必ずしも正確とは限りません。 割り当て
(allocation)は Nomad ジョブ内のさらに小さい単位です。 これについては、このドキュメントでは取り上げません。 詳細については、https://www.nomadproject.io/docs/internals/scheduling.html[Nomad の公式ドキュメント]を参照してください。
指定されたジョブの割り当てからログを取得するには、以下の手順に従います。
-
nomad status
コマンドで、ジョブ ID を取得します。 -
Get the allocation ID of the job with
nomad status <job-id>
command. -
Get the logs from the allocation with
nomad logs -stderr <allocation-id>
クラスタのスケールアップ
デフォルトでは、Nomad クライアントは AWS の Auto Scaling Group (ASG) 内にセットアップされます。 設定を表示するには、
-
EC2 ダッシュボードに移動し、左側のメニューから [Auto Scaling Groups (Auto Scaling グループ)] を選択します。
-
Nomad クライアントを選択します。
-
Actions > Edit を選択し、Desired/Minimum/Maximum の数を編集して設定します。 これにより、スピンアップして使用可能なままにする Nomad クライアントの数を定義します。 [Scaling Policy (スケーリングポリシー)] タブを使用して忙しい時刻にグループを自動的にスケールアップするように設定できます。ポリシーの定義に関するベストプラクティスについては、以下のセクションを参照してください。 Use nomad job metrics to assist in defining your scaling policies.
Auto Scaling ポリシーのベストプラクティス
ブログの連載では、CircleCI のエンジニアリングチームが、自動スケーリングの一般的なベストプラクティスを見つけるために取り組んだコスト削減シミュレーションについて記載しています。 AWS の Auto Scaling を設定する際は、以下のベストプラクティスを適用することを検討してください。
-
原則として、クラスタは、ビルドのキューイングを回避できるくらい十分な大きさにします。 具体的には、一般的なワークロードでキューイングが 1秒未満、高価なハードウェアや高レベルな並列処理で実行されるワークロードでは 10秒未満になるようにします。 開発者の時間は高コストであるため、キューイングを 0 まで減らすようにサイズを調整することをお勧めします。 アンダープロビジョニングの費用対効果が出るまで開発者の時間を安くできるようなモデルを作成することは困難です。
-
Auto Scaling グループを作成して、大多数の開発者が通常勤務している時間帯にはスケールアップし、夜間はスケールダウンするようなステップスケーリングポリシーを適用します。 平日の勤務時間中にスケールアップし、夜間にスケールダウンしておくことで、トラフィックが少ない夜間にオーバープロビジョニングを発生させることなく、開発のピーク時に待ち時間を抑制するのがベスト プラクティスです。 なお、過去の数多くのビルドデータによると、通常の勤務時間中のデータセットはおおむね正規分布になっています。
一方で、トラフィックの変動に基づく自動スケーリングを 1 日中行う設定では、起動に長く時間がかかりすぎるため、リアルタイムにキューイングを回避できないことがモデリングから明らかになっています。 そのような状況では、http://docs.aws.amazon.com/autoscaling/latest/userguide/as-scaling-simple-step.html[ステップ ポリシーに関する Amazon のドキュメント]に従って、Auto Scaling とともに CloudWatch アラームを設定してください。
Nomad クライアントのシャットダウン
Nomad クライアントをシャットダウンするときは、まずクライアントをドレイン (drain
) モードに設定する必要があります。 drain
モードのクライアントでは、それまでに割り当てられたジョブは完了しますが、新たにジョブを割り当てることはできません。
-
クライアントをドレインするには、クライアントにログインし、
node-drain
コマンドを以下のように使用して、クライアントをドレインモードに設定します。nomad node-drain -self -enable
-
次に、
node-status
コマンドを使用してクライアントがドレインモードに変更されていることを確認します。nomad node-status -self
また、下記のコマンドにノード ID を代入して実行し、リモートノードをドレインモードに設定することもできます。
nomad node-drain -enable -yes <node-id>
クライアントクラスタのスケールダウン
クライアントをシャットダウンするメカニズムを設定するには、まずクライアントを drain
モードに変更し、すべてのジョブが完了してから、クライアントを終了させます。 また、https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html[ASG ライフサイクルフック]を設定することで、インスタンスをスケールダウンするスクリプトをトリガーできます。
このスクリプトで、上述のコマンドを使用して以下の手順を実行します。
-
インスタンスをドレインモードに設定します。
-
インスタンスで実行中のジョブを確認し、ジョブが完了するのを待ちます。
-
インスタンスを終了します。
ドキュメントの改善にご協力ください
このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。
- このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
- ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
- CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。 フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。
サポートが必要ですか
CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。
または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.