「マイクロサービスアーキテクチャ」を読みました

マイクロサービスアーキテクチャを読んだ話

去年くらいに話題になった「マイクロサービスアーキテクチャ」を最近読みました。
仕事でマイクロサービスアーキテクチャを採用しているプロジェクトに関わることがあり、自分自身今までマイクロサービスアーキテクチャを採用しているプロジェクトに関わったことがなかったので、そもそもマイクロサービスってどういった設計で、Monolithicなサービスと何が違うのかをちゃんと理解しようと思って読みました。

本書の構成

1. マイクロサービス
2. 進化的アーキテクト
3. サービスのモデル化方法
4. 統合
5. モノリス分割
6. デプロイ
7. テスト
8. 監視
9. セキュリティ
10. コンウェイの法則とシステム設計
11. 大規模なマイクロサービス
12. まとめ

大まかにまとめると、

• 1~2が概説
• 3~ 4が各コンポーネントやDBの設計方法、森シック→マイクロサービスにする流れの説明
• 6~9が実際にマイクロサービスアーキテクチャで考慮しなればいけない内容を分野を分けてそれぞれ具体例を用いて説明してくれている
• 10以降はもう少し粒度が荒く、組織的な内容やマイクロサービスアーキテクチャを採用する上で考慮しなければならないこと

という感じ。

3~5、6~9は実際にマイクロサービスアーキテクチャを採用する上でのプラクティスやミドルウェアの説明など粒度が細かい内容が多かったので本エントリでは触れず。

監視ツールやテスト方法、セキュリティに関しては大体設計をする上でMonolithicでもマイクロサービスアーキテクチャでも根本は同じだと感じた。

監視については、マイクロサービスに関わる全コンポーネントを監視できるようにすること。
適切に振る舞っているかを一目でわかるようなメトリックスを用意することなど、Monolithicなサービスを開発しているときは監視対象もほぼ一箇所であった一方で、マイクロサービスは小規模な各コンポーネントが自律して動作しているので、すべて が正常に動作しているかを確認できるように監視しなればならない、ということ。

監視はMonolithicなサービスを開発しているときと比べると、監視対象が増える分、適切な監視体制を構築するのはレベルの高い作業だと感じた。

マイクロサービスアーキテクチャとは？

ではそもそもマイクロサービスアーキテクチャとは何なのか？

1章の言葉を借りると 協調して動作する小規模で自律的なサービス である。

• 小さく、かつ1つの役割に専念
• 自律的

どの程度小さければいいのかという問に対してケース・バイ・ケースという答えしか書いてなかったのはちょっと個人的には消化不良。
確かにそうだとは思うのだけれど、そこの指針をもう少し教えてほしかった印象がある。
そのあたりは、実際にアーキテクチャを考える上で議論しながら適切な粒度を決めていくのがいいのであろう。

マイクロサービスの原則

まとめの章から拝借

• ビジネス概念に沿ったモデル化
• 自動化の文化
• 内部実装と詳細の隠蔽
• すべての分散化
• 独立したデプロイ
• 障害の分離
• 高度な観測

勉強になったところ

• 「境界づけられたコンテキスト」にそってコンポーネントは分割すること
  • この本を読む前に会社の中でDDD本の輪読会をしていて、DDDについて、ある程度知識を持った状態で読んだので、粒度の粗い、主に設計文脈で説明されている内容を理解するのに非常に役立ちました。
  • ビジネスレベルでのドメイン、技術レベルでのドメイン、目的レベルでのドメインなど、コンテキストを分ける粒度は組織によって異なると思いますが、一定の指針としての 境界づけられたコンテキスト を参考にすべきというのはいい指針だと感じた。
  • コンポーネント間の境界では境界をどう策定するか、どう各コンポーネント間をつなげるかの議論を丁寧に、より厳格にしていくこと。
  • 特定のコンポーネントから見たときにAPIで別のコンポーネントとつなげるので、呼び出し元のコンポーネントは呼び出し先のコンポーネントの詳細は知らなくていいこと。
  • この 知らなくていい 、裏を返せば、何を知っている必要があるのか 、どんなインターフェースを用意するのかを設計段階で合意形成しておくのが大切。
    一方で各コンポーネント内については比較的制限はゆるく、コンポーネント内の規範に従えばいいと。
• マイクロサービスもコンポーネント単位ではOOP的な思想が入っていること
  • Monolithicなサービス作っているとどうしても、内部で色々密結合してしまうことが多く、いざ大胆な変更をしたいときになかなか動き出せないことがある。
  • 疎結合、詳細の隠蔽というのはマイクロサービスアーキテクチャ全体で見るとオブジェクティブ指向のパラダイムが内部に採用されているように感じました。
• 最初からマイクロサービスにしない
• 銀の弾丸にはなりえない
  • マイクロサービスアーキテクチャは課題に対する銀の弾丸ではなく、あくまで求められる要件に対するソリューションの一つであること

読んでみての感想

流行っている、採用実績があるからと行って、プロジェクトにマイクロサービスアーキテクチャを採用していいかというのはやはりすぐには決められないことだと思う。 僕も、キャリアの中でMonolithicなサービスのいち部分を切り出したことがあったのを思い出したけど、Monolithicな状態でも疎結合で切り出しやすい形にしていてよかったと今振り返ってみても思う。
マイクロサービスアーキテクチャは銀の弾丸ではないので、やはり採用した瞬間に管理しなければならない対象は増え、全てを知る人がいなくなるかもしれない。また、ちょっとした変更でも複数コンポーネントの再デプロイが必要になるかもしれず、開発速度もその分食われて遅くなるので、スピード感をもって開発したいスタートアップなどにはむしろ向かない思想だと思う。

ただ、一方でコンポーネントが一つの状態で中にごった煮の如くありとあらゆるドメインのサービスが突っ込まれている状態のツラミももちろんあり、その点から見ると、ある一定程度の規模を超えたり、最初からスケールすることを前提とするサービスであるのであればマイクロサービスアーキテクチャを採用するのはいい選択肢だと感じた。

また、本書とはあまり関係ないけれど、去年話題になった書籍だからか、書籍内で紹介しているツールは主にAWSの内容が多かった。
今だとGCPやMicrosoftAzure等もクラウドサービスが拡張されてきて、フルマネージドな製品も出てきているので、AWSに拘る必要はないのかなーと感じた。