JAWS SUMMIT 2012

2012.03.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。くろの(福田)です。

先日、JAWS SUMMIT 2012第1日目に参加してきました。

■開催概要

■オープニング:Welcome to AWS Eco-System: AWSとデベロッパーエコシステム

アリエル・ケルマン(@akelman) Director, WW Marketing Amazon Web Services

  • Cloud Virtualization + Application Services + Ecosystem Services
  • JAWSUG、2009年Kick Off、2010+4、2011年+12(うち女子会1)
  • 地理的拡大8つのリージョン
  • AWS Pace of Innovation:非常に速いイノベーション。2011年82サービスの追加
  • Amazon S3 Usage:2011年Q4、7620億個
  • Price Reductions:価格の低減
  • AWSの(Adoption)普及:米シェア59%
  • 日経Cloud Ranking:AWS1位

AWSエバンジェリスト初号機玉川さんからのお知らせ

元gumi CTOの堀内さん(@horiuchi)がAWSのテクニカルエバンジェリスト弐号機に!

■キーノート1:Build your own apps on AWS: AWSでクラウドデベロッパーになろう

ジェフ・バー(@jeffbarr) Senior Evangelist, Amazon Web Services

▼2011年の新しいAWSリージョン

  • 2011年3月Tokyo
  • 2011年8月GovCloud=米政府、州、関連企業専用クラウド
  • 2011年11月Oregon
  • 2011年12月Sao Paulo(サンパウロ)

今後各国政府専用クラウドも作っていきたい!

▼AWS Elastic Beanstalk

  • Javaアプリケーションを用意するだけで環境は自動的にAWSが作成してくれる。
  • 今後他の言語にも広げていきたい(!)
  • AWSリソースを直接コントロール、カスタマイズすることも可能

▼Amazon Virtual Private Cloud

  • Dedicated Instances:占有インスタンス(1物理サーバー内に1ユーザーのサーバのみ)

▼Amazon DymanoDB

  • 低遅延
  • シームレスな高スケーラビリティ
  • 冗長性、可用性
  • 管理不要
  • プロビジョンド・スループット
    • IOPSを設定=保証
    • 必要なスループットを予め設定
  • APIで設定を変更可能
  • IOPSが閾値を超えた場合の通知機能アリ

■キーノート2

The Challenge Economics of Data: アマゾン内の事例にみる、ビックデータ とクラウドの活用最前線

ジョン・ラウザー(@jrauser) Principal Quantitative Engineer, Amazon Web Services

▼amazon.com社内チームにインタビュー

  • new economics(Hadoop、Cloud Computing)
  • lower cost
  • distributed computing is hard

2台のコンピュータで処理を行うようになると、難易度は突然上がる

例えば人の作業時間の平均を取る。 Aさん 9:00 9:10、Aさん 11:31 11:58の様なデータ

  • map:人 作業時間
  • shuffle:ソート
  • reduce:合算

この合算処理は異なるマシン(クラスタ)によって行われる。 全体では複雑な処理もシンプルなタスク(mapとreduce)に分割する事が重要。

このmapとreduceの処理を「安価なハードウェアで実現」出来るようになった。

amazon.comではすべての製品カタログをAmazon S3に保存。10億以上のアイテム。 変更の少ない処理は2ノードのAmazon EMRで処理。 全カタログの分類は50ノードのAmazon EMRで処理。

このクラスタノード数が多様なのが特徴。 スモールとかビッグとかによってシステムが変わるわけでなく、同じような処理を異なるノード数のEMRで処理しているだけ。

(先ほどの図にあるように)処理の難易度はサーバー2台も50台も変わらない。

このノード数の決定が処理を行う直前であればあるほど良い。 直前に決定できるようなシステムで有ればあるほどよい ⇒ 意思決定にどのくらいのスピードで対応できるかに繋がってくる!

speed limits risk

Amazon EMR lowers changes the economics of big data

What is big data?

Extremely Big Data = Peta, Exa?

処理サーバー数が非常に多くなると処理難易度はまた難しくなる。

しかし、Amazon EMRがそのデータ処理の敷居を大幅に下げてくれた。

amazon.com的にはsmall dataもextremely big dataも同じ難易度で分析できるので、特にどれが重要と言うことでは無い。すべて重要!

log processing isn't our business 残りの時間をお客様のための革新的なことを考える時間に回せることが重要

amazon.comは内部でAWSを使っているよ!

