事業成長からみるhacomonoアーキテクチャの変遷

株式会社hacomono
Makoto Shiga（志賀 誠)
有働 開

アーキテクチャ年表 - 各社の意思決定の歴史
https://findy.connpass.com/event/371331/

1. Last Update 2022.03.16 事業成長からみる hacomonoアーキテクチャの変遷
2. section 01 目次
3. 3 目次 • 会社紹介 • hacomonoアーキテクチャの変遷 • マルチプロダクトアーキテクチャ
4. section 02 会社紹介
5. 5 自己紹介 • 志賀 誠（まこたす） • 株式会社hacomono ◦ 2022/8 ~ ◦ プラットフォーム部所属 • x: Maco_Tasu • GitHub: MacoTasu
6. 6 サービスについて
7. 7 hacomonoの成り立ち
8. section 03 hacomonoアーキテクチャの変遷
9. section 03-1 シングルテナント構成時代
10. 10 hacomonoの成り立ち この辺りの話をします
11. 11 初期のアーキテクチャ • お客様のご要望でジムのDXサービスを開発したことがはじま り • 当初は シングルテナント環境 を採用
12. 12 初期のアーキテクチャ
13. 13 初期のアーキテクチャ
14. 14 シングルテナントの課題 インフラが増えるにつれて、様々な問題が顕在化 運用コストの増大 : EC2, RDS, Jenkinsなどのアップデート対応コストが増加。 構成管理の問題 : IaC化が行き届かず、Snowflake Server状態に。 CDが不安定 ストレージがパンク、メモリ不足 etc…
15. section 03-1 マルチテナント構成時代
16. 16 事業成長 この辺りの話をします
17. 17 解決したい課題 次のアーキテクチャに期待すること • シングルテナントで生じていた課題の解決 ◦ immutable infrastructureではない ◦ CI / CDの課題 ◦ スケールが遅いなど etc… • シングルテナント / マルチテナントを横断で扱える ◦ 移行を考慮し、透過的にリクエストを扱える
18. 18 アーキテクチャ全体像
19. 19 シングルテナントの課題 アーキテクチャの刷新により、以下の改善を実現 ✅ OSアップデートの簡易化 Fargateの利用により、OS管理が不要に ✅ 運用コストの削減 プールモデルのインフラにより、運用可能なIaCへ ✅ コストの最適化 Aurora Serverless v2により、DBの運用負荷を軽減 Fargateに迅速なスケール
20. 20 アーキテクチャ - API Gateway - • API Gateway ※ ◦ 適切なバックエンドへReverse Proxyを行う ◦ Route53のSRV,TXTへProxy先の情報を保存し、読み取 りをすることで高いSLAを実現している ※ AWSのAPI Gatewayではないです
21. 21 データ移行 API Gateway x DMSを活用し、データ移行を実現
22. 22 データ移行 2023年に移行を開始 ~ 現在で残り25環境まで進んだ 移行についての詳細はこちら https://techblog.hacomono.jp/entry/2024/04/16/1100
23. 23 組織とアプリケーションのリアーキテクチャ 課題: • 事業成長に合わせ、開発チームが機能ごとに分割。 • モノリスなリポジトリを複数チームで開発することになり、認知 負荷が増大。 検討: • マイクロサービスとモジュラーモノリスを比較検討。
24. 24 マイクロサービス or モジュラーモノリス 高 高
25. 25 マイクロサービス or モジュラーモノリス • 組織・技術の成熟度 ◦ 基盤チーム（プラットフォーム） ▪ マイクロサービス /モジュラーモノリスの経験 ◦ プロダクトチーム（ストリームアラインド） ▪ 分散システムの経験 ◦ 共通事項 ▪ リソース観点 • 事業の方向の確実性 ◦ どんなドメインを扱っていくか可視化されている ◦ 既に確立したコアとなるドメインがある
26. 26 マイクロサービス or モジュラーモノリス 高 高 hacomono
27. section 04 マルチプロダクトアーキテクチャ
28. 28 自己紹介 • 有働開（kaikai） • 株式会社hacomono ◦ 2024/7 ~ ◦ プラットフォーム部所属 • X: @PbwBi • GitHub: u-kai • 万博は行けずに終わってしまいました...
29. 29 おさらいとこれから 現状のおさらい hacomonoというプロダクトを提供中 これから 競争力向上を狙うためにマルチプロダクト戦略を遂行したい
30. 30 これからに向けて ~プロダクトを量産するために ~ プロダクト数が増加しても維持が必要なもの • 開発速度 • 持続可能な運用 • セキュリティ・信頼性 アーキテクチャや組織を再考する必要あり
31. 31 プロダクトを量産するためのアーキテクチャ プロダクトを量産するためのアーキテクチャ案 1. hacomonoプロダクトにモジュールとしてプロダクトを追加 2. プロダクト毎にリソースを作成し、hacomonoとは分離 プロダクト毎にリソースを作成し、分離 することで 開発速度/セキュリティ・信頼性を担保 していきたい
32. 32 専用リソースの作成による懸念点と解決に向けて 中央チームへの運用負荷やコミュニケーションコスト増 マルチプロダクト基盤構築による解決を狙う
33. 33 マルチプロダクト基盤で実現したいこと リソース分離・リソースの標準化 /共通化・SelfServiceの提供 開発速度・セキュリティの担保と運用負荷軽減 を目指す
34. 34 基盤を達成するための技術選定 hacomonoで実績のあるECS/Lambda 基盤作りのスタンダードKubernetes(EKS) VS
35. 35 ECS/LambdaとEKSの基盤構築における比較 ECS/Lambda Kubernetes リソース分離 AWSアカウント分離 クラスターもしくは Namespace分離 リソースの標準化/共通化 独自/ベンダー依存の仕組み構 築 エコシステムの導入 Self-Serviceの提供 〃 〃 運用負荷 単体の運用負荷は低い 独自の仕組みの数だけ基盤全 体の運用負荷が高くなる 単体の運用負荷は高い エコシステムによって基 盤全体の運用負荷を抑え られる(はず)
36. 36 技術選定における意思決定 Kubernetes(EKS AutoMode)を採用することに 理由 • エコシステムが豊富で基盤構築に適していると判断 • Kubernetesの抽象を使うことで一貫した運用が可能 • KubernetesのPoCや勉強会を半年以上チームで行ってきた • EKS AutoMode誕生によるKubernetes自体の運用負荷軽減
37. 37 マルチプロダクト基盤概要図 ただいま構築中！詳細は弊社TechBlogにて https://techblog.hacomono.jp/entry/2025/10/14/110000
38. 38 今後の展望 • Observabilityを向上させる • 本番稼働を達成する • 開発者体験を高める改善を繰り返し行う • 普及活動による組織への浸透
39. https://www.hacomono.jp/