Amazon Pinpoint のマルチテナント実装方法

Amazon Pinpoint でマルチテナンシーを実現するアプローチ

ビジネスは常に進化しており、複数の製品ライン、顧客セグメント、あるいは地理的なロケーションを管理することも少なくありません。さらに、独立系ソフトウェアベンダー (ISV) である企業間取引 (B2B) 企業の多くは、顧客のマーケティングオートメーション環境を管理する必要があります。このような複雑性から、効率的に適応・拡張できる強固な顧客エンゲージメント戦略が必要になります。しかし、テナントごとにバラバラのシステムを管理は手間なだけでなく、リソースを大量に消費し、運用コストの増加や潜在的なデータのサイロ化につながります。Amazon Pinpoint のマルチテナント設定は、これらの課題に取り組み、企業が統一されたアーキテクチャの下で顧客エンゲージメント活動を効率的に実現します。

実現のポイントは、マルチテナントを採用するかどうかだけではなく、お客様固有のビジネス要件に合わせてどのように実装するかです。 Amazon Pinpoint では、これを実現するために複数のアプローチを用意しています。このブログでは次の 3 つについて説明します。

Single Account / Single Pinpoint Project (SA/SP): 1 つのアカウントで、1 つのPinpoint Project を用意する方法になり、シンプルに実現できます。ただし慎重な権限管理が必要です。
Single Account / Multiple Projects (SA/MP): 1 つのアカウントで複数の Pinpoint Project を用意する方法になり、きめ細かな管理が可能です。ただしクォータによる制限が存在します。
Multiple Accounts / Multiple Projects (MA/MP): マルチアカウントで複数の Pinpoint Project を用意する方法になり、拡張性が非常に高くなります。ただし包括的な監視が必要になります。

それぞれの長所、短所、最適なユースケースを掘り下げ、配信チャネルの要件に応じて異なるマルチテナンシー構成を選択する方法についても掘り下げることで、アーキテクチャの判断ができます。

このブログを通して、検討の複雑さを解消し、ビジネス目標に合わせて Amazon Pinpoint のアーキテクチャ設計に役立てることができます。

Single Account / Single Pinpoint Project (SA/SP)

概要

Single Pinpoint Project のセットアップでは、すべてのカスタマーのアクテビティが 1 つのプロジェクト内に存在します。この場合のマルチテナントの実装方法は、顧客のエンドポイント属性が活用できます。これを活かすことで、Amazon Pinpoint を初めて使用する人でも簡単に管理ができます。この場合の設定例を以下に示します。

1つの Pinpoint Project を用意し、複数のテナントの情報を管理する場合、エンドポイントのカスタムユーザー属性を利用してテナント情報を管理することができます。また、キャンペーン情報のタグ機能を利用することで、テナントごとにキャンペーン情報を管理することができます。この設定を行うために必要な要素を以下に示します。

顧客データを保持する S3 バケット
- Pinpoint にインポートする顧客情報リストを保存する S3 バケットを用意します。Amazon Pinpoint では S3 に配置した CSV ファイルをセグメントとしてインポートすることができます。Amazon Pinpoint でテナントごとの設定を行うため、テナント情報をカスタムユーザー属性として CSV ファイルに記載します。
1 つの Amazon Pinpoint プロジェクト
- Amazon Pinpoint Project を 1 つ作成します。
- 配信するチャネルごとの設定をします。
- テナント情報にはタグ機能でキャンペーン情報を割り当てることができます。
Amazon Kinesis
- Amazon Pinpoint のイベントストリームの設定を利用することで、Amazon Kinesis 経由で S3 に保存することができます。
イベントデータを分析するための Amazon Athena と S3 バケット
- Amazon Pinpoint のイベントデータを S3 に保存し、Athena 経由で分析します。このソリューションを活用できます。

この構成を採用する際の注意点として、顧客のエンドポイント情報が同じ Pinpoint Project 内に存在することが挙げられます。カスタム属性など各テナントを識別できる値を指定し、 AWS Identity and Access Management(IAM) ポリシーで解決することも可能ですが、アクセス権や属性の管理は各自で行う必要があります。

また、エンドポイントを追加するには、Channel と Address を指定する必要があります。1 つのプロジェクトで、異なるエンドポイントに同じ Channel と Address を指定することはできないため、注意が必要です。以上のことから、エンドポイントの Channel と Address がテナント間で重複しなければ、独自のアクセス許可制御を構築することが可能であるため、このパターンを検討することができます。

