🐙
マイクロサービス？モノリス？SaaSアーキテクチャのPros/Cons | SaaS.tech #1
概要
2022/03/15に開催された下記勉強会のメモです
セッション
アプリケーションが大きくてつらい……ってコト！？
- SmartHR「本体」-> ふつうのRails
- でかい三銃士
- コードベース
- テーブル規模
- エンジニアの人数
大きくてつらいに対してどのようなアプローチを取ろうとしているか
- 「つらい」と感じていることが「こうだったら良いなあ」をあげてみる
- まずは何が問題なのかを発散->「つらい」問題の方向性が見えた
- エンジニアだけでなくPM陣も参加（でTake2）
- 何が「コア機能」かの共通認識を得た
- 機能を切り出すよりリファクタの方が効果高そう
- コストと解決した時の嬉しさをマッピングして優先度判断
モジュラーモノリスに夢を見ても良いか？
- Spotifyの事例を参考
- メリットは高そうだがRails（ActiveRecord）だと扱いが難しい
- まずはリファクタを進める
リファクタリングをどう進めるか
- 機能開発しているチームでPoC進めるのは難しい
- Scrum（LeSS）で別チームを短期編成
その他：資料に出てきたBiTemporal Data Modelの話はこちら
絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ
基本構成
- SPA + Backend API (Nuxt.js + Golang)
- 各プロダクトごとのマイクロサービス
- DBはマイクロサービスをまたいで共有しない
- プロダクト間の循環参照は避ける
マイクロサービスのケーススタディ
- 循環参照を避けるためデータの自動同期（非同期）
- リトライ
- データ不整合の定期的な監視とアラート
- パフォーマンス対策としてのレプリケーション
アーキテクチャ再考
- マイクロサービスのモノリス化をトライ
- 循環参照問題は解決しなかった
- 組織のスケールという流れに逆行
- 撤退
デモつき！動かしてわかる はじめてのPact
コンシューマ駆動テスト
- Consumer(Webサービス)とProvider(APIサービス)の間でContractを結び、Contractに違反していないことをConsumer,Providerでテスト
- Contractの内容はリクエストとレスポンスのセット
デモで動かしたものはこちら
利用事例
コンシューマ駆動テスト・Pactについて
Scalebaseがモノリスでもなくマイクロサービスでもなくモジュラモノリスを採用した理由
- 最初はモノリスでスタート
- スタートアップはスピード命
- ビジネスフェーズと組織規模にマッチしない
- ドメイン設計の改善
- 全く違うドメイン・コンテキストが制約もなく開発が続けられれば、時間と共に密結合になる未来は避けられない
- モジュラモノリスの採用
- 意識的・強制的にコンテキスト分割を可能にする設計の実現
カオナビにおけるマイクロサービスの取組と今後の展開
基本構成
- PHP(Laravel), AWS(EC2), モノリシック
問題点
- ソースコード
- 暗黙知の増大、機能ごとにアーキテクチャが異なる等
- Dev/Opsの認知負荷が増大
- インフラ
- EC2からECS等に乗り換えたい
- ソフトウェアエンジニアがもう少しインフラレイヤーに踏み込める形が望ましい
- チーム開発
- 開発チームは機能開発後に解散
- Opsが日に日につらくなる
マイクロサービス
- 相当な困難がありそう
- 事例はチラホラ、BFFなど
- 結果として縦割り組織ができないか
- カスタマーサクセスの阻害要因にならないか
- 慎重な組織設計が求められる
- 考慮することがたくさん
- その後の運用
- チーム体制
- ログ、デバッグ、結果整合性
モジュラモノリス
- モノリスと適切なモジュラー分割できないのはマイクロサービス以前
- 実例は少しずつでてきている
モノリスの複雑化の増大に対してどうやって軽減、改善していくか
- モノリスを水平・垂直で考える
水平
- ミドルウェアで切り出されるような機能郡
- 認証
- 通知
- メール送信
- バッチ
- コアドメインから疎結合にしやすい
- マネージドサービス利用、マイクロサービスとして分割
垂直
- 機能単位にパッケージにして名前空間・ディレクトリで分割
- 機能単位のソースコード郡
- 各機能から使われる共通モジュール
- フレームワーク
- パッケージによる責務分離で全体の認知負荷を軽減
大切にしていること
- 既存の価値提供が毀損されない
- セキュリティに脆弱な構成にならない
- ビッグリライトを避ける
アーキテクトが価値を提供する相手
- 顧客だけでなく開発者の開発者体験にも寄与したい
- チャレンジの余地を残すアーキテクチャの模索
実際に取り組んでいること
- プロトタイピングによる実験
- Composer Packageを使ったモジュールの分割
- リファクタリング
- 考古学調査
- Unknown unknownの掘り出しと文書化
- 曖昧・複雑な仕様の調査と文書化
問題から目をそらさない！
Discussion