(レポート) BDT310: AWSでのビッグデータのアーキテクチャパターンおよびベストプラクティス #reinvent

AWS re:Invent 2015では今年も様々な新機能・新サービスが目白押しとなっております。発表と同時にそれら新リリースとなったテーマのセッションも急遽開催され、そのセッションに非常に多くの参加者が列を成すという光景も会期中頻繁に見られました。私個人としては当イベント期間中はAmazon Redshift／ビッグデータ／ETLといったテーマに関するセッションをピックアップして参加していました。当エントリではその中からビッグデータのアーキテクチャパターンとベストプラクティスについて解説がなされたセッションについてレポートしたいと思います。

イントロ

• ビッグデータは件数、ベロシティ、多様性などと絡めて年々規模を増している。
• ビッグデータの改革
  • バッチ→リアルタイム→予測(prediction)
  • レポート→アラート→予報(forecast)
  • 多過ぎるツール群...これらはリファレンスアーキテクチャなのか？何を使うべきなのか？それを使う理由は？どのように使えば良いのか？
  • 

• アーキテクチャの原則
  • "データバス(data bus)"を分離：データ／蓄積／処理／回答
  • ジョブに合った適切なツールを使う
  • Lambdaアーキテクチャのアイデアを使う
  • AWSマネージドサービスの活用
  • ビッグデータ≠コストがかかる

ビッグデータ処理の簡略化

収集・摂取

• データタイプによる採用アーキテクチャの選択
  • トランザクション：データベースの読み書き、キャッシュ
  • 検索：ログ、ストリーム
  • ファイル：ログファイル、ログ収集フレームワーク
  • ストリーム：ログレコード、センサー&IoTデータ

• ストリームストレージの選択肢
  • AWSマネージドなサービス
    • Amazon Kinesis(Streams)
    • DynamoDB Streams(table + steams)
    • Amazon SQS(キュー)
    • Amazon SNS(pub/sub)
  • 上記以外(非マネージド)
    • Apache Kafka(stream)

• なぜストリームストレージなのか？
  • プロデューサーとコンシューマーを分離出来る
  • 永続化バッファ
  • 複数のストリームを収集
  • クライアント順序を予約
  • ストリーミングMapReduce
  • 並列実行

• Queues & Pub/Subについて
• プロデューサーとコンシューマ/サブスクライバの分離
• 永続化バッファ
• 複数のstreamsを収集
• 以下のものは無い／保障されない
• クライアント順序
• Amazon SQSの並列実行
• ストリーミングMapReduce

どのストリームストレージを使うべきか？

ファイルストレージ

なぜAmazon S3がビッグデータに向いているのか？

• HDFSとAmazon Glacierはどうか？
• ホットな(アクセスがとても頻繁にある)データにはHDFSを使う
• 頻繁なアクセスのあるデータにはAmazon S3(標準)を使う
• 頻繁ではないアクセスの場合であればAmazon S3 Standard - IAを使う
• ColdデータにはAmazon Glacierを使う

Database + Search Tier

ベストプラクティス：ジョブに適したツールを使うこと。 どのデータストアを使うべきか？ + データ構造：スキーマで定義/JSON/Key-Value値 + アクセスパターン：アクセスするデータの格納形式 + データ：アクセス頻度の差 - hot/warm/cold + コスト：適正なコストか否か

アクセスパターンによるツール選定

データアクセス頻度の違いによる見極め

どのデータストアを使うべきか？

処理・分析

データの分析はデータの検査、整形、変換、有用な情報を見つけるためのゴールとなるデータモデリング、結論の提案、意思決定のサポート等など広範に及ぶ。

• 例：
• インタラクティブなダッシュボード：インタラクティブ分析
• 日次/週次/月次レポート：バッチ分析
• ビリングアラート、1分毎のメトリクス：リアルタイム分析
• センチメント分析、予測モデル：機械学習

インタラクティブ分析：

大量の(warm/cold)データを扱う、回答を得るサイクルは秒単位で。

例).セルフサービスダッシュボード

バッチ分析：

大量の(warm/cold)データを扱う、回答を得るサイクルは分単位〜時間単位。

例).日次、週次、月次等のレポート生成

リアルタイム分析：

少量の(hotな)データを扱い、質問する、回答を得るサイクルはミリ秒〜秒単位。

リアルタイム(イベント)：データストリーム内でイベントに対しリアルタイムで回答。例).ビリングアラート

ニアリアルタイム(マイクロバッチ)：データストリーム内で小さなバッチイベントに対するニアリアルタイムな操作。例).1分毎のメトリクス

MLを使うと、コンピュータで(明確な)プログラミングを行わずに学習をさせる事が出来る。

機械学習アルゴリズム：

教師あり学習(プログラムに"教える")：分類、回帰

教師なし学習(自分自身で学ぶ)：クラスタリング

分析ツールとフレームワーク

• 機械学習
• Mahout, Spark ML, Amazon ML
• インタラクティブ分析
• Amazon Redshift, Presto, Impala, Spark
• バッチ処理
• MapReduce, Hive, Pig,
• ストリーム処理
• マイクロバッチ：Spark Streaming, KCL, Hive, Pig
• リアルタイム：Storm, AWS Lambda, KCL

どのストリーム処理の技術を使うべきか？

ETLについても、AWS Data Pipelineや各種ETLツール、

また、ETLツールの位置付けに関する解説などもなされていました。

デザインパターン

データを扱う上でのデータフロー、データパイプラインを語る上で有用となる『デザインパターン』についても解説がなされていました。

Multi-Stage Decoupled "Data Bus"

Multiple Processing Applications(or Connectors)

Real-Time Analytics

Interactive & Batch Analytics

Lambda Archtecture

さいごに

当セッションの内容はタイトルが示す通り、全般的な・広範な部分をカバーする内容となっていましたがそのテーマの個々が非常に整理整頓されており、とても参考になる指針が沢山あって勉強になりました。お客様のデータにまつわる環境はそれこそ千差万別、一括りで『この場合はこう』とも言い切れない部分があるはずです。そんな時にこのセッションの情報を有効活用してお客様の環境に於けるビッグデータ業務の推進に一役立てると嬉しいですね。以上、現地ラスベガスからお送りました。