about
埋め込み QuickSight で BI アプリケーションをつくることになったものの、いろいろわからんことが多かったので調べたり聞いたりしためも。マルチテナントで作りたかったので、ユースケースとしては
- 埋め込み
- マルチテナント
あたりに記事の内容はフォーカスするかも。
資料
QuickSight は EC2 とかと違って、巷にあんまり Qiita とか Zenn の記事が転がっていない。一方ドキュメントも例のごとくわかりやすくないので、資料を見つけるところから大変だった。
結論、 Black belt とか AWS が配布してるスライド資料が役に立つし SA さんからもこれらを案内された。
Amazon QuickSight におけるシングルサインオンの設計と実装
- 一番見た資料
- ユーザ管理についての説明
- アプリケーションの構成の例も載ってる (p.81)
- 二番目に見た資料
- この通りにつくればマルチテナントの埋め込みアプリがつくれる
このほかの資料
- Amazon QuickSightの埋め込み方法をちょっぴりDeep Dive
- Amazon QuickSight の分析機能をマルチテナントのアプリケーションに埋め込む
- Amazon QuickSight アカウント/ユーザー管理におけるポイント
- Amazon Quicksight 埋め込みハンズオン
QuickSight の基礎?知識
QuickSight とは
そもそも QuickSight は AWS が提供する BI マネージドサービスで、 BigQuery や S3, Athena, Salesforce などいろいろなデータソースからデータを引っ張って可視化できる。
QuickSight の概念
- data source
- data set
- visual/analysis/dashboard
- user
- group
- namespace
あたりがコアの概念。
Amazon Quicksight 埋め込みハンズオン の ここ にまとまっていて、図にするとこう↓
まず、マルチテナントにおいて重要なのがテナントごとの独立したリソース管理で、それが QuickSight の namespace で実現できる。というのをテナントごとにつくれば、テナントごとに独立したリソース管理ができる。
このほか、visual が一個一個のチャートや表などで、 analysis・dashboard は複数の visual を持つ。analysis は visual を「作る」場所で、 dashboard は上司とか顧客に visual を「見せる」場所.. というのが自分の理解。
これが visual をつくる analysis
こっちは dashboard
User と Group に関しては名前のままだけど、マルチテナントの場合は namespace ごとに user/group を作成するところがポイント。なので、「QuickSight にユーザを追加します」というより「QuickSight のこの名前空間にユーザを追加します」という操作になる。
default namespace と custom namespace (カスタム名前空間)
QuickSight では必ずしも namespace を設定しないといけないわけではなく、たとえば社内用の QuickSight だと名前空間はつくらないで運用している。ここであえてちょっと分かりにくい文になっているのは、もともと QuickSight には default namespace (デフォルト名前空間) が作られていて、マルチテナント運用にしない場合はすべてこの default namespace の中にユーザを追加したりデータセットを作成したりすることになる。
で、マルチテナント運用にする場合は default namespace 以外の名前空間、すなわち「カスタム名前空間」をつくってそれぞれに各テナントを割り振る。ので、namespace がある・ないというよりは、 custom namespace を使う・使わないという切り分けになっていて、 AWS のドキュメントも「カスタム名前空間の場合は〜〜」みたいな書き方になる。
埋め込み QuickSight
... の話をする前に、QuickSight の「ふつうの使い方」について話すと、QuickSight は
- AWS management console とはユーザーの管理がまったく別
- 独自のログインページがある (management console から飛ぶこと「も」できる)
というちょっと特殊なサービスになっていて、つまり AWS を普段触らない営業さんも management console を経由せず QuickSight を使ってもらうことができる (理論上は)。
https://aws.amazon.com/jp/blogs/big-data/an-updated-amazon-quicksight-sign-in-experience/
1 に関しては、QuickSight は QuickSight でこういう↓ユーザリストがあって、IAM User の有無にかかわらず QuickSight を使う人の email はここに登録する。
https://docs.aws.amazon.com/ja_jp/quicksight/latest/user/managing-users.html
2 については、 IAM User がある場合はこういうふうに management console から飛ぶこともできるが、そうでない場合は QuickSight 独自のログインページを案内できる。
埋め込み QuickSight では、この QuickSight の URL に案内せず、自分のアプリケーションの中に QuickSight のダッシュボードやコンソール*を iframe で埋め込む。埋め込み用の SDK があるので、これを使うとそこそこ簡単に埋め込みができる。
*ダッシュボードが閲覧のみなのに対し、コンソールというのは dataset を追加したり、 visual/analysis/dataset を作れる QuickSight のフル機能を備えた UI で、つまり 埋め込みでない QuickSight にアクセスしたときと同じもの。
QuickSight は AWS アカウントに1つ
セクションタイトルの通りだけど、 AWS アカウントに1つしか QuickSight のインスタンス? を立てられない。ほとんどないけど、たとえば「ユーザにどのように QuickSight への認証させるか」という設定は QuickSight 作成時にしか設定できないので注意かも。
https://community.amazonquicksight.com/t/integrating-aws-managed-microsoft-ad-with-quicksight/1230
QuickSight の詳細
RLS
QuickSight のデータセットには RLS (row-level security) を設定できて、どういう user や group がどういう条件の行にアクセスできるかを指定できる。ドキュメントはここ。
具体的には、こういう↓形式の CSV やクエリを書いて RLS を各 dataset に対して設定する。
この表は「Group ごとにアクセスできる Region と Segment を制御しますよ」という RLS で、1行目は「EMEA-Sales」グループは Region = EMEA, Segment = Enterprise,SMB,Startup のいずれかを満たす行を閲覧できるというルールを表している。
で、この query / CSV から RLS を表す dataset を作成して、それをデータの入った dataset に設定する。たとえば、 CLI の aws quicksight create-data-set だと、 --row-level-permission-data-set オプションに↓のように値を渡す。
{ "Arn": "arn:aws ...", "PermissionPolicy": "GRANT_ACCESS", "FormatVersion": "VERSION_2", "Status": "ENABLED" }
create-data-set — AWS CLI 2.15.39 Command Reference
注意点としては string に対してしか RLS を設定できないので、数値の ID 列とかだと hash したりする必要がある。
custom namespaces / カスタム名前空間 だと、 UI でリソースが管理できない
default namespace (= 新しい名前空間を作らなかった場合) は Manage QuickSight の画面から user, group, dataset を確認したり追加したりできる。
一方、custom namespace の場合、この画面には現れないので、CLI を叩いたり別途管理画面を作ったりする必要がある。BI アプリケーションを作るときにここに気づかないと、あとから慌てて管理画面をつくる工数を捻出したり、最初はエンジニアに依頼して CLI を叩いてもらう... というようなことが必要になる
QuickSight user の password-based login について
custom namespace の limitations のところに "Password-based logins" はできないよ、と書いてあって、これがなんのことかよくわからなかった。
https://docs.aws.amazon.com/quicksight/latest/user/namespaces.html
結論、↓の画面を経由する = "password-based login" ということらしい (SA さんに確認)。
custom namespaces と user の IdentityType
同じく custom namespaces の limitations のところには
Custom namespaces—those that are not the default namespace—are only accessible to IAM Federated Single-Sign On users.
と書いてあるのだが、別の workshop には
Federated users, IAM users and QuickSight managed users can all be created in secondary namespaces. However, only Federated and IAM users in secondary namespace will be able to access QuickSight console directly. You can user QuickSight managed users with secondary namespaces if your use case requires only embedded access.
https://catalog.workshops.aws/quicksight/en-US/admin-workshop/5-multitenancy
ということで、埋め込み QuickSight なら QuickSight-managed users でもいけそう?
このやり方は試してないけど、今回は IdentityType = IAM にした。もし IdentityType = QUICKSIGHT にした場合、
- QuickSight-managed users にする
- = ユーザ自身に QuickSight ユーザを作成する権限を与えられない (IAM ロールと紐づかないから)
- = 自己プロビジョニングできない
- 管理者が QuickSight にアカウントをつくる必要がある (ユーザ自身で sign up できない)
という予感がするので注意かも
Athena データソースの注意
Athena データソース・マルチテナント・AUTHOR 権限の組み合わせでの注意点で、S3 にあるファイルから Athena でテーブルや view をつくる場合、ユーザに dataset にする Athena view に権限をつける必要がまずある。しかし、これだけだと元の S3 ファイルに権限がないのでエラーになるので、結局大元の S3 ファイルや途中の view にも権限をつけることになる。
ここで、ユーザに AUTHOR 権限 = dataset を作成する権限を与えた場合、RLS を仮に dataset に付与していたとしても元の Athena view や S3 あら新たな dataset を作成できてしまうのでまずい。回避方法としては、 S3 → Athena で dataset となる view を作ったあと、もう一度 Athena → S3 にエクスポートして、 S3 data source に RLS かけてみたけど、結局 RedShift とか使った方がよかったのかなと思ったり...
Cognito を使う場合の Cognito User と QuickSight User の紐づけ
Amazon QuickSight におけるシングルサインオンの設計と実装 の資料だと、↓のような埋め込みアプリケーションの設計が紹介されている。
言葉にすると、
- ユーザは Cognito でアプリケーションにログインする
- アプリケーションはバックエンドで QuickSight の
generate-embed-url-for-registered-userを叩いて、クライアントにその URL を返す - クライアントは URL を使って埋め込みを描画する
という流れになる。このとき、 step 2 では Cognito のユーザと QuickSight ユーザを紐づけてどの "registered user" に対する URL かを判定しないといけない。
ここがいまいちわかりにくいのだけど、結論としてはユーザの email などを key にして Cognito user の email → QuickSight user の username をつくることになる。
たとえば、foo@example.com というユーザに利用してもらいたい場合、
- Cognito に
email: foo@example.comとなるユーザを登録する - 同時に QuickSight にも
email: foo@example.comでユーザを登録する
と2つのユーザを登録する必要がある。 generate-embed-... ではパラメータに UserARN が必要なので、バックエンド側のロジックとしては
- Cognito の id token を受け取る
- id token から email を取得
- QuickSight の DescribeUser API で UserName から UserARN を取得する
- UserARN を GenerateEmbedUrlForRegisteredUser に渡して URL を取得
のようになる。
なお、 QuickSight User の identity type が IAM の場合、
RegisterUserの引数に IAM Role を渡す必要があり、UserNameは/ (e.g. quicksight-user/foo@example.com)
となる。(role session name がいまいち何なのかよくわかってないけど Cognito だと email になった)
... というのは Amazon QuickSight におけるシングルサインオンの設計と実装 の p.26 あたりにある
