マイクロサービスアーキテクチャにおける分散スケジューラ

マイクロサービスのスケーラビリティに関するエキスパートであるDigitalOceanのMartin Campbell氏が、MicroXchg Berlin 2017で、分散スケジューラを備えたマイクロサービスベースアーキテクチャの運用について講演した。話題の中心は、氏がその過程で遭遇した問題と、KubernetesやNomad、Mesosといった製品間のトレードオフに関するものだ。

講演の主な内容は次のようなものだ。

• 分散スケジューラを使用することにより、あたかも単一の物理マシンであるかのようにクラスタを捉えることが可能になる。
• これらの製品はDevOpsをより簡単にすると同時に、マイクロサービスベースのアーキテクチャには付きものである、運用上の複雑性を軽減する。
• いずれもステートフルなサービスの実行にはあまり向いていないので、そのようなタイプのサービスは実行しないことがベストである。
• ネットワーク分割(network partition)が発生した場合、フォールトトレラントな分散スケジューラは、ホストノードがマスタと通信できなくなったとしても、すべてのプロセスを実行したままにしておく必要がある。

まず最初にCampbell氏は、オペレーティングシステムのカーネルは集中型のスケジューラであると説明した。単一のマシン上で複数のプロセスを管理するもの、という意味だ。分散スケジューラはコンセプト的には同じだが、単一マシンではなく、マシンのクラスタに渡って動作する点が違う。“データセンタ全体を対象として、あたかもひとつの物理的マシンのように扱うのです。”

分散スケジューラは、マイクロサービスアーキテクチャにおいて特にメリットがある。この種のシステムには、複数のサービスが絶えず拡張され展開されることによって生じる余分な運用オーバーヘッドがあるから、というのがCampbell氏の考えだ。

さまざまな分散スケジューラの比較として、Campbell氏はまず、Mesosでの自身の経験について話した。Mesosでは、プロセスが実行させる物理マシンが何であるかを気にする必要はない。CPUやRAMなどのリソース割り当てに基づいたデプロイメントをMesosが処理してくれる。また、データセンタがひとつの物理マシンであるかのように、容易に視覚化できるダッシュボードも用意されている。

Campbells氏がMesosで体験した大きな問題は、ネットワーク分割の処理方法にある。Mesosマスタと通信できなくなったプロセスが強制終了されてしまうのだ。これは好ましくない設計選択だ、とCambell氏は考えている。現実問題として、分散システムのネットワーク分割は珍しいことではないので、このような状況ではプロセスを引き続き実行させておくことが望ましい。この動作がデータ損失の原因となる例として、氏はKafkaを取り上げた。Kafkaはレジリエントに設計された分散メッセージバスだが、ネットワーク分割がほぼすべての単一ノードの、延いてはデータの損失に繋がる可能性がある。

最終的にCampbell氏はMesosを諦め、その代替として最初にNomadを選択した。Nomadのメリットは独自のゴシッププロトコル(gossip protocol)を使用していることだ。これにより、同一データセンタ内だけでなく、データセンタ間でのサーバ通信が可能になる。ネットワーク分割が発生しても、同じパーティション内のサービスは引き続き機能し、通信することができる。問題が解決すれば、最終的に一貫性を取り戻すことが可能だ。しかしながら、Nomadを実運用に使用しているアプリケーションを知らなかったので、移行のリスクを負いたくはない、と氏は考えた。

最後に選んだツールがKubernetesだった。Mesosに似てはいるが、いくつかのメリットがあった。まず挙げられるのが、ネットワーク分割の処理方法が異なり、発生時にインスタンスを強制終了しないという点だ。クラスタの状況を容易に確認可能なダッシュボードも備えており、アプリケーションを扱う場合の抽象化のレベルもそれほど高くない。

Campbell氏の取り上げたアプリケーションアーキテクチャに関する詳細や、さまざまなスケジューラに関するさらなる情報を含んだ講演全体は、オンラインで視聴することが可能だ。