Amazon EMR セミナーの記録

Amazon EMR セミナーに行ってきたので、個人的にまとめておく
http://kokucheese.com/event/index/34636/
日時: 2012/5/18 14:00 – 17:00
会場: アマゾン目黒オフィス 東京都目黒区下目黒1-8-1アルコタワーアネックス16F
メインスピーカーは、EMRのSenior Product Manager の Adam Gray氏

場所は目黒のAmazonJapanの本社。渋谷の東邦生命ビルの時とは大違いで、ビル全てがAmazonという陣容。16Fのセミナールームはおそらく200名前後は余裕で入れるしっかりした部屋で、東京でのAWSセミナーは大抵はここでやっていることが多い。

今回のセミナーはどうやら複数回やったようで、自分はこの金曜日に、同じ会社の他のメンバーは翌日に呼ばれたようだ。パートナー向けのプライベートセミナーで、「EMRのみ」を対象にしたセミナーで、かつUSの人間がしっかり話す試みは、日本では初めてではないかと思う。

自分の時は参加人員は、80名ということで抽選だったようですが、ほぼ70-80名は参加していたような気がする。

スピーカーのAdamは、EMRの統括責任者(の多分一人で、これは推測だけど、外向きはAdamで内向にもう一人いそうな気がする)で、EMRのことなら何でも聞いてくれ的な雰囲気ではあった。

プログラムは一時間x3コマの構成で以下順に。

1. BigDataについてま、正直、通り一遍とおりのBigDataの解説でした。ケースは3例を説明。

一つはYelpの例は、これはAWSセミナーではよく出て来る例でレコメンドエンジンへの利用。あとはEtsyの例、ハンドメイドのプロダクトのサイトの例。最後はClimate corporationの例で気象分析の例。

ベースとして例の3V = Volume-データ量 Velocity-スピード Variation-多様性について言及。どれも必要だよね、という話かつ、データ量だけというのは違うし、サイズの問題ではないというコメント。

BigDataの取り扱いについては、Collect->Store->Analyze->Shareの流れで説明していた。Collect(収集) では様々方法でデータは収集しますね、という話で、S3-Gateway, DirectConnect, Streamingによるlog収集, EC2上での生成と様々。Store(保存)については形態に応じて利用できるものが複数あることを指摘していた。サイズが大きいときにはS3を、構造化されているケースでレイテンシーを下げたいときはDynamoで、それ以外は普通にRDSがあります、という話。

Analyze(分析)については、さらに掘り下げていて、Organize->Cleaning->Enrich-> Aggregate の流れで説明していた。特にちょっと注目したのは、複数のリソースの結合処理について話していて、それぞれのデータソースを適切な道具立てで保存し、必要に応じて統合処理をするというやり方もあるよね、という話。ここでEMRの実績に言及。100万クラスターで稼働実績があり、これはCloudera MapR Hortonと比べても遜色はないよね、というかEMRの方が上でしょう、という話をした上で、多数のユーザー事例を並べていました。メディア・インフラ・流通・ライフサイエンス・金融・セキュリティといったところ。

EMRの強みはS3との連携という点は強調してたと思う。指標の提示や、デバック環境・アラーム機能・その他可視化ツールもある、と強調。

最後のShare(共有)については特に可視化については言及。もっとやれることはあるよね、という内容。

このセッションは普通にBigDataの一般論を話して、EMR上での道具立てを、事例の簡単な説明+考え方の流れとともに話した印象。特に連携について強調していたと思う。まー、自分にはあまり興味はないところでした。


2. AmazonでのEMRの実際の利用について実際のAmazonでのEMRの利用についてケースを3っつ交えてのプレゼンテーション。極めて興味深い内容でした。おそらくAmazon本体での実際のEMRの利用を具体的に話した日本での最初のケースだと思う。

まず自分の印象から言うと以下の三つの感想をもった。

1 EMRの大口ユーザーの一つは間違いなくAmazon本体で、下手をすると最大ユーザー? 逆にいうとEMRはAmazonの中では鉄板のサービスの一つで今後もコミットは続くということ。

2 Elastic MapReduceという言い方は多分正確ではない。実態はAmazon Hadoop Distribution As a Service という言い方の方が多分正しい。

3 AmazonHadoopの最大の利用はBIではない。基幹処理に利用しているということ。分散処理を業務にうまく適用している。いわゆるWeb系の仕組みではなく、物流のマスター処理という一般の業務処理に適用している。大規模な分散処理をミッションクリティカルな業務に適用して、統合運用しているケースだと思う。

以下は、具体的な話。
まず、EMRチームはかなりの数のAmazonの内部のチームとディスカッションをしている。特にデータの取り扱いや、コストおよびパフォーマンスについて。その結果が今のEMRに反映されているようだ。ここで上げられたケースは以下の3っつだった。

