Amazon Redshift のよくある質問

Amazon Redshift サーバーレスは、Amazon Redshift のサーバーレスオプションであり、データウェアハウスインフラストラクチャをセットアップおよび管理する必要なく、数秒で分析をより効率的に実行およびスケーリングできます。Redshift サーバーレスを使用すると、データアナリスト、開発者、ビジネスプロフェッショナル、データサイエンティストを含むすべてのユーザーが、データウェアハウスにデータを読み込んでクエリを実行するだけで、データから洞察を得ることができます。

AWS マネジメントコンソールでいくつかの手順を実行するだけで、[Amazon Redshift サーバーレスの設定] を選択して、データのクエリを開始できます。気象データ、国勢調査データ、ベンチマークデータセットなどのプリロードされたサンプルデータセットをサンプルクエリとともに利用して、分析をすぐに開始できます。データベース、スキーマ、テーブルを作成し、Amazon S3、Amazon Redshift からデータをロードしたり、Redshift でプロビジョンされた既存のクラスタースナップショットを復元したりできます。Amazon S3 データレイクでオープン形式 (Parquet や ORC など) のデータを直接クエリしたり、Amazon Aurora や Amazon RDS PostgreSQL や MySQL などの運用データベースでデータをクエリしたりすることもできます。入門ガイドを参照してください。

データウェアハウスの管理経験がない場合でも、クラスターのセットアップ、構成、管理、またはウェアハウスの調整について心配する必要はありません。データから有意味なインサイトを引き出すこと、またはデータを通じてコアビジネスの成果を実現することに専念できます。支払いは実際に使用した分のみになるため、コストを管理しやすくなります。Amazon Redshift の最高のパフォーマンス、豊富な SQL 機能、データレイクおよび運用データウェアハウスとのシームレスな統合、組み込みの予測分析およびデータ共有機能のすべてを引き続きご利用いただけます。データウェアハウスをきめ細かく制御する必要がある場合は、Redshift クラスターをプロビジョニングできます。

複雑な結合、Amazon S3 データレイクと運用データベースのデータへの直接クエリ、マテリアライズドビュー、ストアドプロシージャ、半構造化データのサポート、機械学習、大規模の高パフォーマンスなど、Amazon Redshift の豊富な分析機能をすべて引き続きご利用いただけます。Amazon Redshift が統合するすべての関連サービス (Amazon Kinesis、AWS Lambda、Amazon QuickSight、Amazon SageMaker、Amazon EMR、AWS Lake Formation、AWS Glue など) は、引き続き Amazon Redshift サーバーレスで動作します。

すべての分析ユースケースを引き続き実行できます。シンプルな開始ワークフロー、自動スケーリング、および使用料の支払い機能により、Amazon Redshift サーバーレスエクスペリエンスにより、アドホックビジネスで迅速に開始する必要がある開発およびテスト環境をさらに効率的かつ費用対効果の高い方法で実行できるようになりました。分析、変化する予測不可能なコンピューティングニーズを伴うワークロード、および断続的または散発的なワークロード。

Amazon Redshift へのデータは、さまざまなデータソースから、例えば Amazon S3、Amazon RDS、Amazon DynamoDB、Amazon EMR、AWS Glue、AWS Data Pipeline からロードでき、他にも Amazon EC2 上またはオンプレミスの SSH 対応ホストからロードできます。Amazon Redshift は、データウェアハウスクラスターにデータを取り込む速度を最大化するために、データを各コンピューティングノードに並行してロードしようとします。クライアントは、ODBC または JDBC を使用して Amazon Redshift に接続し、「挿入」SQL コマンドを発行してデータを挿入できます。これは、S3 または DynamoDB を使用するよりも遅いことに注意してください。これらのメソッドは、SQL 挿入ステートメントが単一のリーダーノードを介してロードするのに対し、各コンピューティングノードに並列にデータをロードするためです。Amazon Redshift へのデータロードの詳細については、入門ガイドを参照してください。

Redshift 自動コピーは、Amazon S3 フォルダを追跡し、顧客の介入なしに新しいファイルを取り込むことで、コピーステートメントを自動化する機能を提供します。自動コピーを使用しない場合、コピーステートメントは、既存のファイルのファイルインジェストプロセスをすぐに開始します。自動コピーは既存のコピーコマンドを拡張し、1/新しいファイルの指定された Amazon S3 パスを監視することでファイルの取り込みプロセスを自動化し、2/コピー設定を再利用して、繰り返しの取り込みのために新しいコピーステートメントを作成して実行する必要性を減らします。タスクと 3/ロードされたファイルを追跡して、データの重複を回避します。

