Infrastructure of Pathtraq

  • 3,768 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,768
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
28
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. パストラックのインフラストラクチャ
    サイボウズ・ラボ株式会社
    奥 一穂
  • 2. 2010年2月23日
    パストラックのインフラストラクチャ
    2
    自己紹介
  • 3. 2010年2月23日
    パストラックのインフラストラクチャ
    3
    自己紹介 – 主な仕事 (1)
    Palmscape (Xiino)
    Palm OS 用ウェブブラウザ (実質世界初)
    IBM, NTTドコモ, Sony 等が採用
    M.I.T. TR100/2002 受賞
    Webアプリケーション統合開発環境の開発
    IPA 未踏 2004 – スーパークリエータ
    Japanize
    外国のウェブサービスUIを日本語化するサービス (ブラウザプラグイン)
  • 4. 自己紹介 – 主な仕事 (2)
    パストラック
    ブラウザプラグインを利用して、「今」注目されている情報を抽出するウェブサービス
    Q4M
    高速なメッセージキュー (MySQLのプラグイン)
    Mixi, livedoor, Ficia, DeNA等が使用
    2010年2月23日
    パストラックのインフラストラクチャ
    4
  • 5. 自己紹介– 最近の仕事
    Incline / Pacific
    RDBMS シャーディングの自動化や動的分割
    Cosmic
    Fail-safe Network RAID
    Plack
    Perl の Web Application Middleware
    宮川さんが主開発者
    自分はプロトコル実装やホットデプロイといった分野にコミット
    2010年2月23日
    パストラックのインフラストラクチャ
    5
  • 6. 自己紹介– まとめ
    基盤プログラムの研究開発が仕事
    ブラウザとかストレージミドルウェアとか
    「インフラプログラマ」?
    今日は、インフラプログラマがインフラを作るとどうなるか、という話
    「こういうツールを作りました」ではなく「こう考えて、楽をしています」という話として聞いていただければ。
    2010年2月23日
    パストラックのインフラストラクチャ
    6
  • 7. パストラックとは?
    2010年2月23日
    パストラックのインフラストラクチャ
    7
  • 8. パストラックの概要 (1)
    ブラウザプラグインを利用したウェブアクセス統計サービス
    サービス開始: 2007年8月
    ページ単位のリアルタイム統計と検索
    注目情報を自動抽出
    2010年2月23日
    パストラックのインフラストラクチャ
    8
  • 9. パストラックの概要 (2)
    2010年2月23日
    パストラックのインフラストラクチャ
    9
  • 10. パストラックのデータセット
    2010年2月23日
    パストラックのインフラストラクチャ
    10
    ※圧縮手法等の改善は随時行っています
  • 11. パストラックの問題
    データセットのサイズ増大
    統計データ (100GB) はランダムアクセスなので RAM に載ってないと危険
    従来のサーバ構成では限界
    MySQL / ウェブサーバ兼用
    メモリ: 64GB
    HDD: 500GB x2
    サーバ構成を見直すことに
    サービス開始から予測していたことではあった
    2010年2月23日
    パストラックのインフラストラクチャ
    11
  • 12. ムーアの法則とサーバ投資
    メモリ要求が時間に比例増加するサービスでは、3年目のシステム投資が最大
    YAPC::Asia 2008 発表資料より
    2010年2月23日
    パストラックのインフラストラクチャ
    12
  • 13. 新しいサーバ構成の方針 (1)
    MySQL専用のサーバ
    その他は VM を利用
    単機能化した仮想サーバを複数
    従来: 1台のサーバが複数の機能を提供
    バックアップ手法の統一
    LVM (含む VM イメージ) による増分バックアップ
    2010年2月23日
    パストラックのインフラストラクチャ
    13
  • 14. 新しいサーバ構成の方針 (2)
    SSD の積極利用
    統計データをSSD 上に配置
    メインメモリ超の統計データをハンドリング可能に
    InnoDBの読み込みだと、7200回転な HDD の 40 倍速 (10,000 IOPS @ 16KB read)
    ただし NCQ に対応した SATA ドライバが必要
    並列度が高いので、1プロセスが全力で I/O しても他のプロセスへの影響が少ないので、運用が楽
    全文検索データは従来から SSD
    eSATApで接続して、故障時の対応を簡単に
    2010年2月23日
    パストラックのインフラストラクチャ
    14
  • 15. 新しいサーバ構成
    2010年2月23日
    パストラックのインフラストラクチャ
    15
    2台 (+1) 構成
    DB専用サーバ
    一般用 VM サーバ
    他に、予備機兼開発機
    マスターDB を SSD 化
    SSD によって、当初予測よりも設備投資コストが大幅減
    DBサーバ
    Mem: 64GB, SSD 160GB*2
    VMサーバ
    Mem: 12GB, SSD 80GB
  • 16. 新しい DB サーバ
    旧サーバに SSD を追加して使い回し
    CPU: Opteron 2218 (Dual Core@2.6GHz) x2
    Mem: 64GB
    HDD: 500GB x2 (本文データ等を配置)
    SSD: X25-M 160GB x2 (統計データ専用)
    eSATAで接続
    MySQL 5.1, Q4M
    2010年2月23日
    パストラックのインフラストラクチャ
    16
    DBサーバ
  • 17. 仮想サーバ群
    リバースプロキシ
    Apache + mod_proxy
    アプリケーションサーバ
    PSSPSS (PSGI の実装) + CGI::Application
    ホットデプロイ可能
    全文検索サーバ
    Tritonnベース
    eSATAで接続された X25-M に格納
    2010年2月23日
    パストラックのインフラストラクチャ
    17
    VMサーバ
  • 18. 仮想サーバのホストにはXenServer
    ハードウェア
    CPU: Opteron 2218 (Dual Core@2.6GHz) x2
    Mem: 12GB
    HDD: 500GB x2
    SSD: X25-M 80GB x1 (全文検索サーバ用)
    eSATAで接続
    XenServer + XenCenterを評価してみたかった
    VMware ESXi + vCenterは既に別用途で運用中
    2010年2月23日
    パストラックのインフラストラクチャ
    18
  • 19. XenServer画面写真
    2010年2月23日
    パストラックのインフラストラクチャ
    19
  • 20. パストラックの運用
    2010年2月23日
    パストラックのインフラストラクチャ
    20
  • 21. デーモンは全てdaemontoolsで管理
    理由: デーモン化処理とプログラムの分離
    多数のワーカープロセスに、いちいちデーモン化処理を実装するのは面倒
     ⇒ daemontools使えばいいよね
     ⇒ だったら Apache やMySQLもdaemontoolsで管理すべきだよね
    2010年2月23日
    パストラックのインフラストラクチャ
    21
  • 22. Server::Starterによるホットデプロイ
    TCP サーバをホットデプロイするためのラッパー
    サービス瞬停なしで、アプリケーションをデプロイ可能
    新バージョンが起動できない場合は旧バージョンがサービス継続
    YAPC::Asia 2009 の LT ネタとして開発
    Plack系のhttpd実装を中心に利用可能
    2010年2月23日
    パストラックのインフラストラクチャ
    22
  • 23. タスクはcronで管理
    普通そうですよね
    統計系のタスク間の排他処理はsetlockで
    I/O 競合を避けるため
    バックアップ処理との競合回避も同様
    タスクが失敗したら、どうする?
    2010年2月23日
    パストラックのインフラストラクチャ
    23
  • 24. Cronlog
    2010年2月23日
    パストラックのインフラストラクチャ
    24
  • 25. Cronlog – 動機
    Cronタスクに失敗した時「だけ」エラーメールを送りたい
    Cronのメール送信機能は使えるか?
    ⇒ Cronのメール送信有無は、タスクの終了ステータスではなく、タスクからの出力の有無
    ⇒ task || echo “error!” じゃダメなの?
    ⇒ task の出力がないと障害解析は難しい
    ⇒ 結論: タスクが異常終了したら、タスクの出力をCron経由でメールするラッパーを書けばいい
    2010年2月23日
    パストラックのインフラストラクチャ
    25
  • 26. Cronlog – 例
    task を実行して非ゼロで終了したら task の出力をメール
    5 0 * * * exec cronlog-- task 2>&1
    task を実行して、その出力を保存しつつ、非ゼロで終了したら、task の出力をメール
    5 0 * * * exec cronlog -t -llogfile -- task 2>&1
    -tオプション: 出力の各行にタイムスタンプをつける
    2010年2月23日
    パストラックのインフラストラクチャ
    26
  • 27. 監視とは継続的なテストである
    2010年2月23日
    パストラックのインフラストラクチャ
    27
  • 28. 監視とは継続的なテストである
    監視=定期的な polling による、条件成立の確認
    Heartbeat の受信等も polling に変換可能
    Unix のツールは、正否を終了コードで返す
    ⇒ だったら、cronlogと既存ツールを組み合わせて監視系を書けるよね?
    2010年2月23日
    パストラックのインフラストラクチャ
    28
  • 29. Cronlog を用いた単純な監視例 (1)
    Ping でサーバの死活監視
    5 * * * * cronlog-- ping -n 5 server 2>&1
    Ping が通らなかったらアラートメール
    メールを見れば、packet loss なのか、no route なのか、DNS lookup error なのか分かる
    ⇒ 迅速な対応が可能
    2010年2月23日
    パストラックのインフラストラクチャ
    29
  • 30. Cronlog を用いた単純な監視例 (2)
    HTTP の監視
    5 * * * * cronlog-- wget-O - http://server/ 2>&1
    httpdが 200 を返さない場合はアラートメール
    接続失敗等でもメール送信
    メールの中身はwgetのエラー出力 (or httpdのエラーレスポンス) なので障害解析が簡単
    2010年2月23日
    パストラックのインフラストラクチャ
    30
  • 31. Cronlogによる統合監視
    Q. 多数の項目を監視することはできる?
    A. プログラミング言語のテストフレームワークを使うことで可能
    メリット: プログラマが、使い慣れたテストフレームワークを使って監視系を構築できる
    出力もプログラマが見慣れた形式
    つまり、プログラマがアプリケーションレベルの監視を行うのに最適
    例: メッセージキューのサイズやキャッシュのヒット率
    2010年2月23日
    パストラックのインフラストラクチャ
    31
  • 32. Cronlogによる統合監視の例
    Perl の場合は prove
    多数の監視テストを critical/*.tとして作成
    5 * * * * cronlog -t -l /var/log/critical_log -- prove -R critical 2>&1
    テストが1つでも失敗すると、アラートメール
    警告レベルの監視を動かしたければ、warning/*.tとか作って prove -R warning すればいい
    2010年2月23日
    パストラックのインフラストラクチャ
    32
  • 33. Cronlog まとめ
    タスク監視とサービス監視の両方が可能
    学習コストが低い
    既存の Unix コマンドと組み合わせて監視
    プログラマにやさしい
    使い慣れたテストフレームワークで監視が書ける
    プログラマが書くテストの一部に「監視テスト」を加えるべき
    プログラマが障害対応する運用に好適
    2010年2月23日
    パストラックのインフラストラクチャ
    33
  • 34. Cronlog関連の、その他もろもろ
    その他、小物
    touch_if
    httpdの応答時間やエラー応答の監視
    ssh_run
    手元のスクリプトをリモートサーバに送り込んで実行
    参照:
    http://developer.cybozu.co.jp/kazuho/2010/01/crontab-f131.html
    http://developer.cybozu.co.jp/kazuho/2010/01/cronlog-52f2.html
    2010年2月23日
    パストラックのインフラストラクチャ
    34
  • 35. パストラックのバックアップ
    2010年2月23日
    パストラックのインフラストラクチャ
    35
  • 36. バックアップソフトウェアの要件
    実質無停止のホットバックアップ
    ボリュームレベルのバックアップ
    MySQLとか VM イメージとか、対象によってバックアップ手法を変えたくない
    インクリメンタルバックアップ
    毎日 300GB ずつデータ増加とか勘弁
    エージェントのインストールが不要
    XenServerの Dom0 にソフトインストールとかやりたくない
    2010年2月23日
    パストラックのインフラストラクチャ
    36
  • 37. 結論:ググるの面倒になったので自作
    以前自作した、データベースファイル用の diff ツールをベースに。
    ブロックデバイスの diff は、バイナリファイルの diff より要件が簡単
    over-sshでのバックアップ
    バックアップ元に空き領域が不要
    Disk Read < Network Speed なので問題なし
    2010年2月23日
    パストラックのインフラストラクチャ
    37
  • 38. Blockdiffの特徴
    設定ファイル不要
    コマンドラインの引数で操作
    エージェントのインストール不要
    フルバックアップと増分バックアップが可能
    LVM Snapshot によるホットバックアップ
    外部のロックプログラムと組み合わせてMyISAM, Tritonn等のバックアップも可能
    2010年2月23日
    パストラックのインフラストラクチャ
    38
  • 39. Blockdiffのアルゴリズム
    ボリュームバックアップの場合:
    エージェントを送り込む
    差分バックアップならば、ブロック毎のMD5ファイルも
    必要なロックを獲得して LVM スナップショット作成
    ロックを解除
    LVM スナップショットを開き、ブロック毎に MD5 を比較して、異なっていたら圧縮転送
    新しい MD5 ファイルを転送
    LVM スナップショットを削除
    ※全て SSH で制御・転送
    2010年2月23日
    パストラックのインフラストラクチャ
    39
  • 40. Blockdiffの使い方
    http://developer.cybozu.co.jp/kazuho/2010/01/blockdiff-linux.html
    2010年2月23日
    パストラックのインフラストラクチャ
    40
  • 41. パストラックにおけるBlockdiffの運用
    日毎で増分バックアップ
    毎月1日はフルバックアップ
    バックアップ単位
    DB データのある論理ボリューム
    XenServerの LVM ベースの仮想ディスク
    BlockdiffとXenServerのスナップショットは併用不可
    バックアップの監視はcronlog
    統計タスクとの排他処理はsetlock
    2010年2月23日
    パストラックのインフラストラクチャ
    41
  • 42. Blockdiffの限界
    ≒LVM の限界
    スナップショットの差分だけを取ることができない
    ブロックデバイスのサイズに比例してバックアップに時間がかかる (I/O コストが増大)
    ⇒ 10分ごとのバックアップとかできない
    zfsiscsiなら可能なのに
    バックアップイメージから論理バックアップを取り出すのが面倒
    rollback がないので
    いずれもzfsiscsiなら可能
    2010年2月23日
    パストラックのインフラストラクチャ
    42
  • 43. Blockdiff余談
    メインのロジックは Perl
    元は C だったけど Perl に変更
    C はコンパイラが必要だし 64bit only は、まだ無理
    XenServerの Dom0 は 32bit
    ボトルネックはMD5 の計算だけど、ネイティブライブラリだから問題ない
    Perl / Python は Linux Standards Base に入った
    今後は shell script を書く機会が減りそう
    LL で書いた方が生産性が高いし、速いし
    2010年2月23日
    パストラックのインフラストラクチャ
    43
  • 44. まとめ
    2010年2月23日
    パストラックのインフラストラクチャ
    44
  • 45. まとめ (1)
    パストラックではコマンドラインツールを組み合わせて監視・運用を実現
    ツールの種類を減らすことで TCO 削減
    デーモン管理はdaemontools (svc)
    タスク処理はCron + setlock
    VM イメージと DB データのバックアップはBlockdiff
    サービス監視はperlのテスト
    ロギングと障害通知はCronlog
    2010年2月23日
    パストラックのインフラストラクチャ
    45
  • 46. まとめ (2)
    どのツールを選ぶかは、目的次第
    汎用的 (だけど複雑) なツールの TCO が優れているとは限らない
    「奥が深い」症候群に罹患していませんか?
    細かなツールの組み合わせで書くのがいいケースも
    2010年2月23日
    パストラックのインフラストラクチャ
    46