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ノード数 5台

1ノードサイズCPU 2コアメモリ 20GB

ディスク 100GB



ビッグデータなのでデータは増え続ける線形に増えるのであれば大きな問題にはならない


例えば既存ジョブのデータ量や処理負荷が2倍になったら

CPU 20コアメモリ 200GB

ディスク 1000GB


クラスタサイズも線形に2倍に増やすこれは別に問題ない

CPU 20コアメモリ 200GB

ディスク 1000GB

クラスタサイズCPU 20コアメモリ 200GB

ディスク 1000GBノード数 10台

1ノードサイズCPU 2コアメモリ 20GB

ディスク 100GB



問題は追加のジョブ要件があった場合


追加ジョブCPUメモリを多めに使うがディスクはあまりいらない


ディスク容量が要件にマッチせずに1000GBまで増えているさらに増設していくとさらに無駄も増えていく※スペックが異なるヘテロな構成も可能だが設定が煩雑になる

クラスタサイズCPU 20コアメモリ 200GB

ディスク 1000GBノード数 14台

ディスクは本来550GBでいいのに

1000GBまで増えてしまっている



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などを使う

(無理じゃないけど辛い)



・ストレージ製品の拡張限界。

・データセンターであれば契約ラック数の限界、またはフロアス

ペース限界。

・バックアップのためにクラスタ冗長化や別途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 認定資格出ました


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


71

Technology

20170803 bigdataevent