Amazon Redshift
データベース開発者ガイド (API バージョン 2012年12月1日)

Amazon Redshift の PoC (概念実証) の構築

Amazon Redshift は高速でスケーラブルなデータウェアハウスです。標準 SQL および既存のビジネスインテリジェンスツールを使用して、すべてのデータをシンプルかつコスト効率よく分析できます。Amazon Redshift は他のデータウェアハウスより 10 倍高速なパフォーマンスを提供します。これを実現するために、高度なクエリの最適化、ハイパフォーマンスローカルディスクの列指向ストレージ、機械学習、および大量の並行クエリの実行が使用されます。

以下のセクションでは、Amazon Redshift の PoC (概念実証) を構築するためのフレームワークについて説明します。このフレームワークでは、安全でパフォーマンスが高く、コスト効果が高い Amazon Redshift データウェアハウスを設計、運用するためのアーキテクチャーのベストプラクティスを示します。このガイダンスは、さまざまなビジネスの種類とユースケースにおけるお客様の数千のアーキテクチャ設計を確認して作成されています。データウェアハウスのワークロードを評価するための条件を識別できるように、お客様の体験をまとめてこの一連のベストプラクティスを作成しました。

Amazon Redshift を初めて使用する場合は、「Amazon Redshift の使用開始」を参照することをお勧めします。本ガイドでは、Amazon Redshift を使用してサンプルクラスターを作成し、サンプルデータを操作する方法を実践的に説明します。Amazon Redshift を使用する利点と料金に関する詳細については、マーケティングウェブページの「サービスのハイライト」および「価格情報」を参照してください。

PoC (概念実証) の目標の確認

PoC (概念実証) の目標の確認は、評価プロセスの一部として測定する内容を決定するうえで重要な役割を担います。評価条件には、現在の課題、顧客体験を改善するために行うことを希望する機能強化、現在の業務の課題への対応方法を含めます。次の質問を使用して、PoC (概念実証) の目標を確認できます。

  • 条件を改善したい特定のサービスレベルアグリーメント (SLA) はありますか。

  • Amazon Redshift データウェアハウスをスケーリングする目標は何ですか。

  • お客様またはお客様の顧客がデータウェアハウスに含める必要がある新しいデータセットは何ですか。

  • ベンチマークする必要があるビジネスクリティカルな SQL クエリはどれですか。さまざまなクエリのタイプ (例: 取り込み、更新、削除) など、完全な範囲の SQL の複雑さを確実に含めます。

  • テストする予定のワークロードの全般的な種類は何ですか。この例として、ワークロードの抽出、変換、ロード (ETL)、クエリの報告、バッチ抽出などがあります。

これらの質問に答えると、PoC (概念実証) を構築するための SMART 目標を確立できます。

PoC (概念実証) の設定

Amazon Redshift の PoC (概念実証) 環境は 2 つのステップで設定できます。最初に、AWS リソースを設定します。2 番目に、評価のためにスキーマとデータセットを変換します。

クラスターの設計と設定

次の 2 つのうちいずれかのノードタイプで、クラスターを設定できます。

  • Dense Storage: ハードディスクドライブ (HDD) を使用して、きわめて大規模なデータウェアハウスを低コストで作成できます。

  • Dense Compute: 高パフォーマンスのデータウェアハウスを作成できるように、高速 CPU、大容量 RAM、および SSD (Solid-State Disk) が使用されます。

ワークロードと全体的な予算の目標により、選択するノードの種類が決まります。クラスターのサイズを変更するか、別のタイプのノードに切り替えるのが AWS マネジメントコンソールです。次の追加の考慮事項は、クラスターの設定に役立ちます。

  • 本稼働ワークロードを処理するために十分な大きさのクラスターサイズを選択します。通常、2 つ以上のコンピューティングノード (マルチノードクラスター) が必要です。リーダーノードは追加料金なしで含まれています。

  • Virtual Private Cloud (VPC) でクラスターを作成します。これにより、EC2-Classic インストールより高いパフォーマンスが得られます。

  • 少なくとも 20 パーセントの空き容量、または最大のテーブルで必要とされるよりも 3 倍大きい空き容量を維持するよう計画します。この空き容量は、以下を提供するために必要です。

    • テーブルの使用と書き換えのためのスクラッチ容量

    • バキューム操作とテーブルの再ソートに必要な空き容量

    • 中間クエリ結果の保存に使用する一時テーブル

