BASE大規模リアーキテクチャリング / base_rearchitecturing

by Satoshi Kawashima

Slide 1

Slide 1 text

©︎ 2012 - 2 0 2 2 BASE, Inc. モジュラモノリスを中⼼に据えたアーキテクチャ戦略について 1 BASE⼤規模リアーキテクチャリング

Slide 2

Slide 2 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 2 ⾃⼰紹介 BASE Inc. Tech Lead 川島慧

Slide 3

Slide 3 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 3 今⽇発表すること

Slide 4

Slide 4 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 4 BASEの中⻑期的なアーキテクチャ戦略について

Slide 5

Slide 5 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 5 背景

Slide 6

Slide 6 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 6 サービス概要 2012年12⽉よりネットショップ作成サービス「BASE」をサービス提供開始。今年でちょうど10年⽬に突⼊。

Slide 7

Slide 7 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 7 170万ショップを突破しました🎉 巣篭もり需要による成⻑もあり、ネットショップ開設数が170万ショップを突破しました。サービスの成⻑とともにエンジニアの⼈数も増えました。

Slide 8

Slide 8 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 1 2 3 4 8 コードベースの巨⼤化古いテクノロジーからの離脱トラフィック増加に対するスケーリングサービスの成⻑による課題⼈数増加によるアウトプット量の減少

Slide 9

Slide 9 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 9 個⼈の能⼒の総和が組織の能⼒にはならない例えば1.0の能⼒を持った個⼈が10⼈いても、組織の能⼒は10.0にはならない

Slide 10

Slide 10 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 10 今回⽬指している「アーキテクチャ」とは時間の経過によるビジネス‧テクノロジー‧組織の変化に耐えながら組織の⽣産性を⽀えつづける、事業競争⼒を得るためのシステムの構造

Slide 11

Slide 11 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 11 我々が中⻑期的に向き合っている課題

Slide 12

Slide 12 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 12 根本的な課題 ໨తෆ࣮֬ੑʢWhatͷෆ࣮֬ੑʣ ํ๏ෆ࣮֬ੑʢHowͷෆ࣮֬ੑʣ =>ͲΜͳϓϩμΫτΛ࡞Ε͹͍͍ͷ͔෼͔Βͳ͍ =>Ͳ͏΍ͬͯϓϩμΫτΛ࡞Ε͹͍͍ͷ͔෼͔Βͳ͍ ɾͲ͏͍͏ςΫϊϩδʔͰ࡞Ε͹͍͍ͷ͔ ɾͲ͏͍͏ϓϩηεͰ࡞Ε͹͍͍ͷ͔ ɾͲ͏͍͏૊৫ମ੍Ͱ࡞Ε͹͍͍ͷ͔

Slide 13

Slide 13 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 13 不確実性との向き合い⽅ • 経験主義：⾏動を起こしてその結果を観察し、そこから問題解決を⾏う考え⽅ • 「わからないことは調べるしか無い」という前提を置き、⾏動から不確実性を削減する主義 • 仮説思考：少ない情報から全体像を想定して、問題解決⽅法の獲得を早める考え⽅ •少ない証左から⼤胆な跳躍を起こして経験主義をさらに⽣産的なものにする思考法 • システム思考：多様な要素が集まった全体の関係性を捉える問題の真の原因を⾒つける考え⽅ • 上記の考えに則り、科学的アプローチによって問題の解決を⾏うすごい雑に⾔えば「PDCAを回せ！」ということ不確実性に⽴ち向かうには（たぶん）これくらいしか⽅法は無い

Slide 14

Slide 14 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 14 2つの学習ループを回す • ⽬的不確実性に向き合う：プロダクトのフィーチャを細かく出して、ユーザからのフィードバックから本当に求められているものを探し、適応的に⽅針を変える • ⽅法不確実性に向き合う：テクノロジー‧プロセスについて試⾏錯誤しながら、やってみた結果から適応的にやり⽅を変える • より良いテクノロジー‧プロセスを追求することで、最終的にプロダクトのPDCAを⼒強く⽀えるプロダクトの PDCA テクノロジー‧ プロセスの PDCA プロダクトオーナー開発組織 14