他のパターンに比べて必要なコンポーネントが少ないため、構成が容易になります。Pinpoint API を使い、Pinpoint 側の設定をできるだけ簡略化したいというお客様は、この方法を選択できます。しかし、この方法は、後にテナントが増えるにつれて管理が複雑になる可能性があります。例えば、テナントの詳細なレポートを作成したい場合に課題になる場合があります。Amazon Pinpoint プロジェクトで詳細なレポートを作成するには、各キャンペーンやジャーニーに専用のタグを設定する必要があります。

最後に、Amazon Pinpoint Project と AWS アカウントごとのサービスクォータに注意し、ユースケースに応じて拡張性を持たせるようにしてください。

Single Account / Multiple Projects (SA/MP)

概要

このアーキテクチャでは、Amazon Pinpoint 環境を構築するために単一の AWS アカウントで、顧客またはテナントごとに複数のプロジェクトを作成します。この場合の構成例を図に示します。

この例では、複数の Amazon Pinpoint プロジェクトを作成します。SA/SP の場合と大きく異なる点は、顧客のエンドポイント情報を完全に分離できることです。顧客データのセグメントをインポートする場合、S3 から対象の Pinpoint Project にインポートするだけで、各テナントを別々の状態で管理することが可能です。これにより、IAM ポリシーによる権限管理が容易になります。

また、Amazon Pinpoint では、該当アカウントで取得した送信用のメールアドレスや SMS 番号、メッセージテンプレートなどを全プロジェクト共通で利用することができ、プロジェクトごとのイベントデータを Amazon Kinesis 経由で集約することができます。このような構成をとることで、基本的な設定情報の管理やオペレーターの操作はそのままに、プロジェクトごとにエンドポイント情報を分離できるメリットが得られます。

この構成を設定するために必要な要素は下記になります。

顧客データを保持する S3 バケット
- SA/SPと同様に、Pinpoint にインポートする顧客情報のリストを格納する S3 バケットを用意します。インポートする CSV はプロジェクトごとに用意します。
Amazon DynamoDB テーブル
- Pinpoint のプロジェクト情報を管理するための DynamoDB（またはその他のキーバリューデータベース）テーブルを用意します。テナント情報などをメタデータとして DynamoDB テーブルに格納できます。
AWS Lambda
- Lambda を使用して Pinpoint のプロジェクトを作成します。Amazon Pinpoint では、Amazon Pinpoint API、AWS SDK、または AWS Command Line Interface (AWS CLI) を使用してプロジェクトを作成および設定することもできます。そのため、Pinpoint のプロジェクトと関連するキャンペーン/ジャーニーの作成を自動化することが可能です。テナント情報も作成時に DynamoDB に登録します。
複数の Amazon Pinpoint プロジェクト
- 上記の Lambda で作成した Project です。テナントごとに Pinpoint Project が存在することになり、エンドポイント情報が完全に分離されます。また、IAM 機能を利用することで、プロジェクトごとにアクセス権を制御することも容易です。
- メッセージテンプレート：テンプレートを作成し、プロジェクト間で共有することができます。
- Amazon Pinpoint のイベントストリーム設定を使うことで、キャンペーン、ジャーニー、アプリ、チャンネルのイベントを Amazon Kinesis にストリーミングできます。複数の Amazon Pinpoint プロジェクトを 1 つの Amazon Kinesis にストリームすることができます。正しくセットアップすると、イベントデータには関連するテナント情報がタグ付けされ、分析ソリューションでストリームを解析できるようになります。
イベントデータを分析するための Amazon Athena と S3 バケット
- Amazon Pinpoint のイベントデータは Amazon S3 に保存され、Amazon Athena を介して分析します。この場合、分析ソリューションである Amazon Athena を使うことで、テナントに応じたイベントデータのフィルタリングを行うことができます。詳細については、このソリューションを参照してください。

