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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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. 改善を促進するリーダーシップの実現や⽀援
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    ʹ
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

58. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    58
    モジュラモノリスを
    
    
    中⼼に据えたアーキテクチャ戦略
    

    View Slide

59. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    59
    漸進的にマイクロサービスへ向かっていく
    モジュラモノリスはマイクロサービスほどの強⼒な分離
    は実現できない。さらに組織がスケールするならば最終
    的にマイクロサービス化もあり得る。
    

    View Slide

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

    View Slide

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

    View Slide

62. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    62
    現⾏からマイクロサービスへ向かう⼿順
    現⾏アプリケーション
    
    
    

    View Slide

63. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    現⾏アプリケーション
    
    
    63
    現⾏からマイクロサービスへ向かう⼿順
    Ϗδωεϧʔϧ
    ΞϓϦέʔγϣϯϧʔϧ
    ϑϨʔϜϫʔΫίʔυ
    બΓ෼͚Δ
    BaseIncModuleͱͳΔՕॴ
    

    View Slide

64. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    64
    現⾏からマイクロサービスへ向かう⼿順
    現⾏アプリケーション
    
    
    ϑϨʔϜϫʔΫίʔυ
    module
    

    View Slide

65. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    65
    現⾏からマイクロサービスへ向かう⼿順
    現⾏アプリケーション
    
    
    module
    module
    module
    module
    module
    module
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    チームごとの
    
    
    テクノロジーマネジメント
    各領域がさらに複雑化したときも、分
    割境界として今後もモジュールは増え
    続ける
    

    View Slide

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ܦ༝ͷݺͼग़͠͸ܾͯ͠౳ՁͰ͸ͳ͍ɻ
    

    View Slide

75. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    75
    まとめ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

80. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    80
    BASEの中⻑期的なアーキテクチャ戦略とは
    モジュラモノリスの時点で質の⾼い分業には限界があ
    り、漸進的にマイクロサービス化が可能になるように設
    計を⾏う。
    

    View Slide

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

    View Slide

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

    View Slide

83. ©︎ 2012
    -
    2
    0 2
    2
    BASE, Inc.
    83
    ご清聴
    
    
    ありがとうございました
    

    View Slide