Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
まとめ • サービスの進化、時代の変化により、求められるアーキ テクチャは変わっていく • 将来の成長を加味して、早めに判断できると良い • アーキテクチャのトレードオフを把握することで、比較的 安心してアーキテクチャ変更に取り組むことができる