カンファレンス動画や記事等で中長期の観点でためになりそうなものの要約MEMOです。
以下の動画の要約MEMOです。
GOTO 2019 • Event-Driven Microservices, the Sense, the Non-sense and a Way Forward • Allard Buijze
Event, Event Sourcing, CQRS等を学んで、とにかく使いたくて仕方ない人にお勧めの動画です。DDD(ドメイン駆動設計)の用語もいくつか出てくるため、そのあたりも知っていた方が良いです。
というかEvent-Driven MicroserviceのためにDDDを学ぶのもありです。
要約MEMO
Box + Box + Cylinderによるアーキテクチャ
- どんどんBoxを追加することでレイヤを増やして依存関係を見えなくする従来のアーキテクチャ。
- フンコロガシが転がす玉のようにフン団子が肥大化していく。ちなみにフン団子に乗っているフンコロガシがアーキテクトとのこと。
マイクロサービスが救いになる？
- マイクロサービスはAgility + Team Scalabilityを提供してくれるが、新たな複雑性を追加することになる。
- マイクロサービスをどう分けるかが重要となる。
- 名詞でマイクロサービスを作るNoun Driven Designが横行。
- モノリシックサービスのフン団子をマイクロサービスにしても、大量の小さなフン団子になるだけ。
- 大量の小さなフン団子を避けるためにはモジュール性を高める必要がある。
- モジュール性を高めても、怠惰や技術負債などの様々な要因でフン団子になる可能性がある。
マイクロサービスを救いにするためには？
- カラテキッドという映画における「ワックスがけ」を先に学ぶ。(まずは自己制御などの規律を身につける)
- マイクロサービスを作る前に、まともなモノリシックサービスの作り方を先に学ぶ。
- マイクロサービスの旅(Journey)は、モノリシックサービスから始めて、少しずつマイクロサービスへと発展させていく。あわよくばサーバーレスへと歩む。
- 旅の歩みを着実に進めるために、サービスのLocation Transparencyを保つことが重要となる。
- Location Transparency: コンポーネントは自分も相手もどのロケーション(ex. マシン、VM)にいるかを意識する必要がない。
Eventが救いになる？
- Eventを導入することにより、サービスの依存性を逆転させて疎結合にできる。
- 全てをEventにすればいいのか？マズローのハンマーのような確証バイアスに陥る危険がある。
- Event通知、Event Sourcingなどで全ての釘/問題に対応したくなる？
- 例えばサービス間で全てのEventのデータを複製する仕組みを取ると、各サービスが興味のないEventまで意識する必要が出てくる。
- 複数のサービス間で双方向のやりとりをEventでやるのは、各サービスが「ノドが渇いた！」と宣言した後で口を開けて水を待つような滑稽さ。水を直接飲めばいい。
- Eventで双方向のやりとりをした場合、前述した依存性の逆転は意味をなさなくなる。(双方向を逆転しても双方向)
マイクロサービスのMessaging種類
- マイクロサービスのMessagingはEventだけではない。
- Event: 全ての対象サービスに通知する。結果は返らない。
- Command: 一つのサービスに発行する。確認/結果が返る。
- Query: ロードバランシングで一つ以上のサービスに発行する。必要に応じて集約したりする。結果が返る。
- Message = Eventではないことを理解する必要がある。
- あるサービスに通知する場合はEventを使用し、情報を取得する場合はQueryを使用する。適材適所。
Event Sourcingの誤解
- ただ単にEventをストアすればEvent Sourcingなのか？
- 全体の事実をキャプチャするのがEvent Sourcingである。
- Event Sourcingでは状態を保持せず、状態に導くEventを全て保存する。
- Event Sourcingにはビジネス面、技術面の様々な利点がある。(このあたりは色々な記事や動画で言及されてる)
- ストレージサイズや実装の複雑性は既に大きな課題ではない。課題はEventという考え方のみ。状態を考えるのではなく、振る舞いを考えてEventを抽出する。
- では全てをEvent Sourcingにすればいいのか？答えはもちろんNOである。マズローのハンマーに陥ってはいけない。
- 一つのEntityの変化を処理するようなCommandとの相性は良いが、汎用的なQueryとの相性は悪い。
- 上記のQueryとの親和性を高くするためにCQRSを導入すれば良い。
- では全てをEvent Sourcing + CQRSにすればいいのか？答えはもちろんNOである。
Eventという契約/婚姻
- サービス間でコミュニケーションを行うということは一種の契約であり、婚姻のようなものである。
- Eventが他のサービスに流れたら、その時点でEventが流れたサービスに対して契約/婚姻の関係が発生する。
- Event Sourcingの場合はその中の些細な詳細すらもEventとなるため、意図しない形で上記の契約/婚姻が発生する可能性がある。
- この契約/婚姻の範囲を制限するためにBounded Contextを設けることが重要となる。Bounded Context内のサービスのみがEventという契約/婚姻を結べばよい。
- Bounded Contextを設けるだけでは関係のないサービスにEventが流れることは防げない。このためAnti-Corruptionレイヤを設けて、Bounded Context外のサービスへのEventをフィルタリングしたり変換したりする必要がある。
まとめ
- Eventだけではなく、CommandとQueryも考慮して使用すること。
- 共有すること(Sharing)は介護すること(Caring)と同じ。Eventは流れたところ全てで共有したことになる。
- Bounded Context間の結合/連結に注意すること。
- マイクロサービスは旅である。はじめにモノリシックサービスからスタートし、マイクロサービスに発展させる。ワックスがけ(Wax-On)から始めよう。