Amazon Web Services（AWS）は次々と新しいサービスを世の中に出して、クラウド・コンピューティングの可能性を広げていっています。そのAWSから登場した最新のサービスであるAmazon Redshiftは、そのパフォーマンスや驚異的な低コストのため、発表当時から大変な反響を呼んできました。
この連載では、 Redshiftの概要からその利用方法まで、主にあまりデータウェアハウスを利用した経験がないWeb開発エンジニアなど向けに、このビッグデータ向けクラウド・データウェアハウス製品であるAmazon Redshiftの解説をして行きたいと思います。
まずは、そもそもAmazon Redshiftとは何なのか、その概要から説明します。
Amazon Redshiftはビッグデータ時代のクラウド・データウェアハウス
2012年11月、AWSにとって初めての世界的なユーザカンファレンスであるre:Invent が開催されましたが、そこで目玉として発表されたのが、この Amazon Redshiftです。この製品はデータウェアハウスでありながら、従来の製品よりもテラバイトあたりの価格が10分の1以下であり、さらにクラウド上に構築されるためメンテナンスコストなどの追加費用が必要ないとあって、大変注目を集めました。加えて、最低2TBから最大1.6PBまでスケールでき、通常のPostgreSQL用ドライバやJDBC/ODBCで接続することができるので、既存の資産を利用することも可能とのことで、ビッグデータ関係者が色めきたったものです。
ただし、一般公開がまだ先ということもあって、その時点ではニュースとしては大きく取り上げられましたが、まだ全貌が見えていなかったことは確かです。
その後、2013年2月に一般に公開された後、少しずつその内容が明らかになって来ました。実は、筆者が所属するHapyrus では、一般公開前にAmazonのRedshiftチームと共同で、プレビューベータの製品を検証していたので、公開と同時にいくつかのベンチマーク を公開しました。また、AirBnBというシェアハウスの時間貸しビジネスで大きくなった会社のエンジニアも、同じビッグデータテクノロジーであるHadoopのSQLコンポーネントであるHiveとの比較ブログ を公開するなど、いくつかの記事をネット上で見ることができます。
Amazon Redshiftの特徴
このように断片的な情報はニュースなどで伝わっていますが、そもそもデータウェアハウスとはどのようなシステムなのでしょうか。
データウェアハウスとは、一般的には大量のデータを主に追記の形で蓄積し、時系列などで分析を行うことでビジネスの状態などを把握し、経営を改善したり（Business Intelligence：BI） 、システムの効率化用のデータを取得したりします。その性質上、レコードの更新や削除はほとんど行われません。主に分析用の計算（OLAP）を行い、専用のハードウェア（アプライアンス）や特殊なソフトウェアとして提供されることが多いので、価格は一般的に高価になります。このようなデータウェアハウス製品としては、TeradataやIBM Netezza、HP Verticaなどがあります。最近のそれらの製品に共通して導入されているいくつかの機能があるのですが、Amazon Redshiftにもそのほとんどの主要な機能が搭載されています。
Amazon Redshiftの大きな特徴は、これらのデータウェアハウスと比べて、年額の費用が10倍から多い時には1000倍も低くできることです。たとえばデータウェアハウスを導入するときは数TBの容量でも億単位の金額が必要な場合もありますが、Amazon Redshiftは最低金額が年に$2,000から利用できます（3年リザーブド・インスタンスで2TBストレージの場合） 。
機能スペック的にはそれほど違いがなく、唯一の大きな違いはクラウド上にあるかどうか 、ということです。つまり、すでにクラウド環境を利用している企業でデータウェアハウス導入を検討する場合、Amazon Redshiftは最初の選択肢になるでしょう。もしクラウドを使っていない場合でも、このためにクラウド環境を検討する価値があるかもしれません。
Redshiftの主な機能は、以下のようなものです。
カラムナー（列指向）データベース
カラム種別ごとの豊富な圧縮エンコード
MPP（Massively Parallel Processing）
簡単にインスタンス追加
順番に見て行きましょう。
カラムナーデータベース
データウェアハウスは主にSQLを用いて大規模なデータに対する集計処理を行うので、カラムに対する集計関数（合計や平均など）の実行が基本になります。そこで、カラムごとにデータをブロック化するという手法が有効だということで、このカラムナー（列指向）データベースというものが生まれました。逆に、通常のデータベースは行指向データベースとも呼ばれ、ランダムアクセス（ある特定の行を取得する）に向いています。
図1 カラムナーデータベースと行指向データベースさらに、同じカラムは同じデータの繰り返しが多く起こりやすいので、圧縮が効きやすく、より少ない容量で大きなデータを表すことができます。たとえば、AAAABBCCCAABという12文字のデータは、（ 順番を無視すると）A6B3C3という6文字のデータに置き換えられるわけです。同じ種類のデータが多い（カーディナリティが低いとも言います）と、より圧縮効率が良いというわけです。圧縮効率が良いと何が良いかというと、データを小さくすることができるためデータベース処理スピードの一番のボトルネックである、ディスクからの入出力を減らすことができます。さらにメモリに乗せることもできる可能性も上がり、パフォーマンスに大きな影響を与えます。
このように、カラムナーデータベースは、特に大きなデータの集計処理には優れたパフォーマンスを発揮するのです。
豊富な圧縮エンコード種別
Amazon Redshiftは9種類の圧縮エンコーディングに対応しています（2013/4/4現在） 。たとえば、Byte dictionaryやDelta、Mostlynなどと呼ばれるものです。
それぞれ独自のアルゴリズムがありますが、どれを適用するのが一番良いかは、全体のデータの内容に依存するため、判断するのが難しいでしょう。そのため、RedshiftにはCOPYコマンドという、バッチインポート用のコマンドを初回に実行した時や、その時点で格納されているデータを元にANALYZEコマンドを実行した時に、一番有効なエンコーディングを自動で決定してくれる機能があります。
MPP（Massively Parallel Processing）
通常のデータベースの場合、クラスタ化しスケールさせた場合でもシェアード・ナッシング（リソースを共有しないことにより線形スケールを可能にするアーキテクチャ）にならないので、台数を増やすごとに性能を向上させるのは難しいといわれています。
RedshiftはこのMPPという機構を用いてシェアード・ナッシングを実現し、線形スケールを実現しています。つまり、インスタンスを追加するたびにデータ容量だけでなく、処理性能も向上していくということになります。これは、次回比較するHadoopなどと同じ構造であり、ビッグデータ処理の上では必須の機能と言えるでしょう。
Redshift内部では、Leader Node（SQLドライバなどが接続するインターフェースを担うノード）とCompute Node（スケールする、実際に計算・データ保持するノード）に分かれていて、適切にデータを保持したり、クエリ処理を分散させたりという仕組みが内部的に動いています。この中身はブラックボックスになっていて、基本的にAmazonが管理しているので、ユーザは気にする必要がありません。Hadoopとよく似ていますが、誰が管理するか、というところが大きな違いだと思います（Hadoopクラスタの管理は大変です…） 。
簡単にインスタンス追加
ハードウェア・アプライアンスはもとより、通常のデータウェアハウス・ソフトウェア製品であっても、データ容量が足りなくなったり、思ったようなパフォーマンスが出なくなったりするときにインスタンスを追加するという選択肢がありますが、実際にそうするのは大変です。追加には多額の費用と1ヵ月くらいの日数は必要でしょう。Amazon Redshiftはほんの数クリックで、自由にインスタンスを追加することができます。
このように、豊富な機能をもつAmazon Redshiftですが、それでは具体的なメリットやデメリットにはどのようなものがあるのか、またHadoopやNoSQLデータベースなど既存のビッグデータ技術の利用法と比較して、どのような違いがあるのかを次回で見て行きたいと思います。
筆者が所属する Hapyrus では、Amazon Redshift を使いはじめるための継続データインテグレーションサービスFlyData for Amazon Redshift を提供しています。また、Amazon Redshift の導入コンサルティングも無料で行なっていますので、興味がある方はぜひお気軽に info@hapyrus.com にお問い合わせください。
