Amazon Redshift Serverless と Tableau の統合を最適化する

本記事は 2026 年 6 月 29 日に公開された「Optimize your Tableau integration with Amazon Redshift Serverless」を翻訳したものです。

本記事は、Tableau at Salesforce の Adiascar Cisneros との共著によるゲスト投稿です。

Tableau と Amazon Redshift Serverless を統合すると、サーバーレスのスケーリングと最小限のキャパシティプランニングで高性能なアナリティクスを実現できます。自動スケーリングによりウェアハウス管理は自動化されますが、最適化にはデータモデリング、セキュリティ、クエリ管理への戦略的なアプローチが必要です。

本記事では、Tableau の Relationships と Amazon Redshift Serverless アーキテクチャを活用し、すべての Redshift Processing Unit (RPU) を最大限に活かしながらサブ秒レベルのインサイトを提供する方法を解説します。具体的には、次の 5 つの領域を取り上げます。クエリパフォーマンスに最適なデータモデル設計、セキュリティ構成とアクセス制御、スマートな構成によるパフォーマンス最適化、コスト管理戦略、クエリと結合の最適化手法です。

前提条件

最適化戦略を実装する前に、以下を準備してください。

Tableau Desktop (バージョン 2022.1 以降) または Tableau Server がデプロイ済みであること。
アクティブな Amazon Redshift Serverless ワークスペースがあること。
認証とアクセス制御を構成するための AWS Identity and Access Management (IAM) 権限があること。
Tableau 環境と Amazon Redshift Serverless 間のネットワーク接続が構成済みであること。
ネイティブ Amazon Redshift ドライバーがインストール済みであること。

基盤の構築

アナリティクスシステムの成功はデータモデルから始まります。スケーラビリティの鍵はエンドユーザー体験にあります。データモデルは単なるストレージ構造ではなく、ダッシュボードの応答性の基盤です。Amazon Redshift のデータベース設計を分析要件に合わせることで、Tableau が効率的なクエリを生成できるようになり、コスト削減とユーザーのデータへのエンゲージメント向上を実現できます。

Amazon Redshift に接続する際は、Tableau の論理データモデル、具体的には Relationships の使用をお勧めします。Relationships を使用すると、各テーブルのネイティブな詳細レベルが保持されるため、Tableau は結合カリング (join culling) を実行し、特定のビジュアライゼーションに必要なテーブルのみを動的にクエリできます。

Amazon Redshift スキーマを設計する際は、適切な場合にはスタースキーマ、スノーフレークスキーマ、または 1 つの大きな非正規化テーブルを実装します。これにより、Tableau がクエリ実行を自動的に最適化できるようになります。最新の Amazon Redshift デプロイメントでは、Automatic Table Optimization (ATO) が大きなメリットをもたらします。ATO は AI と機械学習 (ML) を使用してソートキーとディストリビューションキーを継続的に監視・調整します。ATO を活用するには、テーブル作成時にソートキーとディストリビューションスタイルをデフォルトの AUTO 設定のままにします。ATO がワークロードパターンを継続的に監視し、クエリパフォーマンスを向上させるためにキーを調整します。

まず既存のワークブックに Relationships を実装して、結合カリング (join culling) とクエリパフォーマンスの向上を活用しましょう。

接続のセキュリティ保護

ネイティブデータベースドライバーは、汎用の ODBC や JDBC に比べて、セキュリティ機能が強化され、Amazon Redshift の機能とより良く統合されます。

アナリティクスの信頼性は、プラットフォーム間の接続品質に依存します。汎用の ODBC や JDBC ではなく、ネイティブ Amazon Redshift ドライバーを使用してください。ネイティブドライバーは Amazon Redshift の高度な機能を活用するよう設計されており、AWS IAM Identity Center などの最新のセキュリティプロトコルをすぐに使用できます。ネイティブドライバーを使用すれば、最新のセキュリティパッチとパフォーマンス最適化が適用された安全で効率的な接続を確立できます。詳細については、「Integrate Tableau and Okta with Amazon Redshift using AWS IAM Identity Center」を参照してください。

大規模環境での接続安定性

Amazon Redshift のカーソルは、結果セット全体を一度にメモリにロードせず、行単位または小さなチャンクでデータを取得する仕組みです。大規模環境では、大きな結果セットの処理方法が接続の安定性に影響します。一部の高ボリュームシナリオでは、Amazon Redshift のカーソルがリソース負荷を発生させ、ユーザーの同時実行性に影響を与えることがあります。ワークロードを監視し、必要に応じて Tableau Data Customization (TDC) ファイルを使用して接続構成を微調整します。TDC ファイルは、Tableau がデータベースに接続する方法をカスタマイズする XML 構成ファイルです。具体的には、カーソルを無効にすることでスループットが改善されるかどうかを検証してください。

