「AWS Cloud Roadshow 2014 札幌」レポート 〜 AWSビッグデータソリューション ：Amazon Redshift、Amazon EMR、Amazon DynamoDBご紹介 [TC-03]　#AWSRoadshow

こんにちは、石川です。 「AWSビッグデータソリューション ：Amazon Redshift、Amazon EMR、 Amazon DynamoDBご紹介」というテーマで、Black Belt Tech WebinarやビックデータソリューションでおなじみのADSJの今井 雄太さんのセッションについてレポートします。

※資料は別途、公開されると聞いております。公開されましたらリンクを追加するようにします。

概要

AWS にはビッグデータを扱うための様々な便利なサービスや機能がそろっています。今回はその中でも Amazon Redshift、Amazon EMR、Amazon DynamoDB に焦点を絞り、ユースケースや事例、試してみるための具体的な第一歩をご紹介したいと思います。

「AWS のビッグデータサービスで何ができるのか知りたい」、「手元にデータはあるけれど、何をどこから活用しはじめたらいいのか」というお悩みをお持ちの方はぜひこのセッションにおいでください。 このセッションでは、AWSビックデータサービス群、解剖ビックデータ、Getting Started with Big Data Services、プラクティカル・ディープダイブなどを通じてビックデータの流れとAWSのビックデータサービスについて紹介しています。

AWS関連サービスとビックデータサービス群

AWSサービスの全体で40ちょっと位あり、すべてのサービスに精通しているとは言いがたい状況です。 非常に多岐にわたるサービスの中でビックデータ関連サービスは以下の通りです。

S3

歴史の長いサービスで、データの容量制限がなく、３箇所で保存されるためデータの耐久性がとても高い特長があります。

Glacier

S3と耐久性は同じですが、より低価格で低速なサービスです。

DynamoDB

NoSQL as a Service。詳細は以降でご紹介します。

Redshift

AWSが提供するマネージド型のデータウェアハウスです。詳細は以降でご紹介します。

RDS

AWSが提供するマネージド型のリレーショナルデータベースでMySQL、Oracle、PostgreSQLを提供している。

Elastic Map Reduce (EMR)

AWSが提供するマネージド型のHadoopを提供します。詳細は以降でご紹介します。

Kinesis

ストリームコンピューティングを実現するためのサービス。Hadoopがバッチ処理でMapReduceを実現するフレームワークであるのに対して、KinesisはストリームMapReduce、リアルタイムにMapReduceを実現するフレームワークです。

AWS Data Pipeline

スキップ（later）詳細は以降でご紹介します。

今回は上記のうち、Redshift、DynamoDB、Elastic Map Reduce (EMR)の３つに焦点を絞ってお話します。 これらのサービスをどう役割分担させたり、組み合わせたりして、ログの集計や解析をしていくのかというところにフォーカスを当てて説明します。

解剖ビックデータ

ビックデータ活用の４ステップ

第１段階：集める

データはどこで生まれるかというと、アプリケーションサーバー、Webサーバー、モバイルクライアント、IoTと呼ばれるデバイス類から大量のデータが非常に速い速度で生まれるようになっています。これらのデータをいかに集めるのかというのが第一段階となります。

第２段階：ためる

大量のデータを安全でかつコスト効率よく、使いやすい形でデータ保存します。

第３段階：処理する

処理するということははぼんやりしていますが、よくETLという言葉を聞かれると思いますが必要となるデータのみを抽出したり、：逆に不要なデータを除外したり、必要な形式に整形したり、いわゆるデータの利用ファイルの前処理です。データの一次集計もこの段階に作成します。

第４段階：使う

TableauといったBIツールによってデータをレポートとして可視化したり、データ販売ビジネスのデータそのものを提供できるAPIとして提供したり、たくさん使い方が考えられます。

以降、先ほどのご紹介したビックデータサービスをデータ活用のステップに当てはめると

DMP：データマネジメントプラットフォーム

