Amazon Web Services ブログ

Amazon QuickSight でダッシュボードのパフォーマンスを向上させるためのヒントとコツ

この記事は “ Tips and tricks for high-performant dashboards in Amazon QuickSight ” を翻訳したものです。

Amazon QuickSight はクラウドネイティブのビジネスインテリジェンス ( BI ) サービスです。QuickSight はダッシュボードをすばやく読み込むためにクエリの実行を自動的に最適化しますが、このブログで紹介するヒントとコツお試しいただくことでダッシュボードの読み込みをさらに高速化し、最高のパフォーマンスを発揮させることができます。

QuickSight ダッシュボードロード時のデータと実行のフロー

QuickSight のデータフローはクライアントのブラウザからウェブサーバに始まり、QuickSight エンジンへ流れ、高速なインメモリデータベースである SPICE ( Super-fast, Parallel, In-memory Calculation Engine ) あるいは直接データベースに対してクエリを実行します。SPICE はカラムナストレージ、最新のハードウェアイノベーションによるインメモリ技術、自動コード生成を組み合わせて使用しており、大規模データに対してインタラクティブなクエリを実行し、迅速な応答を得ることができます。

Web サーバー、QuickSight エンジン、SPICE は、QuickSight によって自動的にスケーリングされます。QuickSight はフルマネージドサービスであり、SPICE 上の特定のダッシュボードを数十から数千のユーザにスケールアップしたい場合でもインフラのプロビジョニングや管理について考慮する必要はありません。データソースに対して直接クエリするように構築されたダッシュボードでは、ユーザー側でインフラのプロビジョニングや管理が必要になる場合があります。

次の図は QuickSight におけるデータの流れを示しています。

QuickSight の仕組みを理解するために、一般的な実行プロセスを見てみましょう。

  • ブラウザでリクエストが発生すると、JavaScript やフォント、画像などの静的アセットがダウンロードされます。
  • ダッシュボードのすべてのメタデータ ( ビジュアル設定やレイアウトなど ) が取得されます。
  • 行レベルおよび列レベルのセキュリティの設定、動的なコントロールの値、デフォルトのパラメータ、フィルターコントロールのドロップダウンの全値を取得するクエリが実行されます。
  • ビジュアルをレンダリングするためのクエリは同時実行数の上限に達するまで特定の順序で実行されます ( この記事の後半で説明します ) 。SPICE を使用している場合、クエリの同時実行数はより高くなります。ビジュアル内のページネーションにより、クエリが追加される場合があります。

実際の実行プロセスはより複雑で、ダッシュボードの構成やデータソースの種類、直接クエリする場合と SPICE を利用する場合、フィールドのカーディナリティ、データの更新頻度などの要因に影響を受けます。多くの操作は並行して実行され、次のスクリーンショットに示すようにビジュアル関連のクエリはすべて WebSocket を介して実行されます。多くのステップはエンドユーザーのブラウザで実行されるため、ブラウザにプッシュできるシーケンスやワークロードの数などには制限があります。また、ブラウザごとに処理の実装が異なるため、ブラウザの種類によってパフォーマンスが若干異なる可能性があります。

ここからはダッシュボードのパフォーマンスを向上させるための便利な Tips をご紹介します。

SPICE

SPICE を使うことにより結果がキャッシュされ、スケーリングも管理されるため、全体のパフォーマンスを向上させるための最適な方法となります。可能な限り SPICEを使用することをお勧めします。

メタデータ

前述の実行の順番から分かるように、QuickSight は最初の読み込み時に指定されたダッシュボードのメタデータを前もってフェッチします。メタデータに関しては、以下の対応を推奨します。

未使用のデータセットを分析から除外する

ダッシュボード上のビジュアルでもう使用されていないデータセットは、不必要にメタデータのペイロードを増やします。このようなデータセットは、ダッシュボードのパフォーマンスに影響を与える可能性があります。

行レベルおよび列レベルのセキュリティが最適化されていることを確認する

行レベルのセキュリティ、列レベルのセキュリティ、動的なデフォルトのパラメータはそれぞれ、ビジュアル生成のクエリを発行する前に参照を行う必要があります。可能であれば、データセットルールの数と複雑さを制限し、これらの参照をより速く実行できるようにします。データセットルールには可能な限り SPICE を使用してください。直接クエリする必要がある場合は、クエリが最適化されていることと、クエリするデータソースが適切にスケーリングされていることを事前に確認しましょう。

ダッシュボードを組み込む場合、行レベルのセキュリティの参照を最適化するには、匿名ユーザーと組み合わせたセッションタグによる行レベルセキュリティを使用するのが最適な方法です。同様に、動的なデフォルトパラメータを使用する場合は、その代わりにホストアプリケーションであらかじめ検証し、QuickSight Embedding SDK を使用して受け渡すことができます。

計算フィールド

ここでは、計算フィールドに関する Tips を提供します。

計算フィールドをデータ準備ステージへ移動する