重要: この構成ではデータセット全体がメモリにロードされます。大規模なデータセットの場合、パフォーマンスの低下やメモリ不足エラーが発生する可能性があります。この設定を有効にする前に、データセットのサイズとビジネス要件を評価してください。デプロイメントのチューニングにおける重要なステップであり、Amazon Redshift のリソースがアドホック分析に対して十分な応答性を維持できるかの確認に役立ちます。

セキュリティのベストプラクティス

Amazon Redshift Serverless のデプロイ時はセキュリティのベストプラクティスに従ってください。Tableau Server および Desktop の IP 範囲からのインバウンドアクセスを制御するセキュリティグループを構成します。IAM 認証を主要な方法とし、すべての接続に SSL/TLS 暗号化を組み合わせます。

ロールベースのアクセス制御 (RBAC) がセキュリティフレームワークの基盤となります。

IAM ロールをデータベースユーザーにマッピングする。
データベースセキュリティコントロールを使用して Amazon Redshift で最小権限アクセスを実装する。
監査ログで全体を監視する。
ログイン失敗の試行には Amazon CloudWatch を使用する。
AWS CloudTrail で API アクティビティを追跡する。

認可については、多層セキュリティモデルを実装します。

明示的な GRANT ステートメントを適用する。
ビジネス機能に合わせた個別のデータベースロールを作成する。
Amazon Redshift のシステム定義ロールを慎重に使用する。
機密データにはダイナミックデータマスキングを適用する。
継続的な保護を維持するため、定期的にセキュリティ監査を実施する。

現在の接続タイプを監査し、ODBC や JDBC 接続を使用している場合はネイティブ Amazon Redshift ドライバーに移行してください。

スマートな構成によるパフォーマンスの向上

スマートな構成は、クエリするデータ量、複雑なロジックの処理先、ダッシュボードの設計方法、接続のチューニング方法にわたります。以下のセクションで各領域を取り上げます。

データ量の管理

ワークブックの効率を最大化するには、まずデータ量を厳格に管理します。Amazon Redshift は大規模なデータセットを適切に処理できますが、ダッシュボードでは厳密に必要なデータのみをクエリすべきです。本番環境では Tableau Hyper Extracts を使用して、反復的なクエリ処理を Amazon Redshift からオフロードする一貫した高速キャッシュを提供します。ライブ接続が必要な場合は、Data Source Filters を使用し、未使用のフィールドをすべて非表示にして、データ取り込みを厳密に制限します。Tableau がより軽量なクエリを生成するようになり、ネットワークレイテンシーと処理時間を大幅に削減できます。

複雑な処理のデータベースへの移行

次に、複雑な処理の負担をビジュアライゼーション層から移します。エクストラクト内で計算をマテリアライズするか、複雑なロジック (特に行レベルの文字列操作や正規表現) を Amazon Redshift データベースレベルに直接プッシュダウンします。ユーザーがダッシュボードを読み込む前に値を事前計算しておくことで、実行時の高コストな処理を排除できます。

Tableau 内のロジックは、複雑な IF/THEN ステートメントの代わりに CASE ステートメントや Sets などのネイティブ機能を使用してシンプルにします。テストでは、ディメンションのグループ化に対してこれらの方法が大幅に高速であることが示されています。

ダッシュボード設計の効率化

さらに、ダッシュボード設計を効率化してレンダリングプロセスを最適化します。

ダッシュボードあたりのビジュアライゼーション数を制限する。
サーバー側キャッシュの効果を最大化するため、固定サイズのダッシュボードを優先する。
高カーディナリティフィルター (数千の一意の値を持つフィールド) を避ける。
大規模なデータセットでは「関連値のみ表示 (Show Only Relevant Values)」設定を使用しない。ダッシュボードを遅くする余計なバックグラウンドクエリが実行されるためです。

接続とパラメータのチューニング

同時接続ユーザー数に合わせた接続プーリングを有効にして Tableau のパフォーマンスを最適化します。日時処理と並列クエリ実行の設定をワークロードパターンに合わせて構成します。

パラメータの最適化により、Amazon Redshift Serverless の自動リソース管理を強化できます。主要なパラメータは以下のとおりです。

