2週間ほど久しぶりにシリコンバレーに行ってきた訳ですが、その目的の一つが本場のCLOUD EXPOを見ることだった。
まだ知らないクラウドサービスがあるかどうか、またfluxflexと同じようなサービスがあるかどうか、最新の情報がそこに行けばあると思っていた。RightScale User Conference に申し込むとCLOUD EXPOの参加費がタダになるということで、こちらもついでに見てみようという感じだった。
で、結果的にどうだったかというと、CLOUD EXPOは非常に残念な場だった。むしろRightScaleの話のほうが実践的で内容は良かった。
CLOUD EXPO はクラウド上で展開しているサービスの見本市というよりかは、完全にエンタープライズを意識したITベンダーの宣伝の場になっていた。各セッションのスピーカーはスポンサー企業の担当者で、展示物もハードウエアもあり、自社のソフトウエアもあり、「クラウドにかこつけた」キーワードで今まで通りの自社製品のアピールをしている。
スポンサー企業のたくさんお金を出している上位を見ると大手ITベンダーであり、クライド?と思ってしまうようなメンツだ。
アメリカらしいちょっと変わったセッションといえば、スタートアップがクライドを活用するための指南、SaaSスタートアップを束ねるようなコミュニティの紹介というところだろうか。ただ、これらのセッションもスタートアップを顧客と狙うコンサルタントが話していて、スタートアップが自ら語る生きた情報ではない。
基本的には日本のよくあるクラウドセミナーでITベンダーがアピールする傾向とまったく同じなことが分かった。その次の週に日本で行われたCLOUD EXPOのほうが、さくらの新サービス発表とかニフティクラウドにAWSの方が飛び入り参加したりして、実際見ていないがこっちのほうが面白そうに思えた。展示に関しても、USは広めの会議室1つだったので幕張の展示面積のほうがずっと広いしたくさん展示されている。
気になるAmazonは一番下のランクのスポンサーで、配布資料もWebに乗せているセキュリティホワイトペーパーを印刷した物、という気合のなさがまる分かりという感じだった。
CLOUD EXPOと言いつつ、エンタープライズに完全に絞ったイベントだということが分かった。次回は行くことはないだろう。
一方、RightScale User Conferenceはユーザ向けに自社サービスの活用法などを実践的に紹介していた。
しかし、DBのスケーリングの良い答えはRightScaleでも持っていないのだなぁ。悩ましい。。。
こちらの方のメモを以下に記しておく。
RightScale Case Studies
RightScale を使っている4社が自ら説明
-
American Gril</p>
- 子供向け人形、着替えなどの販売
- オンラインもやっている Jun 2010 スタート アバター使う
- Cloudへ移行した パフォーマンスを測って選定したよ
- 1日で移行した implemented
- 2500%キャパシティ increased
-
すでに登録済みのユーザアプリケーションは1ヶ月後に移行した
- 1000%キャパシティ increased
-
構成 : php CDN はAkamai
- フロントは image, web array , re gstry jetty arrayなど
-
今後 much more work ahead
- RightScaleでの教育を受けたい DEV, TEST, LOAD
- implement ability to auto-scale # 現状オートスケールは使ってないみたい
-
WATCHMEN (AltEgo)
- MMO iPhone Appらしい
- 3DバーチャルなMMOぽい
- 25日で 沢山のリクエストが来たよ、登録数ではないけど
-
なぜRightScale?
-
Fail Forward</p>
- Nominalizes downtime, Unix Script
-
RIghtScale Server Templatesすごくよいよ
- テストのためのたくさんのサーバの開発環境を用意
- 地域に関係なく利用出来る
- RightScaleは早いレスポンスがよい
-
Fail Forward</p>
-
Associated Press
- 世界中にニュース配信する
- 3700従業員、300ヶ所のロケーション
- ニュースにとってのチャレンジは第2のマーケットつくる
- 色々なpublisherにライセンスニュースを送ること
- コンテンツのトラッキング、ニュースコンテンツのマネージメントとモニタリング
- 今後 コンテンツライセンスの実行、Audience and engagement services
-
Associated Pressから hNews を配信してトラッキングして、Real time rollup,Mapに描いて、Data Warehouse に食わせて News Registry として保存する
- AWSはEC2, S3, CloudFront, CloudWatch
- AzureはTables, Queues, SQL Azure
- data ware house は自社、private cloud で開発、QA、Testした
- RightScaleのManagemnt UI使った。depoy時間が少ない、深い部分のマネージが出来る、コスト削減になった
- アクセス解析、アメリカ東側中心にアクセスあり
-
Pogo.com
- Socal Gameづくり、Facebook, iPhone, Yahoo!Gamesなど
- Free 100以上作っている、$5-30/m くらいのゲーム40種
- 構成 : AWS base でREST/jSON.HTTPSのフロントとSimpleDB, EBS, RDB, SQS, S3の連携 + EA Hosted Oracle RAC
-
テストが終わってからのデプロイの自動化が問題だった
- installerを書いた
- Nexus から Automated Buikds(Hudson)つかって、Debian Repository(Jetty, JDK含む)でパッケージ化して、Ubuntu EC2にデプロイする流れ
- RightScaleのモニタリング使えるよ、いろいろな言語のスクリプトが使える
- Webnorogukara Syslogで集めて SDBにHadoopかましたろを置く
- S3におく そこから HIVEと連携する
- デプロイがダウンタイムなく早くなった、ロールバックが早くなった
-
Web Filings
- SECレポートのためのソリューションを提供
- GAEの環境ではいくつかのユーザのアプリが動かない
- RightScaleのpre-built script パッケージからはじめられる
- スケーリングのパラメータも設定できる
-
ちょっと問題あったけど今はRightScaleのUbuntu imageでcheck outしている
- tweak scriptを使っている
- rebuild と redeploy が12時間以内で実現できるようになった
- In-HouseするよりもCloud使って色々できるようになった
RightScale Non-MySQL
codeFuturesというDBのShardingの製品を持つ会社の説明
- shard の説明より、Each partition forms part of a shard
- The key to Database Sharding… Share Nothing ができる
- C0001のCはCustomerなのか?
- ASとDBの間にproxy をはさむ
- EC2上でスケーラブルに増やしたらリニアに書き込みパフォーマンスがあがった
- Sharding work: No contention between servers
- Sharding を利用した場合、CPUの利用率が上がって、wait が減ったよ
- Database Typeの比較 MySQL, Postgess, Oracle vs NoSQL(in memory0
-
NoSQLでShardingを動かすためには S2にkey,objectをputして、S3からgetする
- # ってことはS2,S3で同じデータを持てているということ?
- MySQLでも同じ構成
-
Cross-Shardの構成
-
Client側でAgregateしている、Go Fishの命令を出す</p>
- 各サーバにブロードキャストする
-
Client側でAgregateしている、Go Fishの命令を出す</p>
- Sharidingは2台あればfailoverに対応できる、メモリは3つのDBががあること
- S1とS2を1つにすることもできる Elastic shards
- 現在はMySQLのみでできる、将来的にはPostgreSQL, NoSQL, Caching対応
RightScale Web Scaling
Webのサーバ構成でのProxy, App, DBそれぞれのスケーリング方法紹介
- バランシングにてELBはTCPレベルのみ(古い情報であることを断っている)
- HAProxy + Apache もある
-
Recommendationは Minimum of two load balancers
- 異なる Availability zone に置くこと
- m1.largeを使うと良いパフォーマンスをした
-
Application Server Tier
- (RightScaleの)Autoscaling使うことを想定
- 自動化してcodeを持ってくる仕組みが前提
-
Triggers で Custom で connections と Application specific metricsがある
- instance size m1.largeが良い選択肢
- m1.smallはtestにいいよ
-
Caching Tier
- databaseへのアクセスを減らす
- PHP + memcached の組みわせはいいよ
- メモリサイズによってインスタンスサイズが決まる
-
手動でのスケーリングになる
- TTLを気にする
- memcached
-
DB Tire
- slaveのスケールの時にMySQL Proxyを使う構成を紹介
- マルチマスターはライトスケールはお勧めしない
-
NoSQLは一部のユーザで使っている
- SDBとか
- DBのスケーリングのおすすめはない # あらあら。。。
- It depends!だそうな