Amazon Web Services ブログ

Amazon QuickSight による更新失敗したデータセットの再取り込み自動化

Amazon QuickSight は、共同作業の場所を問わず、わかりやすいインサイトを提供することができるクラウドネイティブのビジネスインテリジェンス (BI) サービスです。ユーザーはスケジュールされた方法、またはプログラムされた方法で、SPICE (Super-fast, Parallel, In-memory Calculation Engine) にデータをインポートできます。

QuickSight データセットの更新を設定する場合、更新が失敗したときに所有者に電子メールを送信できますが、一時的なエラーが原因で更新が失敗する可能性があるため、ネイティブに再試行する方法はありません。

この投稿では、更新に失敗したデータセットの取り込みを自動的に再試行するために必要なすべてのリソースを AWS CloudFormation を使いデプロイする方法を示します。これにより、更新が正常に完了したかどうか、障害原因に関する詳細情報がデータセット所有者に提供されるため、ユーザーがデータを利用できるようになるまでの時間を短縮できます。

さらに、QuickSight のアセットは、Amazon CloudWatch メトリクスを使用してモニタリングできます。 QuickSight の開発者と管理者は、これらのメトリクスを使用して、QuickSight エコシステムの可用性とパフォーマンスをほぼリアルタイムで観察し、対応することができます。

ソリューションの概要

CloudWatch メトリクスを使用して、QuickSight からほぼリアルタイムのイベントをキャプチャし、失敗したデータセット更新の新しい取り込みを開始する AWS Step Functions ステートマシンを対象とする CloudWatch メトリックアラームと、 Amazon EventBridge ルールを設定します。

次の図は、この投稿のアーキテクチャを示しています。Step Functions ステートマシンと関連する AWS Lambda 関数は、CloudFormation テンプレートを通じてデプロイされます。

Solution Architecture 次のセクションでは、モニタリングしたいデータセット ID を特定し、CloudFormation テンプレートをデプロイ、作成されたリソースを確認、ソリューションをテストし、不要な課金を回避するためにクリーンアップする方法を示します。

前提条件

このチュートリアルを実施するには、以下が必要です:

  • AWS アカウント
  • QuickSight Enterprise Edition のサブスクリプション
  • CloudWatch メトリック、CloudWatch アラーム、EventBridge、QuickSight、Step Functions、Lambda へのアクセス権限を持つ AWS Identity and Access Management (IAM) ロール
  • 使用するサービスと Python の基本的な知識

モニタリングしたいデータセットIDの特定

データセット ID を特定するには、次の手順を実行してください:

  1. QuickSight コンソールのナビゲーションペインで、Datasets を選択します。
  2. モニタリングしたいデータセットを選択します。
  3. ブラウザの URL から、data-sets/ と /view の間の部分をコピーします。次のような URL になります:

https://us-west-2.quicksight.aws.amazon.com/sn/data-sets/4712aba2-6ecc-4521-b009-deb5b276a5f6/view

テストに使用できるデータセットがない場合は、次の手順で Amazon Athena テーブルを作成し、データセットを作成できます。 このテーブルを使用して、SPICE にインポートする QuickSight データセットを作成します。更新の失敗をシミュレートするために、テーブルを削除してデータセットの更新を失敗させます。この失敗により、作成したステートマシンがトリガーされ、更新を自動的に再試行します。

  1. Athena コンソールで、テーブルを作成します。この投稿では、Athena の CTAS を使用して、foo_bar というシンプルなテーブルを作成します。

CTAS for foo_bar table

  1. QuickSight コンソールで、ナビゲーションペインの Datasets を選択します。
  2. New dataset を選択します。

Create dataset

  1. Create dataset より、Athena を選択します。
  2. Data source name に名前を入力し、テーブルの作成に使用した Athena ワークグループを選択します。
  3. Create data source を選択します。

Create data source

  1. Choose your table セクションで、カタログ、データベース、テーブルを指定します。
  2. Edit/Preview を選択します。

Edit/Preview data

  1. Query mode で、SPICE を選択します。
  2. Save & Publish を選択し、Cancel を選択してデータセットビューに戻ります。

Dataset view

  1. このビューから名前を選択してデータセットを開きます。

Refresh タブで、データセットが作成されたときの更新ステータスを確認できます。ここでは Completed と表示されています。

Refresh tab

  1. ブラウザの URL から、先ほど説明したようにデータセット ID を取得します。

リソースのデプロイ

この手順では、障害発生後の自動取り込みを管理するために、Step Functions ステートマシンと Lambda 関数を作成します。次の手順を実行してください:

  1. AWS CloudFormation コンソールを開きます。
  2. コンソール上でテンプレートを開くために、Launch Stack を選択します。

Launch Stack

  1. Next を選択します。

Create Stack

  1. Parameters にある DataSetID へ前の手順で取得した QuickSight データセット ID を入力します。
  2. Next を選択します。

Specify stack details

  1. 次のページで、Next を選択します。
  2. 最終ページで詳細を確認し、I acknowledge that AWS CloudFormation might create IAM resources. を選択します。
  3. Submit を選択します。

スタックの作成が完了するまでには約 2 分かかります。

リソースの確認

