martinfowler.comのMicroservicesを読んだメモ

フワッとしか理解できていなかったため，理解を深めるために原点となる記事を読みました．

自分に必要な部分について，理解したことと考えをまとめています． martinfowler.comの記事に書いてあるけどこの記事では飛ばしている部分が多くあります．意訳や間違って解釈している部分もあるかもしれません．ぜひ原著も読んでください．

原著で述べられていること

「マイクロサービス」の特徴（≠定義）と，モノリスと比較した違いなどについて述べられています．特に，マイクロサービスを適用する際の設計や組織やプロセスの変化，非中央化（非モノリス化）におけるデータ管理や言語・責任のあり方などについて，トピックを設けて説明されています．

モノリシックサービスの課題（マイクロサービスが解決する課題）

小さな変更がもたらす大きな影響

（後述するアプリケーションレイヤ単位の組織の分割等により，）小さな変更にも関わらず，大きなビルドやデプロイになります．これにより，以下のようなことが問題になり得ます．

ビルドやデプロイにかかる時間の増大
デプロイサイクルの速度低下
影響範囲の調査・特定の複雑化

利用リソースの非効率化

ある一つのモジュールが要求するリソースが大きければ，（それほどリソースを要求しないモジュールを含む）全体のリソースを大きくせざるを得えません．これにより利用リソースの非効率化が発生し得ます．

開発難度の向上

ビジネスケイパビリティでモジュールは分割されているかもしれませんが，コンテクストが多すぎて（広すぎて）開発者の理解や記憶が対応できません．また，モジュールの分割は開発者が制約に従って行う必要があります（モジュール境界はサービスコンポーネントほど明確ではないので，自然に行うことが難しいため）．これにより，開発サイクルの速度低下や品質の低下が発生し得ます．

ユーザ価値への視点が持ちにくい

複雑大規模なアプリケーションの分割はレイヤ境界（インフラ，データベース，UI，サーバサイドロジック，など）により行われ，組織もレイヤ境界により分割されます（コンウェイの法則）．これにより，開発者がユーザ価値の視点を持ちづらくなり，サービスが与える価値や妥当性が低下し得ます．

マイクロサービスの特徴

形態

httpやRPCやMQによって疎結合されるサービス群により実現されるアプリケーションです．
相互に非依存にデプロイが可能です．
データが非中央化され，例えばサービス単位にデータベースを持ち得ます．
- 一貫性を保つためにトランザクションの機構を待つのは大変であり別の問題を発生させ得るため，結果整合性のみのトランザクションレスアプローチがとられることがあります．
インフラの自動化やCI/CDがモノリシックサービスよりも重要化します．

効果

サービスごとに最適な言語や技術を利用できます．
サービスコンポーネント単位の追加・廃棄が速く容易です（進化的設計が可能です）．
- サービスコンポーネント分割の観点は，低依存な置換性とアップグレード性です．
- 一部のサービスだけRAD開発用の言語を適用することなどができます．
- Guardianの例のように，基本的にモノリシックサービスだがモノリシックサービスのAPIを使って新規機能をマイクロサービスで構築することもできます．
- 他のサービスコンポーネントとの依存性が低かったり，一時的であること（廃棄）が予測されるものであれば特に有用です．
プロジェクトからプロダクトへのメンタリティの変化を開発者に促します．
- 開発者はプロダクトのライフサイクル全体に責任を持ち，顧客との関係性を高めることができます．
- モノリシックサービスでもそれは可能ですが，マイクロサービスのサービス粒度ではそれが容易いです．

注意点

モノリシックサービスの課題を解決するためには，アーキテクチャを変えるだけではなく，サービス境界と組織の境界を相似させること．
In-Processなモジュール間のコミュニケーションメソッドに比べ，サービスコンポーネント間のコミュニケーションメソッドが粗野になることを前提とした設計を行うこと．
- Design for Failure
- Circuit Breaker
- リアルタイムモニタリング
- 非同期API呼び出し
- etc
マイクロサービスの利点とトレードオフになる欠点を理解すること．
- 分散システムに特有の問題
- 結果整合性
- オペレーションの複雑姓
サービス境界が明確であるがゆえに，In-processなモジュールよりもリファクタリングが困難になること．（サービスを跨ぐコードの移動や，インタフェースの変更は簡単でないため．）

マイクロサービス化の検討の際に考えること

新規サービスにおけるマイクロサービスの適用

新規サービスには，モジュール分割を適切にしたモノリシックサービスから始め，モノリシックサービスの課題が現れてからマイクロサービスを考えるのが良いアプローチです．

既存のモノリシックサービスのマイクロサービス化

マイクロサービス化するためにマイクロサービス化してはいけないと考えます（マイクロサービス化が目的であってはならない）．対象プロダクトの課題は何なのか，その課題がマイクロサービス化により解決できるのか，を分析することがまず先決でしょう．また，何でもそうですが，マイクロサービスも銀の弾丸ではないので，トレードオフを理解した上で，適用することに価値があるのかよく見定める必要があるでしょう．

チームスキルはシステムの質に影響します．マイクロサービス化を行うと決めた場合，マイクロサービス化が適切であってもチームのスキルが追いついていなければ状況は悪化し得ます．チームスキルの向上やチームのマイクロサービスに対する理解も同時に必要になるでしょう．その際，例えば複雑なドメインを分割し適切なサービス境界を作るためにDDDなどが役に立ちそうです．