昨今のシステムは社内外のシステムと連携していて境界定義が難しいといわれます。マイクロサービスの文脈でもどのようにシステムを分割するかの議論があります。実はこれは50年来続く「部品の分割＝モジュール化」の歴史といえます。最近ではこの部品の分割単位としてドメイン駆動設計の「ドメイン」がよく話題になります。「モジュール」と「ドメイン」にどんな関係があるのでしょうか。Chatwork社でのマイクロサービス化の事例も踏まえながらマイクロサービス設計を「モジュール」と「ドメイン」の軸で語りたいと思います。
「モジュールとしてのマイクロサービス」と「分割単位としてのドメイン」について考えるかとじゅん(@j5ik2o)Object Oriented Conference- 2020/2/16Rev 2.0
View Slide
© Chatworkあなたは誰？● 加藤潤一(@j5ik2o)● Chatwork社のテックリード○ PHPからScalaへのレガシーシステム移行プロジェクトやってます● 直近の活動○ 現場でDDD 2nd○ すえなみチャンス○ 割り勘ドメインのワークショップなど
© Chatworkテーマ● 昨今のシステムは境界定義が難しい。マイクロサービスの文脈でもどのようにシステムを分割するかの議論があります。マイクロサービスのサービスは広義には部品のこと● 部品＝モジュール(モジュールもオブジェクトの一種)。50年来続く「部品の分割＝モジュール化」の歴史からヒントを得られる● 「モジュール」と「ドメイン」にどんな関係があるか、どのように考えるとよいのか、課題は何か、などについて話します
© Chatworkアジェンダ● マイクロサービスアーキテクチャ(MSA)とは● MSA以前の問題とは● MSAでどう変わるのか● 「モジュール化」の温故知新● モジュールの設計要素と設計行為● 分割単位としてのドメイン● システム分割の課題● まとめ
© Chatworkマイクロサービスアーキテクチャとは(釈迦に説法…)
© Chatworkマイクロサービス・アーキテクチャ(MSA)とは● 2011年ごろからある言葉● 簡単にいうと、単一のアプリケーションを小さなサービス群を組み合わせて構成する設計手法○ 個々のサービスは独立したプロセス。APIなどの機構を介して相互通信○ サービスはビジネスの遂行能力に合わせて構築される。DevOpsやクラウドなどの完全自動化された機構の上に動作する
© ChatworkMSA以前の問題とは
© ChatworkMSAモノリシック変更の影響範囲に関する問題● 従来型では一枚岩(モノリシック)なので変更の影響範囲を特定するのに時間が掛かっていた。複雑なシステムであればあるほど比例する● システム内部の境界が厳密ではないので影響が及ぶ関連部分をすべて変更する必要があり、それに伴ってテストも広範囲になりがち● モノリシックの場合は同時並行に機能変更すると影響範囲の特定がさらに難しくなる。場合によっては逐次的に変更を管理する必要がある。これが小さな変更でも時間がかかる理由システムサービスサービス サービス変更変更
© Chatwork分業形態に関する問題● 従来型では「UIチーム」「ビジネスロジックチーム」「DBチーム」などの技術的観点で組織を分割してきた(ノウハウ共有&コスト削減できた)が問題もあった…● 要求に合わせて適切な技術選択が難しい。機能に合わせてミドルウェアや言語の選択が難しい● 技術の選択権がないと優秀なエンジニアはやる気を無くす問題もある。自治権が与えられないUIビジネスロジックDB
© ChatworkMSAでどう変わるのか
© ChatworkマイクロサービスMSAでモジュール構造がどう変わったのかモノリシックなシステム受注管理出荷管理売上管理請求管理入金管理受注管理 出荷管理売上管理 請求管理入金管理APIゲートウェイ内部モジュールがコードやDBも共有しない独立した”コンポーネント”となった
© Chatworkマイクロサービス・アーキテクチャの特徴● サービスを通じたコンポーネント化● ビジネス遂行能力に関わり組織が整理されること● プロジェクトではなくプロダクト● 賢いエンドポイントと土管● 分割統治● 分散データ管理● インフラ自動化● 障がいのための設計● 進化的な設計出典: https://martinfowler.com/articles/microservices.htmlhttp://kimitok.hateblo.jp/entry/2014/11/09/211820 日本語訳
© Chatworkサービスを通じたコンポーネント化● 独立して交換・アップグレード可能なソフトウェアのユニットがコンポーネント。従来からある構造化手法と同じ。古い言い方ではモジュールと呼ぶ。● このようなサービス分割は物理的にサーバ台数も増えるが、DevOpsやクラウドサービスの進化で管理コストが下げられるようになったマイクロサービス受注管理 出荷管理売上管理 請求管理入金管理APIゲートウェイDevOpsCloud Services
© Chatwork「モジュール化」の温故知新
© Chatworkモジュールとは● (単純な説明としては)ハードウェアやソフトウェアを構成する個々の部品のこと
© ChatworkFYI: モジュールの例え● 数の加算的グループの部分集合で、それ自身加算的グループであるもの● モジュール化が入れ子構造(フラクタルな構造)を持つ● package→class→classなどのような入れ子構造● IT以前から複雑性を軽減するために使ってきた5 1 641010465 1
© Chatworkモジュール化のコア概念(1/2)● モジュール内では相互依存し、モジュール間では独立している○ モジュールだけで設計は終わらない。構造面の独立性と機能面でモジュールを統合する枠組みすなわち「アーキテクチャ」が必要出荷管理出荷確認 出荷済通知納品書出力受注管理出荷指示売上管理請求管理入金管理疎結合(関心が弱いものは分離する )関心が強いものを凝集させる
© Chatworkモジュール化のコア概念(2/2)● 抽出・情報を隠す・インターフェイスという特徴を持つ。要素が複雑化すると単純なインターフェイスを持つ別個の要素として抽出することで複雑性を隠蔽できる請求管理モジュール請求(IN)請求書郵送(OUT)請求データ送信(OUT)請求ルールほかのモジュール内部の複雑な知識は隠蔽されている複雑な知識には触れずに労力だけを得る
© Chatworkモジュールの設計要素
© Chatwork明示的なデザイン・ルールと隠されたデザイン・パラメータ(1/2)● 明示的なデザイン・ルール(明示的情報)と隠されたデザインパラメータ(隠された情報)を分離することでモジュール化が可能になる隠されたデザインパラメータ隠されたデザインパラメータ明示的なデザイン・ルール図の出典: オライリー マイクロサービスアーキテクチャ
© Chatwork明示的なデザイン・ルールと隠されたデザイン・パラメータ(2/2)● 明示的なデザイン・ルール○ アーキテクチャ■ モジュールの目的や機能を特定するもの○ インターフェース■ モジュールの相互作用・配置・接続・情報伝達などの定義○ 標準■ モジュールの機能および性能検証するための基準(契約プログラミング相当?)● 隠されたデザイン・パラメータ○ そのモジュールを超えて、ほかの設計に影響を及ぼさない意思決定○ 隠されたモジュールは選択を遅延できる・交換可能。設計の意思決定は、ほかのチームと相談しなくともよい
© ChatworkFYI: デザインルールがFail Fastを支えた事例● IBM System/360ではIBMと異なる企業が、それぞれ独立して取り組みイノベーションの速度が向上した。企業は単一のモジュールに集中し、より深く追究できた● 1つのモジュールが注目されると、膨大な実験が並行して行われた。モジュール設計者たちはモジュール相互間の動作を確保する、デザインルールを守り、広範なアプローチを自由に試みることができた● モジュール化のセカンドエポックはIBM PCでも互換機のムーブメントIBM System/360 (1965〜1977)IBM PC (1981-1990)
© ChatworkFYI: モジュールがアジャイルを支える基盤になる● WIKESPEED○ オブジェクト指向のモジュール基盤とDbCに対応するスクラムで毎週新しい更新を生み出す。チームはビジネス価値を持つモジュールのオーナーとなる○ モジュールによって並行したスクラムが可能となりベロシティを維持・向上させることができた。ムーアの法則のメリットを製造にも転用(ラインがマルチパス化)出典: https://www.agilejapan.org/2016/image/Keynote1_ScrumIncAgileJapan80minJ.pdf
© Chatworkモジュールの設計行為
© Chatworkモジュール化のオペレータ(1/2)● デザイン階層より下位のモジュールが進化しうることが重要(下位システムの不確実性に強い)● 不変性と可変性を作り込む、一般的な設計行為＝モジュール化のオペレータがあるモジュールAデザインルールモジュールA1 モジュールA2モジュールA3デザインルールモジュールA3-1 モジュールA3-2不変性可変性
© Chatworkモジュール化のオペレータ(2/2)● モジュールを分離する● 古いモジュール設計を新しいモジュール設計に交換する● モジュールを削除する● それまでなかったモジュールを追加しシステムを拡大する● 「殻」を作って当初設計された以外のシステムで機能するモジュールにする転用● 複数のモジュールから共通要素を抽出し、階層中に新たなレベルのものを作る包括的デザインルールモジュールAデザインルール モジュールBモジュールBモジュールBモジュールG分割交換追加モジュールCD-E デザインルール削除モジュールDモジュールHモジュールEF デザインルールモジュールF-1モジュールF-2モジュールF-3抽出転用
© ChatworkFYI: モジュール型製品と統合型製品● モジュール型製品は機能に対してモジュールが1対1に紐付く● 統合型製品は機能に対して複数のモジュールが紐付く● ある機能のために複数のモジュールを調整しなければならない製品はモジュール型製品と呼ばない(ただし機能定義による)● モジュール性が高い＝機能とモジュールが対応付いているかが一つの尺度になる統合型製品モジュール型製品機能A 機能BモジュールA モジュールB機能AモジュールA1 モジュールA2 モジュールA3
© Chatworkモジュールの設計改善● デザインルールに従うかぎりモジュール単独の設計改善が可能(密なコミュニケーション)● デザインルール自体を改善するときは、モジュール設計チームどうしの合意によって実現可能(疎なコミュニケーション)● 組織構造がシステムに影響を与えていることがわかるデザインルールモジュールA モジュールB内部の改善は他のモジュールに影響を与えない。独自の設計改善が可能デザインルールはモジュール設計チーム間で合意することで修正・チューニングされていく密 疎ソフトウェアは建築に例えられることがあるが、同一モジュールの構築者と利用者が分離される、一般的なメタファではこれらの活動は説明しにくい機能A 機能B
© Chatwork分割単位としてのドメイン
© Chatwork販売管理ドメインドメイン駆動設計とは● ドメイン○ 問題や知識の領域● ドメインモデル○ ドメイン上の概念のこと。● ドメイン駆動設計○ ドメインの考え方に従うことでビジネスの変化にソフトウェアが対応できるようにすること○ ソフトウェア開発はドメインを中心にしなくても可能だが、それではビジネス変化に適応できない受注管理出荷管理売上管理請求管理入金管理
© Chatwork請求ドメイン商品カタログドメインドメインとＢＣの関係● 問題の領域○ ドメイン○ ビジネスの戦略課題を分析/明確化する領域● 解決の領域○ 境界づけられたコンテキスト(BoundedContext=BC)○ ビジネスの戦略課題を解決する領域○ 業務の単位在庫ドメイン需要予測BC発送ドメイン在庫BC注文ドメインEコマースBCEコマースの例(出典:実践ドメイン駆動設計)組織が扱う関心事はドメインというより境界づけられたコンテキスト
© ChatworkコンテキストAＢＣとシステム・チームを合わせる● 同じ業務ごとにチームとシステムを区切るとドメイン概念を把握しやすくなる● チーム間のコミュニケーションがそのままシステム設計に繋がる(異なる2つのモデルを変換するために共通の言語を使う＝公表された言語)● さまざまなソフトウェア活動の調整がしやすくなる。昔ながらのモジュールの改善と変わらないシステムチームコンテキストBシステムチームコミュニケーションドメインモデルドメインモデル隠されたデザイン・パラメータ 明示的なデザイン・ルールプロトコル/イベント公表された言語(PL)サービス境界
© ChatworkFYI:コンウェイの法則● システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう(引用:エンジニアリング組織論への招待)● 情報処理能力が高まる構造が必要。でなれば、組織構造の問題が知らず知らずにシステムに組み込まれていく…。● ”ソフトウェアは会話でできてる”○ AN AGILE WAY○ コーンウェイの法則汎用モジュール職人個別モジュール開発者個別モジュール開発者個別モジュール開発者
© Chatworkシステム分割の課題
© Chatwork適切な分割とは● システムを分割することでビジネスの変化に対応できるようになるが、その代償としてシステムは複雑化する● 逆に過剰に分割することで、変更に弱くなるもしくは保守性が下がる、可能性がある● 組織に対してサービスが多すぎる事例がよく観測される。こういった過剰な分割を検知・フィードバックする必要がある…適切な分割過剰な分割分割なし変更に強い/保守性が高い変更に弱い保守性が低い分割数N分割数0
© Chatworkモノリスは本当に問題か● モノリスにも利点がある○ すべてのコードが1つのプロジェクトに含まれる○ コードベースが単一であるため、テストやデプロイが容易である○ すべてのデータが利用可能で、サービス間で送信する必要はない○ インフラストラクチャセットが単一である● モジュラモノリスという選択肢○ Shopifyはいかにしてモジュラモノリスへ移行したか○ ECサイト運営のためのSaaS○ MSAの分散システムの複雑性が問題になり代替としてモジュラモノリスへ。モノリス→モジュラ・モノリス→マイクロサービスへの移行パスがあると示した
© Chatwork仕事の単位でモジュラー・モノリス化MSA文脈でのモジュラー・モノリス● 分割しすぎたら関心事単位でモジュール構成を見直す。関係が強いものは近くに、弱いものは遠くに。● 部分的にモジューラモノリスを採用する。サービスをモジュールに格下げして、同一BC内で管理できるように調整する仕事を無視して分割しすぎS1S2S3S4S5S6S7S8T1T2T3M1M2M3M4M5M6M7M8T1T2T3分割度の調整S1S2S3
© Chatwork新たな課題〜フロントエンド・モノリス〜● k8sなどでバックエンドをBC単位で分割しても、BFFを経由してフロントエンドモノリスを作ってしまう問題。● 解法の一つにMicro Frontendsがある(先行事例はSpotify, IKEAなど)。フロントエンドにもモジュラモノリスの発想が必要
© Chatworkまとめ● 複雑なものは分けて考える。人間の認識・管理能力には限界があるので複雑なものは分割するのが正攻法● マイクロサービスやモジュラーモノリスはその手段。これらの手法に共通して重要な設計要素は、モジュール性とビジネスの関心事(境界づけられたコンテキスト)● システムとチーム(組織)は人間のコミュニケーションを阻害しないように構成される必要がある(コンウェイの法則)● 分割すればよいという単純な発想では落とし穴(分散システムの難易度など)にはまるので注意。場合によってはモジュラー型から統合型への部分的な回帰も必要かもしれない
© Chatwork参考文献
© Chatworkご清聴ありがとうございました！
j5ik2o
seike460
beenos
kazuhitoyokoi
lanberb
teamlab
gmvalentino8
murabayashi
deresmos
uhooi
mfunaki
antonicg
ivargrimstad
akosma
lara
maltzj
hursman
chriscoyier
robhawkes
aarron
vanstee
speakerdeck
caitiem20
destraynor
mojombo