Slide 15

Slide 15 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 15 スクラムの解決モデルがわかりやすい • スクラムはプロセスを通して「検査と適応」が⾏われるようにデザインされたプロセスフレームワーク • 定期的なスクラムイベントを通してプロダクトの学習ループとプロセスの学習ループがそれぞれ実⾏される Ҿ༻ݩɿΤϯδχΞϦϯά૊৫࿦΁ͷট଴

Slide 16

Slide 16 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 16 Accelerate本から⾒る⾼パフォーマンス企業 • 事業競争⼒とデリバリパフォーマンスには正の相関があると証明している • なぜならば「ユーザのフィードバックを素早く得られるから」 • ⾼パフォーマンスな組織はソフトウェアデリバリの24のケイパビリティ（組織全体として保持する能⼒）が⾼いことを明らかにした

Slide 17

Slide 17 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 17 ソフトウェアデリバリの24のケイパビリティ • 1. 本番環境の全ての成果物をバージョン管理システムで管理 • 2. デプロイメントプロセスの⾃動化 • 3. 継続的インテグレーションの実装 • 4. トランクベースの開発⼿法の実践 • 5. テストの⾃動化 • 6. テストデータの管理 • 7. 情報セキュリティのシフトレフト • 8. 継続的デリバリ（CD）の実践 • 9. 疎結合のアーキテクチャ • 10. チームへのツール選択権限の付与 • 11. 顧客フィードバックの収集と活⽤ • 12. 全業務プロセスの作業フローの可視化 • 13. 作業の細分化 • 14. チームによる実験の奨励‧実現 • 15. 負担の軽い変更承認プロセス • 16. 事業上の意思決定における、アプリケーションとインフラの監視結果の活⽤ • 17. システムの整合性のプロアクティブ（予防的）なチェック • 18 . WIP制限によるプロセス改善と作業管理 • 19. 作業の可視化による、品質の監視とチーム内コミュニケーションの促進 • 20. 創造的な組織⽂化の育成 • 21. 学びの奨励と⽀援 • 22. チーム間の協働の⽀援と促進 • 23. 有意義な仕事を可能にするツール等の資源の提供 • 24. 改善を促進するリーダーシップの実現や⽀援

Slide 18

Slide 18 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 18 「PDCAを回せ」から振り返るAccelerate本ケイパビリティは仕組みや⽂化など多⾓的な内容が含まれているが、その中には「組織的学習の実現」という要素が含まれていると解釈している。チームがなるべく低いコストでテクノロジー‧プロセスについて試⾏錯誤できる環境を整えることが、最終的に事業のパフォーマンスに還元される、という意味であると捉えている。

Slide 19

Slide 19 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 19 組織的学習を実現する難しさ

Slide 20

Slide 20 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 1 2 3 20 チームの作業の独⽴チームに実験を奨励するチームの持続組織的学習を実現する難しさ

Slide 21

Slide 21 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 21 1. チームの作業の独⽴例えばあらゆる構造が密結合となったモノリシックなシステムを100⼈で修正すると作業の衝突や、デプロイ作業の調整などが⼤量に発⽣する。分業できない分業できる

Slide 22

Slide 22 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 22 1. チームの作業の独⽴たった1つの部品で作られた⾞（実在するかは不明だが）を複数⼈で分業して作ることは出来ない。複数⼈でモノを作る場合、モノの構造が分業可能な単位を規定してしまう法則性がある。モノリシックなシステムの場合、分業が難しい。分業できない分業できる

Slide 23

Slide 23 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 23 1. チームの作業の独⽴ Accelerate本では「疎結合のアーキテクチャ」というケイパビリティで整理されていた。チームが他部署との調整を要さずに、どの程度独⽴して作業を完遂できるか（＝分業が可能か）というケイパビリティだった。アーキテクチャがデリバリのパフォーマンスに制約を与えてしまう前提があるなかで、どれだけそれを抑えるアーキテクチャにできるか。

