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

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

ウィッシュリスト

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

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

• 多数のマシンにまたがってサービス群を実行できること。
• 実行中のサービスを一覧で把握できること。
• サービス間で通信できること。
• 障害時に自動で再起動すること。
• 少人数のチームで運用管理できること。

その上で、必須ではないものの、あると嬉しい要件は次のとおりでした。

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

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

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

例えば、KubernetesではConfigMapsを使ってサービスの設定を埋め込むことができます。特に複数の設定ファイルをマージしたり、1つの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の最も優れた点は、置き換えが容易なことです。提供する機能は他のサービス管理システムにも簡単に統合できるため、ベンダーロックインがほとんどありません。クラスター内の各マシンで、ただ1つのバイナリとして動くだけ——それだけなのです！

疎結合なコンポーネントからなる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の開発スピードに追いつくのは難しいでしょう。しかし、追いつく必要はないのかもしれません！ Nomadのスコープははるかに狭く、コミュニティが小さいからこそ、Kubernetesに比べてプルリクエストが受け入れられやすいというメリットもあります。

まとめ

結論として言いたいのは、みんなが使っているからという理由だけでKubernetesを使わないでください。要件を慎重に見極め、どのツールが要件を満たすのかを確認することが大切です。

大規模なインフラに均質なサービス群をデプロイする予定であれば、Kubernetesが最適な選択肢かもしれません。ただし、そこに伴う複雑さや運用コストを十分に認識しておいてください。そうしたコストの一部は、Google Kubernetes EngineやAmazon EKSのようなマネージドKubernetes環境を利用することで回避できます。

もし、保守が容易で拡張性のある信頼できるオーケストレーターを探しているのであれば、ぜひNomadを試してみてはいかがでしょうか。きっと、その実力に驚くはずです。

Kubernetesが車だとすれば、Nomadはスクーターです。時には車が、時にはスクーターが適しています。どちらにも存在する意義があるのです。