開始するには、関連する IAM ロールを使用して Redshift クラスター/サーバーレスエンドポイントからアクセスできる Amazon S3 フォルダーを用意し、ターゲットとして使用する Redshift テーブルを作成する必要があります。Amazon S3 パスと Redshift テーブルの準備ができたら、copy コマンドを使用してコピージョブを作成できます。コピージョブが作成されると、Redshift はバックグラウンドで指定された Amazon S3 パスの追跡を開始し、ユーザー定義のコピーステートメントを開始して、新しいファイルをターゲットテーブルに自動的にコピーします。

主なユースケースは次のとおりです。1/ Amazon EMR と AWS Glue を使用して、データインジェストと変換パイプライン (バッチとストリーミング) の一部としてデータにアクセスして Amazon Redshift にロードする Apache Spark ジョブを実行するお客様 2/ Amazon SageMaker を使用して実行するお客様 Apache Spark を使用した機械学習であり、特徴量エンジニアリングと変換のために Amazon Redshift に保存されたデータにアクセスする必要があります。3/Amazon Athena のお客様は、Apache Spark を使用して Amazon Redshift でデータのインタラクティブな分析を実行します。

バイカルには次の利点があります。

• Amazon Redshift のデータで Apache Spark アプリケーションを簡単に使い始めて実行できるため、認証されていないバージョンの Spark のセットアップやメンテナンスを手動で行う必要がありません
• Amazon EMR、AWS Glue、Amazon Athena、Amazon SageMaker など、さまざまな AWS サービスから Apache Spark を Amazon Redshift と組み合わせて最小限の構成で使用することの利便性
• Amazon Redshift で Apache Spark アプリケーションを実行しているときのパフォーマンスが向上しました

Amazon Aurora Zero-ETL to Amazon Redshift は、Amazon Aurora のトランザクションデータを書き込み後数秒で Amazon Redshift で利用可能にするフルマネージドソリューションの提供により、Aurora と Amazon Redshift のお客様がペタバイト級のトランザクションデータに対してほぼリアルタイムな分析と機械学習の実行を可能にします。Amazon Aurora Zero-ETL to Amazon Redshift を使用すると、お客様は Amazon Redshift で分析したいデータを含む Amazon Aurora テーブルを選択するだけで、スキーマとデータがシームレスに Amazon Redshift にレプリケートされます。お客様が複雑なデータパイプラインを構築および管理する必要性が減るため、アプリケーションの改善に専念できます。Amazon Aurora Zero-ETL to Amazon Redshift を使用すると、お客様は複数の Amazon Aurora データベースクラスターから同じ Amazon Redshift インスタンスにデータをレプリケートして、複数のアプリケーションにわたって包括的な洞察を得ることができます。また、中核となる分析資産を統合して、大幅なコスト削減と運用効率を得ることができます。Amazon Aurora Zero-ETL to Amazon Redshift を使用すると、マテリアライズドビュー、データ共有、複数のデータ ストアやデータレイクへのフェデレーションアクセスなど、Amazon Redshift のコア分析および機械学習機能にもアクセスできます。これにより、顧客はほぼリアルタイムの分析とコア分析を組み合わせて、ビジネス上の意思決定に役立つ時間に敏感な洞察を効果的に引き出すことができます。さらに、顧客はトランザクションに Amazon Aurora を使用し、分析に Amazon Redshift を使用するため、共有コンピューティングリソースがなく、パフォーマンスが高く、運用上安定したソリューションが得られます。

Amazon Redshift と Amazon Aurora のゼロ ETL 統合により、トランザクション分析のための 2 つのサービス間のシームレスな統合を提供することができます。

ストリーミングデータは、ストリームにクエリを実行すると、時変リレーションの進化をキャプチャするという点で、従来のデータベーステーブルとは異なります。一方、テーブルは、この時間によって変化する関係の特定時点のスナップショットをキャプチャします。Amazon Redshift のお客様は、通常のテーブルでの操作に慣れており、「ELT」などの従来のバッチモデルを使用してデータのダウンストリーム処理 (つまり、変換) を実行しています。Redshift マテリアライズドビュー (MV) を使用する方法を提供します。これにより、お客様は、ストリームの特定時点のビューを、クエリが実行されるまで蓄積されたものとして、ELT ワークフローをサポートするためにできるだけ速く簡単に具体化できます。

