Webtech Walker

第三回ライブドアテックセミナーにいってきた

メモとれた部分だけ。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..)
  • サポート掲示板の開始
  • カード決済対応予定
このエントリーをはてなブックマークに追加