'15年入社の橋本です。
先日AWS Summit Tokyo 2015に展示員をしつつ参加してきましたので、その時のレポートをお送りします。
展示員
サービスのご説明などは以前よりスムーズにできたように思うので、そこが今回良かった点かなあ、と思っています。
一方で、商談に近いお話はまだまだ難しいです。先輩方のトークを聞いていると、やはりもっと精進しなくてはと感じます。まだまだ前途多難ですが、新人ながらこうした機会を与えてもらっているのは非常にありがたいと思います。私自身にとっても良い刺激になっているので、もっと外に出る機会を増やすようにして「商売」のノウハウを吸収していきたいですね。
今回は運用経験のある方と弊社ブースでお話する機会が幾度かありましたが、Cloud Automatorの話は特に興味を持って聞いていただけたケースが多かったように思います。
- 自動化スクリプトを動かすためのサーバの構築／メンテの作業から解放される
- AWS側のAPI仕様変更に伴うスクリプトのメンテから解放される
上記2点が弊社Cloud Automatorの大きな特徴となっていますが、こうした点に興味を持ってもらえるところを見るに、運用サイドの現場での苦労が垣間見える思いがしました。
セッション
私はデータサイエンスの分野に興味があるので、こちらのセッションを覗かせていただきました。
社内でデータ分析環境を構築したお話でした。EMRとSparkを使った分析環境の構築を行われた、とのことです。
ここで簡単にEMRとSparkの説明をしたいと思います。両者ともビッグデータ潮流の火付け役となったApache Hadoopと深い関わりを持つプロダクトです。
EMR (Amazon Elastic MapReduce)
ビッグデータの処理基盤の構築は非常に煩わしいものです。以前、私も自宅の環境を使ってミニマルなHadoopクラスタの構築、そして試運転までをやってみたことがあります。当時の記憶がだいぶ薄れておりますが、非常に苦労したことだけは覚えています。業務用に大規模Hadoopクラスタを構築し、運用までカバーする...そのコストは推して知るべしといったところです。
EMRではそうした部分はマネージドサービスとして提供されており、利用者が本質である分析業務に集中できるようになります。AWSのインフラを使うため、インスタンスの投入も自由自在。あらゆる規模のデータに対応が可能である点もクラウドならではの利点ですね。
Spark (Apache Spark)
Hadoopのように、大規模データの分析に使うものです。...しかし、Hadoopとはまた別の棲み分けがあるようです。いろいろ参考文献を探してみたところ、参考になりそうなページがいくつか見つかりましたので、まずはそれをご紹介します。
さて、SparkがHadoopとどう違うのかを押さえるポイントはいくつかあって、私が特に重要だと思うポイントは以下2点です。
- Sparkは「処理」部分を提供する。Hadoopのようにストレージ(HDFSやS3など)は提供しない
- 一度分析に使ったデータはメモリキャッシュし、2回目以降の処理を高速化
前者によって何が美味しいのかと言うと、HDFS以外のストレージ、もっと言えばS3に溜め込んでおいたログをそのままSparkで扱える、というところです。
後者については、同じデータセットに対して反復学習を行う機械学習アルゴリズムを使う場合や、トライアンドエラーしながらインタラクティブに分析を行いたい場合、これらのケースでメリットがあります。同じデータを繰り返し使うのがわかっているのに、毎回HDFSやS3からデータを取ってくるようでは非効率です。メモリキャッシュの仕組みが絶大な効力を発揮することはご理解いただけるかと思います。
Sparkについては個人的にも興味があるので、今後も調査していきたいと思います。
個人的にはEMRとSparkを利用することで「トライアンドエラーが苦にならない手軽さ」が手に入った、とおっしゃっていた点が心に残っています。SparkとEMRのいいとこ取りをした、非常に面白い事例だと思います。また、その手軽さを支える裏側にAmazonのクラウドインフラがあるのだなと思いました。
詳しい話はAWS Summit Tokyo 2015 開催レポートにも資料が公開されていますので、ご興味があればぜひこちらも併せてご参照ください。
以上です。前回そして今回と、参加レポートの記事をお送りさせていただきました。
そろそろエンジニア的な記事も書きたいですねー。現在AWSの方は修行中なので、次回はそういう内容をお届けできればと思います(笑)