主なユースケースには、以下のようなものがあります。

• 多くのビジネスインテリジェンス/分析クラスターとデータを共有する中央 ETL クラスターは、読み取りワークロードの分離と選択可能な請求機能を提供します。
• 外部使用者とデータを共有するデータプロバイダー。
• 顧客、製品などの共通データセットをさまざまなビジネスグループ間で共有し、幅広い分析とデータサイエンスのために協力します。
• 管理を簡素化するためのデータウェアハウスの分散化。
• 開発、テスト、および実稼働環境の間でデータを共有します。
• 他の AWS 分析サービスから Redshift データへのアクセス。

クロスデータベース クエリを使用すると、接続しているデータベースに関係なく、アクセスできる任意の Redshift データベースからデータをシームレスにクエリして結合できます。これには、クラスター上でローカルなデータベースや、リモートクラスターから利用できる共有データセットも含まれます。クロスデータベースクエリを使用すると、データを個別のデータベースとして整理して、マルチテナント設定をサポートする柔軟性が得られます。

AWS Data Exchange は、AWS のお客様が AWS でサードパーティのデータを安全に交換および使用することをより効率的にします。ほぼすべての業界のデータアナリスト、プロダクトマネージャー、ポートフォリオマネージャー、データサイエンティスト、クオンツ、臨床試験技術者、および開発者は、分析を推進し、機械学習モデルをトレーニングし、データ主導の意思決定を行うために、より多くのデータにアクセスしたいと考えています。しかしながら、複数のプロバイダーにデータを検索する場所はなく、また、プロバイダーがデータを配信する方法に一貫性がないため、出荷済み物理メディア、FTP 認証情報、カスタマイズされた API コールが混在したままとなります。逆に、多くの組織はデータを研究や商業目的で利用できるようにしたいと考えていますが、データ配信、権利付与、および課金テクノロジを構築および維持するには、あまりにも困難で費用がかかりすぎて、貴重なデータの供給をさらに抑制しています。

Amazon Redshift サーバーレスは、データウェアハウスの容量を自動的にプロビジョニングし、基盤となるリソースをインテリジェントにスケーリングします。Amazon Redshift サーバーレスは数秒で容量を調整し、最も要求が厳しく変化しやすいワークロードに対しても一貫して高いパフォーマンスと簡素化された操作を提供します。同時実行スケーリング機能を使用すると、無制限の同時ユーザーと同時クエリをサポートでき、常に高速なクエリパフォーマンスを維持できます。同時実行スケーリングが有効になっている場合、クラスターのクエリキューイングが増加すると、Amazon Redshift は自動的にクラスター容量を追加します。

手動スケーリングの場合、クエリのパフォーマンスを向上させたり、CPU、メモリ、または I/O の過剰使用に対応したりする場合は、AWS マネジメントコンソールまたは ModifyCluster API から Elastic Resize を使用して、データウェアハウスクラスター内のノード数を増やすことができます。データウェアハウス クラスターを変更すると、要求した変更がすぐに適用されます。コンピューティング使用率、ストレージ使用率、および Redshift データウェアハウスクラスターへの読み取り/書き込みトラフィックのメトリクスは、AWS マネジメントコンソールまたは Amazon CloudWatch API を通じて無料で入手できます。Amazon CloudWatch カスタムメトリック機能を使用して、ユーザー定義のメトリクスを追加することもできます。

Amazon Redshift Spectrum を使用すると、Amazon S3 の同じデータにアクセスする複数の Redshift クラスターを実行できます。ユースケースごとに異なるクラスターを使用できます。たとえば、1 つのクラスターを標準レポートの作成に使用し、別のクラスターをデータ分析クエリに使用できます。マーケティングチームは運用チームと異なる独自のクラスターを使用できます。Redshift Spectrum は、クエリの実行を共有リソースプールから複数の Redshift Spectrum ワーカーに自動的に分散し、Amazon S3 からデータを読み取って処理し、結果を Redshift クラスターに戻して残りの処理を行います。

