第三回ライブドア・テクニカルセミナーに行ってきました
クラウド時代のWebストレージ/データベース戦略
自己紹介
- ライブドア 池邊さん
利用者から見て
- 物理的なサーバ、ネットワークを意識しない
- 高可用性
- 柔軟な課金体系
- Amazon S3,CloudFiles...
提供者から見て
- 高価な機器に依存しない=>スケールアウト
- リソース有効活用でコスト効率
- 管理、運用の手間の効率化
ライブドアの考え
- 物理サーバリソースは投資済み
- 提供しているサービスはSaaS的なもの
- さらにコスト効率をあげたい
- (l|P)aaS的なクラウド環境を自分達で付くって自分達で使う
- プライベートクラウド
- クラウドっぽいという言葉が社内で流行
名前
REST
- GET/PUT/DELETE
- Bucketの作成/削除
- Objectの取得/作成/更新/削除
- レプリカの作成数はヘッダで指定
- オリジナル画像は3つくらいレプリカが必要
- サムネイルは再コンバートできるから2つでいいかとか
Example
- http://str.example.com/
は/を含むことが可能 - URIはOSファイルシステムとは独立した論理URI
PUT /ikebe/picture.jpg HTTP/1.1
X-Replication-Count: 3
Content-Length: 10240<内容>
基本戦略
CAP定理
- Consistency
- Availability
- Partition Tolerance
- 一貫性を捨てる
MySQL
Dual Masterが使えるようにAutoIncrement等使ってなくて
PerlのロジックをCにコピペして実装
MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.18 その他の関数
UUID は、スペースおよび時間においてグローバルに一意の数字としてデザインされています。UUID() へのふたつの呼び出しは、互いに接続されていない別々のコンピュータ上で行った場合でも、それぞれ異なるふたつの値を生成することが想定されます。
mod_stf_strage.c
- mod_dav_fileに似ている
- GET/PUT/DELETE メソッドを受け付けてファイルの読み書き
- GETはdefault-handlerに任せ
- PUTはRecursiveにディレクトリを作成
- 同一ファイル名での上書きはできない
- 更新は一回消して内部的には別ファイルを作成
TODO
質問
- ストレージのサイズはどのくらい?
- MAX:20TB-30TB位
- 運用:10T程度
- 月に1Tづつ増える
- mogile FSでは何がダメでSTFなのか
- 作りたい
- mogilefs · GitHubはソースコードが長い
ニーズ
- Webフロントサーバをクラウドにする
- サービス規模に応じて、短時間のリソース増減が可能
- バックエンドは専用サーバ
実装決定までの試行錯誤
技術
目指すもの
- スケールアップ,スケールアウト
- ユーザ操作で即時に行うことが
- なぜ?
- 急激なトラフィック増加があるサービスへの対応
- スモールスタートの規模を最小にとどめて個人開発者の支援
- 人的リソース温存
TODO
- LVS DSR構成
- Auto Scalling
- Auto Scaleも今後対応予定
- PC3?
質問
- DSRでも裁けなくなったらどうする？
- 1顧客の量を制限
- 現状はLVSには余裕があるが、今後増えてきた場合はセットごと追加
- APIを公開することは?
- 今後は必須の条件になってくる
- お値段は?
- EC2よりも性能良くて(メモリ1GB)5,000-6,000
- EC2はネットワーク従量課金であるが、PC2は?
- 社内で賛否両論
- インスタンス監視
- cactiに自動追加
- インスタンスは月額?時間課金?
- まだ話がいっていない
- ログをとっているので1秒単位でも1時間単位でもできる
- お客さまの都合により柔軟に
- インスタンスの重複
- 同じ顧客のインスタンスは同じHWに作らない
- Migration先はシステムが勝手に決める?
- 決めてない
- お客さんに選んでいただいてもよいかな?
livedoor Readerの新機能とは?
自己紹介
- ma.laさん
- ライブドア
- livedoor reader
- livedoor clip
- API,liverary,UIデザイン
- 自社サービスのセキュリティ監査
Livedoor ReaderのStreaming API
- livedoor readerのクロールしているフィードの更新情報をリアルタイムに取得
- キーワードに絞りこみ
- リアルタイム検索エンジン
ポイント
- 外部ドメインでも動く
- 非公開フィードの記事はでない
リアルタイム
- Readerがクロールしたタイミング
Streaming APIのサーバサイド実装
- クローラ
- apache
- nginx+Plackに変更予定
- 5+2台
- mysql
- memcached
- perl
- Q4M
- ジョブ管理
- MySQL(64bit)*2台
- TokyoTyrant
- memcachedの代替
- HashDB*7台
- キャッシュ
- InnoDBPlugin
- 改良されたInnoDB
- データを圧縮してメモリ利用効率向上
- Nginx
- ロシア生まれのWebサーバ
- Streaming APIのフロント
- long-pollコネクション可
- PSGI/Plack
- 負荷試験ツール
- Coroで作られたDoSツール
- 大量のコネクションを張る
- 記事データサイズ
- テキストだけで1TB
- 過去記事の削除->やってない
- 件数不明
- 対象:180Mフィード
- 更新があるフィードは約1時間
- クローラ
- 4台
クローラの処理
Front (古いブラウザ)
- 同一ドメインからAbout | Digg.com
- window.postMessageで呼出て送信
Front (IE)
- window.name+IFRAME間送信