開発中は enable_result_cache_for_session を OFF に設定し、キャッシュではなくライブクエリのパフォーマンスをテストできるようにします。本番では ON に設定します。
スパイクのあるワークロードには AI スケーリングを使用する。
キューベースのクエリリソース管理を使用して、コンピューティング使用量を制御し、暴走クエリの影響を防止する監視ルールを設定する。

エクストラクトとライブクエリの選択は、基本的なアーキテクチャ上の決定です。一律のポリシーではなく、特定のユースケースに合わせたハイブリッドアプローチをお勧めします。

ライブクエリを使用する場合

ライブクエリはリアルタイムアナリティクスに最適です。Amazon Redshift Serverless の自動スケーリングを活用して、大規模なデータセットをその場でクエリします。次のような場合に使用します。

最新のデータが必要な場合。
エクストラクトには大きすぎるデータセット。
データベースレベルの行セキュリティが必要なシナリオ。
Amazon Simple Storage Service (Amazon S3) データに対する Amazon Redshift Spectrum との統合。

ライブ接続はデータベースのパフォーマンスに完全に依存するため、インタラクティブ性を維持するには Amazon Redshift テーブルの最適化とデータベース内でのマテリアライゼーション手法の使用が重要です。

エクストラクトを使用する場合

データが静的な場合やクエリパフォーマンスが重要な場合、Tableau Hyper Extracts は処理負荷を Amazon Redshift から Tableau のデータエンジンに移行する高速キャッシュを提供します。これは、複雑な計算 (行レベルの文字列操作や重い集約など) を含むダッシュボードに有効で、エクストラクトが結果を事前にマテリアライズし、ユーザーがビューを読み込む前にロジックを組み込むことができます。これらの重い処理にエクストラクトを使用することで、Amazon Redshift のコンピューティング負荷を減らし、コストを削減しながらエンドユーザーにサブ秒の応答時間を提供できます。

エクストラクトの適正なサイズ設定

効率を最大化するために、ダッシュボードの特定のニーズに合わせてエクストラクトを適正なサイズに設定します。

SELECT * の考え方を避ける。
データソースにフィルターを使用して行を制限する。
未使用のフィールドを非表示にして冗長な列を削除する。
より高いレベルの分析には、エクストラクトプロセス中にデータを集約する。たとえば、日次トランザクションを月次トレンドに要約すると、ファイルサイズとクエリ時間を大幅に削減できます。
オフピーク時間にリフレッシュをスケジュールする。
インクリメンタル更新を使用して新しい行のみを追加し、Amazon Redshift の RPU 使用量とネットワーク負荷を最小化する。

パフォーマンスとコストのバランスを取るため、ビジネスのデータ鮮度要件とデータの複雑性に合わせて接続方法を選択します。使用パターンを監視し、時間の経過とともにバランスを調整してください。

スタースキーマのクエリと結合の最適化

Tableau Relationships を使用して、スタースキーマの結合とクエリを最適化し、実行時間とコンピューティングコストを削減します。Relationships はテーブルを分離したまま保持し、ビュー内のフィールドに必要なテーブルのみを Tableau が自動的にクエリできるようにします。Relationships は結合よりも柔軟で、すべてのフィールドに対して行レベルのマージを強制しないため、多くの場合パフォーマンスが向上します。

非効率な結合と最適化されていないクエリは、Amazon Redshift に不要なデータのスキャンを強制し、クエリ実行時間とコンピューティングコストの両方を増加させます。

クエリ最適化のベストプラクティス

Tableau にクエリを複雑なサブセレクトでラップさせるカスタム SQL を避けてください。代わりに、テーブルやビューに直接接続して、データベースオプティマイザーが効果的に機能するようにします。

Amazon Redshift スキーマで主キーと外部キーを定義し、Tableau が参照整合性を仮定できるようにします。

重要: Amazon Redshift は主キーや外部キーの制約を強制しません。これらは情報提供のみであり、クエリオプティマイザーがより効率的な実行プランを生成するために使用します。データの整合性はアプリケーション層または ETL 層で管理する必要があります。詳細については、「テーブルの制約」を参照してください。Assume Referential Integrity は、定義されたキーリレーションシップをクエリ時に検証せずに信頼するよう Tableau に指示する設定で、クエリの複雑さを軽減します。

マテリアライズドビューを使用して重い集約を事前計算し、頻繁にアクセスされるデータパターンの実行時間を短縮します。たとえば、一般的な日付ベースの集約やカスタマーレベルのサマリー用にマテリアライズドビューを作成します。