使用できるかどうかは状況により異なります。同時実行スケーリング機能を使用している場合、同時実行スケーリング中データウェアハウスクラスターでは読み取りおよび書き込みが完全に使用可能です。Elastic サイズ変更を使用している場合、4～8 分のサイズ変更期間中はクラスターを使用できません。マネージドストレージの Redshift RA3 ストレージの伸縮性により、クラスターは完全に利用可能になり、データはマネージドストレージとコンピューティングノード間で自動的に移動されます。

Elastic Resize は、クエリのスループットを管理するために、数分以内に単一の Redshift クラスターからノードを追加または削除します。例えば、1 日または月末レポートの特定の時間の ETL ワークロードは、時間どおりに完了するために追加の Amazon Redshift リソースが必要になる場合があります。同時実行スケーリングは、追加のクラスター リソースを追加して、全体的なクエリの同時実行性を高めます。

いいえ。同時実行スケーリングは、Amazon Redshift リソースの非常にスケーラブルなプールであり、お客様は直接アクセスできません。

Amazon Redshift は、シングルサインオン (SSO)、多要素認証、列レベルのアクセス制御、行レベルのセキュリティ、ロールベースのアクセス制御、および Amazon Virtual Private Cloud (Amazon VPC) のための組み込みの ID 管理とフェデレーションにより、業界をリードするセキュリティをサポートします。Amazon Redshift を使用すると、転送中および保管中のデータが暗号化されます。Amazon Redshift のすべてのセキュリティ機能は、最も厳しいセキュリティ、プライバシー、およびコンプライアンスの要件を満たすために、追加料金なしですぐに利用できます。ISO 27001、SOC、HIPAA/HITECH、FedRAMP など、他のどのプロバイダーよりも多くのセキュリティ基準とコンプライアンス認証をサポートする AWS のメリットを享受できます。

はい、Amazon Redshift がロールベースのアクセスコントロールのサポートを提供しています。行レベルのアクセス制御を使用すると、1 つ以上のロールをユーザーに割り当て、ロールごとにシステムおよびオブジェクトのアクセス許可を割り当てることができます。すぐに使用できるシステム ロール (ルートユーザー、dba、オペレーター、およびセキュリティ管理者) を使用するか、独自のロールを作成できます。

AWS Lambda ユーザー定義関数 (UDF) を使用すると、AWS Lambda 関数を Amazon Redshift で UDF として使用し、Redshift SQL クエリから呼び出すことができます。この機能を使用すると、SQL クエリのカスタム拡張機能を記述して、他のサービスやサードパーティー製品との密接な統合を実現できます。Lambda UDF を記述して、Protegrity などのベンダーと統合することで、外部トークン化、データ マスキング、データの識別または匿名化を有効にし、クエリ時にユーザーのアクセス許可とグループに基づいて機密データを保護または保護解除できます。

動的データマスキングのサポートにより、お客様は機密データを簡単に保護し、データマスキング ポリシーを管理することで詳細なアクセスを制御できます。複数のユーザーと、すべてのユーザーに公開できない機密データを含むオブジェクトを持つアプリケーションがあるとします。さまざまなユーザー グループに付与する、さまざまな細分化されたセキュリティレベルを提供する必要があります。Redshift の動的データマスキングは構成可能であり、お客様は、一貫性があり、フォーマットを維持し、元に戻すことができないマスクされたデータ値を定義できます。機能が GA になると、すぐに使用を開始できます。セキュリティ管理者は、ほんの数コマンドでポリシーを作成して適用できます。

はい。Microsoft Azure Active Directory、Active Directory フェデレーションサービス、Okta、Ping Federate、またはその他の SAML 準拠の ID プロバイダーなどの企業 ID プロバイダーを使用したいお客様は、シングルサインオンを提供するように Amazon Redshift を設定できます。Microsoft Azure Active Directory (AD) ID を使用して Amazon Redshift クラスターにサインオンできます。これにより、Redshift で Azure Active Directory ID を複製することなく、Redshift にサインオンできるようになります。

はい。Amazon Redshift クラスターへの認証時に、セキュリティを強化するために多要素認証 (MFA) を使用できます。