Slide 24

Slide 24 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 24 2. チームに実験の奨励をするテクノロジー‧プロセスのPDCAを回す上で、より効果的に学習をしてもらうために実験の奨励をする。チーム外の⼈々との調整なしに新たなアイディアを試したり、⼤幅なシステムの変更を可能にする。ツール選択の権限を付与する。 Accelerate本では「チームによる実験の奨励‧実現」「チームへのツール選択権限の付与」というケイパビリティで整理していた。

Slide 25

Slide 25 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 25 実験を奨励することは難しい例えばモノリシックなシステムを100⼈でメンテナンスする場合、誰かが特異な実装を⾏うと「そんなものを俺はメンテナンスできない」という拒絶反応が⽣まれやすい。あるいは、それを嫌って修正をやり切ったり、完全にドキュメント化したり、合意をとったり、完璧に全てをやり切らないと何もやってはいけないかのような、事態を硬直化させる環境圧⼒が働く。

Slide 26

Slide 26 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 26 「試⾏錯誤」という⾔葉の裏にあるもの試⾏錯誤は綿密に計画⽴てた⾏動ではなく、中間状態を許容したチャレンジというニュアンスが強い。チャレンジの合意を取ることは⼈数が多いほど難しく、相互に深いコミュニケーションが取れるようなスモールチームが望ましい。

Slide 27

Slide 27 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 27 3. チームの持続実際にPDCAを回して学習をするチームが持続的でなければ、学習によって得た知識を定着させる先が存在しないことになるので組織的学習が実現しづらい。知識はチームに宿る。学習とは持続した活動なので、プロジェクトごとにチームが解散するような組織体制ならば、得た知識を次回以降の活動に活かすこともないまま失われる。

Slide 28

Slide 28 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 28 「チーム」とは学習の単位ここでいう「チーム」とは、特定のドメイン領域に責任を持ち、その領域におけるプロダクトとテクノロジー‧ プロセスについて学習を⾏う単位として扱っている。「チーム」を定義し、それを持続させるために、組織図を更新する必要がある。

Slide 29

Slide 29 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 29 「組織的学習の実現」から⾒る「アーキテクチャ」の意味持続的に組織的学習を実現する上では組織図の更新だけでは⾜りず、システムの構造が我々の作業の質をも決定してしまう。アーキテクチャがそれを決定する。 ࣄۀ ૊৫ ΞʔΩςΫνϟ ࣄۀڝ૪ྗΛ֫ಘ͢ΔͨΊʹ ࣋ଓతͳ૊৫తֶशΛ࣮ݱ͢Δ ֶश୯ҐΛఆٛ͠ɺ νʔϜΛ࣋ଓͤ͞Δ νʔϜ͕ͳΔ΂͘ಠཱͨ͠ ࡞ۀΛՄೳʹ͢Δ ࡋྔͷେ͖ͳࢼߦࡨޡΛՄೳʹ͢Δ ࠓճͷࢿྉͰݴٴ͢ΔྖҬ

Slide 30

Slide 30 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 30 https://speakerdeck.com/tcnksm/kai-fa-zhe-xiang-kefalseji-pan-wotukuru?slide=14

Slide 31

Slide 31 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 31 マイクロサービスアーキテクチャの検討

Slide 32

Slide 32 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 32 「組織的学習の実現」から⾒るMSA これまでに記述してきた課題を解決するうえでマイクロサービスアーキテクチャ（以下MSA）は極めて理想的な解決策であると考えている。スモールチームがそれぞれにマイクロサービスを保有することで分散統治された組織へ変わることが出来る。

Slide 33

Slide 33 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 33 MSA化の検討社内では肯定的な意⾒がほぼ無かった。 MSAによるメリットよりも、複雑さによるオーバーヘッドのほうが⼤きいイメージを持つ⼈が多かった。もっとエンジニアの⼈数が多ければ分かるが、今のBASE の規模ではまだMSAによるメリットを享受するには⼩さすぎるという話になった。

