マイクロサービスの未来 - 機能サービス設計と監視可能性

2月16日と17日の両日にBerlinで開催されるmicroXcngカンファレンスに備えて、InfoQはUwe Friedrichsen、Adrian Cole両氏と会い、マイクロサービスアーキテクチャスタイルが実現する機能サービス設計、分散システムで明らかになった新たな課題、マイクロサービスアーキテクチャスタイルの将来像などを議論した。

codecentricでCTOを務めるFriedrichsen氏、PivotalのソフトウェアエンジニアであるCole氏との会話での重要なポイントは次のようなものだ。

• マイクロサービスの考え方で重要なのは、アプリケーション環境の他の部分からの独立性と速やかな発展性をサポートする特性である。多くの実装者はこの点を無視している。
• 監視システムとログシステムには、現在のソフトウェアアーキテクチャを反映する形での進化が求められる。このことは技術および認知の両面において影響力を持つ。
• 機能分割の方法について、古典的なソフトウェア技術教育で学んだこと(“同じことを繰り返すな！”のような)の多くは、マイクロサービスのような分散システムでは通用しない。
• “マイクロサービス”という言葉自体は将来的になくなるかも知れないが、機能分割の新たなアーキテクチャスタイルとして定着するだろう。
• コモディティになるものを標準化することには高い価値がある。断片化、公平性ないし相互運用性の欠如といったものは、エンドユーザに価値の消失を引き起こすからだ。

インタビューの全内容を以下に紹介する。

InfoQ: Uweさん、マイクロサービスを導入している一連の企業にとって今、最も困難な課題となっているものは何でしょうか？

Friedrichsen: マイクロサービスをやっていること、それ自体です。

“マイクロサービス”はメインストリームの用語として普及しています。Spring Bootなどのユーザはみな、自分たちがマイクロサービスを実践していると言います。誤解しないでください – Spring Bootが悪いと言っているのではありません。HTTPインターフェースを公開するアプリケーションを書くことが、必ずしもマイクロサービスを開発していることにはならない、と言いたいのです。

マイクロサービスの根幹的な考え方は、アプリケーション環境の他の部分からの独立性、速やかな発展性をサポートするその特性にあります。残念ですが、私の知る限りでは、マイクロサービスの定義においてこのような特性に重きを置いている人があまりにも少ないのです。

マイクロサービスは迅速な行動を支援するアーキテクチャスタイルです。 企業が変化の速い市場にあって、ITに急速なビジネス変化のサポートが求められているのならば、ITは速やかに行動しなくてはなりません。しかしながら、それを行なった後であっても、単なるアーキテクチャスタイル以外に、ITとして速やかな行動が求められるものは多数あります。

マイクロサービスのように喧伝されたトレンドが問題なのは、自分たちの状況に対して適切なソリューションではないにも関わらず、それを採用しようとする人たちが少なくないことです。ITの迅速さがそれほど強く求められていないのであれば、おそらくマイクロサービスは必要ないでしょう。その状況でもSpring Bootを使うことは可能ですが(面白いものであることは事実です)、それは“マイクロサービス”と呼べるものではありません。

InfoQ: Adrianさん、迅速に行動する(何かを壊すことなく)と言えば、分散システムの運用に関する洞察を提供するためのシステム監視のアプローチは、従来のものからどのように進展しなくてはならないのでしょう？

Cole: 監視システムとログシステムは、現在のソフトウェアアーキテクチャとその実現形式を反映する形で進展しなくてはなりません。例として、マイクロサービスから機能単位へとスコープを縮小する、というものがあります。これは技術と認知の両面に影響します。短命なマネージド機能をキャプチャできなければ、メトリックのウィンドウニングやデリバリが問題になるかも知れません。

認知に関する負担にも対処しなくてはなりません(し、実際に対処しています)。私たちの場合は、エラーログを出力するオペレーションに分散トランザクションのコンテキストを追加した上で、それらを説明する詳細なコンテキストをさらに重ねています。システムと認知の負担とのバランスをとる必要があるのですから、大変な仕事です。

InfoQ: 以前にUweさんの講演で、Spring Boot(およびgo-micro、Senca.js)のような“マイクロサービス”フレームワークを使用することによって、現代的な開発スタックに対する監視可能性の導入が極めて容易になる、という話を聞いたことがあります。

Cole: そうですね、mixoxchgではZipkinを使った分散トレースについて講演します。JavaやSpring Bootについても少し取り上げる予定です。Marcin Grzejszczak氏を中心として熱心に開発が続けられている、Spring Bootの分散トレース用プラグインである“sleuth”を導入すれば、実現はかなり簡単です。Start.spring.ioを使用すれば、文字通りZipkinのような単語をクリックするだけでうまく行くようになります。ブログ記事の人気から判断すると、十分に簡単だと受け取られているようです。

go言語については、マイクロやトレースに関してはあまり耳にしませんが、Peter Bourgon氏のgo-kitバンドルが、OpenTracingという名前のライブラリインターフェースプロジェクト経由でサポートしています。ドキュメントから判断する限り、appdashとZipkinはそのままで動作するようです。後者については、Zipkinに関係もしているgo言語チャンピオンのBas van Beek氏が保証しています。

InfoQ: Uweさん、次に開発パターンについて伺いたいのですが、開発者や設計者が機能的なサービス設計を検討する上で、何か推奨できる方法はありますか？

Friedrichsen: そのような方法があれば、それを売ってたくさんお金を儲けることができるのですが ... ただし、次のようなことは言えるでしょう。開発者やアーキテクトに対して、必要とされる範囲の機能サービス設計を困難にしている要因には、３つのものがあると思います。