Amazon Redshift は、データウェアハウス クラスターで障害が発生したノードを自動的に検出して置き換えます。高密度コンピューティング (DC) および高密度ストレージ (DS2) クラスターでは、高いデータ耐久性を確保するために、データはコンピューティングノードに格納されます。ノードが置き換えられると、データは他のノードのミラーコピーから更新されます。データは Amazon S3 に保存され、ローカルドライブはデータキャッシュとしてのみ使用されるため、RA3 クラスターと Redshift サーバーレスは同じようには影響を受けません。代替ノードがプロビジョニングされて DB に追加されるまで、データウェアハウスクラスターはクエリと更新に使用できません。Amazon Redshift は、交換ノードをすぐに利用できるようにし、最も頻繁にアクセスされるデータを最初に Amazon S3 からロードして、データのクエリをできるだけ早く再開できるようにします。単一ノードクラスターは、データレプリケーションをサポートしていません。ドライブに障害が発生した場合は、S3 のスナップショットからクラスターを復元する必要があります。実稼働には少なくとも 2 つのノードを使用することをお勧めします。

Amazon Redshift データウェアハウスがシングル AZ デプロイであり、クラスターのアベイラビリティー ゾーンが利用できなくなった場合、Amazon Redshift は、データの損失やアプリケーションの変更なしで、クラスターを別の AWS アベイラビリティーゾーン (AZ) に自動的に移動します。これを有効にするには、クラスター構成設定で再配置機能を有効にする必要があります。

シングル AZ デプロイとは異なり、マルチ AZ 配置でデータウェアハウスを実行することにより、お客様は Redshift の可用性を向上させることができるようになりました。マルチ AZ 配置では、データウェアハウスを複数の AWS アベイラビリティーゾーン (AZ) で同時に実行し、予期しない障害シナリオでも運用を続けることができます。マルチ AZ 配置は 1 つのエンドポイントを持つ単一のデータウェアハウスとして管理されるため、ビジネス継続性を維持するためにアプリケーションを変更する必要はありません。マルチ AZ 配置は、自動的に回復する容量を保証することで回復時間を短縮し、最高レベルの可用性と AZ 障害に対する回復力を必要とするビジネス クリティカルな分析アプリケーションを使用するお客様を対象としています。これにより、お客様は、AWS Well-Architected フレームワークの信頼性の柱の推奨事項により準拠したソリューションを実装することもできます。Amazon Redshift マルチ AZ の詳細については、こちらを参照してください。

RPO は Recovery Point Objective の頭字語であり、障害が発生した場合のデータの最新性の保証を表す用語です。RPO は、最後のデータ復旧ポイントからの最大許容時間です。これにより、最後の復旧ポイントからサービスの中断までの間の許容可能なデータ損失と見なされるものを決定します。Redshift マルチ AZ は RPO = 0 をサポートします。これは、障害が発生した場合にデータが最新であることが保証されることを意味します。リリース前のテストでは、Amazon Redshift マルチ AZ 配置の RTO は、万が一 AZ 障害が発生した場合でも 60 秒未満であることがわかりました。

Redshift Relocation は、すべての新しい RA3 クラスターとサーバーレスエンドポイントでデフォルトで有効になっています。これにより、大規模な停止が発生した場合に、データの損失や追加コストなしで、別の AZ でデータウェアハウスを再起動できます。再配置は無料で使用できますが、これはベストエフォート型のアプローチであり、復旧対象の AZ でのリソースの可用性と、新しいクラスターの起動に関連する他の問題によって目標復旧時間 (RTO) が影響を受ける可能性があるという制限があります。これにより、回復に 10 ～ 60 分かかる場合があります。Redshift マルチ AZ は、数十秒で測定された RTO を提供することで高可用性要件をサポートし、容量の制限や新しいクラスターを作成するその他の潜在的な問題の影響を受けないため、継続的な運用を保証します。

はい。Amazon Redshift は業界標準の SQL を使用し、標準の JDBC および ODBC ドライバーを使用してアクセスします。Redshift コンソールの [Connect Client] タブからは、Amazon Redshift のカスタムの JDBC および ODBC ドライバーをダウンロードできます。人気のある BI および ETL ベンダーとの統合が検証されており、その多くは、データの読み込みと分析を開始するのに役立つ無料トライアルを提供しています。また、AWS Marketplace でも、Amazon Redshift と連携するように設計されたソリューションを数分でデプロイおよび設定できます。

Amazon Redshift Spectrum はすべての Amazon Redshift クライアントツールをサポートしています。クライアントツールは、引き続き ODBC または JDBC 接続を使用して Amazon Redshift クラスターエンドポイントに接続できます。変更の必要はありません。

