Amazon Web Services ブログ
Amazon QuickSight を利用した SaaS 環境でのマルチテナントアプリケーションのサポート
本記事は、Support multi-tenant applications for SaaS environments using Amazon QuickSight を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。
可視化やレポートを利用するアプリケーションやサービスは、顧客の導入を促進し、収益を増やし、競争上の優位性を生み出します。
統合された分析やレポートがない場合、SaaS (Software as a Service) ソリューションの市場での競争力が低下してしまいます。
しかし、自社開発や商用の BI (business intelligence) ソリューションを利用する場合、構築と運用コストがかさみがちです。
Amazon QuickSight は AWS のサーバーレス BI サービスで、組み込みアプリケーションで数千の顧客が利用し、コストを抑えながらもシームレスな可視化や分析体験を提供しています。
この記事では QuickSight のマルチテナンシーに焦点を当てていますが、マルチテナンシー以外のパターンについての詳細は、Build embedded analytics architectures using Amazon QuickSight を参照してください。
多くの組織がマルチテナンシーの利点を享受できますが、運用上のオーバーヘッドやコストをかけずにソフトウェアを利用できる SaaS ソリューションがマルチテナンシーの主なユーザーになります。
SaaS ソリューションの取り組みの１つとして、高品質の BI ソリューションを低コストかつ大規模に提供することがあります。
QuickSight では、セルフマネージドソリューションの運用オーバーヘッドを削減しながら、コスト効率よく機能を提供できます。
さらに、QuickSight のマルチテナンシーは、顧客向けのダッシュボードやレポート作成ソリューションを提供するコンサルティング企業にとっても有用です。
この投稿では、マルチテナント環境における QuickSight のデプロイの方法のガイダンスと、QuickSight アプリケーションでデータの分離とテナントへのリソースのデプロイに関する考慮事項について説明します。
アプリケーション内のマルチテナント機能は、ユーザーグループを相互に分離するメカニズムを提供します。
これらのグループは、異なる企業や地理的領域、または同一企業内の別の事業部門のユーザーかもしれません。
異なるテナントのユーザーは、お互いのユーザー、データ、アセットを見ることができませんが、各ユーザーグループごとに別々のインフラストラクチャを用意する複雑さを軽減できます。
この投稿では、次のトピックについて説明します。
- ユースケースに最適な QuickSight でのデータ分離方式の選択
- QuickSight 内のオブジェクトにアクセスを許可し、デプロイする最適な方法の選択
- テナントユーザーのプロビジョニング
- 全テナントへのアセットデプロイを可能にする開発およびデプロイ手法
グループと名前空間
Amazon QuickSight では、リソースを分離してマルチテナンシーを実現する方法が 2 つあります。グループを利用する方法と、名前空間を利用する方法です。
どちらの方法でも、リソース (データソース、データセット、分析、ダッシュボード) を分離できますが、1 つ根本的な違いがあります。
エンドユーザーがダッシュボードの構築、デプロイ、または共有を行う必要がある場合は、名前空間を使用する必要があります。
エンドユーザーがレポート作成を行う必要があり、Author ライセンスを必要とする場合には名前空間が必須になります。
グループのメンバーシップでは、Author ライセンスを持つ著者がグループ外で新規リソースを共有するのを制限できません。これにより、意図しないデータ漏洩のリスクが高まります。
オブザーバビリティの観点から、名前空間は QuickSight におけるテナントレベルの利用状況の監視を簡素化することで、利用状況の追跡と顧客への請求を容易にします。
グループか名前空間のどちらを使うかを決める前に、それぞれのアプローチの制限事項に関するドキュメントを確認してください。
テナント毎のデータセットとデータソース vs 行レベルセキュリティを使用した単一データセット
QuickSight のマルチテナントアーキテクチャでは、データセットに関する決定を下す必要があります。
この節では、2 つのオプションについて検討します。
どちらのオプションが最適かは、組織のリスク許容度や業界固有のコンプライアンス要件に依存します。
テナント毎のデータセットとデータソース
このシナリオでは、テナントごとにデータセットが存在します。各データセットは、そのテナントに特化したデータを返すように、データフィルタまたはパラメータ付きのカスタムクエリの形式で構成されています。
テナントごとにデータソースを持つ必要はありません。たとえば、Amazon Athena を使用して Amazon Simple Storage Service (Amazon S3) からデータを照会する場合、すべてのテナントで共有される接続詳細を持つデータソースを使用できます。
各テナントのデータセットは、異なるテナント ID で Athena にクエリを送ることができます。
データベースレベルのマルチテナンシーが、テナントごとにデータベース・スキーマやクラスターなどの分離されたハードウェアやスキーマを含む場合、テナントごとにデータソースを 1 つ用意する必要があります。
AWS Lambda 関数を使用することで、テナントごとのアセットのデプロイを自動化することもできます。
このプロセスでは新しいアセットを作成し、そのアセットが特定の名前空間 (テナント) 内のグループまたはユーザーからのみ参照できるように、必要なアクセス許可を適用します。
また Lambda を使用して、必要に応じてテナントのクリーンアップやユーザーおよびアセットの削除を行うこともできます。
次の図はこのアーキテクチャを示しています。
行レベルセキュリティを使用した単一データセット
この例では、全てのテナントの生データを格納した 1 つのデータセットがあり、行レベルのセキュリティ (RLS) が有効になっています。単一のダッシュボードがこのデータセットを指しており、すべてのテナントと共有することができます。
RLS を利用するには、各テナントがアクセス可能なデータを保持する別のデータセットを作成する必要があります。詳細は、Amazon QuickSight での Row-Level Security (RLS) の利用をご覧ください。
次の図はこのアーキテクチャを示しています。
オプションの比較
以下の表は、それぞれのオプションのメリットとデメリットを要約したものです。
| オプション | 長所 | 短所 |
| テナント毎に固有のアセット (データソース、データセット、ダッシュボード) | データの分離を必要とする業界特有の要件に準拠できる | アセットを管理するための自動化が必要になり、開発オーバーヘッドが比較的大きくなる |
| SPICE の利用コストをテナント単位で追跡しやすい | ||
| RLS を利用したテナント間での共有アセット | 実装が単純で開発オーバーヘッドが低くなる | SPICE の利用コストをテナント単位で追跡できない |
| RLS のルールデータセットがセキュリティの要になる | ||
| 保存されたデータの容量が SPICE 制限に達する可能性が高くなる |
プロビジョニング、認証、認可
この記事では、テナント (名前空間)、グループ、ユーザーをプロビジョニングします。他の実装では、ID フェデレーションを使用して、グループを QuickSight の外部で管理できます。
アプリケーションにダッシュボードを埋め込むと、QuickSight でのユーザー管理を排除でき、シームレスなユーザーエクスペリエンスを提供できます。
埋め込みアプリケーションは、ユーザーに代わって QuickSight API を呼び出し、ダッシュボードをユーザーに表示する iFrame で利用できる 1 度だけ利用可能な URL を生成します。
埋め込み URL の作成時にユーザーコンテキストが渡されるため、QuickSight にサインインする必要はありません。
詳細については、Embedding Workflow ワークショップを参照してください。
QuickSight 固有のセキュリティのベストプラクティスについては、Amazon QuickSight のセキュリティベストプラクティスを参照してください。
以下のセクションでは、AWS Identity and Access Management (IAM) のユーザー、グループ、名前空間、アセットを使用して、QuickSight でマルチテナント環境に必要なリソースを作成します。
わかりやすくするため、AWS Command Line Interface (AWS CLI) での例を使用しています。
AWS CLI の代わりに、AWS SDK for Python (Boto3) などの他の SDK を使うこともできます。
テナント (名前空間)
このセクションでは、カスタムの名前空間という形式で最初のテナントを作成し、次にグループを作成します。
名前空間内のグループは、多数のユーザーに対して権限を適用するのに便利です。
次のコマンドを入力します (自分の AWS アカウント ID と名前空間の名前を指定してください):
このプロセスは非同期です。名前空間が作成されたかどうかを確認するには、次のコマンドを入力します。
ユーザー
このセクションでは、IAM ユーザーを作成し、そのユーザーを名前空間の下で QuickSight に登録します。
まず、適切な権限を持つ IAM ユーザーを作成する必要があります。詳細は、AWS アカウントに IAM ユーザーを作成するを参照してください。
次のコマンドを入力して、作成したユーザーを名前空間の下で QuickSight Author として登録します。
テナント間でのアセットのデプロイ
このセクションでは、テナント間でデータセットをデプロイするプロセスを確認します。AWS CLI を使って JSON 形式でデータセットをエクスポートし、テンプレートを作成することで、さまざまなテナントにデータセットをデプロイできるようになります。
AWS CLI コマンドまたは Python 用の SDK を Lambda と組み合わせて、エクスポートとデプロイのパイプラインを作成し、本番ワークロードでこれらのパイプラインを自動化できます。
QuickSight には、アセットをコードとしてエクスポートする 2 つの方法があります:
- 標準の API (例: describe-dashboard) を使用する
- バンドル API を使用する
バンドル API を使用すると、すべての依存関係を単一のエクスポートファイルにバンドルすることで、エクスポートプロセスが簡素化されます。
マルチテナントの環境でアセットを開発する場合、開発用の名前空間を割り当ててください。
デフォルトの名前空間または顧客の名前空間を使用できます。
次の図は、名前空間間でのアセットのエクスポート、テンプレート化、インポート処理を示しています。
バンドルエクスポートとしてアセットをデプロイするには、以下の手順を完了してください。
- エクスポートしたいダッシュボードの ARN を取得するには、次のコマンドを入力します:
- 取得したリソース ARN を使って、エクスポートジョブを開始します。AWS CLI では、ダッシュボードが使用しているデータセットとデータソースがエクスポートされるように、依存関係を含める必要があります。この記事では、エクスポート形式は JSON を使用しますが、AWS CloudFormation もサポートされています。次のコードを参照してください。
–asset-bundle-export-job-id の値はエクスポートジョブの期間中、一意である必要があります。QuickSight では、アセットバンドルエクスポートジョブを最大 5 つ同時に実行できます。
エクスポートジョブは、ダッシュボード、データセット、データソース JSON 出力 (または CloudFormation 形式) を含む .qs ファイル拡張子の .zip ファイルを生成します。
この .zip ファイルは Amazon S3 に保存されます。
エクスポート ジョブが完了すると、.qs ファイルの場所を示す S3 の署名付き URL が生成されます。この URL は 5 分間だけ有効です。この URL が期限切れになった場合は、describe-asset-bundle-export-job コールを実行して再度有効化してください。
- API が非同期であるため、バンドルのエクスポートの進捗状況を確認するには、次のコマンドを入力してください:
次のコードは、出力がどのようになるかを示しています。
- DownloadUrl の値をコピーし、curl を使って Amazon S3 からファイルをダウンロードします。DownloadURL の値を二重引用符で囲むようにしてください:
-
以下のコマンドを使用して、コンテンツを解凍してください。
次のスクリーンショットは、フォルダ構造がどのようになるかを示しています。
QuickSight には、インポート中にホスト名、パスワード、データ ソース名などのパラメーターを上書きする場合に、すぐに使えるいくつかのオプションが用意されています。これを行うには、AssetBundleImportJobOverrideParameters API を使用してください。
パラメータ化しようとしている属性が API でサポートされていない場合は、それらのパラメータをテンプレート上で手動で追加する必要があります。スクリプトを使ってパラメータを検索し、必要な値に置き換えることができます。この記事では、検索と置換のプロセスについては扱いません。
エクスポートされたバンドルのファイルを見ると、各 JSON ファイルには ID として datasourceId、dataSetId、dashboardId があり、次のスクリーンショットのように、更新する必要のある name キーがあります。
テナントごとに dashboardId、datasetId、name を一意にすることは必須です。
次の例には、国用のデータセットフィルターがあり、テナントごとに異なる値に設定する必要があります。ダッシュボードには同じフィールドやフィルターがない場合があります。表示・設定したい列またはフィルターを選択します。
次のスクリーンショットでは、元のフィルタを示しています。
次のスクリーンショットは、新しいパラメータでフィルターしたものを示しています。
ここで、プロセスを自動化して、スクリプトに {{ COUNTRY_PARAMETER }} を関連する値に置き換えさせることができます。
- この投稿では、手作業で
{{ COUNTRY_PARAMETER }}に値を設定してファイルを保存します。 dashboard、dataset、datasourceフォルダと同じディレクトリレベルに移動し、新しい .zip ファイルを作成してください。
- 新しいバンドルファイルを Amazon S3 にアップロードします:
-
以下の AWS CLI コマンドでインポートジョブを開始します:
-
進行状況を確認するには、次のコマンドを入力してください。
バンドルをインポートした後、作成されたアセットは、誰からも見えたり、アクセスできない状態になっています。これは、設計上、バンドルにはアクセス許可が含まれていないためです。
-
複数のテナントにアクセスできるようにするため、新しいダッシュボードにグループの権限を追加するには、次のコマンドを入力します (YOUR_PRINCIPAL_ARN の値は作成した IAM ユーザーを指定できます)。
テナントグループのダッシュボードの権限を更新したら、ジョブが完了し、ユーザーがそれにアクセスできるようになります。ユーザーがデータセットにアクセスする必要がある場合は、そのアセットの権限を更新する必要があります。
-
次のコマンドを入力してパーミッションを更新してください:
アセットを別の名前空間にデプロイ
別の名前空間にアセットをデプロイするには、テンプレートにパラメータを追加することから始め、前述の手順を繰り返します。
結論
この記事では、マルチテナントの SaaS 環境で QuickSight レポートをデプロイする際の設計上の考慮事項について説明しました。
設計する上で最初に決定しなければならないことは、テナント間での権限分離についてです。
テナントがリソースを作成または編集できる場合は、名前空間が最適です。
その次の設計の判断基準は、行レベルセキュリティを持つか、テナントごとに単一のデータセットを持つかです。
SPICE データセット間の分離を持つには、テナントごとのデータセットが必要です。
この記事の最後のセクションでは、テナント間でアセットバンドルをデプロイする方法のガイダンスを提供しました。
QuickSight の組み込み分析とマルチテナンシーの詳細は、Build embedded analytics architectures using Amazon QuickSight および Embed multi-tenant analytics in applications with Amazon QuickSight を参照してください。
著者について
Evangelos Pertsinis は、アマゾンウェブサービスのソリューションアーキテクトです。彼は、顧客が AWS テクノロジーを効率的に活用できるよう支援しています。エンドツーエンドのデータ ソリューションの設計と構築の経験を持つエヴァンゲロスは、顧客と協力してデータの価値を引き出すことに情熱を注いでいます。自由時間には、エヴァンゲロスはサッカー、ハイキング、釣りを楽しんでいます。
Mike Gillespieは、アマゾンウェブサービスのプリンシパルソリューションアーキテクトです。彼は、AWS でソリューションを実行するソフトウェア会社と協力し、AWS を使用して製品を改善するのを支援しています。 Mike は、機械学習、分析、サーバーレス、セキュリティなどのさまざまなドメインでソリューションを構築する、実践的なテクノロジを好むビルダーです。仕事以外では、マイクは屋外でランニングやパドリングをしたり、ポッドキャストを聴きながら犬の散歩をしたり、写真を撮ったりすることを楽しんでいます。
Ramon Lopezは、Amazon QuickSight のプリンシパルソリューションアーキテクトです。 BI ソリューションの構築に長年の経験と会計のバックグラウンドを持つ彼は、顧客と協力してソリューションを作成し、世界クラスのサービスを作成することが大好きです。仕事以外の時は、海や山など屋外で過ごすことを好みます。