Infrastructure of Pathtraq

パストラックのインフラストラクチャサイボウズ・ラボ株式会社奥　一穂

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

ムーアの法則とサーバ投資メモリ要求が時間に比例増加するサービスでは、３年目のシステム投資が最大 YAPC::Asia 2008 発表資料より 2010年2月23日パストラックのインフラストラクチャ 12

新しいサーバ構成の方針 (1) MySQL専用のサーバその他は VM を利用単機能化した仮想サーバを複数従来: １台のサーバが複数の機能を提供バックアップ手法の統一 LVM (含む VM イメージ) による増分バックアップ 2010年2月23日パストラックのインフラストラクチャ 13

新しいサーバ構成の方針 (2) SSD の積極利用統計データをSSD 上に配置メインメモリ超の統計データをハンドリング可能に InnoDBの読み込みだと、7200回転な HDD の 40 倍速 (10,000 IOPS @ 16KB read) ただし NCQ に対応した SATA ドライバが必要並列度が高いので、１プロセスが全力で I/O しても他のプロセスへの影響が少ないので、運用が楽全文検索データは従来から SSD eSATApで接続して、故障時の対応を簡単に 2010年2月23日パストラックのインフラストラクチャ 14

新しいサーバ構成 2010年2月23日パストラックのインフラストラクチャ 15 ２台 (+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 テストが１つでも失敗すると、アラートメール警告レベルの監視を動かしたければ、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の運用日毎で増分バックアップ毎月１日はフルバックアップバックアップ単位 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

Infrastructure of Pathtraq

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Infrastructure of Pathtraq

Semelhante a Infrastructure of Pathtraq (20)

Mais de Kazuho Oku

Mais de Kazuho Oku (20)

Infrastructure of Pathtraq