リソースを確認するには、次の手順を実行してください:

  1. AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。
  2. 作成したスタックを選択します。スタック名を変更していない場合、automate-failed-ingestion-blogという名前になります。
  3. Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。
  4. Type が AWS::CloudWatch::Alarm の Physical ID を選択して、リソースを新しいタブで開きます。
  5. CloudWatch アラームの詳細を確認します。View EventBridge rule を展開すると、EventBridge ルールの基礎となるパターンが表示されます。
  6. ブラウザで、CloudFormation コンソールが開いているタブに戻ります。
  7. Type が AWS::Events::Rule の Physical ID を選択して、リソースを新しいタブで開きます。
  8. Event pattern タブに、EventBridge ルールで説明されていたイベントと同様のイベントが記載されています。唯一の違いは、state に ALARM を追加したことで、ステータスが OK に変更されたときもターゲットがトリガーされないことです。
  9. ブラウザで、CloudFormation コンソールが開いているタブに戻ります。
  10. Type が AWS::StepFunctions::StateMachine の Physical ID を選択して、リソースを新しいタブで開きます。
  11. Edit を選択して、Step Functions のステートマシン定義を開きます。
  12. Lambda 関数を選択し、View function を選択すると Lambda 関数を開くことができます。

Step Functions のステートマシンロジック

ステートマシンが実行されると、Check Previous Ingestions ステートの最初の Lambda 関数が実行され、前回の取り込みのステータスがチェックされます。 最新のステータスが完了している場合、ステートマシンは COMPLETED のステータスを送信し、Success 状態を経由して終了します。 Lambda 関数による更新失敗が特定の回数 (デフォルトでは 6 回) を超えた場合、TOO_MANY_FAILURES のステータスを送信し、Fail 状態を経由して終了します。リトライ回数は Lambda 関数で設定できます。

State machine logic 1/2

ステータスが COMPLETED でも TOO_MANY_FAILURES でもない場合、ステートマシンは Default の状態を経由して、Start New Ingestion 状態の次の Lambda 関数を実行します。その後、フローは 60 秒間待機した後、Get Ingestion Status 状態の Lambda 関数を実行して取り込みのステータスを確認します。この Lambda 関数がステータス COMPLETED を返した場合、ステートマシンは Success 状態を経由して終了します。ステータスが FAILED の場合は Fail 状態を経由して終了します。それ以外のステータスの場合は、再び 60 秒間待機した後、再確認します。

開始される更新の種類は、最後の更新と同じになります。データセットの編集中にエラーが発生する可能性があり、更新タイプ EDIT でエラーが発生します。自動更新プロセスが失敗していないため、この時点ではコードは取り込みを再試行しません。

State machine logic 2/2

ソリューションのテスト

  1. AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。
  2. 作成したスタックを選択します。スタック名を変更していない場合、automate-failed-ingestion-blogという名前になります。
  3. Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。
  4. Logical ID が DataSourceIngestionFailed の Physical ID で指定されているリンクを選択します。

これにより、モニタリングしているデータセットに関連する CloudWatch アラームが開きます。

Cloudwatch Alarm

  1. データセットのソースを更新できないようにするか、テストのために作成したデータセットを使用している場合は、作成したテーブルを削除してください。

Drop foo_bar

  1. QuickSight データセットから、REFRESH NOW を選択し、Full refresh を選択して、CONTINUE を選択します。

データセットの更新は Failed と表示されます。

Dataset refresh tab

  1. 1 分待って、CloudWatch アラームのステータスをもう一度確認してください。

アラーム状態は In alarm になります。

Cloudwatch Alarm

  1. CloudFormation スタックの Resources タブで、Logical ID が QuickSightRestartIngestionStateMachine の Physical ID に指定されているリンクを選択します。

これにより、リトライロジックを実行する Step Functions ステートマシンが開きます。

  1. Name の下にある ID を選択して、ステートマシンの最新の実行を表示してください。

この実行では、取り込みが再試行されましたが、失敗したため、ステータスが Fail に設定されています。

State machine status graph

  1. メールアラートを有効にするには、QuickSight コンソールに移動し、ナビゲーションペインの Datasetsを選択します。
  2. 機能を有効にするデータセットを選択します。
  3. Refresh タブで、Email owners when a refresh fails を選択します。

Dataset refresh tab Email owners when a refresh fails

このオプションをデータセットで選択した場合、所有者はEメールを通じてすべての失敗の通知を受け取ります。

Email with failed refresh status

クリーンアップ

今後の請求を避けるために、作成したリソースを削除してください:

  1. AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。
  2. 作成したスタックを選択します。スタック名を変更していない場合、automate-failed-ingestion-blogという名前になります。
  3. Delete を選択します。

これにより、スタックによって作成されたすべてのリソースが削除されます。

まとめ

このチュートリアルでは、QuickSight データソースの失敗した更新を自動的に再試行するために必要なすべてのリソースを作成しました。 これらのリソースが相互にどのように関連しているか、そしてこのソリューションがデータを自動的に更新することで QuickSight のユーザーエクスペリエンスを改善し、データセットの更新が失敗したときには、QuickSight オペレーターの手動作業を自動化することで、オペレーターエクスペリエンスを改善する方法を示しました。

詳細は、Amazon QuickSight をご覧ください。QuickSight コミュニティに参加して、他のユーザーと質問したり、答えたり、学んだりすることができます。

翻訳はソリューションアーキテクトの松浦が担当しました。原文はこちらです。

著者について

Andres Castro は、グローバルファイナンシャルサービスのグローバルソリューションアーキテクトです。過去25年間、コンサルティングや金融セクターで DevOps エンジニア、ファイナンスデータソリューションアーキテクト、クラウドエンジニアとして働いていました。ビジネスインテリジェンス、データガバナンス、データアナリティクス、その他すべてのクラウドに情熱を注いでいます。