こんにちは、洲崎です。
2024/5/31にAmazon ConnectでゼロETLを利用した分析ができるようになりました。
ゼロETLとは
ゼロETLとは、「ゼロ」という名前がついているように、ETLを実行する際の複雑なデータパイプラインの構築を行わず（あるいは少なく）分析を行うことができることを指します。
ETLとはExtract（抽出）、Transform（変換）、Load（書き込み）というデータを分析などに扱いやすくするために加工するプロセスのことを指します。
Amazon Connectのデータ分析については、今まではCTRなどのイベントデータをS3に保存し、Glueなどでテーブルを作成しつつAthenaなどでクエリをかけて分析することが主流でした。
構成例：[Amazon Connect]録音データの検索やS3を参照するQuickSight ダッシュボードを作ってみた
それが上記の構成例であげている「Amazon Data Firehose」や、「Glue Crawler」なしでも、Amazon Connectのデータを元にQuickSightやAthena等で分析することができるようになりました。
分析できるデータの保持期間や対象は以下です。（参考：Data retention）
- データ保持期間：25か月間
- データレイク起動時に、以下の期間を対象としてインスタンスからデータを含める
- 以下のデータは2022年10月以降のデータから分析可能
- Contacts Record
- Contact Statistic Record
- Agent Queue Statistic Record
- Agent Statistic Record
- 以下のデータは2023年7月以降のデータから分析可能
- Contact Lens 会話分析データ
- 以下のデータは2023年2月以降のデータから分析可能
- Contact Lens 評価レコード
- 以下のデータは2024年5月以降のデータから分析可能
- コンタクト フロー イベント
ものは試しで、早速やってみます。
やってみる
Amazon Connectインスタンスからデータレイクの作成
Amazon Connectコンソールでインスタンスを選択し、サイドメニューのApplicationsの中にある「分析ツール」を開きます。
データレイクのところで、「データ共有の追加」をクリックします。
「Target AWS account ID」には対象のAmazon ConnectインスタンスがあるAWSアカウントIDを入力します。（データ共有を行うAWSアカウントIDと同一でも問題ないです）
データ型は「Contacts Record」と「Contact Statistic Record」を指定します。
（各データ型の詳細は、以下のドキュメントをご確認ください）
「確認」をクリックします。
これで、Amazon Connect側でのデータレイクの設定は完了です。
Resource Access Manager リソース承認
Resoruce Access Managerのコンソール画面を開きます。
Resource Access Managerに、先ほど指定したデータタイプごとにリソース共有がきているので、クリックして開きます。
右上にある「リソース共有を承認」をクリックします。（データタイプごとにそれぞれ承認します）
Lake Formation データベースの作成
Lake Formationのコンソール画面を開き、「Databases」から「Create database」をクリックします。
以下の形で入力します。
- Table details
- Resource Link
- Resource Link Name
- Database
- GlueにあるDatabase（特に指定がない場合は「Default」）
- Shared table's region
- Asia Pacific(Tokyo)
- Shared table
- 共有を承認したリソースをプルダウンで選択
テーブルが作成されたことを確認します。
テーブルが作成されると、Athenaでクエリをかけることができます。
試しに以下のSQLでクエリを実行してみます。
SELECT * FROM "default"."connect_data" limit 10;問題なくクエリを実行することができました。
QuickSightユーザーのアクセス許可
Lake Formationで作成したテーブルにQuickSightで分析するには、QuickSightユーザーのアクセス許可の設定が必要です。
権限については、「ユーザーがリソースリンクに対する権限」と、「基盤となるリソースデータの読み取りアクセスをもつ権限」の2つが必要になります。
Lake Formationで作成したテーブル（connect_data）を開き、「Actions」から「Grant」を選択します。
以下の形で入力します。
- Principals
- QuickSightユーザーのARN
- ※AWS CLIで以下のコマンドを叩くことでARN情報の取得が可能です
aws quicksight list-users --aws-account-id [Accound_id] --namespace default
- LF-Tags or catalog resources
- Named Data Catalog resources
- Databases
- Glueの指定したデータベース
- Tables
- connect_data(作成したテーブル）
- Resource link permissions
- Describe
Data Lake permissionsのところに2つ（「IAM role」、「QS User」）の権限が新たに作成されます。
この段階で、QuickSightのユーザーは、Lake Formationのテーブルが存在することを確認できますが、データへのアクセスまでの権限はないため、追加で権限を作成します。
同じような手順で、Lake Formationの対象のテーブルを開き、「Action」から「Grant on target」を指定します。
入力する情報は「Grant」の時とほぼ変わらずです。「Table permissions」のところは「Select」のみ許可する形にします。
これで、Lake Formation周りの権限設定は完了です。
QuickSightで可視化のテスト
QuickSightのAWSのサービスへのアクセスで、あらかじめAmazon S3とAmazon Athenaを許可しておきます。
データセットの画面から、「新しいデータセット」をクリックします。
任意のデータソース名をいれて、データソースの作成に進みます。
テーブルの作成で、先ほど作成したLake Formationのテーブル（connect_data)を指定します。
このまま「Visualize」します。
すでに様々なフィールドが入っている状態で、分析レポートを作成することができました！
以下は「initiation_timestamp（通話開始のタイムスタンプ）の数を日付順で表したレポート」と、「Agent_username（エージェント名）ごとに対応したレコードの数」をグラフで出してみました。
最後に
Amazon ConnectのゼロETLについて、QuickSightで分析するところまで試してみました。
FirehoseやGlueでパーティショニングなどのETL処理をせずに、分析基盤まで整えることができました。
個人的にはLake Formationは初めて触ったので新鮮でした。
FirehoseやGlueではパーティションやテーブル定義など細かく決めることはできますが、そういった要件がない場合はゼロETLのパターンもぜひ試してみてください。
ではまた！コンサルティング部の洲崎でした。
11
