【イベント参加レポート】 MicroBlogCon #1

観測気球

収集物の記録書庫 a data archive of collection -- collectible toys

[要旨] MicroBlogCon #1 のレポートを公開します。MicroBlogCon というより、Q4M Con という感じでしたが、なかなか面白いイベントでした。
[キーワード] Q4M,memcached,Gearman,TheSchwartz,Wassr,Twitter,mixi

« パソコンでデコメの作成・送受信ができるWEBメールサービス「PAGMail (パグメール)」 | トップページ | 今週のお買い物 (2008.10.12~10.18) »

2008.10.18

【イベント参加レポート】 MicroBlogCon #1

2008年8月27日にサイボウズラボで開かれた「MicroBlogCon #1」の参加レポートというか、メモです。例によって、遅くなってしまいましたが、せっかくなので公開します)。

ちなみに、この日の前日(8月26日)から Tech・Ed 2008 Yokohama (のレポートももうすぐ公開する予定) に参加するため関東にいました。26日の夜は、Twitter の中の人を囲む会に出席。イベント続きの月末でした。

メモ

以下、会場で取ったメモをほとんどそのまま載せています。気が付いた範囲で直していますが、まだ、聞き間違い、勘違いしているところ等、残っているでしょう。気づいた方は、ここ、おかしいよ、とか指摘してください。

MicroBlogCon #1  2008年8月27日 @サイボウズラボ
  公式サイト
    http://soozy.org/index.cgi?MicroblogCon1
  動画
    http://techtalk.jp/2008/08/microblog-conference-1.html
    http://www.nicovideo.jp/mylist/8144722 (当日の模様を録画したもの)

(1) inside Echo (kazeburo/長野さん)
・エコーとは
   mixi のマイクロブログサービス
     通常の書き込み
     りぷらい

     自分へのりぷらいの一覧
     アクセス制限なし(指定IDの人のエコーが見える)

・mixi のデータベースアーキテクチャ
   mixiの歴史
     2004年開始、完全招待制
     1500万ユーザ
     アクティブ率56% (3日に1回以上アクセスしている人)
     いまモバイルのほうが圧倒的に多い

   I/O の分散の歴史
     スレイブをどんどん追加
     データベースのクラスタリング
     read の分散はできても write の負荷は高いまま → パーティショニング
        ID ごとに分散

   パーティショニングの課題
     auto increment の代用
     最新のマイミクの書き込みの取得 (最新情報DB)
       全員のデータを保持
       古いデータをcronで削除
       スケールアップ
        マイミクは最大1000人

・エコーのアーキテクチャ
   パーティショニング
     autoincrement の ID をなくした
     あけおめ、ことよろアタックに耐える
   ID Generator
     限界 … inoDB  250ID辺りでデッドロック
     すべてのメッセージを通してのIDは持たないようにする
     メンバーID + タイムスタンプ をプライマリキーにすることで管理
        タイムスタンプが重なったときは、いちばん最初のだけが残る
   最新情報のWriteの分散
     時間軸的な分散
     遅延書き込み

   キュー
    TheSchwartz (six apart製)
      MySQL にキューをためる
      auto increment の ID
    Q4M
      高速、書き込み性能高い
      Pathtraq での実績
      API がシンプル
      kazuhooku++

    遅延対策
      memmcached を利用
      最新1件を保持、最新情報DBとマージ

    worker
      Q4M (最新情報DB)
      MySQLのサーバに乗っける
      1プロセス/1台
      daemontools
         定期的にリブート

Q4M を mixi のキューシステムの標準にしていこうと考えている


(2) Queueueueueueue (tokuhirom)
    Gearman/TheSchwartz と Q4M

    client / gearmand / worker
    gearmand: perl module
      ためこみすぎると大変なことに
    gearman worker
      select(2)で待っているのでリアルタイム 
    gearman client
      perl, ruby, python

   Danga::Socket
     非同期に結果を受け取れる

   Wassr ではできるだけ gearman を使いたくない
      Danga::Socket なサーバでブロッキング

   フックでやること多すぎ
     Apache でやると重いので、別プロセスでやる (fav otsune とか)

   TheSchwartz
     インストールが楽
     1秒に1回SQL(select文)うってジョブがないか見てる
     リアルタイム性が不要なときに使う

     用途
       Feedの生成、画像ブログパーツ
       cronのスクリプトgearman → TheSchwartz

   Gearmand
     信頼性がない
     よく落ちる お茶目な存在

   TheSchwartz と Gearman の連携
     多少遅れてもいいようなのに適用

   Q4M
    インストールがうまくいかなくてあきらめた


(3) memcached pluggable engine concept (toru maesaka)
合体
  キャッシュゾーンをモジュール化

  キャッシュサーバである必要がなくなる
  ハッシュデータベース
  レプリケーション専用サーバ
  プロキシ専用のサーバ

