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

2.
2010年2月23日<br />パストラックのインフラストラクチャ<br />2<br />自己紹介<br />

3.
2010年2月23日<br />パストラックのインフラストラクチャ<br />3<br />自己紹介 – 主な仕事 (1)<br />Palmscape (Xiino)<br />Palm OS 用ウェブブラウザ (実質世界初)<br />IBM, NTTドコモ, Sony 等が採用<br />M.I.T. TR100/2002 受賞<br />Webアプリケーション統合開発環境の開発<br />IPA 未踏 2004 – スーパークリエータ<br />Japanize<br />外国のウェブサービスUIを日本語化するサービス (ブラウザプラグイン)<br />

4.
自己紹介 – 主な仕事 (2)<br />パストラック<br />ブラウザプラグインを利用して、「今」注目されている情報を抽出するウェブサービス<br />Q4M<br />高速なメッセージキュー (MySQLのプラグイン)<br />Mixi, livedoor, Ficia, DeNA等が使用<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />4<br />

5.
自己紹介– 最近の仕事<br />Incline / Pacific<br />RDBMS シャーディングの自動化や動的分割<br />Cosmic<br />Fail-safe Network RAID<br />Plack<br />Perl の Web Application Middleware<br />宮川さんが主開発者<br />自分はプロトコル実装やホットデプロイといった分野にコミット<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />5<br />

6.
自己紹介– まとめ<br />基盤プログラムの研究開発が仕事<br />ブラウザとかストレージミドルウェアとか<br />「インフラプログラマ」?<br />今日は、インフラプログラマがインフラを作るとどうなるか、という話<br />「こういうツールを作りました」ではなく「こう考えて、楽をしています」という話として聞いていただければ。<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />6<br />

7.
パストラックとは?<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />7<br />

8.
パストラックの概要 (1)<br />ブラウザプラグインを利用したウェブアクセス統計サービス<br />サービス開始: 2007年8月<br />ページ単位のリアルタイム統計と検索<br />注目情報を自動抽出<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />8<br />

9.
パストラックの概要 (2)<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />9<br />

10.
パストラックのデータセット<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />10<br />※圧縮手法等の改善は随時行っています<br />

11.
パストラックの問題<br />データセットのサイズ増大<br />統計データ (100GB) はランダムアクセスなので RAM に載ってないと危険<br />従来のサーバ構成では限界<br />MySQL / ウェブサーバ兼用<br />メモリ: 64GB<br />HDD: 500GB x2<br />サーバ構成を見直すことに<br />サービス開始から予測していたことではあった<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />11<br />

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

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

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

15.
新しいサーバ構成<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />15<br />２台 (+1) 構成<br />DB専用サーバ<br />一般用 VM サーバ<br />他に、予備機兼開発機<br />マスターDB を SSD 化<br />SSD によって、当初予測よりも設備投資コストが大幅減<br />DBサーバ<br />Mem: 64GB, SSD 160GB*2<br />VMサーバ<br />Mem: 12GB, SSD 80GB<br />

16.
新しい DB サーバ<br />旧サーバに SSD を追加して使い回し<br />CPU: Opteron 2218 (Dual Core@2.6GHz) x2<br />Mem: 64GB<br />HDD: 500GB x2 (本文データ等を配置)<br />SSD: X25-M 160GB x2 (統計データ専用)<br />eSATAで接続<br />MySQL 5.1, Q4M<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />16<br />DBサーバ<br />

17.
仮想サーバ群<br />リバースプロキシ<br />Apache + mod_proxy<br />アプリケーションサーバ<br />PSSPSS (PSGI の実装) + CGI::Application<br />ホットデプロイ可能<br />全文検索サーバ<br />Tritonnベース<br />eSATAで接続された X25-M に格納<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />17<br />VMサーバ<br />

18.
仮想サーバのホストにはXenServer<br />ハードウェア<br />CPU: Opteron 2218 (Dual Core@2.6GHz) x2<br />Mem: 12GB<br />HDD: 500GB x2<br />SSD: X25-M 80GB x1 (全文検索サーバ用)<br />eSATAで接続<br />XenServer + XenCenterを評価してみたかった<br />VMware ESXi + vCenterは既に別用途で運用中<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />18<br />

19.
XenServer画面写真<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />19<br />

20.
パストラックの運用<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />20<br />

