infrastructure of pathtraq

パストラックのインフラストラクチャ

サイボウズ・ラボ株式会社奥　一穂

パストラックのインフラストラクチャ 22010 年 2 月 23 日

自己紹介

パストラックのインフラストラクチャ 32010 年 2 月 23 日

自己紹介 – 主な仕事 (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 日


自己紹介 – 最近の仕事

Incline / PacificRDBMS シャーディングの自動化や動的分割

CosmicFail-safe Network RAID

PlackPerl の Web Application Middleware宮川さんが主開発者自分はプロトコル実装やホットデプロイといっ

た分野にコミット

2010 年 2 月 23 日


自己紹介 – まとめ

基盤プログラムの研究開発が仕事ブラウザとかストレージミドルウェアとか「インフラプログラマ」 ?

今日は、インフラプログラマがインフラを作るとどうなるか、という話「こういうツールを作りました」ではなく「こ

う考えて、楽をしています」という話として聞いていただければ。

2010 年 2 月 23 日


パストラックとは ?

2010 年 2 月 23 日


パストラックの概要 (1)

ブラウザプラグインを利用したウェブアクセス統計サービスサービス開始 : 2007 年 8 月

ページ単位のリアルタイム統計と検索注目情報を自動抽出

2010 年 2 月 23 日


パストラックの概要 (2)

2010 年 2 月 23 日


パストラックのデータセット

2008/4 2010/2

サンプルユーザー ( アクティブ )

6,300 12,500

アクセスの収集数 ( 日毎 ) 約 100 万 160 万

アクセスの収集数 ( 累計 ) 1 億 8 億

統計データサイズ 16GB 100GB

総データサイズ 100GB 230GB

2010 年 2 月 23 日

※ 圧縮手法等の改善は随時行っています


パストラックの問題

データセットのサイズ増大統計データ (100GB) はランダムアクセスなの

で RAM に載ってないと危険従来のサーバ構成では限界

MySQL / ウェブサーバ兼用メモリ : 64GBHDD: 500GB x2

サーバ構成を見直すことにサービス開始から予測していたことではあった

2010 年 2 月 23 日


ムーアの法則とサーバ投資

メモリ要求が時間に比例増加するサービスでは、３年目のシステム投資が最大YAPC::Asia 2008 発表資料より

2010 年 2 月 23 日

1 2 3 4 5 6 7 8 9 10

Year

Data SizeMoore's LawSystem Cost


新しいサーバ構成の方針 (1)

MySQL 専用のサーバその他は VM を利用

単機能化した仮想サーバを複数従来 : １台のサーバが複数の機能を提供

バックアップ手法の統一LVM ( 含む VM イメージ ) による増分バック

アップ

2010 年 2 月 23 日


新しいサーバ構成の方針 (2)

SSD の積極利用統計データを SSD 上に配置

メインメモリ超の統計データをハンドリング可能にInnoDB の読み込みだと、 7200 回転な HDD

の 40 倍速 (10,000 IOPS @ 16KB read)ただし NCQ に対応した SATA ドライバが必要並列度が高いので、１プロセスが全力で I/O しても

他のプロセスへの影響が少ないので、運用が楽全文検索データは従来から SSDeSATAp で接続して、故障時の対応を簡単に

2010 年 2 月 23 日


新しいサーバ構成

2010 年 2 月 23 日

２台 (+1) 構成DB 専用サーバ一般用 VM サーバ他に、予備機兼開発機

マスター DB を SSD 化SSD によって、当初予測よりも設備投資コストが大幅減

DB サーバMem: 64GB, SSD 160GB*2

VM サーバMem: 12GB, SSD 80GB


新しい DB サーバ

旧サーバに SSD を追加して使い回しCPU: Opteron 2218 (Dual [email protected]) x2Mem: 64GBHDD: 500GB x2 ( 本文データ等を配置 )SSD: X25-M 160GB x2 ( 統計データ専用 )

eSATA で接続

MySQL 5.1, Q4M

2010 年 2 月 23 日

DB サーバ


仮想サーバ群

リバースプロキシApache + mod_proxy

アプリケーションサーバPSSPSS (PSGI の実装 ) + CGI::Application

ホットデプロイ可能

全文検索サーバTritonn ベース

eSATA で接続された X25-M に格納

2010 年 2 月 23 日

VM サーバ


仮想サーバのホストには XenServer

ハードウェアCPU: Opteron 2218 (Dual [email protected]) x2Mem: 12GBHDD: 500GB x2SSD: X25-M 80GB x1 (全文検索サーバ用 )

eSATA で接続

XenServer + XenCenter を評価してみたかったVMware ESXi + vCenter は既に別用途で運用中

2010 年 2 月 23 日


XenServer 画面写真

2010 年 2 月 23 日


パストラックの運用

2010 年 2 月 23 日


デーモンは全て daemontools で管理

理由 : デーモン化処理とプログラムの分離多数のワーカープロセスに、いちいちデーモン

化処理を実装するのは面倒　⇒ daemontools 使えばいいよね　⇒ だったら Apache や MySQL も

daemontools で管理すべきだよね

2010 年 2 月 23 日


Server::Starter によるホットデプロイ

TCP サーバをホットデプロイするためのラッパーサービス瞬停なしで、アプリケーションをデプ

ロイ可能新バージョンが起動できない場合は旧バージョ

ンがサービス継続YAPC::Asia 2009 の LT ネタとして開

発Plack 系の httpd 実装を中心に利用可能

2010 年 2 月 23 日


タスクは cron で管理

普通そうですよね統計系のタスク間の排他処理は

setlock でI/O 競合を避けるためバックアップ処理との競合回避も同様

タスクが失敗したら、どうする ?

2010 年 2 月 23 日


Cronlog

2010 年 2 月 23 日


Cronlog – 動機

Cron タスクに失敗した時「だけ」エラーメールを送りたいCron のメール送信機能は使えるか ?⇒ Cron のメール送信有無は、タスクの終了ス

テータスではなく、タスクからの出力の有無⇒ task || echo “error!” じゃダメなの ?⇒ task の出力がないと障害解析は難しい⇒ 結論 : タスクが異常終了したら、タスクの出力

を Cron 経由でメールするラッパーを書けばいい

2010 年 2 月 23 日


Cronlog – 例

task を実行して非ゼロで終了したら task の出力をメール5 0 * * * exec cronlog -- task 2>&1

task を実行して、その出力を保存しつつ、非ゼロで終了したら、 task の出力をメール5 0 * * * exec cronlog -t -l logfile -- task

2>&1-t オプション : 出力の各行にタイムスタンプをつける

2010 年 2 月 23 日


監視とは継続的なテストである

2010 年 2 月 23 日


監視とは継続的なテストである

監視＝定期的な polling による、条件成立の確認Heartbeat の受信等も polling に変換可能

Unix のツールは、正否を終了コードで返す⇒ だったら、 cronlog と既存ツールを組み合わせて監視系を書けるよね ?

2010 年 2 月 23 日


Cronlog を用いた単純な監視例 (1)

Ping でサーバの死活監視5 * * * * cronlog -- ping -n 5 server 2>&1

Ping が通らなかったらアラートメールメールを見れば、 packet loss なのか、 no

route なのか、 DNS lookup error なのか分かる⇒ 迅速な対応が可能

2010 年 2 月 23 日


Cronlog を用いた単純な監視例 (2)

HTTP の監視5 * * * * cronlog -- wget -O - http://server/

2>&1

httpd が 200 を返さない場合はアラートメール接続失敗等でもメール送信メールの中身は wget のエラー出力 (or httpd

のエラーレスポンス ) なので障害解析が簡単

2010 年 2 月 23 日

http://server/


Cronlog による統合監視

Q. 多数の項目を監視することはできる ?A. プログラミング言語のテストフレームワーク

を使うことで可能メリット : プログラマが、使い慣れた

テストフレームワークを使って監視系を構築できる出力もプログラマが見慣れた形式つまり、プログラマがアプリケーションレベル

の監視を行うのに最適例 : メッセージキューのサイズやキャッシュのヒッ

ト率

2010 年 2 月 23 日


Cronlog による統合監視の例

Perl の場合は prove多数の監視テストを critical/*.t として作成5 * * * * cronlog -t -l /var/log/critical_log --

prove -R critical 2>&1テストが１つでも失敗すると、アラートメール警告レベルの監視を動かしたけれ

ば、 warning/*.t とか作って prove -R warning すればいい

2010 年 2 月 23 日


Cronlog まとめ

タスク監視とサービス監視の両方が可能

学習コストが低い既存の Unix コマンドと組み合わせて監視

プログラマにやさしい使い慣れたテストフレームワークで監視が書け

るプログラマが書くテストの一部に「監視テス

ト」を加えるべきプログラマが障害対応する運用に好適

2010 年 2 月 23 日


Cronlog 関連の、その他もろもろ

その他、小物touch_if

httpd の応答時間やエラー応答の監視ssh_run

手元のスクリプトをリモートサーバに送り込んで実行

参照 :http://developer.cybozu.co.jp/kazuho/2010/

01/crontab-f131.htmlhttp://developer.cybozu.co.jp/kazuho/

2010/01/cronlog-52f2.html

2010 年 2 月 23 日

http://developer.cybozu.co.jp/kazuho/2010/01/crontab-f131.html

http://developer.cybozu.co.jp/kazuho/2010/01/crontab-f131.html


パストラックのバックアップ

2010 年 2 月 23 日


バックアップソフトウェアの要件

実質無停止のホットバックアップボリュームレベルのバックアップ

MySQL とか VM イメージとか、対象によってバックアップ手法を変えたくない

インクリメンタルバックアップ毎日 300GB ずつデータ増加とか勘弁

エージェントのインストールが不要XenServer の Dom0 にソフトインストールと

かやりたくない2010 年 2 月 23 日


結論：ググるの面倒になったので自作

以前自作した、データベースファイル用の diff ツールをベースに。ブロックデバイスの diff は、バイナリファイル

の diff より要件が簡単over-ssh でのバックアップ

バックアップ元に空き領域が不要Disk Read < Network Speed なので問題なし

2010 年 2 月 23 日


Blockdiff の特徴

設定ファイル不要コマンドラインの引数で操作

エージェントのインストール不要フルバックアップと増分バックアップ

が可能LVM Snapshot によるホットバック

アップ外部のロックプログラムと組み合わせて

MyISAM, Tritonn 等のバックアップも可能2010 年 2 月 23 日


Blockdiff のアルゴリズム

ボリュームバックアップの場合 :1. エージェントを送り込む

差分バックアップならば、ブロック毎の MD5 ファイルも

2. 必要なロックを獲得して LVM スナップショット作成

3. ロックを解除4. LVM スナップショットを開き、ブロック毎に

MD5 を比較して、異なっていたら圧縮転送5. 新しい MD5 ファイルを転送6. LVM スナップショットを削除

※全て SSH で制御・転送

2010 年 2 月 23 日


Blockdiff の使い方

http://developer.cybozu.co.jp/kazuho/2010/01/blockdiff-linux.html

2010 年 2 月 23 日


パストラックにおける Blockdiff の運用

日毎で増分バックアップ毎月１日はフルバックアップ

バックアップ単位DB データのある論理ボリュームXenServer の LVM ベースの仮想ディスク

Blockdiff と XenServer のスナップショットは併用不可

バックアップの監視は cronlog統計タスクとの排他処理は setlock

2010 年 2 月 23 日


Blockdiff の限界

≒LVM の限界スナップショットの差分だけを取ることができ

ないブロックデバイスのサイズに比例してバックアップに

時間がかかる (I/O コストが増大 )⇒ 10 分ごとのバックアップとかできない

zfs iscsi なら可能なのに

バックアップイメージから論理バックアップを取り出すのが面倒rollback がないので

いずれも zfs iscsi なら可能2010 年 2 月 23 日


Blockdiff 余談

メインのロジックは Perl元は C だったけど Perl に変更C はコンパイラが必要だし 64bit only は、ま

だ無理XenServer の Dom0 は 32bit

ボトルネックは MD5 の計算だけど、ネイティブライブラリだから問題ない

Perl / Python は Linux Standards Base に入った今後は shell script を書く機会が減りそうLL で書いた方が生産性が高いし、速いし

2010 年 2 月 23 日


まとめ

2010 年 2 月 23 日


まとめ (1)

パストラックではコマンドラインツールを組み合わせて監視・運用を実現

ツールの種類を減らすことで TCO 削減デーモン管理は daemontools (svc)タスク処理は Cron + setlock

VM イメージと DB データのバックアップは Blockdiff

サービス監視は perl のテストロギングと障害通知は Cronlog

2010 年 2 月 23 日


まとめ (2)

どのツールを選ぶかは、目的次第汎用的 ( だけど複雑 ) なツールの TCO が優れ

ているとは限らない「奥が深い」症候群に罹患していませんか ?

細かなツールの組み合わせで書くのがいいケースも

2010 年 2 月 23 日

infrastructure of pathtraq

Technology