1. それ自体が非常に難しいものであること。ソフトウェアアーキテクチャと設計に40年以上のキャリアを積んでいても、十分には理解できません。

そのために、たくさんの人たちがDDD(ドメイン駆動設計)を提唱しています。確かにDDDは、出発点としては優れているのですが、それらのパターンで現在のビジネス上の課題に対処した適切な設計ができるかと言えば、それはまったく別の問題です – プロダクトマネージャやプロダクトオーナが目の前にいて、“生産性の向上”を絶えず求められるような状況ではなおさらです。

その上に、機能分解(functional decomposition)やDRY(Don’t Repeat Yourself)、あるいは再利用可能な機能の開発といった、私たちが機能分割に関してソフトウェア教育から学んだことはすべて、マイクロサービスのような分散システムには通用しないのです。このような設計のベストプラクティスを使用したなら、どうしようもない設計が出来上がって、運用時で頭を悩ませることになるでしょう。つまり私たちは、分散システムを学び直さくてはならないのです。私が個人的に見る限りでは、適切な方法についてまだ多くのことを学ぶ必要があります。

2. 魅力的なスライドショーがITの真の問題を覆い隠していること。

新しいフレームワーク、プログラミング言語、あれとこれをどうやって行なうのか、といった果てしない議論、あれとこれをしなかったどうなるのか、あなたは間違っている、などと説く大勢の独断的な人たち。まばゆいほど新しいものや、さまざま意見が、私たちの周りには満ち溢れています。カンファレンスに行ったり、IT雑誌を読んだり、あるいはTwitterのタイムラインを見れば、私が言わんとすることが分かって頂けるでしょう。このすべてが、優れた設計方法を学ぶよりもこちらの方がずっと素晴らしいですよ、と言っているのです。

3. 私たちが5年ごとに集団的知識を失うこと。

私の観察によれば、私たちは約5年ごとに、大学(あるいは他の所)から来る新世代の開発者に出会っています。見方を変えれば、これは私たちが5年ごとに集団的知識を失っているという意味でもあるのです。彼ら新しい世代は、何年か前にあなたの考え方を変えた講演や記事を(今はまだ)知りません。彼らはそれぞれ、自分たちの仕事を最初から学び直さなくてはならないのです。

機能設計のような“時代を超越する”トピックで事態を難しくしているのは、特にITにおいて、“新しい”ものに“価値”があり、“古い”ものは“役に立たない”という考え方があるという事実です。“私たちは急速に変化するビジネスの中にいるのですよ？”“5年、10年、あるいは20年以上も経った知識に、どんな価値があるというのですか？”古い知識がすべて無価値ではない、と最終的に一部の人たちが理解したとしても、同じ話を何度も語って、何度も忘れているのであれば、毎年入社する新人開発者の大半はその話を耳にしないことになります。

InfoQ: IT産業における人々の変化の速さに関する話がありましたが、マイクロサービスアーキテクチャ方針そのものの将来像はどのようなものなのでしょう？

Friedrichsen: 率直に言ってしまうと、分かりません。“マイクロサービス”という言葉自体は、多くのベンダやコンサルタント、新しいクールなもので着飾りたいだけの人たちによって取り上げられた後に、最終的には一時の流行語として消えていくでしょう。一方で、そのアーキテクチャスタイル自体は定着しています。事実、私たちが“マイクロサービス”と呼び始めた時にも、そのスタイルは新しいものではありませんでした。ずっと前から存在していたのです。それがITの進歩をベースにアップデートされて、“マイクロサービス”と呼ばれるようになったに過ぎません。次にアップデートされれば、きっとまた違う名前で呼ばれるようになるのでしょう。

あるいは近い将来、マイクロサービスのスタイルがさらに分化される可能性もあります。皆が皆、“純粋な”マイクロサービススタイルの特徴をすべて必要としている訳ではありませんし、自分たちの直面する問題を解決するために、マイクロサービススタイルの特徴の一部分だけが必要な人もたくさんいるはずです。

しかし、正直に言うならば、どうなるか分かりませんね。

InfoQ: 最後になりますがAdrianさん、マイクロサービススタイルの将来を考える時、この世界でのオープン標準の価値をどう思いますか、また、それを管理する組織ないし財団の創設についてはどうでしょう？

Cole: いちばん難しい質問ですね！というのは、オープンや標準ということばが一般的に、とても漠然と使われているからです。例えば、オープンという接頭辞を名称に持つ小さなワーキンググループはたくさんありますが、その性格や定義、オープン性や実際に提供するアウトプットは全然違います。オープンということばの付かない標準もたくさんあって、IETFのような公式グループに匹敵するようなレベルのアウトプットを提供しています。例えば、リアクティブストリームグループの成果には非常に感銘を受けました。彼らのWebサイトを見ると、オープンということばへの言及はただひとつ、“問題をオープンにする”ということだけなのです！

話を戻すと、コモディティになるものを標準化することには高い価値があります。フラグメンテーションや公平性ないし相互運用性の欠如は、エンドユーザの価値の損失を引き起こすからです。財団や組織などは、標準を開発するための設備のひとつです。標準はその定義からも、長期的かつ多様な取り組みを真摯に行なう必要があります。標準が無計画に始まってはいけないと言うのではありません。必要になった時点で無計画な標準からフォーマルなものに移行できることも否定しませんし、無計画な標準が失敗すると決まっている訳でもありませんから。個人的な意見ではありますが ...

InfoQは、2月16日と17日にベルリンで開催されるmicroXchgカンファレンスからのニュースを報告する予定だ。カンファレンスの詳しいスケジュールは、イベントのWebサイトで確認することができる。