20170803 bigdataevent

Big Data取り扱い方の
オンプレミスとクラウドの違い
アマゾンウェブサービスジャパン株式会社
テクニカルトレーナー上原誠
2017年8月3日
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
…そしてトレーニングへの誘い

自己紹介
 名前: 上原誠 (うえはらまこと)
 現職: AWS のテクニカルトレーナー
 前職: 渋谷系のWeb系のインフラ系エンジニア
 好きなHadoopエコシステム：ZooKeeper
 好きなデータストア：Aerospike

ビッグデータの「パイプライン」
収集
保存
処理と分析可視化
深い理解データ
© 2016 Amazon Web Services, Inc. and its affiliates. All rights reserved.

ビッグデータの「パイプライン」
収集
保存
処理と分析可視化
深い理解データ
別にオンプレでもでる

ただ
オンプレミスだと大変なことがある

ここでは５つあげます
①ハードウェアの世代問題
②サイジングの課題
③バージョンアップの課題
④本番規模でテストしずらい問題
⑤ストレージの課題

①ハードウェアの世代が上がると
まったく同じスペックのものは調達
できない。Hadoopクラスタのノー
ド増設時に困る。

これはサーバーを使い続けることによる問題
※古い世代が残る、むやみに捨てられない

クラウドだと

・Hadoopクラスタのノードは使い捨て
・クラウドのHadoopの使い方はクラスタ単位で使い、終わったら
消す、なので新しい世代のEC2が出たら全てそれを使い、使い終
わったら消す。古い効率の悪いEC2を使い続ける必要はない。
※厳密に同じスペックを保証するわけではないが、明確に古い世
代のEC2排除は可能

②Hadoopクラスタのノード数を増
やすとCPUとRAMとDISKが線形に
増える。追加ジョブ要件にマッチで
きない。

CPU 10コア
メモリ 100GB
ディスク 500GB
例えばこういうジョブがあったら

CPU 10コア
メモリ 100GB
ディスク 500GB
こんなクラスタになる
クラスタサイズ
CPU 10コア
メモリ 100GB
ディスク 500GB
ノード数 5台
1ノードサイズ
CPU 2コア
メモリ 20GB
ディスク 100GB

CPU 10コア
メモリ 100GB
ディスク 500GB
ビッグデータなのでデータは増え続ける
線形に増えるのであれば大きな問題にはならない

例えば既存ジョブのデータ量や処理負荷が2倍になったら
CPU 20コア
メモリ 200GB
ディスク 1000GB

クラスタサイズも線形に2倍に増やす
これは別に問題ない
CPU 20コア
メモリ 200GB
ディスク 1000GB
CPU 20コア
メモリ 200GB
ディスク 1000GB
ノード数 10台
1ノードサイズ
CPU 2コア
メモリ 20GB
ディスク 100GB

CPU 10コア
メモリ 100GB
ディスク 500GB
問題は追加のジョブ要件があった場合
CPU 10コア
メモリ 100GB
ディスク 50GB
追加ジョブ
CPUメモリを多めに
使うがディスクは
あまりいらない

ディスク容量が要件にマッチせずに1000GBまで増えている
さらに増設していくとさらに無駄も増えていく
※スペックが異なるヘテロな構成も可能だが設定が煩雑になる
CPU 20コア
メモリ 200GB
ディスク 1000GB
ノード数 14台
ディスクは本来
550GBでいいのに
1000GBまで増えて
しまっている
CPU 10コア
メモリ 100GB
ディスク 500GB
CPU 10コア
メモリ 200GB
ディスク 50GB
MapReduceとHDFSが密結合なので仕方ない

オンプレミスのHadoopクラスタは、
永続的に動き続けるクラスタにジョブを入れ込んでいく考え方
Job1 Job3
Job2

Job3
Job2
Job1
クラスタにジョブを入れ込んでいくのではなく

それぞれのジョブにクラスタを立てる
Job3
Job2
Job1

ジョブが終わったらジョブとともにクラスタも消す
クラスタを使い捨てる
使い捨て！
Job2
Job3

そう、使い捨てこそがクラウドの
メリット

AWSのEC2と同じ考え方
サイジングや
新しいツール検証
様々な試験
一時的な処理

AWSのEC2と同じ考え方
消す
サイジングや
新しいツール検証
様々な試験
一時的な処理
終わったら

これをクラスタ単位で行う

最適なサイジングができる

それぞれのジョブにどのくらいのスペックのクラスタ
が適切かを事前に検証できる。なので最適なサイジングができる
使って、終わったら消
せるんだからバンバン
試せばいい
Job1

ということは

③バージョンアップも事前に試せる

Job3
唯一無二のクラスタをバージョンアップするから怖かった
(いや〜怖かった)
Job2
Job1

バージョンアップも怖くない

同じ理由で、④新しいツールも試しやすい
例えば

MapReduceは素晴らしいと思っていたが(実際シンプ
ルで安定してて素晴らしかった)、Sparkが登場した。

