Contenu connexe
Similaire à Infrastructure of Pathtraq (20)
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 / Pacific RDBMS シャーディングの自動化や動的分割 Cosmic Fail-safe Network RAID Plack Perl の Web Application Middleware 宮川さんが主開発者 自分はプロトコル実装やホットデプロイといった分野にコミット 2010年2月23日 パストラックのインフラストラクチャ 5
- 6. 自己紹介– まとめ 基盤プログラムの研究開発が仕事 ブラウザとかストレージミドルウェアとか 「インフラプログラマ」? 今日は、インフラプログラマがインフラを作るとどうなるか、という話 「こういうツールを作りました」ではなく「こう考えて、楽をしています」という話として聞いていただければ。 2010年2月23日 パストラックのインフラストラクチャ 6
- 11. パストラックの問題 データセットのサイズ増大 統計データ (100GB) はランダムアクセスなので RAM に載ってないと危険 従来のサーバ構成では限界 MySQL / ウェブサーバ兼用 メモリ: 64GB HDD: 500GB x2 サーバ構成を見直すことに サービス開始から予測していたことではあった 2010年2月23日 パストラックのインフラストラクチャ 11
- 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 しても他のプロセスへの影響が少ないので、運用が楽 全文検索データは従来から SSD eSATApで接続して、故障時の対応を簡単に 2010年2月23日 パストラックのインフラストラクチャ 14
- 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
- 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
- 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 テストが１つでも失敗すると、アラートメール 警告レベルの監視を動かしたければ、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
- 38. Blockdiffの特徴 設定ファイル不要 コマンドラインの引数で操作 エージェントのインストール不要 フルバックアップと増分バックアップが可能 LVM Snapshot によるホットバックアップ 外部のロックプログラムと組み合わせてMyISAM, Tritonn等のバックアップも可能 2010年2月23日 パストラックのインフラストラクチャ 38
- 39. Blockdiffのアルゴリズム ボリュームバックアップの場合: エージェントを送り込む 差分バックアップならば、ブロック毎のMD5ファイルも 必要なロックを獲得して LVM スナップショット作成 ロックを解除 LVM スナップショットを開き、ブロック毎に MD5 を比較して、異なっていたら圧縮転送 新しい MD5 ファイルを転送 LVM スナップショットを削除 ※全て SSH で制御・転送 2010年2月23日 パストラックのインフラストラクチャ 39
- 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 + setlock VM イメージと DB データのバックアップはBlockdiff サービス監視はperlのテスト ロギングと障害通知はCronlog 2010年2月23日 パストラックのインフラストラクチャ 45
- 46. まとめ (2) どのツールを選ぶかは、目的次第 汎用的 (だけど複雑) なツールの TCO が優れているとは限らない 「奥が深い」症候群に罹患していませんか? 細かなツールの組み合わせで書くのがいいケースも 2010年2月23日 パストラックのインフラストラクチャ 46
