マイクロサービス ４つの分割アプローチ
•
55 recomendaciones•42,269 vistas
アプリケーションの分割のアプローチ ●４つのアプローチ - ビジネスファンクション - 動詞／ユースケース - 名詞／リソース - 境界づけられたコンテキスト ● トランザクションの分割 - パイプライン化 (VETRO) - コーディネート (Saga) - 状態更新の非同期化 ( Event History - State Materialize - Domain Specific Query )
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a マイクロサービス ４つの分割アプローチ
Más de 増田 亨
Más de 増田 亨 (20)
マイクロサービス ４つの分割アプローチ
- 19. ネットワークは信頼できる → 必ず落ちる ネットワークは遅延しない → メモリに比べとんでもなく遅い ネットワークの帯域は無限である → 帯域は有限 ネットワークは安全である → アクセスできている＝穴が開いている ネットワーク構成は変化しない → 誰かが前触れもなく変更する 一人の管理者が集中管理してくれる → 複数人がばらばらに管理している 転送コストはゼロである → データ転送はお金がかかる ネットワーク全体は等質である → 性質の異なる構成要素のごった煮 出典：Fallacies of Distributed Computing Explained http://www.rgoarchitects.com/Files/fallacies.pdf 勘違い 真実 2019/5/18 19
- 24. ビジネスファンクションによる分割 ✓業務の活動単位・管理単位を、そのままシステム構造に反映 ✓サービス間連携が（現実世界と同じ）複雑さになりやすい ✓大企業の場合 ➢ 業務機能ごとに部門が分かれている ➢ 商品カテゴリ、担当地域などでさらに細分化が必要かも ➢ 大企業病（非効率、硬直化、調整ごとの多さ、合意形成までの時間）がシステ ムの開発・運用に、そのまま持ち込まれる ✓中小企業の場合 ➢ 複数の業務機能をひとつの部門が担当する ➢ 業務機能をまたがった要求がでてきやすい（システム構造との不整合がおき やすい） 2019/5/18 24
- 32. 名詞／リソースで分割 ✓エンティティ＋CRUD ✓データ更新に責任を持つサービスを明確できる ✓リソース単位をまたがった参照が複雑になりがち ➢ 外部キー参照制約、JOINが使えない世界 注文データが顧客番号と商品番号を持つ ✓異なる関心事が混在し、肥大化しがち ➢ 顧客 識別情報、プロファイル、連絡先、購入履歴、プリファレンス、コミュニ ケーション履歴、認証・認可の設定、アクセス履歴、 … ➢ 商品 識別情報、説明、仕様、価格、在庫状態、物流特性、… 2019/5/18 32
- 33. リソース管理単位の分割 2019/5/18 33 顧客系リソース 商品系リソース ID-氏名 プロファイル 連絡先 購入履歴 プリファレンス コミュニケー ション履歴 認証認可 設定 アクセス 履歴 番号-名前 商品カタログ 仕様詳細 価格 物流特性 仕入特性 取り扱い状態 在庫状態 モノリスのリソース管理を、こういう単位のCRUDに分割しながら マイクロサービスへの移行を検討する
- 35. わからん！ 2019/5/18 35 解釈も定義も説明もばらばら… 原因の一つはバーノンの「実践ドメイン駆動設計」の説明が、 エヴァンスの「ドメイン駆動設計」とは、だいぶ違った独自の解釈と説明だから
- 36. ドメイン 2019/5/18 36 モデル サブ ドメイン サブ ドメイン サブ ドメイン 境界づけられた コンテキスト サブドメイン サブドメイン コンテキスト コンテキスト コンテキスト エヴァンス流 コンテキスト → モデル → サブドメイン バーノン流 ドメイン → サブドメイン → コンテキスト
- 37. エヴァンス流の定義 ✓Bounded Context : 境界づけられたコンテキスト ➢ひとつのモデルを一貫して適用できる範囲 ➢境界の実体 ⚫ チーム（密接なコミュニケーションの範囲） ⚫ ソースコードやDBスキーマの所有権（変更可能範囲） ✓サブドメイン ➢特定のモデルの中の、独立性の高い、凝集した塊 2019/5/18 37 どちらもマイクロサービスの単位になりえる 実際には、サブドメインは設計の見直しで定義しなおすことが多い サブドメインでマイクロサービスに分けるのは設計改善の障害になりやすい
- 44. 2019/5/18 44 ビジネスファンクション 業務の活動単位・管理単位で分割する 動詞/ユースケース 機能要求一覧で分割する 名詞/リソース エンティティ+CRUD ビジネスルール中心 境界づけられたコンテキスト サブドメイン （ドメイン駆動設計由来の分割）
- 46. トランザクション 分解パターン 2019/5/18 46 パイプライン化 （VETRO） コーディネータ （Saga） 状態更新の非同期化 （EH-SM-DSQ）
- 49. inbound メッセージ Event 通知、Document送付 Query 問い合わせ、Command 指示 Validation 妥当性検証 メッセージ内容の妥当性を検証する データ形式、必須属性、値範囲、… Enrich 情報付加 メッセージに含まれたIDなどから、関連する情報を収集 するルール（ex. 顧客ID->顧客購買履歴) Translate 情報導出 付加された情報を元に、新たな情報を導出するルール （ex. 購買履歴 → 顧客ランク ) Routing 分岐判定 導出された情報を元に、適切なオペレーションに分岐さ せるルール ( ex. 顧客ランクごとの対応 ) Operation 通知/記録 通知ルール：誰に何を通知すべきか？ 記録ルール：どこに何を記録すべき？ 2019/5/18 49
- 51. コーディネータ （Saga） ③が不成立だった場合、①と②にキャンセル処理を実行する さまざまな状況と、その対応方法(undo)の物語を用意する ①②③を、独立して、順不同で実行する 三つともOKであれば完了（Happy Goal) ①独立したトランザクション A ②独立したトランザクション B ③独立したトランザクション C inbound メッセージ コーディ ネータ ひとつの大きなトランザクション → 独立した複数の小さなトランザクションに分割 2019/5/18 51
- 54. 状態更新の非同期化 イベント記録 Event History イベント履歴に追記のみ 状態は更新しない 状態は、履歴を再生して 動的に導出する 状態の実体化 State Materialize 目的ごとに必要な状態を 導出する イベント発生とは 非同期に処理 (publish/subscribe) 目的別のクエリ Domain Specific Query 検索の文脈ごとのクエリ サービスを提供する （なんでも検索にしない） APIがシンプルになる 各クエリのパラメータは数 個にとどめる 2019/5/18 54
- 55. Event History - State Materialize – Domain Specific Query 2019/5/18 55 inbound イベント イベント ハンドラ 目的別 状態 状態の 実体化 問合せ subscribe 目的別 状態 状態の 実体化 問合せ subscribe 目的別 状態 状態の 実体化 問合せ subscribe publish イベント 履歴 追記 ① ② ③ 状態は、履歴を再生して導出 問合せを目的別に分解することで、 APIとデータ構造をシンプルにできる
- 60. トランザクションの分解パターン 2019/5/18 60 パイプライン化 （VETRO） コーディネータ （Saga） 状態更新の非同期化 （EH-SM-DSQ）