Infrastructure of Pathtraq
- 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 / PacificRDBMS シャーディングの自動化や動的分割CosmicFail-safe Network RAIDPlackPerl の Web Application Middleware宮川さんが主開発者自分はプロトコル実装やホットデプロイといった分野にコミット2010年2月23日パストラックのインフラストラクチャ5
- 11. パストラックの問題データセットのサイズ増大統計データ (100GB) はランダムアクセスなので RAM に載ってないと危険従来のサーバ構成では限界MySQL / ウェブサーバ兼用メモリ: 64GBHDD: 500GB x2サーバ構成を見直すことにサービス開始から予測していたことではあった2010年2月23日パストラックのインフラストラクチャ11
- 12. ムーアの法則とサーバ投資メモリ要求が時間に比例増加するサービスでは、３年目のシステム投資が最大YAPC::Asia 2008 発表資料より2010年2月23日パストラックのインフラストラクチャ12
- 13. 新しいサーバ構成の方針 (1)MySQL専用のサーバその他は VM を利用単機能化した仮想サーバを複数従来: １台のサーバが複数の機能を提供バックアップ手法の統一LVM (含む VM イメージ) による増分バックアップ2010年2月23日パストラックのインフラストラクチャ13
- 14. 新しいサーバ構成の方針 (2)SSD の積極利用統計データをSSD 上に配置メインメモリ超の統計データをハンドリング可能にInnoDBの読み込みだと、7200回転な HDD の 40 倍速 (10,000 IOPS @ 16KB read)ただし NCQ に対応した SATA ドライバが必要並列度が高いので、１プロセスが全力で I/O しても他のプロセスへの影響が少ないので、運用が楽全文検索データは従来から SSDeSATApで接続して、故障時の対応を簡単に2010年2月23日パストラックのインフラストラクチャ14
- 15. 新しいサーバ構成2010年2月23日パストラックのインフラストラクチャ15２台 (+1) 構成DB専用サーバ一般用 VM サーバ他に、予備機兼開発機マスターDB を SSD 化SSD によって、当初予測よりも設備投資コストが大幅減DBサーバMem: 64GB, SSD 160GB*2VMサーバMem: 12GB, SSD 80GB
- 16. 新しい DB サーバ旧サーバに SSD を追加して使い回しCPU: Opteron 2218 (Dual Core@2.6GHz) x2Mem: 64GBHDD: 500GB x2 (本文データ等を配置)SSD: X25-M 160GB x2 (統計データ専用)eSATAで接続MySQL 5.1, Q4M2010年2月23日パストラックのインフラストラクチャ16DBサーバ
- 17. 仮想サーバ群リバースプロキシApache + mod_proxyアプリケーションサーバPSSPSS (PSGI の実装) + CGI::Applicationホットデプロイ可能全文検索サーバTritonnベースeSATAで接続された X25-M に格納2010年2月23日パストラックのインフラストラクチャ17VMサーバ
- 18. 仮想サーバのホストにはXenServerハードウェアCPU: Opteron 2218 (Dual Core@2.6GHz) x2Mem: 12GBHDD: 500GB x2SSD: X25-M 80GB x1 (全文検索サーバ用)eSATAで接続XenServer + XenCenterを評価してみたかったVMware ESXi + vCenterは既に別用途で運用中2010年2月23日パストラックのインフラストラクチャ18
- 21. デーモンは全てdaemontoolsで管理理由: デーモン化処理とプログラムの分離多数のワーカープロセスに、いちいちデーモン化処理を実装するのは面倒 ⇒ daemontools使えばいいよね ⇒ だったら Apache やMySQLもdaemontoolsで管理すべきだよね2010年2月23日パストラックのインフラストラクチャ21
- 22. Server::StarterによるホットデプロイTCP サーバをホットデプロイするためのラッパーサービス瞬停なしで、アプリケーションをデプロイ可能新バージョンが起動できない場合は旧バージョンがサービス継続YAPC::Asia 2009 の LT ネタとして開発Plack系のhttpd実装を中心に利用可能2010年2月23日パストラックのインフラストラクチャ22
- 25. Cronlog – 動機Cronタスクに失敗した時「だけ」エラーメールを送りたいCronのメール送信機能は使えるか?⇒ Cronのメール送信有無は、タスクの終了ステータスではなく、タスクからの出力の有無⇒ task || echo “error!” じゃダメなの?⇒ task の出力がないと障害解析は難しい⇒ 結論: タスクが異常終了したら、タスクの出力をCron経由でメールするラッパーを書けばいい2010年2月23日パストラックのインフラストラクチャ25
- 26. Cronlog – 例task を実行して非ゼロで終了したら task の出力をメール5 0 * * * exec cronlog-- task 2>&1task を実行して、その出力を保存しつつ、非ゼロで終了したら、task の出力をメール5 0 * * * exec cronlog -t -llogfile -- task 2>&1-tオプション: 出力の各行にタイムスタンプをつける2010年2月23日パストラックのインフラストラクチャ26
- 28. 監視とは継続的なテストである監視＝定期的な polling による、条件成立の確認Heartbeat の受信等も polling に変換可能Unix のツールは、正否を終了コードで返す⇒ だったら、cronlogと既存ツールを組み合わせて監視系を書けるよね?2010年2月23日パストラックのインフラストラクチャ28
- 29. Cronlog を用いた単純な監視例 (1)Ping でサーバの死活監視5 * * * * cronlog-- ping -n 5 server 2>&1Ping が通らなかったらアラートメールメールを見れば、packet loss なのか、no route なのか、DNS lookup error なのか分かる⇒ 迅速な対応が可能2010年2月23日パストラックのインフラストラクチャ29
- 30. Cronlog を用いた単純な監視例 (2)HTTP の監視5 * * * * cronlog-- wget-O - http://server/ 2>&1httpdが 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テストが１つでも失敗すると、アラートメール警告レベルの監視を動かしたければ、warning/*.tとか作って prove -R warning すればいい2010年2月23日パストラックのインフラストラクチャ32
- 33. Cronlog まとめタスク監視とサービス監視の両方が可能学習コストが低い既存の Unix コマンドと組み合わせて監視プログラマにやさしい使い慣れたテストフレームワークで監視が書けるプログラマが書くテストの一部に「監視テスト」を加えるべきプログラマが障害対応する運用に好適2010年2月23日パストラックのインフラストラクチャ33
- 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
- 41. パストラックにおけるBlockdiffの運用日毎で増分バックアップ毎月１日はフルバックアップバックアップ単位DB データのある論理ボリュームXenServerの LVM ベースの仮想ディスクBlockdiffとXenServerのスナップショットは併用不可バックアップの監視はcronlog統計タスクとの排他処理はsetlock2010年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
- 45. まとめ (1)パストラックではコマンドラインツールを組み合わせて監視・運用を実現ツールの種類を減らすことで TCO 削減デーモン管理はdaemontools (svc)タスク処理はCron + setlockVM イメージと DB データのバックアップはBlockdiffサービス監視はperlのテストロギングと障害通知はCronlog2010年2月23日パストラックのインフラストラクチャ45
- 46. まとめ (2)どのツールを選ぶかは、目的次第汎用的 (だけど複雑) なツールの TCO が優れているとは限らない「奥が深い」症候群に罹患していませんか?細かなツールの組み合わせで書くのがいいケースも2010年2月23日パストラックのインフラストラクチャ46