モノリスとマイクロサービスの橋渡し - ベターからモアベターへ - 白土 慧, Kei Shiratsuchi, @kei_s ϦΞʔΩςΫνϟʹ͓͚ΔΞϯνύλʔϯ΁ͷ޲͖߹͍ํͱ࣍ͳΔ௅ઓ, 2024.06.18(Tue)

自己紹介 • 白土 慧 （シラツチ ケイ） • kei-s • @kei_s • 2021〜: 株式会社アンドパッド • リアーキテクティングチーム（リアーキチーム）を立ち上げ • 主に大規模な Rails アプリケーションを対象

このトークでは • 多様なサービスを提供するためのアーキテクチャについて、ANDPADの 事例として、Railsとマイクロサービス間のgRPC通信を例にお話しします • 現在進行形でアーキテクチャを進化させています • アンチパターンではなく、正攻法な進化と捉えています • トークの流れ • ANDPADのサービス成長の歴史 • モノリスとマイクロサービスの接続 • 利点・トレードオフと、変化への対応

前提 • ANDPAD： 建築・建設業向けのSaaS • 様々な業務ドメイン向けのプロダクトを提供 • 施工管理、検査、チャット、etc… • 顧客がサービスを様々な組み合わせで利用できる • 提供するプロダクトが多く、開発チームも多い

ANDPADサービスと アーキテクチャの(ざっくり)歴史

古代: 単一サービスのRailsアプリ • 2016年サービス提供開始時 • 施工管理サービスをRailsで構築 • 施工管理にまつわる新機能を実装 • 黒板 • 検査 • … 本体Rails 施工管理 黒板 検査

中世: 新規サービスをモノリスに構築 • 現場ではなく、建築事務所での業務をサポート するサービス • 引合粗利管理 • 本体Railsに新たなドメインのサービスが追加 • ユーザ、案件データなどを施工管理サービ スと共有しているが、独自の画面・データ モデルが増える • モジュラモノリスとして切り出しうるが、当時 はそのような仕組みが整備されていなかった 本体Rails 施工管理 引合粗利管理

近代: 新サービスを別なRailsアプリで提供 • 建築事務所向けに新サービスを立ち上 げ • 受発注 • 開発速度を重視し、本体と別に新規 Railsアプリを立ち上げ • 本体Railsアプリの肥大化を回避 • 開発メンバーはRailsエンジニアが 多かった • 本体RailsとREST APIで連携 本体Rails 施工管理 受発注 Rails 引合粗利管理

現代: 新規サービスをマイクロサービス化 • 新たなドメインへの参入。本格的にVertical SaaSへ • 職人の稼働管理 • … • 新規サービスを次々と出していきたい • マイクロサービス化 • 各サービスごとに技術選定、gRPC で連携 • ユーザデータは共通化、サービス特有の データはそれぞれのサービスが持つ • Goエンジニアの増加 本体Rails 施工管理 受発注 Rails マイクロ サービス マイクロ サービス 引合粗利管理

注意 • この発表ではマイクロサービスと呼称していますが、一 般的なマイクロサービスの定義とはズレがあります。 • 実際には、一つのプロダクトが一つのサービスになって おり、いわゆるマイクロサービスよりは粒度が大きいで す。 • 一般的な定義である、単一の永続化ストレージに依存せ ずにデプロイ・開発できる状態を目指しています • 絶賛取組中です

ANDPADアーキテクチャの歴史まとめ • 古代: 単一サービスのRailsアプリ • 中世: 新規サービスをモノリスに構築 • 近代: 新サービスを別なRailsアプリで提供 • 現代: 新規サービスをマイクロサービス化 • 巨大なモノリスと外部サービス群という構成

モノリスと マイクロサービスの連携

gRPCによる通信 • モノリスとマイクロサービス、マイクロサービス間の連携 には gPRC による同期通信を採用 • パフォーマンス • スキーマ駆動 • Goエンジニアが主導し、導入・キャッチアップがスムー ズに進んだ

マイクロサービス導入時の実装 • gRPC APIサーバをGoで実装 • 本体RailsアプリのDBを直接参照する • 基本的に参照系のみを実装 • マイクロサービスからの通信は参照系 が大半 • ユーザデータの確認、案件ステータ スの同期 • 更新が必要な際は、本体Railsに更新 用REST APIを追加し呼び出す 本体Rails マイクロ サービス マイクロ サービス DB gRPCサーバ

利点・トレードオフと 変化への対応

利点とトレードオフ • 利点 • 比較的シンプルな実装で、すぐに提供開始できる • 複雑な本体Railsから独立して開発できる • 高速にレスポンスできる

利点とトレードオフ • トレードオフ • 本体Railsのモデルを用いないため、ビジネスロ ジックが分散してしまう • 複雑なデータモデルを扱うのが難しい • 更新系APIによるデータ更新は、バリデーション やコールバックなど複雑なロジックを再実装する 必要がある • 本体側のロジック変更に追従するのが難しい

導入からこれまでの判断 • マイクロサービスの導入は不可避 • Vertical SaaSとして目指す状態を本体Railsだけで 実装するのは困難 • 新規サービスで必要なgRPC APIは限られる • コアとなるいくつかのデータのみ • 更新系は少ないだろうという想定 • すぐにでも導入してマイクロサービスを立ち上げたい • → 利点に対して、許容できるトレードオフという判断

これからを見据えて • マイクロサービス化によって、新サービスの提供がス ムーズになった • 今後もマイクロサービスは増えるだろう • 必要なgRPC APIが増えるだろう • 複雑なデータモデルが必要になる可能性がある • ビジネスロジックの乖離に気づけない可能性がある • → トレードオフが重要になってきている

これから • 本体RailsにgRPC APIを実装する • 利点 • Railsのモデルを用いてビジネスロジックを 共通化できる • テストにより、モデルのロジック変更が gRPC APIに影響があることを把握できる • トレードオフ • Go+直接DB参照に比べ、Railsのモデルを 通した操作になるので通信速度が劣化する 可能性が高い 本体Rails マイクロ サービス マイクロ サービス gRPC API

進め方 • 本体RailsにgRPC APIを実装し、一つのマイクロサービス を対象に移行可能か検証 • 本体Railsへの組み込み、リリースフローの実装・検証 • パフォーマンス懸念の検証 • どの程度の速度なら許容可能なのかの検証 • Go実装からの改善ポイントの検証 • 認証方式、スキーマ定義の改善 • 現在、絶賛進行中です💪

まとめ • サービスの進化、時代の変化により、求められるアーキ テクチャは変わっていく • 将来の成長を加味して、早めに判断できると良い • アーキテクチャのトレードオフを把握することで、比較的 安心してアーキテクチャ変更に取り組むことができる