複雑な結合を最小化するためにデータを非正規化して Amazon Redshift Serverless を最適化します。変更を適用した後、Tableau のパフォーマンス記録を使用してクエリ速度を定期的に検証し、ボトルネックを特定してください。

コストの最適化とモニタリング

Amazon Redshift Serverless は RPU 時間を秒単位 (最小 60 秒) で課金するため、実行したワークロードに対してのみ料金が発生します。

クエリ量とリソース使用量を最適化することで、Amazon Redshift Serverless のコストを制御し、予測可能な支出を維持できます。コンピューティングコストの制御には、データソースのフィルターと「未使用フィールドをすべて非表示 (Hide All Unused Fields)」を使用して、Tableau クエリが Amazon Redshift に到達する前に最適化します。必要な行と列のみをスキャンする軽量な SELECT ステートメントが生成されるようになります。Amazon Redshift Serverless はワークロードに基づいてリソースをスケールするため、Tableau ソース層でデータ量と複雑性を削減することで RPU 消費量とコストを低減できます。

詳細については、「Amazon Redshift Serverless の課金」を参照してください。

コストバッファーとしてのエクストラクトの使用

Tableau Hyper Extracts は、高トラフィックのダッシュボードに対するコストバッファーとして機能します。データを Tableau のインメモリエンジンに抽出することで、データベースのコストは通常、個々のユーザーインタラクションごとではなく、スケジュールされたリフレッシュ時に発生します。ライブ接続では、サーバーキャッシュポリシーを「更新頻度を下げる (Refresh less often)」に設定して Tableau のキャッシュアーキテクチャを最大限に活用し、反復的なダッシュボードビューがメモリからすぐに提供され、冗長な課金対象クエリを回避するようにします。

モニタリングとアラート

RPU 使用パターンを監視し、課金アラートを設定してコスト管理を維持します。

クエリ結果のキャッシュとリソース集約型タスクの戦略的なスケジューリングを組み合わせる。
スケーリングイベントデータとクエリパターンを使用してしきい値を定義する。
RPU 消費量のスパイクに対して Amazon CloudWatch アラームを設定する。
最適化の機会を特定するため、Amazon Redshift のクエリモニタリングメトリクスを毎週確認する。

クリーンアップ

継続的な料金の発生を避けるために、本記事で説明した構成のテスト中に作成したリソースを削除してください。

テスト用に作成した Amazon Redshift Serverless のワークグループと名前空間を削除する。
Tableau 接続用に作成した IAM ロール、ポリシー、ユーザーを削除する。
Tableau Server または Desktop の IP アクセス用に構成したセキュリティグループを削除する。
テスト中に作成したマテリアライズドビュー、テーブル、スキーマを削除する。
テストワークグループに接続されたスケジュール済みの Tableau エクストラクトの更新をキャンセルする。
テスト環境を参照する Tableau データソースとワークブックを削除する。
テストリソースのモニタリング用に設定した CloudWatch アラームや CloudTrail の構成を削除する。

Amazon Redshift Serverless リソースの管理の詳細については、「Amazon Redshift Serverless での請求」を参照してください。

まとめ

本記事では、Tableau と Amazon Redshift Serverless の統合に関する主要な最適化戦略を取り上げました。Relationships を使用したデータモデルアーキテクチャ、ネイティブドライバーと AWS IAM によるセキュリティ構成、エクストラクトとスマートな構成によるパフォーマンス最適化、RPU モニタリングによるコスト管理、クエリ最適化手法です。

AI 駆動の最適化が進化する中、Tableau Pulse を含む Amazon Redshift の AI 機能とベストプラクティスの最新情報を把握することが重要です。Tableau と Amazon Redshift Serverless の統合がセキュアでコスト効率が高く、高パフォーマンスを維持するよう、構成、パフォーマンス、セキュリティを定期的に確認してください。

最適化は継続的で反復的なプロセスです。環境を最適な状態に保つために、設定を定期的に確認し、パフォーマンスを監視し、ワークロードパターンの変化に適応してください。組織の成長に合わせてスケールするコスト効率の高いアナリティクス環境を維持できます。

スピードとコスト効率の両方を提供するセキュアで高性能なアナリティクスソリューションを構築する準備はできましたか？ Salesforce と AWS のパートナーシップ Web ページにアクセスして、今すぐインサイトのスケーリングを始めましょう。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

Amazon Web Services ブログ