hacomono TECH BLOG

フィットネスクラブやスクールなどの顧客管理・予約・決済を行う、業界特化型SaaS「hacomono」を提供する会社のテックブログです！

開発速度を加速させるマルチプロダクト基盤：Self-Service提供への挑戦



はじめに

こんにちは。基盤本部プラットフォーム部のkaikaiです。
入社して1年3ヶ月ほど経ちました。まだ新人な気分でしたが、スタートアップ界隈だとベテランの域みたいです。(精進せねば)

さて、本記事では、プラットフォームチームが現在開発を進めている「マルチプロダクト基盤」についてご紹介します。
このプロジェクトが目指すのは、事業スケールに不可欠な、開発者が「素早く、安全に、迷わず」開発できる仕組みを実現することです。この記事では、その背景から技術選定、現状と今後の展望までをお話しします。

構築の背景と課題

現在弊社ではhacomonoという一つのサービスを展開しています。
hacomono自体はモジュラーモノリスとクリーンアーキテクチャで構築されており、インフラリソースは主に次の構成です。

  • APIサーバー
  • 非同期ジョブ基盤
  • データベース
  • ルーティング Gateway

大部分は ECS と Lambda を活用しており、マネージドな領域が多いため基盤本部で運用できていました。

一方、弊社はマルチプロダクト戦略による成長を考えており、これからは複数のプロダクトを並行して生み出していく方針です。もし従来どおり各プロダクト毎にプラットフォームチームが支援を行うと、次の問題が表面化します。

  • インフラ準備に時間がかかり、ローンチが遅れる
  • プロダクト数の増加に伴い運用が逼迫し、担当者の燃え尽きや既存プロダクトへの影響が懸念される



この課題に対する現実解は二択と考えています。

1．各プロダクトに十分な基盤エンジニアを配備する

2．プロダクト数が増えても開発速度と安全性を両立できる「仕組み」を用意する
プラットフォームチームは後者を選択し、専属チームによるSelf-Service構築を目指しています。理由はプロダクト数に比例して基盤エンジニアを配備するのは難易度が高いからです。
目標はプロダクトチームが「素早く、安全に、迷わず」開発を進められ、プロダクト数がスケールしても運用負荷が比例して増大しない状態をつくることです。

技術選定について

上で設定した目標を実現するための技術として、hacomono内で実績のあるECS/Lambdaを拡張する案と、新たにKubernetesを導入する案の二つを比較検討しました。

1. ECS/Lambdaの拡張

アプリケーションを動かす基盤としてECS/Lambdaは、マネージドされている領域が多いため運用負荷が低いという大きなメリットがあります。
しかし、私たちが目指す高度なSelf-Serviceやガードレールを実装しようとすると、ECS/Lambdaだけでは完結せず、複数の仕組みを組み合わせたり、独自の仕組みやベンダー依存な仕組みを多数入れないと難しいことが考えられています。
我々の経験上もこれまで基盤機能を作成する場合は、自前で開発するか計画自体を見送ることが多かったです。
また、このアプローチは基盤開発コストだけでなく、デプロイ後の運用においても、多数のコンポーネントを統合的に管理するのが難しいという課題があります。管理の仕組みを自前で用意する場合、結果として仕組み自体の運用が複雑化してしまう懸念もありました。

2. Kubernetesの導入

一方、Kubernetesは単なるアプリケーション実行基盤ではなく、「プラットフォームを構築するためのプラットフォーム」と私は考えています。
Kubernetes単体による基盤構築は難しいのですが、Kubernetesが提供するAPIと豊富なエコシステムを活用することで、ガードレールが組み込まれたSelf-Serviceを構築しやすいです。例えばCDの仕組みはArgoCDを、サービス間通信の関心毎にはIstioを、と言った感じです。
また、Kubernetesという抽象でアプリケーションに必要なほぼ全てのリソースを扱えるため、(クラスター戦略に依存しますが)プロダクト数が増加しても運用作業を抑えられると考えています。
ただし、Kubernetes自体の難しさやバージョンアップなどの運用工数はECS/Lambdaよりも数段高いとされています。

意思決定について

両者を比較し、プラットフォームチームではKubernetesの採用を決定しました。
Kubernetesの方が私たちが目指す「Self-Serviceを作るための基盤」として、より適していると判断したためです。

もちろん、学習コストやKubernetes自体の運用ハードルといった課題もありますが、以下のような準備+AWSアップデートもあり挑戦する価値は十分にあると判断しました。

  • プラットフォームチームの人員が増強されたこと
  • PoCや勉強会を通じて、Kubernetesの知見が着実に高まっていたこと
  • EKS Auto Modeの誕生により運用負荷が下がっていること

最悪の場合、実績のあるECS/Lambdaの構成に戻れるほど実績を積んでいたことも、私たちの決断を後押ししました。

現状の取り組み