1 Affiliate プログラムの集計
そもそも集計すべきAffiliate プログラムのリンクの形態が多様にあるという問題もあり、その集計、特に支払いの計算はかなり大変だった。初期の頃は3回のC++のバッチアプリで処理をしていた。二時間・日次・締め処理の3種類の処理で、ボトルネックは日次処理。ここに分散処理を適用し、Hadoopを導入した。分散処理は敷居が高く、当初は苦戦したがHadoopで相当楽にはなった。集計処理にMapReduceを利用している。処理の流れはOrder->Filter->S3->Hadoop->S3の流れ。

次の問題として、ピーキーなビジネス要求をどう捌くかという問題があった。特にAmazonの処理はトラフィックが一定ではない。11月に最大の波が来るし、そもそも昼夜で差が激しい。ピークに合わせたハードの調達を行うと平均して7割程度は無駄になる。よって、ここにEC2を利用した。一日おおよそ4時間程度のバッチ処理で、空いている時間は利用しない。これにより運用コストも削減できた。

・・・要するにですね。HadoopをEC2に乗っけてみましたというのがEMRの起こりで、それはAmazon用でしたという話です。つまり、Amazon用のHadoopです、ということがルーツですね。

2 在庫センターのマスター管理
商品マスターの属性管理をEMRで行っている。マスター件数は1500億件(多分これは属性を正規化していると思う)。これだけ件数が多い理由は各国ごとで商品の属性により取り扱いカテゴリーがことなり、実際に課税が異なることも発生するため。例えばゴルフシューズは靴か?奢侈品か? また燃えるもの?燃えないもの?の区別や高価品の区別、こういった管理区分は様々。これらの処理は、マスター登録->SQL処理->DWH登録->HRVリスト->DCの流れで処理されているが、DWHがボトルネックになる。なので、このマスターを全件S3に格納してEMRで処理。マスター件数はほぼ毎日5千万づつ増えている換算になっている。尚、常にフルバッチを処理を処理しているわけではなく、必要なケースに応じて起動ノード数は調整している。

・・・正直、かなり衝撃的でした。まずマスターの数。聞いた事無いですよ。たしかにこの規模では通常のアーキテクチャでは処理不能。とはいえHadoopでマスター処理とは、すげーなとは思います。規模が違うとはいえ、すでにAsakusaで同じようなことはやっているので、どの程度大変かは実感できますが、運用している方も相当気合いをいれないと無理なのはわかる。

3 Amazon Cloud Playerでの分析
これは最初からEMRで処理を記述している。結果として、従来に比べてコード量が非常に少なくて済んだ。現在3000行程度だが十分に機能しているし、保守性も高い。Log processing is NOT our businessだそうです。ま、当然言えば当然ですが。

以上でまとめ。社内のEMRの利用はここ最近は爆発的に増えている(一応グラフが出てた。スケールがわからなかったけど、数倍のスピードで伸びているのはわかった)それから大事なのは処理のターンアラウンドを上げること。これによりいろいろな事に挑戦できる。すなわちイノベーションのチャンスが増える。 これもご高説の通りで。

んで、質問タイム。

自分の質問は以下
「Q1 業務系にHadoopを利用する場合、出力が安定しないことが多い。特に物流センターのような時間にタイトなところで、その部分をどうカバーアップしているのか?」
「A1 確かにその通りだ。しかし、規模が大きくなるとある程度オペレーションも読めるようになるため、一定のSLAは保証できるようになってきている。現在のところ一週間の稼働job数は毎週100万に近づいており、ここまでくるとそうそうブレることはない」

「Q2 障害対策や保守はどうしているのか?特にEMRチーム側ではなくてユーザーサイド。ここには専用のチームがいるのか?」
「A2 基本的にAWSサイドはEMRチームが。そしてユーザーサイドにはユーザーのチームが機能している。ただしユーザーサイドはアウトソーシングしているけどね。あと、補足するとこのAmazonの担当チームがそのままEMRのサポートチームで特にプラチナサポートを担当している。だから、プラチナサポートを受ければ、ほぼ今のAmazonが受けているのと、同等のサポートサービスを受けられると考えてもらっていい」

・・・つまり、プラチナ以外はかなりアレだと言っている気がしないでもないし、実際そーかもなー、というココロアタリが無い訳でもないので、まー世の中そーゆーもんかと思います。

その他の質問はHDFSのSPoFについてのものが多かったが、まーS3においとけばいんじゃね、という話でして。個人的にはEMRについては、そもそもHDFSのSPoFはあまり問題にならないというかS3->HDFSの方が問題だろ、という感じでしたので。

3. EMRの解説一応、EMRの説明と多々ある誤解を解きます、という内容です。Amazon+Asakusaのセミナーで結構一緒にやっていたので、内容はいつものパターン的な。一応セオリー的な話を、松尾さんがしていました。お疲れさまです!

という感じでした。もの凄く面白かったので、(いや、おもしろがっていたのは俺だけかもしれない気もするががが)また、次回も深いやつを期待したいですね。

あと、Adamには終わったあとで、ところでHBaseはどうだ?って聞いたら「やってるぞ」的な話でしたので、HBaser(日本で推定で30人位)の方は乞うご期待ですね!

以上でございます。