マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ

Transcript

1. マルチプロダクト×マルチテナントを支える モジュラモノリスを中心としたアソビューのアーキテクチャ アソビュー株式会社 兼平大資 2025/08/07 インフラアーキテクチャ選択のジレンマ - 5社の設計思想と意思決定のリアル
2. Name: 兼平大資 Company: アソビュー株式会社 Role: CTO X: @disc99_ About Me 2
3. 1. About Me 2. アソビューとアーキテクチャ 3. ジレンマとコアとなる考え方 4. 意思決定のリアル 5. まとめ アジェンダ 2
4. 1. About Me 2. アソビューとアーキテクチャ 3. ジレンマとコアとなる考え方 4. 意思決定のリアル 5. まとめ アジェンダ 2
5. アソビューとは 3
6. 事業の全体像 4
7. プロダクトの全体像 5
8. 事業規模と実績 運営歴: 最初のプロダクト立ち上げから13年（2012年〜） プロダクト展開: マルチプロダクト（プロダクト数: 20+） 大規模ユーザー: toC 会員数1,700+万人、toB 契約施設数10,000+店舗 技術的特徴と課題 モール型の複雑性: アソビュー！の商品数、バリエーションの柔軟性 高トラフィック: モールだけでなく、SaaS型（ウラカタ）も含め、ピークトラフィック4,000+ rps ピーク性: 商品、施設、季節、時間による急激な負荷変動 データ整合性: 多数のプロダクトからのアクセスに対する在庫の一貫性 サービス品質: SaaSは施設の日常業務を支えるため、高信頼性・高可用性が重要 組織と成長戦略 プロダクト組織: 約100名の開発体制 新規事業+グロース: 会員と商品データを起点とした事業立ち上げ+既存事業の多角化 事業とプロダクトの特徴 6
9. インフラアーキテクチャの全体像 7
10. 1. About Me 2. アソビューとアーキテクチャ 3. ジレンマとコアとなる考え方 4. 意思決定のリアル 5. まとめ アジェンダ 7
11. よくある選択肢 モノリス vs マイクロサービス vs モジュラモノリス シングルテナント vs マルチテナント vs ハイブリッドモデル 単一DB vs DB分離 REST vs GraphQL vs gRPC 同期通信 vs 非同期通信 モノレポ vs マルチレポ 単一言語 vs マルチ言語 オンプレミス vs 単一クラウド vs ハイブリッドクラウド アーキテクチャ選択のジレンマ 8
12. ミッションや事業内容をもとに選択するのは言わずもだが 他に何をもとに選択するべきか？ 9
13. アーキテクチャの原則 「アーキテクチャには正解も不正解もない。あるのはトレードオフ だけだ。 」 ― ソフトウェアアーキテクチャの基礎 Mark Richards, Neal Ford アーキテクチャのトレードオフ 10
14. 漸進的な変更を支える技術 「進化的アーキテクチャの定義には、漸進的な変更が含まれてい る。これは、アーキテクチャは小さく漸進的な変更を容易にしなけ ればならないということを意味している。 」 ― 進化的アーキテクチャ - 絶え間ない変化を支える Neal Ford, Rebecca Parsons, Patrick Kua アーキテクチャの進化 11
15. Conway's Law 「システムを設計する組織は、その組織の構造をそっくりまね た構造の設計を生み出してしまう」 ― Melvin Conway (1967) Inverse Conway Maneuver 目指すアーキテクチャから組織構造を設計する martinfowler.com - Conway's Law アーキテクチャと組織 12
16. 1. About Me 2. アソビューとアーキテクチャ 3. ジレンマとコアとなる考え方 4. 意思決定のリアル 5. まとめ アジェンダ 12
17. モノリス vs マイクロサービス vs モジュラモノリス アソビューの選択: モジュラモノリス + マイクロサービス(一部) 判断理由 開発効率: 単一ソース・デプロイで開発スピード維持、マルチプロダクトにも対応可 柔軟性・可逆性: モジュールを柔軟に切り替えることで、マイクロサービス化が可能 運用負荷: インフラ管理の複雑性を抑制 チーム規模: プロダクト特性や組織を考えたときの現実解 実装 境界づけられたコンテキストでモジュール分割 モジュール間はgRPCインターフェイスで統一 必要に応じて部分的にマイクロサービス化 アーキテクチャパターンの選択 13
18. 環境変数による柔軟な起動モード シングルソース・マルチデプロイメント: 同一のソースコ ードベースから、デプロイメントの環境変数でモジュー ル切り替え 運用に応じた選択: トラフィック状況や要件に応じて選択 することで開発速度とスケーラビリティ、パフォーマン スを最適化 段階的移行とロールバック: モノリス → モジュラモノリ ス → マイクロサービスモード → フルマイクロサービス 起動パターンの例 モノリスとして起動も、マイクロサービスとして起動も 可能 例: ローカルではモノリス、サーバーではマイクロサービ ス(プロダクト単位/機能単位/テナント単位) # モノリス起動（全モジュール） export ACTIVE_MODULES=* # 特定モジュールのみ起動 export ACTIVE_MODULES=activity,reservation export ACTIVE_MODULES=payment モジュラモノリスのマイクロサービスモード 14
19. en-ambi.com - モジュラモノリスに移行する理由 ─ マイクロサービス の自律性とモノリスの一貫性を両立させるアソビューの取り組み speakerdeck.com - モノリスとマイクロサービ スを経てモジュラモノリスを導入した実践事例 モノリス、マイクロサービスからモジュラモノリスへ 15
20. シングルテナント vs マルチテナント vs ハイブリッドモデル アソビューの選択: マルチテナント（EKSシングルクラスター） 判断理由 運用効率: 単一クラスターによる管理コスト削減、セキュリティ・監視・アップグレードの一元管理 スケーラビリティ確保: Kubernetesならシングルクラスターでも十分なスケーラビリティを実現(HPA、 VPA、Cluster Autoscaler、PDB) ネットワーク最適化: クラスター内通信による低レイテンシとセキュリティ向上 トレードオフ メリット: 運用コスト削減、スケーラビリティ確保、デプロイ効率化 リスク: 障害時の影響範囲拡大（デプロイメント分離で軽減） インフラ構成の選択 16
21. 単一DB vs DB分離 アソビューの選択: DB分離（機能別） 判断理由 歴史的進化: 単一DBから始まり、成長に伴い段階的に分離 可用性重視: マルチテナント特性によるノイジーネイバー問題への対策 障害分離: DB分離により可用性は向上、一方でトランザクション・コストに課題 柔軟な対応: 物理インスタンス共有でスキーマ分離という選択肢も活用 実装 Aurora (MySQL/PostgreSQL): メインのプロダクトDBとして利用 Cloud Spanner: スケーラビリティが重要な新規プロダクトで利用 DynamoDB、Redis: 高速アクセスが必要なキャッシュ・セッションデータ データの寿命は長いので、DBの選択はプロダクトにおいて非常に重要な判断 データベース設計の選択 17
22. REST vs GraphQL vs gRPC アソビューの選択: gRPC + REST 判断理由 Protocol Buffersのエコシステムを中心とした選択 統一スキーマ定義: IDLから標準でgRPC、OpenAPI経由でRESTの両方に対応 高速で効率的な通信: 高トラフィックなプロダクトのためシリアライゼーション効率とネットワーク最 適化は重要 マルチプロダクト統一: プロダクト間でのAPI仕様統一によるメンテナンス性向上 使い分け: 外部はREST（ブラウザ通信・外部連携のデファクト） 、内部はgRPC（性能重視） トレードオフ 効果: API応答速度改善、ネットワーク効率向上 課題: デバッグツール充実が必要、学習コスト API設計の選択 18
23. speakerdeck.com - 全てのAPIをProtocol Buffersで管理する Protocol BuffersによるAPI管理 19
24. 同期通信 vs 非同期通信 アソビューの選択: 混在（gRPC + Kinesis Streams） 判断理由 リアルタイム性: gRPCで即座な応答が必要な処理 可用性: イベント駆動で耐障害性を確保 プロダクト間連携: プロダクト間での効率的なデータ同期と整合性、高トラフィックに対する負荷軽減 適材適所: 用途に応じた最適な通信方式選択 実装 同期: gRPC（API呼び出し） 非同期: Kinesis Streams（イベント処理） 通信方式の選択 20
25. speakerdeck.com - イベント駆動型マイクロサービスアーキテクチャ 同期通信と非同期通信 21
26. モノレポ vs マルチレポ アソビューの選択: モノレポ 判断理由 可視性向上: 全ソースコードの1リポジトリで統一管理 統一ルール: 共通CI/CD、コーディング規約 アトミックな変更: 複数サービス・コンポーネントの変更を単一コミットで実現 企業・エンジニアバリュー: マルチプロダクトであってもONE TEAM、フルサイクルエンジニアの実現 効果 IDE・エディタでの全ソース検索が可能 横断的な修正が単一PRで完結 あらゆるソース、ナレッジの一元管理 AIツールが全コンテキストを読み込める リポジトリ構成の選択 22
27. speakerdeck.com - 120リポジトリを1つのMonorepoに統合した理由 Monorepoへの移行 23
28. オンプレミス vs 単一クラウド vs ハイブリッドクラウド アソビューの選択: AWS中心のクラウド 判断理由 スケーラビリティ: 季節性・時間性による急激な需要変動（4,000+rps）への対応 マルチプロダクト・マルチテナントの運用: インフラを統一プラットフォームで効率的に管理、安定し たサービス提供とテナント分離 運用効率: マネージドサービス活用による運用負荷軽減 実装 EKS、Aurora、DynamoDB、Kinesis 一部Google Cloud併用（BigQuery、Spanner等） インフラ基盤の選択 24
29. 単一言語 vs マルチ言語 アソビューの選択: バックエンドJava中心(Spring Boot)、フロントエンドTypeScript(React) 判断理由 運用安定性: パフォーマンス、セキュリティ、後方互換性、各種サービスのSDKサポート品質など高い 信頼性、ランタイムの一貫性、モジュラモノリスとの相性 柔軟性・採用容易性: 他のプロダクトでも積極的に参加できる、豊富な人材プール(必要に応じて他言語 も活用) AI対応: LLM学習データの豊富さ トレードオフ メリット: 人材確保・運用安定性・AI活用の容易さ 課題: パフォーマンス要求の高い処理、特定領域での最適化限界 技術スタックの選択 25
30. 現在の課題と今後の計画 DB利用の非効率性: 似たような特性を持つDBを必要以上に利用 → 統一していく API Gateway運用の複雑性: REST/gRPC変換の静的コード生成、アグリゲーション処理変更によるデプ ロイ頻度増加、パフォーマンスの劣化 → 動的変換とアグリゲーション処理の移行 ノイジーネイバー問題: アプリケーション・DBでの影響検知が困難 → 動的スケールなトラフィック分離 よる自動対応 イベント処理のスケール限界: 現状の非同期処理基盤での制約 → 新たな非同期連携基盤構築 AI活用の開発効率化: モノレポでのビルド・CI/CD最適化不足 → AI活用によるビルドツール・CI/CD強化 今後の展望 26
31. 1. About Me 2. アソビューとアーキテクチャ 3. ジレンマとコアとなる考え方 4. 意思決定のリアル 5. まとめ アジェンダ 26
32. 完璧なアーキテクチャは存在せず、常にトレードオフを意識してコンテキストに応 じた最適解を見つける ビジネスドメインの深い理解がアーキテクチャ選択の精度を決める 変化の激しい環境では段階的移行戦略でリスクを最小化し、可逆性を意識する アーキテクチャと組織構造は表裏一体 アソビューではシステム横断でのデータ再利用や迅速な開発のための「集約」と、負 荷分散や権限分離などの「分割」を使い分ける戦略を採用 まとめ 27