急成長SaaSを支えた 5年間のアーキテクチャ進化史 マルチテナント化からコンパウンド化まで

アーキテクチャカンファレンス2025
2025-11-21 13:55-14:35 C会場
急成長SaaSを支えた 5年間のアーキテクチャ進化史 マルチテナント化からコンパウンド化まで

Transcript

1. 急成⻑SaaSを⽀えた 5年間のアーキテクチャ進化史 マルチテナント化からコンパウンド化まで 2025/11/21
2. • ⾃⼰紹介 / 弊社紹介 • アーキテクチャ進化史①：マルチテナント化 • アーキテクチャ進化史②：コンパウンド化 • まとめ ⽬次
3. ⾃⼰紹介 / 弊社紹介
4. ⾃⼰紹介 東京⼤学を2015年に卒業 株式会社ワークスアプリケーションズにてエンタープライズ向けの ERPパッケージシステムを開発。 2019年、SEVENRICH GROUPにジョイン。 SEVENRICH GROUPでは、パーソナルジム向けの経営管理SaaS Glialの⽴ち上げ、 完全Web予約制のクリニック CLINIC TEN SHIBUYAの⽴ち上げなど、グループ内外で のOMO（Online Merges Offline）サービスのプロトタイピング‧⽴ち上げを 連続的に⼿掛ける。 その中でAWSやAzureなどクラウドインフラの最適化を請け負うサービス 「CTO booster」を⽴ち上げ、株式会社DELTAをスピンアウト。 以後株式会社DELTAの代表CTOを務める。 丹 哲郎 Tetsuro Tan 代表取締役CTO
5. 弊社概要 会社名 株式会社DELTA 所在地 東京都渋⾕区桜丘町９−８ ＫＮ渋⾕３ビル 2F 設⽴ 2022年 代表者名 丹 哲郎 事業内容 開発組織向け技術⽀援事業 私たちは CTOとエンジニア組織のための テクニカル‧プロフェッショナルです リアーキテクチャやコスト削減などの技術負債解消、 時にはエンジニア特化の採⽤⽀援まで。 エンジニア組織向けに幅広いソリューションを備え、 挑戦と成⻑を⽀え続けます。 グループ元 SEVENRICH GROUP
6. サービスラインナップ 要求仕様に合わせたシステム開発〜納品までを実⾏ システム受託開発 技術負債解消⽀援 完全成果報酬型インフラコスト削減代⾏サービス IaCコードの実装を格安‧最短2週間で代⾏するサービス クラウド利⽤状況の分析を⾏い、コスト状況の可視化するサービス FinOps booster IaC booster エンジニア特化型の採⽤⽀援AIエージェント ⽣成AIエージェント開発 組織/業務課題の解決に最適な ⽣成AIエージェントを構築‧導⼊サービス 技術アドバイザー 技術顧問でエンジニアリング課題の解決をサポート ⽣産性向上⽀援 開発⽀援 主要クラウドサービスに対応した 法⼈向けの請求代⾏サービス DELTAの請求代⾏ ⾔語やフレームワークの 格安‧⾼速バージョンアップ⽀援サービス VersionUp booster クラウドマイグレーション 既存システムのクラウド移⾏を計画‧実⾏し、 最適な運⽤環境へ移⾏
7. 今回のケーススタディ EC/D2C 事業者様の売上・利益を上げることに特化した「売上を逃さない」EC プラットフォーム「ecforce」を提供。 受注や顧客の一元管理はもちろん、多彩なマーケティング機能によりショップの売上を最大化します。 ※1：全導入ショップの年商平均 /集計期間 2019年12月~2020年11月 ※2：ecforceへ移行したショップ 3社の1年経過時点のデータ /集計期間 2017年9月~2020年4月 ※3：ecforceへ移行したショップ 10社の移行前後 6ヶ月の比較データ /集計期間 2017年9月~2020年4月 ※1 ※2 ※3
8. 今回のケーススタディ 2023年に「統合コマースプラットフォーム」としてecforce（ECカートシステム）に限らない複数プロダクト展開構想を発表。 さらに2025年には「AIコマースプラットフォーム」として「ecforce AI」を中心としたAIプラットフォーム化を発表
9. アーキテクチャ進化史①：マルチテナント化
10. マルチテナント化で変わったこと マルチテナント化 コンパウンド化 • テナント数のリポジトリが存在（約300） • ⼿動での環境構築 • コストもテナント数/nぐらいで増加傾向 • デプロイジョブも⻑期化 Before After • リポジトリ数が激減 • 環境構築が⾃動(5分)に • テナントあたりコストが80%削減 • デプロイジョブも短期化
11. 環境開設のリードタイムの⻑さによる機会損失を防ぎたい ecforceの申し込みから⼿動で環境構築をしており、お客様 にecforceの環境を開設するまでに時間を要していた。 未来のコスト増加の抑制 新たなリード導線の導⼊ ショップ提供速度の向上 マルチテナント化検討当時の狙い 1 2 3 認知度向上に伴い発⽣するリードの取りこぼしを防ぎたい タクシー∕テレビ CM による認知度向上施策の実施に伴いト ライアルプランのようなものを実装検討していた マルチテナント化 コンパウンド化 マーケティング施策を打つことで契約件数の伸⻑が⾒込めて おり、コストのショップ数依存からの脱却を図りたい ecforceのインフラコストはショップ数に⼤きく依存（2020.6時点）
12. ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 やったこと①：差分の洗い出し 差分の 洗い出し • 差分洗い出し⽤のStep Functionsを実装 ◦ テナントごとリポジトリのclone ◦ ベースリポジトリもclone ◦ diffを取る ◦ diff結果をS3にアップロード • S3の情報をまとめる（⽣成AIなんて無いので⽬検） マルチテナント化 コンパウンド化
13. 差分の 洗い出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 やったこと②：ｿｰｽｺｰﾄﾞで表現されていた設定をDB切り出し ソースコードで 表現されていた 設定をDBに 切り出し マルチテナント化 コンパウンド化 • config/initializers配下でpuma起動時に初期化されていた 各種設定もDBから逐次取り出しに修正 ◦ action_mailer ◦ Rails.cache ◦ テーマファイル(liquid)の読み込み ◦ sidekiq(引数にtenant idを追加) ◦ sidekiq-cron ◦ loggerへのtenant id tagの追加 ◦ 各種メールに記載のURLのベースパスの変更 ◦ バケット、CDNのディストリビューションID等の動的変更 ◦ ‧‧‧
14. schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し やったこと③：⾃動構築のジョブの構築 ⾃動構築の ジョブの構築 • テナント管理DBへのデータ投⼊ • DNSレコードの払い出し • 管理者ユーザーの払い出し • 各種設定データの投⼊ マルチテナント化 コンパウンド化
15. 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 やったこと④：schema_migrationsテーブルの同期 schema_ migrations テーブルの同期 • リポジトリごとにmigrationファイルのバージョンが異なる • Railsでは、ファイルシステムのmigrationファイルとDBに記録されている 適⽤済みマイグレーションのバージョンが違うとエラーになる • 過去分の適⽤済みマイグレーションのバージョンをsquashし、 バージョンを揃える マルチテナント化 コンパウンド化
16. 移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 やったこと⑤：全修正をﾏﾙﾁﾃﾅﾝﾄ環境とｼﾝｸﾞﾙﾃﾅﾝﾄ環境で同居 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる • 今の環境がマルチテナント環境かどうかを動的に判定 ◦ シングルテナントの場合：ファイルシステムの設定を読み込み ◦ マルチテナントの場合：データベースから設定を読み込み • これらの処理の動的な差し替えのため、メタプログラミングを多⽤した ◦ Rubyでなければもっと⾟かったはず‧‧‧ マルチテナント化 コンパウンド化
17. Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる やったこと⑥：移⾏ジョブの構築 移⾏ジョブの 構築 • マイグレーションバージョンの同期 • 既存設定の抽出 • 既存設定をデータベースに投⼊ • 同期、投⼊の成否をチェック • マルチテナントフラグを⽴てる • 公開！ マルチテナント化 コンパウンド化
18. 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 やったこと⑦：Makara(当時)との同居 Makara(当時) との同居 • リーダーインスタンスへのSELECTクエリのルーティングを⾏うgem • 複数のコネクションを取り回す設計となる = ミドルウェアで、リクエスト 時にコネクションを use 句で切り替えるApartment gemとの⾷い合わせが 極端に悪い • マルチDB x マルチテナンシーの実現が⼤きな課題 ◦ 結局、Makaraのアダプタを⾃作 ◦ Makara側がコネクションを切り替える際に、再度テナントを参照して その都度切り替える設計 マルチテナント化 コンパウンド化
19. 初期の設計の優れた点 共通化と⾮共通化のセンス ec_force gem (rails engine) ec_force_app_mothwing ec_force_app_xxx ec_force_app_xxx ec_force_app_xxx • コアな処理は全て共通のgemとして実装されていた • 分散していたリポジトリ群は、ほぼ共通のgemを呼び出すのみの薄い実装だった • 将来の共通化を⾒越した賢い設計 マルチテナント化 コンパウンド化
20. アーキテクチャ進化史②：コンパウンド化
21. 【再掲】今回のケーススタディ 2023年に「統合コマースプラットフォーム」としてecforce（ECカートシステム）に限らない複数プロダクト展開構想を発表。 さらに2025年には「AIコマースプラットフォーム」として「ecforce AI」を中心としたAIプラットフォーム化を発表
22. コンパウンド化で変わったこと • プロダクトごとに認証‧認可がバラバラ • クロスセル‧アップセルが営業依存 • エンタープライズグレードのID管理に 追従しづらかった • プロダクトごとに選定技術もバラバラ Before After • 共通の認証基盤を構築 • ポータル画⾯を⽤意、将来のクロスセル ⾃動化を⾒越せるように • 認証基盤とエンタープライズIDを 接続できるように • SDKを実装し、技術依存の箇所を局所化 マルチテナント化 コンパウンド化
23. やったこと①：共通の認証基盤の構築 • 全てのプロダクトにOIDCクライアントを実装 • 共通のOIDC ID Providerを実装 • セッション管理機構も⼀部共通化 ecforce accounts (ID Provider) ecforce ecforce chat ecforce check ecforce bi Salesforce(契約管理) 横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 SDKの実装 共通の 認証基盤の構築 マルチテナント化 コンパウンド化
24. 横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 SDKの実装 共通の 認証基盤の構築 やったこと②：横断ポータルの実装 • SSO⽤のポータルのフロントエンドを実装 • 権限管理、招待/revoke、各プロダクトへのログインを⼀元化 • 将来的にはポータル上での請求管理、別プロダクトの購買も可能な導線 • 各プロダクトは個別にIdPと通信してOIDCするため、極めて薄く軽量な Webアプリケーションとして実装できた マルチテナント化 コンパウンド化
25. 共通の 認証基盤の構築 移⾏ジョブの 構築 やったこと③：移⾏ジョブの構築 横断ポータルの 実装 エンタープライズID との接続 SDKの実装 • 既存アプリケーションの認証情報を抽出 • パスワードのハッシュアルゴリズムごと共通ユーザープールに移⾏ • 必要な権限を付与 • 対象テナントのSSO有効フラグを⽴てる • 公開！ マルチテナント化 コンパウンド化
26. 共通の 認証基盤の構築 エンタープライズID との接続 やったこと④：エンタープライズIDとの接続 エンタープライズ IdP 共通 IdP ログイン先 アプリケーション 横断ポータルの 実装 移⾏ジョブの 構築 SDKの実装 • 共通IdPの上流に顧客のエンタープライズIDを接続 • 上流のエンタープライズIDからのSSOを実現 ◦ OIDC/SAMLでアイデンティティやロールを受け取る ◦ 共通IdP側の属性に読み替え ◦ 権限をassume マルチテナント化 コンパウンド化
27. SDKの実装 共通の 認証基盤の構築 やったこと⑤：SDKの実装 横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 • 共通の認可基盤との通信を⾏うためのSDKリポジトリを実装 • プロトコルはConnect (gRPC)ベースだが、クライアントを含めて 各⾔語向けにビルドしてプライベートレジストリから配信 • 各プロダクトの開発者はSDKを呼び出すだけ • SDK側にトレーシング‧リトライの機構をミドルウェアとして積むことで 中央集権的な管理を実現 マルチテナント化 コンパウンド化
28. 初期の設計の優れた点 設計として「捨てる」箇所のセンス • 権限管理の機構が各プロダクトに（ほぼ）実装されていなかった • 認証機構もごくシンプルなID/PW形式のみに敢えてしていた • 将来的に中央集権的な認証認可基盤が実装されることを⾒越して、 敢えて各プロダクトで個別に持つべき箇所を最⼩化していた マルチテナント化 コンパウンド化 結果的に、各プロダクトへの影響を最⼩化して ⼤規模な基盤の差し替えに成功
29. まとめ
30. マーケティングへの投資を⾒込んだ構築⾃動化の実現、 コンパウンド化/エンタープライズ戦略を⾒込んだID基盤。 ビジネス上の要求を先読みして技術投資をタイムリーに⾏ う。 共通化‧個別化のセンス 設計を「捨てる」センス 技術投資とビジネスの同期 まとめ：SUPER STUDIO社の事例から学ぶ3つのポイント 1 2 3 将来的に共通化が⾒込まれる箇所は、敢えて個別での実装 を⾏わずに運⽤⾯でカバーする意思決定も効いてくる 最初からマルチテナンシを作り込むと実装コストが嵩み、 noisy neighborも発⽣する。しかし、完全に個別化すると 管理コストが⾼まり将来の共通化も⾟くなる。 良いバランスを⾒極める
31. まとめ：CTOの役割とは？ 「ビジネスを意識した技術意思決定」の真髄は「タイミング」 • YAGNI(You Ain’t Gonna Need It)原則に沿って早すぎる最適化は避ける • 将来の拡張性は「⾒込む」が「作り込まない」 ◦ エンジニアの習性として、特にメガベンチャー出⾝のCTOは初期から作り込んで しまう ◦ ビジネスは不確実であり、作り込んだものが無駄になってしまう危険性もある • しかし、どこかでリアーキテクチャリングは必要になる この「どこかで」を⾒極め、ビジネスが今後2-3年でどう動くか。 それに必要な⾮機能特性は何かを⾒据えて、タイムリーに技術投資することが CTOとしての「ビジネスを意識した技術意思決定」なのではないか
32. CTOの役割とは？ 親孝⾏したいときに親はなし • 将来のためにやるべきことが⾒えたとしても、現場のエンジニアはロードマップの 実現に忙しい • CTOやテックリード本⼈が⼿を動かせる領域は相対的に狭くなっていく • 技術投資は、⾦銭的な投資と同じく、資⾦があればできるわけではない ◦ 投資先のソーシングと選定が重要 ロードマップやスクラムの「外」にある課題こそ 外注という選択肢も有効ではないか？ ▶ DELTAにぜひご相談を！
33. EOF