AWSソリューションアーキテクトのJiang yifengさんによるEMRを中心とした技術の詳説です。

私はまだEMRをヘビーに使ったことはなくて、AWSサービスの中でいうとRedshiftのほうをよく使っています。 ただ、EMRのポテンシャルはとても高く、いま最も使っていきたいサービスの一つです。 他のクラウドサービスに似たサービスが無いことも特徴かと思います。

私が最近EMRに注目しているのは、ずっと起動し続けるサービスではデータが収まりきらなくなってきた、という課題があります。 私が取り組んでいるプロダクトでは、一日に約2TBのログが生まれています。圧縮しても数百GB。そうすると、RDSやRedshift, ElasticSearchなどの起動しっぱなしのクラスタにデータを格納し続けるのが困難になってきました。運用もきついですし、コスト的にもきついです。

そこで、古いデータを消していくという運用になるのですが、後から古いデータにアクセスしたいケースはやはりあります。 また、RedshiftでSQL、というだけではこなせないタスクも想定する必要が出てきたため、EMRを検討しています。

デザインパターン

• 一時的なクラスタの活用
• ジョブ実行中のみクラスタが存在

• データはS3に永続化される

• タスクノードの活用

  • Spotインスタンスを使ってコスト削減
  • 短時間で大量のリソースを必要とする場合、S3から大量のデータをHDFSのコピーする際に一時的にタスクノードを追加して、HS1インスタンスなどにデータをロードする手法

ベストプラクティス

• 常に現世代のインスタンスタイプを使用

• ワークロードに最適なノードタイプを選ぶ

  • HS1 HDFS用途
  • I2 and HS1 ディスクIOが多いジョブ
  • 大きめのノードで構成する小さなクラスタが効率的

• 最適なファイルサイズ

  • 小さいファイル(100MB以下)を下げる
  • S3でHadoop利用の場合は1~2GBが最適なファイルサイズ
    • 1mapperからS3のデータ取得速度 10~15mb/s
    • Mapper処理は60秒以上であるべき 60sec * 15mb = 1GB
  • S3DistCpを使ってファイルを結合して最適なサイズに。

チューニング

• 最強のチューニングはデータを効率よく保持すること

• Hadoopはバッチ向け

• Hadoop処理時間の目安は1時間〜数日

• 短いジョブは他の技術がフィットするかも

  • Apache Storm
  • Apache Spark
  • Redshift

• チューニングについて

• ノード追加！！

• ビジネスの価値を最大化する目的からすると一番早い

• Gangliaでクラスタをモニタリング

• EMRなら1クリックインストール

• 例：ネットワークI/O

  • もっとも重要なメトリック。特にS3を使う場合
  • 1つのインスタンスからなるべく多くのネットワークI/Oを引き出す: Mapper数追加
  • Gangliaでネットワークスループットをチェック例えば200mbpsしか使っていなかったらMapperを追加することで改善する可能性が高い

プラットフォームとしてのEMR

HBase

• 書き込みが激しいものに有効

• OpenTSDB

  • HBase上のtime series database
  • 大規模なモニタリング用
  • 秒間数百万のデータ書き込み

• 自動／手動でAmazon S3にHBaseをバックアップ

  • フルバックアップ／増分バックアップ/指定のバージョンに簡単リストア

Impala

• SQL on Hadoop

• Hiveと互換性が高い: 一部のユースケースにおいてはHiveを置き換えられる

• ストレージレイヤー　永続クラスタのHDFSまたはHbaseを使う必要がある。現時点ではS3に未対応

Presto

• ブートストラップでインストール
• Impalaと違い、S3のデータにダイレクトにアクセス可能なところ

Spark

• 非常に光速
• インメモリで処理しきれるならMapReduceより早いケースが多い
• ブートストラップでインストール
• ver0.8をサポート。1.0はcoming soon
• Sparkはメモリを大量に使う。R3系やSpotインスタンスを利用
• CloudWatchでSparkのメトリックスをサポートする JVMの監視が可能
• Spark Streaming + Amazon Kinesisの構成でリアルタイムで分散処理