データソースは、Webサーバーやモバイルクライアントをはじめ、IoTといったセンサーデバイスからの入力を想像してください。そして、そのデータの保存は基本的にS3が第一の検討候補になります。これをEMRを使ってETL（必要なデータを抽出、不要データの除外、一次集計）して、その結果をDynamoDBに保存します。保存したデータをWebAPIとして提供するといった、データ活用ビジネスとして注目を集めるデータマネジメントプラットフォーム（DMP）ではこのような構成を取るケースが多くあります。以下データの流れです。

S3にデータを貯める　>>　EMRでETL　>>　DynamoDBに保存　>>　Web app

Analytics：集計

DMPと同様にEMRでETLした結果をRedshiftに格納するとどうのような活用ができるかというと、柔軟で高速なアナリティクス(集計)です。ECサイトの売れ行き、広告配信の結果の集計、ウェブサイトのページビュー、トラフィックのレポートティングなどRedshiftにテータを格納しておくとSQLによる集計、可視化というが容易にできます。以下データの流れです。

S3にデータを貯める　>>　EMRでETL　>>　Redshiftに保存　>>　Analytics

Dashboard

HadoopではETLするだけではなくHiveを使った集計も可能で、集計の結果を容量の小さいRDSに格納してレポートのダッシュボードとして使うことが考えられます。

S3にデータを貯める　>>　EMRでSum(集計)　>>　RDSに保存　>>　Dashboard

Data Pipeline

１時間に１回データをEMRでETLしてRedshiftやRDSに入れるといったデータ移動に伴うバッチ処理を管理してくれます。

Glacier

あまり参照されなくなった古いデータはより安価でより低速なGlacierに格納します。

Kinesis

一時間に一回ではなく、よりリアルタイムにした場合にデータの入り口にKinesisを導入することで後ろの処理にリアルタイム性を持たせることができる。

集める〜ためる〜処理する〜使うの４つのステップのまとめ

集める：データを集めてS3にアップロードするまで ためる：S3にためる 処理する：EMRを使ってETLをしてETL後データをS3に入れる処理をする 使う：Tableauを使う場合、Redshiftの前段に置きRedshiftのクエリーを投げてその結果をTableau側で可視化する

例１．バッチ処理によるアクセスログデータの活用

一般に多数のWebサーバーから上がってログをFlentdに代表されるリアルタイムにコレクションできるログコレクタを使ってS3に集約していきます。EMRで不要なカラムやロボットからのアクセスを除外したりします。ETLした処理済みデータをS3に保存し、Redshift にCOPYして、TableauといったBIツールや自前のダッシュボード等でデータの可視化やレポートを出すといった構成がよくあるデータの集計手法となります。以下、データの流れです。

Webサーバー（fluentdなどで）　>>　ログ集計サーバー　>>　S3（オリジナル）　>>　EMR／ETL　>>　S3（処理済み）　>>　Redshift（ETL済みデータ）　>>　BIツール（例．Tableau）

例２．DMP（データマネジメントプラットフォーム）

ユーザーのアクセスログや一覧といった、誰々がある日時に何々しましたといったデータを元に興味分析をしてデータとして提供する。 ログ集計までは例１と一緒です。あるユーザの属性情報をEMRで計算して、あるユーザは何々が好きっぽいといった結果をDynamoDBに格納します。最終的にDynamoDBの情報をAPI経由して情報を提供する。以下、データの流れです。

Webサーバー（fluentdなどで）　>>　ログ集計サーバー　>>　S3（オリジナル）　>>　EMR／ETL　>>　DynamoDB　>>　データをAPIで提供

Getting Started with Big Data Services

それぞれの中身、はじめ方について各サービスの紹介をします。

Redshift

RedshiftのアーキテクチャはMPP(超並列演算)、データの格納は列指向、通信方式などに特徴があります。

超並列

コンピュートノードというノードが並んでいて、それぞれのコンピュートノードの中にデータが格納されています。非常に大きな特徴としてJDBC/ODBCがありますがPostgreSQL互換のインタフェースになっていますので新しいことを覚える必要がなく、10台のRedshiftのクラスタをデプロイするとあとは、psqlでログインしてSQLを投げれば巨大なデータの集計や統計を容易に取ることができます。

列指向

