AWS re:Invent 2014に参加してきた – Breakout Session 2日目

1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...

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)

Overview of Boto3

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に格納しています.

Example of Amazon S3 and HDFS pipeline

まとめ

昨日に引き続き,色々と濃い話を聞くことが出来ました.
早くAWS Lambdaを試したくて仕方ないです←

さてこれからre:Playです.飲みですお酒です!
最後まで楽しんできます\(^o^)/


1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...
      この投稿は審査処理中  | 元のサイトへ