急にマイクロサービスやってと言われた時に読む本

急にそんなこと言われたら手段が先行してるので、そもそも何がやりたいんだっけの話をしましょう。

それはさておき、マイクロサービスや分散アーキテクチャがなんにもわからない状態の時に読みたい本を書いていきます。

# はじめに
ここでいうマイクロサービスはモノリスアプリケーションを分解する過程や思想の先にあるものを指しています。

自分が開発しているのはモノリシックなアプリなのでマイクロサービスは関係ないと思っている人もいるかも知れません。
しかし、web アプリケーションを作っていると、完全にスタンドアローンな状態は珍しく、大抵は何かしらの外部 API （決済など）をコールしていることが多いと思います。それは広義の意味では分散システムであると言えます。故に、web アプリケーションを開発しているのであれば分散システムについてインプットしておくのは有意義だと思います。

# 概念編
## マイクロサービスアーキテクチャ 第2版
https://www.oreilly.co.jp/books/9784814400010/

とりあえずこれさえ読んでおけば間違いない一冊。
2022年12月に出版されたもので、2016年に出た第1版から大幅に増改訂（ページ数は約2倍w）があり、マイクロサービスに関するトピックを網羅的にカバーしています。
概念から技術的プラクティスからテストや組織論まで、マイクロサービスをやろうとした時に考えないといけないことが全てわかります。正直これ一冊読んでおけばそれっぽい会話ができるので、とりあえず読んでおいて損がないと思います。


## マイクロサービスパターン 実践的システムデザインのためのコード解説
https://book.impress.co.jp/books/1118101063

本書も上述の本と同じく、マイクロサービスについて広く解説した内容になっていて、とりあえず手に取るのにうってつけの一冊。
Java ですがサンプルコードがいくつか載っています。ただ、上述のオライリーの「マイクロサービスアーキテクチャ」を読んでいるなら重複する内容も多いので読まなくても良いかも。

## ソフトウェアアーキテクチャの基礎
https://www.oreilly.co.jp//books/9784873119823/

マイクロサービスパターンだけでなく、その他の様々なアーキテクチャを横並びに紹介している本。
ソフトウェアアーキテクチャそのものの定義やアーキテクチャを考える際の考慮ポイントなど、それぞれのアーキテクチャパターンのメリデメを比較しながら解説してくれるため、入門書として大変わかりやすいです。
マイクロサービスパターン自体は単なる手段の一つでしかなく、構築や運用の難易度が高いといった負の側面もあります。他にどういった手段があるのかを検討することで適切な選択ができるようになります。
マイクロサービス云々に関わらず読んでおくと今後の技術選定の糧になります。

本書で紹介されている各パターンのメリデメ早見表

https://zenn.dev/nakaryo/articles/0e6b53d4eeeca2

## エリック・エヴァンスのドメイン駆動設計
https://www.shoeisha.co.jp/book/detail/9784798126708

有名な DDD の本。
ドメイン駆動における _境界づけられたコンテキスト_ や _集約_ の考え方は、そのサービスが何を解決しようとしているのか、を明確にするステップです。サービス分割時のサービス境界を考えるときにどのようにサービスを定義したらいいかの助けになるかもしれません。
実装プラクティスの部分は参考にしなくていいと思います。

# 実践編
## モノリスからマイクロサービスへ
https://www.oreilly.co.jp//books/9784873119311/

