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

Transcript

1. ©︎ 2012 - 2 0 2 2 BASE, Inc. モジュラモノリスを中⼼に据えたアーキテクチャ戦略について 1 BASE⼤規模リアーキテクチャリング
2. ©︎ 2012 - 2 0 2 2 BASE, Inc. 2 ⾃⼰紹介 BASE Inc. Tech Lead 川島慧
3. ©︎ 2012 - 2 0 2 2 BASE, Inc. 3 今⽇発表すること
4. ©︎ 2012 - 2 0 2 2 BASE, Inc. 4 BASEの 中⻑期的なアーキテクチャ戦略について
5. ©︎ 2012 - 2 0 2 2 BASE, Inc. 5 背景
6. ©︎ 2012 - 2 0 2 2 BASE, Inc. 6 サービス概要 2012年12⽉よりネットショップ作 成サービス「BASE」をサービス提 供開始。 今年でちょうど10年⽬に突⼊。
7. ©︎ 2012 - 2 0 2 2 BASE, Inc. 7 170万ショップを突破しました🎉 巣篭もり需要による成⻑も あり、ネットショップ開設 数が170万ショップを突破 しました。 サービスの成⻑とともにエ ンジニアの⼈数も増えまし た。
8. ©︎ 2012 - 2 0 2 2 BASE, Inc. 1 2 3 4 8 コードベースの巨⼤化 古いテクノロジーからの離脱 トラフィック増加に対するスケーリング サービスの成⻑による課題 ⼈数増加によるアウトプット量の減少
9. ©︎ 2012 - 2 0 2 2 BASE, Inc. 9 個⼈の能⼒の総和が組織の能⼒にはならない 例えば1.0の能⼒を持った個⼈が10⼈いても、組織の能⼒ は10.0にはならない
10. ©︎ 2012 - 2 0 2 2 BASE, Inc. 10 今回⽬指している「アーキテクチャ」とは 時間の経過によるビジネス‧テクノロジー‧組織の変化に 耐えながら組織の⽣産性を⽀えつづける、事業競争⼒を 得るためのシステムの構造
11. ©︎ 2012 - 2 0 2 2 BASE, Inc. 11 我々が中⻑期的に 向き合っている課題
12. ©︎ 2012 - 2 0 2 2 BASE, Inc. 12 根本的な課題 ໨తෆ࣮֬ੑʢWhatͷෆ࣮֬ੑʣ ํ๏ෆ࣮֬ੑʢHowͷෆ࣮֬ੑʣ =>ͲΜͳϓϩμΫτΛ࡞Ε͹͍͍ͷ͔෼͔Βͳ͍ =>Ͳ͏΍ͬͯϓϩμΫτΛ࡞Ε͹͍͍ͷ͔෼͔Βͳ͍ ɾͲ͏͍͏ςΫϊϩδʔͰ࡞Ε͹͍͍ͷ͔ ɾͲ͏͍͏ϓϩηεͰ࡞Ε͹͍͍ͷ͔ ɾͲ͏͍͏૊৫ମ੍Ͱ࡞Ε͹͍͍ͷ͔
13. ©︎ 2012 - 2 0 2 2 BASE, Inc. 13 不確実性との向き合い⽅ • 経験主義：⾏動を起こしてその結果を観察し、そこから問題解決を⾏う考え⽅ • 「わからないことは調べるしか無い」という前提を置き、⾏動から不確実性を削減する主義 • 仮説思考：少ない情報から全体像を想定して、問題解決⽅法の獲得を早める考え⽅ •少ない証左から⼤胆な跳躍を起こして経験主義をさらに⽣産的なものにする思考法 • システム思考：多様な要素が集まった全体の関係性を捉える問題の真の原因を⾒つける考え⽅ • 上記の考えに則り、科学的アプローチによって問題の解決を⾏う すごい雑に⾔えば 「PDCAを回せ！」ということ 不確実性に⽴ち向かうには（たぶん）これくらいしか⽅法は無い
14. ©︎ 2012 - 2 0 2 2 BASE, Inc. 14 2つの学習ループを回す • ⽬的不確実性に向き合う：プロダクトのフィーチャを細かく出して、ユーザからのフィードバック から本当に求められているものを探し、適応的に⽅針を変える • ⽅法不確実性に向き合う：テクノロジー‧プロセスについて試⾏錯誤しながら、やってみた結果か ら適応的にやり⽅を変える • より良いテクノロジー‧プロセスを追求することで、最終的にプロダクトのPDCAを⼒強く⽀える プロダクトの PDCA テクノロジー‧ プロセスの PDCA プロダクトオーナー 開発組織 14
15. ©︎ 2012 - 2 0 2 2 BASE, Inc. 15 スクラムの解決モデルがわかりやすい • スクラムはプロセスを通して「検査と適応」が⾏われるようにデザインされたプロセスフレーム ワーク • 定期的なスクラムイベントを通してプロダクトの学習ループとプロセスの学習ループがそれぞれ実 ⾏される Ҿ༻ݩɿΤϯδχΞϦϯά૊৫࿦΁ͷট଴
16. ©︎ 2012 - 2 0 2 2 BASE, Inc. 16 Accelerate本から⾒る⾼パフォーマンス企業 • 事業競争⼒とデリバリパフォーマンスには正 の相関があると証明している • なぜならば「ユーザのフィードバックを素早 く得られるから」 • ⾼パフォーマンスな組織はソフトウェアデリ バリの24のケイパビリティ（組織全体として 保持する能⼒）が⾼いことを明らかにした
17. ©︎ 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. 改善を促進するリーダーシップの実現や⽀援
18. ©︎ 2012 - 2 0 2 2 BASE, Inc. 18 「PDCAを回せ」から振り返るAccelerate本 ケイパビリティは仕組みや⽂化など多⾓的な内容が含まれ ているが、その中には「組織的学習の実現」という要素 が含まれていると解釈している。 チームがなるべく低いコストでテクノロジー‧プロセスに ついて試⾏錯誤できる環境を整えることが、最終的に事 業のパフォーマンスに還元される、という意味であると 捉えている。
19. ©︎ 2012 - 2 0 2 2 BASE, Inc. 19 組織的学習を 実現する難しさ
20. ©︎ 2012 - 2 0 2 2 BASE, Inc. 1 2 3 20 チームの作業の独⽴ チームに実験を奨励する チームの持続 組織的学習を実現する難しさ
21. ©︎ 2012 - 2 0 2 2 BASE, Inc. 21 1. チームの作業の独⽴ 例えばあらゆる構造が密結合となったモノリシックなシ ステムを100⼈で修正すると作業の衝突や、デプロイ作業 の調整などが⼤量に発⽣する。 分業できない 分業できる
22. ©︎ 2012 - 2 0 2 2 BASE, Inc. 22 1. チームの作業の独⽴ たった1つの部品で作られた⾞（実在するかは不明だが）を 複数⼈で分業して作ることは出来ない。複数⼈でモノを作る 場合、モノの構造が分業可能な単位を規定してしまう法則性 がある。モノリシックなシステムの場合、分業が難しい。 分業できない 分業できる
23. ©︎ 2012 - 2 0 2 2 BASE, Inc. 23 1. チームの作業の独⽴ Accelerate本では「疎結合のアーキテクチャ」というケ イパビリティで整理されていた。チームが他部署との調整 を要さずに、どの程度独⽴して作業を完遂できるか（＝ 分業が可能か）というケイパビリティだった。 アーキテクチャがデリバリのパフォーマンスに制約を与 えてしまう前提があるなかで、どれだけそれを抑えるアー キテクチャにできるか。
24. ©︎ 2012 - 2 0 2 2 BASE, Inc. 24 2. チームに実験の奨励をする テクノロジー‧プロセスのPDCAを回す上で、より効果的 に学習をしてもらうために実験の奨励をする。 チーム外の⼈々との調整なしに新たなアイディアを試した り、⼤幅なシステムの変更を可能にする。ツール選択の 権限を付与する。 Accelerate本では「チームによる実験の奨励‧実現」 「チームへのツール選択権限の付与」というケイパビリ ティで整理していた。
25. ©︎ 2012 - 2 0 2 2 BASE, Inc. 25 実験を奨励することは難しい 例えばモノリシックなシステムを100⼈でメンテナンスす る場合、誰かが特異な実装を⾏うと「そんなものを俺は メンテナンスできない」という拒絶反応が⽣まれやす い。 あるいは、それを嫌って修正をやり切ったり、完全にド キュメント化したり、合意をとったり、完璧に全てをやり 切らないと何もやってはいけないかのような、事態を硬 直化させる環境圧⼒が働く。
26. ©︎ 2012 - 2 0 2 2 BASE, Inc. 26 「試⾏錯誤」という⾔葉の裏にあるもの 試⾏錯誤は綿密に計画⽴てた⾏動ではなく、中間状態を 許容したチャレンジというニュアンスが強い。 チャレンジの合意を取ることは⼈数が多いほど難しく、 相互に深いコミュニケーションが取れるようなスモール チームが望ましい。
27. ©︎ 2012 - 2 0 2 2 BASE, Inc. 27 3. チームの持続 実際にPDCAを回して学習をするチームが持続的でなけれ ば、学習によって得た知識を定着させる先が存在しない ことになるので組織的学習が実現しづらい。知識はチーム に宿る。 学習とは持続した活動なので、プロジェクトごとにチー ムが解散するような組織体制ならば、得た知識を次回以 降の活動に活かすこともないまま失われる。
28. ©︎ 2012 - 2 0 2 2 BASE, Inc. 28 「チーム」とは学習の単位 ここでいう「チーム」とは、特定のドメイン領域に責任 を持ち、その領域におけるプロダクトとテクノロジー‧ プロセスについて学習を⾏う単位として扱っている。 「チーム」を定義し、それを持続させるために、組織図 を更新する必要がある。
29. ©︎ 2012 - 2 0 2 2 BASE, Inc. 29 「組織的学習の実現」から⾒る「アーキテクチャ」の意味 持続的に組織的学習を実現する上では組織図の更新だけ では⾜りず、システムの構造が我々の作業の質をも決定し てしまう。アーキテクチャがそれを決定する。 ࣄۀ ૊৫ ΞʔΩςΫνϟ ࣄۀڝ૪ྗΛ֫ಘ͢ΔͨΊʹ ࣋ଓతͳ૊৫తֶशΛ࣮ݱ͢Δ ֶश୯ҐΛఆٛ͠ɺ νʔϜΛ࣋ଓͤ͞Δ νʔϜ͕ͳΔ΂͘ಠཱͨ͠ ࡞ۀΛՄೳʹ͢Δ ࡋྔͷେ͖ͳࢼߦࡨޡΛՄೳʹ͢Δ ࠓճͷࢿྉͰݴٴ͢ΔྖҬ
30. ©︎ 2012 - 2 0 2 2 BASE, Inc. 30 https://speakerdeck.com/tcnksm/kai-fa-zhe-xiang-kefalseji-pan-wotukuru?slide=14
31. ©︎ 2012 - 2 0 2 2 BASE, Inc. 31 マイクロサービス アーキテクチャの検討
32. ©︎ 2012 - 2 0 2 2 BASE, Inc. 32 「組織的学習の実現」から⾒るMSA これまでに記述してきた課題を解決するうえでマイクロ サービスアーキテクチャ（以下MSA）は極めて理想的な 解決策であると考えている。 スモールチームがそれぞれにマイクロサービスを保有す ることで分散統治された組織へ変わることが出来る。
33. ©︎ 2012 - 2 0 2 2 BASE, Inc. 33 MSA化の検討 社内では肯定的な意⾒がほぼ無かった。 MSAによるメリットよりも、複雑さによるオーバーヘッ ドのほうが⼤きいイメージを持つ⼈が多かった。 もっとエンジニアの⼈数が多ければ分かるが、今のBASE の規模ではまだMSAによるメリットを享受するには⼩さ すぎるという話になった。
34. ©︎ 2012 - 2 0 2 2 BASE, Inc. 34 MSAの複雑さ • データの⼀貫性を確保する難しさ • 可観測性の難しさ • 管理するインフラストラクチャやリポジトリの増加 • マイクロサービス間の依存関係管理 • サーキットブレーカーなどの障害対策 • サービス間通信のレイテンシ • 分割境界線の難しさ
35. ©︎ 2012 - 2 0 2 2 BASE, Inc. 35 MSA化に失敗したリスクは⼤きい マイクロサービス化に失敗して「分散したモノリス (distributed monolith)」というアンチパターンに陥る ケースをよく聞く。 境界線をまたいだ修正はモノリスのときよりも⼤きな オーバーヘッドがかかり、変更に苦痛が伴うシステムに なってしまう。
36. ©︎ 2012 - 2 0 2 2 BASE, Inc. 36 いきなりMSAを始めることは原著も否定的 MSAへの移⾏は少しずつ⼩さく進め ることを強く勧めている。 おそらく最初は間違えることになる とも予⾔している。
37. ©︎ 2012 - 2 0 2 2 BASE, Inc. 37 Martin Fowlerの「Monolith First」 MSAの問題としてサービス間に適切で 安定した境界を⾒つけた場合にのみう まく機能するということ。 サービス間のリファクタリングはモノ リスよりも遥かに困難になる。 https://martinfowler.com/bliki/MonolithFirst.html
38. ©︎ 2012 - 2 0 2 2 BASE, Inc. 38 モノリスからマイクロサービスへの書籍 サービス境界の誤りは⾼くつく。ドメ インを深く理解しないまま分割する と、サービスをまたぐ変更の数が増え たりする。 あるいはMSAによって何を達成しよう としているのか明確に把握していない 場合にも、MSAは悪いアイディアであ る。
39. ©︎ 2012 - 2 0 2 2 BASE, Inc. 39 MSAは難しい 分散システム特有の難しさもあるが、なにより境界線の 定義が難しい懸念があった。 マルチプロダクトな企業はプロダクト単位で分けやすい が、BASEはほぼシングルプロダクトな企業なので、境界 線の定義は難しかった。
40. ©︎ 2012 - 2 0 2 2 BASE, Inc. 40 MSA以外の選択肢は無いのか？ 組織的学習の実現をするうえでMSAは理想的な解ではあ るが、本当にMSA以外の選択肢はないのか？ MSAほどの⾼い分離でなくてもいいし、境界線は完全に 定義しきれない状態でも着⼿できる⽅法はないのか？
41. ©︎ 2012 - 2 0 2 2 BASE, Inc. 41 モジュラモノリス
42. ©︎ 2012 - 2 0 2 2 BASE, Inc. 42 モジュラモノリスとはなにか モジュールによって構造化されたモ ノリス。 モノリス同様、単⼀リポジトリ‧単 ⼀デプロイを維持するが、内部のソ フトウェア部品はモジュールという 単位で分割された状態。
43. ©︎ 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
44. ©︎ 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
45. ©︎ 2012 - 2 0 2 2 BASE, Inc. 45 モジュールとはなにか ソフトウェア開発⼀般の「モジュール」とは単純に⾔っ てしまえばソフトウェアを構成する個々の部品のこと。 この資料における「モジュール」はモジュラモノリスを 構成する部品であり、ある程度独⽴して作業可能な単位 として扱う。社内の命名はBaseIncModuleとなってい る。
46. ©︎ 2012 - 2 0 2 2 BASE, Inc. 46 BaseIncModuleとは ビジネスドメインを基準に作られ、ビジネス価値を⽀え るソフトウェア上の枠組み。ビジネス上関⼼の強いもの が同⼀モジュールに集まり、弱いものは別モジュールへ 分かれる。 直接的な⾔い⽅をすれば、DDDにおける境界づけられた コンテキストと同⼀の単位として作られる。 Microservice Checkout ίϯςΩετ Module Checkout ίϯςΩετ
47. ©︎ 2012 - 2 0 2 2 BASE, Inc. 47 クリーンアーキテクチャをベースに作成している Application Domain 内側2層を「BaseIncModule」 と呼んでいる ※BASEͰ͸CleanArchitectureΛ3૚ͱͯ͠࡞͍ͬͯΔ Gateways
48. ©︎ 2012 - 2 0 2 2 BASE, Inc. 48 BASEのモジュラモノリスを図⽰するとこう ModularMonolith A P I G a t e w a y Module Module Module Module ʹ
49. ©︎ 2012 - 2 0 2 2 BASE, Inc. 49 ディレクトリ構造 Ϟδϡʔϧஔ͖৔ ϑϨʔϜϫʔΫ্ͷsrcσΟϨΫτϦ ֤ϞδϡʔϧͷInterfaceͷٕज़త࣮૷ ApplicationϨΠϠͱDomainϨΠϠʢ֤Ϟδϡʔϧʹଘࡏ͢Δʣ Ϟδϡʔϧ͝ͱʹςετ͕͋ΔʢDBͳͲͷٕज़ৄࡉʹ͸ґଘ͍ͯ͠ͳ͍ʣ Ϟδϡʔϧ Ϟδϡʔϧ͝ͱʹಠࣗͷίʔσΟϯάن໿΍PHPStanʹΑΔνΣοΫΛ͍ͯ͠Δ
50. ©︎ 2012 - 2 0 2 2 BASE, Inc. 50 モジュール間の関係 モジュールごとにパブリックAPIを⽤意し、外部からはそ こにしかアクセスさせないことで、内部の詳細を隠蔽す る。 フレームワークのControllerからもモジュールにはパブ リックAPIからしかアクセスできないし、モジュール間の 通信もパブリックAPIにしかアクセスさせない。
51. ©︎ 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
52. ©︎ 2012 - 2 0 2 2 BASE, Inc. 52 依存ルール 複数の依存ルールがある。 deptracというツールを使⽤して依存ルールの違反がない かをCIでチェックしている。 deptrac: https://github.com/qossmic/deptrac
53. ©︎ 2012 - 2 0 2 2 BASE, Inc. 53 依存ルール • クリーンアーキテクチャとしてのルール • レイヤ間の依存の⽅向が内側のみに向かう • モジュラモノリスとしてのルール • モジュール外部からはモジュール内部に直接依存でき ず、パブリックAPIにしか依存できない • モジュール間で循環依存があってはならない • モジュール内部の独⾃ルール • チームで独⾃のルールがあれば⾃由に設定しても良い
54. ©︎ 2012 - 2 0 2 2 BASE, Inc. 54 MSAと同様のメリット モジュールが作業分割の単位になる。 モジュール内部を隠蔽することでモジュールの設計の独 ⽴性を担保でき、各チームに委ねることが出来る。
55. ©︎ 2012 - 2 0 2 2 BASE, Inc. 55 MSAと⽐較したメリット • 単⼀リポジトリなのでコード検索‧修正が容易 • 単⼀インフラなので分散システム特有の複雑さを避けや すい • 規律の崩壊を防ぎやすい • モジュールを横断した修正が容易 • モジュール境界線⾃体の⾒直しが容易 • 漸進的にマイクロサービスに向かえる（詳細は後の章）
56. ©︎ 2012 - 2 0 2 2 BASE, Inc. 56 モジュール境界線の修正が容易 ྫ͑͹ϚΠΫϩαʔϏεͰޙํޓ׵ੑͷͳ͍APIͷߋ৽͕ൃੜͨ͠৔߹ͷमਖ਼ྫ Microservice Microservice 1. ݺͼग़͠ଆͰࣄલʹޓ׵ੑ ͕ͳ͘ͳΔՕॴͷमਖ਼Λ͢Δ ※APIόʔδϣχϯάΛ͠ͳ͍৔߹ 2. APIΛߋ৽͢Δ 3. ৽͍͠࢓༷ʹԊͬͨमਖ਼Λߦ͏ APIΞΫηε ModularMonolith Module Module 1. ྆ऀΛҰ౓ʹमਖ਼ͯ͠ 1ճͷσϓϩΠͰ׬ྃ APIΞΫηε モジュール境界線の⼿戻りを低いコストで実現できる 安定した境界線を⼿探りで探しやすい
57. ©︎ 2012 - 2 0 2 2 BASE, Inc. 57 MSAと⽐較したデメリット モジュール境界や依存関係のルールを確実に守らないといけない 単⼀インフラなのでテクノロジー選択の裁量は低い ＝＞静的解析ツールでだいたいは実現可能 単⼀デプロイなのでデプロイの交通渋滞が発⽣する ＝＞マイクロサービスでも全チームが好き勝⼿にプログラミング⾔語とか変えると 基盤技術構築できない問題があるため、完全⾃由にさせてる企業は実は少ない認識 ＝＞解決案なし
58. ©︎ 2012 - 2 0 2 2 BASE, Inc. 58 モジュラモノリスを 中⼼に据えたアーキテクチャ戦略
59. ©︎ 2012 - 2 0 2 2 BASE, Inc. 59 漸進的にマイクロサービスへ向かっていく モジュラモノリスはマイクロサービスほどの強⼒な分離 は実現できない。さらに組織がスケールするならば最終 的にマイクロサービス化もあり得る。
60. ©︎ 2012 - 2 0 2 2 BASE, Inc. 60 漸進的にマイクロサービスへ向かっていく 漸進的にマイクロサービスへ向かっていけることもモ ジュラモノリスのメリットとなる。現⾏のアーキテク チャからモジュラモノリスを経由することで、漸進的に マイクロサービス化を実現可能にする。
61. ©︎ 2012 - 2 0 2 2 BASE, Inc. 61 漸進的にマイクロサービスへ向かっていく BaseIncModuleは実⾏環境に依存していない＝実⾏環境 を変更可能。システム上の移動可能な単位として扱う。 ※PHPͱͦͷόʔδϣϯʹ͸ґଘ͍ͯ͠ΔͷͰʮ࣮ߦ؀ڥʹґଘ͕ແ͍ʯͱݴ͍੾Δͷʹޠฐ͸͋Δ
62. ©︎ 2012 - 2 0 2 2 BASE, Inc. 62 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション
63. ©︎ 2012 - 2 0 2 2 BASE, Inc. 現⾏アプリケーション 63 現⾏からマイクロサービスへ向かう⼿順 Ϗδωεϧʔϧ ΞϓϦέʔγϣϯϧʔϧ ϑϨʔϜϫʔΫίʔυ બΓ෼͚Δ BaseIncModuleͱͳΔՕॴ
64. ©︎ 2012 - 2 0 2 2 BASE, Inc. 64 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション ϑϨʔϜϫʔΫίʔυ module
65. ©︎ 2012 - 2 0 2 2 BASE, Inc. 65 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション module module module module module module
66. ©︎ 2012 - 2 0 2 2 BASE, Inc. 66 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module ࣮ߦ؀ڥඇґଘͳͷͰ ࣮ߦ؀ڥΛมߋͰ͖Δ ϑϨʔϜϫʔΫ΋มߋͰ͖Δ
67. ©︎ 2012 - 2 0 2 2 BASE, Inc. 67 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module Web API Call ৽ΞϓϦέʔγϣϯͷϩδοΫ ΛWebAPI CallͰݺͼग़͢ ※DBτϥϯβΫγϣϯ͸෼͔Εͯ͠·͏
68. ©︎ 2012 - 2 0 2 2 BASE, Inc. 68 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module Web API Call logic logic logic ϚΠΫϩαʔϏεΑΓ͸ ௿͍ίετͰڥքઢΛಈ͔ͤΔ
69. ©︎ 2012 - 2 0 2 2 BASE, Inc. 69 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module Web API Call ڥքઢͷ҆ఆ
70. ©︎ 2012 - 2 0 2 2 BASE, Inc. 70 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module Web API Call DBトランザクション分離 PHPプロセス分離 ※DBτϥϯβΫγϣϯͷ෼཭͸ࣄલʹઓུతʹ΍ΕΔͳΒ΍ͬͨ΄͏͕ྑ͍ CAPఆཧʹ΋͋Δ௨Γɺ෼ࢄγεςϜԽ͢Δͱ σʔλͷӬଓԽ͸CAPͷ͍ͣΕ͔͕େ͖͘ଛͳΘΕΔ
71. ©︎ 2012 - 2 0 2 2 BASE, Inc. 71 現⾏からマイクロサービスへ向かう⼿順 現⾏アプリケーション モジュラモノリス module module module module module module Web API Call DB෼཭
72. ©︎ 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
73. ©︎ 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 チームごとの テクノロジーマネジメント 各領域がさらに複雑化したときも、分 割境界として今後もモジュールは増え 続ける
74. ©︎ 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ܦ༝ͷݺͼग़͠͸ܾͯ͠౳ՁͰ͸ͳ͍ɻ
75. ©︎ 2012 - 2 0 2 2 BASE, Inc. 75 まとめ
76. ©︎ 2012 - 2 0 2 2 BASE, Inc. 76 BASEの中⻑期的なアーキテクチャ戦略とは アーキテクチャを「時間の経過によるビジネス‧テクノロ ジー‧組織の変化に耐えながら組織の⽣産性を⽀えつづ ける、事業競争⼒を得るためのシステムの構造」と定義 した。
77. ©︎ 2012 - 2 0 2 2 BASE, Inc. 77 BASEの中⻑期的なアーキテクチャ戦略とは 中⻑期的に事業競争⼒を得るには、組織的学習の持続的 な実現が必要であるとした。 アーキテクチャが分業の質を制約してしまう前提の中 で、なるべくこれを実現できるようなアーキテクチャが 望ましい。
78. ©︎ 2012 - 2 0 2 2 BASE, Inc. 78 BASEの中⻑期的なアーキテクチャ戦略とは ビジネスを⽀えるソフトウェア上の枠組みを「モジュー ル」という名前でパッケージングを⾏う。 モジュールを分業可能な単位として扱い、各チームに委 任してそれぞれにPDCAを回してもらうことで組織的学習 を実現する。
79. ©︎ 2012 - 2 0 2 2 BASE, Inc. 79 BASEの中⻑期的なアーキテクチャ戦略とは 適切で安定したモジュール境界線はいきなり⾒つからな いことを前提とする。 モジュールの境界線はモジュラモノリス上で⼿戻りしな がら調整することで、適切で安定した境界線を⼿探りで 探す。
80. ©︎ 2012 - 2 0 2 2 BASE, Inc. 80 BASEの中⻑期的なアーキテクチャ戦略とは モジュラモノリスの時点で質の⾼い分業には限界があ り、漸進的にマイクロサービス化が可能になるように設 計を⾏う。
81. ©︎ 2012 - 2 0 2 2 BASE, Inc. 81 BASEの中⻑期的なアーキテクチャ戦略とは 我々は全体システムにおける最終形を定義しない。それ は未来のビジネス‧テクノロジー‧組織の変化に応じて システムに対する要求が変わるため、最適解が変わり続 けることを前提とする。
82. ©︎ 2012 - 2 0 2 2 BASE, Inc. 82 BASEの中⻑期的なアーキテクチャ戦略とは アーキテクチャは従来「後から変更することが難しい部 分」とされてきた。 モジュールをアーキテクチャにおける可動域にすること で、その時点での要求をなるべく満たすような形態への 変更可能とすることで、漸進的に進化しつづけることが可 能なアーキテクチャであることを⽬指す。
83. ©︎ 2012 - 2 0 2 2 BASE, Inc. 83 ご清聴 ありがとうございました