なぜ?
  データを永続化したい、冗長化したい
  高速なキューサーバを楽に作りたい

  memcached の fork (派生版) が多いのはもったいない
  → プラグイン化

  engine_handle 構造体 で管理
    create_instance()  唯一エクスポートする関数

もっと情報をエンジンに与えたい
  スタートアップオプションを追加
   複数のオプションはどうするか? → エンジンにまかせる
  ランタイムで追加情報をエンジンに与えたい (運用中にモード変更とか)
    バイナリプロトコルを使えば可能
      reserved 2バイト
      data 1バイト
       の3バイトが未使用なので、これらを使って渡す

リリースの目安
  バイナリプロトコルのサポートが最優先
  1.4 でプラグインサポート


(4) Q4M a high perfomance message queue for MySQL (Kazuho Oku)
MySQL 用のメッセージキューモジュール

デザインゴール
  堅牢性
    クラッシュや停電時にデータロストしない
  高速性
  柔軟性
    特定のデータだけキューに入れる

メッセージオリエンテッドミドルウェア
メッセージキューは一時的なストレージであって、データベースではない

  ・送信側と受信側が同一のキューにアクセス
  ・送信側と受信側で別のキューを使う (遅延アクセス、途中であて先を変更できる、マルチキャスト、etc)
  ・メッセージブローカー

Q4M はこれら全部のパターンが書ける

パフォーマンス
  ・複数のスレッドからの要求を単一のi/oリクエストにしてしまう
  ・7655メッセージ/秒
  ・23000 I/Oリクエスト/秒

オーナーモードとノンオーナーモード
  オーナーモード: 処理中の行のみ見える
    queue_wait()

    queue_end()
    queue_abort()

制限
  インデックスがない
  UPDATE文がない
  SELECT文とDELETE文はある

実例
 pathtraq
 mixiエコー
 Webクローラー (Q4M のサンプルとして同梱)

優先度つきのキュー


(5) clientアプリの矜持 (kan/ふしはらかん/wasaco の人)
  アクセス頻度が高い
  キャッシュによって負荷を回避
  サーバ側でユーザのキャッシュをもつ
  設定が頻繁に変わる

  サーバ側じゃなくてクライアント側でやった方がいい
  そもそもhttpを使わない xmpp, irc → スケールするプロトコルを使う
  シンプルなサーバと高機能なクライアント
  wasaco はサーバにやさしいクライアント


(6) acotie のドキドキperlプログラミング (acotie)
プレゼンツールは、yappo氏の plusen を使っている

適度にフィードバックすることが大切
Twitter での特定ユーザの発言の解析
mecab を使っている

WWW:Mechanize
  指定ユーザの発言10ページ分(RSS)を取るのに使っている

XML::RSS
  取得したRSSから発言を抜き出すのに使用

MeCab
  発言を形態素解析 → 単語をピックアップ

今のところ、単に単語の一覧を生成しているだけ
  (まだ、使用頻度順に単語をリストアップするとかはしてないらしい)

CPANモジュールを有効に使いましょう


(7) 空気を読む (yappo)
Twitter では空前の UTF-7 ブーム
苦情も来る

 ブラウザで見ると何も見えない(反転表示させると見える。ひみつのメッセージ風)
   早速 WassrPad に実装してみた (デコード、エンコードとも対応)


(8) MicroBlog におけるSPAM対策 (tasukuchan)
  SPAM対策が重要、困難
  多くのユーザに発言が届く
  発言内容が短いので判断が難しい

  CodeRepos も microBlog
   SPAM にやられた例
     コミット連続100回とか
   SPAM があることを啓蒙
     CodeRepos類似サービスで 130コミットをやってみた

  2ch の全発言が push されてくるサービスを作ろうとしている

イベント後の飲み会で、nipotanさんやmalaさんに会うことができたのがよかった。

投稿者: tsupo 2008.10.18 午前 02:35 | 固定リンク | このエントリーをはてなブックマークに追加 | このエントリを del.icio.us に登録 このエントリの del.icio.us での登録状況 | このエントリを Buzzurl に追加このエントリの Buzzurl での登録状況 | このエントリをlivedoorクリップに登録 このエントリのlivedoorクリップでの登録状況 このエントリをlivedoorクリップに登録している人の数 | 酢鶏巡回中

楽天市場


Twitter」カテゴリ内の最近の記事

プログラミング」カテゴリ内の最近の記事

品揃え豊富で安い!NTT-X Store


アマゾンわくわく探検隊

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/6737/42451495

この記事へのトラックバック一覧です: 【イベント参加レポート】 MicroBlogCon #1:

コメント

コメントを書く




※イタズラ防止のため、メールアドレスを入力しないと投稿できません。

次からのコメント入力の手間を省くために、名前やメールアドレスをcookieに記憶しますか?


URL を入力すると、その URL にリンクがはられます。
なお、メールアドレスは公開されません。ご安心ください。


ワード

ニッセン

fujisan.co.jp

楽天市場