あなたの組織にとってマイクロサービスは本当に必要ですか？ / Why YOUR organization should NOT choose Microservices Architecture.

クラスメソッド株式会社が主催するイベント DevelopersIO Decade 2021 で発表した「あなたの組織にとってマイクロサービスは本当に必要ですか？」の登壇資料です。
https://classmethod.jp/m/devio-2021-decade/

「マイクロサービス」がバズワードとなって久しいですが、それはあなたの組織のとって本当に必要なものでしょうか？ マイクロサービスアーキテクチャには技術的な設計手法だけでなく、組織論としての側面があります。マイクロサービスとはそもそも何なのか、どういった状況で必要になるものなのかといったことを踏まえた上で、導入のアンチパターンやマイクロサービス以外の選択肢について、改めてご紹介します。

Transcript

1. あなたの組織にとって
   マイクロサービスは本当に必要ですか︖
   2021/10/7
   AWS事業本部コンサルティング部 寺岡慶佑
   

   View Slide

2. 2
   発表者紹介
   寺岡 慶佑（とばち）
   ● 2020年11月入社
   ● 前職: Webサービス開発・運用
   ○ Amazon ECS/EKSを用いた構成
   ● 好きなAWSサービス
   ○ AWS App Mesh
   ○ Amazon EKS
   ● 2021 APN AWS Top Engineer
   ● 趣味
   ○ 紅茶
   ○ ビール
   @toda_kk
   @tobachi
   

   View Slide

3. 3
   本日お伝えしたいこと
   マイクロサービスだけが正解ではない
   

   View Slide

4. 4
   あなたの組織では
   マイクロサービスについて
   どのように考えているでしょうか？
   

   View Slide

5. 稼働中のアプリケーションをモノリスからマイクロサービスへ
   移行しようとしている
   新たに開発するアプリケーションを最初からマイクロサービス
   として構築しようと考えている
   アプリケーションをすでにマイクロサービス化している
   5
   マイクロサービスに対するアプローチのパターン
   

   View Slide

6. 稼働中のアプリケーションをモノリスからマイクロサービスへ
   移行しようとしている
   モノリスのままアプリケーション規模が拡大したことよる複雑化
   デリバリーや品質、可用性などの課題を解決したい
   新たに開発するアプリケーションを最初からマイクロサービス
   として構築しようと考えている
   技術的負債を抱えない形でシステム構築したい
   アプリケーションをすでにマイクロサービス化している
   マイクロサービスアーキテクチャによって全ての課題は解決済み？
   6
   アプリケーション開発に関する思惑
   

   View Slide

7. 7
   Case1;
   モノリスからマイクロサービスへ
   

   View Slide

8. 8
   アプリケーション新規開発フェーズ
   Database
   App
   User
   🧑💻
   開発者
   🧑💻
   インフラ
   🙋
   オーナー
   

   View Slide

9. 9
   アプリケーションレイヤーの依存関係
   Database
   User
   単純なレイヤードアーキテクチャを想定
   🧑💻
   開発者
   🧑💻
   インフラ
   🙋
   オーナー
   

   View Slide

10. 10
    機能追加によるアプリケーション規模の拡大
    Database
    User
    ビジネス要求に応じた機能追加や改善
    チームメンバーの増加
    ビジネス要求
    🧑💻🧑💻🧑💻
    開発者
    🧑💻🧑💻
    インフラ
    🙋
    オーナー
    

    View Slide

11. 11
    依存関係がだんだん複雑になっていく
    Database
    User
    ビジネス要求
    アプリケーション内の依存関係が複雑化していく
    → 変更の影響範囲がわかりにくくなる
    ビジネス要求
    ❓ ❓
    🔥 🔥
    🧑💻🧑💻🧑💻🧑💻🧑💻
    開発者
    🧑💻🧑💻🧑💻
    インフラ
    🙋
    オーナー
    

    View Slide

12. 12
    そして、さらなる機能追加……
    Database
    User
    ビジネス要求
    ビジネス要求
    ビジネス要求
    ❓ ❓
    ビジネス要求
    ビジネス要求
    ❌
    ❌
    ビジネス要求の変化にアプリケーションが追いつけなくなる
    全体的なシステム品質・可用性・パフォーマンスの低下
    🔥
    🔥
    🔥
    🔥 🔥
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    ❓ ❓
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