スキーマの変換とデータセットの設定

AWS Schema Conversion Tool (AWS SCT) または AWS Database Migration Service (AWS DMS) を使用して、スキーマ、コード、データを変換できます。最適なツールの選択は、データのソースによって異なります。

Amazon Redshift のデータの設定には、以下が役立ちます。

クラスター設計に関する考慮事項

クラスターを設計するときは、次の 5 つの属性に留意してください。これを覚えておくための簡単な方法として、SET DW という頭字語があります。

  • S – ソートキーの S です。クエリフィルタでは、ソートキー列に頻繁にアクセスします。ソートキーを選択するには、以下のベストプラクティスに従います。

    • ソートキー列とする列を最大 3 個選択します

    • ソートキーは特異性の度合いに関して昇順で並べ替えますが、使用頻度とのバランスを取ります

    ソートキーの選択の詳細については、「最良のソートキーの選択」および AWS ビッグデータブログの高度なテーブル設計の計画に関する投稿を参照してください。

  • E – エンコーディングの E です。エンコーディングにより、各テーブル内の各列に使用される圧縮アルゴリズムが設定されます。エンコーディングは自分で設定するか、Amazon Redshift で自動的に設定できます。Amazon Redshift での最適な圧縮アルゴリズムの自動的な設定については、「自動圧縮ありでテーブルをロードする」を参照してください。

  • T – テーブルメンテナンスの T です。Amazon Redshift のクエリオプティマイザは、クエリの統計が最新である場合に、より効率的な実行計画を作成します。テーブルからデータをロード、更新、または削除した後で統計を収集するには、ANALYZE コマンドを使用します。同様に、VACUUM コマンドを使用すると、スキャンされるブロックの数を最小限に抑えることができます。VACUUM は次の手順を実行してパフォーマンスを向上させます。

    • ブロックから論理的に削除された行を除外し、スキャン対象のブロックを減らします。

    • ソートキー順にデータを維持し、それによりスキャンで特定のブロックを対象にします。

  • D – テーブルのディストリビューションの D です。テーブルのディストリビューションには、3 つのオプションがあります。

    • KEY – ディストリビューションの列を指定します。

    • EVEN – Amazon Redshift はラウンドロビンパターンでコンピューティングノードを割り当てます。

    • ALL – Amazon Redshift は各コンピューティングノードのデータベーススライスにテーブルの完全なコピーを配置します。

    • 次のガイドラインは、最善のディストリビューションパターンの選択に役立ちます。

      • ユーザーが customer id 値を使用して Customers テーブルを頻繁に結合し、それによりデータベーススライス間で行が均等に分散される場合、ディストリビューションキーに customer id を選択するのが適しています。

      • テーブルが約 5 百万行で、ディメンションデータが含まれる場合は、ALL 分散スタイルを選択します。

      • EVEN はディストリビューションパターンに適していますが、すべてのコンピューティングノードに対してデータが分散されます。

  • W – Amazon Redshift ワークロード管理 (WLM) の W です。WLM を使用する場合、コンピューティングクラスターを通じて SQL ステートメントの流れと、割り当てるシステムメモリを制御します。WLM の設定の詳細については、「 」を参照してください。

Amazon Redshift 評価チェックリスト