21.
デーモンは全てdaemontoolsで管理<br />理由: デーモン化処理とプログラムの分離<br />多数のワーカープロセスに、いちいちデーモン化処理を実装するのは面倒<br /> ⇒ daemontools使えばいいよね<br /> ⇒ だったら Apache やMySQLもdaemontoolsで管理すべきだよね<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />21<br />

22.
Server::Starterによるホットデプロイ<br />TCP サーバをホットデプロイするためのラッパー<br />サービス瞬停なしで、アプリケーションをデプロイ可能<br />新バージョンが起動できない場合は旧バージョンがサービス継続<br />YAPC::Asia 2009 の LT ネタとして開発<br />Plack系のhttpd実装を中心に利用可能<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />22<br />

23.
タスクはcronで管理<br />普通そうですよね<br />統計系のタスク間の排他処理はsetlockで<br />I/O 競合を避けるため<br />バックアップ処理との競合回避も同様<br />タスクが失敗したら、どうする?<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />23<br />

24.
Cronlog<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />24<br />

25.
Cronlog – 動機<br />Cronタスクに失敗した時「だけ」エラーメールを送りたい<br />Cronのメール送信機能は使えるか?<br />⇒ Cronのメール送信有無は、タスクの終了ステータスではなく、タスクからの出力の有無<br />⇒ task || echo “error!” じゃダメなの?<br />⇒ task の出力がないと障害解析は難しい<br />⇒ 結論: タスクが異常終了したら、タスクの出力をCron経由でメールするラッパーを書けばいい<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />25<br />

26.
Cronlog – 例<br />task を実行して非ゼロで終了したら task の出力をメール<br />5 0 * * * exec cronlog-- task 2>&1<br />task を実行して、その出力を保存しつつ、非ゼロで終了したら、task の出力をメール<br />5 0 * * * exec cronlog -t -llogfile -- task 2>&1<br />-tオプション: 出力の各行にタイムスタンプをつける<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />26<br />

27.
監視とは継続的なテストである<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />27<br />

28.
監視とは継続的なテストである<br />監視＝定期的な polling による、条件成立の確認<br />Heartbeat の受信等も polling に変換可能<br />Unix のツールは、正否を終了コードで返す<br />⇒ だったら、cronlogと既存ツールを組み合わせて監視系を書けるよね?<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />28<br />

29.
Cronlog を用いた単純な監視例 (1)<br />Ping でサーバの死活監視<br />5 * * * * cronlog-- ping -n 5 server 2>&1<br />Ping が通らなかったらアラートメール<br />メールを見れば、packet loss なのか、no route なのか、DNS lookup error なのか分かる<br />⇒ 迅速な対応が可能<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />29<br />

30.
Cronlog を用いた単純な監視例 (2)<br />HTTP の監視<br />5 * * * * cronlog-- wget-O - http://server/ 2>&1<br />httpdが 200 を返さない場合はアラートメール<br />接続失敗等でもメール送信<br />メールの中身はwgetのエラー出力 (or httpdのエラーレスポンス) なので障害解析が簡単<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />30<br />

31.
Cronlogによる統合監視<br />Q. 多数の項目を監視することはできる?<br />A. プログラミング言語のテストフレームワークを使うことで可能<br />メリット: プログラマが、使い慣れたテストフレームワークを使って監視系を構築できる<br />出力もプログラマが見慣れた形式<br />つまり、プログラマがアプリケーションレベルの監視を行うのに最適<br />例: メッセージキューのサイズやキャッシュのヒット率<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />31<br />