13. 13
    複雑化したモノリスの問題点
    モノリスのままアプリケーション規模が拡大したことによって
    発生した問題点
    ビジネス機能の凝集度の低さによる密結合の発生
    変更による影響範囲が見えなくなる
    大量実行される回帰テスト、思わぬバグの発生
    変更を大きな単位でデプロイしたくなる
    → デリバリー速度の低下、システム全体の品質や可用
    性の低下
    

    View Slide

14. 14
    モノリスの問題点を解決するために
    モノリスからマイクロサービスへ
    

    View Slide

15. 15
    マイクロサービスアーキテクチャとは
    アプリケーションを複数の独立したコンポーネントに分割し、
    ネットワーク通信により協調させて全体として動作させる分散
    アーキテクチャ
    App
    App
    App
    App
    App
    App
    App
    App
    

    View Slide

16. 技術異質性
    サービスごとに異なる技術を選定できる
    回復性（レジリエンス）
    1つのコンポーネントにおける障害発生がシステム全体に影響を及ぼ
    すことを防ぐことができる
    スケーリング
    サービス単位でスケーリングできる
    デプロイの容易性
    サービス単位でデプロイできる
    16
    マイクロサービスアーキテクチャのメリット
    Sam Newman，佐藤直生監訳・木下哲也訳，『マイクロサービスアーキテクチャ』（オライリー・ジャパン）より
    

    View Slide

17. 組織面の一致
    サービスの所有権を小規模チームに移すことができる
    合成可能性
    機能の再利用性を高められる
    交換可能にするための最適化
    サービスの書き換えや削除が容易
    17
    マイクロサービスアーキテクチャのメリット
    Sam Newman，佐藤直生監訳・木下哲也訳，『マイクロサービスアーキテクチャ』（オライリー・ジャパン）より
    

    View Slide

18. 18
    複雑化したモノリス
    Database
    User
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

19. 19
    アプリケーション内の責務を分離する
    Database
    User
    ビジネス機能に応じて少しずつ責務を分離する
    → 技術的な観点ではなく、ビジネス機能の観点で分離する
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

20. 20
    アプリケーション内の責務を分離する
    Database
    User
    最初からすべての責務を分離しようとする
    → 適切な境界が判断できず、却って変更コストがかかる
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    ❓ ❓ ❓ ❓
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

21. 21
    アプリケーション内の責務を分離する
    Database
    User
    ビジネス機能に応じて少しずつ責務を分離する
    → 少しずつ分離することで適切な境界をチームが学んでいく
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

22. 22
    責務をマイクロサービスとして分離
    Database
    User
    マイクロサービスの境界に応じて
    所有権を持つチームを配置
    🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    App DB
    🧑💻🧑💻‍
    🧑💻🧑💻🧑💻
    🧑💻
    インフラ
    

    View Slide

23. 23
    マイクロサービスの分離を繰り返していく
    User
    マイクロサービスの境界と
    チームの境界を一致させる
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    開発者
    🧑💻🧑💻🧑💻
    インフラ
    🙋
    オーナー
    App DB
    🙋🧑💻‍
    Database
    App DB
    🙋🧑💻‍
    

    View Slide

24. 24
    ここで改めて、モノリスについて考えてみる
    モノリスは悪なのか？
    

    View Slide

25. 25
    モノリスは悪なのか？
    本セッションにおける「モノリス」とは
    単一なプロセスとしてデプロイされ稼働するシステムのこと
    モノリスのメリット
    コードが単一なため、テストやデプロイが容易になる
    インフラ構成もシンプルになるため変更管理や運用が容易になる
    

    View Slide

26. Load
    Balancer
    26
    モノリスのメリット
    Database
    単一リポジトリからの一貫したテスト、デプロイ
    シンプルなインフラ構成
    Server
    App
    Mono
    Repository
    Server
    App
    Server
    App
    Server
    App
    Test
    Deploy
    

    View Slide

27. 27
    モノリスは悪なのか？
    モノリスの問題点？
    コードが密結合になり、変更コストが高くなったモノリスに問題が
    ある
    → 密結合を避け、依存関係を適切に管理できていれば、むし
    ろ単一なプロセスによるメリットを得られるはず
    

    View Slide