■アジャイルとクラウドが変える開発スタイル

  • 司会:AWS玉川さん
  • パネラー:平鍋さん(@hiranabe)、倉貫さん(@kuranuki

▼アジャイル

  • 昔の開発:スポンジケーキ>クリームを塗る>苺を置く
  • 今の開発:ショートケーキを作る>必要な数を改良(スケールアップ)・量産(スケールアウト)していく
  • クラウドはショートケーキのスポンジを提供するので、その上のものを我々はアジャイルに開発していけば良い

今時はケーキ屋さんもショートケーキ毎に実際に作っているらしい(在庫を最小化している)

アジャイル開発=ビジネスアラインド開発(aligned)

在庫を少なくしたい、持たない=lean思考

▼クラウド出現のインパクト

デベロッパーのためのAWSクラウド

  • 2006年AWS出現
  • amazon.comのデベロッパーの生産性を高めるために作られた。
  • 社内タスクフォース
  • 「サーバーをすぐに使いたい」
  • 「ストレージをすぐに使いたい」
  • 「これは社外でもきっと役に立つだろう」

プログラマブルなインフラストラクチャ (APIをコードでたたけばインフラを構築できる)

ハードウェアがソフトウェアに (作ったり、消したり、編集したりが容易に可能)

▼AWSクラウドと新ビジネス

  • ソフトウェアビジネス ⇒ (Web)サービスビジネス
  • 10年前:オープンソース ⇒ ソフトのライセンス費を90%削減
  • 最近:AWSクラウド ⇒ インフラの運用費を90%削減

▼アジャイル×クラウドの体現

point of sales ⇒ point of use

SIは製造業からサービス業にやっと変わってきた。 サービス利用後も価値を上げていくスタイル。 (製品=販売(納品)時の価値が最大で、その後価値が減っていく(償却していく))

スモールスタートとスケールアウト() 従来は矛盾していたが今は自然な開発スタイル。 (:クラウドアーキテクティング原則の一つ)

▼フリーディスカッション

AWSは落ちるもんだと考えて設計するのが良い。 (品質に関する考え方を大きく変える必要な場面がある)

IPA非ウォーターフォール研究会 電器メーカー、SI、楽天、GREEなどが参加。 ビジネスが動いているところは自然にアジャイルを採用している。 なのでエバンジェリズムする必要が無いのでは無いか?

クラウドの登場によって日本の産業構造がもう少し速く変化していくのでは無いだろうか。

アジャイルだとお客様と接する機会が増える。 するとエンジニアのモチベーションが上がる。 エンジニアの成長スピードも速くなっている。 『高速道路化』している。

将棋がインターネットの登場によって進化スピードが劇的に上がったのと同様。

システムの完成形の話をすること自体が間違っている。 (見えないゴールに対して顧客と一緒に少しずつ前進していくのが大切)

ここで、まつもとゆきひろ様光臨

言語=道具、好きなの使って下さいが基本。

思ったことがぱっとできる言語が理想。 言語周辺の環境も重要(ライブラリ等)

クラウドにより「言語のコアの部分」は影響を受けない。

インフラが安くなってるのに、ソフトウェア開発がそんなに高くていいの? ⇒なので小さいチームでさくっと作って、よかったら育てていく流れ

▼まとめ

  • 玉川さん:操船術が大事ぜよ
  • 平鍋さん:3Kを3Tに。楽しい、定時に帰れる、高い給料
  • 大貫さん:お金を稼ぐためにリーダーにならざるを得ないような環境を無くしたい。ソフトウェアは小さい会社で小さいチームで。それで大きな成功を。大きな会社いらんぜよ。脱藩せよ。

■ビッグデータ×クラウドが変えるシステムアーキテクチャ

■ビッグデータ×クラウドが変えるシステムアーキテクチャ

国立情報学研究所 佐藤一郎さん(@ichiro_satoh)

▼ビッグデータが流行っていますが

  • データ量や多様性が本質的では無い。
    • そもそもビッグデータを持っている企業は少ない。
  • ビッグデータ関連技術が重要。
    • スモールデータ処理の高速化。
  • スモールデータとビッグデータに本来境目は無い。
    • 両者を接続する技術が重要。

今までの処理がコース料理、ビッグデータの世界はビュッフェ形式。 いかに組み合わせるか。この組み合わせる処理が難しい。

データの前処理が大変。例:データ形式の変換

  • 前処理に自前システムを使うのもったいない
  • ※この前処理が出来ていれば実はRDBでも分析できるケースはある

▼アプリケーション主導からデータ主導へ

  • 設計だけでなく、運用も含めてデータ主導

▼データ主導型システムアーキテクチャ

  • 既存ITシステムは特定アプリケーションを前提に設計・適用
  • ビッグデータではデータと関心事に応じて分析手法を変える必要がある
  • なのでAWSを使うのが良い

▼クラウドが変えるシステムアーキテクチャ

  • 中規模以上のITシステムは分析システムとして構築するしか無い
  • プロセッサコアの性能向上は頭打ち
  • コア数またはサーバー数を増やす

▼分散システムは複雑&低信頼性

  • 物理的制約(通信遅延)により、システムの全体情報が分からない
  • 故障を想定したシステム構成・運用
  • 「壊れたコンピュータ」と「いずれ壊れるコンピュータ」しか無い

▼ITシステムに縛られない

  • 自前で分散システムを所有・運用すべきで無い。
    • 分散システムの難しさは専門事業者(AWS)に任せる。
  • データやアプリケーションに応じたシステムアーキテクチャ。
    • 汎用的なアーキテクチャよりも、目的に応じたアーキテクチャ。
    • システム構成の動的変更はまだまだ研究レベル
  • スケーラビリティよりも伸縮性(Elasticy)
    • 必要になったら拡張、【不要になったら縮小】
  • 人に縛られない
    • 開発者や管理者に仕事を作るためのITシステムはいらない。
    • 人を雇わなければ人に縛られない。

▼ビッグデータの先にある世界

  • データ共有化
    • データ処理とデータ提供は不可分
  • 処理よりもデータ
    • データ処理とデータ提供は不可分
  • 誰でもシンクタンク化
    • スプレッドシートが誰でも会計処理ができるようにしたように
  • 物理世界とサイバー世界の不可分化
    • Cyber-Physical Systems化
  • シミュレーションとの融合
    • 足りないデータはシミュレーションで補う

■ビッグデータの功罪

NAUTILUS 神林さん

▼技術的な側面

  • 分散環境の敷居を下げた。
  • 分散インフラの普及にはずみをつけている。

▼全体の雰囲気的な側面

  • ビジネスの側面
    • どうみてもバブル。
    • 実際どの程度のビジネスになっているのか不明。
    • 足下が見えてない、完全なレッドオーシャン。
  • 過去の蓄積を軽視
    • 既存のCRM以上のものが提供できていない部分もある。
    • CRMの市場がシュリンクしているのにビッグデータ製品が売れるわけが無い。
  • そもそもCRM等の過去の歴史・積み上げを知らない人が騒いでいる
    • 既存のちゃんとした統計のプロたちには迷惑。
  • プロは現状にノーコメント
    • 「もうすこし勉強してね」「そんなに甘くないぞ」

▼品質の問題

  • 割とナイーブな実装が許容されている。
  • 未だにまともなテスト環境がない。
  • Bigtopとか、かなり最低の出来。

▼過剰適用

  • なんでもHadoopに入れますとか違う。
  • レイテンシー要求とか勘違い多すぎる。
  • RDBMSで出来る部分は確かにある。
  • とはいえ、RDBMSの使い方もおかしい。
  • なんでもACIDとか、いつでもDistinctとか。
    • 技術者の99%がSQLはまともに書けていない。

▼運用の問題が軽視

  • 運用軽視が酷い。
  • 軽視というのは「簡単にできる」と思っている人が多い。
  • 障害対策のノウハウが普及していない。

▼スモールデータの軽視

  • データサイズが小さいと無視?
  • データが小さいのでHadoopは使わないという話がある。
  • 全体の8割は小さな処理。
  • 全体の2割で、8割の時間のロングバッチ。

▼技術的な不勉強を助長

  • parallelとconcurentの区別が付いていない。
  • インフラに寄りすぎている。
  • 設計技法とか絶望的に無い。
  • キーの設計とかも絶望的に無い。

▼超個人的意見

  • ビッグデータについて:もうビッグでもないし、いい加減このワードは聞き飽きた
  • Hadoopについて:飽きた

■ディスカッション

▼日本と米国のビッグデータのトレンドが違う

  • 日本は現場の人が分析。
  • 現場主導なので現場がいくら分析してもビジネスに応用できなければ意味が無い。

▼データ分析を失敗した経験が重要

  • そこをちゃんとインプリしていくだけでマーケットがある。
  • 失敗の掘り起こしだけでも重要。

▼データ分析の失敗を繰り返している人が最終的にデータを上手く分析できている。

▼SIは必要だがSIerが必要であるとは別。

▼稼働率に依存していると人が半減しているのでそもそも仕事として成立しなくなる。

▼IT部門の仕事を作るためのシステムをSIerが作っているのを変えないといけない。

▼ビッグデータと未来

大谷さん

  • ビッグデータの量は日本では多くない。データの桁が海外と違う。
  • 粒度は細かい。技術は追いついていない。需要は掘れば掘るほどある。

佐藤さん

  • 一つの組織のデータ量は少ない。変わらない。
  • データ共有を始めると一気に増える。その時がビッグデータ。

おしまい

@Cronoloves