(読書メモ) モノリスからマイクロサービスへ

Amazonリンク https://www.amazon.co.jp/dp/4873119316/

読んだ理由

• モノリス、マイクロサービスの各アーキテクチャ特性の違いを知りたかったので積んでいた本。
• ここ約3年、前職でRoRのモノリスのサービス開発をしていて、直近３ヶ月くらいはマイクロサービス的なサービスに携わり２人月程度のシステムを要件定義〜設計〜リリースまで主導した後、１日1章くらいのペースで読んでいった。きっと自分の設計思想が正しいものであったのか、もっとよい方法がないのか、ある種の答え合わせをしたかったのだろう。

読んだ感想

• 大変満足。設計の引き出しが増えた感と選定根拠を示す上での言語化する機会に役に立つ知識をインストールできた気がしている。
• 今までやってきたアーキテクトパターンや思考に名前が付いていたりと他の開発者とコミュニケーションをする上で共通認識の専門用語を使ってコミュニケーション/議論の効率化に繋がるイメージを持てた。
• モノリスとマイクロサービスどちら側でもないフラットな視点で全体的に解説されていたが印象的。それぞれにメリット・デメリットがあるのでトレードオフを理解しバランスを取る必要があるとのこと。
• サーガという分散トランザクションの紹介は、まさに最近の設計で少し悩ましかったところで、補償トランザクション (Compensating Transaction)っぽいことは考えていたので、思考方針としては正しかったことがわかって安心できた。

各章のメモ (一部)

### 5章

- 所有権のスコープ
  - 各マイクロサービスに対する所有権の扱い。組織が大所帯で自由に各マイクロサービス修正できてしまうとコードに統一感がなくなり質が悪くなりがちなので、チームで変更管理をして、他チームからはPullRequestで受ける形をとったりする
- 破壊的変更
  - マイクロサービス間のIFに変更があり、本番リリース後に影響が出る問題
  - ロックステップリリース

- 監視とトラブルシューティング
  - マイクロサービスの監視はモノリスと比べて複雑になりがち
  - まずやるべきはログ集約であり、ROIが高い。
- 本番環境でのテスト とても価値があるが、顧客に影響がないようにしよう
- マイクロサービスはモノリスに加えてe2eテストを整えるのにコストがかかる自動テストは各マイクロサービスの役割に留めるのがベストプラクティス

- 技術選定時の考え方 (5.9.3)
  - 可逆的な変更か不可逆的な変更か?
　  - 横断チームに各チームの技術リーダーを入れて組織全体のアーキクチャを共有できるような仕組みがベストプラクティスとしてあるよ
- 孤児サービス
  - サービス概要が時間経過に伴い不明になること。メタデータなどでサービス管理をすることで、サービスの役割、どのチームが作ったのか管理すべきか？などを管理しておくと、長期間運用しやすくなるだろう。そういった課題を解決するサービスも出てきている (biz ops ツール)