“クラスタスケジューラ”: Cindy Sridharan氏が語るスケジューラの目的と、imgixがNomadを選択した理由

imgixのエンジニアであるCindy Sridharan氏が、KubernetesやHashiCorpのNomadなどのジョブススケジューラに関する総括的な記事を執筆した。記事の中で氏は、imqixの開発チームがかつて直面し、同社が技術スタックにスケジューラを導入する契機ともなった、アプリケーションのパッケージングやデプロイメントやライフサイクルといった課題について論じている。imgixは最終的にNomadを選択したが、その決定に関して、バランスの取れた分析と実装に関する概要(と残件となった課題)が記事全体で紹介されている。概要は次のとおりだ。

1. スケジューラの目的に関する現在のあり方は、元々はGoogleで着想され、開発されたものだ。
2. Google以外の問題を解決する上で、はたしてそれは、どの程度まで転用可能(あるいは不可能)なのだろうか。
3. “大規模”でなくてもスケジューラが有用なのはなぜか。
4. 既存のインフラストラクチャにスケジューラを導入する際の問題点。
5. スケジューラを使用した、ハイブリッドなアーティファクトデプロイメントの運用。
6. imgixがKubernetesではなく、Nomadを選択した理由。
7. 未解決な課題。
8. 新しいツールの導入による新たな問題。
9. 将来的な展望。

私たちが現在開発しているアプリケーションは、10年前に比べてはるかに複雑化している、とSridharan氏は言う。中核となるビジネスロジックが単純であっても、高信頼性や高可用性、顧客満足、急速なイノベーション、継続的デプロイメント、迅速なフィードバックループと定常的イテレーションといった将来的なニーズが、標準化された、信頼性の高いツーリングの必要性を急速に高めている。多くの企業がGoogleのような“ユニコーン組織”を目指しているが、これには限界がある。

“Google Infrastructure For Everyone Else (GIFEE)”は、実際に直面している問題の解決にそのテクノロジが適用可能であって、初めて意味を持つのです。

クラスタスケジューラが一般化したのは、GoogleのBorgに関するホワイトペーパ(PDF)がきっかけだった。同社が10年以上にわたって、“コンテナ”内のすべてをBorgでオーケストレーションしていることは有名な話だ。大企業以外でのコンテナ化はDockerの大成功によって実現したものであり、それがKubernetesの誕生にもつながっている。

スケジューラは、ほとんどのエンジニアリング企業にとって、最初は何か得体のしれないもの、不相応なものに思えるかも知れません。しかし事実は、ゲームチェンジャにもなり得るような、従来のソフトウェアライフサイクル手法を大きく進歩させるものなのです。スケジューラの提供するフレキシビリティと、その導入によってすぐに得られるメリットは、いくら強調しても足りません。

Sridharan氏は、imgixチームがスケジューラテクノロジを導入するきっかけになった、３つの課題について説明した。パッケージング - さまざまな言語で記述されたアプリケーションをパッケージするための、POSIX的な標準の必要性(Dockerコンテナはこの標準に近いが、いくつか制限がある)。デプロイメント - 同じように、静的にリンクされたバイナリであったり、より複雑なアーティファクトの集合体であったりするアプリケーションをデプロイする上で、言語に依存しない標準的アプローチが存在しない。ライフサイクル - 開発対象はすべて分散システムであるため、部分障害、アプリケーション機能のデグレーション、SLO(Service Level Object)やSLA(Service Level Agreement)などを考慮しなくてはならない。

imqixのスタック内にスケジューラを実装することの機会費用を念頭に置きつつ、記事全体では、最終的にNomadが選択された理由について論じられている。 現在のKubernetsとDockerの緊密な結合(および既存のimqixアプリケーションのパッケージング形式を変更する必要性)と、Kubernetesに内在するネットワーク的な問題とを比較した結果が、このテクノロジの採用を見送った決定要因としてあげられている。Nomadでは、静的リンクされた単一バイナリを含むさまざまなアーティファクトのデプロイメントが可能であると同時に、サービスディスカバリを目的としたConsulとの統合性も良好である(しかもimgixの技術スタックでは、その時点ですでにConsulが使用されていた)。

新たなツールを導入する場合、特に運用ツールにおいては、既存のインフラストラクチャとシームレスに統合可能なものを選択すること、すでに動作しているものに対して必要な変更が最小限であること、この２つが経験から求められます。

Normadをロールアウトしたことによる成果はすぐに現れた、とSridharan氏は言う - デプロイメントパッケージと既存のConsulサービスディスカバリ機構に必要な変更を最小限に留めることができた。ジョブファイル内のアプリケーションセマンティクスを開発者が指定できるようになった。“Opsの民主化”、すなわち、(使用する言語スタックの違いや、長時間実行アプリケーションとバッチジョブなど)多様なアプリケーションのジョブファイルに類似性があることで、デプロイメントを短時間で理解できるようになった。オペレーションが簡略化された - 例えば、Nomadは各ノードに単一バイナリとしてデプロイされる。現時点でNomadの課題としてあげられるのは、アクセスコントロールリスト(ACL)がないことだが、これはingressゲートウェイやHAProxyのようなリバースプロキシを使用することで克服できる。また、クオータや優先度、クラスタリソースの過剰な要求なども問題だ。

Cindy Sridharan氏の記事“Cluster Schedulers”全体はMediumで、記事に関する簡単な説明はTwitterで、それぞれを参照することができる。