マイクロサービスとモジュラリティ

InfoQで何年にもわたって議論してきたように、開発者には、マイクロサービスを選ぶべき理由と、選択を避けるべき理由が数多くある。Gene Hughson氏は先頃、Simon Brown氏の見解に対して、モジュラリティの改善がマイクロサービスを選択する理由にならないのではないか、という記事を書いた。

Hughson氏は言う。

モノリスを適切に構築する上で問題がある状況で、分散アーキテクチャを使用してモジュラリティを強要しようとしても、実際にはうまくいかないと思います。

実際に2014年の記事で、Brown氏とHughson氏は“大きな泥団子(Big Ball of Mud)”のアナロジでマイクロサービスを論じている。その時のBrown氏の意見は、

モノリシックなシステムを開発していて“大きな泥団子”になりそうなら，ソフトウェアのアーキテクチャに十分な注意が払われているかを検討すべきです。開発中のソフトウェアの中心となる抽象構造を本当に理解しているか？ インターフェースや責務は明確か？ 明確でないとすれば，マイクロサービスアーキテクチャへの移行が有効だと，どうして言えるでしょう？ 確かに，サービスを物理的に分割することで，ショートカットの利用を強制的に止めさせることはできるでしょう。しかし同じような分割は，モノリシック内でコンポーネントを分割することでも実現できるはずです。

Hughson氏はマイクロサービスによる開発を氷山に例えて、外見よりもはるかに多くのことが水面下で進んでいる、と述べている。

開発チームが設計ガイドラインを遵守できない、あるいはその意思がない場合には、複雑性を増すことが必要な解決策ではないでしょう。アプリケーションの分散化によって、さまざまな問題が偶然絡み合う可能性は低減できますが、まったく不可能にはなりません。

氏はこの最後の点について、Brown氏のツイートへのリンクで説明している。

設計ガイドラインを遵守できない、あるいはその意思のない開発チームに関する自身の以前のコメントを参照しながら、氏は次のように説明する。

誤ってモジュラリティを損なうことを防止する、という対策では、先に述べた２つ、すなわち遵守できないチームと遵守する意思のないチームのどちらにも対処できないと思うのです。皮肉なことではありますが、モジュラリティの必要性を理解していない人の中には、そのような問題があるにも関わらず、“ソリューション”としては非常にクリエイティブなケースもあります。遵守する意思のないチームでも同じです。

Hughson氏は、モジュラリティの手段としての分散化(マイクロサービスは本質的に分散化である)は、その目的には合わないと主張する。さらに氏は、同じ懸念がアプリケーションのアーキテクチャに限らず、アプリケーションのデータにも適用されると考えている。

規律あるモノリシックチームならば、モノリシックなデータアーキテクチャでもモジュラリティの維持が可能です。しかし、複数のチームがモノリシックなデータアーキテクチャを共有しようとすれば、深刻なレベルのガバナンスオーバヘッドを経験するか、あるいはモジュラリティを完全に失うことになるでしょう。

Christian Posta氏は昨年、マイクロサービスへの移行において、アプリケーションのデータ面の管理が最も難しい部分であったと述べた。その内容は当時のInfoQでも伝えている。

合理的な複雑性でエンタープライズドメインのマイクロサービスを構築するためには、そのドメイン内にあるさまざまな責任のバウンダリを見つける必要があります。見つけ出したバウンダリの中に、それぞれの責任を表現するドメインモデルを構築します。次にそのドメインモデルを基にして、各ドメインのデータモデルを作成します。DDDを使ってこのようなバウンダリを見つけ出して、それぞれの境界コンテキスト(bounded context)を作成すれば、そのコンテキストがマイクロサービスになるのです。

自身の記事に寄せられた、何らかの形のガバナンスが必要だと指摘するコメントに対して、Hughson氏は次のように同意している。

構造的(“モジュラリティを破ることができないようなコンポーネントを提供する”)であろうと、あるいは手続き的(“規律順守”のように)であろうと、受け身の方法では十分ではありません。競合する利益を調整し、設計が袋小路に迷い込まないように監視するためには、アプリケーションレベル(私見では、これはアプリケーションアーキテクトの仕事です)以上のガバナンスが絶対に必要なのです。誤解や経験不足、規定の不履行、さらには設計の不一致などによって、このようなことが起こり得ることを心得ておくことが重要です。何が起きているのかを監視する必要があります。同じように重要なのが、それがなぜなのか、ということです。

記事の結論として重要なのは、コンポーネントを独立的に管理、拡張、デプロイする必要のあるアプリケーションの構築において、マイクロサービスがその役割を果たす、という氏の意見を理解することだ。ただし、マイクロサービスへの道を選択する理由については、充分に理解しておく必要がある。