28. 28
    モノリスとマイクロサービスの良いとこ取り
    マイクロサービスは一種の分散システムである
    分散化によって失われるモノリスのメリット
    コードが単一なため、テストやデプロイが容易になる
    インフラ構成もシンプルになるため変更管理や運用が容易になる
    分散させず単一プロセスのまま、コードの密結合を避け変化に
    柔軟な構造が保てるようなアーキテクチャ？
    

    View Slide

29. 29
    1つの選択肢
    モジュラモノリスアーキテクチャ
    

    View Slide

30. モノリスの一形態
    独立した複数のモジュールで構成される
    かつ、単一プロセスとしてデプロイされて稼働するシステム
    30
    モジュラモノリス（Modular Monolith）とは
    

    View Slide

31. 31
    モジュラモノリス（Modular Monolith）とは
    Database
    User
    単一のソースコード内でモジュールが分離されている状態
    各モジュールは疎結合を保ちながらコード内で呼び出される
    （実現方法はさまざま）
    

    View Slide

32. インフラ観点から見たモジュラモノリス
    Load
    Balancer
    32
    Database
    シンプルなインフラ構成、スケーリングなど変更管理が容易
    Mono
    Repository
    Test
    Deploy
    Server Server
    Server
    Server
    

    View Slide

33. ディレクトリ構造の再編成
    MVCモデルに基づくRuby on Railsアプリケーション
    コンポーネントごとに手動でラベリングして分割
    依存関係の分離を強制
    依存関係を管理するための社内ツールの開発
    コンポーネントの境界を強制
    明示的に依存しないコンポーネントをロードしない
    33
    Shopifyの例: モノリスからモジュラモノリスへ
    参考: [翻訳] Shopifyにおけるモジュラモノリスへの移行 https://qiita.com/tkyowa/items/ae9fa550237cb6f48318
    

    View Slide

34. 34
    モジュラモノリスの有用性
    分散システムに起因する課題が発生しない
    マイクロサービスではサービス間通信などを考慮する必要がある
    モノリスのメリットを保ったままアプリケーション規模を拡大
    できる
    最終的にマイクロサービスに移行するにしろ、モノリスの活用
    も選択肢に入れるべき
    

    View Slide

35. 35
    Case2;
    新たに開発するアプリケーションを
    最初からマイクロサービスとして構築する
    

    View Slide

36. 36
    【再掲】アプリケーション内の責務を分離する
    Database
    User
    最初からすべての責務を分離しようとする
    → 適切な境界が判断できず、却って変更コストがかかる
    🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻
    🧑💻🧑💻🧑💻🧑💻
    開発者
    🙋
    オーナー
    ❓ ❓ ❓ ❓
    🧑💻🧑💻🧑💻
    🧑💻🧑💻
    インフラ
    

    View Slide

37. 37
    サービス分割の難しさ
    適切なサービス境界を判断できない段階での
    サービス分割はリスクが大きい
    

    View Slide

38. ビジネス機能に応じて分離する
    少しずつ分離することで、チームが学んでいく
    ビジネス機能に応じた境界のヒントになりそうなところ
    デプロイの単位として分離したいところ
    データベースがすでに分離されているところ
    → すでにビジネス機能の責務が考慮されている可能性がある。
    ただし、技術的な観点に頼り過ぎない方が良い
    38
    適切なサービス境界を見つけるために
    

    View Slide

39. I feel that you shouldn't start with microservices unless you have reasonable
    experience of building a microservices system in the team.
    39
    Martin Fowler “MonolithFirst”
    参考: MonolithFirst https://martinfowler.com/bliki/MonolithFirst.html
    

    View Slide

40. 規模の大きくなったモノリスを分割するパターンが、マイクロ
    サービスでは上手くいきやすい
    サービス分割の難しさに起因する
    対象となるビジネスドメインに関して、アプリケーションの開発・
    運用した経験を経た方が、適切なサービス境界を判断しやすい
    最初からマイクロサービスとしてアプリケーションを開発する
    のは、一種のアンチパターンであると考えた方が良い
    単純に開発スピードが遅くなる
    デプロイのパイプラインを整備する必要がある
    分散システムのロギング、モニタリングが必要
    → ファーストリリースが遅くなる
    40
    アンチパターンとしてのMicroservices First
    

    View Slide

41. 41
    Case3;
    アプリケーションを
    すでにマイクロサービス化している
    

    View Slide

