アスペクトとサービスに大きな違いはあるのか？

Arnon Rotem-Gal-Oz氏は3年前、当時比較的新しいトピックであったマイクロサービスとSOAとの関係について論じ、同時にナノサービスについての疑問を提起した。最近の記事で氏は、マイクロサービスは一部の人たちが信じているような万能薬ではなく、単なるマーケティング戦略なのではないか、という主張をしている。

私にとって、マイクロサービス全般がコンサルタントのマーケティング戦略ではないかと思う明らかな兆候のひとつは、マイクロサービス対モノリスという、中間に何も存在しないような考え方です。一方で、最近は、エンドポイントでサービスを提供し、独自のプロセスで動作するものは何でもマイクロサービスと呼ばれているようです。

氏の指摘には一理あるかも知れないが、マイクロサービスを必ずしもバイナリではなく、アプローチのあり方だとする捉え方も明らかにある。例えば、ミニサービスを主張するGartnerや他の人たちは、それを次のように定義している。

ミニサービスは真のSOA(マイクロサービスとは異なります)であり、複数のマイクロサービスを含む場合もあります。マイクロサービスよりもレベルがひとつ上なのです。マイクロサービスが内部のスケールを重視するのに対して、ミニサービスはサービスに対する外部的なアプローチであり、結果としてが外部機能を向上させます。

ミニサービスのようなコンセプトは当然ながら他にもある。いわゆるマイクロリス(microlith)である。しかし、Rotem-Gal-Oz氏が懸念するのは、マイクロサービスを採用せずに開発されたサービスは悪、ないしはモノリスである、という風潮だ。

[...] 独立的にデプロイされるコンポーネントがすべてマイクロサービスであり、マイクロサービスの特性をすべて備えなければならないとすれば、非常に複雑なことになります。これらの特性、分離性、自律性を得るためには、APIの結合、トランザクション的な結合、一時的な結合、内部構造的な結合など、多くの面での結合を回避するという、大変な労力を必要とします。その結果として、すべての原則に従わなくても、何でもマイクロサービスと呼ぶ状況に落ち着くことになります。

氏の記事に対するコメントのひとつが指摘しているように、また、過去に我々が何度かレポートしているように、これと同じことがRESTに対しても起きている。

マイクロサービスという用語は、RESTと同じように、その意味を失っています。http上でjsonを使用する(ほぼ)APIがすべてRESTと呼ばれるのと同じように、すべてのサービスがマイクロサービスと呼ばれているのです。

Rotem-Gal-Oz氏は、サービスに対するバイナリアプローチは、(それが優れたサービスであるか、あまりよくないサービスであるかに関わらず)生産性が低いと考えている。

サービスとはまさにビジネス機能、エンドポイントの提供するAPI(ないしコントラクト)を中心に構築され、自律性およびその他の外部的なポリシによって管理されるものだ、という点を認識する必要があります。しかしながら、それとは別に、サービスをより小さく独立性の高いコンポーネントに分割しようというモチベーションが存在します。これはデプロイメントや開発サイクルの独立性といった原則や利点のほとんどを具現化する反面、データ構造やストレージといったいくつかの依存関係は依然として共有されています。私はこれを半独立的(semi-independent)コンポーネントアスペクトと呼んでいます。

さらに氏は、アスペクト(aspect)とサービスを区別することが、異なるサービスの異なるアスペクトによるサービスバウンダリの維持が可能であることを確実にする、とも述べている。サービスをアスペクトに分割することによって、サービスのサイズや複雑性が増加しても、すなわち、現在のマイクロサービスの定義から潜在的に遠ざかることになった場合でも、柔軟性とシンプルさを維持することが可能になる。Rotem-Gal-Oz氏は自身が携わったシステムの中から、ひとつのアスペクトしか持たない、小さな(氏は’小さい’という定義を示さなかったが、コードの行数に基づくものと思われる)サービスのある実例をいくつか紹介した。その一方で、多くのアスペクトを持った、より複雑なサービスも存在する。

ひとつのアスペクトがイベントデータをサービスに取り込み、変換とデータマッチング(新しいデータと既存データとの関連グラフの構築)を行う処理を扱い、別のアスペクトがデータに対するユーザ駆動の操作を実行し、さらに別のアスペクトがデータにアクセスするためのクエリAPIを(グラフQLで)提供します。アスペクトにはそれぞれライフサイクルがあり、独立的にデプロイされます。アスペクトは複数の言語(ScalaとJavaScript)を使用しますが、一方ではデータを共有し、他のサービスとの間の壁を維持する、という違いがあります。

まとめてデプロイされ、一貫したユニットとして運用されることを除けば、これらのアスペクトはマイクロサービスと酷似している。率直に言うと、マイクロサービスは独立して存在している訳ではないのだ。全体的なアーキテクチャとしては、Martin Fowler氏らがかつて議論したStrangerパターンに近いと思われる。Rotem-Gal-Oz氏は次のように結論する。

結合レベルを管理し、サービス境界を維持することが重要です。アスペクトが何であるか、サービスが何であるかを理解することが、全体的なアーキテクチャのコントロールを可能にし、複雑に絡み合った相互依存関係を回避すると同時に、より小さなコンポーネントを使用することによる柔軟性と処理時間の改善を可能にします。

このような“アスペクト”が事実上マイクロサービスであるかどうかは別として、他に少なくとも一人(Udi Dahan氏)が同じような結論に達しているようだ。ただし氏は、このソフトウェアコンポーネントに違う呼び方をしている。

独自のエンドポイントにデプロイされる場合も、他の同類のコンポーネントと共にホストされる場合もある、このようなサービスのソフトウェアパッケージを説明するために、私は自律的コンポーネント(AC:Autonomous Component)という用語を使っています。複合的なUIを構築する場合、この共同ホスティングモデルがもっとも有効です。

氏の定義する自律的とは、氏が何年も前にSOAに関して論じたもので、他のACに依存しないという意味だ。幸いにも氏はその数年後、ACとマイクロサービスについて、次のように詳しく説明してくれている。

マイクロサービスとACはほぼ同じです。なぜ“ほぼ”なのでしょう？ACはデプロイメントの物理的単位である必要はありません。同じ物理プロセス内に複数のACがデプロイされることも珍しくないのです。その最も一般的な構成のひとつが、コンポジットUIとして構築されたWebフロントエンドです。ひとつのWebサーバプロセス内に、サービスのコンポーネントが複数あることが分かります。

アスペクト/自律的コンポーネントとマイクロサービスを区別することは、モノリスから完全なマイクロサービスアーキテクチャへの中間ステップとして有効ではある。しかしながら、いまだ標準化されていないマイクロサービスの定義のため、これらのコンポーネントがすべてマイクロサービスと呼ばれるようになるのではないか、という懸念が残る。あるいは、明確にそう呼んではいなくても、同じことをすでに行なっている人がいるかも知れない。