モノリシックの先にあるもの。マイクロサービス、あるいは / Does monolithic evolve into micro service

モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行をどう考えるかというテーマのプレゼンです。

## イベント

Tech Do 第12回
https://mimemo.io/m/vj5XN4jM53l86d7

## 参考

- ECにおけるマイクロサービス分割を考察する
https://dskst9.hatenablog.com/entry/2019/01/13/221041

Transcript

1. モノリシックの先にあるもの。 マイクロサービス、あるいは Tech Do 2019.2.8 daisuke sato @dskst9
2. daisuke sato @dskst9 Engineering Manager at ASKUL クラウドとアーキテクチャ、組織論が好き。最近はエンジニ アリングマネージャ楽しいよというのを世の中に広めたいと 思っている。
3. モノリシックから マイクロサービスへ 移行を検討している方？
4. 本日お話すること モノリシックなレガシーシステムと マイクロサービスの付き合い方
5. マイクロサービスで 何を解決したいのか？
6. 課題は何か
7. モノリシックの限界 • 肥大化するスパゲティコード • 何をするにも時間がかかり、作業効率が低下 • そして、スケールできなくなるチーム
8. モノリシックの限界 • 肥大化するスパゲティコード • 何をするにも時間がかかり、作業効率が低下 • そして、スケールできなくなるチーム 変化に弱い設計のモノリシックの限界
9. 変化に弱い設計の モノリシックからの脱却を考える • 最低限3層構造にしたい ◦ プレゼンテーション層 ◦ ロジック層 ◦ データベース層 • スケールできるようにサービス分割したい • 分割したサービスをチームごとに開発したい
10. マイクロサービス やってみるか？
11. マイクロサービス やってみるか？ とか考えて
12. よーいドン！ で、マイクロサービスを 目指すと
14. アーキテクチャを知る
15. 進化的 アーキテクチャ “モノリスを構築できないとき、なぜ マイクロサービスが その答えだと思うのか”
16. 非構造化モノリス Monolithic Architecture • 非構造化モノリス • レイヤ化アーキテクチャ • モジュール式モノリス • マイクロカーネル UI クラス クラス クラス クラス クラス レイヤ化アーキテクチャ プレゼンテーション層 ビジネスロジック層 永続化層 データベース モジュール式モノリス UI コンポーネント モジュール モジュール モジュール
17. Event Driven Architecture • Broker • Mediator Broker event process message process process process message Mediator event process process message Mediator process workflow
18. Service-Oriented Architecture • ESB駆動SOA SOA business service message bus process choreographar service orchestrator enterprise service application service infrastructure service
19. Microservices Architecture • より小さなサービス粒度でそ れぞれ独立 • ビジネスドメインに沿ったモデ ル化、分離 • 高度な自動化、分散化、 API module module module module module module module module module module request request request
20. Service-Based Architecture 移行用のアーキテクチャパターン （あるいは、分断されたモノリス） • 大きなサービス粒度 • 大きなデータベーススコープ • レガシーシステムとの統合ミドル ウェア UI module module module module module module module module module module request request request
21. ECにおける マイクロサービスで考察する
22. マイクロサービスにおける サービスの考え方
23. サービスの境界を考える • DDDでの境界付けられたコンテキストを定義するように、コン テキストマップを作る • サービスをビジネスの境界で切るのか、機能の境界で切るの かこれは悩ましい問題 • サービス分割を行った結果が正しいかは、その組織にしかわ からない
24. サービスの境界を考える（イメージ）
25. 境界は組織を作る 境界定義をするということ、 それは組織をつくること
26. コンウェイの法則 “システムを設計する組織は、 その構造をそっくりまねた構造 の設計を生み出してしまう”
27. ECサイトで 境界を定義してみる
28. ECサイトにおける境界の定義の例 • Order • Cart • Catalog(Products) • User • Payment • Inventory • Shipping
29. イメージしてみた マイクロサービスの粒度に沿って サービスを作る。 （各サービスの中にモジュールの イメージを記載）
30. 浮き彫りになる課題 • 適切なサービス分割ができているのだろうか • この単位でデータベース分割をできるのか • 分散トランザクションをどうするのか • 全サービスから利用されるサービスのパフォーマンスをどうす るのか • このサービス量を運用できるのだろうか
31. ステップを踏まずに いきなりマイクロサービスを目指すと リスクが高すぎる
32. 考え方を変える
33. ストラングラーアプリケーションパターン という考え方
34. ストラングラーアプリケーションパターン Martin Fowlerが提唱した、大規模な Web アプリケーション内のコー ドをリファクタリングしてリリースする際の処理方法 • 変換: 既存のサイトと同等の新しいサイトを作成 • 共存: 既存のサイトから新しいサイトにリダイレクトするために、機 能を増分的に実装 • 排除: 古い機能からリダイレクトされるようになったら、既存のサ イトからその機能を削除
35. ストラングラー アプリケーションパターン × Service-Based Architecture
36. モノリスの課題を解決できそうな "可能な限り共有の少ない" アーキテクチャ
37. いきなりマイクロサービスはやらない • ある程度のファットサービスにする • モノリスデータベースを使い続ける • BFFはつくらない 今は Service-Based Architecture が適していそう
38. Service-Based Architecture でイメージする サービスの粒度が荒くなるが、シン プルになる
39. それでも課題はたくさんある • 分散トレーシング • 計算された並列処理 • データベースボトルネック • 開発難易度の増大 • フロントとAPIの密結合化
40. 進化するアーキテクチャ 退化するアーキテクチャ
41. その選択は進化なのか退化なのか それは組織にしかわからない 我々にできることは「何を解決したいのか」 課題から始めること
42. いきなりマイクロサービスはだめ マイクロサービスはある日突然なるわけではない 日々、課題を解決していて気づいたらマイクロサービ スになっているもの
43. マイクロサービスと聞こえたら
44. 何を解決しようとしているのか考えよう
45. 今、 解決するべきか 考えよう
46. 今の課題を解決して一歩ずつ進んでいこう
47. ご清聴ありがとうございました