クラウド上に効率的な ビッグデータ処理基盤を構築するには？ · 保存 分析 Amazon Glacier Amazon S3 Amazon DynamoDB Amazon RDS/ Aurora...

1 © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾン ウェブ サービス ジャパン

ソリューションアーキテクト 下佐粉 昭

2016年6月3日

クラウド上に効率的な

ビッグデータ処理基盤を構築するには？~データ特性に応じたシステム設計~

2

TwitterでAWS Summitに参加しよう!

公式アカウント@awscloud_jpをフォローしたお客様に

フリクションボールペンをプレゼント！

【配布場所】ロビーや展示会場のコンパニオンが配布中！お気軽にお声かけください。

3

コレクター

KinesisProducer

ストリームデータ

KinesisStream

Lambda

KinesisConsumer

AWSIoT

IoTDevice

本セッションの範囲ビッグデータ処理基盤：２つの領域

• 一旦ディスクに保存（着地）してからの処理

• バッチ、マイクロバッチ

• Hadoop, Data Warehouse ..

• リアルタイム処理

• ストリーミング処理

本セッションで扱う内容

4

ビッグデータ処理基盤 on クラウド：変わらないこと

• データを収集して、分析し、可視化

• 分析では、標準的な技術・OSSや商用ソフトウェアを活用

• AWSのマネージドサービスを活用することでより便利に

収集 分析 可視化

データを収集 大規模データを高速に分析

人間が参照しやすい形に

5

クラウド＋ビッグデータ：３つのポイント

#1. 全てを叶える万能ツールは存在しない

#2. データは加工せず全期間を残す

#3. スケールアウトで解決する

CLOUD BIG DATA+

6

#1. 全てを叶える万能ツールは存在しない

例）自由検索＆レポート

• レスポンス：数秒~数分

• データサイズ：直近13ヶ月（ホットデータ）

• 技術：高速RDB、BIツール

例）長期的なビジネストレンド分析

• レスポンス：数十分~数時間

• データサイズ：全期間データ（10年間）

• 技術：スループット重視、Hadoop

ONE SIZE

DOES NOT

FIT ALL

photo credit; marissa anderson

https://goo.gl/FTAU81

7

必要な技術を必要なところへ配置する

基準：サイズ、レイテンシー、アクセス頻度、コスト …

物理構築の負荷から開放され、何をどう使うかにフォーカス

収集 分析 可視化自由検索

分析 可視化全期間分析

8

これまで：

1. ディスクが高価で上限がある

2. データはサマリーだけ、もしくは期間限定で保存

3. 処理できる内容は固定的

#2. データは加工せず全期間を残す

On クラウド：

1. 安価・上限無しのストレージ

2. オリジナルデータを全て残す

3. 処理対象・処理内容はビジネスに合わせて変わる

インフラ管理者の仕事：データを活用して新しい課題に素早く対応できるインフラを用意する。個別リクエストへの対応

インフラ管理者の仕事：ストレージを溢れさせず、時間内に処理が終るようにサイズや処理内容を調整する

9

データレイク

• 多様なデータを一元的に保存

• データを失わない

• サイズ制限からの開放

• 決められた方法（API）ですぐにアクセスできる

→システム全体のハブ

センターデータ

非構造化ファイルテキストファイル

RDBMS

データレイク

API呼び出しによる連携

10

