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

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

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

Transcript

1. あなたの組織にとって マイクロサービスは本当に必要ですか︖ 2021/10/7 AWS事業本部コンサルティング部 寺岡慶佑
2. 2 発表者紹介 寺岡 慶佑（とばち） • 2020年11月入社 • 前職: Webサービス開発・運用 ◦ Amazon ECS/EKSを用いた構成 • 好きなAWSサービス ◦ AWS App Mesh ◦ Amazon EKS • 2021 APN AWS Top Engineer • 趣味 ◦ 紅茶 ◦ ビール @toda_kk @tobachi
3. 3 本日お伝えしたいこと マイクロサービスだけが正解ではない
4. 4 あなたの組織では マイクロサービスについて どのように考えているでしょうか？
5. 稼働中のアプリケーションをモノリスからマイクロサービスへ 移行しようとしている 新たに開発するアプリケーションを最初からマイクロサービス として構築しようと考えている アプリケーションをすでにマイクロサービス化している 5 マイクロサービスに対するアプローチのパターン
6. 稼働中のアプリケーションをモノリスからマイクロサービスへ 移行しようとしている モノリスのままアプリケーション規模が拡大したことよる複雑化 デリバリーや品質、可用性などの課題を解決したい 新たに開発するアプリケーションを最初からマイクロサービス として構築しようと考えている 技術的負債を抱えない形でシステム構築したい アプリケーションをすでにマイクロサービス化している マイクロサービスアーキテクチャによって全ての課題は解決済み？ 6 アプリケーション開発に関する思惑
7. 7 Case1; モノリスからマイクロサービスへ
8. 8 アプリケーション新規開発フェーズ Database App User 🧑💻 開発者 🧑💻 インフラ 🙋 オーナー
9. 9 アプリケーションレイヤーの依存関係 Database User 単純なレイヤードアーキテクチャを想定 🧑💻 開発者 🧑💻 インフラ 🙋 オーナー
10. 10 機能追加によるアプリケーション規模の拡大 Database User ビジネス要求に応じた機能追加や改善 チームメンバーの増加 ビジネス要求 🧑💻🧑💻🧑💻 開発者 🧑💻🧑💻 インフラ 🙋 オーナー
11. 11 依存関係がだんだん複雑になっていく Database User ビジネス要求 アプリケーション内の依存関係が複雑化していく → 変更の影響範囲がわかりにくくなる ビジネス要求 ❓ ❓ 🔥 🔥 🧑💻🧑💻🧑💻🧑💻🧑💻 開発者 🧑💻🧑💻🧑💻 インフラ 🙋 オーナー
12. 12 そして、さらなる機能追加…… Database User ビジネス要求 ビジネス要求 ビジネス要求 ❓ ❓ ビジネス要求 ビジネス要求 ❌ ❌ ビジネス要求の変化にアプリケーションが追いつけなくなる 全体的なシステム品質・可用性・パフォーマンスの低下 🔥 🔥 🔥 🔥 🔥 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー ❓ ❓ 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
13. 13 複雑化したモノリスの問題点 モノリスのままアプリケーション規模が拡大したことによって 発生した問題点 ビジネス機能の凝集度の低さによる密結合の発生 変更による影響範囲が見えなくなる 大量実行される回帰テスト、思わぬバグの発生 変更を大きな単位でデプロイしたくなる → デリバリー速度の低下、システム全体の品質や可用 性の低下
14. 14 モノリスの問題点を解決するために モノリスからマイクロサービスへ
15. 15 マイクロサービスアーキテクチャとは アプリケーションを複数の独立したコンポーネントに分割し、 ネットワーク通信により協調させて全体として動作させる分散 アーキテクチャ App App App App App App App App
16. 技術異質性 サービスごとに異なる技術を選定できる 回復性（レジリエンス） 1つのコンポーネントにおける障害発生がシステム全体に影響を及ぼ すことを防ぐことができる スケーリング サービス単位でスケーリングできる デプロイの容易性 サービス単位でデプロイできる 16 マイクロサービスアーキテクチャのメリット Sam Newman，佐藤直生監訳・木下哲也訳，『マイクロサービスアーキテクチャ』（オライリー・ジャパン）より
17. 組織面の一致 サービスの所有権を小規模チームに移すことができる 合成可能性 機能の再利用性を高められる 交換可能にするための最適化 サービスの書き換えや削除が容易 17 マイクロサービスアーキテクチャのメリット Sam Newman，佐藤直生監訳・木下哲也訳，『マイクロサービスアーキテクチャ』（オライリー・ジャパン）より
18. 18 複雑化したモノリス Database User 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
19. 19 アプリケーション内の責務を分離する Database User ビジネス機能に応じて少しずつ責務を分離する → 技術的な観点ではなく、ビジネス機能の観点で分離する 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
20. 20 アプリケーション内の責務を分離する Database User 最初からすべての責務を分離しようとする → 適切な境界が判断できず、却って変更コストがかかる 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー ❓ ❓ ❓ ❓ 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
21. 21 アプリケーション内の責務を分離する Database User ビジネス機能に応じて少しずつ責務を分離する → 少しずつ分離することで適切な境界をチームが学んでいく 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
22. 22 責務をマイクロサービスとして分離 Database User マイクロサービスの境界に応じて 所有権を持つチームを配置 🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻 開発者 🙋 オーナー App DB 🧑💻🧑💻‍ 🧑💻🧑💻🧑💻 🧑💻 インフラ
23. 23 マイクロサービスの分離を繰り返していく User マイクロサービスの境界と チームの境界を一致させる 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 開発者 🧑💻🧑💻🧑💻 インフラ 🙋 オーナー App DB 🙋🧑💻‍ Database App DB 🙋🧑💻‍
24. 24 ここで改めて、モノリスについて考えてみる モノリスは悪なのか？
25. 25 モノリスは悪なのか？ 本セッションにおける「モノリス」とは 単一なプロセスとしてデプロイされ稼働するシステムのこと モノリスのメリット コードが単一なため、テストやデプロイが容易になる インフラ構成もシンプルになるため変更管理や運用が容易になる
26. Load Balancer 26 モノリスのメリット Database 単一リポジトリからの一貫したテスト、デプロイ シンプルなインフラ構成 Server App Mono Repository Server App Server App Server App Test Deploy
27. 27 モノリスは悪なのか？ モノリスの問題点？ コードが密結合になり、変更コストが高くなったモノリスに問題が ある → 密結合を避け、依存関係を適切に管理できていれば、むし ろ単一なプロセスによるメリットを得られるはず
28. 28 モノリスとマイクロサービスの良いとこ取り マイクロサービスは一種の分散システムである 分散化によって失われるモノリスのメリット コードが単一なため、テストやデプロイが容易になる インフラ構成もシンプルになるため変更管理や運用が容易になる 分散させず単一プロセスのまま、コードの密結合を避け変化に 柔軟な構造が保てるようなアーキテクチャ？
29. 29 1つの選択肢 モジュラモノリスアーキテクチャ
30. モノリスの一形態 独立した複数のモジュールで構成される かつ、単一プロセスとしてデプロイされて稼働するシステム 30 モジュラモノリス（Modular Monolith）とは
31. 31 モジュラモノリス（Modular Monolith）とは Database User 単一のソースコード内でモジュールが分離されている状態 各モジュールは疎結合を保ちながらコード内で呼び出される （実現方法はさまざま）
32. インフラ観点から見たモジュラモノリス Load Balancer 32 Database シンプルなインフラ構成、スケーリングなど変更管理が容易 Mono Repository Test Deploy Server Server Server Server
33. ディレクトリ構造の再編成 MVCモデルに基づくRuby on Railsアプリケーション コンポーネントごとに手動でラベリングして分割 依存関係の分離を強制 依存関係を管理するための社内ツールの開発 コンポーネントの境界を強制 明示的に依存しないコンポーネントをロードしない 33 Shopifyの例: モノリスからモジュラモノリスへ 参考: [翻訳] Shopifyにおけるモジュラモノリスへの移行 https://qiita.com/tkyowa/items/ae9fa550237cb6f48318
34. 34 モジュラモノリスの有用性 分散システムに起因する課題が発生しない マイクロサービスではサービス間通信などを考慮する必要がある モノリスのメリットを保ったままアプリケーション規模を拡大 できる 最終的にマイクロサービスに移行するにしろ、モノリスの活用 も選択肢に入れるべき
35. 35 Case2; 新たに開発するアプリケーションを 最初からマイクロサービスとして構築する
36. 36 【再掲】アプリケーション内の責務を分離する Database User 最初からすべての責務を分離しようとする → 適切な境界が判断できず、却って変更コストがかかる 🧑💻🧑💻🧑💻🧑💻🧑💻🧑💻 🧑💻🧑💻🧑💻🧑💻 開発者 🙋 オーナー ❓ ❓ ❓ ❓ 🧑💻🧑💻🧑💻 🧑💻🧑💻 インフラ
37. 37 サービス分割の難しさ 適切なサービス境界を判断できない段階での サービス分割はリスクが大きい
38. ビジネス機能に応じて分離する 少しずつ分離することで、チームが学んでいく ビジネス機能に応じた境界のヒントになりそうなところ デプロイの単位として分離したいところ データベースがすでに分離されているところ → すでにビジネス機能の責務が考慮されている可能性がある。 ただし、技術的な観点に頼り過ぎない方が良い 38 適切なサービス境界を見つけるために
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
40. 規模の大きくなったモノリスを分割するパターンが、マイクロ サービスでは上手くいきやすい サービス分割の難しさに起因する 対象となるビジネスドメインに関して、アプリケーションの開発・ 運用した経験を経た方が、適切なサービス境界を判断しやすい 最初からマイクロサービスとしてアプリケーションを開発する のは、一種のアンチパターンであると考えた方が良い 単純に開発スピードが遅くなる デプロイのパイプラインを整備する必要がある 分散システムのロギング、モニタリングが必要 → ファーストリリースが遅くなる 40 アンチパターンとしてのMicroservices First
41. 41 Case3; アプリケーションを すでにマイクロサービス化している
42. マイクロサービス自体が分散システムであり、複雑なアーキテ クチャである サービスごとに独立したデプロイの自動化が必要 サービス間で通信を行うため、ネットワーク起因のレイテンシーや 障害が発生する サービス間で通信の整合性を保つ必要がある（バージョニングな ど） サービスを越えたロギングやモニタリングといった可観測性の確保 これらの課題を解決する技術的要素については割愛 42 マイクロサービスに起因して発生する課題
43. 43 マイクロサービスの目的を考える あなたの組織では なぜマイクロサービスを採用するのか？
44. チームの自律性を高めるため サービスの所有権を小規模チームに持たせ、ビジネス要求の変化を サービスに反映させやすくする 費用対効果の高い可用性や回復性を実現したい 負荷の高いビジネス機能を個別にスケーリングできるようにする 個々のサービスの障害によるシステム全体への影響を抑える 新しい技術を試しやすくするため サービス間で適切に通信できれば、個々のサービスの技術要素はチ ームごとに選定できる 44 なぜマイクロサービスを採用するのか？
45. 究極的には、ビジネス価値の最大化のため ビジネス価値を顧客にいち早く提供するために、デリバリーを高速 化したい チームの自律性を高めることで、生産性を向上させたい 45 なぜマイクロサービスを採用するのか？
46. App 46 ビジネス価値の最大化のためのサービス分離 DB App DB App DB DB DB App App User サービスとチームの一致
47. マイクロサービスでチームの生産性を最大化できるか？ マイクロサービスはチーム体制に直接影響を及ぼす手法である サービス境界とチーム境界が一致できない場合 マイクロサービスのメリットを十分に得られない可能性がある 組織としてマイクロサービスがマッチしない場合は、モジュラ モノリスへの移行も選択肢として採用し得る マイクロサービス起因の課題を技術的に解決するよりも、モノリス に回帰してしまった方が早いケースもある 47 組織論としてのマイクロサービス
48. 48 あなたの組織にとって マイクロサービスは本当に必要ですか？
49. 稼働中のアプリケーションをモノリスからマイクロサービスへ 移行しようとしている モノリスのままアプリケーション規模が拡大したことよる複雑化 デリバリーや品質、可用性などの課題を解決したい 新たに開発するアプリケーションを最初からマイクロサービス として構築しようと考えている 技術的負債を抱えない形でシステム構築したい アプリケーションをすでにマイクロサービス化している マイクロサービスアーキテクチャによって全ての課題は解決済み？ 49 【再掲】アプリケーション開発に関する思惑
50. すでに動いているモノリスを徐々に分割する 徐々に分割しながら、適切なサービス境界を学んでいく モジュラモノリスも検討する 最初からマイクロサービスとして構築するのはアンチパターン 適切なサービス境界を判断できるか？ 「分散モノリス」となってしまう懸念 サービス分割が上手くいかなかった場合は、モノリスへの回帰 も選択肢として考える 時間の経過と共にマイクロサービスが適切でなくなってしまうこと も考えられる 50 本セッションのまとめ
51. 51 本日お伝えしたかったこと マイクロサービスだけが正解ではない
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 参考資料