Reference
https://www.oreilly.co.jp/books/9784873117607/
目次
-
1章 マイクロサービス
-
2章 進化的アーキテクト
-
3章 サービスのモデル化方法
-
4章 統合
-
5章 モノリスの分割
-
6章 デプロイ
-
7章 テスト
-
8章 監視
-
9章 セキュリティ
-
10章 コンウェイの法則とシステム設計
-
11章 大規模なマイクロサービス
-
12章 まとめ
まずは
マイクロサービスとは
協調して動作する小規模で自律的なサービス
Golden Role
「他には何も変更せずに、単独でサービスの変更やデプロイを行えるか。」
メリット
技術異質性
サービスごとに異なる技術を使う決断ができる。
また影響範囲が狭いため、その決断を迅速に行う事ができる。
回復性
単一障害点を回避し、障害に応じて機能低下させるシステムを構築可能。
マイクロサービス(分散システム)特有の障害も存在することを理解しなければならない。
スケーリング
サービス単位でのスケジューリングが可能なので、モノリシックサービスに対して効率的にスケーリングが可能。
デプロイ容易性
変更の影響範囲を小さくすることができるため、迅速にデプロイが可能。
問題が生じた場合は、問題の原因である個別のサービスを迅速に特定、ロールバックを実現。
組織面の一致
アーキテクチャを組織により良く一致させることができ、1つのコードベースで作業する人数を最小化し、チームの大きさ、生産性を最適化する。
合成可能性
分散システムとSOAの主な利点の1つは、機能を再利用する機会を広げること。
目的に対して様々な方法で機能を利用可能。
交換可能にするための最適化
サービスが小さければ、サービスの置き換え、削除に対する障壁が小さくなる。
レガシーシステムを残しにくい。
大切なこと
成功のためには
マイクロサービスは様々な分野の技術や方法論を組み合わせることで成り立っています。
- SOA(サービス指向アーキテクチャ)
- DDD(ドメイン駆動設計)
- CI・CD(継続的インテーグレーション・デリバリ)
- インフラ仮想化
- 自動化
- アジャイル開発プロセス
- などなど
これらの総合的に実践することで初めて本領を発揮します。
最低限必要な標準ルール
各マイクロサービスと、システム全体の状態を監視するための仕組みやルール。
マイクロサービスがAPIを公開するための標準技術やルール。
あるマイクロサービスの障害がシステム全体に波及しないようにするための仕組みやルール。
サービスの分け方、繋ぎ方
基本的な考え方
凝集性: 変更する理由が同じものは集める、変更する理由が違うものは分ける
疎結合: 連携するサービスに関して必要最低限のことだけしか把握しない。
境界づけられたコンテキスト
「Domain-Driven Design」で述べられている概念。
わかりやすかった記事(日本語)
データは境界を決定する第二条件であるべき
大事なのは「何を行うか」
そして「そのためにはどんなデータが必要か」と考える
同じデータだからとまとめると凝集性が逆に下がってしまう。
繋ぎ方
共有データベース
DBは事実上、脆弱な大規模API
いかなる代償を払ってでも避けるべき
同期通信、非同期通信
- リクエスト/レスポンス
リクエストを発行し、レスポンスを待つ - イベントベース
イベントを通知するだけ
オーケストレーションとコレオグラフィー
あるサービスとその下流となる複数のサービスによってひとつの処理が構成される場合の制御方法
-
オーケストレーション
基点となるサービスが下流サービスをリクエスト/レスポンスでフロー制御
基点となるサービスが神サービスになりがち -
コレオグラフィー
基点となるサービスがイベントベースでイベントを発行し、下流サービスがそれを受信して個々に処理を行う
コレオグラフィによる連携を模索すべき
コード共有
よく言うDRYは危険
全てのサービスに渡るDRYには寛大になるべき
コードの重複 << サービス間の結合
DBの分割
外部キーやトランザクションを失う
CAP定理ってやつ、整合性／可用性／分断耐性
一般的にはAPシステムを選択する
整合性が取れていない状態を表現するドメインの概念(例 処理中の注文など)を導入
分散トランザクション
後半
- デプロイ
- テスト
- 監視
- セキュリティ
- コンウェイの法則とシステム設計
- 大規模なマイクロサービス
最後に
あくまで手段。
SOA、DDDのためのマイクロサービス。
決して銀の弾丸ではない。