Kubernetesはコンテナオーケストレーションにおける圧倒的な存在だ。
世界最大級のデプロイメントを支えているが、それには代償が伴う。

特に小規模なチームにとっては、運用に手間がかかり、学習曲線も急だ。trivagoで4人のチームが目指していたことに対しては、オーバーヘッドが大きすぎた。そこで代替手段を探し、Nomadに惚れ込んだ。

ウィッシュリスト

私たちのチームは、監視やパフォーマンス分析のための典型的なサービスを数多く運用している。Goで書かれたメトリクス用APIエンドポイント、Prometheusエクスポーター、LogstashやGollumのようなログパーサー、そしてInfluxDBやElasticsearchのようなデータベースだ。これらのサービスはそれぞれ独自のコンテナで動作している。私たちが必要としていたのは、これらのジョブを稼働させ続けるためのシンプルな仕組みだった。

まずはコンテナオーケストレーションに求める要件をリストアップした。

• 多数のマシンにわたってサービス群を実行できること。
• 稼働中のサービスの全体像を把握できること。
• サービス間の通信を可能にすること。
• サービスが停止した際に自動で再起動すること。
• 小さなチームで管理できること。

さらに、必須ではないがあると嬉しい要件は次のとおりだった。

• マシンを能力ごとにタグ付けできること（例：I/O負荷の高いサービスのために高速ディスクを搭載したマシンにラベルを付ける）。
• これらのサービスをオーケストレーターに依存せずに実行できること（例：開発環境）。
• 設定やシークレットを共有するための共通の場所があること。
• メトリクスやロギング用のエンドポイントが提供されること。

なぜKubernetesは私たちに合わなかったのか

Kubernetesでプロトタイプを作成した際、サービスを運用するためにどんどん複雑なロジックを積み重ねていることに気づいた。しかも、そのロジックに暗黙のうちに依存するようになっていた。

一例として、KubernetesではConfigMapsを使ってサービス設定を埋め込むことができる。特に複数の設定ファイルをマージしたり、Podにサービスを追加したりする場合、すぐに非常に分かりにくくなる。Kubernetesやhelmを使えば、関心の分離を保つために外部設定を動的に注入することもできる。しかし、これはプロジェクトとKubernetesの間に密接で暗黙的な結合を生みかねない。HelmやConfigMapsはオプション機能なので、使わなくてもよい。設定をそのままDockerイメージにコピーするという手もある。ただ、その道に進むのは誘惑的で、後になって不要な抽象化に足をすくわれることになりかねない。

さらに、Kubernetesのエコシステムは今も急速に進化している。ベストプラクティスや最新のツールに追従するには、かなりの時間と労力がかかる。kubectl、minikube、kubeadm、helm、tiller、kops、oc——挙げればきりがない。Kubernetesを始めるのにすべてのツールが必要なわけではないが、どれが必要なのかを判断するのは難しく、少なくともそれぞれが何なのかは把握しておかなければならない。そのため、学習曲線はかなり急だ。

Kubernetesを使うべきとき

trivagoの中でも、多くのチームがKubernetesを使い、満足している。ただし、それらの環境はGoogleやAmazonによって管理されており、そうした運用を担うだけの能力がある。

Kubernetesには、大規模なコンテナオーケストレーションをより管理しやすくする素晴らしい機能が備わっている。

• きめ細かい権限管理
• カスタムコントローラーにより、ロジックをクラスタ内に持ち込める。これらはKubernetes APIと通信するプログラムにすぎない。
• オートスケーリング！ Kubernetesは需要に応じてサービスを自動でスケールアップ・ダウンできる。サービスメトリクスを使って、手動介入なしでこれを行う。

問題は、それらの機能が本当に必要かどうかだ。これらの抽象化が勝手にうまく動くことを当てにしてはならない。内部で何が起きているのかを学ぶ必要がある。

特に、trivagoのコアインフラと密接につながっているためほとんどのサービスをオンプレミスで運用している私たちのチームでは、自前でKubernetesクラスタを運用するコストをかけたくなかった。私たちがやりたかったのは、サービスを届けることだった。

電池は付属しません

