Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ff655584d57df8448153fa618cc86db3?s=47 Daisuke Sato
February 08, 2019

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

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

## イベント

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

## 参考

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

Ff655584d57df8448153fa618cc86db3?s=128

Daisuke Sato

February 08, 2019
Tweet

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. よーいドン! で、マイクロサービスを 目指すと

  13. None
  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. ご清聴ありがとうございました