microXchg BerlinでのStefan Tilkov氏の講演より - マイクロサービスのアンチパターンとパターン

マイクロサービスは、モジュールを独立した展開および運用のユニットとして設計するパターンで、実装上の自由度の大きさが特徴である。ネットワーク通信を必須とすることによってモジュール間にバウンダリを形成し、カプセル化を実現して、モジュール間の対話方法に反することを困難にする — Stefan Tilkov氏は、ベルリンで開催されたmicroXchg 2018での講演でこう説明した上で、氏の観点によるマイクロサービスプロジェクトのパターンとアンチパターンについて論議し、他の人々がアンチパターンとする中で氏がパターンであると考えるもの、あるいはその逆のものを指摘した。

NNOQ創設者のひとりであるTilkov氏にとって、マイクロサービスを使用する意義とは分離であり、自律性と柔軟性である。その一方で、自身の定義に従ってモジュール化されたソフトウェアを構築するならば、マイクロサービスである必然性はまったくない、とも指摘する。しかし、我々にそれが実現できないため、やはりマイクロサービスは必要なのだ。

進化的アーキテクチャ (Evolutionary Architecture)

システムを構築する場合、最初から最適なアーキテクチャを開発する代わりに、適応性を備えた進化的アーキテクチャを構築しておき、ある時点において適切なものになるように変更する、という方法もある。このようなアーキテクチャは次のものを備えている、とTilkov氏は言う。

• 大規模なドメインを“変革の島(islands of change)”と呼ぶものに分解する
• 再利用ではなく、置き換えを念頭に置いて設計する
• 共有依存性を最小限とし、再利用ではなく、自律性と冗長性に重点を置く

この方法によるメリットのひとつは、A/Bテストの利用などの実験が可能になることだ。

分散型モノリス (Distributed Monolith)

Tilkov氏の最初のアンチパターンは分散型モノリス、あるいは腐ったマイクロサービス(microservices gone bad)である。氏の定義は次のとおりだ。

ネットワークインターフェース上の通信を介して密に結合されたモジュールで構成される、任意の規模のシステム

Tilkov氏によると、これはビジネスドメインへの視点を欠いた、多くがハイプないしカンファレンスを動機とするアーキテクチャである。このパターンを使った結果は、一般的には次のようなものになる。

• 変更の波及的拡大
• 複雑な環境
• 理解や維持が困難

最悪の場合には、誰も管理できないようなテクノロジとフレームワークの混合と化す可能性もある。

デカップリングイリュージョン

Tilkov氏の経験では、多くの開発チームは、柔軟で変化に迅速に対応できるという理由からマイクロサービスを導入している。デカップリングイリュージョンは、システムをモジュールに分割したものの、ドメイン知識の不足から根本的な問題 — ステークホルダやビジネス上の要件の相互分離が実現されていないアンチパターンである。その結果、ステークホルダの2つ以上の要件からモジュールが作成され、他モジュールへの依存性が生じてしまう。このようなモジュールは、修正や展開を同時に行わなければならない。

マイクロプラットフォーム

前述のアンチパターンと直交するアンチパターンがマイクロプラットフォームである。これは、すべての内部サービスのアスペクトをフレームワークで統一し、全チームにその使用を強制するものだ。問題となるのは、個々のサービスと、すべてのサービスに関心を持つひとりのステークホルダとの技術的な依存関係である。標準化の理由は、少なくとも当初は合理的に思えるかも知れない。しかしそれは同時に、新機能やアップデートをコーディネートする必要を生じさせることにもなる。この問題を軽減するためにTilkov氏は、フレームワークの使用を任意にすることを推奨する。

エンティティサービス

注文サービスのようなエンティティサービスは、リテールビジネスにおいては妥当かつ有用なサービスに思えるかも知れない。このパターンで問題なのは、そのサービスを利用するすべてのサービスが自身のニーズを強要することから、エンティティサービスが最終的に、それを利用する全クライアントからの関心をすべて混ぜ合わせたものになってしまうことだ。このようなエンティティサービスは必要でない場合が多い、とTilkov氏は主張する。それぞれのサービスが、それぞれの見解の下で自ら注文の責任を持てばよいことなのだ。このようなサービスが作成される唯一の理由は、“注文”という名称が存在することによって、注文の共通モデルを作り上げようとするエンタープライズデータモデル(EDM)の考え方が採用されたためだ、と氏は指摘する。

DDDDとSCS

Tilkov氏はこれまで、さまざまな部分 — コンテキスト境界(bounded context)で構成された複雑なビジネスアプリケーションを抱えたクライアントに、何度となく出会っている。これらのコンテキストをマイクロサービスと組み合わせると、非同期通信を基本として、ビジネスイベントを使用し、データを冗長保存する分散ドメイン駆動設計(DDDD)パターンに行き着く。このようなサービスは疎結合で自律的だが、それぞれのサービスのサイズがコンテキスト境界の大きさになることが多い。このアプローチの動機は独立的な進化を可能にすることにある、とTilkov氏は考えている。

自己完結型システム(SCS)はDDDパターンに似ているが、各サービスが独自のフロントエンドを持ち、サービスの簡単な結合がフロントエンドで行われる場合の多い点が異なる。これによって、必要なインフラストラクチャを最小限に抑えることが可能になる。開発チームを切り離すためには最適なモデルだ、というのが氏の意見だ。

モノリス

Tilkov氏が最後に挙げたパターンはモノリスである。独立した小規模なチームなど、多くの場合においては現在でも理想的だと氏は考えている。開発の簡単な標準的アプリケーションであり、リファクタも容易で、人為的に導入された分散機構も存在しないからだ。

結合性が高く、緊密に統合された、展開アプリケーションの単一ユニット

まとめ

Tilkov氏のプレゼンテーションでは、サービスのサイズに注目していた。2,000以上のものが連なって構成されるようなアーキテクチャは理解が難しいと思われる。そのため氏は、その上にグループあるいはクラスタリングによる構造をもう少し加えることを提唱している。最後に氏は、正しいモデルというものはない、ということを強調した — すべては状況次第なのだ。選択されたソリューションは、常にドメインとビジネス上望ましいメリットによって進められるべきだ。さらに氏は、可能であるならば、要求に従って成長の可能な進化的アーキテクチャに取り組むべきだ、とも指摘している。

カンファレンスの講演は記録され、一部はすでに公開されており、その他も順次公開される予定だ。