こんにちは、大久保です。
先週 Qiita Night～AWS～ に参加して、いろいろと新たな知見を得ることができました。ありがとうございました。
私も『マルチテナントとAurora Serverless V2』でLTで発表させていただきました。MGReでの経験がどなたかの知見になっていったら嬉しいです。
マルチテナントのアーキテクチャについて
マルチテナント型のSaaSは、以下のようなアーキテクチャーに分類することができます。
- サイロモデル
- プールモデル
- サイロ＋プールモデル（ハイブリッドモデル）
サイロモデルは、テナントごとに専用リソースが提供されるアーキテクチャです。他のテナントの影響を受けないシンプルなアーキテクチャとなりますが、インフラ構築の自動化等、テナントの増加に対して安定的な運用オペレーションを構築する必要があります。
プールモデルは、すべてのテナントでリソースを共有するアーキテクチャです。1つの環境でサービスを提供できるため、テナントの追加が容易であり、また、コンピューティングリソースを集約できることで、コスト効率が良いというメリットがあります。
ハイブリッドモデルは、サイロモデルとプールモデルのいいとこ取りとなります。運用オペレーションの手数は増えてしまいますが、拡張性と安定性のどちらも獲得することができます。
MGReのアーキテクチャーの変遷
2017年：サイロモデル
テナントごとに環境を構築（シングルテナント）していきました。
アプリケーション実行環境はElasticBeanstalkで構築し、オートスケーリングも実現しています。
2017年当時はServerlessが存在しなかったため、DBはプロビジョンドAuroraにて提供しています。アクセス状況を計測して運用しながらDBインスタンスサイズを調整する等、スパイクアクセスへの対応がかなり大変でした。
2020年：プールモデル
すべてのテナントで環境を共有し、アプリケーションの迅速なバージョンアップをおこなえるようになりました。
アプリケーション実行環境はFargateで構築し、ElasticBeanstalkと比較して、オートスケーリングの速度が格段に速くなっています。DBはAurora Serverless V1を導入し、アクセス状況に応じてキャパシティを調整できるようになりました。
Aurora Serverless V1で困ったこと
おもにパフォーマンス周りで問題が発生することがありました。
スパイクアクセスのような急激な負荷上昇が合った場合、オートスケーリングの速度が追いつかず、一時的に処理が遅くなってしまう場合がありました。また、スケーリング中にアプリケーションからのDBコネクションが切れてしまう場合があり、その都度再接続が発生しておりました。
また、Readerレプリカがないためクエリの分散がおこなえず、リードヘビーなアクセスが多いとキャパシティに余裕がなくなってしまうことがあります。
2022年：ハイブリッドモデル
プールモデルでは、ノイジネイバー問題という特定のテナントがリソースを消費してしまう事象が発生する可能性があるため、現在はハイブリッドモデルを取り入れております。
また、DBには待望のAurora Serverless V2が選択できるようになり、順次アップグレードしております。
Aurora Serverless V2の良いところ
- 高速スケーリング（V1に比較してめちゃくちゃ速い（実測0.5秒程度でスケールアップ）です。）
- Readレプリカ（最大15インスタンスまで追加できるため、キャパシティが激増します。）
- Performance Insight（V1では使えなかった、クエリを詳細に分析することができます。）
MGReにおいては、プロビジョンドインスタンスが xlarge 以上だとコスト効率が良くなるというシミュレーション結果を得たため、シングルテナントにおいても順次導入しています。実際に 2xlarge x 3 (Writer/Reader x 2)を置き換えたところ50%以上のコスト削減効果がありました。
まとめ
スケールアップとスケールアウトの両方の特性を持つAurora Serverless V2は、マルチテナント型のアーキテクチャとの相性はとてもよく、また、コスト効率にも優れているため、SaaSとしてのサービスを安定的に提供するための有力な選択肢となり得ると思います。