Amazon Web Services ブログ
Netezza データウェアハウスの Amazon Redshift への移行
IBM により Netezza の製品寿命が終了する旨の発表がなされており、現状の分析アプライアンスからデータとワークロードを移動する必要性に迫られている人もいることでしょう。一部の人にとっては、これがクラウド移行の良いチャンスにもなります。
そこで Amazon Redshift の登場です。
Amazon Redshift は、大規模なワークロードを処理できるように構築された、クラウドネイティブなデータウェアハウスプラットフォームです。主要な部分が Netezza と共通なので、オンプレミスのアプライアンスの置き換え先として素晴らしい候補の 1 つとなります。Amazon Redshift を使えば、他の分析プラットフォームに対する場合より短い時間と少ない変更点で、データやアプリケーションを移行できます。このことは、開発者にとってみれば、新しいデータベースを再トレーニングする時間が削減できることを意味します。また経営側から見てみると、移行に関するコストと時間を節約できることになります。詳細については、「How to migrate a large data warehouse from IBM Netezza to Amazon Redshift with no downtime」をご参照ください。
この記事では、Netezza と Amazon Redshift の間での重要な共通点と相違点をご説明しながら、それらが移行タイムラインに与える影響についても解説していきます。
共通点
Netezza と Amazon Redshift の間には、3 つの大きな共通点が存在します。つまり、Postgres との互換性、強力な並列処理 (MPP) アーキテクチャ、そして Netezza では FPGA で実現している機能である Amazon Redshift の Advanced Query Accelerator (AQUA) です。
Postgres との互換性
Netezza と Amazon Redshift では、オープンソースデータベースである Postgres に対し、いくつかの互換性が共通しています。Netezza SQL と Amazon Redshift SQL は同じ構文を使用しており、特に両者とも、Postgres での手続き型言語である PL/pgSQL をサポートしています。Netezza に保存してある手続きコードは、ほぼ書き換えなしで、Amazon Redshift 用に変換できることになります。
また、AWS Schema Conversion Tool も用意されています。これにより、ユーザーは労力を一切払うことなく、Netezza に保存してある手続きの大部分を Amazon Redshift 構文へ移行することが可能です。さらに、これら 2 つのデータベースともに、トランザクショナル用ではなく分析ワークロード用に設計されているため、その特性も似通っています。たとえば、Netezza でも Amazon Redshift であっても、オプティマイザーにクエリプランを改善させる目的でテーブル上のプライマリキーを定義することが可能ですが、パフォーマンス向上のためにプライマリキーを適用することはありません。
MPP アーキテクチャ
Netezza と Amazon Redshift はどちらも MPP データベースです。したがって、クエリはまずリーダーノードに送信され、その後、複数のコンピューティングノードに伝達するため、 1 組のコマンドセットにコンパイルされます。このタスクは各ワーカーノードで並列処理され、結果がリーダーノードに返されます。それぞれの結果はここで集約され、ユーザーに対して出力されます。このことは、Netezza におけるゾーンマッピングや分類スタイルなどのアーキテクチャ的戦略を、同じように Amazon Redshift にも適用できるということを意味します。詳細については、「Amazon Redshift Engineering’s Advanced Table Design Playbook: Preamble, Prerequisites, and Prioritization」をご参照ください。
Amazon Redshift AQUA と Netezza の FPGA
AWS では最近、Amazon Redshift の新機能 AQUA を発表しており、本投稿執筆時点ではプレビュー版となっています。AQUA は、特定のコンピューティングタスクをストレージレイヤーの近方に置くために、AWS が設計したプロセッサーを使用します。圧縮、暗号化、フィルタリング、集約 (およびその他のタスクなど) は、ストレージとコンピューティングの中間的なレイヤーで処理されます。これにより CPU は、より複雑なタスクを処理するための能力を温存できます。この AQUA は、リリースの時点でクエリ速度を最大で 10 倍に高めました。
Netezza では、CPU に到達する前のデータに対し、FPGA を使ってシンプルな計算処理を行っています。この、Netezza における FPGA 機能を適用するように設計されたアプリケーション (特定の集約関数やデータフィルタリングに強く依存するクエリなど) は、AQUA を使う Amazon Redshift クラスターに効率良く変換できます。
相違点
前出のように Amazon Redshift と Netezza の間にはいくつもの類似点がありますが、同時に相違点も存在します。Netezza から Amazon Redshift への移行を行う際、データとアプリケーションのアーキテクチャに無視できない影響を与え得る、留意すべき相違点は 3 つ存在します。つまり、列保存と行保存、同時実行スケーリング、データレイク統合です。
列保存と行保存
Netezza が、行ごとのデータをディスク上のデータブロックに保存するのに対し、Amazon Redshift では、列ごとのデータを保存します。列保存は、多くの分析ワークロードにおいて、行保存と比べてパフォーマンス上の大きなメリットを提供できます。一般的には、分析用データベースのテーブルには多くの列が存在しますが、1 回のクエリで使われるのは、この中でひと握りの列だけです。たとえば、列が 100 個、行が 1 億個あるテーブルを保持している、行保存データベースを想定してみましょう。仮に、このテーブルにおいて 1 つの列にあるすべての値を合計しようとすると、そのクエリでは、たった 1 つの列にあるデータを取得するためテーブル全体を検索する際の I/O に、かなりな時間を奪われることになります。同じテーブルを保持する列型のデータベースでは、処理すべき I/O は列を 1 度処理する分だけになります。また Amazon Redshift では、こういったワークロードに対して改善したパフォーマンスを活用できることに加え、他のオプションも用意されています。Netezza で実施していた一般的な分析ワークロード用の幅広なテーブルを、I/O の増加を考慮せずに設計できるのです。
同時実行スケーリング
Netezza と Amazon Redshift ではともに、同時実行における問題を低減するために、キューの優先度と短いクエリの高速化がサポートされています。ただ、Amazon Redshift には、クラウドのメリットを活用して同時実行を処理するための、追加的なオプションもあります。
その機能の中の 1 つでは、Netezza アプライアンスから関係性のないワークロードを取り出します。それらは、処理規模に応じてインスタンスタイプとノード数が設定された、個別の Amazon クラスターに移行されます。Netezza がライセンスとサポートのため提供する従来の料金モデルでは、アプライアンスのサイズの選択肢は限られています。したがって、こういった種類のアーキテクチャのための予算を、各組織が用意しきれない場合もあり得ます。
加えて、Amazon Redshift では 同時実行スケーリング 機能も使えます。これにより、追加的な計算キャパシティのスケールアウト (そして後のスケールイン) を、即座に自動的に行えます。クラスター内でノードの追加や削除をする場合、もしくは、他の種類のノードを試したいといった場合には、伸縮自在なサイズ変更 (ノード数を変更する場合) 、および従来のサイズ変更 (インスタンスタイプを変更する場合) を使って、ほんの数分でそれを実行できます。
この種類のスケーリングやサイズ変更は、ブレード数が固定されたオンプレミスのアプライアンスを使っている Netezza では、現実的なものとは言えません。Amazon Redshift での同時実行スケーリングでは、事実上無制限のユーザー数とクエリ数を同時処理できます。さらに、必要な計算キャパシティが自動的に追加および削除されるので、同時実行スケーリングクラスターの料金は、実際に使用された期間のみとなります。
データレイク統合
Netezza では、Netezza ホストもしくはリモートのホストからのデータファイルを使い、外部テーブルを作成することが可能です。しかし、これらのテーブルでクエリを実行する際は、事前に、内部的な全データセットを移行しておく必要があります。Amazon Redshift Spectrum によれは、データベースとの間でデータセットを移動するための便利な手法としての外部テーブルは必要ありません。データレイク内のデータに対し、内部テーブルと同じ方法で分析クエリが実行できます。パーティショニングは、データレイク内のデータ量が増大するのに合わせ、1 度のクエリで検索するデータ数 (つまりパフォーマンス) に一貫性を維持するよう機能します。さらに、Amazon Simple Storage Service (Amazon S3) にある外部テーブルからのデータを、Amazon Redshift の内部テーブルに加えることも可能です。
このことの意味は、データウェアハウスとデータレイクを真に統合し、ウェアハウスでのコストの高い要件を緩和するということに留まりません。お客様のクラスター外にある専有インフラストラクチャを使う Amazon Redshift Spectrum レイヤーでは、お客様のクラスターを多くのコンピューティング集約型タスクから解放し、それらを Redshift Spectrum レイヤーに押し込むことが可能になるのです。詳細については「Amazon Redshift Spectrum の概要」をご参照ください。
まとめ
Amazon Redshift を使うと Netezza からの移行を加速でき、分析ワークロードのクラウドへの移行において、コストと時間の削減が期待できます。これら 2 つのシステム間にある共通点が、移行に関する諸問題を緩和します。さらに Amazon Redshift には、パフォーマンスとコストに対し追加的なメリットを与え得る、異なった重要機能も備わっています。AWS のパートナーネットワークとその専門知識が、お客様の移行戦略を支援し、可能性のある障害や落とし穴を避けるためのガイドをご提供いたしております。
著者について
John Hwang は、AWS のシニア ソリューション アーキテクトです。
Brian McDermott は、 AWS のシニアセールスマネージャーです。