Slide 34

Slide 34 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 34 MSAの複雑さ • データの⼀貫性を確保する難しさ • 可観測性の難しさ • 管理するインフラストラクチャやリポジトリの増加 • マイクロサービス間の依存関係管理 • サーキットブレーカーなどの障害対策 • サービス間通信のレイテンシ • 分割境界線の難しさ

Slide 35

Slide 35 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 35 MSA化に失敗したリスクは⼤きいマイクロサービス化に失敗して「分散したモノリス (distributed monolith)」というアンチパターンに陥るケースをよく聞く。境界線をまたいだ修正はモノリスのときよりも⼤きなオーバーヘッドがかかり、変更に苦痛が伴うシステムになってしまう。

Slide 36

Slide 36 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 36 いきなりMSAを始めることは原著も否定的 MSAへの移⾏は少しずつ⼩さく進めることを強く勧めている。おそらく最初は間違えることになるとも予⾔している。

Slide 37

Slide 37 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 37 Martin Fowlerの「Monolith First」 MSAの問題としてサービス間に適切で安定した境界を⾒つけた場合にのみうまく機能するということ。サービス間のリファクタリングはモノリスよりも遥かに困難になる。 https://martinfowler.com/bliki/MonolithFirst.html

Slide 38

Slide 38 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 38 モノリスからマイクロサービスへの書籍サービス境界の誤りは⾼くつく。ドメインを深く理解しないまま分割すると、サービスをまたぐ変更の数が増えたりする。あるいはMSAによって何を達成しようとしているのか明確に把握していない場合にも、MSAは悪いアイディアである。

Slide 39

Slide 39 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 39 MSAは難しい分散システム特有の難しさもあるが、なにより境界線の定義が難しい懸念があった。マルチプロダクトな企業はプロダクト単位で分けやすいが、BASEはほぼシングルプロダクトな企業なので、境界線の定義は難しかった。

Slide 40

Slide 40 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 40 MSA以外の選択肢は無いのか？組織的学習の実現をするうえでMSAは理想的な解ではあるが、本当にMSA以外の選択肢はないのか？ MSAほどの⾼い分離でなくてもいいし、境界線は完全に定義しきれない状態でも着⼿できる⽅法はないのか？

Slide 41

Slide 41 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 41 モジュラモノリス

Slide 42

Slide 42 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 42 モジュラモノリスとはなにかモジュールによって構造化されたモノリス。モノリス同様、単⼀リポジトリ‧単⼀デプロイを維持するが、内部のソフトウェア部品はモジュールという単位で分割された状態。

Slide 43

Slide 43 text

©︎ 2012 - 2 0 2 2 BASE, Inc. Microservices 43 図で⽐較するマイクロサービスとモジュラモノリス A P I G a t e w a y Microservice Microservice Microservice Microservice HTTPͳͲɺಛఆͷ࣮૷ٕज़ʹ ґଘ͠ͳ͍ϓϩηεؒ௨৴ ಛఆͷϚΠΫϩαʔϏε ʹશݖݶΛ༗ͨ͠νʔϜ ʹΑΔ։ൃɾӡ༻ શϚΠΫϩαʔϏεڞ௨ͷ લॲཧ Client

Slide 44

Slide 44 text

©︎ 2012 - 2 0 2 2 BASE, Inc. ModularMonolith 44 図で⽐較するマイクロサービスとモジュラモノリス A P I G a t e w a y Module Module Module Module ಛఆͷϞδϡʔϧʹશݖ ݶΛ༗ͨ͠νʔϜʹΑΔ ։ൃɾӡ༻ Ϟδϡʔϧؒ௨৴͕ඞཁͳ৔߹ɺ WebAPIίʔϧͰ͸ͳ͘PHPϝιου ίʔϧʹΑΔݺͼग़͠ʮ΋ʯՄೳ શϞδϡʔϧڞ௨ͷલॲཧ ͸ϑϨʔϜϫʔΫͷ MiddlewareͳͲͰ࣮ݱՄೳ Client

