マイクロサービスアーキテクチャ読書メモ 1章マイクロサービス
黒字部分は本書の抜粋。赤字部分は私のコメントです。
マイクロサービスとは
強調して動作する小規模で自律的なサービス
小さく、かつ１つの役割に専念
凝縮生（関連するコードが集まるようにすること）が重要
単一責任原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」
Jon Evansはマイクロサービスを「２週間で書き直せるもの」と定義している
サービスが小さければ小さいほど、マイクロサービスアーキテクチャの利点と欠点が最大化される。
マイクロサービスのサイズについて、「２週間」という具体的な数字を示している。標準的なスクラム開発だと、ちょうど１スプリント分だろう。これ以上小さくすると利点よりも欠点が大きくなるケースが多くなる。
自律性
マイクロサービスは独立したエンティティ
サービス間のすべての通信はネットワークを経由して呼び出す
黄金律は「他には何も変更せずに、単独でサービスの変更やデプロイを行えるか」
主な利点
技術的異質性
サービスごとに異なる技術を使うことができる
それぞれのサービスで最適な技術を使える
リスクが低いサービスを選んで新技術を試すことができる
複数の技術の採用にはオーバーヘッドが伴う
サービスごとに異なる技術を使えるという点は、マイクロサービスの利点として喧騒されることが多いが、必ずしも最適解という訳ではない。むしろ本書で紹介されているNetflixやTwitterのように利用可能な技術に制約を課しているところがほとんどだろう。じゃないといずれメンテナンスが破綻して収拾不能になると思われる。
回復性
マイクロサービスではサービスの全体障害に対処し、それに応じて機能低下させるシステムを構築できる
究極的には全てのサービスがなんらかの機能のSPoFになってしまうと思われるので、マイクロサービス化をすると、システム全体で見たときの狭義でのサービス稼働率は下がることになると思う。ただエラーハンドリングを適切に実施することで一部機能を落とした状態で縮退運転をさせることが可能になり、結果として*しぶとい*システムになる。
スケーリング
デプロイの容易性
組織面の一致
アーキテクチャを組織によりよく一致させることができる
１つのコードベースで作業する人数を最小化し、チームの大きさと生産性を最適化できる
チーム分散の問題を解消できる
私の所属してる部署は開発チームが世界中に分散してるので、このチーム分散による弊害を肌で感じている。特に時差の大きいチーム同士で、一個のレポジトリを開発していくのは悪夢だ。この状況を改善できるだけでも、マイクロサービス化を進める意義はあるだろう。
合成可能性
第三者がサービスの機能を再利用しやすい
交換可能にするための最適化
サービスが小さいと実装置き換えや削除がしやすい
サービスをリプレースしたり破棄するために、わざわざマイクロサービス化の改修を行うなんて、いかにもまどろっこしいやり方で予算を取るのも大変そうだが、ビッグバンリプレースの困難さ（不可能さ）を思えば、むしろそうすべきだと思う。
他の分解テクニック
共有ライブラリ
共有ライブラリの欠点
技術的多様性が失われる
ライブラリは同じ言語であるか、少なくとも同じプラットフォームで動作しなければならない
システムの各部を独立してスケールさせられない
新しいライブラリをデプロイするにはプロセス全体をデプロイし直さなければならない
ビジネスドメイン固有ではなく組織内で再利用したい一般的なタスクのためのコードを作成することは、ライブラリの候補
モジュール
ライブラリより高度なライフサイクル管理が可能で、プロセスを停止せずに変更が可能になる等の利点がある
適切に分解された独立したモジュールを作ることは技術的には可能だが、実世界では、プロセス境界内のモジュール分離の約束が守られたことはほとんどない
Javaのモジュール化の仕組みであるOSGiは実際のプロダクトで導入を試したことがあるが、管理コストとベネフィットが全く見合わないので早々と破棄した経験がある。あれをまともに運用できてるシステムはどの程度あるのだろうか？
銀の弾丸などない
マイクロサービスは金のハンマーとして使うと好ましく無い選択となる
マイクロサービスには分散システムに関連するすべての複雑さがある
私の感覚だとマイクロサービスはまだそこまで流行ってないと思うが、今後メディアとか偉い人たちが口にするようになったら要注意だろう。マイクロサービスが有効な状況は限られている。
