Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

hbstudy#06

2,981 views

Published on

hbstudy06の資料です

Published in: Technology
  • Be the first to comment

hbstudy#06

  1. 1. システムの運用・監視のコツ 株式会社ハートビーツ 坂口 利樹 2009/12/04
  2. 2. agenda  インフラエンジニアのお仕事  監視とは  なぜ監視が必要なのか  どうやって監視するか  監視チームを作る
  3. 3. 誰?  坂口利樹 ( さかぐちとしき )  twitter : tsakaguchi  Mail : sakaguchi.toshiki@gmail.com  インフラエンジニア  エンジニア歴 2 年半 ( しんそつ )  PostgreSQL Confarence 2009 Tokyo/Fall  実行委員
  4. 4. インフラエンジニアのお仕事 定例業務 定例業務 非定例業務 設計、アーキテクト ● 管理 ● ● ボトルネックの解析・ログ解析 ● 機器・設定情報の管理 高負荷プロセスの分析 ● リソース管理 ● 運用方法・監視方法の検討・提案 ● バックアップ ● 権限・セキュリティ管理 選定 ● ● ネットワーク・サーバ 監視 ● OS ・アプリケーション ● システム・機器の稼働状況、 iDC ・回線等の選定 リソース状況・ログ出力、改竄検知 ● 負荷テスト ● 障害対応 構築 ● 問い合わせ対応・サポート ● ● サーバ、機器のセットアップ ● 社内外からの問い合わせ ラックマウント・ケーブリング SSL 証明書取得・設定
  5. 5. インフラエンジニアのお仕事 定例業務 定例業務 非定例業務 設計、アーキテクト ● 管理 ● ● ボトルネックの解析・ログ解析 ● 機器・設定情報の管理 高負荷プロセスの分析 ● リソース管理 ● 運用方法・監視方法の検討・提案 ● バックアップ ● 権限・セキュリティ管理 選定 ● ● ネットワーク・サーバ 監視 ● OS ・アプリケーション ● システム・機器の稼働状況、 iDC ・回線等の選定 リソース状況・ログ出力、改竄検知 ● 負荷テスト ● 障害対応 構築 ● 問い合わせ対応・サポート ● ● サーバ、機器のセットアップ ● 社内外からの問い合わせ ラックマウント・ケーブリング SSL 証明書取得・設定
  6. 6. 監視とは
  7. 7. 監視とは  システムやネットワークの状況変化を 知るための情報収集活動
  8. 8. なぜ監視が必要なのか
  9. 9. なぜ監視が必要なのか  大前提:ビジネス・サービスが動いている  高可用性が求められる  すべての障害を予期することは困難 機能停止 性能低下 機能監視 性能把握
  10. 10. 監視の種類を分類 機能監視 性能把握 ● L1 〜 L3 ネットワーク ● L4 〜 L7 サービス ● HTTP(S) システムリソース ● POP3(S) CPU 使用量 ● ● ● SMTP(S) ● IMAP(S) ● メモリ使用量 DNS Disk I/O ● ● ● SSH ● (S)FTP ● Network( 遅延・帯域 ) ● DB への接続状態 ● DB の内部状態 ● プロセス死活 ● ログ出力 ● RAID
  11. 11. 監視の種類を分類 機能監視 性能把握 ● L1 〜 L3 ネットワーク ● L4 〜 L7 サービス ● HTTP(S) システムリソース ● POP3(S) CPU 使用量 ● ● ● SMTP(S) ● IMAP(S) ● メモリ使用量 DNS Disk I/O ● ● ● SSH ● (S)FTP ● Network( 遅延・帯域 ) ● DB への接続状態 ● DB の内部状態 ● プロセス死活 ● ログ出力 ● RAID
  12. 12. どうやって監視するか
  13. 13. どうやって監視するか  監視ツールを使う  メリット  既に欲しい機能が作り込まれている  オープンソース  ZABBIX  Hinemos  Nagios  hobbit(Xymon)
  14. 14. Google trend(world) hobbit hinemos zabbix Nagios
  15. 15. Google trend(Japan) hobbit hinemos zabbix Nagios
  16. 16. 監視ツール選定 (1)  機能  スケジューリング  人間のスケジュールに合わせた運用 例:バッチ処理時間帯はある程度の負荷を許容   柔軟性  プラグインで拡張可能か!? Nagios の場合、プラグインの exit code で判定 0: OK 1: WARNING 2: CRITICAL
  17. 17. 監視ツール選定 (2)  性能  Nagios の場合、 3 年前のマシン 1 台で 400 台く らいが目安 Pentium4 3GHz, mem 1GB  で検証→ 400 台、 4000 項目程度は OK  Nagios は AMQP と組み合わせてスケールアウト もできるらしい ( 未検証 )
  18. 18. 監視ツール選定 (3)  運用  設定内容の管理  バージョン管理システム ( ハートビーツでは SVN) で管理できると楽  テスト環境の用意  バージョン管理システムと組み合わせて テスト環境を構築しています  テスト環境はメールが一切飛ばないようにしています
  19. 19. 監視設定手順 2.設定・動作確認 1.チェックアウト Nagios(test) 3.コミット SVN リポジトリ 5.設定反映 4 .チェックアウト Nagios (1) 7.設定反映 Nagios (2) 6.チェックアウト
  20. 20. 監視のポイント  何のサービスが動いているか  最適な監視  必要なところ ( 使っているところ )  監視項目をむやみに増やしすぎない  使う側の視点
  21. 21. 監視サーバのネットワーク  2拠点から監視  別キャリアのネットワーク Nagios(1) Internet 監視対象サーバ Nagios(2)
  22. 22. 監視項目例 (Web サイト )  外部  内部  HTTP/HTTPS  LoadAverage  表示されるまでの時間  メモリ  文字列  プロセス総数  ログイン  ログ出力  シナリオ  プロセス稼働状況  回線使用状況  DB レプリケーション  Disk 残容量  Disk I/O
  23. 23. 監視項目例 (JavaVM)  プロセス死活  ヒープ域不足 (Out of Memory)  OOM Killer によりプロセスが Kill される  Tomcat/Jboss プロセスサイズ  ログ監視
  24. 24. 監視項目例 (MySQL)  Mysql Status の取得  Web サーバから DB サーバへの接続  レプリケーションの状況  テーブルを作成して削除
  25. 25. システム監視だけじゃない!  大事なのはビジネスなので、そのレイヤーまで見る!  IBM 用語で「センス アンド レスポンド」というそうです  例えば・・・  システムのログインユーザ数を監視 (DB へのクエリ結 果)  広告からのサイト流入量を監視 (DB へのクエリ結果 )
  26. 26. 閾値の調整  閾値の決定ポリシー  サービスによって様々  運用しながら  誤報  なくすことはできない(宿命)  減らすことはできる  リトライチェック  根本的な解決を !
  27. 27. 誤報撲滅!  遠い場合 (EC2 、中国にあるサーバ )  パケットロスは容認  リトライ回数を増やす  対応しないアラートは誤報と同じ  「アラートを無視する習慣」につながるので、重点 的になくす!  「アラートを無視する習慣」がついたら一巻の終わ り
  28. 28. 閾値の調整例  どこまでが正常なのか  サイト表示: 3 秒〜 5 秒 ( 目標値 )  LoadAverage : CPU のコア数  SWAP : 20%  プロセス総数 Web サーバ (Apache­prefork) の場合 稼働中のプロセス総数      + (MaxClients­ 稼働中の httpd プロセス数 )
  29. 29. 対応の自動化  イベントハンドラの活用  LB から切り離す  落とし穴に注意 例: Apache の自動再起動スクリプト  セマフォによるリソース管理の上限で Apache が自動起動されず、 web サービスが復旧しない  Apache 管理ユーザのセマフォの削除を手動で行い解決
  30. 30. 監視の種類を分類 障害監視 性能監視 ● L1 〜 L3 ネットワーク死活 ● L4 〜 L7 サービス監視 ● HTTP(S) POP3(S) システムリソース ● ● SMTP(S) ● ● IMAP(S) ● DNS ● CPU SSH メモリ使用量 ● ● (S)FTP ● DB への接続状態・内部 ● Disk I/O ● ● システムリソース ● ログインユーザ数 ● Network プロセス死活 DB の内部状態 ● ● ● CPU ● Memory 使用量 ● SWAP 使用量 ● ディスク空き容量 ● ログ出力
  31. 31. なぜ監視するか  変化の把握  ボトルネックの把握  チューニング  スケールアウト / スケールアップ  後々必要になってくるので早い段階からの実装  キャパシティプランニング  このシステムでどれだけこなせるか  どのタイミングで増設が必要になるか
  32. 32. どうやって監視するか  ツールを使う  MRTG  Cacti  Munin  ZABBIX  Hinemos
  33. 33. 何を監視するか  想定されるボトルネックはどこか?  想定されるトラブルは何か?
  34. 34. 監視項目例 (MySQL)  Cacti  Login Count /Session Count  InnoDB BuffrePool / I/O / Insert Buffer Row Operations / Log Buffer Size.....
  35. 35. さいごに・・・ 監視チームを作る
  36. 36. 監視チームを作る  監視と障害対応は切り離せない  一人ではやりきれない  夜間の障害対応  複数同時の障害  精神的・労務的な問題  24 時間 365 日  4 人は最低必要 ( 休み無し )
  37. 37. 情報共有  アラートメールの送信先  インフラ担当だけでなく開発や企画担当の人も  ドキュメント ( 監視仕様書 )  人を育てるのにも有効
  38. 38. ドキュメントの書き方のコツ  ネットワーク構成図  アプリケーション構成図  対応フローの確定  監視項目ごとの状況確認方法  監視項目ごとの対応方法
  39. 39. アプリケーション構成図 ( 例 ) hb-web01 ハートビーツ Postfix:25 Internet apache(123.123.1.1:80) 共有 FW tomcat(8009) MySQL:3306 (Master) hb-nfs01 apache2(123.123.1.21:80) ト ウン ファイル共有 smb マ ト vsftpd:21 sshd:22 ウン sm bマ rs yn c+ ss h hb-webdev01 バ ッ Postfix:25 ク apache(123.123.2.1:80) ア ッ プ tomcat(8009) MySQL:3306 hb-backup01 MySQL:3307 MySQL:3306 Replication Replication apache2(123.123.2.2:80) Slave Slave rsync+ssh バックアップ sshd:22 vsftpd:21 sshd:22 svn リポジトリ
  40. 40. 監視項目ごとの状況確認方法例
  41. 41. 復旧方法例 (1)
  42. 42. 復旧方法例 (2)
  43. 43. その他気をつける点  ドキュメントの二重管理  対応する人の決定
  44. 44. 対応する人の決定の補足  お見合いが一番怖い  ダウンタイムだけが伸びたら・・・ビジネスに影響大!  誰がボールを持っているか、常に明確に!  アラート同報だと誰がボールを持っているか不明確  深夜の場合、ボールを受け取った後や、対応中にホストダウン ( 居 眠り ) の可能性も・・・  ハートビーツの場合、ひとりずつ電話をかけるのでボールの持ち 主は明確になります 対応完了のご連絡をいただけない場合、ベストエフォートでリ マインドもできます
  45. 45. 終 ご清聴ありがとうございました

×