日本では初開催ということで AWS SUMMIT に行って来ました。
人気のイベントということで、ほとんど参加してみたいと思っていたセッションは埋まっていたので、主に keynote を聞くことを目的に今日だけの参加という感じで行って来ました。
感想などは、のちほど追記することにして、まずはメモのみを共有したいと思います。
Contents
- あいさつ from AWS Japan 代表取締役 長崎忠雄氏
- 10:30 〜 12:20 KE-1 キーノート 基調講演 Day1 Go Global!
- Your Future of Cloud Computing
- ユーザ企業の話（1） gloops Inc, CTO
- ユーザ企業の話（2） 朝日新聞社
- ユーザ企業の話（3） V-CUBE
- 14:30 〜 15:15 CS-1 活用事例セッション 事例セッション #1 ソーシャルでのクラウド活用事例（仮題）
- 15:30 〜 16:15 SL-2 ソリューションセッション ソリューションセッション#2 リーンクラウドでいこう！ クラウドで実現するリーンスタートアップ
- 16:30 〜 17:15 SL-3 ソリューションセッション ソリューションセッション#3 ビッグデータの3つのVと4つのプロセスを支えるAWS活用法
あいさつ from AWS Japan 代表取締役 長崎忠雄氏
- 日本で初開催のAWS SUMMIT
- Cloud Computingの現状を肌で感じてもらいたい
＊
- 東京リージョン
- 最速の成長を遂げた→世界八箇所のリージョンの中で、初年度の成長が。
: 個人的にはもうすでにヒットしているものが日本で後発で開始されただけだからだと思う
＊
- 過去1年のハイライト
- ウェブアプリケーション→花王さん
- ビジネスアプリケーション→電通さん、SAP
- ビッグデータ＆HPC→アカデミック領域で先行
- ディザスタリカバリー→東芝、医療情報
＊
- 金融業界でも
- 今週発表された記事
- セキュリティリファレンス
AWS アーキテクチャセンター (AWS Architecture Center) | アマゾン ウェブ サービス（AWS 日本語） - AWSのサイトでダウンロード可能
＊
- エコシステム
- パートナーエコシステム
- デベロッパーコミュニティ→JAWSというUserGroup
- スタートアップ＆VCコミュニティ→Startup Hub
10:30 〜 12:20 KE-1 キーノート 基調講演 Day1 Go Global!
Your Future of Cloud Computing
▶ クラウドコンピューティングの特質
- 初期投資が不要
- 低額な変動価格
- 実際の使用分のみの支払い
- セルフサービスなインフラ→いろいろな交渉ごと（ライセンス購入やらDC契約やら）に煩わされずに済む
- スケールダウンが容易 (Elasticity)→いらないときにいらないリソースはオフにしておこう
- 市場投入と俊敏性の改善→to be more agile. for startups.
: なぜ U.S. の方のプレゼンなのにスライド日本語…
▶ AWS platform
- 展開と管理
▶ AWSのグローバルインフラストラクチャ
- 8箇所のリージョン
地球を離れた場所でも
- 1 箇所でアプリをつくったら、どこでも展開できる
- たとえ地球を離れた場所でも→Curiosity（火星探査：他のセッションで話題があるらしい）
▶ エンタープライズでの実績
▶ 日本でも既に多数の導入実績
▶ 拡大する日本のパートナーエコシステム
- システムインテグレーター と ISV
▶ アナリストの評価
- マーケットシェアリーダー
▶ AWSの規模；S3の成長
- Peak request 750,000+ per second
- chart of total number of object stored in S3
- 905 Billon Q1 2012
- 1 Trillion end of this year
▶ AWS infrastructure inventments
▶ 価格低減のための哲学
- 資本投資、技術投資、効率改善、値下げ、より多くの顧客獲得のサイクル
- building a win-win situation
- これまで20回の値下げをしてきた実績
▶ IDC におけるAWSのROIの調査
- 5年間で70％のコスト削減
- 開発コスト、85%削減
- アプリケーション管理コスト→52％削減
- インフラのサポートコスト→56％削減
▶ ここからは AWSプラットフォームのラインナップの概要
▶ AWSグローバルインフラストラクチャ
- リージョン、アベイラビリティゾーン、エッジ・ロケーション
- アベイラビリティーゾーン内部でも可用性を高めるために
- それぞれに電源装置などを用意→エッジ
▶ 東京リージョンのアベイラビリティーゾーンが追加に
- キャパ拡大、冗長性拡張、よりフレキシブルに
▶ AWSネットワークサービス
- AWS virtual private cloud
- AWS Direct Connect
- Amazon Route S3
▶ Compute service
- Amazon EC2
- Auto scaling
- Amazon Elastic Load Balancing
▶ Storage Service
- S3
- Elastic Block Store
- Storage Gateway -> virtual appliance, seamless back.
▶ DB service
- Amazon DynamoDB (this Jan released)
- Amazon RDS
- Amazon ElasticCache -> managed memcached service
▶ Application Eco System
- security services
- log analysis
- developer services
- BI
- testing
▶ 展開と管理
- AWS management console
- AWS IAM (user management)
- Amazon Cloud Watch
- AWS CloudFoundation
- AWS Elastic Beanstalk
▶ AWS イノベーションのペース
- 数が右肩あがりに伸びてる図 (2007-2012)
- 顧客がもっとも喜んでくれているのは
▶ Amazon Glacier
- infinite archive storage
- 長期間のアーカイブに適する
- コスト効率のよいデータ外部保管
- テープの代替として
- データの長期間デジタル保存
▶ I/O improvement
- Fast and Scalable
＊
- Amazon EBS provisioned IOPS
- 99.9% の確率でプロビジョニングされたIO性能の10％範囲内の性能がでるように設計
＊
- High IO instance for EC2
- using SSD for the local storage
- suitable for using Cassandra or MongoDB
クラウドコンピューティングの7つの変革
- コスト削減、より速い展開だけではない
- クラウドによって可能なのは変革
▶ 変革1 分散処理アーキテクチャをもっと簡単に
- 既存のインフラストラクチャで分散処理の環境を作るのは大変
- それをクラウドが簡単にするという話
- 分散インフラ
- Multi-AZ service
- ビルディングブロック
- 粗結合のプロセス連携
＊
- 共通パターンのためのアーキテクチャテンプレートを用意した
▶ 変革2 共有システムのセキュリティ
- アプリケーション
- 適切なセキュリティモデルが構築可能
- インフラストラクチャ
- よりセキュリティレベルの高いインフラを提供
（AWSではセキュリティには大変気を使っている、数多くの基準に準拠するように心がけているなど）
▶ 変革3 アーキテクチャによるスケーリングからコマンドによるスケーリングへ
- アーキテクチャによるスケーリングの例：NoSQLのスケーリング
- DynamoDBを用いたコマンドによるスケール
- もはやShadingをどうするかなんてことも考える必要はないと。
▶ 変革4 スーパーコンピュータをすべてのユーザの手元に
- スーパーコンピュータの利用はエリートの特権だった→何より高い
- AWSがそれを準備した
- 性能の説明→写真
▶ 変革5 沢山の失敗と早く失敗体験
- 従来のインフラでは失敗のコストが膨大でイノベーションが進みにくい
- AWS で沢山の失敗と早い失敗体験を
- 失敗のコストは劇的に軽減
- 新しいアイデアに簡単にトライ
- リスクテイクが多くなることで多くのイノベーションにつながる
▶ 変革6 ビッグデータにビッグなサーバーは不要
- ビッグデータの問題は複雑であるべきではない
- クラウドでシンプルに
- クラウドにデータをロード（S3/DynamoDB)
- データ分析を管理 (Hadoop/EMR)
- 結果を可視化
▶ 変革7 モバイル時代のためのモバイルエコシステム
▶ Recap
- 初期投資を削減
ユーザ企業の話（1） gloops Inc, CTO
▶ social gaming company
- user 1800 万人
- 150億PV/月
- 北米市場をターゲットに
▶ ソーシャルゲームの特徴
▶ システム構成
- Route S3
- ELB
- python + Django
- memcached / Redis
▶ Why AWS?
- 要求に応じたリソース確保
- 物理制約からの解放
- IO性能
▶ 求められるIO性能
- 数万ー数十万の同時接続
- 都度接続する
- 最終的にIOがボトルネックに
▶ High IO instance EC2 のベンチマークテスト
- 2TBのローカルストレージ
- 高い性能
- ただし
- 永続化の機能はない などの制約
▶ その他のパワフルなBackend
- DynamoDBは検証中
▶ 分析基盤にもAWS
- ゲームのログを日々蓄積
▶ 多くのツールがすぐつかえる状態にある
- それを活用するのがユーザー企業の立場
- 使いこなして go global
ユーザ企業の話（2） 朝日新聞社
- Go global with the Asahi Shinbun
▶ なぜ朝日新聞が？
▶ 新聞社と技術
▶ じゃあ、朝日新聞がどう go global なのか？
- そのときどきの技術をどのように活用するか
▶ 新聞社の国際事業は？
- 英字新聞発行が柱だった
- 紙からデジタルへ
- 他言語で世界に向けて発信へ
（アジアで最も信頼されるメディアを目指している）
▶ Webサイト構築の基本要件
▶ 0311
- Facebookで英文情報発信、反響が大きかった
- 日本のメディアによる国際発信の意義
- AWSの力を借りることに
▶ トップページは後回しに
- コンテンツに注力
ユーザ企業の話（3） VーCUBE
- エンタープライズの会社
- ビジュアルコミュニケーションの展開
▶ ビジュアルコミュニケーションとは？
- テレビ会議、ビデオ会議
- Webinar など
▶ シェアNo1
▶ 企業コンセプト
▶ なぜグローバルか？なぜアジアか？
- アジアは世界最大のマーケットになる
など
▶ シンガポールオフィス
▶ オンラインセミナーの仕組み
- 201208 開始
- モバイル対応
- AWS 使用
▶ システム構成
▶ なぜAWSを選んだか
Global, Agility, Flexibility, Cost.
14:30 〜 15:15 CS-1 活用事例セッション 事例セッション #1 ソーシャルでのクラウド活用事例（仮題）
15:30 〜 16:15 SL-2 ソリューションセッション ソリューションセッション#2 リーンクラウドでいこう！ クラウドで実現するリーンスタートアップ
▶ リーンクラウドとは？
- Amazonが提言する言葉
＊
- 経営マネジメント→リーンスタートアップ
- 開発→リーン開発
- 運用→Devops
- インフラ→AWS
- すべてのレイヤーで
- ムダをなくし
- 早いサイクルを回す
▶ トヨタ生産方式がルーツ
- 業務改善手法、プロセスに昇華
▶ TPSの基本概念
- Muda に注目
▶ 7つのムダ
- 顧客に価値を与えない物は全てムダ
▶ ムダとlean
- ムダをなくす「文化」と「仕組み」
▶ リーンスタートアップ
- 不確実性の高いマーケットに対しl製品をだしていく組織→会社の大小は関係ない
- 課題は曖昧で正確な解決方法はない→実験的アプローチ、リソースもできるだけもたない
▶ リーンスタートアップの原則
- Amazonが一番大事と思うのは計測と学習
▶ 開発・計測・学習のサイクルをまわす
- アイデア→構築
- 製品→計測
- データ→学習
▶ 継続的に速くまわすことがリスク低減に
▶ MVP
- 市場評価を得るための最低限の製品
- amazon.com そのものが見本
▶ なぜ？を繰り返す
▶ クラウド以前のスタートアップのインフラストラクチャ
- インフラの選択肢
- レンタルサーバ
- 自社オフィス＆自作サーバ
▶ クラウド以前の苦労
- リソース→インフラエンジニアの不足
- スケール
- サーバー調達
＊
- インフラの変化の遅さと経営サイドの意思決定
- インフラの構築がボトルネックに
▶ クラウド時代のインフラ
- 物理インフラからの解放
- 本来のサービス開発、提供へ集中
▶ 最低限の構成をすぐに準備
- ざっくりと 300$/month
▶ クラウドなら不可変動に柔軟に対応
- 一時的なアクセス集中時のみスケールアップ
- 負荷が終わればスケールダウン
- 継続的なサービス成長にも対応可能
▶ 本当に必要なことは計測と学習
- AWSでムダを削減
- vimeo, dropbox, pinterest
▶ Devops
- インフラとアプリの歩み寄り
- 自動化がどれだけ可能かの図説
▶ コスト減＝利益増
- スライドシェアのリンク
▶ 統計的なアプローチ
- できるだけデータを集める
- AB testing
▶ まとめ
- リーンクラウドでスタートアップ
- リーンスタートアップ＋アジャイル＋Devops
- ムダを減らして早く進める
- ビジネス・開発・運用
- それぞれが柔軟な（仲のよい）組織と文化
▶ 7つのムダもAWSなら★★
16:30 〜 17:15 SL-3 ソリューションセッション ソリューションセッション#3 ビッグデータの3つのVと4つのプロセスを支えるAWS活用法
▶ アジェンダ
- AWSのおさらい
- ビッグデータとは何か？
- 事例に学ぶビッグデータ活用
- ビッグデータアーキテクチャ
▶ AWSのおさらい
- アプリケーション
- ライブラリ・・・
- 分散処理、・・・
- コンピュート、ストレージ、DB
- ネットワーク（VPC、専用線、DNS）
- グローバルインフラストラクチャ（リージョン、アベイラビリティゾーン、エッジロケーション）
▶ ビッグデータとは何か？
- マーケティングのバズワードになってしまっていて説明は難しい
- データ量？？
- いや、3つのV
▶ 一つ目のV Volume
- そもそもデータはなぜ増える？
- デバイス数の増加
- パーソナライズ
- ビジネスメトリクスの確保などなど
▶ ビッグデータの成長速度
- そのほとんどが非構造化データ
▶ ビッグデータを支えるAmazon S3
- そのコンセプト
- 堅牢であること
- 常時利用可能
- スケーラブル
- 安心安全
- 高速
- シンプル
- 従量課金、低価格
▶ ふたつめのV Velocity
- Amazon のWEBサーバの移行
- 現場、AmazonのWebサーバはすべてクラウド
- EC2＋オートスケールで自在にスケール
- データの到達速度に対してどれだけ許容量があるか
▶ 3つめのV Variety
- Varietyへの対応
- AWSのサービスをレゴのように組み合わせる
▶ Bigdata 4つのプロセス
- 収集
- 保存
- 分析
- 共有
1-4のプロセスを回転よく回す
▶ AWSを使用してシンプルに実現可能
- もちろんAWSで実現可能
▶ データサイズ・構造とのAWSサービス対応
- RDS、DynamoDB、EMR、S3、Glacier
▶ ユーザー事例
- リクルートの事例
- Suumo
- 行動分析すぐやりたい
- スピード最優先
- オンプレミスからログ転送
- さまざまな効果
＊
- So-net の事例
-
- 広告の分析基盤
- データ量増えてもスケールさせたい
- 内部の人材でやりたい
- システム構成
- クラウド連携（salesforce & AWS)
- その効果→Photo
- S3＋EMRの分析
- コスト効果→浮いたコストでさらにアドバンスな機能を
＊
- アンデルセンサービスさん
- 課題
- 基幹系のバッチ（原価計算）
- Variety に該当する内容
- Asakusa との組み合わせ事例
-
- さらにEMRにも移行しより効率的に
- その効果→図
- 時間制約からの解放
- より新しい物へのチャレンジ
- 既存のシステム負荷の低減
＊
- 海外事例
- Netfix
- 2500万人以上のストリーミング会員
- 500億以上のイベント
- 課題
- データハブ
- イベントデータの処理
- 顧客の行動分析
- Netfix
ー
-
-
- S3 の活用→データ保存のハブ
- 1PB以上のデータ保存しても何も問題なし
-
ー
-
-
- 分析→EMRの活用
- EMRはキャッシュのような使い方もできる→堅牢性をあげる
- クラスタのサイズを処理のさなかに変えることもできる（Netflixの場合、土日のピーク帯）
-
-
-
- 2つの分析クラスタ→本番とアドホック分析
-
＊
-
- yelp の事例
- 口コミサイト
- スペルミスの自動修正などでAWSが動いている
- サイトログはすべてS3上に
- Hadoop Cluster、EMR
- 使い終わったら落とす→規模もシーズナブルに変化させている
- yelp の事例
▶ ビッグデータアーキテクチャ
▶ 標準的なアーキテクチャ
- データの収集、保存、分析、共有
▶ BIツールとの連携
- karmasphere -> Analyst
- SQL -> Engineer
▶ データ中心アーキテクチャ
- ビッグデータが注目されるのはそれだけ扱いが難しいから
▶ まとめ
- ビジネス編
- 技術編
- ビッグデータは普及期にはいってるといえるのではないか？
:同意
