O’Reilly Japan - マイクロサービスアーキテクチャ

設計、開発、テストや監視など一通りまとまっているマイクロサービスアーキテクチャの本。

マイクロサービスアーキテクチャというのは、協調して動作する小規模で自律的なサービスでシステムを構成するもので、 一般的なモノリシック(一枚岩)システムのモジュールのように独立したサービスを作っていく。 自律的というのは、他には何も変更せずに、単独でサービスの変更やデプロイを行えるということ。

メリットとしては

• サービスごとに異なる技術を使うことができる
• 一部のサービスで障害が発生しても、機能低下させて稼働し続けるシステムを構築できる
• 性能を高める必要があるサービスだけをスケールでき、効率的にリソースを使うことができる
• デプロイのリスクを最小限に抑えることができるため、迅速に行うことができる
• レガシーなコードを捨て去る障壁が低い

などが挙げられていた。

正しくサービスを切り分けるにはドメインの理解が必要で、「境界づけられたコンテキスト」が1つのサービスとなるようにする。 そのため、最初はモノシリックに進めることも推奨されていた。

特に初めてのドメインでは、システムをマイクロサービスに分解するのが時期尚早だとコストがかかってしまう場合があります。いろいろな意味で、マイクロサービスに分解したい既存のコードベースがある方が、最初からマイクロサービスに取り組むよりもはるかに簡単です (3.3.3)

実現する上で、DBの扱いが難しいと思った。 サービス間のDBの共有はスキーマの変更に弱く、技術の縛りが発生してしまうので避けなければならない。 一方で、DBを分割すると1つのトランザクションで完結しなくなり、どのように整合性を保っていくか。 そんな話が5章に書いてあって、いくつか方法は挙げられているが、いずれにせよ何かしらの制御をしなくてはいけないし、 データの取得の上でも一つのデータベースにあったほうが便利だったりする。 サービスの単位がデータに引きずられてしまうと、マイクロサービスとはいえないものが出来上がりそうだ。 きれいに分けられればいいが実際どうなんだろう。

すぐにマイクロサービスを採用するかは別としても、考え方として活かせそうなことが多かった。 実際にやってみて、また読み返して自分のものにしていこうと思う。