• 適切な技術を選択する (#1)

• データを消さずにデータレイクに集め、分析につなげる(#2)

大規模データ分析に必要な基盤

収集 データレイク

（保存）

分析 可視化

データを収集し、データレイクへ格納

全期間保存。共通APIでアクセス

ニーズ #1

分析 可視化ニーズ #2

AP

I

11

#3. スケールアウトで解決する

スケールアップもスケールアウトもクラウドでは容易

…しかしスケールアップには限界がある（CPU、メモリ）

スケールアウト可能なテクノロジー

＝規模の増加に耐えうる設計

S

XL

スケールアップ

スケールアウト

12

スケールアウト ≠ 高価

クラウドではスケールアウトがコスト・時間の両面で効率的

• 必要な時に必要なだけノードを追加できる

• ノードを増やしても利用時間が短くなればコストは同じ

処理時間

8時間 処理時間

2時間

JOB

16ノードに拡張

JOB

4ノード×8時間＝32

16ノード×2時間＝32

13

• 適切な分析技術を選択する (#1)

• データをデータレイクに集め、多様な分析につなげる(#2)

• 分析はスケールアウト可能なインフラの上で(#3)

大規模データ分析 on クラウド（ここまでのまとめ）

収集 データレイク

（保存）

分析 可視化

データを収集し、データレイクへ格納

全期間保存。共通APIでアクセス

可視化

スケールアウト可能な技術

分析スケールアウト

可能な技術A

PI

14

AWS＋ビッグデータ分析基盤

15

EC2があれば何でも出来るけど…

マネージドサービスで管理負荷を低減可能

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

オンプレミス 独自構築 on EC2 AWSマネージドサービス

お客様がご担当する作業 AWSが提供するマネージド機能

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

16

分析保存

Amazon

Glacier

AmazonS3

Amazon

DynamoDB

Amazon RDS/

Aurora

AWSマネージドサービス：ビッグデータ

AWS Data

Pipeline

Amazon

CloudSearch

Amazon EMR

Amazon EC2

Amazon

Redshift

Amazon

Machine

Learning

AWS IoT

AWS Direct

Connect

収集

Amazon Kinesis

Amazon

Kinesis

Firehose

Amazon

Elasticsearch

Amazon

Kinesis

Analytics

Amazon

QuickSight

AWS DMS

(近日公開)

(近日公開)

Snowball

可視化

Amazon EC2

17

例）オンプレミスのデータをAWSで分析する• データ・ソースがオンプレミスのDC内に複数

• 多種多様なシステムからEXPORTしたデータをAWSへ転送（定期的）

• １０年間以上のデータを保存して分析できるようにしたい（例：数１００TB～）

• 多くの利用者は直近１年間のデータしか分析しない（例：数１０TB）

収集 データレイク

分析 可視化

EXP ？ ？ ？ ？

18

経路と帯域

経路によって帯域・安定性が異なる

• インターネット経由

• Direct Connect（専用線）

• Import/Export Snowball

帯域を活かすには、並列化が有効

オンプレミスDC

orders1.csv

1,pencil,100,15-06-01

2,eraser,50,15-06-02

…

・・・

ordersN.csv

30,pen,150,15-06-28

31,book,50,15-06-29

…

• 差分・圧縮• 並列転送

DX（専用線）

インターネット

VPN

OR

プロトコルの選択

19

データ転送方法の検討ポイント

• 送信データを小さくする

• 圧縮、差分

• 帯域を使い切れていない場合は、並列化が最重要

• 転送先がS3の場合、aws s3コマンドを使うと、自動的に分割して転送される

• 帯域の安定性が問題の場合はプロトコルを専用のものに• 高速ファイル転送に最適化されたプロトコルやツールが開発

されている。商用ソフトウエアや、Tsunami UDP（OSS）等

• http://tsunami-udp.sourceforge.net/

• １ファイル当たりの転送においてscp等より速度が出やすい

20

Amazon S3

データ分析

Elastic MapReduce

Redshift

データバックアップ

EC2 RDS

Storage Gateway

EBS

Redshift

コンテンツ配信

CloudFront

データアクセスGW

Storage Gateway

コンテンツトランスコード

Elastic Transcoder

データアーカイブ

Glacier

データ交換

Data Pipeline

AWSのデータレイク＝Amazon S3

21

S3によるデータレイク実現のメリット

• 上限無し：サイジング不要

• 高い耐久性：99.999999999%

• 安価な費用：

• $0.033/GB/月*（スタンダード）

• $0.019/GB/月*（標準-低頻度アクセス）

例）10TBの保存で約2.1万円/月**

• APIアクセス

• 多様な言語にライブラリを提供

• AWS各種サービスと連携

データレイク

Amazon

EMR（Hadoop）

Amazon

Redshift

Amazon

API

Gateway

Amazon

S3

センターデータ 非構造化ファイルテキストファイル

RDBMS

* 費用は2016年6月時点での東京リージョンでの価格です** 1USドル = 110円での試算

Machine

Learning

22

ElastiCacheインメモリDB

RDS

RDB

DynamoDB

NoSQL

Amazon S3汎用ファイルデータレイク

Amazon Glacier長期保存

階層化による格納（#1. 全てを叶える万能ツールは存在しない）

ホットデータ：

• 応答速度重視

• 限定範囲のデータ

コールドデータ：

• 容量当たりの単価重視

• 膨大なデータ

23

Amazon Redshift

• マネージドRDBMS

• SQL（標準）

• スケールアウト可能

スケールアウト可能な分析サービス

Amazon Elastic MapReduce (EMR)

• マネージドHadoop

• Hadoop/Spark（標準）

• スケールアウト可能

OR

マネージド, 標準技術, スケールアウトが選択の鍵

24

Amazon Redshift

特徴

• データサイズ：最大2PBまで拡張可能

• 超並列(MPP)、カラムナ型DBエンジンによる高速SQL処理

• スケールアウト可能。最大128台

• PostgreSQLとの互換性

• 使った分だけの利用料金。従来のデータウェアハウスの1/10のコストで実現

フルマネージドのデータウェアハウスサービス

10Gb Ether

JDBC/ODBC

Redshift大規模分散処理で分析SQLを高

速実行

25

SQLを分散処理（スケールアウト）

SELECT * FROM …

SQLをコンピュートノードへ配信

CPU CPU CPU CPU CPU CPU

リーダーノード

コンピュートノード

分散してSQLを処理

ノードに直結した高速ストレージ

26

フルマネージド型のRDBMS

運用管理に必要な機能をビルトイン

• S3からの高速ロード＆アンロード

• 自動バックアップ＆リストア

• モニタリング

• データの再編成

• クエリの解析：

27

Amazon Elastic MapReduce（EMR）

大規模データ処理をHadoop/Sparkなどの分散処理フレームワークを使って効率的に処理

AWS上の分散処理サービス• 簡単かつ安全にBig Dataを処理• 多数のアプリケーションサポート

簡単スタート• 数クリックでセットアップ完了• 分散処理アプリも簡単セットアップ

低コスト• ハードウェアへの投資不要• 従量課金制• 処理の完了後、クラスタ削除• Spotインスタンスの活用

Hadoop

分散処理アプリ

分散処理基盤

Amazon EMRクラスタ

簡単に複製リサイズも1クリックSpotも利用可能

28

EMRFS: S3をHDFSの様に扱う

“s3://” と指定するだけでHDFSと同様にS3にアクセス

• 計算資源とストレージを分離できる

• コスト面でもメリット大

• クラスタのシャットダウンが可能

• クラスタを消してもデータをロストしない

• 複数クラスタ間でデータ共有が簡単

• データの高い耐久性（S3）

EMR

EMR

Amazon

S3

29

EMRで稼動するSQLエンジン

SQLエンジン操作アプリ ストレージ

YARN

Map

ReduceTez Spark

HiveSpark

SQL

Presto

JDB

C /

OD

BC

Hiv

e M

eta

sto

re

HDFS

EMRFS

Hue

Zeppelin

SELECT…

30

データ分析プラットフォーム比較Amazon Redshift Amazon EMR

分類 大規模データ処理に特化したマネージドRDBMS

Hadoop/Spark等分散処理フレームワークのマネージド環境

処理系 SQL（PostgreSQLと互換性） アプリケーションに依存：Hive、Pig …

Presto等でSQLでの分析も可能

スケールアウト 可能 可能

ストレージの種類 高速なローカルストレージ HDFS、もしくはEMRFSでS3上のデータを取り込まずにアクセス

ノードとストレージの分離

ノードとストレージは同時に増加・削減

ストレージに影響を与えずにノード増減が可能（EMRFSの場合）

最大処理サイズ 2PB（圧縮後） 上限無し（EMRFSの場合）

処理レイテンシー Low • Presto (Low)

• Hive (Midium~High)

運用管理 運用管理に必要な機能がビルトイン 分散処理系＋OSSアプリ環境を容易に

分析ツール、ETL等 JDBC/ODBC+プッシュバック対応等ネイティブレベルでの対応

JDBC/ODBC経由もしくはHive メタストア経由で多くの環境がサポート

31

Amazon Redshift

• SQL処理に特化・高速

• ローカルディスク上で処理

分析サービスの選択例

Amazon Elastic MapReduce (EMR)

• 自由にアプリケーションを選択

• EMRFSでS3データにアクセス

S3に直接アクセスできるEMRFSを使い、データレイク上の全期間のデータ分析に活用

頻繁にアクセスされるホットデータを格納し、高速なSQLアクセス機能を活用して分析

32

分析に必要なプリプロセスをどこで実行するか？

AWSに転送前のオンプレミス環境で実施• スケールアウトが困難

• データレイクをオンプレミス側に用意する必要がある

S3上のファイルをElastic MapReduceで変換• スケールアウト可能なインフラで処理

• 言語・アプリを柔軟に選択可能

• データレイクを含むAWSサービスへの接続性

Redshift内でSQLで変換• スケールアウト可能

• Redshift内に取り込んだデータのみ操作可能

33

EMR:プリプロセス処理に向く高い接続性

例）Spark on EMRとAWSサービスとの連携

Amazon EMR

Amazon S3(データレイク）

DynamoDB

Amazon RDS

Amazon Kinesis

Amazon Redshift

Elastic Search

Service

EMRFS

Streaming Data

Connector

Copy from

HDFS

EMR-DynamoDB

Connector

JDBC(SparkSQL)

Elastic Search

Connector

34

例）プリプロセスの構成例

Amazon RedshiftAmazon EMR• 非構造化データの構造化・整形• 構造化データのフィルタリング• S3へ変形済データを出力

サマリーテーブル

ファクトテーブル

マート・サマリー表の更新をSQLで実行

Amazon S3

全データ 変形済データ

35

可視化部分は用途に応じて選択可能

EC2+BIツール• 多彩なパートナーソリューショ

ン・OSSをEC2上で活用

Amazon QuickSight [プレビュー]

• 専門家不要のBIサービス

• AWS内外のデータソースにアクセス

36

分析

分析

データレイク

選択の例：全体図• データをAWSへ転送、S3で収集＆保存、データレイクとする

• ホットデータ（直近データ）分析環境としてRedshift

• 全期間データ分析環境としてEMR

収集

可視化

Presto

/EMR

Redshift QuickSight

EXPAmazon S3

BI＋EC2

Direct

Connect

プリプロセスEMR

全データ 変形済

37

事例で見るビッグデータ処理

on AWS

38

事例：Nasdaq様 Redshift/EMRを使い分け

• Redshift:300TB分の直近データ

• EMR+Presto+S3:全期間データ共通のSQLでアクセス

re:Invent 2015発表資料 BDT314 「A Big Data & Analytics App on Amazon EMR & Amazon Redshift 」より引用

39

事例：Finra様 750億イベント/日の処理基盤• S3をデータ共有サービスとして定義し、EMRやRedshiftからアクセス

re:Invent 2015発表資料 BDT305 「Amazon EMR Deep Dive & Best Practices」より引用

40

Finra様：DWHアプライアンスとHive/Tez＋S3比較

• S3に置いたままのデータをHive/Tez on EMRでアクセス

• DWHアプライアンスとの比較で十分な速度を実現

re:Invent 2015発表資料 BDT305 「Amazon EMR Deep Dive & Best Practices」より引用

41

事例：スマートニュース様マネージド・サービスを中心とした技術選択

http://www.slideshare.net/smartnews/20160127-building-a-sustainable-data-platform-on-aws より引用

42

スマートニュース様（Batch~Serving~Output部分）

• S3に入った生データをEMRでETL処理

• レポート：データはRDS→BIツール

• 広範囲分析：RC File形式でS3に格納し、Presto→BIツール

43

App

Server

アプリケーション

Web

Server

トランザクショナル・データ

ロギングデバイス

コレクター

AndroidiOS

KinesisProducer

ファイルデータ

ストリームデータ

S3

RDS

DynamoDB

AmazonRedshift

KinesisStream

Lambda

Pig

Hive

KinesisConsumer

Am

azo

n E

last

ic M

ap

Red

uce

AWSIoT

収集 分析 可視化

QuickSight

IoTDevice

保存

EC2

分析SW

44

まとめ：変化を織り込んだビッグデータ処理基盤

#1. 全てを叶える万能ツールは存在しない

• 適切な技術は変わっていく

#2. データはオリジナルを残す

• 活用方法は将来的に変わる

#3. スケールアウトで解決する

• 対象データはビジネスによって変わる

45

AWS Black Belt Online Seminarのご案内

AWSJ の Tech メンバーがAWSに関する様々な事を日本語で紹介・解説する無料のオンラインセミナー

AWSについてもっと勉強したい方にオススメ！

AWS イベント 検索

46

補足資料：可用性

47

ノード単体障害への対応

• ノード単体の障害への対応はサービスの機能で対応可能

• Redshift：ノード障害の発見、新ノードでの復帰がビルトイン

• EMR：Hadoopの仕組みの中でのジョブリトライ

リスタート

大量のリソース

48AZ #2

システム全体の可用性はマルチAZで担保する

• どこまで可用性が必要なのか要検討

• システム全体の可用性はマルチAZで担保するのが基本

• S3は自動的に3箇所以上のDCにデータをコピー

AZ #1

49

EMR＋マルチAZ環境

EMRFSでS3にデータを維持しているため、別AZで処理の引き継ぎが可能

ジョブごとに別のAZにクラスターを起動することも可能

AZ #2AZ #1

S3

EMRFS

50

Redshift＋マルチAZ環境

案）２つのRedshiftクラスター

①：1年分データ

HDDでバイト単位のコスト重視

②：超ホットデータ（１ヶ月）

SSDで速度重視、サイズを小さく

メリット

②を小さく、コスト最適化

メンテナンスウィンドウを別に設定

最悪でも直近データにアクセス可能

その間にリカバリ

AZ #2AZ #1

S3

HDD

１ヶ月分のデータ

１年間分のデータ

① ②

51

本資料では2016年6月3日時点のサービス内容および価格についてご説明しています。最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。

資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。

内容についての注意点

AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

価格は税抜表記となっています。日本居住者のお客様が各サービスを使用する場合、別途消費税をご請求させていただきます。

52