従来のOracleやMySQL、PostgreSQLは「行指向」と呼ばれデータが一行一行ディスクに格納されていますので、この行をロックして更新をかけるのは得意ですが、特定の列を取り出して集計するという動作が得意なのが「列指向」ストレージとなります。列指向のデータベースは列ごとにデータがディスクに書かれています。それぞれの列が上から数えた順番だけをお互いに保持している仕組みのストレージです。

リーダーノード（勝手に補足）

リーダーノードはコンピュートノードとクライアントアプリケーションの間に位置しますので、psql(クライアント)はリーダーノードを経由してクエリーをコンピュートノードで実行します。実行計画のコンパイルと配布、複数のコンピュートノードから結果の集計してクライアントに返します。

コンピュートノード

４種類(dw1.xlarge、dw1.8xlarge、dw2.large、dw2.8xlarge)で、その中でもdw2.largeというのが最初に試すのに最適なノードで、ストレージもSSDなのでディスクアクセスも早く、容量も160GBあるので簡単に始められます。現状の価格(2014年11月現在)は一年間動かし続けても年間約15万程度から始められます。一番小さい構成ではコンピュートノード一台から始めることができます。複数ノードは最大32や100ノードなど、必要な容量や性能に応じて増減することが可能です。なので将来必要となる容量を確保する必要がなく、必要に応じてスケールアップすることができます。

Redshiftの利用イメージ

接続はpsqlでログインできます。SQLでテーブルを作成後に、COPY文を利用してS3上のファイルからRedshiftにデータをインポートします。データが入るとあとは普通のSQLでGROUP BYを実行するのみで集計できます。 逆にSELECTを指定してUNLOAD文を実行することで必要なデータをS3にエクスポートする事もできますので外部とのデータ連携も容易にできるようになっています。

Redshiftのまとめ

• 大量のデータをSQLで高速に処理することができる
• データ量が増えても性能が落ちにくい
• SQLで操作ができるのでレポートツールやデータの可視化に最適

EMR：Elastic Map Reduce

EMRはHadoopを使っている人が前提となりますのでRedshiftと比較してハードルが高いです。例えば、6台のEC2でHadoopのクラスタを構築しろと、コマンドを発行すると6台のEC2がデプロイされてHadoopがインストールされて使えるようになります。 ユーザーとのインタフェースはここのHadoopになりますので特に新しいことを覚える必要はなく、普通のHadoopとして利用することが可能です。

ワークフローマネジメント

スクリプトでHadoopのクラスタ起動ができます。(aws emr create-cluster ...) 仕事をあらかじめ定義してクラスタを起動し、終わったら自動的にクラスタ削除（Hiveのクエリーを指定）ができます。Hiveのアプリケーションの名前やHiveのクエリが書いてるるファイルのS3のパスやAutoTerminateを指定します。 例えば、cronやDataPipelineでワークフローを実行するようにスケジュールすることによって非常にクラウドらしい使い方をすることができます。

S3／DynamoDBとの連携

Hiveを例に解説すると、"CREATE EXTERNAL TABLE" 文でS3のURLスキームを指定することでS3にあるデータをこのようなスキーマを持ったテーブルとして直接扱うことができる。S3にデータを上げただけでEMRからHiveの文で集計をすることができます。 また、Hiveを使ってETLする方法として、例えばTable1、Table2とそれぞれS3のデータがあるとして、"INSERT INTO SELECT"でTable1からカラム３と４を除外してTable2をつくるというクエリを投げるとTable2のS3のデータが作成されます。 同等にDynamoDBのテーブルもマウントできますので、Hiveを経由してDynamoDBのテーブルをS3にバックアップするということもできます。

Redshift以外にHive(EMR)でも集計ができますがどっちを使えばよい？

見ていただいたとおりHiveのためにEMRを使うお客様も多くいます。Redshiftの基本的な使い方はRDBで、正規化を必要する前提条件がありますがそれ故にJOINやSQLで解析することに最適化されたサービスです。一方Hive(EMR)はあくまでHadoopです。SQLライクなインタフェースはありますがMapReduceというフレームワークに基づいたコンパイルしてHadoopの処理として動作しますのでSQLに最適化されているわけではないので、SQLに最適化された分析・解析はRedshiftの方が圧倒的に早い場合が多い。逆に機械学習やETL、その他に関してはEMR(Hadoop)を使うのがいいよ考えます。