Slide 45

Slide 45 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 45 モジュールとはなにかソフトウェア開発⼀般の「モジュール」とは単純に⾔ってしまえばソフトウェアを構成する個々の部品のこと。この資料における「モジュール」はモジュラモノリスを構成する部品であり、ある程度独⽴して作業可能な単位として扱う。社内の命名はBaseIncModuleとなっている。

Slide 46

Slide 46 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 46 BaseIncModuleとはビジネスドメインを基準に作られ、ビジネス価値を⽀えるソフトウェア上の枠組み。ビジネス上関⼼の強いものが同⼀モジュールに集まり、弱いものは別モジュールへ分かれる。直接的な⾔い⽅をすれば、DDDにおける境界づけられたコンテキストと同⼀の単位として作られる。 Microservice Checkout ίϯςΩετ Module Checkout ίϯςΩετ

Slide 47

Slide 47 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 47 クリーンアーキテクチャをベースに作成している Application Domain 内側2層を「BaseIncModule」と呼んでいる ※BASEͰ͸CleanArchitectureΛ3૚ͱͯ͠࡞͍ͬͯΔ Gateways

Slide 48

Slide 48 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 48 BASEのモジュラモノリスを図⽰するとこう ModularMonolith A P I G a t e w a y Module Module Module Module ʹ

Slide 49

Slide 49 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 49 ディレクトリ構造 Ϟδϡʔϧஔ͖৔ ϑϨʔϜϫʔΫ্ͷsrcσΟϨΫτϦ ֤ϞδϡʔϧͷInterfaceͷٕज़త࣮૷ ApplicationϨΠϠͱDomainϨΠϠʢ֤Ϟδϡʔϧʹଘࡏ͢Δʣ Ϟδϡʔϧ͝ͱʹςετ͕͋ΔʢDBͳͲͷٕज़ৄࡉʹ͸ґଘ͍ͯ͠ͳ͍ʣ Ϟδϡʔϧ Ϟδϡʔϧ͝ͱʹಠࣗͷίʔσΟϯάن໿΍PHPStanʹΑΔνΣοΫΛ͍ͯ͠Δ

Slide 50

Slide 50 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 50 モジュール間の関係モジュールごとにパブリックAPIを⽤意し、外部からはそこにしかアクセスさせないことで、内部の詳細を隠蔽する。フレームワークのControllerからもモジュールにはパブリックAPIからしかアクセスできないし、モジュール間の通信もパブリックAPIにしかアクセスさせない。

Slide 51

Slide 51 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 51 図で⽐較するマイクロサービスとモジュラモノリス Module Controller Command Module PublicAPI PublicAPI PublicAPI PublicAPI Entity ValueObject Repository DomainService Module಺෦ͷϩδοΫʹ͸Moduleͷެ։ I/FΛ௨͔ͯ͠͠ΞΫηεͰ͖ͳ͍ Moduleಉ࢜ͷ௨৴Λߦ͏৔߹Ͱ΋ɺ PublicAPIΛ௨͔ͯ͠͠ΞΫηεͰ͖ͳ͍ Entity ValueObject Repository DomainService

Slide 52

Slide 52 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 52 依存ルール複数の依存ルールがある。 deptracというツールを使⽤して依存ルールの違反がないかをCIでチェックしている。 deptrac: https://github.com/qossmic/deptrac

Slide 53

Slide 53 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 53 依存ルール • クリーンアーキテクチャとしてのルール • レイヤ間の依存の⽅向が内側のみに向かう • モジュラモノリスとしてのルール • モジュール外部からはモジュール内部に直接依存できず、パブリックAPIにしか依存できない • モジュール間で循環依存があってはならない • モジュール内部の独⾃ルール • チームで独⾃のルールがあれば⾃由に設定しても良い

Slide 54

