クラスタ統合リアーキテクチャ全貌～1,000万ユーザーのウェルネスSaaSを再設計～

アーキテクチャconference 2025

株式会社hacomono
基盤本部 プラットフォーム部 プラットフォームエンジニア

本セッションでは10,000店舗、登録者数1,000万人を支えるウェルネス向けSaaS hacomonoにおける今後のリアーキテクチャ戦略についてご紹介します。
hacomonoではテナントグループ毎にECSクラスタを分割して運用していました。
しかし事業のスケールに伴い、リソース効率の悪化、テナント間の環境差異、オペレーションコストの増加など様々に直面しています。
これらの課題を解消し、持続可能な事業成長を支えるためのクラスタ統合戦略、そして実現のための具体的な技術アプローチについてご紹介いたします。

Transcript

1. Last Update 2022.03.16 クラスタ統合リアーキテクチャ全貌 1,000万ユーザのウェルネス SaaSを再設計 株式会社hacomono 居石峻寛
2. 2 自己紹介 居石峻寛 (Oriishi Takahiro) • 株式会社hacomono • プラットフォームグループ所属 • 徳島県に生息地 経歴 • インフラエンジニア • フルスタックエンジニア • プラットフォームエンジニア ← now X: hetare70914
3. section 01 プロダクト紹介
4. 4 hacomonoとは 4 ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー・ ウェルネス施設の手続きをすべてデジタル化 ウェルネス産業を、新次元へ。
5. 5 Wellness x Facility デバイス連携 入退館 プロテインサーバー タンニングマシン iPadチェックイン ロックQR ロックワイヤレス AIカメラ 実際に顔を合わせてサービスを提供することの 多いウェルネス産業において、店舗内の設備は 欠かせない存在です。 IoT部門があるhacomonoでは、店舗での設備 をデジタル化 することで、体験向上だけでな く、そこから得られるデータの活用の促進 も進めています。 ウェルネス店舗の物理的な設備を IT化、 高付加価値の顧客体験を
6. 6 10,000店舗・施設での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング
7. 7 新しいフィールドへの挑戦 2026年始め グランドローンチ予定 掲載施設・店舗と ユーザーをマッチング “空き枠の稼働率を上げたい”、“新しい顧客にアプ ローチしたい”などのニーズを持っている施設・ 店舗と、多種多様なニーズを持っているユーザー をマッチング するサービスです。 ユーザーは都合やその日の気分にフィットし たプログラムを都度予約できます。 業界の可能性を無限大に すべての人に「継続する」フィットネスを
8. 8 Utilities 言語／フレームワーク Business Tools DevOps JavaScript Node.js MySQL NGINX TypeScript Vue.js Sass Ruby Rails Swift Golang Tailwind CSS Nuxt.js Storybook Flutter GitHub Docker ESLint Yarn Terraform Ansible Grafana Sentry GitHub Actions Vite Playwright Vitest Mabl Slack Jira Notion Google Workspace Twilio SendGrid GitHub Copilot CodeRabbit CURSOR Devin Claude ChatGPT Notion AI Infrastructure AWS Fargate Amazon EC2 Amazon Lambda Amazon RDS Aurora Serverless v2 Dart hacomonoの技術スタック
9. section 02 アーキテクチャの変遷
10. 10 hacomonoのサービス特性 • 24時間365日の稼働が求められる ◦ 24時間ジムにも導入 ◦ お客様の店舗営業にも致命的な影響 ▪ 入館できない ▪ レッスン予約や会員登録の機会損失 • 予約スケジュール公開時のスパイク
11. 11 サイロモデルとプールモデル AWSのWell-Architectedフレームワークでは2つのモデルが定義 サイロモデル プールモデル
12. 12 初代アーキテクチャ 開発初期ではサイロモデルを採用、テナント毎に占有リソースを用意
13. 13 初代アーキテクチャ 開発初期ではサイロモデルを採用、テナント毎に占有リソースを用意
14. 14 初代アーキテクチャ 開発初期ではサイロモデルを採用、テナント毎に占有リソースを用意 • インフラコストの最適化が困難 • 事業スケールに従い運用コストが非線形的に上昇 ◦ 増加するインスタンス障害 ◦ インスタンスの状態差分 ◦ 不安定なリリース作業 • OS依存でランタイムの更新が滞るなど開発速度低下
15. 15 現行アーキテクチャ プールモデルを採用、1ECSクラスタ=1テナントグループ(複数テナント)
16. 16 テナントの分離 MySQLのスキーマをテナント毎に作成することでデータ分離を実現 テナント間の切り替えはapartmentを使用して実現
17. 17 リリースフロー Github ActionsとAWS Codeシリーズを組み合わせた新しいフロー Jenkinsのインスタンスに縛られなくなり、週一のリリースも可能に
18. 18 段階的な移行 期間を分けて段階的な移行を実施 EC2構成が60程度まで減少、引き続き移行を継続
19. 19 クラスタ数の変化 現在3000を超えるテナント数 60のサイロモデル + 37のプールモデル • 柔軟なスケーリングによるコスト最適化 • クラスタ数減少による運用コストの低減 • 不安定なリリース・メンテナンス作業からの脱却
20. section 03 infra v2プロジェクト
21. 21 現在hacomonoが抱える課題 • サイロモデル、プールモデルの混在 ◦ 監視ツールの統合ができていない ◦ 両方のアーキテクチャを考慮したアプリケーション (モード制御、EC2のOS起因でランタイムアップデートが難しい) • プールモデルでもバックエンドのECSクラスタが1つになっていない ◦ インフラコストの最適化に余地あり ◦ デプロイ速度も最適化の余地あり ◦ 実運用を経てプールモデルの知見がたまってきた
22. 22 現在hacomonoが抱える課題 • サイロモデル、プールモデルの混在 ◦ 監視ツールの統合ができていない ◦ 両方のアーキテクチャを考慮したアプリケーション (モード制御、EC2のOS起因でランタイムアップデートが難しい) • テナントグループの数だけVPC+ECSクラスタ+DBが構築される ◦ インフラコストの最適化に余地あり ◦ デプロイ速度が遅い ◦ テナントグループ毎に性能やオートスケールの設定がバラバラ infra v2 プロジェクトの発足！ ECSクラスタの統一 + EC2の全撤廃
23. 23 ECS完全移行のボトルネック 「DBの統合が困難」というボトルネック • データやテーブル、コネクションの増加でパフォーマンス劣化 • 移行作業時データ量に応じてダウンタイムが大きくなる • テナント毎に求められる性能や可用性が異なる
24. 24 ボトルネックの解消 「DBの統合が困難」というボトルネック 🤔 DBを統合せず 今のを使えば良いのでは？
25. 25 現行のDBを流用 現行のDBを流用するために必要なもの • 各テナントの環境は個別のVPCで構成 → VPCを跨いだ通信経路 • テナントグループ毎にDBが異なる → ルーティング制御機構
26. 26 データベースを移行せず流用 採用した技術 • VPCを跨いだ通信経路 → VPC Endpoint & Resource Gateway • ルーティング制御機構 → ProxySQL
27. 27 VPC Endpoint & Resource Gateway
28. 28 ProxySQL DBとクライアントをプロキシするOSS • MySQL/PostgreSQLをサポート • ルーティング機能を備えており スキーマ等で接続先の制御が可能 ◦ アプリケーションは `use <schema name>`を使うだけ • 設定変更は2種類 ◦ 設定ファイルを読取 ◦ MySQLでテーブルを操作
29. 29 ProxySQL バックエンドのDBへプロキシするポート 管理者がアクセスしてProxySQLを操作するポート
30. 30 ProxySQL DBとクライアントをプロキシするOSS • MySQL/PostgreSQLをサポート • ルーティング機能を備えており スキーマ等で接続先の制御が可能 ◦ アプリケーションは `use <schema name>`を使うだけ • 設定変更は2種類 ◦ 設定ファイルを読取 ◦ MySQLでテーブルを操作 ステートレスにしやすく採用したいが... テナント増減があった際の更新は？ その度にコンテナを入れ替える...？
31. 31 ProxySQL ProxySQLはMySQLクライアントから命令文を発行することで 設定ファイルのホットリロードが可能
32. 32 ProxySQL-Cron ProxySQLの設定更新を自動化するサイドカーを構築 定期的にテナントグループの情報を取得しProxySQLに反映
33. 33 infra v2の構成
34. section 04 おわりに
35. 35 これから infra v2の基本設計や技術検証等を行ってきました 現在本番稼働に向けて検証を進めています • リリースパイプラインの検証 ◦ Canaryリリース ◦ B/Gデプロイ • 監視の実装 • 負荷試験 • 移行方法の模索
36. 36 まとめ • 開発初期はサイロモデルを採用 ◦ コストの増大 ◦ 不安定なリリース • プールモデルへの移行 ◦ コンテナ最適化 ◦ 運用コスト、インフラコストの大幅削減 ◦ リリースの安定化、高速化 • infra v2でECSクラスタの統合とEC2の廃止 ◦ DBを統合しない判断 ◦ ProxySQLでの接続先制御
37. 37 We are hiring!! ウェルネスを新次元へと押し上げる新しい仲間を探しています！！ まずはカジュアル面談からでも！！ 募集職種例 • プラットフォームアーキテクト • サービス基盤エンジニア • データ基盤エンジニア • プロダクトエンジニア
38. https://www.hacomono.jp/