Redshift Spectrum のテーブルにアクセスするために使用するクエリは、Redshift クラスターのローカルストレージにあるテーブルに対して使用するものと完全に同じ構文および機能を持ちます。外部テーブルは、それらが登録された CREATE EXTERNAL SCHEMA コマンドで定義されたスキーマ名を使用して参照されます。

Amazon Redshift Spectrum は現在、Avro、CSV、Grok、Amazon Ion、JSON、ORC、Parquet、RCFile、RegexSerDe、シーケンス、テキスト、TSV など、多くのオープンソースデータ形式をサポートしています。<br>Amazon Redshift Spectrum は現在 Gzip 圧縮と Snappy 圧縮をサポートしています。

ローカルテーブルの場合と同じように、クエリで schema_name.table_name を使用することで、スキーマ名を使用して、意図したテーブルを正確に選択できます。

はい。CREATE EXTERNAL SCHEMA コマンドは Hive メタストアをサポートしています。現在、Hive メタストアに対する DDL はサポートされていません。

システムテーブル SVV_EXTERNAL_TABLES にクエリを実行して、その情報を取得することができます。

はい。Amazon Redshift ML 機能により、SQL ユーザーは使い慣れた SQL コマンドを使用して機械学習 (ML) モデルを簡単に作成、トレーニング、デプロイできます。Amazon Redshift 機械学習を使用すると、フルマネージドの機械学習サービスである Amazon SageMaker を使用して Amazon Redshift のデータを利用できます。Amazon Redshift は、教師なし学習 (K-Means) と教師あり学習 (Autopilot、XGBoost、MLP アルゴリズム) の両方をサポートしています。また、AWS Language AI サービスを使用して、事前に構築された Lambda UDF 関数を使用して SQL クエリのテキストフィールドを翻訳、編集、分析することもできます - ブログ投稿を参照してください。

Amazon Redshift は、あらゆるタイプの従来型、クラウドネイティブ、コンテナ化された、サーバーレスの Web サービスベースおよびイベント駆動型アプリケーションを使用して、Amazon Redshift からのデータに簡単にアクセスするために使用できる Data API を提供します。Data API は、ドライバーを設定したりデータベース接続を管理したりする必要がないため、Amazon Redshift へのアクセスを簡素化します。それらの管理を行う代わりに、ユーザーは Data API が提供する安全な API エンドポイントを呼び出すだけで、Amazon Redshift クラスターに SQL コマンドを実行することができます。データベース接続の管理とデータのバッファリングは Data API が行います。Data API は非同期であるため、後で結果を取得できます。クエリ結果は 24 時間保存されます。

Data API は、IAM 認証情報と AWS Secrets Manager からのシークレットキーの使用の両方をサポートしています。Data API は AWS Identity and Access Management (IAM) 資格情報をフェデレートするため、Okta や Azure Active Directory などの ID プロバイダー、または API 呼び出しでデータベース認証情報を渡すことなく、シークレットマネージャーに保存されているデータベース資格情報を使用できます。

はい、aws redshift-data コマンドラインオプションを使用して、AWS CLI から Data API を使用できます。

AWS Lambda、AWS Cloud9、AWS AppSync、Amazon EventBridge などの他のサービスから Data API を使用できます。

いいえ、Data API の使用に別途料金はかかりません。

Amazon Aurora MySQL 互換エディション、Amazon Aurora PostgreSQL 互換エディション (プレビュー)、Amazon RDS for MySQL、および Amazon DynamoDB (限定プレビュー) は、Amazon Redshift とのゼロ ETL 統合をサポートしています。

トランザクションデータにほぼリアルタイムでアクセスする必要がある場合は、Amazon Redshift との Aurora ゼロ ETL 統合を使用すべきです。ゼロ ETL 統合を使用すると、簡単な SQL コマンドで Amazon Redshift ML を活用できます。

Amazon Redshift との Aurora ゼロ ETL 統合は、サポートされている AWS リージョンの Aurora MySQL 3.05 バージョン (MySQL 8.0.32 と互換性あり) 以降の Aurora MySQL 互換エディションでご利用いただけます。

Amazon Redshift との Aurora ゼロ ETL 統合は、米国東部 (オハイオ) リージョンにおいて、Aurora PostgreSQL 15.4 向けの Aurora PostgreSQL 互換エディションでご利用いただけます。

