システムをマイクロサービスに分解するには

２年前、Vladik Khononov氏とそのチームはマイクロサービスの導入を決定したものの、数ヶ月後には大きな混乱に陥った。モジュラリティなどの基本的な部分やその実現方法に十分な注意を払うことなく、新しいクールなテクノロジに飛びついたからだ — 先頃ロンドンのSkills Matterで開催されたDDD eXchange 2018カンファレンスで、氏はそう説明した。サーバレスフレームワークやプラットフォーム、メッセージメカニズムには投資したが、システムをマイクロサービスに分割する方法についての考慮 — バウンダリを見つけ出して、さまざまな機能がどのバウンダリに置かれるべきかを検討する過程が欠けていた。

InternovusのCTOであるKhononov氏とチームが最初に持っていたのは、サービスを小さくすればマイクロサービスになる、という考え方だった。結果は直ちに分散モノリスの構築になり、その後数年間、その小さなサービスの除去とシステムを分解するさまざまな戦略の評価に明け暮れることになったのだ。

コンテキスト境界

ユビキタス言語はドメイン駆動設計(DDD)における重要なプラクティスであり、これを実践するには、そのドメインの言語で専門家と話すことだ、とKhononov氏は記している。彼らは同じビジネスコンセプトに対して異なるメンタルモデルを持っていたり、異なるコンセプトを同じ言葉で言い表しているかも知れない。それはすなわち、これらのコンセプトが異なるバウンダリ境界に属していることを示している。こうして見つけ出した境界を使って、Khononov氏のチームは、それぞれの領域がサービスとなるように、サービスの定義を最初から実施した。これらのサービスは極めて広範なビジネス分野を表現しているが、コンテキスト境界が複数のビジネスドメインをカバーする場合もある、と氏は指摘する。

ビジネスサブドメイン

次のステップでは、定義したサブドメインを境界として、各ビジネスサブドメインに対してひとつのサービスを作成した。サブドメインとサービスを1対1で関係付けることはDDDコミュニティではごく一般的なアプローチだが、Khononov氏らはこれに留まらず、より小さなサービスを目指して努力を続けた。

ビジネスエンティティ

サブドメインをさらに深く見ることによって、ビジネスエンティティとプロセスが明らかになったので、氏らはこれを独自のサービスとして抽出した。この最終的なアプローチは最初こそ悲惨な失敗に終わったが、その後のプロジェクトでは成功を収めることができた、とKhononov氏は述べている。

これら3つの戦略を見てKhononov氏は、コンテント境界を用いた作業はモノリスとして有効な最大の境界を見つけるのには適している、と述べている。作業モデルとしては実用的だが、氏の考えるマイクロサービスの考え方とはまったく異質のものだ。ビジネスサブドメインとエンティティのいずれを選択する場合でも、最適な分解レベルは、構築中のシステムとそのユースケースによってまちまちだ、と氏は言う。マイクロサービスはサービスの内側の問題ではない、むしろサービス間の相互作用と結合性が問題なのだ、と氏は強調する。

マイクロサービスに分解可能なシステムのしきい値は、マイクロサービスを含むシステムのユースケースによって定義されます。

システム設計を簡単に評価する方法はいまだ見つかっていないが、システムをマイクロサービスに分解するプロセスの合理化を支援するために十分な設計のヒューリスティックの蓄積は完了した、とKhononov氏は考えている。氏が有用であると認識したのは、次のようなことだ。

• 常にコンテキスト境界のレベルまで分解すること。正当な理由がない限り、それ以上分解してはならない。分散システムには分散システム独特の問題があるのだ。
• コアサブドメインは、企業の利益の源泉である。ドメインに関する十分な知識が得られて、適当なサブドメインが確認できるまで、分解してはならない。
• 汎用的なサブドメインを購入ないし採用すること。それらはすでに解決された問題であり、独自に実装してもメリットは期待できない。
• コアドメインのサポートにはサブドメインのサポートが必要だが、それ以上のメリットがあるわけではない。一般的にそれらは十分安定していてシンプルなので、初期段階ではもちろん、場合によってはエンティティサービスでも、分館することに意義はない。
• 同じサービス内に留まる必要のある機能やメソッドを見つけるためには、一貫性の要件を用いるのがよい。
• イベントは明示的かつ自己記述的であること。サービス内の実装詳細としてプライベートイベントを、サービスの公開インターフェースの一部としてパブリックイベントの制約されたセットを使用することを検討するべきだ。
• 同じレートで変化するサービスを見つけよう — 統合することで、複雑性を低減できるかも知れない。
• 各サービスのインターフェースを評価すること。幅が広過ぎる場合、そのサービスはもっと小さく分解できる可能性がある。統合的な側面を中心的なターゲットとして境界を再評価し、システム設計全体の簡略化を検討しよう。

システムにおけるサービスの平均サイズが小さくなるにつれ、システムはモノリシックな大きな泥玉(big ball of mud)から脱出して、コンテキスト境界を基本とした比較的大きなサービスを経由して、マイクロサービスに到達することができる、と指摘して、Khononov氏は講演を締め括った。同時に氏は、さらに小さなサービスを追求していくことが、最終的には“分散した大きな泥玉”に行き着くことも強調している。

エンティティサービスは、Michael Nygard氏やStefan Tilkov氏などからは、アンチパターンのひとつとして取り上げられている。