マルチテナントのサーバレスを支える技術【マルチテナントSaaSにおけるエンジニアリング大全 Day10】

はじめに

本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day10 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。

今回は、マルチテナントを支えるサーバレス技術について言及していきたいと思います。少々AWS寄りの話題になりますが、ご了承ください。

今回の記事で指す『サーバレス』はFaaS、AWSでいえばLambdaを中心とするアーキテクチャであることに最初に言及しておきます。

サーバーレスアーキテクチャの概要

なぜサーバレスを採用するか？

そもそもなぜサーバレスを採用するのでしょうか？マルチテナントの文脈においては、テナントごとにより処理のワークロードが大きく異なること に起因します。つまりノイジーネイバー問題を避けるために採用したい側面があります。ノイジーネイバー問題については昨日の記事で触れたため、ぜひそちらも参考にしてください。

サーバレスアーキテクチャを採用すれば、コンピューティングリソースの観点では、（限度はあれど、）自動スケーリングをインフラレイヤに移譲させることができ、ノイジーネイバー問題への対策の一種になります。

サーバレスでない選択肢についての補足

今回の記事では、マルチテナントにおけるサーバレス特有の処理について解説を進めていくのですが、それ以前にサーバレスでない選択肢についても触れさせてください。

AWSでいえば、Fargate、EKS、EC2、App Runnerなどのコンテナ・仮想マシンベースのソリューションが該当します。弊社プロダクトのQastにおいては、そのほとんどがFargate on ECSで構築されており、一部（体感１割）のみ非同期処理やスケジュール実行がLambdaで構成されています。（少し脱線しますが）Qastの開発においては、サーバレス基盤としてServerless Frameworkを利用した開発基盤を用意しているので、こちらの記事も参考にどうぞ。

しかしながら、コールドスタート、タイムアウト制限、メモリ構成の制約など、トレードオフも存在します。またLambdaなどのFaaSを採用するときに、ログ出力、パフォーマンス、アラートなどに対して別管理になってしまいがちという問題もあります。

そういった諸問題は一般論としてあれど、今回の記事においては、「マルチテナント」としてサーバレスを採用する場合のプラクティスと言った観点での紹介をしていきます。

具体的な実装アプローチ

具体の実装パターンを掘り下げていきたいと思います。AWSのサーバレスのベストプラクティスが紹介されているため、こちらをもとに簡単に解説を行いましょう。

出典: AWS におけるマルチテナント SaaS の実装パターン ~ サーバーレス編

上図はAWS上にサーバレスアーキテクチャを構築する最もシンプルな例です。API Gatewayなどをバックエンドの入口に認証を経由（上図ではCognitoによる認証）したあと、Lambda上にAuthorize（JWTの検証など）の処理を実装し、そこで テナント固有の一時クレデンシャルを取得 し、それをもとに適切なアクセス認可を取得し、Lambdaの処理を実装する流れになっています。

テナント固有の一時クレデンシャルを取得する

Lambdaを活用したマルチテナントアーキテクチャの核心は、テナントごとに異なる実行コンテキストを動的に切り替えることにあります。

先ほどのアーキテクチャ図でも示されていた通り、Lambda上のAuthorize層では、テナントIDをもとにAWS STSを利用してテナント固有のIAMロールを引き受けます。これにより、Lambdaの実行コンテキスト内で、そのテナントのみがアクセス可能なリソースに制約されたクレデンシャルを取得できます。

例えばプールモデルでデータを管理している場合であっても、DynamoDBのテーブルアクセスにおいて、特定のパーティションキーのみに制限したIAMポリシーを適用することで、テナント間のデータ漏洩を防ぐことができます。サイロモデルであれば、テナント専用のS3バケットやDynamoDBテーブルへのアクセスを許可するポリシーを適用することで、より強固な分離が実現できます。

テナント分離モードにおける隔離

さらに直近の2025年11月、AWS Lambdaにテナント分離モード（Tenant Isolation Mode） が導入されました。これは、単一のLambda関数内で個々のテナントまたはエンドユーザーレベルまで分離を拡張する機能です🎉

これまでのLambdaでは下記のように、実装によって誤ったリソースが共有されてしまう場合がありました。

• キャッシュされたデータ
• グローバル変数
• /tmpディレクトリに保存されたファイル

これらを根本から解消するためには、テナントごとに個別のLambda関数をデプロイしたり、カスタム分離ロジックを実装する必要がありました。

しかし今回から導入されたテナント分離モードを有効にすると、Lambdaは関数の実行環境を顧客が指定したテナント識別子（tenant ID） に関連付けます。これにより、特定のテナントの実行環境が、同じLambda関数を呼び出す他のテナントからの呼び出しリクエストに使用されることがなくなります！

マルチテナント観点では非常にありがたいアップデートですね。

まとめ

今日はサーバレス、特にAWS Lambdaとマルチテナントの実装パターンについて紹介しました。Lambdaにおいてもマルチテナントを標準とした機能追加などもあり、よりサーバレスを採用しやすい土台が整ってきているように思います。

さて明日はいまホットな生成AIについてマルチテナント観点で紹介していきます。