アメリカはポートランドで開催されたHashiConfカンファレンスで、HashiCorpは、新しい分散スケジュールプラットホームであるNomadを発表した。また、新しいアプリケーションデリバリツールである‘Otto’も発表した。このツールはリモートでのアプリケーションの配置を管理することで既存のVagrantの上で動作する。
HashiCorpのCEOであるMitchell Hashimoto氏とCTOであるArmon Dadgar氏はHashiConfでのディスカッションで、スケジューラという勃興中の領域の中でNomadを特別なものにしている4つの特質について話した。スケジューラの世界は、例えば、MesosphereのMarathon、Apache Mesos、Amazon ECS、Kubernetesなどがある。Nomadの特質とは、簡単に使えること、スケーラビリティ、柔軟さ、HashiCorpのエコスシテムと連携できることだ。
Nomadはリソースのプーリング、ジョブ、タスクスケジューリングを管理するひとつのバイナリとして配置でき、他のストレージサービスか管理機構(ZooKeeperやetcdのような)は必要ない。ひとつのNomadエージェントは各ホストにインストールされ利用できるリソース(CPU、メモリ、ディスク)の情報を収集する。この情報は、Nomadサーバへ送信される。Nomadサーバはジョブの受付けやどのホストがリソースを使えるかどうかの判定、ホストのタスクのスケジューリングをする。
Nomadは複数のデータセンター、複数のリージョンで使える。ジョブのスケジューリングもデータセンターをまたいで、または、リージョンをまたいで行える。また、ネットワークやインフラの障害に耐性があるように設計されており、Nomadサーバはタスクの取りまとめをし、状態の複製をして、高可用性と耐障害性を実現する。それぞれのサーバもスケジューリングの決定に参画するよういんなっている。これによって、トータルのスループットは増加する。
Nomadのジョブとタスクの生成は、ひとつの仕様を利用する。この仕様は配置物に依存しない。これによって、ワークロードを‘仮想化したり、コンテナ化したり、スタンドアロンアプリケーション化したりできる’、とHashiCorpはいう。NomadはAtlasのようなHashiCorpの既存のエコシステムとも連携する。
NomadはHashiCorpのすべての製品が遵守している原則に従って設計されており、ユーザのワークフローいフォーカスし、基底の技術に依存しません。
新しく発表されたOttoはアプリケーションデリバリツールであり、Vagrant上で動作する。Vagrantは同社初のオープンソースツールであり、2010年にローカルの開発環境管理に関する問題を解決するためにMitchell Hashimoto氏によって開発された。Ottoも'vagrant up'スタイルで配置のワークフローでを管理でき、ローカルの開発環境も'otto deploy'で管理できる(Herokuの'git push heroku master'やDocker Composeの'compose up'よりもシンプルだ)。
アプリケーションとインフラの設計は、OttoのAppfileで定義される。このファイルは複雑で複数の層にまたがり、VMやコンテナとして、複数のインフラプロバイダに配置されるアプリケーションを定義できる。また、Ottoは複数の構成ファイルやセキュアな情報の保持、ポリシーによるアクセス制限の強制をサポートする。ただし、アクセス制御については、同社の商用製品であるAtlasと連携する必要がある。
InfoQは同社の共同設立者でありCTOであるArmon Dadgar氏にインタビューし、Nomadについて話を聞いた。
InfoQ: 'Nomad'についてお話を聞きたいと思います。'Nomad'とは何なのか簡単に説明していただけますか。
Dadgar: Nomadはクラスタマネージャでクラスタのリソースを一括してプールし、クラスタをまたいで動くアプリケーションのために管理を簡単にします。ユーザがアプリケーションに注力し基底の仕組みは抽象化するのが目的です。
Nomadを使うには、開発者は宣言的なジョブの定義をします。Nomadはその定義が制約を満たしていることを確認し、リソースの利用が最大化するように効率的にタスクのパッチングをします。Nomadは複数のワークフローをサポートします。Dockerやその他の仮想化、コンテナ化の仕組みやすべてのメジャーなOSのスタンドアロンアプリケーションをサポートします。
Nomadは、私たちの大きな目標であるマイクロサービスアーキテクチャとイミュータブルインフラの推進の一翼を担います。企業がマイクロサービスに移行するにつれ、たくさんの一枚岩のプロジェクトから何百、何千ものマイクロサービスが生まれます。Nomadを使えば、各サービスをジョブとして簡単に管理できます。Nomadのようなツールがなければ、運用上の課題はマイクロサービスの推進にとって障害となるでしょう。
現在のイミュータブルインフラの場合、配置はマシン単位で行われます。特に、PackerやTerraformのようなツールを使っている場合はそうです。このやり方はうまくいきますが、新しいマシンに展開している時間がかかり、必要以上に遅いです。不変のベースとなるOSにコンテナ化されたアプリケーションを配置するほうがいいと考えるかもしれません。しかし、このやり方だと配置に時間がかかるようになります。このような課題を解決するためにNomadのようなツールが必要なのです。
InfoQ: Nomadは既存のクラスタリソースマネージャやスケジューラとにています。例えば、GoogleのBorgやApache Mesosのようなものです。NomadやNomadで使っているアルゴリズムはこのような既存のプロジェクトを活用しているのでしょうか。
Dadgar: クラスタ管理の世界は非常に興味深い研究で満ちており、私たちも先行技術の成果の恩恵を受けています。Nomadの設計はGoogle BorgとOmegaに着想を得ています。OmegaはBorgより知られていませんが、スケジューラの楽観的並列性に新しいアプローチをしており、Nomadも影響を受けました。これによって、スケジューリングの決定を並列でできるようになりました。
Nomadは新しいプロジェクトですが、ConsulとSerfの中核にある技術を使っています。Consulは合意プロトコルRaftを使っています。SerfはgossipプロトコルSWIMをベースにしています。どちらとも大規模な環境で広く使われています。これらを活用することで、Nomadはゼロから開発するよりも強力なプロジェクトになりました。
InfoQ: 発表では、Nomadは長時間実行されるサービスでも短時間のバッチジョブもサポートするということでした。企業にとって、両方のタイプのワークロードを別々に実行できるのは重要なことでしょうか。
Dadgar: 一般的に言えば、ほとんどのサーバは、5%から20%しか使われていません。この不効率さは直接、企業のコストになります。Nomadはふたつの種類のワークフローを同じハード上で実行できるようにすることで、より効率的にし、コストを削減します。Nomadによって開発チームと運用チームの速度は上昇します。しかし、効率性とコスト削減の効果もとても大きいです。これは、とても重要なことです。
InfoQ: Windowsのアプリケーションのサポート表明されています。これは、勃興している、企業がクラスタ管理ソリューションへ移行しているという'エンタープライズ'の市場を狙うためですか。
Dadgar: Windowsは従来DevOpsの世界では顧みられていませんでした。しかし、私たちHashiCorpのエコシステムの中ではWindowsは第一に需要なプラットホームです。スタートアップの中では不人気ですが、Windowsは大企業にはとても浸透しています。このような環境では、Nomadのようなクラスタマネージャの利点は大きいです。運用課題を解決し、コストを大幅に削減するからです。
Nomadエージェントは、Windowsでそのまま動き、拡張できるタスクドライバを使います。ほとんどすべてのWindowsベースのアプリケーションをサポートするためです。仮想化されたワークフローについては、Hyper-Vやリリース予定のWindows Server Containersでサポートされるでしょう。スタンドアロンのC#やJavaのアプリケーションは、CLRとJVMでサポートされます。
InfoQ: Nomadは'複数のデータセンター、複数のリージョン'を解釈します。これはとてもユニークだと思います。どのように実現されているのでしょうか。現状の実装の制限について教えてください。
Dadgar: Nomadはデータセンターのグループをグリーバルクラスタとしてモデル化しています。これはより大きいリージョンを形成します。例えば、"us-west-1"、"us-west-2"、"us-east-1"というAWSのゾーンが"us-aws"というより大きなゾーンを形成するということです。"us-aws"リージョンは"eu-aws"リージョンとグローバルクラスタを形成します。
Nomadのクライアントはデータセンターとリージョンと共に設定され、そのリージョンのサーバとだけ通信できます。サーバ群はリージョンのレベルで運用され、スケジューリングの決定はリージョンないのデータセンターを横断します。リクエストはリージョンに関係なく作成され、サーバによって透過的にフォワードされます。
このモデルの強みは、ジョブが複数のデータセンターにまたがることができるということです。また、リージョンのレベルで障害を分離できます。制限は、ひとつのジョブが複数のリージョンにまたがることはできないことです。しかし、ユーザは同じジョブを複数のリージョンにサブミットできます。
リージョンの粒度は企業によって決めることができます。必要に応じて適切な設定ができます。ほとんどの企業はひとつのグローバルリージョンを使い、すべてのデータセンターを管理します。しかし、リージョンごとにデータセンターを持っても同じくらい簡単です。
InfoQ: 発表では、Nomadによる'運用の単純化'を強調していました。現在業界で盛り上がっているクラスタ管理アプリケーションのプロビジョニングとZooKeeperやetcdをつかった場合の信頼性を考慮するとき、これは、重要な要件なのでしょうか。
Dadgar: 運用の単純さは私たちにとって最優先の要件であり、実装です。分散システムを構築するとき、設計上での考慮点はたくさんあります。最大の問題は調整とストレージの提供です。Nomadは単一のバイナリとして提供され、他に依存物は必要ありません。デフォルトで高い可用性を備えて動作します。
クラスタマネージャの導入で一番の障壁なのが、運用の複雑さです。Nomadを使えば、この問題を解決できると思います。システムに動きのある要素があればあるほど、障害は複雑になります。分散システムはどんなものであれ、理解したり運用したりするのは大変です。複数の分散システムの管理をユーザにやってもらうのは難しいでしょう。
私たちにとっては、運用の単純さは最初のセットアップだけのことではありません。Nomadのメンタルモデルは理解しやすいので、ユーザは論理的に考えることができます。日常業務でNomadを使う開発者は、簡単に利用開始できます。APIも簡単に利用できるのでツールの構築も簡単です。単純さと理解しやすさは信頼性を産みます。信頼性はシステムにとって致命的に重要です。
InfoQ: 他にInfoQの読者に伝えたいことはありますか。
Dadgar: Nomadで実現できたことを誇りに思っていますが。まだ始まったばかりです。Nomadは私たちが推進しているHashiCorpのエコシステムのひとつです。Nomadの次のリリースはConsulとの統合になるでしょう。これによってたくさんの新しい機能がもたらされます。NomadのジョブがConsulのサービスに登録できるようになります。サービス発見の機能も活用できます。Consulのヘルスチェックの仕組みもNomadのスコープを広げずに利用できます。
AtlasやOSSのスイートと統合するという計画もあり、とても興奮しています。組織が需要の変化とコスト削減のために自動的にスケールできるようにするのが私たちの第一の優先事項です。
NomadとOttoのもっと詳しい内容はそれぞれのウェブサイトで確認できます。HashiCorpのウェブサイトでも確認できます。HashiConfカンファレンスのより詳しい内容はHashiConf 2015のウェブサイトで確認できます。