Amazon QuickSight で運用を意識して設定＆監視しておきたい項目を挙げてみる
2025.03.30いわさです。
Amazon QuickSight はフルマネージドな BI サービスです。
そのためインフラ自体に関する監視は不要なのですが、実はサービス使用状況やエラーの監視は必要だったりします。
インフラの管理はほぼ不要なのですが、。
今までいくつか QuickSight の導入支援をしていく中で、運用を意識した際にいくつか設定しておいたほうが良い項目や、管理しておいたほうが良いメトリクスがあることに気が付きました。
今回はそのあたりの情報をまとめておきたいと思います。
特に何も設定しない場合のリスク
このサービス使用状況やエラーの監視をしなかった場合にどういう問題が発生する可能性があるのかを先に説明します。
QuickSight は主要なコンポーネントとしてデータセット・分析・ダッシュボードが登場します。（データソースなどもあるが）
データセットはダイレクトクエリと SPICE 更新に 2 つのモードがあります。
ダイレクトクエリモードは QuickSight 内のデータストアにデータを取り込まず、データソース（データベースなど）に対して毎回クエリを発行してデータ取得し、ビジュアル上にデータを表示します。
SPICE モードは QuickSight 内のデータストアにデータを取り込み、そのデータをビジュアル上に表示します。取り込んだ時のデータ内容であるためデータが古くなりやすく、自動更新機能を使ってデータソースから一定間隔でデータを取り込むことが多いです。また、取り込んだデータは SPICE 容量としてカウントされます。
データセットが用意できたらそこから分析を作成し、ダッシュボードとして公開します。
分析には様々なビジュアルを配置し、また集計や変換など様々な処理を組み込むことが出来ます。
データセットの取り込み失敗
データセットの SPICE モードは、様々な要因でデータ取り込みに失敗する場合があります。
SPICE 使用量の上限に達したり、データソースへのアクセスが出来なかったり、などです。
これによって新しいデータが表示されなかったり、エラーによってビジュアル上でエラーが発生する場合があります。
失敗時には問題を解決した上で再取り込みを行う必要があります。
ダッシュボードでビジュアルを表示する際の遅延やエラー
データセットダイレクトクエリや VPC エンドポイントを使っている場合に QuickSight 外のリソースの関係で起きることが多いのですが、ビジュアルが表示されるまでの時間がデータの増加とともに大きくなり、最終的にはタイムアウトエラーが発生する場合があります。
この問題がおきた場合、予兆を検出した場合は、カスタムクエリの最適化を行ったり計算フィールドやビジュアルの見直しを行う必要があります。
場合によっては外部リソースの上限緩和申請が必要になる場合もあります。
対策
QuickSight は CloudWatch メトリクスをサポートしており、主に CloudWatch を使って監視していくことになります。
また、一部 QuickSight 独自の機能を有効化することで自動で対策できるものもあるのでその機能も使います。
SPICE 使用量に対する対策
まず、SPICE については監視が必要な場合と必要ではない場合があります。
QuickSight は SPICE の使用量に応じて料金が発生します。そのため SPICE 使用量にリミットを設定したいかどうかで対策が変わります。
リミットなしで良ければ次の SPICE 自動購入機能をオンにしてください。（新しいアカウントの場合はデフォルトオンになってます）[1]
これを有効化することで SPICE が枯渇した際に自動で必要な分だけ購入してくれるので SPICE 容量不足に依存したデータセット更新失敗は発生しなくなります。
リミットを設定する場合は現在の SPICE の使用量が上限を超えていないかを監視する必要があります。
この SPICE 使用量は CloudWatch メトリクスとして発行されているので、こちらを使って監視が出来ます。[2]
SPICECapacityLimitInMBが上限、SPICECapacityConsumedInMBが現在の使用量です。
私は数式でパーセンテージを出して 80~90 % くらいのアラームを作成することが多いです。
データセット取り込みエラーに関する検知
データセット取り込みエラーは結構起きるのですが、一番設定が簡単なのはデータセット設定画面で「更新が失敗したときに所有者にメールを送信」を有効化しておくことです。
デフォルトがオフなのでデータセットごとに設定が必要なのと所有者へのメール通知のみではあるのですが、特に難しい設定は不要でチェックをオンにするだけです。
送信先のカスタマイズやそれ以上の細かい監視を行いたい場合になると CloudWatch を使います。
QuickSight のメトリクスはリソース個別のメトリクスと集計メトリクスがありまして、前者だとリソース固有の細かい情報を取得できるのですが個別に設定が必要で、後者の場合は共通設定で一括監視ができるのですが集約されてしまいます。リソースが多い場合は後者で良いと思いますが、重要度の違いでノイズになりそうだったり個別設定が手間でなければ前者のほうが良いです。
主にIngestionErrorCountとIngestionLatencyは監視したほうが良いと思います。
IngestionErrorCountは取り込みに失敗した数なので、1件以上であればすぐに通知して良いと思います。
IngestionLatencyは取り込みの開始から完了するまでの秒数です。
SPICE 取り込み自体のタイムアウトはありませんが、データソース側のタイムアウトが発生する場合があります。
よくあるのは Athena のタイムアウトです。Athena の DML クエリはデフォルトタイムアウト値が 30 分で、上限緩和申請で 240 分まで延長できます。[3]
Athena に限らず、いつのまにかデータサイズが増えて運用している中でデータセット更新に失敗するようになることがあるので、IngestionLatencyも監視しましょう。データセット更新失敗の予兆を検出し余裕もって上限緩和申請したりカスタムクエリやインデックスの最適化ができます。[4]
増分更新を使っている場合、通常は増分更新の時間を監視することになると思います。
増分更新は成功するがフル更新だとタイムアウトで失敗してしまう場合もあるので、増分更新以外に一定頻度でフル更新も実施するようにしておくと安心だと思います。
ビジュアル表示エラーに関する検知
最後にビジュアル表示エラーについてです。
運用している中でデータソースの問題などいろいろな要因でダッシュボード表示時にエラーが発生する場合があります。
閲覧者からエラーの報告を受けて対処もできますが、いち早くエラーに対処したいところです。
こちらも CloudWatch になりますが、VisualLoadErrorCountメトリクスを関しすることでビジュアルのロード中に発生したエラー回数をウォッチできます。
1 件以上発生した通知するようにし、通知を受けた際には分析やデータセットのトラブルシューティングをしましょう。
よく私が見るパターンは SPICE データセットを壊してしまった場合（データ型や計算フィールドの内容を変更してしまった、使っていたフィールドを削除してしまった）か、ダイレクトクエリデータセットでのクエリエラーやタイムアウトです。
前者に関しては変更オペレーションに伴う発生がほとんどなのでちゃんとテストしてくださいねという感じで終わりますが、後者に関しては以前はうまく言っていたがいつのまにか失敗するように...というパターンがあります。
この問題を緩和するためにVisualLoadTimeを監視する方法があります。
このメトリクスはクエリの往復時間も含まれるので、この数値が運用をしていく中で徐々に増えていくようであればビジュアルやクエリの見直しが必要です。
ビジュアル生成に 2 分以上かかる場合にタイムアウトエラーが発生する場合があります。
そのため、監視しているダッシュボードのこの数値が 1 ~ 2 分かかるようになった場合は注意が必要です。
この上限は本日時点で緩和できないので、対策としてはビジュアルの最適化や計算フィールドの見直しが必要になります。
さいごに
本日は Amazon QuickSight で運用を意識して設定＆監視しておきたい項目を挙げてみました。
QuickSight の監視運用までしないケースって多いと思います。
いざ監視項目を決めるとなった時にどういった基準を設けるか迷うことがあったので、ナレッジとしてまとめてみました。