42. マイクロサービス自体が分散システムであり、複雑なアーキテ
    クチャである
    サービスごとに独立したデプロイの自動化が必要
    サービス間で通信を行うため、ネットワーク起因のレイテンシーや
    障害が発生する
    サービス間で通信の整合性を保つ必要がある（バージョニングな
    ど）
    サービスを越えたロギングやモニタリングといった可観測性の確保
    これらの課題を解決する技術的要素については割愛
    42
    マイクロサービスに起因して発生する課題
    

    View Slide

43. 43
    マイクロサービスの目的を考える
    あなたの組織では
    なぜマイクロサービスを採用するのか？
    

    View Slide

44. チームの自律性を高めるため
    サービスの所有権を小規模チームに持たせ、ビジネス要求の変化を
    サービスに反映させやすくする
    費用対効果の高い可用性や回復性を実現したい
    負荷の高いビジネス機能を個別にスケーリングできるようにする
    個々のサービスの障害によるシステム全体への影響を抑える
    新しい技術を試しやすくするため
    サービス間で適切に通信できれば、個々のサービスの技術要素はチ
    ームごとに選定できる
    44
    なぜマイクロサービスを採用するのか？
    

    View Slide

45. 究極的には、ビジネス価値の最大化のため
    ビジネス価値を顧客にいち早く提供するために、デリバリーを高速
    化したい
    チームの自律性を高めることで、生産性を向上させたい
    45
    なぜマイクロサービスを採用するのか？
    

    View Slide

46. App
    46
    ビジネス価値の最大化のためのサービス分離
    DB
    App DB
    App DB
    DB
    DB
    App
    App
    User
    サービスとチームの一致
    

    View Slide

47. マイクロサービスでチームの生産性を最大化できるか？
    マイクロサービスはチーム体制に直接影響を及ぼす手法である
    サービス境界とチーム境界が一致できない場合
    マイクロサービスのメリットを十分に得られない可能性がある
    組織としてマイクロサービスがマッチしない場合は、モジュラ
    モノリスへの移行も選択肢として採用し得る
    マイクロサービス起因の課題を技術的に解決するよりも、モノリス
    に回帰してしまった方が早いケースもある
    47
    組織論としてのマイクロサービス
    

    View Slide

48. 48
    あなたの組織にとって
    マイクロサービスは本当に必要ですか？
    

    View Slide

49. 稼働中のアプリケーションをモノリスからマイクロサービスへ
    移行しようとしている
    モノリスのままアプリケーション規模が拡大したことよる複雑化
    デリバリーや品質、可用性などの課題を解決したい
    新たに開発するアプリケーションを最初からマイクロサービス
    として構築しようと考えている
    技術的負債を抱えない形でシステム構築したい
    アプリケーションをすでにマイクロサービス化している
    マイクロサービスアーキテクチャによって全ての課題は解決済み？
    49
    【再掲】アプリケーション開発に関する思惑
    

    View Slide

50. すでに動いているモノリスを徐々に分割する
    徐々に分割しながら、適切なサービス境界を学んでいく
    モジュラモノリスも検討する
    最初からマイクロサービスとして構築するのはアンチパターン
    適切なサービス境界を判断できるか？
    「分散モノリス」となってしまう懸念
    サービス分割が上手くいかなかった場合は、モノリスへの回帰
    も選択肢として考える
    時間の経過と共にマイクロサービスが適切でなくなってしまうこと
    も考えられる
    50
    本セッションのまとめ
    

    View Slide

51. 51
    本日お伝えしたかったこと
    マイクロサービスだけが正解ではない
    

    View Slide

52. Sam Newman『マイクロサービスアーキテクチャ』（オライリー・ジャ
    パン）
    https://www.oreilly.co.jp/books/9784873117607/
    Sam Newman『モノリスからマイクロサービスへ』（オライリー・ジャ
    パン）
    https://www.oreilly.co.jp/books/9784873119311/
    Martin Fowler Microservices
    https://martinfowler.com/articles/microservices.html
    [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
    https://qiita.com/tkyowa/items/ae9fa550237cb6f48318
    なぜMicroservicesか? | Taichi Nakashima
    https://deeeet.com/writing/2019/05/20/why-microservices/
    52
    参考資料
    

    View Slide

53. View Slide