データはマイクロサービスを取り扱う際の難しい部分である

エンタープライズのためのマイクロサービスを作成・開発する際の最も難しい問題の１つはデータである。ドメイン駆動設計(DDD)を用いて事業ドメインの分析を行い、データをどう表現するかを判断することはマイクロサービスアーキテクチャを構築する際に助けになる、Christian Posta氏はマイクロサービスの実装についての一連のブログ投稿の1記事でこう述べている。

Red Hat社のPrincipal Middleware ArchitectであるPosta氏にとって、マイクロサービスアーキテクチャを選択する主な理由は、システムの各部が異なる速度で開発できることと各部のインターフェイスを最小にすることができることである。この方法でチームを組織するとき、システムアーキテクチャは組織を反映し、マイクロサービスアーキテクチャに向かって進化していく。

しかし問題はチーム間で自律的にこれらを実際に行っていくことであり、これは簡単なことではない。トランザクションを用いず単一のデータベースにすることがモノリシックなアプリケーションでは普通に行われるが、複数のサービスで各サービスが１つのデータベースを使用することは特に伝統的なエンタープライズにおいては挑戦になることがある。

Posta氏はインターネット企業におけるマイクロサービスの実装方法と伝統的なエンタープライズのそれでは大きな違いがあると述べている。インターネット企業がマイクロサービスを主に大量データとスケーラビリティの問題に対処するために使用するのに対して、伝統的なエンタープライズはビジネスの複雑性とスケーラビリティの複雑性に対処するのである。映画を配信したりツイートを投稿する際の複雑性は保険給付支払いシステムのものよりもかなり低い。

本質的に複雑な企業ドメインのためのマイクロサービスを構築する際には、そのドメイン内で異なる責務を持つ境界を発見する必要がある。各々の境界においてドメインモデルを作成し、この責務を表現するように設計を行う。そのとき、各境界のデータモデルは同じ境界にあるドメインモデルに導かれる。DDDを用いることによりこれらの境界の発見と各々の境界付けられたコンテキストの生成が行え、これらの各コンテキストがマイクロサービスとなるのである。

Posta氏の経験では、開発者は単一のリレーショナルデータベースを仮定して分散システムを構築する傾向にあり、ネットワークの信頼性の低さという現実を取り除こうとする。分散データにまつわる問題をしばしば複数のサービス間を横断する2相コミットを用いて解決している。代わりにPonta氏は各境界付けられたコンテキスト内でトランザクション境界を探し、ビジネス制約や不変条件を課すために必要なアトミックな最小のユニットを発見するべきで、トランザクションを他のコンテキストに分散させるべきではないと考えている。

それでもなお他のサービスに何が発生したかを知らせる必要はあり、これを実現するためにPosta氏はイベントを使用することを推奨している。あるサービスがそのドメイン内の事象に関するイベントを発行し、他のサービスはこれらのイベントを読み取って自身のサービスが持つモデルに適応させて任意の変更を永続化する。

この考え方をさらに詳しく知るために、Posta氏はDDDの考え方に従った集合、トランザクション境界と境界付けられたコンテキストについて記述しているVaughn Vernon氏の一連のブログ投稿を紹介している。