Inspireのダッシュボード機能実装について
この記事はFinatextグループ10周年記念アドベントカレンダーの23日目の記事です。
昨日は三浦さんが「あなたに届けるため、僕たちは一瞬の刹那を駆け抜ける -生命体と夜空の星について-」という記事を公開しています。
はじめに
Finatext保険事業でデータ周りのエンジニアをしている高橋といいます。
今年の９月に、Finatextから以下のリリースを出しました。
私は、このリリースにあるSaaS型デジタル保険システム「Inspire」のダッシュボード機能の開発を行っています。この機能は、AWSのBIツール「QuickSight」を用いて開発しています。
今回はその実装面についてお話しようと思います。
重要なポイントは次の通りです。
- 埋め込みによるダッシュボード提供
- API GatewayとLambdaを用いたダッシュボード表示
- IaCによるQuickSightアセットの管理
- IAM Identity Centerと事前プロビジョニングによるユーザー管理
順番に説明していきます。
1. 埋め込みによるダッシュボード提供
QuickSightには埋め込みという機能があります。これはダッシュボードの閲覧や分析をアプリケーションやウェブサイト上に実装する機能です。
埋め込み方法は簡単でUIやAPIから埋め込み用のURLを生成するだけです。
ダッシュボード閲覧の場合、下表の通り埋め込み方法としてユーザー認証有りとユーザー認証無しの二種類があります。
ユーザー認証有りだとQuickSight上でのInspireユーザーの登録・管理コストがネックになります。そこで今回はユーザー認証なしの埋め込みを採用しました。
2. API GatewayとLambdaを用いたダッシュボード表示
Inspire上でダッシュボードを提供するにあたり、ユーザー情報をもとに認証・認可を行い適切なダッシュボードを表示する必要があります。この機構はAPI GatewayとLambdaを組み合わせて構築しました。
手順は次のとおりです。
(1). ダッシュボード閲覧のリクエストを送る
Inspireにログインしてダッシュボードのページを開くとFetch APIによるリクエストが送られます。
(2). OPTIONSメソッドによるプリフライトリクエスト
API GatewayではプリフライトリクエストにLambdaを用いない方法もありますが、今回は少し複雑な処理が必要だったためLamdbaを用いています。
(3). 認証・認可を行うLambdaをキック
プリフライトリクエストが成功すれば後続の認証・認可用のLambdaを実行します。このLambdaは公式でLambdaオーソライザーと名前がついていて、トークンなどの検証および、検証結果を受けての後続処理の制御を行います。
(4). LambdaオーソライザーでJWTの検証を行う
Inspireの認証・認可ではInspire自身が発行したJWTを使っているため、その検証を行います。ここでは予め用意した検証用のエンドポイントを使用します。この検証のコードはLambdaオーソライザーの関数にまとめています。
補足ですが、Lambdaオーソライザーはキャッシュなどの必要最低限の設定のみ変更可能で、メソッドなどは変更できない(見れない)ようになっています。
(5). GETメソッドでLambdaをキック
検証が成功し認証・認可が通れば、ダッシュボードを取得するためのGETメソッドを実行します。ここでも中心となる処理はLambdaが担います。
(6). ダッシュボードの埋め込みURLを取得する
JWTのペイロードに含まれたユーザー情報をもとに、適切なダッシュボードの埋め込みURLを取得します。
(7). ユーザーにダッシュボードを表示する
取得した埋め込みURLはフロントでiframeで読み込みます。これによりユーザーにダッシュボードを表示することができます。
3. IaCによるQuickSightアセットの管理
アセットとはQuickSight上のダッシュボードやデータセットなどのリソースの総称です。
FinatextではGitやTerraformを用いたコード管理を行っています。そのため、アセットの定義をコード化することは効率的な運用を行ううえで重要です。
幸いなことにここ数年、AWS社は新しいAPIを公開することでQuickSightのIaCを推し進めています。
参考: BI トランスフォーメーションを加速する Amazon QuickSight API の新機能
これらのAPIを用いてアセットをコード管理し、効率的なバージョン管理やデプロイを実現することができました。
4. IAM Identity Centerと事前プロビジョニングによるユーザー管理
社内のエンジニアやPM向けにQuickSightへサインインできる環境を構築する必要があります。
以前、AWSサービスで始めるスタートアップ向けデータ分析基盤構築でお話した通り、FinatextではIAM Identity Centerで一元的なユーザー管理を行っており、今回の実装でもそのままです。
IAM Identity CenterのユーザーがQuickSightにサインインするにはQuickSight上でのユーザー作成を行う必要があります。QuickSightユーザーを作成する方法として自己プロビジョニングと事前プロビジョニングの二種類があります。違いは下表の通りです。
事前プロビジョニングはQuickSightユーザーを予め作成するため、権限等の設定を利用開始の事前に行える利点があります。また自己プロビジョニングはユーザーが初回サインインを行うまでQuickSightユーザーが作成されないため、登録漏れなどのリスクがあります。
厳格なユーザー管理を行いため、今回は事前プロビジョニングを採用しました。
最後に
ダッシュボード機能は近日公開予定です。乞うご期待ください。
明日は松崎さんによる「プロポーズプロジェクト」という記事です。お楽しみに！
