メモとれた部分だけ。malaさんの話しがいろんな意味で面白かった。

クラウド時代のWebストレージ戦略

• クラウドとは

  • SaaSとかPaaSとかIaaS

• いいところ

  • 物理的なサーバーとかネットワークを意識しない
  • 高可用性、柔軟な課金体制
  • スケールアウトが用意
  • リソースを有効活用できる
  • 管理運用が容易

• ライブドア的環境

  • 物理サーバーは既にある
  • 提供しているサービスはSaaS的なもの
  • さらに効率あげたい
  • (I|P)ssP的な環境をつくりたい

• クラウドっぽい環境を作って自分たちで使う。プライベートクラウド的なものを構築したい

• ライブドアが求めるもの

  • ライブドアは画像アップのサービスが多い
  • webサービスのメディアストレージ（動画とか）
  • 安価に容量を拡張可能
  • 実際の構成は「あまり」意識したくない

つくってみた

• 名前 STF(STorage Farm)（後付け）
• HTTPを利用した分散ストレージ
• シンプルなkey-value（階層構造とかはストレージのレイヤーでは不要）
• クライアント側からは巨大なストレージプールとして
• レプリケーション
• Apacheモジュールベースなので拡張可能
• ファイルシステムとしてマウントできない
• パーミッション/アクセス制御できない（自分達で使うものなのでまあいいか）
• 認証は他のApacheモジュール

• REST的APIで操作可能

  • リソースに対してリクエストを発行
  • GET/PUT/DELETEをサポート
  • パケットの作成/削除
  • オブジェクトの取得/作成/更新/削除

• Example

  • http://stf.exsample.com/<bucket>/<key>
  • <key>は/を含むことが可能

• 内部の話し

  • 極力コード書きたくないのですでにあるものを作る（バグを入れたくないのでコードを書かない）
  • 作りながらサービスに投入
  • Apache + MySQL + MessageQueue(ActiveMQ|Q4M) + Perl + memcached
  • オブジェクトIDはMySQLのauto incrementにしたくなるけどdual masterができなくなるのでperlのData::UUIDをCにコピペした
  • 削除はMySQLでdeleteして即座にレスポンスを返してMessage Queueで実際のファイルを消している
  • mod_stf_storagはmod_dav_fileに非常に似ている
  • 実ファイル名は毎回ユニークになうように生成
  • Webでの管理用インターフェースはCatalystでつくった
  • MySQLはオーバースペックなのでやめたい（どうせkey/valueなので）

ライブドア流クラウド風サービス

• ライブドアの強み

  • webサービスに強い
  • DATAHOTELというデータセンタを運用
  • 回線、インフラを自社で運用

• クラウドの利点

  • 短時間でサーバー増設
  • 動的なリソースの増減

• Webのフロントをクラウドにするのがいいんじゃないか

• バックエンドは専用サーバーにする

• ストレージサーバーは占有

• 仮想化

  • VMwareはライセンス高い
  • KVMはそれぞれのサーバーに専用のプログラムを導入する必要がある
  • Parallelsはライブドアのレンタルサーバーとかでも使ってるのでParallelsにした

技術編

• ぽこぽことサーバーを増やすのでぽこぽこクラウド
• ParallelsServer4BareMetal + CentOS 5.4 x86_64
• LVSでロードバランシング
• ネットワークはtag VLAN
• Parallelsのライブマイグレーションは高価なストレージは必ずしも必要ない
• リアルサーバーのリソースがたりなくなったらライブマイグレーションでスケールアップ
• ライブマイグレーションは容量が多いと時間がかかるのでドキドキ
• コントロールパネルを用意してユーザーはそこから色々操作させる
• 冗長構成管理とかマイグレーションもユーザーが操作できるようにしたい
• 顧客に管理を任せることで人的リソースを割く必要がなくなる
• 1インスタンスをとても安い価格でだす予定
• 今後はDSR構成、オートスケーリング
• 価格はEC2のスモールよりいいスペックで5000~6000円くらいを狙ってる
• トラフィックを課金にするかは検討中
• cactiで監視