最善の評価結果を得るには、次の項目のリストで、項目が Amazon Redshift の評価に適用されるかどうか確認します。

  • データのロード時間COPY コマンドの使用は、データをロードするためにかかる時間をテストするための一般的な方法です。詳細については、「データロードのベストプラクティス」を参照してください。

  • クラスターのスループット – 1 時間あたりのクエリの測定は、スループットを決定するための一般的な方法です。そのためには、ワークロードの一般的なクエリを実行するテストを設定します。

  • データセキュリティ – Amazon Redshift では、保管時のデータと転送中のデータを簡単に暗号化できます。また、キーを管理するための数多くのオプションがあり、Amazon Redshift はシングルサインオン (SSO) の統合もサポートしています。

  • サードパーティー製ツールの統合 – JDBC または ODBC 接続を使用して、ビジネスインテリジェンスツールや他の外部ツールと統合できます。

  • 他の AWS のサービスとの相互運用性 – Amazon Redshift は、他の AWS のサービス (Amazon EMR、Amazon QuickSight、AWS Glue、Amazon S3、Kinesis など) と統合します。この統合を、データウェアハウスの設定と管理で使用できます。

  • スナップショットのバックアップと作成 – Amazon Redshift は変更された 5 GB のデータごと、または 8 時間ごとに (どちらか早い時点) 自動的にクラスターをバックアップします。また、スナップショットはいつでも作成できます。

  • スナップショットの使用 – 評価の一環として、スナップショットの使用と 2 番目のクラスターの作成を試します。開発およびテスト組織がクラスターを使用できるかどうかテストします。

  • サイズ変更 – 評価には、Amazon Redshift ノードの数またはタイプの増加を含める必要があります。クラスターは、読み取り専用モードであっても、サイズ変更時に完全にアクセス可能です。サイズ変更が進行中であることをユーザーが検出できるかどうか評価します。

  • サポート – 評価の一環として、AWS サポートを評価することを強くお勧めします。

  • クエリのオフロードと頻繁に使用されないデータへのアクセス – Amazon Redshift Spectrum を使用して、別のコンピューティングレイヤーにクエリをオフロードできます。また、Amazon Redshift クラスターに取り込まずに、S3 から直接、頻繁に使用されないデータに簡単にアクセスできます。

  • 運用コスト – データウェアハウスの運用の全体的なコストを、他のオプションと比較します。Amazon Redshift は完全マネージド型サービスであり、1 年あたり約 1000 USD で、テラバイトのデータの無制限の分析を実行できます。

Amazon Redshift 評価のベンチマーク

次の可能なベンチマークのリストが、Amazon Redshift の評価に適用される場合があります。

  • 各ランタイムカテゴリのクエリの一覧を収集します。十分な数 (たとえば、カテゴリあたり 30) を持つことで、現実的なデータウェアハウスの実装が評価に反映されます。

  • 評価に含める各クエリを、評価に対して確立するいずれかのカテゴリに関連付けるための一意の識別子を追加します。次に、これらの一意の識別子を使用して、システムテーブルのスループットを決定できます。また、query_group を作成して、評価クエリを整理することができます。

    たとえば、評価の「Reporting」カテゴリを確立した場合、評価クエリに「Report」という単語のタグを付けるコーディングシステムを作成できます。これにより、レポート内の個別のクエリを R1、R2 のように識別できます。次の例で、この方法を示します。

    [SELECT "Reporting" as query_category, "R1" as query_id, * FROM customers]

    クエリを評価カテゴリと関連付けた場合、一意の識別子を使用して、各カテゴリのシステムテーブルからのスループットを判断できます。次の例は、その方法を示しています。

    select query, datediff(seconds, starttime, endtime) from stl_query where querytxt like “%Reporting%” and starttime >= '2018-04-15 00:00' and endtime <'2018-04-15 23:59'
  • 既存のデータウェアハウスで、さまざまな実行時間がある履歴のユーザークエリまたは ETL クエリを使用してスループットをテストします。スループットをテストするときは、以下の項目を常に考慮する必要があります。

    • ロードテストユーティリティ (たとえば、JMeter などのオープンソースユーティリティ、またはカスタムユーティリティ) を使用する場合、そのツールでネットワーク送信時間を考慮できることを確認します。

    • ロードテストユーティリティが、Amazon Redshift の内部システムテーブルのスループットに基づいて実行時間を評価していることを確認します。

  • 評価中にテストする予定のさまざまな変形をすべて識別します。次のリストに、一般的ないくつかの変数を示します。

    • クラスターサイズ

    • インスタンスタイプ

    • ロードテストの期間

    • 同時実行の設定

    • WLM の設定

サポートが必要な場合は、Amazon Redshift の PoC (概念実証) サポートのリクエストについて参照してください。

その他のリソース

Amazon Redshift の評価の参考にするため、以下を参照してください。