AWS re:Invent 2014 - Breakout Session 2日目が終了しました！
昨日に引き続き，忘れないうちに本日の内容についてまとめます．
関連：AWS re:Invent 2014に参加してきた - Breakout Session 1日目
見たセッション
私が参加したセッションについて，感想ベースでまとめていきます．
Keynote
昨日とは打って変わって，前半はAWS製品自体の話よりも，各パートナーさんとAWSの付き合い方に焦点をあてた話が多くなりました．
SplunkにおいてAWS上に構築したアーキテクチャでコカコーラやNIKEのシステムを運用している話や，Omnifoneにおいて世界中何百万人ものユーザに音楽を提供するサービスを運用するためにAWSを採択した話などが紹介されました．
CTOのWerner氏が "There has never been a better time to build applications ~ アプリケーションを作り始める上でこれ以上のタイミングはない" と述べられていたことが印象的で，(Werner氏の述べていた文脈とは違いますが) 様々な企業がAWSを導入して十分な事例が集まった今というタイミングは，AWSを使ったサービスを始めるには絶好のタイミングなのかもしれないな〜と思いました．
そしてAWS EC2 Container Service!!! Free!!!!!
スーパークールなデモでした．
AWS Lambdaも個人的に凄く重宝しそうな機能なので，早く使ってみたい．
MBL202 - Getting Started with AWS Lambda
早速聞いてきました！
そして，ここでLambdaの紹介を書こうと思ったのですが，既にわかりやすい記事が上がっているので省略します＼(^o^)／w 詳細は以下をご覧下さい．
http://aws.typepad.com/aws_japan/2014/11/run-code-cloud.html
発表の中では，Lambdaを利用することでユーザはよりビジネスロジックにフォーカスすることが出来るという事が強調されていました．
私の中のイメージでは，shellでpipe使って処理を繋ぐくらいカジュアルに使える感じなのですが(であって欲しい。)，どんな感じなのかはデモだけではあまり分からなかったので，実際に使ってみたいですね．現在はNode.jsのみにしか対応していないので，今後の言語拡張が待ち望まれます(Python待ってるPython←)
BDT310 - Big Data Architectural Patterns and Best Practices on AWS
このセッションでは，大規模データのくくりの中でも，求められる要件に応じてどういうツールを選択していけば良いのか？について話をされていました（内輪ネタですみませんが，弊社インターンのSunriseのAWS特化版みたいな感じです）
Stream処理にはKafkaよりもKinesisが良いよという話があったり(まぁAWSのカンファレンスですし・・・)，どのStorageを選択したら良いのか？というところでは
- データ構造はどうなっているか
- クエリの複雑度はどうなっているか
- データの特徴はどうなっているか: hot, warm, cold
- hot: データのボリュームがMB-GBのものや，request rateが非常に高かったり，etc.
といった観点から，使い分けを行った方が良いという話をされていました．
- シンプルな構造化データ: DynamoDB, ElasticCache
- 非構造で非クエリ形式のデータ: S3, Glacier
- 構造的だが，クエリが複雑なデータ: RDS, Cloud Search
- 非構造でカスタムクエリ形式のデータ: EMR
全体的に基本的な感じでした．
デモでは，ビデオ推薦システムを例にbatch processingとstream processingでどうツールを使い分ければ良いのか，それぞれに求められる要件などを挙げながら説明されていました．
面白いベンチマーク結果が紹介されていたので，共有しておきます．
https://amplab.cs.berkeley.edu/benchmark/
BDT303 - Construct Your ETL Pipeline with AWS Data Pipeline, Amazon EMR, and Amazon Redshift
このセッションでは，AWS Data Pipelineを利用して，どのようにETL(Extract/Transform/Load)処理を行えば良いのかについて説明がありました．具体的に，CLIコマンドやEMR，Redshiftの設定例が取り上げられていました．前半は1度でもAWS Data Pipelineを利用したことがあれば知っているだろう基礎的な話です．
後半はCouseraの方がプレゼンターとなり「Coursera Big Data Analytics Powered by AWS」というタイトルで，Dataductについて紹介してくれました(AWS Data Pipelineってぶっちゃけ使いづらいという意見には概ね同意)
Dataductを利用することで，非常に簡潔なETL定義群を用いてpipelineを記述することが出来ます．Dataductは，ETL処理でよく利用される3つの処理を分割しています．
- 様々なソースからデータを抽出
- 抽出したデータをEMR，EC2，Redshift内部 等で加工する
- データを(主に)Redshiftに格納する
各ETL定義は以下のようなYaml形式で書くことが出来ます．
steps:
type: extract-from-rds
sql: | SELECT instructor_id, course_id, rank FROM courses_instructorincourse;
hostname: maestro-read-replica
database: maestro
type: load-into-staging-table
table: staging.maestro_instructors_sessions
type: reload-prod-table
source: staging.maestro_instructors_sessions
destination: prod.instructors_sessions
良さそう！使ってみたら改めてまとめたいと思います．
DEV307 - Introduction to Version 3 of the AWS SDK for Python (Boto)
BotoはPython開発者向けのAWS SDKです．2006年から開発が始まり，現在のメジャーバージョンはPython2.系をサポートしています．今回の発表では，Python3.系に対応するBoto3について説明がありました．
※ Boto3は公式で以下のように述べられており，まだpreview版しかリリースされていません．
WARNING: Boto 3 is in developer preview and should not be used in production yet! Please try it out and give feedback by opening issues or pull requests on this repository. Thanks!
Boto3から新たに加わった(!?)Pagenatorの機能やClient Waitersの機能は便利だな〜と思いつつも，肝心のメジャーリリースの話がなくて若干先行きが不安(´・ω・｀)
そもそもAWS自体がデフォルトで (おぼろげだけど) Python2.6系だった気がするし，なんというかよろしくお願いしますm(_ _)m
BDT302 - Big Data Beyond Hadoop: Running Mahout, Giraph, and R on Amazon EMR and Analyzing Results with Amazon Redshift
前半はEMRの紹介です．後半の方で，R/Mahout/GiraphをEMR上で動かす話が紹介されていました (Giraphについては良く分かってないのでここでは省略します←
- EMRでは全てのノードでRが動いており，Rのmapper/reducerを書いたりすることも可能です (Haddop Streamingで動作します)
- MahoutはJavaで書かれたスケーラブルな機械学習ライブラリです．Mahoutを利用することで，Hadoopを利用したClusteringやClassification，Callaborative filturingを行うことが可能になります. EMRでMahoutを動かすためには，S3上にcustom JARをuploadする必要があります
EMR自体の話が主で，思ったよりRやMahoutの話がなかったのが少し残念。。。
SDD401 - Amazon Elastic MapReduce Deep Dive and Best Practices
様々な知見にあふれていて参考になりました．
いくつかピックアップしてみます．
- mapperが多くなる場合には，タスクノードを活用すると便利
- データが小さい時にはHDFSを利用した方が便利
- 小さいファイルサイズはやめる
- 少なくとも100MB以上であることが望ましい
- 10TB of 1GB Files = 10,000 Mappers * 2 sec = 5時間もかかる
- 60秒以下のHadoopタスクは極力避ける
- シングルタスク＆S3の場合，10MB~15MB/sなので，60sec * 15MBで1ファイル1GB程度が良い
- S3DistCPを使って，小さいファイルはまとめてしまおう！
- S3上には常に圧縮したデータを置く -> Storageのコスト，I/Oどちらの観点でもその方が良い
- データ格納先はS3にする
- HDFSはtemporaryの格納先として利用
- 複数のクラスタ間でデータをシェアすることが可能になる
- 複数のクラスタが1つのRegionで動いていた場合，EMRのノードとS3との通信速度は劇的に速くなる
- 何度もデータを読み込み直す必要がある場合など，HDFSを利用する方が良い場合もある
また，数カ月前に出たというAmazon EMR Consistant Viewについても説明がありました．
参考：http://aws.amazon.com/jp/about-aws/whats-new/2014/09/17/amazon-emr-adds-consistent-view-and-server-side-encryption-support-for-amazon-s3/
EMRFSを使うと，直接S3上のデータを読み込んで同期してくれるようです．
初めて知ったので今度使ってみます．
システム構築例もいくつか紹介されていました．
下記は，KinesisのデータをHDFSにStreamで流し込んでSparkによるリアルタイム処理を行っている例です．最終的な結果はRedshiftに格納しています．
まとめ
昨日に引き続き，色々と濃い話を聞くことが出来ました．
早くAWS Lambdaを試したくて仕方ないです←
さてこれからre:Playです．飲みですお酒です！
最後まで楽しんできます＼(^o^)／