Livedoor Reader Streaming API

• フィードの更新情報をリアルタイムで取得できるAPI
• キーワード検索とかできる
• 外部ドメインでも普通に動く
• 非公開フィードの記事はでない
• ベータテスト中なので仕様とかかわるかも
• クローラーが動くタイミングなのでエントリーが投稿されるタイミングじゃない
• PubSubHubbub対応サービスは本当にリアルタイム

• つかってるもの

  • Q4M
  • TokyoTyrant
  • nginx
  • InnoDBPlugin
  • PSGI/Plack
  • Coro
  • AnyEventy
  • etc..

• Coroで作られたDosツールとかで負荷試験

• データサイズ圧縮中で1TBくらい（テキストのみ）

• クローラーは Broker Fetcher Perser Updaterに分割されてる

• これらをQ4Mでリレーする

• ワーカーはdaemontoolsで動かす

• FetcherはCoroで並列にリクエスト

• ParserはXML::LibXML + XML::Liberal + 独自

• Parserは並列にしてもあんま意味なし

• Updater 記事の振り分けしてMySQLに入れる

• SKIP、INSERT、UPDATE、SILENT_UPDATEという4つの状態がある

• フィード毎に既出のフラグを保持してる

• memcached から TokyoTyrantに

• 複数記事のINSERTはまとめて行う

• 既出フラグはfeedごとにまとめた

• 更新されてないののに使されてないフィード

• 前回のパース結果(Perlのオブジェクト)をTokyoTyrantとかに保存してそれと見比べる

• Async::Queue

  • AnyEvent + JSON RPC
  • Q4Mで色々問題があったので自作のQueueサーバーつくった
  • リクエストとレスポンスはJSON
  • キューの先読み
  • 物理的に遠いケースで有用
  • 遅延Publich
  • 先読みバッファがなくなっていない場合は終了しない
  • 落ちないことより落ちても大丈夫なようにするのが重要
  • 優先度のサポート

• MMQ

  • AnyEvent + JSON RPC（みたいなもの）
  • JSONをフィルタするサーバー
  • 安定してきたら公開する

• Javascript側

  • MXHR(Multipart XHR)
  • Crossdomain XHR
  • window.postMessage(HTML5の仕様に含まれてる)
  • IE対応もiframeの入れ子でがんばってる
  • window.nameでデータを引き渡す
  • できるだけ新しいブラウザでやってください

ニフティクラウド

• ニフティによるクラウド提供
• クラウドプラットフォームになる条件をニフティは満たしてる
• ニフティはクラウド？→条件は満たしてる
• 約5分で準備可能
• コントロールパネルの提供
• システム資源のプール化
• 選べる料金体系
• サーバーはCentOS 5.3
• RedHat系も準備中
• Mini Small Small4 Medium Large
• ネットワークはniftyのものと共用→巨大なバックボーン
• Miniだけ制限がある
• ヘルプデスクサービス、監視サポート、プレミアムサポートを近いうちに用意する
• 利用までは5日と8分
• niftyIDの取得が5日くらいかかる。もってる人は8分で可能
• プライベートLANのオプションを使うとネットワークを自分のところだけ分けれる
• 月額課金の選択には注意→月末に申し込むと一ヶ月分かかる
• SSHキーの紛失はやばし
• iptablesの閉じすぎに注意（FW提供予定）
• 32bit版はメモリ2BGまで
• VMwareつかってる
• とにかく疎結合
• いい機能であっても大きくなれないなら使わない
• ニフティと一体の基盤
• DRSで均等になるように
• 壊れたときに以下に早く復旧させるかが大事
• サーバーはなんでもいい
• VLANが多すぎて大変
• APIサポートするよ
• OSも追加予定(Windows2008, RHEL etx..)
• サポート掲示板の開始
• カード決済対応予定