Nomadは、サービスオーケストレーションの20%で80%を実現するような存在だ。やることはデプロイの管理だけだ。ロールアウトを処理し、エラー時にコンテナを再起動する。それだけだ。

Nomadの本質は、あえて少なくすることにある。きめ細かい権限管理や高度なネットワークポリシーは含まれていないが、それは設計思想によるものだ。そうしたコンポーネントは、エンタープライズサービスやサードパーティによって提供されるか、あるいはそもそも提供されない。

Nomadは、使いやすさと表現力の間で絶妙なバランスを突いていると思う。小規模で、互いにほぼ独立したサービスにはうってつけだ。より高度な制御が必要なら、自分で作るか別のアプローチを取る必要がある。Nomadは単なるオーケストレーターなのだ。

Nomadの最も素晴らしい点は、簡単に置き換えられることだ。提供する機能はサービスを管理する他のあらゆるシステムに簡単に統合できるため、ベンダーロックインはほとんどない。クラスタ内のすべてのマシンで、昔ながらの単一バイナリとして動作するだけだ。それだけのことだ。

疎結合なコンポーネントからなるNomadのエコシステム

Nomadの真の力は、そのエコシステムにある。Consul（キーバリューストア）やVault（シークレット管理）といった、完全にオプションの他製品と非常によく統合できる。Nomadファイルの中では、そうしたサービスからデータを取得するためのセクションを記述できる。

template {
  data = <<EOH
LOG_LEVEL="{{key \"service/geo-api/log-verbosity\"}}"
API_KEY="{{with secret \"secret/geo-api-key\"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

この設定はConsulからservice/geo-api/log-verbosityキーを読み取り、ジョブ内でLOG_LEVELという環境変数として公開する。また、Vaultからはsecret/geo-api-keyをAPI_KEYとして公開している。シンプルだが強力だ。

非常にシンプルなため、NomadはAPIを介して他のサービスとも簡単に拡張できる。例えば、サービスディスカバリのためにジョブにタグを付けることができる。trivagoでは、メトリクスを公開するすべてのサービスにtrv-metricsというタグを付けている。こうすることで、PrometheusがConsul経由でサービスを検出し、/metricsエンドポイントを定期的にスクレイプして新しいデータを取得する。同じことは、例えばLokiを統合することでログについても実現できる。

拡張性の例は他にもたくさんある。

• WebhookとConsul watchesを使ってJenkinsジョブをトリガーし、サービス設定の変更時にNomadジョブを再デプロイする。
• Cephを使ってNomadに分散ファイルシステムを追加する。
• fabioを使ってロードバランシングを行う。

こうした仕組みのおかげで、私たちは事前に大きなコミットをすることなく、インフラを有機的に成長させることができた。

念のための注意

完璧なシステムなど存在しない。派手な新機能を今すぐ本番環境で使うことはおすすめしない。もちろんバグや未実装の機能もあるが、それはKubernetesでも同じだ。

Kubernetesと比べると、Nomadの背後にある勢いははるかに小さい。これまでにKubernetesは約75,000コミット、2,000人のコントリビューターを集めているのに対し、Nomadは約14,000コミット、300人のコントリビューターだ。NomadがKubernetesの開発速度に追いつくのは難しいだろうが、そもそも追いつく必要はないのかもしれない。スコープははるかに狭く、コミュニティが小さいことは、Kubernetesと比べてプルリクエストが受け入れられやすいことを意味するかもしれない。

まとめ

結論はこうだ。みんなが使っているからという理由だけでKubernetesを使うべきではない。要件を慎重に見極め、どのツールが適しているかを検討しよう。

大規模なインフラに同種のサービス群をデプロイする予定なら、Kubernetesが適しているかもしれない。ただし、追加の複雑さと運用コストがかかることは覚悟しておこう。これらのコストの一部は、Google Kubernetes EngineやAmazon EKSのようなマネージドKubernetes環境を使うことで回避できる。

もし、保守が容易で拡張性のある信頼できるオーケストレーターを探しているだけなら、Nomadを試してみてはどうだろう。どこまでやれるのか、驚くかもしれない。

Kubernetesが車だとすれば、Nomadはスクーターだ。時には一方が、時にはもう一方が向いている。どちらにも存在する意味がある。