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

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

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

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

かとじゅん
PRO

November 22, 2019
Tweet

More Decks by かとじゅん

Other Decks in Programming

Transcript

  1. 「モジュールとしてのマイクロサービス」と
    「分割単位としてのドメイン」について考える
    かとじゅん(@j5ik2o)
    Object Oriented Conference- 2020/2/16
    Rev 2.0

    View Slide

  2. © Chatwork
    あなたは誰?
    ● 加藤潤一(@j5ik2o)
    ● Chatwork社のテックリード
    ○ PHPからScalaへのレガシーシステム
    移行プロジェクトやってます
    ● 直近の活動
    ○ 現場でDDD 2nd
    ○ すえなみチャンス
    ○ 割り勘ドメインのワークショップなど

    View Slide

  3. © Chatwork
    テーマ
    ● 昨今のシステムは境界定義が難しい。マイクロサービスの
    文脈でもどのようにシステムを分割するかの議論がありま
    す。マイクロサービスのサービスは広義には部品のこと
    ● 部品=モジュール(モジュールもオブジェクトの一種)。
    50年来続く「部品の分割=モジュール化」の歴史からヒ
    ントを得られる
    ● 「モジュール」と「ドメイン」にどんな関係があるか、ど
    のように考えるとよいのか、課題は何か、などについて話
    します

    View Slide

  4. © Chatwork
    アジェンダ
    ● マイクロサービスアーキテクチャ(MSA)とは
    ● MSA以前の問題とは
    ● MSAでどう変わるのか
    ● 「モジュール化」の温故知新
    ● モジュールの設計要素と設計行為
    ● 分割単位としてのドメイン
    ● システム分割の課題
    ● まとめ

    View Slide

  5. © Chatwork
    マイクロサービスアーキテクチャとは
    (釈迦に説法…)

    View Slide

  6. © Chatwork
    マイクロサービス・アーキテクチャ(MSA)とは
    ● 2011年ごろからある言葉
    ● 簡単にいうと、単一のアプリケーションを小さなサー
    ビス群を組み合わせて構成する設計手法
    ○ 個々のサービスは独立したプロセス。APIなどの機
    構を介して相互通信
    ○ サービスはビジネスの遂行能力に合わせて構築さ
    れる。DevOpsやクラウドなどの完全自動化された
    機構の上に動作する

    View Slide

  7. © Chatwork
    MSA以前の問題とは

    View Slide

  8. © Chatwork
    MSA
    モノリシック
    変更の影響範囲に関する問題
    ● 従来型では一枚岩(モノリシック)なので変更の
    影響範囲を特定するのに時間が掛かっていた。
    複雑なシステムであればあるほど比例する
    ● システム内部の境界が厳密ではないので影響が
    及ぶ関連部分をすべて変更する必要があり、そ
    れに伴ってテストも広範囲になりがち
    ● モノリシックの場合は同時並行に機能変更する
    と影響範囲の特定がさらに難しくなる。場合に
    よっては逐次的に変更を管理する必要がある。
    これが小さな変更でも時間がかかる理由
    システム
    サービス
    サービス サービス
    変更
    変更

    View Slide

  9. © Chatwork
    分業形態に関する問題
    ● 従来型では「UIチーム」「ビジネスロ
    ジックチーム」「DBチーム」などの技
    術的観点で組織を分割してきた(ノウハ
    ウ共有&コスト削減できた)が問題も
    あった…
    ● 要求に合わせて適切な技術選択が難し
    い。機能に合わせてミドルウェアや言
    語の選択が難しい
    ● 技術の選択権がないと優秀なエンジニ
    アはやる気を無くす問題もある。自治
    権が与えられない
    UI
    ビジネス
    ロジック
    DB

    View Slide

  10. © Chatwork
    MSAでどう変わるのか

    View Slide

  11. © Chatwork
    マイクロサービス
    MSAでモジュール構造がどう変わったのか
    モノリシックなシステム
    受注管理
    出荷管理
    売上管理
    請求管理
    入金管理
    受注管理 出荷管理
    売上管理 請求管理
    入金管理
    APIゲートウェイ
    内部モジュールがコードやDBも共有しない独立した”コンポーネント”となった

    View Slide

  12. © Chatwork
    マイクロサービス・アーキテクチャの特徴
    ● サービスを通じたコン
    ポーネント化
    ● ビジネス遂行能力に関
    わり組織が整理される
    こと
    ● プロジェクトではなく
    プロダクト
    ● 賢いエンドポイントと土管
    ● 分割統治
    ● 分散データ管理
    ● インフラ自動化
    ● 障がいのための設計
    ● 進化的な設計
    出典: https://martinfowler.com/articles/microservices.html
    http://kimitok.hateblo.jp/entry/2014/11/09/211820 日本語訳

    View Slide

  13. © Chatwork
    サービスを通じたコンポーネント化
    ● 独立して交換・アップグレード
    可能なソフトウェアのユニット
    がコンポーネント。従来からあ
    る構造化手法と同じ。古い言い
    方ではモジュールと呼ぶ。
    ● このようなサービス分割は物理
    的にサーバ台数も増えるが、
    DevOpsやクラウドサービスの
    進化で管理コストが下げられる
    ようになった
    マイクロサービス
    受注管理 出荷管理
    売上管理 請求管理
    入金管理
    APIゲートウェイ
    DevOps
    Cloud Services

    View Slide

  14. © Chatwork
    「モジュール化」の温故知新

    View Slide

  15. © Chatwork
    モジュールとは
    ● (単純な説明としては)ハードウェアやソフトウェアを構成する個々
    の部品のこと

    View Slide

  16. © Chatwork
    FYI: モジュールの例え
    ● 数の加算的グループの部
    分集合で、それ自身加算
    的グループであるもの
    ● モジュール化が入れ子構
    造(フラクタルな構造)を
    持つ
    ● package→class→class
    などのような入れ子構造
    ● IT以前から複雑性を軽減
    するために使ってきた
    5 1 6
    4
    10
    10
    4
    6
    5 1

    View Slide

  17. © Chatwork
    モジュール化のコア概念(1/2)
    ● モジュール内では相互依存し、
    モジュール間では独立している
    ○ モジュールだけで設計は終
    わらない。構造面の独立性
    と機能面でモジュールを統
    合する枠組みすなわち
    「アーキテクチャ」が必要
    出荷管理
    出荷確認 出荷済通知
    納品書出力
    受注
    管理
    出荷
    指示
    売上
    管理
    請求
    管理
    入金
    管理
    疎結合
    (関心が弱いものは分離する )
    関心が強いもの
    を凝集させる

    View Slide

  18. © Chatwork
    モジュール化のコア概念(2/2)
    ● 抽出・情報を隠す・インターフェイスという特徴を持つ。要素が
    複雑化すると単純なインターフェイスを持つ別個の要素として抽
    出することで複雑性を隠蔽できる
    請求管理モジュール
    請求(IN)
    請求書郵送(OUT)
    請求データ送信(OUT)
    請求ルール
    ほかのモジュール
    内部の複雑な
    知識は隠蔽さ
    れている
    複雑な知識には触れ
    ずに労力だけを得る

    View Slide

  19. © Chatwork
    モジュールの設計要素

    View Slide

  20. © Chatwork
    明示的なデザイン・ルールと隠されたデザイン・パラメータ(1/2)
    ● 明示的なデザイン・ルール(明示的情報)と隠されたデザインパラメータ
    (隠された情報)を分離することでモジュール化が可能になる
    隠されたデザイン
    パラメータ
    隠されたデザイン
    パラメータ
    明示的なデザイン・ルール
    図の出典: オライリー マイクロサービスアーキテクチャ

    View Slide

  21. © Chatwork
    明示的なデザイン・ルールと隠されたデザイン・パラメータ(2/2)
    ● 明示的なデザイン・ルール
    ○ アーキテクチャ
    ■ モジュールの目的や機能を特定するもの
    ○ インターフェース
    ■ モジュールの相互作用・配置・接続・情報伝達などの定義
    ○ 標準
    ■ モジュールの機能および性能検証するための基準(契約プログラ
    ミング相当?)
    ● 隠されたデザイン・パラメータ
    ○ そのモジュールを超えて、ほかの設計に影響を及ぼさない意思決定
    ○ 隠されたモジュールは選択を遅延できる・交換可能。設計の意思決
    定は、ほかのチームと相談しなくともよい

    View Slide

  22. © Chatwork
    FYI: デザインルールがFail Fastを支えた事例
    ● IBM System/360ではIBMと異なる企業が、
    それぞれ独立して取り組みイノベーション
    の速度が向上した。企業は単一のモジュー
    ルに集中し、より深く追究できた
    ● 1つのモジュールが注目されると、膨大な実
    験が並行して行われた。モジュール設計者
    たちはモジュール相互間の動作を確保す
    る、デザインルールを守り、広範なアプ
    ローチを自由に試みることができた
    ● モジュール化のセカンドエポックはIBM PC
    でも互換機のムーブメント
    IBM System/360 (1965〜1977)
    IBM PC (1981-1990)

    View Slide

  23. © Chatwork
    FYI: モジュールがアジャイルを支える基盤になる
    ● WIKESPEED
    ○ オブジェクト指向のモジュール基盤とDbCに対応するスクラムで毎週新しい更新を
    生み出す。チームはビジネス価値を持つモジュールのオーナーとなる
    ○ モジュールによって並行したスクラムが可能となりベロシティを維持・向上させる
    ことができた。ムーアの法則のメリットを製造にも転用(ラインがマルチパス化)
    出典: https://www.agilejapan.org/2016/image/Keynote1_ScrumIncAgileJapan80minJ.pdf

    View Slide

  24. © Chatwork
    モジュールの設計行為

    View Slide

  25. © Chatwork
    モジュール化のオペレータ(1/2)
    ● デザイン階層より下位のモ
    ジュールが進化しうることが
    重要(下位システムの不確実性
    に強い)
    ● 不変性と可変性を作り込む、
    一般的な設計行為=モジュー
    ル化のオペレータがある
    モジュールA
    デザインルール
    モジュールA1 モジュールA2
    モジュールA3
    デザインルール
    モジュールA3-1 モジュールA3-2
    不変性
    可変性

    View Slide

  26. © Chatwork
    モジュール化のオペレータ(2/2)
    ● モジュールを分離する
    ● 古いモジュール設計を新しいモ
    ジュール設計に交換する
    ● モジュールを削除する
    ● それまでなかったモジュールを追加
    しシステムを拡大する
    ● 「殻」を作って当初設計された以外
    のシステムで機能するモジュールに
    する転用
    ● 複数のモジュールから共通要素を抽
    出し、階層中に新たなレベルのもの
    を作る
    包括的デザインルール
    モジュールA
    デザインルール モジュールB
    モジュールB
    モジュールB
    モジュールG
    分割
    交換
    追加
    モジュールC
    D-E デザインルール
    削除
    モジュールD
    モジュールH
    モジュールE
    F デザインルール
    モジュールF-1
    モジュールF-2
    モジュールF-3
    抽出
    転用

    View Slide

  27. © Chatwork
    FYI: モジュール型製品と統合型製品
    ● モジュール型製品は機能に対してモ
    ジュールが1対1に紐付く
    ● 統合型製品は機能に対して複数のモ
    ジュールが紐付く
    ● ある機能のために複数のモジュールを
    調整しなければならない製品はモ
    ジュール型製品と呼ばない(ただし機
    能定義による)
    ● モジュール性が高い=機能とモジュー
    ルが対応付いているかが一つの尺度に
    なる
    統合型製品
    モジュール型製品
    機能A 機能B
    モジュールA モジュールB
    機能A
    モジュールA1 モジュールA2 モジュールA3

    View Slide

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

    View Slide

  29. © Chatwork
    分割単位としてのドメイン

    View Slide

  30. © Chatwork
    販売管理ドメイン
    ドメイン駆動設計とは
    ● ドメイン
    ○ 問題や知識の領域
    ● ドメインモデル
    ○ ドメイン上の概念のこと。
    ● ドメイン駆動設計
    ○ ドメインの考え方に従うことでビジネスの
    変化にソフトウェアが対応できるようにす
    ること
    ○ ソフトウェア開発はドメインを中心にしな
    くても可能だが、それではビジネス変化に
    適応できない
    受注管理
    出荷管理
    売上管理
    請求管理
    入金管理

    View Slide

  31. © Chatwork
    請求ドメイン
    商品カタログドメイン
    ドメインとBCの関係
    ● 問題の領域
    ○ ドメイン
    ○ ビジネスの戦略課題を分
    析/明確化する領域
    ● 解決の領域
    ○ 境界づけられたコンテキ
    スト(Bounded
    Context=BC)
    ○ ビジネスの戦略課題を解
    決する領域
    ○ 業務の単位
    在庫ドメイン
    需要予測BC
    発送ドメイン
    在庫BC
    注文ドメイン
    EコマースBC
    Eコマースの例(出典:実践ドメイン駆動設計
    )
    組織が扱う関心事は
    ドメインというより
    境界づけられたコンテキスト

    View Slide

  32. © Chatwork
    コンテキストA
    BCとシステム・チームを合わせる
    ● 同じ業務ごとにチームとシステム
    を区切るとドメイン概念を把握し
    やすくなる
    ● チーム間のコミュニケーションが
    そのままシステム設計に繋がる
    (異なる2つのモデルを変換するた
    めに共通の言語を使う=公表され
    た言語)
    ● さまざまなソフトウェア活動の調
    整がしやすくなる。昔ながらのモ
    ジュールの改善と変わらない
    システム
    チーム
    コンテキストB
    システム
    チーム
    コミュニケー
    ション
    ドメインモデル
    ドメインモデル
    隠されたデザイン・パラメータ 明示的なデザイン・ルール
    プロトコル/
    イベント
    公表された言語(PL)
    サービス境界

    View Slide

  33. © Chatwork
    FYI:コンウェイの法則
    ● システムを設計する組織は、その構
    造をそっくりまねた構造の設計を生
    み出してしまう(引用:エンジニアリ
    ング組織論への招待)
    ● 情報処理能力が高まる構造が必要。
    でなれば、組織構造の問題が知らず
    知らずにシステムに組み込まれてい
    く…。
    ● ”ソフトウェアは会話でできてる”
    ○ AN AGILE WAY
    ○ コーンウェイの法則
    汎用モジュール
    職人
    個別モジュール
    開発者
    個別モジュール
    開発者
    個別モジュール
    開発者

    View Slide

  34. © Chatwork
    システム分割の課題

    View Slide

  35. © Chatwork
    適切な分割とは
    ● システムを分割することでビジ
    ネスの変化に対応できるように
    なるが、その代償としてシステ
    ムは複雑化する
    ● 逆に過剰に分割することで、変
    更に弱くなるもしくは保守性が
    下がる、可能性がある
    ● 組織に対してサービスが多すぎ
    る事例がよく観測される。
    こういった過剰な分割を検知・
    フィードバックする必要がある

    適切な分割
    過剰な分割
    分割なし
    変更に強い/保守性が高い
    変更に弱い
    保守性が低い
    分割数N
    分割数0

    View Slide

  36. © Chatwork
    モノリスは本当に問題か
    ● モノリスにも利点がある
    ○ すべてのコードが1つのプロジェクトに含まれる
    ○ コードベースが単一であるため、テストやデプロイが容易である
    ○ すべてのデータが利用可能で、サービス間で送信する必要はない
    ○ インフラストラクチャセットが単一である
    ● モジュラモノリスという選択肢
    ○ Shopifyはいかにしてモジュラモノリスへ移行したか
    ○ ECサイト運営のためのSaaS
    ○ MSAの分散システムの複雑性が問題になり代替としてモジュラモノリ
    スへ。モノリス→モジュラ・モノリス→マイクロサービスへの移行パ
    スがあると示した

    View Slide

  37. © Chatwork
    仕事の単位でモジュラー・モノリス化
    MSA文脈でのモジュラー・モノリス
    ● 分割しすぎたら関心事単位でモジュール構成を見直す。関係が強いもの
    は近くに、弱いものは遠くに。
    ● 部分的にモジューラモノリスを採用する。サービスをモジュールに格下
    げして、同一BC内で管理できるように調整する
    仕事を無視して分割しすぎ
    S1
    S2
    S3
    S4
    S5
    S6
    S7
    S8
    T1
    T2
    T3
    M1
    M2
    M3
    M4
    M5
    M6
    M7
    M8
    T1
    T2
    T3
    分割度の
    調整
    S1
    S2
    S3

    View Slide

  38. © Chatwork
    新たな課題〜フロントエンド・モノリス〜
    ● k8sなどでバックエンドをBC単位で分割しても、BFFを経由してフロン
    トエンドモノリスを作ってしまう問題。
    ● 解法の一つにMicro Frontendsがある(先行事例はSpotify, IKEAな
    ど)。フロントエンドにもモジュラモノリスの発想が必要

    View Slide

  39. © Chatwork
    まとめ
    ● 複雑なものは分けて考える。人間の認識・管理能力には限界があるの
    で複雑なものは分割するのが正攻法
    ● マイクロサービスやモジュラーモノリスはその手段。これらの手法に
    共通して重要な設計要素は、モジュール性とビジネスの関心事(境界づ
    けられたコンテキスト)
    ● システムとチーム(組織)は人間のコミュニケーションを阻害しないよ
    うに構成される必要がある(コンウェイの法則)
    ● 分割すればよいという単純な発想では落とし穴(分散システムの難易度
    など)にはまるので注意。場合によってはモジュラー型から統合型への
    部分的な回帰も必要かもしれない

    View Slide

  40. © Chatwork
    参考文献

    View Slide

  41. © Chatwork
    ご清聴ありがとうございました!

    View Slide

  42. View Slide