Netezza ユーザーのための Amazon Redshift 移行ガイド

Netezza テクノロジーを活用した PureData System for Analytics（以降、Netezzaと略す）をご利用のお客様から Amazon Redshift（以降、Redshiftと略す） に関するお問合せや、導入支援のご相談を受ける機会が増えている今日このごろです。Netezza は詳しいけれど、Redshift はよくわからないという方へ、それぞれの違いや Redshift 移行時に考慮することについてご説明します。Netezza と Redshift は、アーキテクチャやSQLに共通点が多いので、Netezza のノウハウが活用でき、学習のコストをあまりかけずに移行できるのではないかと期待を込めてご紹介します。

Redshift 登場の背景

Netezza をはじめとする従来のDWH（データウェアハウス）は、大容量、高性能を追求するために製品・ソリューション専用にチューニングしたアプライアンスとして販売される、非常に高価なものでした。これらのハードルの高さが、DWH やデータ分析基盤の普及の妨げとなっていました。

そこで、2013年に登場したのが Redshift です。クラウドベースの高性能・低価格の DWH サービスは、圧倒的な低コストの他、必要なときに数クリックでスケールアップできるアジリティと、PBを超える規模のデータ集計・分析が可能となる拡張性があります。Redshift は PostgreSQL のプラガブルなアーキテクチャを活かして開発されているので、コマンドや SQL 構文の互換性が高く、PostgreSQL 既存資産の流用が容易で、教育投資が少なく、データ分析に集中できるプラットフォームとして、現在に至ります。

以降、Redshift と Netezza の違いについてご説明します。

アーキテクチャ

Redshift と Netezza は、共に PostgreSQL から派生した DWH です。そのような背景もあり、Netezza ユーザーの方であれば、すでに聞いたことのあることが多く、アーキテクチャを理解するのに時間はかからないと考えています。用語の対応付けは以下のとおりです。

参考：Amazon Redshift Integration Deep Dive (P.10)

Redshift は、Leader Node を頂点に複数の Compute Node が位置する、シェアードナッシングアーキテクチャを採用しています。データはDWHでよく採用される列指向（カラムナ）で、列単位でデータ圧縮してディスクに格納します。ノード間は標準で 10GB のネットワークに接続され、IO のボトルネックが軽減されます。

コスト

Redshift

クラウドベースなので、サーバールーム・工事・電源・空調・ハードの運用・保守・監視は不要です。フルマネージドサービスなので、ソフトのパッチ適用の自動化、バックアップ機能は標準で提供されます。コストは１時間毎に課金されますので、数時間の検証や数日間のPoCにも柔軟な試用が可能です。

サービスが開始してから、価格の変更（プライスダウン）や、低価格・高性能なノードタイプが投入されています。先月は価格変更なしでCPUやIOが従来の２倍になった ds2 ノードが追加され、さらに従来のノードタイプ dw1（dc1）のリザーブドインスタンス購入ユーザーに対して乗り換えも提供されています。詳しくは Amazon Redshift の新しいインスタンスタイプ「DS」を試してみた を御覧ください。

高密度コンピュートノードはデータ容量よりも、処理性能を重視したノードタイプです。一方、高密度ストレージノードはデータ容量と、処理性能のバランスを重視したノードタイプです。

高密度コンピュートノード dc1.large、dc1.8xlarge

Dense Compute（DC）ノードでは、安価で高パフォーマンスのデータウェアハウスを作成できるように、高速 CPU、大容量 RAM、および SSD（Solid-State Disk）が使用されます。ディスク容量よりもIOや処理性能を重視したノードタイプで、上位のノードタイプとしてdc1.8xlargeが提供されています。dc1.largeはRedshift が提供する最も利用費が安いノードタイプです。

高密度ストレージノード ds2.xlarge、ds2.8xlarge

新しい Dense Storage（DS）ノードでは、従来（ds1）よりも高パフォーマンスのデータウェアハウスを作成できるように、CPU、RAM、IOがそれぞれ２倍以上の向上し、大容量の HDD（ハードディスク）が使用されます。コンピュート性能よりもデータ容量を重視したノードタイプで、上位のノードタイプとして ds2.8xlarge が提供されています。といいましても ds1.xlarge は dc1.large 以上にコンピュート性能が優れています。

コスト試算