目標を実現するため、現在私たちはいくつかの有望なエコシステムを組み合わせて基盤開発を進めています。
このセクションでは、その中でも特に期待しているCrossplaneと、GitOpsを実現するArgoCDについてご紹介します。

Crossplane

本基盤の核となりうる技術として、私たちが注目しているのがCrossplaneです。
これは「KubernetesのAPIを拡張し、Kubernetesの既存リソースに加え、AWSのIAMロールやDynamoDBといった外部リソースまでも、独自のKubernetesリソースとして扱えるようにする」ツールです。


Crossplaneを使うことで複数のリソースから成る複雑な構成や、セキュリティ・運用上のベストプラクティスを組み込んだ設定を、一つのシンプルなリソースとして開発者に提供できます。
例えば以下の例は、「Webアプリケーションに必要なリソース一式(ランタイムとネットワーク設定)」をHAppというリソースで、「推奨設定を施したDynamoDB」をTableというリソースで、それぞれ抽象化しています。

apiVersion: platform.example.org/v1alpha1
kind: HApp
metadata:
  name: demo-app
spec:
  image: hoge:v1
  replicas: 2
  domain: hoge
  allowActions:
    - dynamodb:GetItem
    - dynamodb:PutItem
---
apiVersion: platform.example.org/v1alpha1
kind: Table
metadata:
  name: demo-table
spec:
  hash_key: id
  sort_key: timestamp

Crossplaneが私たちの目標にどう貢献するか、下記に示しています。

  • Self-Service
    • 開発者はマニフェストを数行書くだけで、プラットフォームチームが定義したベストプラクティスが詰まったインフラ一式をデプロイできる
    • 他のIaCに頼らずマニフェストのみで全てが完結するため、認知負荷の軽減が期待できる
  • ガードレール
    • Kubernetesのlabelやannotationの付与強制化や、危険な設定を禁止にできる
    • 命名規則の強制やタグを用いたプロジェクト毎の権限管理・コスト管理などをカスタムリソースの裏側に埋め込むことができる
    • 開発者に強い権限を渡す必要がなくなる
  • 運用コストの軽減
    • Self-Serviceとして必要十分にリソースを提供することで、開発者とのやりとりや、ガードレールによるインシデント発生などの運用を軽減できる
    • 基盤機能開発においてもHAppのような定義を使い回すことができる

ちなみにCrossplaneの詳細に関しては、11月に開催されるYAPC::Fukuoka 2025にて発表する予定です。よろしければ是非聴きに来てください！

ArgoCD

マニフェストを安全かつ自動で適用するため、GitOpsを実現するArgoCDも導入しています。
ArgoCDはGitリポジトリを信頼できる唯一の情報源（Single Source of Truth）とし、クラスタの状態を常にGitの状態と一致させ続けます。
これにより、開発者およびプラットフォームチームは「Gitを操作すれば、デプロイが完了する、Gitを見れば構成がわかる」というシンプルかつ強力な開発体験を得ることができます。
加えて、ArgoCDは基盤運用において、特に以下の3つの大きなメリットをもたらします。

  • CD環境の自動提供
    • ApplicationSetを活用すれば、新しいプロダクト用のディレクトリを追加するだけでCDの仕組みを自動生成でき、開発者およびプラットフォームチームの工数を削減できる。
  • 安全な権限管理
    • 開発者にKubernetes権限を直接付与する必要がなく、ArgoCDのRBACによってプロダクトごとに必要な最小限の権限のみを移譲できる
  • 変更の可視性と追跡性
    • Gitのコミット履歴がインフラ構成になる
    • 「いつ、誰が、何を」変更したかが明確になり、問題が発生した際の調査や切り戻しが迅速に行える

その他Istioによるサービスメッシュの実現やKarpenterによるNodeの最適化なども実施し、できる限り開発者が作業をせずとも最適なリソース提供をできるように基盤開発を進めております。

今後の展望

現在、マルチプロダクト基盤は開発者に触ってもらえる一歩手前の段階まで来ています。
そのためまずは開発者に利用してもらうことで、フィードバックを収集しながら開発者体験の改善を繰り返していく予定です。
並行して、基盤に不可欠なオブザーバビリティ（監視、ログ、トレース）周辺の実装も固めていきます。マルチテナンシーな環境で各プロダクトのテレメトリデータをどう分離し、安全に可視化するかが課題です。

まとめ

本記事では、hacomonoのマルチプロダクト戦略を支える新しい開発基盤について、そのコンセプトと現在の取り組みをご紹介しました。
この取り組みはまだ始まったばかりですが、同様の課題に直面している方々にとって、私たちの思考プロセスや技術選定が少しでも参考になれば幸いです。
また、今回は良いことばかり書きましたが、エコシステムを取り入れることで生じるプラットフォームチームの認知負荷や課題などもまた別の機会にご紹介できればと思います。


💁 関連記事