Slide 54 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 54 MSAと同様のメリットモジュールが作業分割の単位になる。モジュール内部を隠蔽することでモジュールの設計の独⽴性を担保でき、各チームに委ねることが出来る。

Slide 55

Slide 55 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 55 MSAと⽐較したメリット • 単⼀リポジトリなのでコード検索‧修正が容易 • 単⼀インフラなので分散システム特有の複雑さを避けやすい • 規律の崩壊を防ぎやすい • モジュールを横断した修正が容易 • モジュール境界線⾃体の⾒直しが容易 • 漸進的にマイクロサービスに向かえる（詳細は後の章）

Slide 56

Slide 56 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 56 モジュール境界線の修正が容易 ྫ͑͹ϚΠΫϩαʔϏεͰޙํޓ׵ੑͷͳ͍APIͷߋ৽͕ൃੜͨ͠৔߹ͷमਖ਼ྫ Microservice Microservice 1. ݺͼग़͠ଆͰࣄલʹޓ׵ੑ ͕ͳ͘ͳΔՕॴͷमਖ਼Λ͢Δ ※APIόʔδϣχϯάΛ͠ͳ͍৔߹ 2. APIΛߋ৽͢Δ 3. ৽͍͠࢓༷ʹԊͬͨमਖ਼Λߦ͏ APIΞΫηε ModularMonolith Module Module 1. ྆ऀΛҰ౓ʹमਖ਼ͯ͠ 1ճͷσϓϩΠͰ׬ྃ APIΞΫηε モジュール境界線の⼿戻りを低いコストで実現できる安定した境界線を⼿探りで探しやすい

Slide 57

Slide 57 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 57 MSAと⽐較したデメリットモジュール境界や依存関係のルールを確実に守らないといけない単⼀インフラなのでテクノロジー選択の裁量は低い＝＞静的解析ツールでだいたいは実現可能単⼀デプロイなのでデプロイの交通渋滞が発⽣する＝＞マイクロサービスでも全チームが好き勝⼿にプログラミング⾔語とか変えると基盤技術構築できない問題があるため、完全⾃由にさせてる企業は実は少ない認識＝＞解決案なし

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 60 漸進的にマイクロサービスへ向かっていく漸進的にマイクロサービスへ向かっていけることもモジュラモノリスのメリットとなる。現⾏のアーキテクチャからモジュラモノリスを経由することで、漸進的にマイクロサービス化を実現可能にする。

Slide 61

Slide 61 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 61 漸進的にマイクロサービスへ向かっていく BaseIncModuleは実⾏環境に依存していない＝実⾏環境を変更可能。システム上の移動可能な単位として扱う。 ※PHPͱͦͷόʔδϣϯʹ͸ґଘ͍ͯ͠ΔͷͰʮ࣮ߦ؀ڥʹґଘ͕ແ͍ʯͱݴ͍੾Δͷʹޠฐ͸͋Δ

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 66 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module ࣮ߦ؀ڥඇґଘͳͷͰ ࣮ߦ؀ڥΛมߋͰ͖Δ ϑϨʔϜϫʔΫ΋มߋͰ͖Δ

Slide 67

Slide 67 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 67 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module Web API Call ৽ΞϓϦέʔγϣϯͷϩδοΫ ΛWebAPI CallͰݺͼग़͢ ※DBτϥϯβΫγϣϯ͸෼͔Εͯ͠·͏

Slide 68

Slide 68 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 68 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module Web API Call logic logic logic ϚΠΫϩαʔϏεΑΓ͸ ௿͍ίετͰڥքઢΛಈ͔ͤΔ

Slide 69

Slide 69 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 69 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module Web API Call ڥքઢͷ҆ఆ

Slide 70

Slide 70 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 70 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module Web API Call DBトランザクション分離 PHPプロセス分離 ※DBτϥϯβΫγϣϯͷ෼཭͸ࣄલʹઓུతʹ΍ΕΔͳΒ΍ͬͨ΄͏͕ྑ͍ CAPఆཧʹ΋͋Δ௨Γɺ෼ࢄγεςϜԽ͢Δͱ σʔλͷӬଓԽ͸CAPͷ͍ͣΕ͔͕େ͖͘ଛͳΘΕΔ