32.
Cronlogによる統合監視の例<br />Perl の場合は prove<br />多数の監視テストを critical/*.tとして作成<br />5 * * * * cronlog -t -l /var/log/critical_log -- prove -R critical 2>&1<br />テストが１つでも失敗すると、アラートメール<br />警告レベルの監視を動かしたければ、warning/*.tとか作って prove -R warning すればいい<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />32<br />

33.
Cronlog まとめ<br />タスク監視とサービス監視の両方が可能<br />学習コストが低い<br />既存の Unix コマンドと組み合わせて監視<br />プログラマにやさしい<br />使い慣れたテストフレームワークで監視が書ける<br />プログラマが書くテストの一部に「監視テスト」を加えるべき<br />プログラマが障害対応する運用に好適<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />33<br />

34.
Cronlog関連の、その他もろもろ<br />その他、小物<br />touch_if<br />httpdの応答時間やエラー応答の監視<br />ssh_run<br />手元のスクリプトをリモートサーバに送り込んで実行<br />参照:<br />http://developer.cybozu.co.jp/kazuho/2010/01/crontab-f131.html<br />http://developer.cybozu.co.jp/kazuho/2010/01/cronlog-52f2.html<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />34<br />

35.
パストラックのバックアップ<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />35<br />

36.
バックアップソフトウェアの要件<br />実質無停止のホットバックアップ<br />ボリュームレベルのバックアップ<br />MySQLとか VM イメージとか、対象によってバックアップ手法を変えたくない<br />インクリメンタルバックアップ<br />毎日 300GB ずつデータ増加とか勘弁<br />エージェントのインストールが不要<br />XenServerの Dom0 にソフトインストールとかやりたくない<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />36<br />

37.
結論：ググるの面倒になったので自作<br />以前自作した、データベースファイル用の diff ツールをベースに。<br />ブロックデバイスの diff は、バイナリファイルの diff より要件が簡単<br />over-sshでのバックアップ<br />バックアップ元に空き領域が不要<br />Disk Read < Network Speed なので問題なし<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />37<br />

38.
Blockdiffの特徴<br />設定ファイル不要<br />コマンドラインの引数で操作<br />エージェントのインストール不要<br />フルバックアップと増分バックアップが可能<br />LVM Snapshot によるホットバックアップ<br />外部のロックプログラムと組み合わせてMyISAM, Tritonn等のバックアップも可能<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />38<br />

39.
Blockdiffのアルゴリズム<br />ボリュームバックアップの場合:<br />エージェントを送り込む<br />差分バックアップならば、ブロック毎のMD5ファイルも<br />必要なロックを獲得して LVM スナップショット作成<br />ロックを解除<br />LVM スナップショットを開き、ブロック毎に MD5 を比較して、異なっていたら圧縮転送<br />新しい MD5 ファイルを転送<br />LVM スナップショットを削除<br />※全て SSH で制御・転送<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />39<br />

40.
Blockdiffの使い方<br />http://developer.cybozu.co.jp/kazuho/2010/01/blockdiff-linux.html<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />40<br />

41.
パストラックにおけるBlockdiffの運用<br />日毎で増分バックアップ<br />毎月１日はフルバックアップ<br />バックアップ単位<br />DB データのある論理ボリューム<br />XenServerの LVM ベースの仮想ディスク<br />BlockdiffとXenServerのスナップショットは併用不可<br />バックアップの監視はcronlog<br />統計タスクとの排他処理はsetlock<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />41<br />

42.
Blockdiffの限界<br />≒LVM の限界<br />スナップショットの差分だけを取ることができない<br />ブロックデバイスのサイズに比例してバックアップに時間がかかる (I/O コストが増大)<br />⇒ 10分ごとのバックアップとかできない<br />zfsiscsiなら可能なのに<br />バックアップイメージから論理バックアップを取り出すのが面倒<br />rollback がないので<br />いずれもzfsiscsiなら可能<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />42<br />

43.
Blockdiff余談<br />メインのロジックは Perl<br />元は C だったけど Perl に変更<br />C はコンパイラが必要だし 64bit only は、まだ無理<br />XenServerの Dom0 は 32bit<br />ボトルネックはMD5 の計算だけど、ネイティブライブラリだから問題ない<br />Perl / Python は Linux Standards Base に入った<br />今後は shell script を書く機会が減りそう<br />LL で書いた方が生産性が高いし、速いし<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />43<br />

44.
まとめ<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />44<br />

45.
まとめ (1)<br />パストラックではコマンドラインツールを組み合わせて監視・運用を実現<br />ツールの種類を減らすことで TCO 削減<br />デーモン管理はdaemontools (svc)<br />タスク処理はCron + setlock<br />VM イメージと DB データのバックアップはBlockdiff<br />サービス監視はperlのテスト<br />ロギングと障害通知はCronlog<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />45<br />

46.
まとめ (2)<br />どのツールを選ぶかは、目的次第<br />汎用的 (だけど複雑) なツールの TCO が優れているとは限らない<br />「奥が深い」症候群に罹患していませんか?<br />細かなツールの組み合わせで書くのがいいケースも<br />2010年2月23日<br />パストラックのインフラストラクチャ<br />46<br />