こんにちは、メグリでサーバーサイドエンジニアをしている蔵下です。

少し前ですが、10/13にヘイ株式会社（現 STORES 株式会社）さんと LT 会のイベントを行いました。今回はそこで発表した内容に少し追記しつつ改めてまとめてみようと思います。

LT 内容

タイトル

ここがつらいよマルチテナント

本日のお題

マルチテナント向けSaaS開発時の経緯とマルチテナントのつらみについて

弊社では2020年6月に EAP という前身サービスから MGRe にリブランディングを行いました。その際にクライアントごとに個別に環境を用意するシングルテナント方式から、一つの環境に複数クライアントが同居するマルチテナント方式に転換しました。今回はマルチテナントを数年開発・運用してわかったつらみについてお話します。

MGRe について

マルチテナント向けのSaaS
ニュース、お知らせ、クーポン、店舗検索、プッシュ通知、アイテム等 + 会員証の基本機能
様々なECや会員基盤システムと連携が可能

MGRe の歴史

受託時代（シングルテナント、フルスクラッチ）
EAP時代（シングルテナント、個別環境、ベースコードを切り出し）
MGRe（マルチテナント、共有リソース + 個別環境）

過去のサービスとの比較

マルチテナントにしてつらかった点

パフォーマンスの課題
- DB（Aurora Serverless）の性能限界が見えてる
- WAF 等 AWS のリソース上限
運用の課題
- テナント領域のアップデートが手間
- テナントが混ざる
一番の課題
- やらかすと被害が大きい

パフォーマンスの課題

DB（Aurora Serverless）の限界
- コンテナ（API）はいくらでも増やせる
- プッシュ配信時のスパイクアクセス
- MGRe のセグメント配信は仕様上キャッシュが難しい
- 通勤時（9時台）やスーパー等の小売はお昼過ぎ（12〜13時台）と夕方（17時以降）

WAF 等 AWS のリソース上限
- route53 でテナントごとにドメインを用意　→　上限500程度
- テナントごとにロードバランサを用意　→　上限100程度
- WAF による管理画面用 API の IP 制限　→　正規表現のため最大文字数の制限
- Aurora Serverless のさばける上限　→　上限 ACU 256（メモリ488GB）

運用面の課題

テナント領域のアップデートが手間
- テナント毎に異なる認証処理を吸収
- mgre-auth という gem を用意
- ある程度共通化はされているものの数が多い
テナントが混ざる

一番の課題

やらかすと被害が大きい
- あるテナントのユーザー数とニュースのレコード数が増加
- それによりセグメント検索 API のパフォーマンスが低下
- リクエストがつまり始める
- リクエストがつまっているためコンテナが新しく立ち上がり続ける
- コンテナ起動時に DockerHub からあるイメージをプルしていた
- 短時間にプルし過ぎたためレート制限
- イメージをプル出来ずコンテナ起動失敗
- 生きているコンテナも次々死ぬ
- コンテナがいなくなり全てのテナントでサービス停止😭

対策

パフォーマンスの対策

古いデータの削除、非公開化
- インデックスの見直しも含め、取得レコード数を減らすのが最も効果的
Aurora Serverless v2 への移行
- 細かく素早い ACU（容量）変更
  - 0.5単位、v1 は8→16→32のように2の累乗単位
- 適切な ACU 選択によるコストメリット、マルチ AZ 対応等 v1 から比べて多くの利点
- v1 はインスタンス1つのみ、v2 は Aurora と同じライター／リーダークラスター方式
- v1 からの進化というより Aurora をサーバーレスにした感じ

運用面の課題

テナント領域のアップデートの自動化
- PR 後各テナントのリポジトリにおいてコミット→ PR までの自動化、スタンダードプランにおいてはマージ〜自動デプロイまでの仕組みづくり

一番の課題

QA（テスト）含むリリース体制の整備
- 項目書を作り計画立てたテストに
手軽に行える負荷テスト
- k6

MAU が大きいテナントの分離
- 別の DB インスタンスを用意する

マルチテナントにして良かった点

アップデートの適用が楽
- 厳密には楽ではないが一度のアップデートですべてのテナントに適用できる
- シングルテナントより開発した機能やバグ修正の適用速度が早い
SaaS としてプロダクトを成長させるにはマルチテナントという選択は最適だった

まとめ

Aurora Serverless v2 はいいぞ
QA さんありがとう