注意点として、Pinpoint は、AWS アカウントあたり 100 プロジェクトというソフトリミットがあります (サポートチケットで増やすことは可能です）。その他のクォータも、プロジェクトとアカウントレベルで適用されるため、考慮する必要があります。

以上のことから、SA/MP を使用する場合、アカウントごとのクォータに制限があること、個々のテナントのプロジェクト作成プロセスを自動化するには、より多くの初期設定が必要になることに注意する必要があります。しかし、SA/SP アーキテクチャーと比較すると、より多様な顧客データをより安全に管理し、効率的に運用できることが期待できます。

Multiple Accounts / Multiple Projects (MA/MP)

概要

MA/MP のアプローチに入る前に、この構成における AWS Organizations の役割を理解することが重要です。AWS Organizations は、複数の AWS アカウントを 1 つの組織に統合し、ガバナンスとコストの一元化を実現できます。この機能は、単一の中央管理 AWS アカウントから複数の AWS アカウントと Amazon Pinpoint プロジェクトを効果的に管理できるため、MA/MP セットアップで特に有用です。AWS Organizations の詳細については、AWS Organizations の公式ドキュメントを参照してください。

MA/MP セットアップでは、顧客またはテナントごとにそれぞれの AWS アカウントを利用します。この場合の構成例を以下に示します。

この例では、Management アカウントを作成し、その下に複数の AWS アカウントを用意しています。Management アカウントでは AWS Account ID と Pinpoint Project ID を管理し、プロジェクトを Lambda で作成します。顧客データやイベントストリームデータは Management アカウントで管理し、各プロジェクトの情報を集約しています。この構成の大きなメリットは、個々のテナントのアクションを分離できることで、ノイジーネイバーなどのアンチパターンを防ぐことができます。また、単一の AWS アカウントでは処理できないクォータの制約からも解放されます。さらに、Amazon Pinpoint は CloudFormation のカバレッジに優れており、再現性の高いアーキテクチャを自動的にデプロイすることも可能です。

この設定の設定に必要な要素を以下に示します。

AWS Organizations
- 複数のアカウントを管理するために Organizations を設定します。複数のアカウントを設定するためのベストプラクティスを参照してください。
Management アカウント
- 複数のアカウント情報を管理するためのアカウントを作成します。アカウント間でリソースを操作する場合は、IAM ロールとサービスコントロールポリシー（SCP）を使用します。これにより、アカウントをまたいだアクセスが可能になります。必要な要素は前述の SA/MPと同じです。
  - 顧客データを保持する S3 バケット: AWS では、アカウントをまたいで S3 データを利用できます。クロスアカウント設定を行い、顧客データを各アカウントにセキュアに紐付けられます。
  - Dynamo DB テーブル: AWS Account ID、Pinpoint Project ID、それに紐づく管理情報を保持します。
  - AWS Lambda: Lambda を使用して Pinpoint Project を作成します。
  - イベントデータを分析するための Athena と S3 バケット: 複数のアカウントや Pinpoint Project のイベント情報を集約して分析します。
テナントごとの AWS Account と Pinpoint Project
- テナントの分け方に応じて、AWS Account と Pinpoint Project を用意します。AWS CloudFormation を利用したアカウント作成の自動化も検討できます。
- アカウント毎に配信チャネルのメールアドレスや SMS 番号等を設定する必要がある場合があります。(詳細は次のセクションを参照)
- Amazon Kinesis はアカウント毎に用意されますが、俯瞰してレポーティングしやすいように全て Management アカウントの同じ S3 に保存させます。

注意点としては、アカウントが分かれているため、それぞれを管理する必要が出てくることです。例えば、新規作成したAWS アカウントはサンドボックス状態になり、サポートチケットによる本番利用申請がアカウントごとに必要になります。また、レピュテーションはすべて1つのAWS アカウントで行われるため、アカウントごとにレピュテーションを監視する必要もあります。

Amazon Pinpoint のチャネルごとのアプローチ : 提供サービスとアーキテクチャの整合性

マルチテナントのための Pinpoint アーキテクチャを選択するだけでなく、どのチャネルでサービスを提供するのが最適かを決定し、その決定がマルチテナンシーアーキテクチャの選択にどのように影響されるかを決定することが極めて重要です。以下に、マルチチャネル、マルチテナント構成に役立つ Amazon Pinpoint の機能と、各チャネルで注意すべき潜在的な課題について列挙します。

E メール

E メールは、Amazon SES の設定セットと E メールサプレッションリスト機能と統合でき、最も汎用性の高いチャネルの 1 つです。3 つのマルチテナンシーモデルのいずれにも簡単に適応できます。

設定セット: 設定セットを使用すると、異なる IP プールや異なるイベント送信先を使用して、メール送信アクティビティを分離することができます。
- 設定セットは Amazon Pinpoint と Amazon SES の両方で使用できます。Amazon SES で設定した設定セットのルールは、Amazon Pinpoint を使用して送信するメールメッセージにも適用されます。
- SA/SP および SA/MP: メールテンプレートと送信 IP アドレスは、Pinpoint プロジェクト内の各テナントの構成セットを使用してタグ付けする必要があります。
- MA/MP: E メールテンプレートと送信 IP アドレスは、アカウントのデフォルトを使用して送信するか、設定セットを使用してきめ細かくタグ付けすることができます。
E メールサプレッションリスト: サプレッションリストはアカウントレベルで自動的に管理されます。または、特定の設定がアカウントレベルのサプレッションリストを上書きできるかどうかを指定できます。
- SA/SP および SA/MP
  - すべてのテナントも同じアカウントのサプレッションリストに従います
    - いずれかのテナントがハードバウンスまたは苦情を受けたEメールアドレスに E メールを送信すると、他のすべてのテナントも同じアドレスに E メールを送信できなくなります。
    - アカウントレベルのサプレッションリストは、設定セットレベルで上書きできます。
- MA/MP
  - テナントの 1 人がハードバウンスされた E メールアドレスや苦情のある E メールアドレスに E メールを送信した場合、そのテナントが所属する AWS アカウントのみがサプレッションリストに従います。つまり他のAWSアカウントのテナントは、そのメールアドレスにメールを送信できます。
ノイジー・ネイバーの脅威: 一般的に、あるテナントのパフォーマンスが他のテナントのアクティビティによって低下することを指します。このアンチパターンを E メールで検討する場合、1つの悪質なテナントが環境全体のメール送信アクティビティに影響を与えることを防ぐための対処が必要になります。ある顧客がバウンス率や苦情率の制限を超えた場合、その顧客への送信は一時停止されます。これは、違反の自動レビューのためにリージョンレベルで行われます。
- SA/SP および SA/MP
  - E メールのバウンス率やクレーム率はリージョンレベルで追跡されるため、1つの悪質なテナントからのバウンスや苦情が多い場合、アカウント全体のメール送信ドメインがブロックされる可能性があります。
  - このような事態を避けるためには、個々のテナントが高いバウンス、苦情率を示した場合に警告を発するよう、専用の設定セットとアラームを設定するのがベストプラクティスです。
- MA/MP
  - 最も隔離性が高く、E メール ID、ドメインが1つのテナント、アカウントによってのみ使用可能であることを保証します。
  - 重要: AWSのTrust and Safetyチームでは、手動でアカウントレベル、ドメインレベル、または複数のアカウントに跨いで確認することができ、メール送信の一時停止をすることができます。どのアーキテクチャを採用するかにかかわらず、すべてのテナントの送信アクティビティを責任を持って管理することがベストプラクティスとして推奨されます。
- メール送信クォータ
  - E メール日次送信クォータと E メール送信レートがアカウントレベルで表示されます。
  - SA/SP および SA/MP
    - AWS アカウント内の全テナントの 1 日の送信クォータと送信レートの合計を予測し、それに応じてサービス制限を引き上げる必要があります。そのため、サービス制限のしきい値を正しく見積もるには、より多くの計画が必要になります。
  - MA/MP
    - 各テナントが個別の AWS アカウントを使用するため、個々のテナントのニーズに応じてサービス制限を引き上げることができます。
    - 個々のテナントが事前にメール送信クォータリクエストを通知し、それに応じてAWSアカウントでクォータリクエストが発生するように、ビジネスプロセスを整備することがベストプラクティスになります。
- マルチテナント環境でのメール送信に関する詳細は、SES のマルチテナントに関する AWS ブログを参照してください。

SMS

送信元アイデンティティの取得: OID（電話番号）は AWS アカウントとリージョンに関連付けられています。
- OID はアカウントやリージョンをまたいで利用することができないため、新しい AWS アカウントやリージョンごとに取得プロセスを繰り返す必要があります。
番号のプール: 電話番号や送信者 ID をグループ化する機能です。特に Single Project モデルで、テナントごとに通信をセグメント化するのに便利です。
設定セット: V2 SMS and Voice API のリリースにより、設定セットを使用して、マルチテナント環境の SMS オプトアウトリスト、OID、イベントストリーミング先を管理できるようになりました。
- この方法の詳細については、Amazon Pinpoint で設定セットを使用して SMS を送信する方法についてのブログを参照してください。
ノイジー・ネイバーの脅威
- SA/SP および SA/MP
  - API 呼び出しで OID を指定しない場合、Amazon Pinpoint は (スループットと配信可能性の観点から) 最も適切な OID を使用して SMS を送信しようとすることに注意してください。
  - E メールと同様に、番号プールと設定セットを活用して、SMS 送信アクティビティを 1 つのアカウントに分離できます。新しい OID をリクエストするにはコストと時間がかかるため、これによって SMS OID のレピュテーションを守ることができます。
- MA/MP
  - 最も分離され、1つのテナント、アカウントでのみ使用可能な番号を確保します。
SMS オプトアウト: メールチャネルのサプレッションリストと同様に、オプトアウトはアカウントと設定セットごとに管理されます。そのため、MA/MP 設定では、あるアカウントで配信をオプトアウトした顧客は、他のアカウントからの配信を引き続き受信することできます。

プッシュ通知

Amazon Pinpointは、FCM、APNS、Baidu Cloud Push、ADM などの様々なプッシュサービスと統合しています。

プロジェクトレベルの認証：認証情報は Pinpoint のプロジェクトレベルで設定されるため、個別の管理が必要です。
- 異なるアプリケーションを使用する複数のテナントでは、SA/SP アーキテクチャを使用することはできません。
詳細については、モバイルプッシュガイドを参照してください。

アプリ内メッセージ

Pinpoint のプロジェクトごとの設定：プッシュ通知と同様に、各 Pinpoint プロジェクトに設定できるアプリ内メッセージは 1 つだけです。
- アプリ内メッセージを必要とするアプリケーションが複数ある場合は、SA/SP アーキテクチャを採用できません。
詳細については、アプリ内チャネルのドキュメントを参照してください。

カスタムチャネル

Amazon Pinpoint のカスタムチャネルでは、サードパーティのサービスを含め、API を持つあらゆるサービスを通じてメッセージを送信できます。Amazon Pinpoint からカスタムチャネルを広範囲に使用する場合は、AWS Lambda のサービス制限、特に SA/SP または SA/MP アーキテクチャを検討している場合に注意する必要があります。

まとめ

このブログでは、Amazon Pinpoint でマルチテナントを実装するための複雑な仕組みを紐解いてきました。今回のディープダイブでは、3つのアーキテクチャパターンを取り上げました。

Single Account/Single Project (SA/SP): シンプルな管理を提供する初心者に優しいアプローですが、異なるテナント間で送信アクティビティを分離するためには、細心の注意を払って権限の管理が必要です。
Single Account/Multiple Projects (SA/MP): 顧客データをきめ細かく管理できますが、管理の複雑さは若干増します。注意点として、クォータと潜在的な「ノイジーネイバー」問題になる可能性があります。
Multiple Accounts/Multiple Projects (MA/MP): 管理の複雑さは増すものの、最も柔軟性と独立性が高い方法になります。

各アプローチには、管理・レポートの容易さ、拡張性、顧客データの管理に関するトレードオフがあります。また、マルチテナントの決定が Amazon Pinpoint のチャネル構成にどのような影響を与えるかについても検討しました。E メールや SMS からプッシュ通知まで、アーキテクチャの選択は、これらの配信チャネルをいかに効率的に管理できるかに直接影響します。これらの情報を活用することで、ビジネス目標に沿った意思決定を行うことができます。

次のステップ

Amazon Pinpoint 環境のアーキテクティングと実装をします。このブログ記事で説明したベストプラクティスとアーキテクチャのガイドラインを指針として使用してください。今後、選択するアーキテクチャ構成は、ユーザー数、企業規模、または販売チャネルなど、特定のニーズに合わせて調整する必要があります。初期設定だけでなく、それぞれのサービス制限やクォータを含む長期的な管理面も考慮に入れてください。

著者について

Tristan (Tri) Nguyen

AWS の Amazon Pinpoint および Amazon Simple Email Service スペシャリスト・ソリューションアーキテクト。仕事では、企業システムにおける通信サービスの技術的実装とアーキテクチャ/ソリューション設計を専門とする。趣味はチェス、ロッククライミング、ハイキング、トライアスロン。

中村達也（Nakamura Tatsuya）

AWS でエンタープライズ企業を担当するソリューションアーキテクト。主に商社業界、流通・小売業界を担当し、日本のお客様向けに Amazon Pinpoint の導入支援も行っている。ERP 導入支援や複数の新規 Web サービス立ち上げなど、これまでのキャリアは多岐にわたる。

Amazon Web Services ブログ