QuickSight では、データ準備または分析で計算フィールドを追加することができます。SPICE データセットに対して、集計やパラメータを含まない計算を実行させることができるので、できるだけ多くの計算をデータ準備段階で行うことを強く推奨します。計算フィールドの計算をデータセット内で行うことで計算処理の時間を減らし、クエリのパフォーマンスを向上させることができます。計算で集計やパラメータを使用している場合でも、計算の一部をデータ準備中に移動することが可能な場合があります。例えば、以下のような計算式が該当します。

sum() を削除しifelse()のみを残すことで、QuickSight はその計算式を実行 ( 事前計算 ) し、SPICE データセットの実際のフィールドとして保存することが可能です。その後、合計する別の計算を追加するか、またはビジュアルに追加し合計を集計することができます。

一般的には、複雑な ifelse ロジックや文字列の操作や参照を行う計算をさせることで、ダッシュボードのパフォーマンス改善が最大化されます。

簡略化した ifelse 構文の実装

ifelse 関数は簡略化して記述することができます。例えば次のような記述から始めることができます。

以下のように簡略化することで、よりパフォーマンスが高くなります。

toString() 関数を慎重に使う

toString() 関数を使用して数値データを文字列に変換して後続処理を行うと、単純な整数値や数値ベースの算術計算をする場合よりもパフォーマンスが下がり、データベースエンジンにも負荷がかかります。そのため、toString() 関数は慎重に使用するようにしましょう。

システムから NULL 値が返されるタイミングを把握し、NULL 値のカスタマイズを利用する

多くの方は計算フィールドで NULL を正常にに扱う必要があると考えています。しかし多くのケースでは QuickSight 側に NULL のハンドリングに任せることが可能です。この機能を活用することで、計算をよりシンプルにすることができます。次の例では、0 による除算はすでに QuickSight によって扱われています。

上記の関数は、以下のように記述することができます。

ビジュアル上で NULL を静的な文字列で表現する必要がある場合、QuickSight ではビジュアル設定で NULL 値が返されたときにカスタム値を設定することができます。前述の例では、書式設定のオプションでカスタム値 0 を設定することができます。このような処理を計算フィールドから除外することで、クエリのパフォーマンスを大幅に向上させることができます。

シート上でのフィルターとパラメータの比較

パラメータは一見とてもシンプルな構成ですが、特にネストされた関数やコントロールで使用する場合はすぐに複雑になってしまいます。パラメータはその場で評価されるため、すべての依存関係をリアルタイムに処理しなければなりません。各パラメータが本当に必要なのか再確認してください。場合によっては以下の $market の例のように、単純なドロップダウンのコントロールに置き換えることができるかもしれません。

計算フィールドで使用するコントロールパラメータを作成する代わりに、フィルターコントロールのドロップダウンを使用することができる場合があります。

テキストフィールド と ドロップダウン ( またはリスト ) のフィルターコントロールの比較

分析を設計する際、フィルタリングしたいビジュアルにフィルターコントロールを追加することができます。フィールドのデータ型が文字列の場合、フィルターコントロールのタイプにいくつかの選択肢があります。単一または複数の値を選択可能なリストを表示するために値を取得する必要があるドロップダウン ( またはリスト ) よりも、単一または複数のエントリを入力できるテキストボックスを表示するテキストフィールドがより良いパフォーマンスのために推奨されます。

シート上のコントロール

ダッシュボード上部のコントロールパネルはデフォルトでは折りたたまれていますが、設定でダッシュボードの公開時に展開された状態にすることもできます。この設定を有効にすると、QuickSight はビジュアルがロードされる前にコントロールの値をフェッチするコールを優先します。コントロールのいずれかが高いカーディナリティを持っている場合、ダッシュボードのロードのパフォーマンスに影響を与える可能性があります。QuickSight は最後に使用されたコントロールの値を保持するため、閲覧者は最初のステップとしてコントロールを調整する必要がなくなる、ということを考慮して、この設定の必要性を検討しましょう。

ビジュアルタイプ: チャート

このセクションでは、チャートを使用する際のアドバイスを提供します。

データポイントの数がスライスの上限より小さい場合、‘ [その他]カテゴリーを非表示 ’ を使用する

[その他] のカテゴリーにデータが追加される前に、ビジュアルに表示したいデータポイントの数を制限することができます。[その他] のカテゴリには、使用しているビジュアルタイプのスライスの上限 ( 自分で設定したもの、または表示制限に基づくもの ) を超えるすべてのデータの集計が含まれます。ディメンジョンがスライスの上限未満であることが分かっている場合は、このオプションを使用することでダッシュボードのパフォーマンスが向上します。

ビジュアルタイプ: テーブルとピボットテーブル

このセクションでは、テーブルとピボットテーブルを使用する際のアドバイスを提供します。

生データのテーブルビューを表示する場合は 値フィールドを活用する

すべての生データをテーブルに出力したい場合は、グループ化の条件フィールド、値フィールド、あるいはそれらを合わせて使用することができます。最もパフォーマンスが高くなるのはすべてのフィールドを値に設定する方法です。グループ化の条件を使用する場合、まずクエリを実行した後に Group By 関数を実行するため、すべてのデータをデータベースから取得する必要があり、コストがかかります。

