hacomono TECH BLOG

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

マルチテナントへの道 Gateway編

はじめに

hacomono VP of Platform Engineering のやじ(@srv)です。 年末年始は SteamDeck 届いたので、PS Vita での発売以来ずっとやりたいと思っていたAKIBA’S TRIP 2で時間を溶かしました。

前回は「マルチテナントへの道 序章」と題して hacomono のアプリケーションアーキテクチャの刷新について触れさせていただきました。 今回は前回の中で詳しく書けなかったアーキテクチャの技術要素について深堀りさせて頂ければと思います。

TL;DR

  • 新旧2つのアーキテクチャが同時稼働するハイブリッド環境
  • 透過的に取り扱うための API Gateway が必要
  • API Gateway を支える Routing Table の仕組み

アーキテクチャの変更

前回の記事で触れた様に hacomono では去年アーキテクチャの刷新を行いました。新しいマルチテナントアーキテクチャは新規環境の格納に利用しており、旧来からご利用頂いているお客様は旧来のシングルテナントアーキテクチャ上で動作しております。旧アーキテクチャについては順次、新しいアーキテクチャへのマイグレーションを進めております。

この様なハイブリッド環境で逐次的にアーキテクチャの更新を行える様にするため、2つのアーキテクチャを透過的に利用可能にするレイヤーが必要となります。

そこで本要件を満たすための API Gateway を開発することにしました。

前提

hacomono では歴史的経緯などもあり、複数の AWS アカウントを利用してお客様へサービスを提供しております。
これらを透過的に取り扱える様に Gateway 層を設計する必要があり、haconiwa と呼んでいる Provisioning を行うためのAWS アカウントとシングルテナントを扱う prd1, prd2、並びにマルチテナント商用環境である prd3 の4つのAWSアカウントをまたぐようにしています。
これにより、今後プロダクトが増えた場合も AWS アカウントを分けることが出来る様になりました。

Gateway

Gateway 層は以下の機能を有しています。

  • フロントエンドの提供
  • API 呼出を適切なバックエンドへルーティングするための API Gateway それぞれ ECS Fargate を用いた ECS Service として定義しており、共通の ALB により Listener Rule を用いたパスベースでのディスパッチが行われる様になっております。

API Gateway

API Gateway ではテナントごとに適切なバックエンド API への Dispatch を行う Reverse Proxy 機能を有しており、転送先の情報は Route53 上に SRV レコード、並びに TXT レコードとして登録されております。
API Gateway はすべてのリクエストが集中する単一障害点となってしまう特徴を持っており、高いサービスレベルが求められます。
Route53 には SLA 100% という特徴があり、読み取り専用データベースとしては非常に優秀な特性を持っているため、この特性を利用することにより API Gateway のサービスレベル向上に利用致しました。
また API Gateway は今回 hacomono の商用環境では初採用となる Go による実装を行っております。

Route53 の更新

API Gateway はすべて Route53 上のデータを元に動作しております。Route53 上への登録処理は Lambda により実現されております。
Route53 へ登録する為の情報は DynamoDB で管理しており、DynamoDB の情報は各種 Lambda がマルチテナント、シングルテナント双方のアーキテクチャと連動して
また各 Lambda についても Go により実装されており、20前後の各 Lambda で共通のコードベースを元にAWS SAM を用いて管理しております。

IaC

上記の数々の AWS 上のリソースは AWS SAM も含め Terraform を使って管理しており、本番環境だけでなく検証環境も Terraform を GitHub Actions 経由で構築する形で実現しております。
また GitHub Actions 上の AWS 認証情報の管理には OpenID Connect 機能を利用することにより、Secret に頼らない形での認証・認可を行っております。
この GitHub Repository 単位での認証・認可設定についても弊社では Terraform による管理を行っております。

まとめ

今回は「マルチテナントへの道 Gateway編」と題して、hacomono のマルチテナントアーキテクチャを支える API Gateway 周りの話をさせていただきました。
今後もCI/CDやプロビジョニングを行うための仕組みを紹介させて頂き、最後に hacomono の次のアーキテクチャの計画についても触れさせて頂こうと思っています。

続き


hacomonoエンジニア採用ウィッシュリスト
エンジニア求人一覧