Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

© Chatwork MSA以前の問題とは

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

© Chatwork MSAでどう変わるのか

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

© Chatwork システム分割の課題

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

© 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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

© Chatwork 参考文献

Slide 41

Slide 41 text

© Chatwork ご清聴ありがとうございました！

Slide 42

Slide 42 text

No content