Amazon Redshift のとの Aurora ゼロ ETL 統合により、複雑なデータパイプラインを構築して維持する必要がなくなります。1 つまたは複数の Aurora データベースクラスターからのデータを 1 つの Amazon Redshift データベースクラスターに統合し、Amazon Aurora からのペタバイト単位のトランザクションデータに対して、Amazon Redshift を使用してほぼリアルタイムの分析と ML を実行できます。

Amazon Redshift との Aurora ゼロ ETL 統合は、Amazon Redshift Serverless および Amazon Aurora Serverless v2 と互換性があります。Aurora Serverless v2 と Amazon Redshift Serverless の両方を使用すると、データパイプラインのインフラストラクチャを管理することなく、トランザクションデータの分析をほぼリアルタイムで生成できます。

まず、Amazon RDS コンソールを使用してゼロ ETL 統合を作成します。これには、Aurora ソースと Amazon Redshift デスティネーションを指定します。統合が作成されると、Aurora データベースが Amazon Redshift にレプリケートされ、最初のシードが完了したらデータのクエリを開始できます。詳細については、Amazon Redshift との Amazon Aurora ゼロ ETL 統合に関する開始方法ガイドをお読みください。

Aurora から Amazon Redshift Zero-ETL への統合では、トランザクションをアトミックにレプリケートして、ソース Aurora データベースとターゲット Amazon Redshift クラスター間のデータの一貫性を確保します。
この統合によるトランザクションのアトミック性に関するいくつかの重要なポイントは次のとおりです。

• Aurora でコミットされたトランザクションのみが Amazon Redshift にレプリケートされます。 コミットされていないトランザクションやロールバックされたトランザクションは適用されません。
• この統合では、2 段階のコミットプロセスを使用して各トランザクションを Amazon Redshift にアトミックに適用します。トランザクションのすべてのデータ変更が適用されるか、または何も適用されないか (エラーが発生した場合) のいずれかです。
• ソースとターゲットの間でトランザクションの一貫性が維持されます。レプリケーション後、特定のトランザクションのデータは Aurora と Amazon Redshift の両方で一貫性が保たれます。
• DDL または DML によるスキーマ変更も、整合性を維持するためにアトミックに適用されます。
• トランザクションをアトミックに適用することで、データベース間で部分的なトランザクションが発生したり、一貫性のないデータ状態が発生したりすることがなくなります。

Amazon Redshift との Aurora ゼロ ETL 統合により、ソース Aurora データベースとターゲット Amazon Redshift クラスター間のトランザクションの完全な一貫性が維持されます。

スキーマ変更の処理方法に関する重要なポイントは次のとおりです。

• CREATE TABLE、ALTER TABLE、DROP TABLE などの DDL ステートメントは、Aurora から Amazon Redshift に自動的にレプリケートされます。
• 統合により、レプリケートされたスキーマの変更について、Amazon Redshift テーブルで必要なチェックと調整が行われます。たとえば、Aurora に列を追加すると、その列が Amazon Redshift にも追加されます。
• レプリケーションとスキーマの変更は、ソースデータベースとターゲットデータベース間の遅延を最小限に抑えながら、リアルタイムで自動的に行われます。
• DML の変更が DDL の変更と並行して発生しても、スキーマの一貫性は維持されます。

ローカルのAmazon Redshiftデータベースでマテリアライズドビューを作成して、ゼロETL統合によってレプリケートされたデータを変換できます。ローカルデータベースに接続し、クロスデータベースクエリを使用して宛先データベースにアクセスします。3 部表記の完全修飾オブジェクト名 (destination-database-name.schema-name.table-name) を使用することも、宛先データベースとスキーマのペアを参照する外部スキーマを作成して 2 部表記 (external-schema-name.table-name) を使用することもできます。

ゼロ ETL 統合とデータ変更の継続的な処理は、追加料金なしで提供されます。ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の Amazon RDS および Amazon Redshift リソースには課金されます。これらのリソースには、次が含まれる場合があります。

• 拡張バイナリログを有効にすることで追加の I/O とストレージが使用される
• Amazon Redshift データベースをシードするための初期データエクスポートのスナップショットエクスポートコスト
• レプリケートされたデータを保存するための追加の Amazon Redshift ストレージ
• ソースからターゲットへのデータ移動にかかるCross-AZデータ転送コスト

