Amazon Web Services ブログ
Amazon SES でのマルチテナント実装方法
この記事は、How to implement multi tenancy with Amazon SES を翻訳したものです。
このブログ記事では、Amazon SES でマルチテナントを設計する方法と、下流の顧客 (downstream customers / 本記事では「下流の顧客」と表記しています) に対するメール一括送信処理に効果的に対応できるマルチテナントアーキテクチャを実装するための基本的なベストプラクティスについて説明します。
Amazon Simple Email Service (SES) は、様々な業界のお客様が受信者にメールを送るために活用されています。多くの場合、下流の顧客や他の事業部門に代わってメールを送信する必要があります。多くの組織 (マルチテナント運営者) では一般的に、このような使用例を「マルチテナントメール送信の実践」と呼んでいます。メール送信のマルチテナント実践 (最終顧客 (end customers / 本記事では「最終顧客」と表記しています) の代わりに大量のメールを送信) を実施するには、Amazon SES の利用者は各顧客またはテナントのメール送信のレピュテーション (送信元の評価、信頼度 / 本記事では「レピュテーション」と表記しています) を分離することを保証しながら、何千もの下流の顧客のメール送信ニーズを効果的に満たすことができるアーキテクチャを採用する必要があります。
ユースケース
- 異なるドメインの異なるビジネスユニット (BU) からの複数のブランドをオンボードできるようにするとき
- マーケティング部門と業務部門のテナントを分離する必要があるとき
- ISV のお客様で、最終顧客のメール送信レピュテーションを分離する必要があるとき
- 設定セットによるドメイン管理を行うとき
- 個々の顧客の電子メール送信のレピュテーションを追跡し、電子メール送信プロセスを制御するとき
前提条件
この記事に関して、以下の知識を有する読者を前提としています。
- AWS アカウントの管理
- AWS Regions
- Amazon Simple Email Service
- Amazon Simple Notification Service
- Amazon CloudWatch
- Amazon SES の設定セット
- AWS Organizations
ソリューションの概要
電子メールのエコシステムにおいて、ドメインと IP のレピュテーションは電子メールを相手の受信トレイに届けるために重要です。マルチテナントのシナリオでは、テナントは独自のビジネスや社内チーム (マーケティングチーム、カスタマーサービスチームなど) である可能性があります。各テナントの成熟度は大きく異なるため、マルチテナント環境の導入はますます複雑で困難になる可能性があります。あるテナントでは十分に検証されたエンゲージメントの高い受信者リストを持っているかもしれませんが、別のテナントでは信頼されていない電子メール受信者リストを持っているかもしれません。そのような電子メールアドレスにメールを送信すると、バウンスやスパムが発生して、IP やドメインのレピュテーションが低下する可能性があります。そのために組織では、未熟な送信者や悪質業者が他のテナントに影響を与えるのを防ぐための安全策を構築する必要があります。
マルチテナントをより理解するために、まず Amazon SES がどのように電子メールを送信するかを見てみましょう。Amazon SES を経由してエンドユーザーに送信されるメールは、Amazon SES 内でマッピングされた IP アドレスを使って送信されます。Amazon SES は、共有 IP アドレスと専用 IP アドレスの 2 種類の IP アドレスを提供しています。(現在、Amazon SES では、1. 専用 IP アドレス (標準)、2. 専用 IP アドレス (マネージド) の 2 種類の専用 IP を提供しています。) 共有 IP アドレスは、多くの SES のお客様で共有されており、お客様が専用 IP アドレスをリクエストしない限り、すべてのメールはデフォルトで共有 IP アドレスを使って送信されます。専用 IP アドレスは、単一のお客様またはテナントのために指定されます。テナントは、お客様自身のエコシステム内のビジネスユニットまたは ISV の最終顧客である場合があります
もしお客様が SES 経由でメール送信するために共有 IP を使用し、マルチテナントを実現しようとしている場合、テナントのタグ付け、SES イベントの宛先ルーティング、各テナントのコスト配分など、複数のテナントのビジネス機能を分離することはできますが、あるテナントから別のテナントへのメール送信レピュテーションを管理または分離することには役立ちません。なぜなら、これらの共有 IP は AWS リージョンにマッピングされており、ある不正なテナントがスパムメールを送信しようとしている場合、同じリージョンで同じ共有 IP のセットを使用している他のお客様にも影響を与えるからです。
Amazon SES のユーザーで、あるテナントのレピュテーションを別のテナントから分離したい場合、専用 IP が理想的なソリューションとなります。専用 IP または専用 IP (専用 IPプールとも呼ばれる) は、それぞれのテナントに割り当てることができ、そのテナントのメール送信のレピュテーションを別のテナントのレピュテーションから容易に分離することができます。もし、テナント 1 が問題のある送信者で、Gmail、Hotmail、Yahoo などのインターネットサービスプロバイダ (ISP) がそれぞれのドメインや IP にフラグを立てたとしても、他のテナントのドメインや IP のレピュテーションは相互に排除されているため、影響を受けることはなくなります。
Amazon SES は、主に 1. 設定セット、2. 専用 IP プールの 2 つの仕組みでマルチテナントをサポートしています。設定セットは、検証済み ID に適用される設定ルールです。一方、専用 IP プールは、専用 IP をプールにグループ化し、それを設定セットにマッピングすることで、それぞれの ID が他のテナントに影響を与えずに同じ IP プールを利用することができるようにします。以下の簡略化したアーキテクチャをご覧ください。
1 つの AWS アカウントで複数のテナント運用する
このアーキテクチャでは、テナント 1 (Tenant1)、テナント 2 (Tenant2)、テナント 3 (Tenant3) はそれぞれの専用 IP で異なる構成を使用し、テナント 4 (Tenant4) は共有 IP を使用しています。つまり、テナントは自分のドメインでどの設定セットを使用する必要があるか選択できます。これにより、お客様はマルチテナントを実現することができます。
Amazon SES のマルチテナント – ベストプラクティス
Amazon SES のマルチテナント運用を行う場合、お客様を担当している AWS のアカウントチームにご連絡いただくか、マネジメントコンソールにて「サービス制限の引き上げ」カテゴリーとしてサポートケースを起票し、数万人の最終顧客の代わりにメール送信することをお知らせ下さい。これにより AWS がお客様のアカウントに正しく制限を設定し、お客様の送信パターンを認識することができます。
上記のようなアーキテクチャは、Amazon SES ユーザーが複数の最終顧客を効率的に管理するのに役立つことがほとんどですが、稀に Amazon SES ユーザーが AWS サポートから Amazon SES アカウントがレビューされている旨の通知を受け取ることがあります。これは、Amazon SES アカウントがテナントに問題のあるメールを送信するために使用されていること、または (レビュー時間枠内に問題のある送信者を制御するために積極的に反応しなかった場合に) アカウントが一時停止されていることを示しており、スパムまたは苦情率が一定のしきい値を超えたため SES アカウントからメールを送信できないことを示しています。このような状況が発生するのは、Amazon SES のサニタイズ処理が、デフォルトで AWS アカウントレベルで実装されているためです。そのため、専用 IP や専用 IP プールを使用しているテナントでスパムやクレーム率が SES の承認された上限を超えた場合でも、Amazon SES はアカウント管理者に通知を送り、そのアカウントで懸念事項をフラグ付けします。このような場合、「設定セットの E メール送信を自動的に一時停止する」として知られるプロセスを実装することが推奨されます。Amazon SES を構成し、特定の設定セットを使用して送信されるメールに固有のレピュテーションメトリクスを Amazon CloudWatch にエクスポートすることができます。さらにこれらのメトリクスを使用して、各設定セットに固有の CloudWatch アラームを作成することができます。これらのアラームが特定の閾値を超えた場合、Amazon SES アカウントの全体的な電子メール送信機能に影響を与えることなく、指定された設定セットを使用する電子メールの送信を自動的に一時停止することができます。
もし、あなたがエンタープライズ規模の ISV のお客様で、数万人の下流の顧客をお持ちの場合、Amazon SES が提供する最大クォータに達してしまう可能性があります。この場合、1) AWS の SES アカウントの例外を要求します – このアプローチでは、既存のアカウントに適用されるクォータをより高い閾値に引き上げるよう AWS に要求することで、以前の使用状況とレピュテーションに応じて AWS がより多くの顧客/テナントを収容するためにアカウントの上限値を引き上げます。これを行うには、AWSのサポートケース「サービス制限の引き上げ」を作成し、Amazon SES アカウントのクォータをより高くしたい理由を提示する必要があります。なお、この例外が常に許可される保証は無いことにご留意下さい。例外申請が却下された場合、2 つ目の選択肢である 2) 複数の AWS アカウントで顧客をセグメント化する方法、に進む必要があります。この方法では、SES を使用してメール送信の仕組みを設定するために、事前に顧客数を計算し、同じ AWS リージョン内の複数のアカウントに下流の顧客を分散させる必要があります。2 つ目の選択肢を更に理解するために、以下のアーキテクチャ図をご覧ください。
複数の AWS アカウントを利用したマルチテナント
上記アーキテクチャでは、様々なテナントが異なる AWS アカウントで Amazon SES に接続し、マルチテナントを実装しています。電子メールイベントの応答は、同じ AWS リージョンまたは異なるリージョンにある中央データレイクに戻すことができます。さらに上図のように、異なるテナントにマッピングされたすべての AWS アカウントは親 AWS アカウントの下にあります。この階層構造は、AWS Organizations によって構成することができます。複数の AWS アカウントを作成して一元管理する組織に統合することが可能になるため、AWS Organizations のご利用をお勧めします。AWS Organizations を利用することで、複数の AWS アカウントを自分の作成した組織に統合し一元管理することができるため、セキュリティやコンプライアンスのガイドライン、すべての子アカウントの統合請求の管理などに役立ちます。
まとめ
Amazon SES における適切なマルチテナント実装は、最終顧客のレピュテーションの管理に役立つだけでなく、各ユーザーの利用状況を互いに独立して追跡するのに役立ちます。このブログ記事では、Amazon SES のユーザーがどのように Amazon SES を利用して多数の最終顧客を管理できるか、Amazon SES でマルチテナントアーキテクチャを実装するための設計ベストプラクティスとは何かについて紹介しました。
Satyasovan Tripathy は、Amazon Web Services でシニアスペシャリストソリューションアーキテクトとして働いています。インドの Bengaluru を拠点に、AWS customer developer service product portfolio を専門としています。仕事以外では読書と旅行が好きです。
翻訳はソリューションアーキテクト 杉本 晋吾 が担当しました。原文はこちらです。