マルチテナントの SaaS デプロイ
概要
SaaS企業は、多数のテナント向けにソリューションを運用しています。AWS エッジサービス (CloudFront、AWS WAF など) のマルチテナントデプロイでは、柔軟性、コスト、スケーラビリティ、運用上のオーバーヘッドなどのビジネス要件を満たすために、慎重に設計を決定する必要があります。
シンプルなアーキテクチャ上の決定。
CloudFront を使用してマルチテナントソリューションを設計する際は、以下のアーキテクチャ上の決定を考慮してください。
- すべてのテナントに同じホスト名 (saas.com/tenant1、saas.com/tenant2 など) を使用していますか、それとも別のホスト名を使用していますか? 同じホスト名を使用している場合は、単一の CloudFront ディストリビューションを使用してデプロイすることもできます。
- 別のホスト名を使用している場合、同じドメイン名 (例:tenant1.saas.com、tenant2.saas.com) を使用していますか、それとも別のドメイン名 (例:tenant1.com、tenant2.com) を使用していますか? CloudFront ディストリビューションは、複数のホスト名 (SAN 証明書) をホストできる 1 つの TLS 証明書に関連付けることができます。同じドメイン名を使用する場合、テナントごとに CloudFront ディストリビューションをデプロイするか、ワイルドカード CNAME と TLS 証明書 (*.saas.com) を含む単一のディストリビューションをすべてのテナントにデプロイするかを選択できます。ドメインが異なる場合は、テナントごとに CloudFront ディストリビューションをデプロイするか、最大 100 の異なるドメインをホストできる SAN 証明書を持つ複数のディストリビューションをデプロイするかを選択できます。ただし、同じ TLS 証明書にアタッチするドメインが多いほど、TLS 証明書の発行プロセスに手間がかかります。
- ドメイン名を管理しているのは誰か? テナントがドメインを管理している場合、ホスト名を CNAME として CloudFront ディストリビューションに追加するための追加手順が必要になります。セキュリティ上の理由から、CloudFront では、ホスト名をカバーする有効な TLS 証明書を添付して、ドメインの所有権を証明する必要があります。テナントは、お客様が ACM にアップロードする独自の TLS 証明書を共有するか、ACM を使用してテナントに代わって TLS 証明書を発行してもらう必要があります。2 つ目の方法では、ACM はドメインの所有権を証明するために DNS に CNAME トークンを作成するよう要求します。
- テナントは同じコンテンツを共有していますか、それとも異なるコンテンツを共有していますか？ 共通のコンテンツを共有している場合は、さまざまなテナントが使用できる単一のドメインで共有コンテンツをホストすることを検討してください。これにより、共有コンテンツのキャッシュヒット率が向上します。
- 複数のテナントに CloudFront ディストリビューションを使用している場合、同じオリジンでテナントをホストしますか、それとも異なるオリジンでテナントをホストしますか? 同じオリジン (例:単一の S3 バケットまたは 1 つの ALB) を使用している場合は、URL パスまたは Host ヘッダーでテナントを区別できます。この方法でテナントを区別する場合は、Host ヘッダーをキャッシュキーに追加します。異なるオリジンを使用している場合 (たとえば、テナントごとに 1 つの S3 バケット、ALB クラスターでテナントをシャーディングする場合)、トラフィックを正しいオリジンにルーティングするには、Lambda @Edge on origin リクエストイベントが必要です。テナントを区別するために path を使用している場合 (saas.com/tenant1、saas.com/tenant2 など)、CloudFront キャッシュ動作を使用してさまざまなテナントをオリジンにネイティブにルーティングできますが、CloudFront ディストリビューションごとの動作数には制限があることに注意してください。
- 設計は、AWS サービスごとおよび AWS アカウントごとの AWS クォータを尊重していますか?
設計における以下のトレードオフを考慮してください。多層オファリングには差別化されたトレードオフを実装できることに注意してください。たとえば、ドメイン名を管理する基本階層では、すべてのテナントが同じ CloudFront ディストリビューションを共有します。プレミアムテナントにはそれぞれ、カスタムドメインと AWS WAF を使用したセキュリティ保護を備えた専用の CloudFront ディストリビューションがあります。
| 各テナントは専用の CloudFront ディストリビューションでホストされています | 同じ CloudFront ディストリビューションでホストされている複数のテナント | |
| オブザーバビリティ | テナントごとにネイティブに利用可能 | ディストリビューションレベルで利用できるため、ログを使用してテナントごとにメトリックを抽出するには余分な労力が必要です |
| ブラスト半径 | 変更は 1 つのテナントにのみ影響します | 1 つの変更がすべてのテナントに影響します |
| オペレーションのオーバーヘッド | CloudFront API レベルでのスロットリングを回避するためにバッチロールアウトによる大規模な自動化が必要 | 低 |
| カスタマイズ | 各テナントは独自の構成を持つことができます | すべてのテナントに同じ設定。WAF を有効にすると、すべてのリクエストに対して課金されます |
| パフォーマンス | 各 CloudFront ディストリビューションは、トラフィック (オリジンへの接続など) によって個別にウォームされる必要があります。 | すべてのテナントがウォームアップされた CloudFront ディストリビューションの恩恵を受ける |
CloudFront ディストリビューションは 1 つの AWS WAF ウェブ ACL にアタッチできます。同じ WebACL を複数の CloudFront ディストリビューションで使用できます。前述のトレードオフは、以下に加えて、WAFの導入にも当てはまります。
| テナントごとの Web ACL の使用 | 複数のテナントに同じ WebACL を使用する | |
| 料金 | WebACL/ルールのコストはテナント数に比例して増加する | WebACL/ルールのコストはテナント数に依存しません |
| 偽陽性 | ルールを更新しても、単一テナントでのみ誤検知が発生する場合がある | ルールを更新すると、多数の単一テナントで誤検知が発生する可能性がある |
一般的ユースケース
テナントごとのサブドメイン
このシナリオでは、テナントごとにサブドメイン (tenant1.saas.com) を作成します。Route 53 は CloudFront ディストリビューションへのワイルドカードエイリアスレコード (*.saas.com) で設定されており、これもワイルドカード CNAME (*.saas.com) で設定されており、ホストヘッダーはキャッシュキーに含まれています。動的リクエストを処理する ALB オリジンは、Host ヘッダーを使用してテナントをネイティブに区別します。このシナリオでは、CloudFront の無効化はキャッシュキーのヘッダー部分 (Host ヘッダーなど) に依存しないため、1 回のコンテンツ無効化がすべてのテナントに適用されることに注意してください。静的コンテンツを提供する S3 バケットでは、ホストヘッダーを読み取って URL を S3 のテナントディレクトリ (例:tenant1.saas.com/index.html-> s3://bucket:arn/tenant1/index.html) に書き換えるために、ビューワーリクエストイベントで設定された CloudFront 関数が必要です。S3 からすべてのテナントに同じコンテンツ (たとえば、同じシングルページアプリケーション) を提供しながら、API を使用してテナントを区別する場合は、このシンプルなソリューションを検討してください。
異なるオリジンでテナントをホストしている場合は、オリジンリクエストイベントで Lambda @Edge 関数を設定して、テナントリクエストをテナントをホストしているオリジンにルーティングする必要があります。この実装の詳細については、以下のケーススタディをご覧ください。
独自ドメインを持つテナント
このシナリオでは、テナントごとに専用の CloudFront ディストリビューションを用意し、プロセスを自動化します (例:Amazon Certificate Manager を使用したディストリビューションの作成と TLS 証明書の発行など)。事前に、関連するクォータ (アカウントごとの配布数、TLS 証明書の数など) を上げてください。場合によっては、CloudFront ディストリビューションを複数の AWS アカウントに分散させる必要があります。
サーバー上の TLS を終了する
CloudFront では要件の規模を満たすことができない場合は、TCP/TLS 接続を終了するためのリバースプロキシ (NLB や EC2 など) を構築し、セキュリティとパフォーマンスを向上させるために Global Accelerator をその前に構築することを検討してください。このシナリオでは、必要に応じてリバースプロキシにキャッシュを実装する必要があることに注意してください。