詳細については、「Amazon Aurora の料金」にアクセスしてください。

Amazon Redshift との Amazon RDS for MySQL ゼロ ETL 統合に関するよくある質問については、「Amazon RDS for MySQL のよくある質問」をご覧ください。この統合の料金の詳細については、「Amazon RDS for MySQL の料金」をご覧ください。

Amazon Redshift RA3 クラスターと Amazon Redshift サーバーレスは、Redshift マネージドストレージを使用します。これには、常に最新のデータのコピーが利用可能です。DS2 および DC2 クラスターは、クラスター上のデータをミラーリングして、障害が発生した場合に最新のコピーを使用できるようにします。バックアップはすべての Redshift クラスタータイプで自動的に作成され、24 時間保持されます。サーバーレスの復旧時点では直近 24 時間のものが提供されます

無期限に保持できる独自のバックアップを作成することもできます。これらのバックアップはいつでも作成でき、Amazon Redshift の自動バックアップまたは Amazon Redshift サーバーレス復旧ポイントをユーザーバックアップに変換して、保持期間を長くすることができます。

Amazon Redshift は、スナップショットまたは復旧ポイントを別のリージョンの Amazon S3 に非同期でレプリケートして、ディザスタリカバリを行うこともできます。

DS2 または DC2 クラスターでは、無料のバックアップストレージは、データウェアハウスクラスターのノード上のストレージの総サイズまでに制限されており、アクティブなデータウェアハウスクラスターにのみ該当します。

例えば、データウェアハウスストレージが合計で 8 TB の場合は、追加費用なしでは最大でも 8 TB のバックアップストレージしか使用できません。バックアップ保持期間を 1 日を超えて延長したい場合は、AWS マネジメントコンソールまたは Amazon Redshift API を使用して行うことができます。自動スナップショットの詳細については、Amazon Redshift 管理ガイドを参照してください。

Amazon Redshift では変更されたデータのみがバックアップされるため、ほとんどのスナップショットでは無料のバックアップストレージがほんのわずかしか消費されません。バックアップを復元する必要がある場合、お使いのバックアップ保持ウィンドウ内にすべての自動バックアップへのアクセスをお持ちです。復元するバックアップを選択したら、新規データウェアハウスクラスターがプロビジョニングされ、そこにデータが復元されます。

AWS マネジメントコンソールまたは ModifyCluster API を使用して、RetentionPeriod パラメータを変更することにより、自動バックアップが保持される期間を管理できます。自動バックアップを完全にオフにする場合は、保持期間を 0 に設定できます (推奨されません)。

データウェアハウスクラスターを削除する場合、削除時に最終スナップショットを作成するかどうかを指定できます。これにより、削除されたデータウェアハウスクラスターを後日復元できます。以前に作成したデータウェアハウス クラスターの手動スナップショットはすべて保持され、削除を選択しない限り、標準の Amazon S3 レートで請求されます。

コンピューティング使用率、ストレージ使用率、および Amazon Redshift データウェアハウスクラスターへの読み取り/書き込みトラフィックのメトリクスは、AWS マネジメントコンソールまたは Amazon CloudWatch API を通じて無料で入手できます。Amazon CloudWatch のカスタムメトリック機能を使用して、ユーザー定義のメトリクスを追加することもできます。AWS マネジメントコンソールは、すべてのクラスターの状態とパフォーマンスを監視するのに役立つ監視ダッシュボードを提供します。Amazon Redshift は、AWS マネジメントコンソールを介して、クエリとクラスターのパフォーマンスに関する情報も提供します。この情報により、クエリプランと実行統計を表示することで、どのユーザーとクエリが最も多くのシステムリソースを消費しているかを確認し、パフォーマンスの問題を診断できます。さらに、各コンピューティングノードのリソース使用率を確認し、すべてのノード間でデータとクエリのバランスが確実にとれるようにできます。

Amazon Redshift は定期的にメンテナンスを実行して、クラスターに修正、機能強化、および新機能を適用します。プログラムまたは Redshift コンソール を使用してクラスターを変更することにより、スケジュールされたメンテナンスウィンドウを変更できます。これらのメンテナンス期間中、Amazon Redshift クラスターは通常の操作に使用できません。リージョン別のメンテナンスウィンドウとスケジュールの詳細については、Amazon Redshift 管理ガイドの「メンテナンスウィンドウ」を参照してください。