EMRの利用

まずは一次集計で利用することから考える。

DynamoDB

３つ特長

• S3と同様にデータは３箇所以上で保管されるため、管理不要で信頼性が高い
• その上で必要なだけのスループットを設定できるプロビジョンドスループット
• ストレージの容量制限がなく、ディスクやノードの追加が不要

構成要素

オペレーションはHTTPベースのAPIで提供されているので、全てのサービスがAPI呼び出しによってPUTやGETをします。逆の言い方をするとサーバーのデプロイなしにコードを書くだけで利用できます。

プライマリーキー

プライマリーキーは２種類の組み合わせ HashKey MemCachedやRedisのようなKVSのような使い方をする。ある人の情報が欲しい場合に予め知っているユーザーIDからに対応する情報を取得する。 Hash and Range Key コンポジットキーのようなプライマリキーを持つことができる。よくユーザーの行動履歴の管理に使われます。ユーザのIDがハッシュキーであることは変わらない。その下にタイムスタンプなどをレンジキーとする場合が多い。そうするとあるユーザーのある機関のデータを纏めて取得することができます。 最近では、Local Secondaly IndexやGlobaSecondaly Indexという便利な機能があり、ある程度クエリの柔軟性がありますが、一番性能を出すためにはある程度制約の中で利用していただく必要があります。

特長

大量のデータを格納しておいて、その中から必要な小数のデータを高速にやりとりするのみ最適化されています。逆にデータを一定期間大量にスキャンして集計したいといった目的にはDynamoDBには不得意です。

プラクティカル・ディープダイブ

データ処理をする上でS3が重要です。これまでの下記関系のお話もS3に大本のデータさえ入れておけば必要なときにHadoopから取り出して処理する、DynamoDBから取り出して処理する、Redshiftにロードして処理するということができます。

S3とEMR

オンプレのHadoopの場合、事前にキャパシティプランニングをしてリソースが溢れないように運用する必要がありますがS3に保存しておくと、共有のストレージとしてジョブごとにHadoopのクラスタを分けて並列で処理することができます。

S3とRedshift

S3に対してCOPY/UNLOADでインポートやエクスポートができます。あまり参照しない古いデータはGlacierに安価に保存する事ができます。S3にスナップショットを保存することができ、スナップショットからデータを復旧する事ができます。

S3とDynamoDB

Hiveを経由したS3へのバックアップ、更に古いデータはGlacierに保存する。

S3を使ったバッチ処理

オリジナルのデータからEMRでETLの処理をしてその結果を結果をS3にチェックポイントとして保存します。ステップごとにS3に保存しておくと、例えば途中の処理が失敗した場合にチョックポイントに置いたデータから処理を再開するということができます。

リアルタイム性の導入

レポートとDMPのアーキテクチャです。バッチ処理はデータが常に流れていたとしても集計のタイミングは15分や1時間おきで処理するというのがバッチ処理のこれまでの考え方だったと思います。ここのログ集約サーバーのところにKinesisを経由することで、全く同じデータを全く同じ順番で複数にコピーすることができます。S3にはこれまで通りに流しつつ、更にレポートの速報値のためのデータを横から取り出して、精度は100%ではないけれどもほぼリアルタイムのための速報値のためのデータを分岐させることができます。バッチ処理はこれまで通り行いつつ、分岐させてリアルタイムな処理を加えることをラムダアーキテクチャと呼びます。

各サービスの役割

集める〜ためる〜処理する〜使うは、サービスごとに必要なフェーズに必要なサービスは異なりますので、自分がどのソリューションを必要としているのかというのを見極めてサービスをお選びください。 （どこかから） 集める サーバ モバイル （どのくらい） 貯める S3、DynamoDB、RDS （どういう） 処理 EMR、EC2 （どうやって） つかう　Redshift、DynammoDB、RDS