Slide 71

Slide 71 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 71 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーションモジュラモノリス module module module module module module Web API Call DB෼཭

Slide 72

Slide 72 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 72 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーション Web API Call A P I G a t e w a y Listing module Checkout module Order module Payment module CRM module

Slide 73

Slide 73 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 現⾏からマイクロサービスへ向かう⼿順現⾏アプリケーション Web API Call A P I G a t e w a y Listing Checkout module Order module Payment module CRM module PHP製 module Go製 module module チームごとのテクノロジーマネジメント各領域がさらに複雑化したときも、分割境界として今後もモジュールは増え続ける

Slide 74

Slide 74 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 74 移⾏段階を類型化移⾏初期移⾏中期移⾏後期適切で安定的な境界線を⼿探りで⾒つけようとしている段階。境界線を移動させるコストが低めのモジュラモノリス上で⼿戻りしながら妥当な境界線を発⾒しようと模索している。物理的な分解が始まり、本格的なマイクロサービスへ。⼀部の境界線がある程度安定している状態。トランザクション分離やDB分離など、モジュールの切り離しが始まる。モジュール間の通信も PHPメソッドコールからIPC経由へ。モジュラモノリス module mo modu module module モジュラモノリス module module module module module module Order module Payment module CRM module 74 ※CAPఆཧʹ΋͋Δ௨Γɺ෼཭͢ΔͱCAPͷ͍ͣΕ͔͕େ͖͘ଛͳΘΕΔɻ PHPϝιουίʔϧͱIPCܦ༝ͷݺͼग़͠͸ܾͯ͠౳ՁͰ͸ͳ͍ɻ

Slide 75

Slide 75 text

Slide 76

Slide 76 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 76 BASEの中⻑期的なアーキテクチャ戦略とはアーキテクチャを「時間の経過によるビジネス‧テクノロジー‧組織の変化に耐えながら組織の⽣産性を⽀えつづける、事業競争⼒を得るためのシステムの構造」と定義した。

Slide 77

Slide 77 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 77 BASEの中⻑期的なアーキテクチャ戦略とは中⻑期的に事業競争⼒を得るには、組織的学習の持続的な実現が必要であるとした。アーキテクチャが分業の質を制約してしまう前提の中で、なるべくこれを実現できるようなアーキテクチャが望ましい。

Slide 78

Slide 78 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 78 BASEの中⻑期的なアーキテクチャ戦略とはビジネスを⽀えるソフトウェア上の枠組みを「モジュール」という名前でパッケージングを⾏う。モジュールを分業可能な単位として扱い、各チームに委任してそれぞれにPDCAを回してもらうことで組織的学習を実現する。

Slide 79

Slide 79 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 79 BASEの中⻑期的なアーキテクチャ戦略とは適切で安定したモジュール境界線はいきなり⾒つからないことを前提とする。モジュールの境界線はモジュラモノリス上で⼿戻りしながら調整することで、適切で安定した境界線を⼿探りで探す。

Slide 80

Slide 80 text

Slide 81

Slide 81 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 81 BASEの中⻑期的なアーキテクチャ戦略とは我々は全体システムにおける最終形を定義しない。それは未来のビジネス‧テクノロジー‧組織の変化に応じてシステムに対する要求が変わるため、最適解が変わり続けることを前提とする。

Slide 82

Slide 82 text

©︎ 2012 - 2 0 2 2 BASE, Inc. 82 BASEの中⻑期的なアーキテクチャ戦略とはアーキテクチャは従来「後から変更することが難しい部分」とされてきた。モジュールをアーキテクチャにおける可動域にすることで、その時点での要求をなるべく満たすような形態への変更可能とすることで、漸進的に進化しつづけることが可能なアーキテクチャであることを⽬指す。