Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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