マイクロサービス:4つの分割アプローチの比較
増田さん
クラウド、コンテナ、設計スキル
クラウド、コンテナはあくまで必要条件
負荷分散、リスク分散、データ分散、機能分散
前3つは非機能要因
モノリス -> 可能性の検討(部分適用) -> 移行検討(部分適用)
基本は同じ
関心の分離
凝集度↑ 結合度↓
モジュール化
ロジックに対して、inbound, outbound, datasource
req/resp -> pub/sub, enque/deque(マイクロサービスで使われがち)
分割
どこまで小さく出来るか?
理論的には、メソッド呼び出しの単位
実践的には、クラウド/コンテナ/設計/運用の習熟度が限界を決めてくる
どこまで小さくするか?
論理的なモジュール分割は積極的に(モノリスだからこそ、大胆にできる)
物理的な配置、運用単位は慎重に
ネットワークは等質ではない、性質の異なる構成要素のごった煮
業務機能での分割
↑ 活動単位 = システム単位
↓ リアルワールドと同様に複雑な連携となる
企業サイズ
大企業はより細分化している -> 大企業病がシステム運用に持ち込まれる
小企業はもっと細分化していない -> 業務機能をまたぐ要求が出てくる
リアルな組織構造がキーになる
データの一貫性や流れの一貫性、修正、取り消しの処理
動詞: ユースケース
AがBをCする
↑ 機能要求を分割しやすい
↑ 開発範囲を定義しやすい
↓ トランザクション単位のマイクロサービス
サービス間のロジック重複、断片化: レガシィになりやすい構造
サービスの肥大化、重複
バッチ処理が重くなりやすい
-> 背後のロジックを共通化して分割する
名詞: リソース
Entity ごとにキーを付けて更新と参照を行う
↑ データ更新の単位を分離
↓ JOINができない、参照が複雑
むしろ、リソースの分割単位を関心事に応じて再設計すべきでは?
良い設計につながる
↓ 関心が分離できない、肥大化しがち
境界づけられたコンテキスト(DDD由来の分割)
エヴァンス vs バーノンの「コンテキスト」と「サブドメイン」の定義が違う
エヴァンスの方が設計のセオリーに合っている?
コンテキスト -> モデル -> サブドメイン
コンテキスト
ひとつのモデルを移管して適用できる範囲
境界の実体
サブドメイン
凝集度の高いコンテキスト
モデル ≒ ビジネスルール単位で分けていく
計算や判断を中心に、インバウンド、アウトバウンド、データソースを司るサービスを作っていく
トランザクション
パイプライン(VETRO)
トランザクションを分解(垂直切り離し)する
コーディネータ(Saga)
トランザクションを分散(水平切り離し)する
状態更新の非同期化(EH-SM-DSQ)
Pub/Sub による水平切り離し