名前の通り、モノリスをマイクロサービスに移行していく際の手順や考え方が書かれています。ここまでは割と概念的な面を説明する本でしたが、本書は実践的な内容も多く、現場で役立つ一冊です。
[ストラングラーパターン](https://martinfowler.com/bliki/StranglerFigApplication.html)や共有データベースなど、具体的な技術的プラクティスが説明されているので、実際に手を動かしながら手順を追ってみるのもいいかもしれません。
また、この本の冒頭で結構な誌面を割いて、マイクロサービス化はハードルがたくさんあるからよく考えてから実行に移そうという趣旨のことが書いてあって、それも非常に良かったです。

## データ指向アプリケーションデザイン
https://www.oreilly.co.jp/books/9784873118703/

有名なイノシシ本。マイクロサービスの本というわけではないですが、分散システムでデータを扱うためのチップスがたくさん載っているので必読の一冊。
分散システムで一番難しいのはデータの保存やサービス間でのデータのやり取りだと思います。この本では分散環境で発生する問題や一貫性、トランザクションの考え方など、他の本ではあまり見かけないトピックが満載で、かなり読み応えがあります。読むことで必ずレベルアップできる一冊です。冒頭にも書きましたがマイクロサービス化してなくても自分のサービスが何かしらの外部 API と通信していることは多々あり、その際の通信の信頼性やデータの一貫性、整合性が損なわれるのはどんな時か、というのは知っておくべきなので、web サービスを作っている人全員におすすめします。
マイクロサービスの観点では、サービスを分割した際のデータの信頼性の担保をより強固なものにできるでしょう。

ちなみに第8章には「分散システムの問題」というタイトルが付いており、ネットワークフォールトやビザンチン問題などの分散システムにフォーカスした話になっています。

https://speakerdeck.com/xerial/30fen-dewakarudetazhi-xiang-apurikesiyondezain-data-engineering-study-number-18

## 分散システムデザインパターン
https://www.oreilly.co.jp/books/9784873118758/

分散システム構築における、割と具体的な技術的プラクティスをいくつか紹介してくれています。
分散システムを構築するという方針が決まってから読むと、how について学べるので良いと思います。
サイドカーコンテナパターンやイベント駆動など、分散システム環境上で特に有効なチップスが学べます。


## ソフトウェアアーキテクチャ・ハードパーツ
https://www.oreilly.co.jp//books/9784814400065/

「ソフトウェアアーキテクチャの基礎」の作者が、その内容を補完するような内容を書いた一冊。前著ではアーキテクチャパターンの紹介にとどまっていましたが、この本では架空のプロジェクトをベースに、実際にどのような意思決定をしてアーキテクチャ選定をしていくかをロールプレイ的に学べます。現行のシステムの問題点を解消するために、それぞれの解決策にどんなトレードオフがあるのかを整理しながら話を進めていくので、自分の作っているシステムにはどれが当てはまりそうかを考えながら読むのもいいかもしれません。
また、「進化的アーキテクチャ」で提唱されていた適応度関数というものを使って、選択したアーキテクチャが損なわれていないかを機械的にチェックする機構も解説していて、これも良かったです。

https://www.oreilly.co.jp/books/9784873118567/

## Kubernetesマイクロサービス開発の実践

https://book.impress.co.jp/books/1123101061

別にこの本でなくてもいいのだけど、Kubernetes はインプットしておくといいかもしれない。
マイクロサービスでシステムを分割していくと、それらをどのように物理的に動かすのかについて考えないといけない。例えば、複数サービスの協調スケーリングだったり、サービスヘルスチェックだったり、サービスディスカバリだったりといった、モノリスの時にはなかった考慮点が出てくる。
Kubernetes はそうした複数のサービスをオーケストレーションするのに有効なツールなので、インフラを立てる際は検討してみてもいいかもしれない。

# その他ネット記事

## モジュラモノリス
少し前まではモノリスが辛い→マイクロサービス化、という風潮がありましたが、マイクロサービスはマイクロサービスで色んな辛みがあり、移行したはいいものの辛みの種類が変わっただけで結局辛いという事例も多々あったそうです。
最近ではマイクロサービスの辛みとモノリスの辛みの解消のいいとこどりをしたような手法としてモジュラモノリスというものがあります。
書籍ではないですが、自分が最初に目にしたのは shopify の事例でした。

https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity

https://qiita.com/tkyowa/items/ae9fa550237cb6f48318

shopify では当時約6000個あった Ruby のクラスをスプレッドシートにリストアップし、それらに手動でラベリングをしていくという地道な作業から始まったそうです。また、サービス境界を跨いだ参照を自動で検出するためのツールを自作していたりと、始めるまでの道のりが中々ハードルが高そうです。

これはこれでルールを決めて構築するのが難しそうですが、最近事例も増えてきた気がするのでインプットして試してみるのもいいかもしれません。

## サービスメッシュ
サイドカーパターン
サービスをドメインで分割していくと、本来分離する必要のない技術的な関心ごと（監視やロギング、ネットワークプロトコルなど）が各サービスで多重管理され、wet になります。また、ネットワーク通信に関する様々な問題点も出てきます。
そうしたものを解決するためにサービスメッシュという概念があります。

https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh
https://dev.classmethod.jp/articles/servicemesh/

具体的な構築としてはサイドカーコンテナパターンを使うことが多いです。

https://learn.microsoft.com/ja-jp/azure/architecture/patterns/sidecar


## アンビエントメッシュ

https://istio.io/latest/blog/2022/introducing-ambient-mesh/

Istio が提唱する新しいサービスメッシュの形。
1アプリコンテナに1サイドカーコンテナは結構無駄が多いので、サイドカーの中でさらに責務を分割して、共通化できる部分を単一のプロキシとして動かそうという思想。それによってより効率的に、セキュアになる。