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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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 参考資料

Slide 53

Slide 53 text

No content