AWSでNomadクラスタを構築――クラスタやジョブ管理の仕組みと内部構造を知る：コンテナ実行基盤「Nomad」をKubernetesと比較検証（3）（2/2 ページ）

[守永宏明，grasys]

Job Specification

　Jobファイルの定義についてポイントを押さえて説明します。詳細は公式ドキュメントをご確認ください。

　NomadのJobは階層構造になっており、HCL（HashiCorp configuration language）かJSONで記述します。ヒューマンリーダブルなシンタックスになっているので、HCLで記述しない理由はないでしょう。他のHashiCorpプロダクトを利用したことがあればなじみのある設定言語ではないでしょうか。

　NomadのJobを動的に生成してデプロイするようなワークフローではJSONが活躍します。

Network Stanza

　ワークロードが利用するネットワークの定義を記述します。Driverごとにサポートしているネットワークモードが異なるので、利用するDriverの設定を確認する必要があります。

　例えば、Docker Driverはhostモードとbridgeモードをサポートしていますが、hostモードを利用する場合はconfigに「host_network = true」を、bridgeモードを利用する場合はNetwork Stanzaに「mode = bridge」を記述する必要があります。

　containerd Driverも同様に上記ネットワークモードをサポートしています。

　ポートマッピングを利用することで、ワークロードが実行されているネットワークネームスペースのトラフィックを、ホストネットワークのポートにマップすることができます。また、複数のネットワークインタフェースが存在する場合には、どのネットワークインタフェースにポートマッピングするか選択できます。

Task Stanza

　Jobが実行するワークロードの定義を記述します。configにはDriver固有の設定を記述してワークロードを構成できます。

Service Stanza

　Taskが実行するサービスをConsul Serviceに登録できます。ConsulのサービスディスカバリとDNSが利用可能になり、Consul Connectではサービスを論理単位で扱うことが可能になります。

Job Type

　実行可能なJobは3種類です。

• service：永続的に稼働するプロセスです。APIサーバやProxyなどステートレスなワークロードを実行するときに利用します
• system：全てのNomad ClientにAllocateをされるJobです。全てのClientの状態を利用するデーモンプロセスなどを稼働させるときに使います。KubernetesのStatefulSetに似ています
• batch：処理が完了したら終了してAllocationを開放するプロセスです。ワークロードを初期化する処理や定期的にワークロードを実行するときに利用します

Artifact

　任意の場所から指定したファイルを取得してNomadの実行環境に配置する機能を提供します。公開されているリポジトリなどからQUEMイメージファイルやjarファイルを取得したい場合に必要な設定です。

サービスメッシュ

　Consul ConnectでEnvoyをNomadのSidecar Taskとして実行し、サービスメッシュの機能を利用することが可能になります。

モニタリング

　Nomad UIでJobの状態管理はもちろん、ClientやTaskのリソース利用状況などをモニタリング可能です。ただし、リソースの詳細やアプリケーション固有のメトリクスはPrometheusやGrafanaなどのモニタリングツールを利用する必要があります。

ロギング

　ワークロードの標準出力および標準エラーをロギングする機能が備わっており、UIまたはCLIを利用してモニタリングできます。ログの保存や分析が必要なシステムではFluentdやBeatsなどのツールを利用する必要があります。

ストレージ

　Clientにhost_volumeを設定してTaskにvolumeを指定すれば、ClientノードのホストOSファイルシステムを永続的なストレージとして利用できます。詳細は公式ドキュメントを参考にしてみてください。

Consul Integration

　構築済みのConsulと接続することで、次の機能が利用できるようになります。

自動クラスタ構築

　Nomadは、Consulクラスタノードの中からNomadサーバが稼働しているノードを探してクラスタに加わります。この挙動は初期構築時もフェイルオーバー時も同様に機能します。

Service登録

　JobのService Stanzaに記述した設定がConsul Serviceとして登録されます。ConsulがServiceを検知することによりServiceの状態を監視したり、Consul agentをホストしているノードからサービスにアクセスしたりできるようになります。

　サービスのアクセスにはConsul DNSも利用できます。

Consul KVデータの利用

　JobのTemplate Stanzaを利用することでConsul KVのデータにアクセスできるようになります。

Consul Connect Integration

　mTLSとIntentionを利用することにより、マイクロサービスにおけるサービス間の認証と通信制御が可能になります。これによりサービス間の認証と通信制御のためにネットワーク構成やFirewall（FW）などの設定をする必要がなくなります。

Prerequisites

　利用する際は次の前提条件を確認する必要があります。

• Consul Connectの動作要件としてLinux Network Namespaceが必要なため、macOSとWindowsでは動作しません
• Nomad ClientがNetwork Namespaceを利用するためにはCNIプラグインが必要となるので、ホストにインストールしておく必要があります
• ConsulはConnectを利用できるように設定しておく必要があります

mTLS

　ConsulにはBuilt-In CAという認証に使う認証局やサーバ証明書などを管理する機能が備わっています。Built-In CAとしてVaultを設定することも可能です。

　サービス間コミュニケーションにConsul Connectを利用するとセキュアなワークロードを構成できます。アプリケーションを変更することなくサービス同士のTLS通信ができ、セキュアな通信が実行されます。

Intention

　TLS通信では証明書を利用してサービスを認証可能です。証明書を利用してサービス間通信を認可する機能がIntentionです。サービスを論理的に捉えることでネットワーク構成やFWを意識することなく通信を制御できます。

　例えば、サービスAからはデータベースにアクセスすることを許可するが、サービスBからはアクセスを許可しないといった設定を簡単に実装できます。

