Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは

サービスメッシュを実装するオープンソースソフトウェアIstioが最新バージョンを公開した。このリリースではこれまでのコントロールプレーンの発想を一新して、複数のプロセスが協調する形から、「istiod」というモノリシックなプロセスが制御を行う方式に変更されたことが明らかになった。

バージョンアップの概要はIstioのブログ記事にあるが、より詳細にマイクロサービスからモノリシックへの変更に関しては、Christian Posta氏によるブログ記事が参考になる。

公式サイト：Istio in 2020 - Following the Trade Winds

これまでのIstioのアーキテクチャー

最新のIstioのアーキテクチャー。コントロールプレーンがシンプルになった

Solo.incのField CTOであるPosta氏はRed Hatのアーキテクトというキャリアの持ち主で、2019年11月のKubeConではマイクロサービスを指向するプログラミング言語であるBallerinaのセッションを行ったこともある。このようにPosta氏は、マイクロサービスについて早い段階からの知識と経験を持ったエンジニアと言って良いだろう。

参考：KubeCon 2日目の注目はAirbnbのユースケースとBallerina

一般的にはマイクロサービスを実装することで開発に必要な時間が短縮されること、個別にアップデートすることが可能になり、よりクラウドネイティブになることなどが利点として挙げられる。しかしPosta氏による以下のブログ記事では、それらの利点を得るために多くのトレードオフが必要であることが紹介されている。

Posta氏のブログ：Istio as an Example of When Not to Do Microservices

最大のトレードオフは複雑さが増すことだ。一つのアプリケーションが果たす機能を複数のプロセスとして実装することで、プロセス間通信のエラー処理やテストなど、開発段階での工数も膨らむことになる。また実装時にはモニタリングやトレーシングなど、これまでのモノリシックなアプリケーションでは実装していなかったツールを導入する必要も出てくるだろう。開発・運用の双方で大きく負担が増えるのは明らかだ。

またIstioの場合は、セキュリティを個別に設定する必要がないインストレーションも一緒に行われるのが一般的な導入方法であることなどから、マイクロサービスとしてコントロールプレーンを実装する必要性が低いことがわかったという。これがIstioがistiodを導入した理由であるということだ。

またPosta氏は別の記事でも、マイクロサービスを実装するべきでないという理由をいくつか挙げている。特に組織がツリー状の階層構造を取っているのであれば、すべての細かなプロセスがメッシュ状につながるマイクロサービスは向いていないという。これは「システムの設計を行う組織は、その組織がコミュニケーションする構造をコピーしたデザインのシステムを作り上げてしまう」というコンウェイの法則を別の表現で表したものと言えるだろう。

そしてなによりも、マイクロサービスを開発したいと思ったとしても、その組織構造や文化、それに慣れた人がマイクロサービスに向かないものである限り、マイクロサービスを勧めないという辺りは日本人には頭が痛い話ではないだろうか。AmazonやNetflixのように開発したコードを本番に毎日プッシュするような環境にいない限り、マイクロサービスは諦めたほうが良いというのがPosta氏の結論だろう。

Posta氏のブログ：You're not going to do Microservices

また組織がそれほど大きくないのであれば、マイクロサービスに行く必要がないというのも同じ発想だろう。これはクラウドネイティブなソフトウェアを多く取り上げるメディアのThe New StackのPodcastでGoogleのKelsey Hightower氏とLightStepのCEOであるBen Sigelman氏が語り合っていたことだ。

Sigelman氏もかつてGoogleでトレーシングのソフトウェアであるDapperを開発していたエンジニアで、今はOpenTelemetryの開発をリードするエンジニアだ。クラウドネイティブなシステムにおいては、Hightower氏同様に経験を持っていると言える。

二人の対話は以下のサイトから聴くことができる。

Kelsey Hightower and Ben Sigelman Debate Microservices vs. Monoliths

マイクロサービスのようにMoving Parts（実行されるソフトウェア）が多い場合は、モノリシックなシステムに比べて監視やトレーシング、状態を評価するためのメトリクスを取得するシステムを同時に導入しないと状態監視ができない。またカオスエンジニアリングに代表される「常に正しく稼働するのではなく、常に何かが壊れる前提でシステムを設計する」という姿勢も必要だろう。そこまで含めるとこれまでの開発運用体制では対応できず、結果的にマイクロサービスによって人的資源が増加することも想定される。

マイクロサービス化の道は決して平坦ではないが、しかしその人的資源を効率的にマイクロサービスに取り入れた例が日本にもある。Istioの例から始まった「組織がそれに対応していないのならマイクロサービスを無理に進める必要はない」というのは金言だと言えるが、それを違うアプローチでマイクロサービスを上手く取り入れた例が、メルペイのマイクロサービス導入事例だ。これは2019年の秋に行われたCloud Native Days Tokyo 2019のセッションで、メルペイが社内のシステムにマイクロサービスを取り入れたことを紹介するものだ。

参考：CloudNative Days Tokyo 2019：メルペイのマイクロサービス化の目的とは？

この事例のポイントはモノリシックなアプリケーションでは開発からテスト、実装までに必要な時間が大きく、開発のリソースを効率よく使うための阻害要因になっていたという点だ。具体的にはマイクロサービスとしてコードを小さくすることで少数の開発エンジニアでチーム構成を行い、開発に必要な時間を短縮することができたという事例だ。結果としてエンジニアが別のプロジェクトに素早く取り掛かることができるようになり、生産性が上がったという。

ここでのポイントは、プロセスを分割することでその機能要件にあった言語やツールを選ぶことができるというマイクロサービスの利点を消して、すべてのエンジニアが同じツール、言語を使うという選択を行っていることだろう。本来ならプロセスの機能要件に応じて最適なツールや言語を選択するべきだが、どのエンジニアでも即座に開発に取り掛かれるように言語やツールを限定したことで、生産効率が上がったというのはマイクロサービス化を検討する企業にとっては重要な知見だろう。

最後にもう一度、最新のIstioの話題に戻ると、強化されたポイントとしてパブリッククラウドとの連携の強化や仮想マシンとのインテグレーションなどが挙げられている。

Istio 1.5のその他の強化ポイント

他にもWebAssemblyのランタイムとIstioが使うProxyであるEnvoyの連携による他言語のモジュールの組み込みなど、興味深い強化も行われている。

WebAssemblyとEnvoyによるエクステンションの実装

IstioはIBMやRed Hat、Google、VMwareなどからの強いサポートによって今後もサービスメッシュの領域では拡がっていくだろうが、マイクロサービスからモノリシックという大きなアーキテクチャーの変更をやり遂げたことはコミュニティが健全な証拠だろう。外部連携にWebAssemblyを使うというのも大きなアーキテクチャー上の変更だし、大胆な判断だったように思える。この変化をコミュニティとユーザーが受け入れるには時間が必要となるだろうが、今後もIstioの将来に注目していきたい。