はじめまして、ネットコムの越川と申します。
Amazon QuickSight(以降QuickSight)について調査する機会があったので、ナレッジとして本記事に纏めました。 具体的には、QuickSightの埋め込みダッシュボードの種類と実装方法です。埋め込みの定義については後程、解説しますのでご安心下さい。
想定する読者は、 ダッシュボードの埋め込みをしたいんだけど、何がベストなのか良く分からない、、という方です。 僕自身、最初は良く分からなかったので、同じ境遇にいる方の一助になれば幸いです。 概要編では埋め込み方式の種類を整理して、実装編では具体的にどうやって埋め込み処理をするのかデモ環境を交えて解説したいと思います。
QuickSightとは
QuickSightを一言で説明しますと、AWSが提供するBIツールです。BIツールとは様々なデータを分析・見える化することで経営や業務に役立てるツールを指します。概要を理解する上で、以下４つの基本用語を押さえる必要があります。
こちらの動画でも分かりやすく解説されています。
① データソース
➁ データセット
➂ 分析
④ ダッシュボード
一つずつ解説していきます。
① データソース
データの提供元です。データソースは、Amazon RDSやS3などのAWS内のサービスを指定することも可能です。
AWS他のサービスに加えて、他のSaaSサービスやCSVなどのファイルを利用することもできます。
➁ データセット
データソースをベースにした定義情報です。
もう少しかみ砕くと、データソースを操作し易いようにカスタマイズしたもの になります。
例えば、Excelの表ファイルをデータソースとして利用する場合、不要な列を削除したり、新しい計算列を追加するといったことが可能です。操作し易いようにデータソースをカスタマイズして、データセットとして定義します。
➂ 分析
データセットを分析・視覚化したものです。
先ほどのExcelの表ファイルで例えると、単純な表形式のデータを様々な形で視覚化することができます。
視覚化のタイプはビジュアルタイプと呼ばれており、グラフや図など複数のパターンが提供されています。
④ ダッシュボード
分析の読み取り専用版です。
今回の主題であるダッシュボードの埋め込みとは、このダッシュボードを指します。
ダッシュボードは他のユーザと共有することが可能です。
何となくイメージがついたかと思いますので、利用時の大まかな手順を記載します。
①データソースからデータを取り込んでデータセットを作成します。
➁データセットから分析を作成し、データの分析と視覚化を行います。
➂作成した分析をダッシュボードとして公開して、他のユーザと共有します。
ダッシュボードの閲覧方法は２つあります。 一つ目は、実際にQuicksightにログインして閲覧する方法で、二つ目は個人で作成したアプリケーションに埋め込む方法です。 今回の主題は二つ目のアプリケーションに埋め込む方法になります。 その埋め込み方式は、様々なパターンがあります。 具体的な種類については、次章以降で整理していきます。
エディション
埋め込みダッシュボードを利用する上で、先ずエディションについてする理解する必要があります。
※エディションとは一般的に製品自体は同じだが価格や機能が異なるパッケージを指します。
QuickSightでは、StandardとEnterpriseの２種類のエディションが提供されています。Standardでは、埋め込みダッシュボードの機能はサポートされていないため、自ずとEnterpriseを利用することになります。各機能のサポート有無はこちらをご確認下さい。
加えて注意が必要なのは、後述する「①公開方式」の全ユーザ向けを選択される場合は、
別途、セッションキャパシティプランの購入が必要となります。
詳細は①公開方式で説明します。
ダッシュボードの埋め込みパターン
埋め込みの方法は一言で言うと、ＵＲＬを発行してダッシュボードを表示させたいアプリケーションに記載するだけです。とは言え、実際にはそんなにシンプルではありません。このＵＲＬ発行をする上で、検討すべき3つの方式があります。
①公開方式
➁ＵＲＬの発行方式
➂発行したＵＲＬの埋め込み方式
概要は以下の通りです。１つずつ詳しく見ていきたいと思います。また、埋め込みの概要はこちらのドキュメントが参考になります。
| No | 方式 | 概要 | 実装 | 概要 |
|---|---|---|---|---|
| 1 | 公開方式 | ダッシュボードを公開する範囲 | 登録済みユーザ | QuickSight登録済みユーザ向け |
| 全ユーザ | QuickSight未登録ユーザ向け | |||
| 2 | URL発行方式 | ダッシュボードURLの発行方式 | ワンクリック方式 | GUIから発行する方式 |
| API方式 | APIを実行して発行する方式 | |||
| 3 | URLの埋め込み方式 | 発行したURLの埋め込み方式 | iframe | iframeタグを利用した方式 |
| SDK | 専用のSDK(JavaScript)を利用した方式 |
①公開方式
公開方式は大きく分けて、登録済みユーザ向けと全ユーザ向けの２種があります。
登録済みユーザ向けとは、QuickSight上に登録されているユーザという意味です。前提として、QuickSightを利用するにはユーザ登録が必要になります。ユーザは複数の種類が存在し、Emailベースの認証やIAMユーザ、AzureADなどのIdpを利用したSSO方式など様々です。そのQuickSightに登録されているユーザ向けに埋め込みダッシュボードを公開する方式という意味になります。
一方で、全ユーザ向けというのは、QuickSight側での認証を必要としない公開方式です。先ほど、QuickSightを利用するには、ユーザ登録が必要と記載しましたが、この公開方式を使えば登録処理を省くことが可能です。登録済みユーザ向けの場合は、QuickSight側でのユーザ管理が必要になりますが、全ユーザ向けの場合、全てのユーザが匿名ユーザ（Anonymous）として処理されます。つまり、QuickSight側のユーザ管理をする必要が無くなります。
全ユーザ向けを利用する場合は、セッションキャパシティプランというサブスクリプションの購入が必要になります。このセッションキャパシティというのは、言わばセッションをまとめ買いするという考え方です。全ユーザ向けの場合は、QuickSight側で認証を通さないため、セッションを事前にまとめ買いして、そこからセッションを消費していきます。
セッションの詳細については、こちらの「よくある質問」をご確認下さい。
➁URLの発行方式
URLの発行方式は大きく分けて、ワンクリック方式とAPI方式の２種があります。
ワンクリック方式は、文字通りワンクリックでURLを発行できる方式です。QuickSightのダッシュボードページから、「埋め込みコードをコピー」を押下すると、iframeタグに埋め込まれた状態でクリップボードにコピーされます。
※「リンクをコピー」を押下すると埋め込みURL単体のコピーも可能です。
<iframe width="960" height="720" src="生成された埋め込みURL"></iframe>
URL自体は永続性があるため、一度、発行すれば定期的に再発行するなどのオペレーションも発生しません。
ただし、登録済みユーザ向けの場合は、QuickSightの認証画面にリダイレクトされるため、エンドユーザが都度、認証情報をブラウザ上から入力する必要があります。もちろん、全公開の場合は、認証は不要のため、リダイレクトされる心配はありません。
API方式は、AWS側で提供されているAPIを利用して発行する場合です。APIはAWS CLIから利用することも可能ですし、JavaやPythonなどの言語を使うことも可能です。 下図はユーザ認証を不要とする場合のフローです。 ここで注意が必要なのはAPIを実行するのはアプリケーションサーバであって、クライアント(ブラウザやモバイルアプリ)ではありません。 また、アプリケーションサーバには別途、QuickSightへのアクセスを許可するIAMロールの付与が必要になります。 登録済みユーザ向けとして認証を必要とする場合は、別途、idプロバイダーとの連携が必要となります。 先述の通り、ワンクリック方式ですと登録済みユーザ向けの場合、認証画面にリダイレクトされてしまいますが、API方式の登録済みユーザ向けの場合は、APIのパラメータにQuickSightのユーザ情報を渡すため、バックエンドで認証を通すことができます。 APIの詳細はこちらが参考になります。
➂発行したURLの埋め込み方式
①と➁では、埋め込むダッシュボードをどのスコープで公開して、どうやってURLを発行するかをお伝えしました。 最後は、その発行したURLをどうやってコンテンツファイルに埋め込むかです。 埋め込み方式は大きく分けて、iframe方式とSDK方式の２種です。 iframe方式の場合は、HTMLのiframeタグを利用して埋め込む方式で、ワンクリック方式でも記載した通り、非常に簡単な方法となります。
一方でSDK方式の場合は、埋め込み専用のSDKを利用して埋め込みます。 iframe方式と異なる点は様々なパラメータを渡してダッシュボードをカスタマイズできるという点です。 iframeより柔軟にダッシュボードのサイズを変更したり、別のダッシュボードに遷移させるといった豊富な機能が提供されています。 詳細な機能は実装編で解説したいと思いま SDKの詳細はこちらのドキュメントが参考になります。
構成パターン
つらつらと説明してしまいましたが、最終的な利用パターンはこちらの計８種となります。 ただし、記載の通り、No2と4は公式未推奨となります。 公式ドキュメントにもこのパターンは記載されておらず、サポートに問い合わせましたが非推奨との回答でした。
また、ワンクリック方式の場合、公式ドキュメント上では以下の表記となっているため、そちらに合わせています。
登録済みユーザ向け⇒エンタープライズワンクリック
全ユーザ向け⇒パブリックワンクリック
| No | URL発行方式 | 公開方式 | 埋め込み方式 | 備考 |
|---|---|---|---|---|
| 1 | ワンクリック方式 |
ワンクリックエンタープライズ （登録済みユーザ） |
iframe | |
| 2 | SDK | 公式非推奨 | ||
| 3 |
ワンクリックパブリック （全ユーザ） |
iframe | セッションキャパシティの購入が必要 | |
| 4 | SDK | 公式非推奨 | ||
| 5 | API方式 | 登録済みユーザ | iframe | |
| 6 | SDK | |||
| 7 | 全ユーザ | iframe | セッションキャパシティの購入が必要 | |
| 8 | SDK |
検討方法
初見ですと、結局どのパターンを採用すれば良いの？？って感じですよね。 要件次第なので、これにすべき！！とは断言はできないのですが、 選定ポイントとしては上記の３つの方式を一つずつ整理すると良いかと思います。
①公開方式
全ユーザ向けと登録済みユーザ向けの２種類がありましたね。
全ユーザ向けを利用すれば、QuickSightのユーザ管理をする必要はありません。
一方で、先述の通りセッションキャパシティの購入が必要になります。
月額でも＄250、年間だと最安でも$20,000かかりますので、決して安い買い物ではありません。
※2022/10月時点
登録済みユーザ向けの場合は、QuickSight側でのユーザ管理が必要になりますが、仕組化である程度、運用の負担を減らすことはできるかなと思います。 ユーザの利用規模や運用方針に基づいて判断していただければと思います。
➁URLの発行方式
ワンクリック方式とAPI方式の２種類がありました。
ワンクリック方式ですと、文字通りワンクリックで埋め込みURLを生成できるので実装の手間は少ないです。
ただし、登録済みユーザ向けのワンクリックを選定した場合は、アプリケーションユーザが都度、QuickSightの認証画面にリダイレクトされるので、ユーザによる認証作業が発生します。
全ユーザ向けのワンクリックを選定した場合はその心配は不要ですが、先述の通りセッションキャパシティの購入が必要であることをお忘れなく。 一方で、API方式は別途、APIにパラメータを設定したり、アプリケーションからAPIを呼び出したりなど実装の手間がかかります。 その代わり、登録済みユーザ向けでも、API方式を採用すればバックエンドで認証を通すことができるので、ユーザによる認証作業は省くことが可能です。
➂発行したURLの埋め込み方式
iframe方式とSDK方式の２種類です。
これは個人的にSDKの利用をお勧めします。
先述の通り、SDKでは様々なカスタマイズ機能を提供しているからです。
当初は特に使わなかったとしても、将来的に埋め込みの要件が変わった際に活用することも可能です。
また、コンテンツファイルにscriptタグを挿入すれば直ぐに使えるので気軽に利用できます。
さいごに
埋め込みダッシュボードは考慮点が多いため、大局的に情報を整理して判断して下さい。 次回の実践編では、具体的な実装方法をデモ環境を交えて解説します。 最後まで読んでいただきありがとうございました。