• 例１．小規模のエントリークラスタは、dc1.large x 1（約28,272円/月）
• 例２．ディスク4TB、CPU8個のクラスタは、ds2.xlarge x 2 (約235,715円/月）
• 例３．ディスク14TB、CPU28個のクラスタは、ds2.xlarge x 7 (約825,000円/月）

※ AWS利用費の試算は、2015/7/15現在の価格と、1ドル当たり123円で試算しています。リザードインスタンスを適用すると更にお安くなります。

Netezza

エントリーモデルは汎用サーバー上で Netezza テクノロジを動作させる機種「小規模エントリーモデル（N3001-001）」、ディスク4TB、CPU28個で、参考価格は2400万円（税別）です。

コスト試算

• 例１．ディスク4TB、CPU28個のクラスタは、「小規模エントリーモデル（N3001-001）」です。汎用サーバー上で Netezza テクノロジを動作させるモデルで (参考価格は2400万円（税別））です。

※ 参考価格について、こちらの記事を参考にしています。その他、サーバールーム・工事・電源・空調・ハード／ソフトのパッチ適用、もちろんバックアップソリューションは別途必要です。

拡張性

Netezza がスケールアップをする場合は、上記の製品ラインナップの中から選択して移行、もしくは増強となるでしょう。

Redshift がスケールアップをする場合は、ノード数を増やしたり、上位のノードタイプに変更します。変更操作はマネジメントコンソールから、ノード数やノードタイプをクリックするのみです。すると、バックグラウンドで新しいクラスタが起動して、データが新たに平準化して格納され、移行が終わると新しいクラスタにスワップされる、これらの作業は全て自動的に行われます。

移行している間は参照のみとなりますが DWH は利用可能です。この手順は拡張だけでなく、縮小する場合も同様です。 Redshift は、完全なシェアードナッシング・アーキテクチャなので、クラスタの処理性能やディスク容量はノードの数に比例して、線形スケールします。

クエリの高速化

共にシェアードナッシング・アーキテクチャなので、データは、テーブルを作るときに指定した分散キーに基づいて平準化します。分散キーは結合するレコード同士が同じディスクに配置されるようなカラムを指定します。 実際にクエリを投げると、Leader Node がクエリを受け付けて、最適化したプランのC++のソースコードに変換・コンパイルして、Compute Node に配布、実行します。よって、2回目以降はコンパイル済みのオブジェクトがキャッシュされますので早くなります。 ここまではほとんど同じと言ってよいでしょう。

Netezza はインデックスがなくても性能を維持する仕組みとして、ZoneMap と FPGA によるデータフィルタがあり、ハードウェアが高速化の要となります。

Redshift にも オンメモリのZoneMap が存在し、メタデータとして最大値と最小値を管理することで、不要なブロックの読み飛ばしが可能です。テーブルを定義するときに複合ソートキー（Coｍpound Sortkey）を指定することでき、列データは1 MB のブロックにソートして格納することで、FPGA なしでも高速に動作させることができます。更に、このZoneMapの管理方式を応用して、複数のカラムをどのように組み合わせても検索条件がフェアになるようなマルチディメンショナルなソートキー（Interleaved Sortkey）を指定すると、M-OLAP のような多角的なデータ分析ができるようになります。

参考：【新機能】Amazon Redshift の Interleaved Sorting機能を試してみた

Redshift 移行の考慮

分散キーは１カラムのみ

Netezzaは、分散キーに複数カラム指定することが可能ですが、Redshift は現状１カラムのみです。なので、もし分散キーが複数設定されている場合は変更が必要です。 分散キーの選定で重要なのは、データや処理が特定のノードに集中する（ノードが HOT になる）ことを避けることと、テーブル間の結合の際に再分散によるノード間転送が発生させないこと、この２点です。 解決策としては、以下の3つの方針に従うことで回避できます。

• 一般に結合対象となる「マスタテーブル」は「分散タイプ：ALL」を指定する（全てに緻密な分散キー設計をしない）
• 非マスタテーブル間で結合する際にはコロケーションを意識して共通の分散キーを指定する（要所はしっかりと分散キー設計する）
• 分散キーは平準化するようにカーディナリティが高く、値が分散したカラム（シーケンス番号、顧客番号等）などを設定する

マテリアライズドビュー

Netezza のマテリアライズドビューは、元テーブルの更新を反映する仕組みになっている、非常な便利な機能ですが、更新を維持するコストが小さくありません。 Redshift はデータをロードしたり、アップデートしたタイミングで、マテリアライズドビューに相当するテーブルを作成して対処する方法が考えられます。利用頻度が低いのであればビューとして作成します。

冗長化

Netezza は SMP host に対して、DRBDによる冗長化の選択が可能ですが、これはオンプレ故に可用性を確保するにはこの選択肢しか無いからです。

Redshift は Leader Node に対する冗長化はありませんが、Leader Node はデータを永続化しないので、クラスタを再起動することで物理ハードが切り替わり復旧可能ですので、待機系を用意する必要がありません。更にデータに関してはスナップショットを自動取得することで、異なるデータセンタ（別のAZ）や別のリージョン（海外のリージョン）でクラスタを立ち上げ、サービス継続という選択も容易に実現可能です。

セキュリティ

Netezza はオンプレなので自社のサーバールーム内にデータソースとなるサーバー群やBIツールとともに完全に閉じ込めることができます。

一方、Redshift はデータソース、Redshift、BIツール全てがクラウド上に置くことでクラウド内に閉じ込めることができますが、利用についてはクラウドに接続する必要があります。 お客様のオフィスとクラウド間をVPNや専用回線、接続の暗号化（SSL）などで接続するすることで、セキュリティを担保していただきます。Redshift は、接続の暗号化（SSL）やデータ保存領域の暗号化は標準でサポートしています。また、データソースとなるS3に関しても暗号化やパブリック・アクセスを制限することが可能です。

最後に

クラウドサービスである Redshift の強みをまとめますと、

• 伸縮自在が可能で簡単
• コスト、アジリティ、全体での管理が可能
• データのアップロードは通信料は発生しない
• 他のAWSのサービスとのシナジー
• そして、Netezza ユーザーであれば移行のリスクやコストが小さいこと

Netezza のアーキテクチャは共感するところも多く、私自身多くのベストプラクティスを学びました。今日においてもオンプレでなければならないユースケースが存在することも理解できます。従来の DWH は、本来は OLTP とは住み分けたほうが良いはずの機能を無理やり込み、結果としてハードウェア依存がコストに転嫁されている傾向が見られます。 ビックデータの活用が本格化する中で、「DWHが大量データの管理、集計、分析に最適化されているのでその分野で活用することが効果的である」という理解を得られつつあると感じています。

Redshiftは、初期導入のハードルの低さ、アジリティ、費用対性能、AWS のサービスとのシナジーを目の当たりにすると、かなりストライクゾーンの広いDWHであることが理解できたと思います。Netezza ユーザーの皆様はぜひご検討ください。