Observability

　サービス間のメトリクスをConsul UIで表示できます。また、別途EnvoyのメトリクスをPrometheusで表示することも可能です。

構成オプション

　Consul Connectの構成オプションはnative、sidecar_service、gatewayがあります。

• native：Taskが実行するアプリケーションがProxyの実装を内包している場合に利用できます
• sidecar_service：Consul Connectを構成します。デフォルトではEnvoyをSidecar Proxyとしてインジェクションし、mTLSやIntentionの振る舞いを実行します。また、sidecar_taskを設定することでSidecar Proxyをカスタマイズできます
• gateway：Consul Mesh Gatewaysを構成します。デフォルトではEnvoyをGateway Proxyとしてインジェクションし、Gatewayとしての振る舞いを実行します。また、sidecar_taskを設定することでGateway Proxyをカスタマイズできます。さらにConsul Connect Gatewaysを構成するためにgateway Stanzaが用意されています

Vault Integration

　構築済みのVaultと接続することにより、Vaultが管理しているシークレットにアクセスできるようになります。

　ワークロードで動作するアプリケーションは別のアプリケーションやAPI、データベースなどにアクセスすることが想定されます。そのためワークロード上ではアクセストークン、パスワード、クレデンシャル、API Keyなどのシークレットを安全に利用する必要があります。

　シークレットをJobに直接記述するのではなく、template StanzaにVaultからシークレットを取得するためのテンプレートを記述することで、動的かつ安全にシークレットを利用することが可能です。

シークレット管理

　Nomadにはシークレットを管理する機能はありません。Vaultがシークレット管理を担いますのでVaultインテグレーションを利用しましょう。

マルチクラスタ管理

　NomadはMulti-Region Federationによるマルチクラスタ管理が可能です。2つのクラスタを別々のRegionに構築するだけで、簡単にマルチクラスタ環境を構築できます。

（出典：公式サイト）

Region

　クラスタはRegionごとに1つだけ存在します。複数のロケーションにクラスタを構築してMulti-Region Federationを構成でき、ワークロードの高可用性を担保します。

Datacenter

　クラスタは複数のDatacenterを含むことができます。NomadのDatacenterはConsulとはコンセプトが異なり、物理的なロケーションというよりはワークロードを論理的に分けて管理するために用意されています。

ファーストクラス実装

　Consul、Vault、Consul TemplateといったHashiCorpが提供するプロダクトを、ネイティブに利用可能です。

• Consulによる自動クラスタリング、サービスディスカバリ、DNS、Consul Connectなどの機能
• クレデンシャル管理と安全な利用
• GolangテンプレートをJobに定義し、Consul KVやVaultシークレットをワークロードで扱う

サードパーティー製ソフトウェアの連携

　Nomadは次のソフトウェアと連携して動作し、ワークロードに必要な機能を拡張します。

Envoy

　Consul ConnectのSidecar Proxy Taskとしてインジェクションされ、サービスメッシュの機能を提供します。NomadにおいてはConsulがEnvoyのコントロールプレーンの役割を担います。Consulの設定を変更することでTraffic SplittingやCircuit Brakingの機能を実現できます。

（出典：公式サイト）

CNI

　CNIの機能を通じてネットワーク管理を拡張可能です。

CSI

　CSI（Container Storage Interface）の機能を通じてさまざまなCloud Providerのディスクデバイスを利用することが可能です。CSIのサポートはまだβ段階ですが、筆者はCSIのチュートリアルを実行してAmazon EBS CSI driverが動作することを確認しています。

Enterprise版について

　OSS（オープンソースソフトウェア）版は十分な機能を備えていますが、HashiCorpのサポートが必要な場合や追加の機能が必要な場合はEnterprise版の購入を検討してください。Enterprise版を購入することによりさまざまな機能が利用できるようになります。例として、Multi-RegionにまたがったJobの管理や動的リソースのサイズ変更、Sentinelを用いたJobファイルの検証などがあります。

まとめ

　Nomadはバイナリ1つで提供されているためインストールが非常にシンプルです。しかし、本番環境での活用においてはコンテナオーケストレーター以外の機能が必要になるケースがほとんどのため、ConsulとVaultのインテグレーションが必須でしょう。ConsulおよびVaultにある程度精通していないと設定や初期化、クラスタリングなどの難易度が高まり、インストールや構築のハードルがぐっと高くなる印象です。

　しかし、NomadのTask Driverを活用することでさまざまなワークロードを協調させて動作させることができます。Multi-Region Federationによるマルチクラスタ管理がコア機能として備わっており、Consul Connectを利用したサービスメッシュもConsul Integrationにより実現できます。インストールや構築のハードルは高いかもしれませんが、オンプレミスからクラウドへの移行や大規模なサービス展開、マルチクラウドを検討している企業にとってNomadは魅力的なプロダクトの一つといえるでしょう。

筆者紹介

守永宏明

grasys R&D Lead Engineer

組み込み系IT企業、金融関係のオンライントレードシステム開発企業を経て、ソーシャルゲーム開発・運営会社へ入社。ゲームプログラマ、開発推進メンバーとして経験を積み、2015年2月にgrasysへ参画。Google Cloudでのさまざまなインフラ環境の構築／運用、監視プログラムの設計／開発経験を持つ。最近は社内システムの選定／インテグレーション、全体効率化などにフォーカスした活動を続けている。

Google Cloud / AWS / Azureを中心に技術情報を発信中

【grasys engineer blog】