Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える

「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える

昨今のシステムは社内外のシステムと連携していて境界定義が難しいといわれます。マイクロサービスの文脈でもどのようにシステムを分割するかの議論があります。実はこれは50年来続く「部品の分割=モジュール化」の歴史といえます。最近ではこの部品の分割単位としてドメイン駆動設計の「ドメイン」がよく話題になります。「モジュール」と「ドメイン」にどんな関係があるのでしょうか。Chatwork社でのマイクロサービス化の事例も踏まえながらマイクロサービス設計を「モジュール」と「ドメイン」の軸で語りたいと思います。

かとじゅん

November 22, 2019
Tweet

More Decks by かとじゅん

Other Decks in Programming

Transcript

  1. © Chatwork あなたは誰? • 加藤潤一(@j5ik2o) • Chatwork社のテックリード ◦ PHPからScalaへのレガシーシステム 移行プロジェクトやってます

    • 直近の活動 ◦ 現場でDDD 2nd ◦ すえなみチャンス ◦ 割り勘ドメインのワークショップなど
  2. © Chatwork アジェンダ • マイクロサービスアーキテクチャ(MSA)とは • MSA以前の問題とは • MSAでどう変わるのか •

    「モジュール化」の温故知新 • モジュールの設計要素と設計行為 • 分割単位としてのドメイン • システム分割の課題 • まとめ
  3. © Chatwork MSA モノリシック 変更の影響範囲に関する問題 • 従来型では一枚岩(モノリシック)なので変更の 影響範囲を特定するのに時間が掛かっていた。 複雑なシステムであればあるほど比例する •

    システム内部の境界が厳密ではないので影響が 及ぶ関連部分をすべて変更する必要があり、そ れに伴ってテストも広範囲になりがち • モノリシックの場合は同時並行に機能変更する と影響範囲の特定がさらに難しくなる。場合に よっては逐次的に変更を管理する必要がある。 これが小さな変更でも時間がかかる理由 システム サービス サービス サービス 変更 変更
  4. © Chatwork 分業形態に関する問題 • 従来型では「UIチーム」「ビジネスロ ジックチーム」「DBチーム」などの技 術的観点で組織を分割してきた(ノウハ ウ共有&コスト削減できた)が問題も あった… •

    要求に合わせて適切な技術選択が難し い。機能に合わせてミドルウェアや言 語の選択が難しい • 技術の選択権がないと優秀なエンジニ アはやる気を無くす問題もある。自治 権が与えられない UI ビジネス ロジック DB
  5. © Chatwork マイクロサービス MSAでモジュール構造がどう変わったのか モノリシックなシステム 受注管理 出荷管理 売上管理 請求管理 入金管理

    受注管理 出荷管理 売上管理 請求管理 入金管理 APIゲートウェイ 内部モジュールがコードやDBも共有しない独立した”コンポーネント”となった
  6. © Chatwork マイクロサービス・アーキテクチャの特徴 • サービスを通じたコン ポーネント化 • ビジネス遂行能力に関 わり組織が整理される こと

    • プロジェクトではなく プロダクト • 賢いエンドポイントと土管 • 分割統治 • 分散データ管理 • インフラ自動化 • 障がいのための設計 • 進化的な設計 出典: https://martinfowler.com/articles/microservices.html http://kimitok.hateblo.jp/entry/2014/11/09/211820 日本語訳
  7. © Chatwork サービスを通じたコンポーネント化 • 独立して交換・アップグレード 可能なソフトウェアのユニット がコンポーネント。従来からあ る構造化手法と同じ。古い言い 方ではモジュールと呼ぶ。 •

    このようなサービス分割は物理 的にサーバ台数も増えるが、 DevOpsやクラウドサービスの 進化で管理コストが下げられる ようになった マイクロサービス 受注管理 出荷管理 売上管理 請求管理 入金管理 APIゲートウェイ DevOps Cloud Services
  8. © Chatwork FYI: モジュールの例え • 数の加算的グループの部 分集合で、それ自身加算 的グループであるもの • モジュール化が入れ子構

    造(フラクタルな構造)を 持つ • package→class→class などのような入れ子構造 • IT以前から複雑性を軽減 するために使ってきた 5 1 6 4 10 10 4 6 5 1
  9. © Chatwork モジュール化のコア概念(1/2) • モジュール内では相互依存し、 モジュール間では独立している ◦ モジュールだけで設計は終 わらない。構造面の独立性 と機能面でモジュールを統

    合する枠組みすなわち 「アーキテクチャ」が必要 出荷管理 出荷確認 出荷済通知 納品書出力 受注 管理 出荷 指示 売上 管理 請求 管理 入金 管理 疎結合 (関心が弱いものは分離する ) 関心が強いもの を凝集させる
  10. © Chatwork 明示的なデザイン・ルールと隠されたデザイン・パラメータ(2/2) • 明示的なデザイン・ルール ◦ アーキテクチャ ▪ モジュールの目的や機能を特定するもの ◦

    インターフェース ▪ モジュールの相互作用・配置・接続・情報伝達などの定義 ◦ 標準 ▪ モジュールの機能および性能検証するための基準(契約プログラ ミング相当?) • 隠されたデザイン・パラメータ ◦ そのモジュールを超えて、ほかの設計に影響を及ぼさない意思決定 ◦ 隠されたモジュールは選択を遅延できる・交換可能。設計の意思決 定は、ほかのチームと相談しなくともよい
  11. © Chatwork FYI: デザインルールがFail Fastを支えた事例 • IBM System/360ではIBMと異なる企業が、 それぞれ独立して取り組みイノベーション の速度が向上した。企業は単一のモジュー

    ルに集中し、より深く追究できた • 1つのモジュールが注目されると、膨大な実 験が並行して行われた。モジュール設計者 たちはモジュール相互間の動作を確保す る、デザインルールを守り、広範なアプ ローチを自由に試みることができた • モジュール化のセカンドエポックはIBM PC でも互換機のムーブメント IBM System/360 (1965〜1977) IBM PC (1981-1990)
  12. © Chatwork FYI: モジュールがアジャイルを支える基盤になる • WIKESPEED ◦ オブジェクト指向のモジュール基盤とDbCに対応するスクラムで毎週新しい更新を 生み出す。チームはビジネス価値を持つモジュールのオーナーとなる ◦

    モジュールによって並行したスクラムが可能となりベロシティを維持・向上させる ことができた。ムーアの法則のメリットを製造にも転用(ラインがマルチパス化) 出典: https://www.agilejapan.org/2016/image/Keynote1_ScrumIncAgileJapan80minJ.pdf
  13. © Chatwork モジュール化のオペレータ(1/2) • デザイン階層より下位のモ ジュールが進化しうることが 重要(下位システムの不確実性 に強い) • 不変性と可変性を作り込む、

    一般的な設計行為=モジュー ル化のオペレータがある モジュールA デザインルール モジュールA1 モジュールA2 モジュールA3 デザインルール モジュールA3-1 モジュールA3-2 不変性 可変性
  14. © Chatwork モジュール化のオペレータ(2/2) • モジュールを分離する • 古いモジュール設計を新しいモ ジュール設計に交換する • モジュールを削除する

    • それまでなかったモジュールを追加 しシステムを拡大する • 「殻」を作って当初設計された以外 のシステムで機能するモジュールに する転用 • 複数のモジュールから共通要素を抽 出し、階層中に新たなレベルのもの を作る 包括的デザインルール モジュールA デザインルール モジュールB モジュールB モジュールB モジュールG 分割 交換 追加 モジュールC D-E デザインルール 削除 モジュールD モジュールH モジュールE F デザインルール モジュールF-1 モジュールF-2 モジュールF-3 抽出 転用
  15. © Chatwork FYI: モジュール型製品と統合型製品 • モジュール型製品は機能に対してモ ジュールが1対1に紐付く • 統合型製品は機能に対して複数のモ ジュールが紐付く

    • ある機能のために複数のモジュールを 調整しなければならない製品はモ ジュール型製品と呼ばない(ただし機 能定義による) • モジュール性が高い=機能とモジュー ルが対応付いているかが一つの尺度に なる 統合型製品 モジュール型製品 機能A 機能B モジュールA モジュールB 機能A モジュールA1 モジュールA2 モジュールA3
  16. © Chatwork モジュールの設計改善 • デザインルールに従うかぎり モジュール単独の設計改善が 可能(密なコミュニケーショ ン) • デザインルール自体を改善す

    るときは、モジュール設計 チームどうしの合意によって 実現可能(疎なコミュニケー ション) • 組織構造がシステムに影響を 与えていることがわかる デザインルール モジュールA モジュールB 内部の改善は他のモ ジュールに影響を与え ない。独自の設計改善 が可能 デザインルールはモ ジュール設計チーム間 で合意することで修正・ チューニングされていく 密 疎 ソフトウェアは建築に例えられることがあるが、同一モジュールの構築 者と利用者が分離される、一般的なメタファではこれらの活動は説明し にくい 機能A 機能B
  17. © Chatwork 販売管理ドメイン ドメイン駆動設計とは • ドメイン ◦ 問題や知識の領域 • ドメインモデル

    ◦ ドメイン上の概念のこと。 • ドメイン駆動設計 ◦ ドメインの考え方に従うことでビジネスの 変化にソフトウェアが対応できるようにす ること ◦ ソフトウェア開発はドメインを中心にしな くても可能だが、それではビジネス変化に 適応できない 受注管理 出荷管理 売上管理 請求管理 入金管理
  18. © Chatwork 請求ドメイン 商品カタログドメイン ドメインとBCの関係 • 問題の領域 ◦ ドメイン ◦

    ビジネスの戦略課題を分 析/明確化する領域 • 解決の領域 ◦ 境界づけられたコンテキ スト(Bounded Context=BC) ◦ ビジネスの戦略課題を解 決する領域 ◦ 業務の単位 在庫ドメイン 需要予測BC 発送ドメイン 在庫BC 注文ドメイン EコマースBC Eコマースの例(出典:実践ドメイン駆動設計 ) 組織が扱う関心事は ドメインというより 境界づけられたコンテキスト
  19. © Chatwork コンテキストA BCとシステム・チームを合わせる • 同じ業務ごとにチームとシステム を区切るとドメイン概念を把握し やすくなる • チーム間のコミュニケーションが

    そのままシステム設計に繋がる (異なる2つのモデルを変換するた めに共通の言語を使う=公表され た言語) • さまざまなソフトウェア活動の調 整がしやすくなる。昔ながらのモ ジュールの改善と変わらない システム チーム コンテキストB システム チーム コミュニケー ション ドメインモデル ドメインモデル 隠されたデザイン・パラメータ 明示的なデザイン・ルール プロトコル/ イベント 公表された言語(PL) サービス境界
  20. © Chatwork FYI:コンウェイの法則 • システムを設計する組織は、その構 造をそっくりまねた構造の設計を生 み出してしまう(引用:エンジニアリ ング組織論への招待) • 情報処理能力が高まる構造が必要。

    でなれば、組織構造の問題が知らず 知らずにシステムに組み込まれてい く…。 • ”ソフトウェアは会話でできてる” ◦ AN AGILE WAY ◦ コーンウェイの法則 汎用モジュール 職人 個別モジュール 開発者 個別モジュール 開発者 個別モジュール 開発者
  21. © Chatwork 適切な分割とは • システムを分割することでビジ ネスの変化に対応できるように なるが、その代償としてシステ ムは複雑化する • 逆に過剰に分割することで、変

    更に弱くなるもしくは保守性が 下がる、可能性がある • 組織に対してサービスが多すぎ る事例がよく観測される。 こういった過剰な分割を検知・ フィードバックする必要がある … 適切な分割 過剰な分割 分割なし 変更に強い/保守性が高い 変更に弱い 保守性が低い 分割数N 分割数0
  22. © Chatwork モノリスは本当に問題か • モノリスにも利点がある ◦ すべてのコードが1つのプロジェクトに含まれる ◦ コードベースが単一であるため、テストやデプロイが容易である ◦

    すべてのデータが利用可能で、サービス間で送信する必要はない ◦ インフラストラクチャセットが単一である • モジュラモノリスという選択肢 ◦ Shopifyはいかにしてモジュラモノリスへ移行したか ◦ ECサイト運営のためのSaaS ◦ MSAの分散システムの複雑性が問題になり代替としてモジュラモノリ スへ。モノリス→モジュラ・モノリス→マイクロサービスへの移行パ スがあると示した
  23. © Chatwork まとめ • 複雑なものは分けて考える。人間の認識・管理能力には限界があるの で複雑なものは分割するのが正攻法 • マイクロサービスやモジュラーモノリスはその手段。これらの手法に 共通して重要な設計要素は、モジュール性とビジネスの関心事(境界づ けられたコンテキスト)

    • システムとチーム(組織)は人間のコミュニケーションを阻害しないよ うに構成される必要がある(コンウェイの法則) • 分割すればよいという単純な発想では落とし穴(分散システムの難易度 など)にはまるので注意。場合によってはモジュラー型から統合型への 部分的な回帰も必要かもしれない