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

aws-reinvent2015

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

IMG_0100

イントロ

  • ビッグデータは件数、ベロシティ、多様性などと絡めて年々規模を増している。
  • ビッグデータの改革
    • バッチ→リアルタイム→予測(prediction)
    • レポート→アラート→予報(forecast)
    • 多過ぎるツール群...これらはリファレンスアーキテクチャなのか?何を使うべきなのか?それを使う理由は?どのように使えば良いのか?
    • IMG_0106
  • アーキテクチャの原則
    • "データバス(data bus)"を分離:データ/蓄積/処理/回答
    • ジョブに合った適切なツールを使う
    • Lambdaアーキテクチャのアイデアを使う
    • AWSマネージドサービスの活用
    • ビッグデータ≠コストがかかる

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

IMG_0112

収集・摂取

IMG_0119

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

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

IMG_0140

ファイルストレージ

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

IMG_0143

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

Database + Search Tier

IMG_0150

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

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

IMG_0159

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

IMG_0161

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

IMG_0165

処理・分析

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

  • 例:
    • インタラクティブなダッシュボード:インタラクティブ分析
    • 日次/週次/月次レポート:バッチ分析
    • ビリングアラート、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

IMG_0185

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

IMG_0186
IMG_0190

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

IMG_0193

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

IMG_0199

IMG_0200

デザインパターン

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

Multi-Stage Decoupled "Data Bus"

IMG_0203

Multiple Processing Applications(or Connectors) IMG_0205

Real-Time Analytics

IMG_0218

Interactive & Batch Analytics

IMG_0226

Lambda Archtecture

IMG_0234

さいごに

IMG_0238

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