使用する行、列、メトリクス、計算を最小限にする

1 つのピボットテーブルに行、列、メトリクス、およびテーブル計算の組み合わせを多く含めると、読み込みが過負荷になるリスクがあります。また、背後にあるデータベースの計算上の制限に直面する可能性もあります。複雑さを軽減してエラーの発生率を下げるには、以下の操作を実行します。

  • フィルタを適用して、ビジュアルに含まれるデータを削減する。
  • 行と列のフィールドウェルで使用するフィールドを少なくする。
  • 値 のフィールドウェルで使用するフィールドをできるだけ少なくする。
  • 追加のピボットテーブルを作成して、各テーブルで表示するメトリクスの数を少なくする。
  • 小計、合計、条件付き書式を可能な限り削減する。

折りたたまれていない列は最もシンプルであり、一部のケースを除いて高いパフォーマンスを維持できる可能性があります。

ビジュアル表示のシークエンス

人の目線の動きは左から右、そして上から下へと進みます。このビジュアル表示のシークエンスを理解することは、コンテクストに沿ってダッシュボードのビジュアルを再配置することにつながります。読み込みに時間がかかるビジュアルをダッシュボードの一番下に配置し、すばやくロードできるKPIやインサイトのビジュアルを画面の上部付近に配置することでスクロールせずに見える範囲を素早く表示でき、ダッシュボードパフォーマンスに対する閲覧者の感覚を向上させることができます。

埋め込み

最後の推奨事項は、埋め込みに関するものです。

ユーザー管理フローをクリティカルパスから除外する

ほとんどの場合、ユーザー管理や認証フロー ( DescribeUser や RegisterUser API など ) はホストアプリケーション上で非同期に実行することができます。
分析ページへのアクセスごとにオーバーヘッドが発生してしまうため、埋め込みを実施する前にあらかじめユーザーを登録しておくことを検討しましょう。
事前にウェブサイト上でユーザーを認証し、 Amazon Cognito または AWS Security Token Service ( Amazon STS ) のセッショントークン ( 必要な場合 ) を事前に取得します ( 例えば、ユーザーのログイン時やホームページの訪問時など ) 。これにより、ユーザーが分析ページにアクセスした際の追加のランタイムオーバーヘッドを削減することができます。

ワークロードをクライアントからウェブサーバーやバックエンドサービスへ移動する

他のアクティビティも実行しているホストアプリケーションのウェブページ上に QuickSight のダッシュボードが埋め込まれている場合、ホスト上の API 呼び出しの順序に細心の注意を払う必要があります。QuickSight のダッシュボードの読み込みがホストアプリケーション上の他の重い API 呼び出しによって制限される可能性があります。ロジックをできるだけウェブサーバやバックエンドのサービスに移動し、ブラウザ上での処理の競合を防ぎましょう。

ユーザーが分析セクションから移動した際、埋め込み iframe を削除しない

ユーザがウェブアプリケーションの非分析ページに一時的に移動した場合 ( 特にシングルページアプリケーション ) 、埋め込まれた iframe を DOM から削除せず iframe を DOM 要素に残したまま、ユーザから非表示にすることができます。これにより、ユーザーがアプリケーションの分析セクションに戻ったときに同じセッションを再開することができ、ユーザーは再読み込みを待つ必要がありません。

navigateToDashboard() および navigateToSheet() を可能な限り使用する

同時にロードする必要がない複数のダッシュボードがホストアプリケーション上に存在する場合、AWS の JavaScript SDK で公開している 2 つの API、navigateToDashboard() または navigateToSheet() を利用することで、認証フローを最適化することができます。これらの API は、認証トークンを再利用しながら各読み込みに同じ iframe を再利用します。
この手法は、埋め込み機能を利用している多くのユーザーにとって非常に有効であることが証明されています。
これらの API の詳細については、 Amazon QuickSight Embedding SDK を参照してください。

まとめ

今回は、QuickSight ダッシュボードのパフォーマンスをチューニングするためのヒントとコツをご紹介しました。2021 年に AWS は、SPICE データの上限をデータセットあたり 5 億行に倍増しました。また、Amazon Redshift、Amazon Athena、Amazon RDS、Amazon Aurora、PostgreSQL、MySQL、Oracle、SQL Server、MariaDB、Presto、Teradata、Snowflake などの SQL ベースのデータソースにおいて、最大 15 分ごとに増分データ更新が可能になり、データ更新間の時間を 75 %削減することが可能になりました。2022 年も QuickSight のダッシュボードのパフォーマンスをさらに向上できるよう、お客様のために革新を続けています。
これらの Tips によってダッシュボードの読み込みがどのように改善されたかに関するフィードバックをお待ちしています。

著者について

この記事は、Shekhar Kopuri, Blake Carroll, Vijay Chaudhari, Wakana Vilquin-Sakashita によって投稿された記事を翻訳したものです。

翻訳は Solutions Architect 原田 江海咲 が担当しました。原文はこちらです。