MapReduceは素晴らしいと思っていたが(実際シンプ
ルで安定してて素晴らしかった)、Sparkが登場した。
※Hiveの資産を活用するためにHive on SparkやHive on Tezがあるが新規で作るならSparkで
よいと思う。コード(java,scala,python)もシンプルに書けるので従来より生産性が高い
MapReduceはゆっくりと死んでいく・・

そんな時クラスタが「触るな危険」では試しずらい。

「テストしたいから同規模のクラスタをサクッと用意
して」と言われても辛い。

今後もよりいいものは必ずでてくる！
エンジニアにはよりいいものを試し、よりいいプロダ
クトにしてほしい。それを止めるようなプラット
フォームじゃいけない。

そう、使い捨てこそがクラウドの
メリット(2回目)

だがデータが消えたのでは意味がない

クラスタを使い捨ててもデータは残したい
データは残したい
Job2
Job3

コンピューティング処理レイヤとストレージレイヤ
を分けることでデータを永続化
ストレージレイヤの分離
ストレージ
Job2
Job3

コンピューティング処理レイヤとストレージレイヤを疎結合にする
それぞれのクラスタの永続データ
はストレージレイヤに保存
ストレージ
Job2
Job3

⑤データは増え続ける。「数百TBや
数PBのストレージが欲しい」「と言
うか理想は容量無限のストレージが
欲しい」。そして数PBとかのバック
アップどうする？？

オンプレだと

無理

・ストレージ製品の拡張限界。
・データセンターであれば契約ラック数の限界、またはフロアス
ペース限界。
・バックアップのためにクラスタ冗長化や別途DASなどを使う
(無理じゃないけど辛い)

できる

そう、S3

S3の３つの特徴
１．丈夫 (耐久性99.999999999%)
２．容量無制限
３．Hadoopから接続しやすい (EMRFS、s3n、s3a)

１．丈夫 (耐久性99.999999999%)
バックアップが必要ならクロスリージョンレ
プリケーションを活用できる

１．丈夫 (耐久性99.999999999%)
あと安い
バックアップが必要ならクロスリージョンレ
プリケーションを活用できる

コンピューティング処理レイヤとストレージレイヤを分ける
ストレージにS3
Job2
Job3
ストレージ

コンピューティング処理レイヤとストレージレイヤを分ける
Hadoopクラスタに
EMR
コンピューティング処理
のHadoopクラスタにEMR
Job2
Job3
ストレージ

これでデータが一箇所に
データが一箇所にあるということは

一箇所のデータに対して
最適なデータ処理エンジンを使える
ストレージ
Athena
Redshift

ストレージ
一箇所のデータに対して
最適なデータ処理エンジンを使える
Athena
Redshift
データレイク

Hadoopの考え方との違い
(Hadoopはオンプレミスを想定した
アーキテクチャ)

・データローカリティを活かした処理スループットの向上。
・起動し続けるのでクラスタではHDFSのデータは絶対。その司令
塔であるマスターノードはHA構成で死守する。
・Rack-awarenessでラック障害や距離を意識したデータ配置、
レプリケーション時のL2スイッチの上りの帯域の考慮、スイッチ
のDeepBuffer機能使ったりなど。

・データローカリティを活かした処理スループットの向上。
・起動し続けるのでクラスタではHDFSのデータは絶対。その司令
塔であるマスターノードはHA構成で死守する。
・Rack-awarenessでラック障害や距離を意識したデータ配置、
レプリケーション時のL2スイッチの上りの帯域の考慮、スイッチ
のDeepBuffer機能使ったりなど。
スループットはS3でもそこそこ出る
数時間のバッチ処理時間が1,2割増えて問題あるか？で検討する
使い捨てなのでHA機能ない。
HDFSはテンポラリ用途として使う
ネットワークまわり
はAWS側が全て行う

まとめ

クラウドらしさとは
・リソースをすぐに使えて不要になったら捨てる
・容量無制限のストレージ
・バージョンアップの気軽さ、本番スケールのテストのしやすさ
・ジャストサイズでプロビジョニング
・運用負荷軽減で本来やりたいことに注力
・データローカリティは下がる
・HDFSはテンポラリ
・NameNodeのメタデータ操作にビビらない。NameNodeも作って壊す
・他にもビッグデータ処理に役立つサービスとしてAthena、Kinesis、
Redshift、Snowball、QuickSightなどなど
：

クラウドらしいベストプラクティス
・なるべくマネージドサービスを使って運用負荷軽減
・できるだけ一時クラスターを使う
・EC2スポットインスタンスの活用。「スポットフリート！」
・新しいインスタンスに移行してパフォーマンスを活用
・最適なサイジングの為のモニタリング
：

詳しくは・・

・ディスカッションあるよ

６月くらいに
Big Data 認定資格出ました

認定資格、トレーニングの話

20170803 bigdataevent

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 20170803 bigdataevent

Ähnlich wie 20170803 bigdataevent (20)

Mehr von Makoto Uehara

Mehr von Makoto Uehara (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)

20170803 bigdataevent