HashiCorp のブログに Nomad 0.3 のリリースに関する投稿がありました。例によって、自分のための情報整理とメモを兼ねて、翻訳内容を参考情報程度の位置づけで公開します。
■ original post
Nomad 0.3 – HashiCorp https://www.hashicorp.com/blog/nomad-0.3.html■ Nomad 0.3
私たちは Nomad 0.3 のリリースを誇りに思います。 Nomad とは分散してスケールする高可用性を持つクラスタ管理︵マネージャ︶であり、マイクロサービスとバッチ処理の両方を行うよう設計されたスケジューラです。 今回のリリースでは新機能を導入しました。中心となるコンポーネントを強固なものにします。全面的なUX︵ユーザ経験︶の改善は、Nomad をプロダクションで使えるよう、準備するに至る道を確固たるものとします。主要な機能は次の通りです。 ●定期ジョブ︵Periodic Jobs︶ ●ログ・ローテーションとファイルシステム API ●ジョブ・キュー︵Job Queues︶ より詳しい変更情報は Nomad 0.3 の CHANGELOG をご覧ください。 こちらから Nomad 0.3 をダウンロードできます。あるいは、Nomad 0.3 の新機能や改良について知りたければ、このまま読み進めてください。■ 定期ジョブ︵Periodic Jobs︶
Nomad 0.3 は定期的に実行するジョブ︵訳者注‥以下、﹁定期ジョブ﹂︶を導入しました。これはユーザが cron 形式をベースとするバッチ・ジョブを定期的に実行できます。定期ジョブとはバックアップや ETL ︵訳者注‥Extract︵抽出︶/Transform︵加工︶/Load︵読み込み︶︶のような様々なワークロードであり、大部分の環境において実行可能なものです。昨年 Nomad を発表して以来、この機能に対してコミュニティから強い要望がありました。 Nomad は定期ジョブを実行するための、分散︵分配︶とフォールト・トレラント機能を提供します。単一でエフェメラル︵ephemeral‥短命・短時間︶なノードでは、可用性の課題があります。 そのような環境では、crontab をベースとした実行システムは苦慮しますが、そこでも実行可能なのです。 次の例は、定期的にバッチを Nomad ジョブで15分ごとに動かします。job "backup" {
...
periodic {
cron = "*/15 * * * * *"
}
...
}
﹁nomad status﹂は直近で処理した定期ジョブの状態と、次の処理までのタイムスタンプを表示します。
$ nomad status backup ID = backup Name = backup Type = batch Priority = 50 Datacenters = dc1 Status = running Periodic = true Next Periodic Launch = 2016-02-25 00:40:00 +0000 UTC Previously launched jobs: ID Status backup/periodic-1456359780 dead backup/periodic-1456359840 dead backup/periodic-1456360020 running $ nomad status backup/periodic-1456360020 ID = backup/periodic-1456360020 Name = backup/periodic-1456360020 Type = batch Priority = 50 Datacenters = dc1 Status = running Periodic = false ==> Evaluations ID Priority Triggered By Status d451a894 50 periodic-job complete ==> Allocations ID Eval ID Node ID Task Group Desired Status b763c7b8 d451a894 d551531b cache run running
■ ログ・ローテーションとファイルシステム API
プロダクション環境におけるアプリケーションの管理・デバッグのためには、ログの管理が非常に重要な要素です。Nomad 0.3 では、ログ保存で直面する2つ要素を解決します。 ●﹁stdout﹂︵標準出力︶と﹁stderr﹂︵エラー出力︶のログファイルをローテーション ●ホストマシンに SSH でログインしなくても、ログにアクセスできる Nomad 0.3 はタスクごとにログ・ローテーションを指定できます。この設定を通して、ユーザはログファイルの大きさやローテーションを管理できます。以下は記述例です。logs {
max_files = 5
max_file_size = 10
}
この例では﹁stderr﹂﹁stdout﹂のログを5つのファイルに保持し、それぞれのファイルサイズは 10 MB と指定しています。アプリケーションが更にログを出力すると、古いログファイルをパージし︵削除し︶、指定した以上のログを保管しないよう制限します。
アプリケーションのログ設定機能のほかに、Nomad 0.3 ではファイル・システムのタスクを表示するための一連の新コマンドを導入しました。これはログファイルや他のファイルを表示する機能です。
$ nomad fs ls c5598dc8 redis/local/ Mode Size Modfied Time Name -rw-r--r-- 0 B 24/02/16 23:19:18 UTC redis.stderr.0 -rw-r--r-- 10 MB 24/02/16 23:22:54 UTC redis.stdout.3 -rw-r--r-- 10 MB 24/02/16 23:22:54 UTC redis.stdout.4 -rw-r--r-- 10 MB 24/02/16 23:22:54 UTC redis.stdout.5 -rw-r--r-- 10 MB 24/02/16 23:22:54 UTC redis.stdout.6 -rw-r--r-- 6.0 MB 24/02/16 23:22:54 UTC redis.stdout.7こちらの出力から分かるのは、 Nomad クライアントは直近の5つのログファイルしか保管していません。古い﹁redis.stdout.0﹂﹁redis.stdout.1﹂﹁redis.stdout.2﹂はパージされました。 特定のログファイルの内容を確認するには、次のようなコマンドを実行します。
$ nomad fs cat c5598dc8 redis/local/redis.stdout.7 <LOGの内容>ストリーミング・ログやリモート・ログを流すようなログ記録サブシステムの拡張が、Nomad のロードマップに含まれています。
■ ジョブ・キュー︵Job Queues︶
ジョブ・キューとは、ユーザがジョブをスケジュール（訳者注：どの環境上で実行するかを計画・処理すること）できるようにします。それが、全てのリソースを巨大なクラスタで使う場合でもです。リソースが追加されるか利用可能になると、 Nomad はジョブを再評価（re-evaluate）し、実行します。 以下の例は、現在よりも多くのリソースを必要とするジョブを実行します。そうすると Nomad は「blocked」と評価し、リソース変更を処理します。
$ nomad run redis-cache.nomad ==> Monitoring evaluation "b58210a7" Evaluation triggered by job "redis-cache" Scheduling error for group "cache" (failed to find a node for placement) Allocation "eb78c6f3" status "failed" (0/1 nodes filtered) * Resources exhausted on 1 nodes * Dimension "cpu exhausted" exhausted on 1 nodes Evaluation status changed: "pending" -> "complete" ==> Evaluation "b58210a7" finished with status "complete" $ nomad status redis-cache ID = redis-cache Name = redis-cache Type = service Priority = 50 Datacenters = dc1 Status = pending Periodic = false ==> Evaluations ID Priority Triggered By Status 05263d94 50 job-register blocked b58210a7 50 job-register complete ==> Allocations ID Eval ID Node ID Task Group Desired Status eb78c6f3 b58210a7 <none> cache failed failedNomad は blocked と評価しました。これはクラスタがジョブを実行するために十分な CPU リソースを持っていないためです。blocked として中断されていても、リソースが追加されるとスケジューラはそれをトリガとして、新しい割り当てとジョブ実行を処理します。
$ nomad status redis-cache ID = redis-cache Name = redis-cache Type = service Priority = 50 Datacenters = dc1 Status = pending Periodic = false ==> Evaluations ID Priority Triggered By Status 05263d94 50 job-register complete b58210a7 50 job-register complete ==> Allocations ID Eval ID Node ID Task Group Desired Status eb79c6fg 05263d94 d551531b cache running running eb78c6f3 b58210a7 <none> cache failed failedこれまでのエンジニアは極めて効率的なジョブ・キューを作ることに力を注いできました。そうではなく、スケジューラが著しく速く、より高性能に行うのです。 Nomad を使った目覚ましいパフォーマンス改善に関する概要は、近いうちにブログへの投稿する予定です。
