• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Infrastructure of Pathtraq
 

Infrastructure of Pathtraq

on

  • 5,000 views

 

Statistics

Views

Total Views
5,000
Views on SlideShare
3,641
Embed Views
1,359

Actions

Likes
2
Downloads
28
Comments
0

5 Embeds 1,359

http://developer.cybozu.co.jp 1343
http://webcache.googleusercontent.com 8
http://www.slideshare.net 6
http://j2k.naver.com 1
http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Infrastructure of Pathtraq Infrastructure of Pathtraq Presentation Transcript

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