🐙

マイクロサービス?モノリス?SaaSアーキテクチャのPros/Cons | SaaS.tech #1

2022/10/12に公開

概要

2022/03/15に開催された下記勉強会のメモです
https://saas-tech.connpass.com/event/239175/

https://www.youtube.com/watch?v=YJ6Uv6cUFdM

https://togetter.com/li/1859424

セッション

アプリケーションが大きくてつらい……ってコト!?

  • SmartHR「本体」-> ふつうのRails
  • でかい三銃士
    • コードベース
    • テーブル規模
    • エンジニアの人数

大きくてつらいに対してどのようなアプローチを取ろうとしているか

  • 「つらい」と感じていることが「こうだったら良いなあ」をあげてみる
    • まずは何が問題なのかを発散->「つらい」問題の方向性が見えた
  • エンジニアだけでなくPM陣も参加(でTake2)
    • 何が「コア機能」かの共通認識を得た
  • 機能を切り出すよりリファクタの方が効果高そう
    • コストと解決した時の嬉しさをマッピングして優先度判断

モジュラーモノリスに夢を見ても良いか?

  • Spotifyの事例を参考
  • メリットは高そうだがRails(ActiveRecord)だと扱いが難しい
  • まずはリファクタを進める

https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity

リファクタリングをどう進めるか

  • 機能開発しているチームでPoC進めるのは難しい
    • Scrum(LeSS)で別チームを短期編成

その他:資料に出てきたBiTemporal Data Modelの話はこちら

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ

基本構成

  • SPA + Backend API (Nuxt.js + Golang)
  • 各プロダクトごとのマイクロサービス
  • DBはマイクロサービスをまたいで共有しない
  • プロダクト間の循環参照は避ける

マイクロサービスのケーススタディ

  • 循環参照を避けるためデータの自動同期(非同期)
    • リトライ
    • データ不整合の定期的な監視とアラート
  • パフォーマンス対策としてのレプリケーション

アーキテクチャ再考

  • マイクロサービスのモノリス化をトライ
    • 循環参照問題は解決しなかった
    • 組織のスケールという流れに逆行
    • 撤退

デモつき!動かしてわかる はじめてのPact

https://hello-cdc.sat0shi.dev/1

コンシューマ駆動テスト

  • Consumer(Webサービス)とProvider(APIサービス)の間でContractを結び、Contractに違反していないことをConsumer,Providerでテスト
  • Contractの内容はリクエストとレスポンスのセット

デモで動かしたものはこちら
https://github.com/toyamarinyon/sat0shi-store

利用事例
https://techlife.cookpad.com/entry/2016/06/28/164247
https://developers.freee.co.jp/entry/introduction-of-pact
https://note.com/sys1yagi/n/n93a3d8f4a64a

コンシューマ駆動テスト・Pactについて
https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/
https://pactflow.io/how-pact-works/#slide-1
https://pactflow.io/blog/schemas-are-not-contracts/
https://pactflow.io/blog/proving-e2e-tests-are-a-scam/

Scalebaseがモノリスでもなくマイクロサービスでもなくモジュラモノリスを採用した理由

  • 最初はモノリスでスタート
    • スタートアップはスピード命
    • ビジネスフェーズと組織規模にマッチしない
  • ドメイン設計の改善
    • 全く違うドメイン・コンテキストが制約もなく開発が続けられれば、時間と共に密結合になる未来は避けられない
  • モジュラモノリスの採用
    • 意識的・強制的にコンテキスト分割を可能にする設計の実現

カオナビにおけるマイクロサービスの取組と今後の展開

基本構成

  • PHP(Laravel), AWS(EC2), モノリシック

問題点

  • ソースコード
    • 暗黙知の増大、機能ごとにアーキテクチャが異なる等
    • Dev/Opsの認知負荷が増大
  • インフラ
    • EC2からECS等に乗り換えたい
    • ソフトウェアエンジニアがもう少しインフラレイヤーに踏み込める形が望ましい
  • チーム開発
    • 開発チームは機能開発後に解散
    • Opsが日に日につらくなる

マイクロサービス

  • 相当な困難がありそう
    • 事例はチラホラ、BFFなど
  • 結果として縦割り組織ができないか
  • カスタマーサクセスの阻害要因にならないか
  • 慎重な組織設計が求められる
  • 考慮することがたくさん
    • その後の運用
    • チーム体制
    • ログ、デバッグ、結果整合性

モジュラモノリス

  • モノリスと適切なモジュラー分割できないのはマイクロサービス以前
  • 実例は少しずつでてきている

モノリスの複雑化の増大に対してどうやって軽減、改善していくか

  • モノリスを水平・垂直で考える

水平

  • ミドルウェアで切り出されるような機能郡
    • 認証
    • 通知
    • メール送信
    • バッチ
  • コアドメインから疎結合にしやすい
  • マネージドサービス利用、マイクロサービスとして分割

垂直

  • 機能単位にパッケージにして名前空間・ディレクトリで分割
    • 機能単位のソースコード郡
    • 各機能から使われる共通モジュール
    • フレームワーク
  • パッケージによる責務分離で全体の認知負荷を軽減

大切にしていること

  • 既存の価値提供が毀損されない
  • セキュリティに脆弱な構成にならない
  • ビッグリライトを避ける

アーキテクトが価値を提供する相手

  • 顧客だけでなく開発者の開発者体験にも寄与したい
  • チャレンジの余地を残すアーキテクチャの模索

実際に取り組んでいること

  • プロトタイピングによる実験
  • Composer Packageを使ったモジュールの分割
  • リファクタリング
  • 考古学調査
    • Unknown unknownの掘り出しと文書化
    • 曖昧・複雑な仕様の調査と文書化

問題から目をそらさない!

Discussion