hbstudy06の資料です

1. システムの運用・監視のコツ
株式会社ハートビーツ
坂口 利樹
２００９／１２／０４

2. agenda

インフラエンジニアのお仕事

監視とは

なぜ監視が必要なのか

どうやって監視するか

監視チームを作る

3. 誰？

坂口利樹 ( さかぐちとしき )
 twitter ： tsakaguchi
 Mail ： sakaguchi.toshiki@gmail.com

インフラエンジニア

エンジニア歴 2 年半 ( しんそつ )

PostgreSQL Confarence 2009 Tokyo/Fall 実行委員

4. インフラエンジニアのお仕事
定例業務
定例業務 非定例業務
設計、アーキテクト
●
管理
● ●
ボトルネックの解析・ログ解析
●
機器・設定情報の管理 高負荷プロセスの分析
●
リソース管理 ●
運用方法・監視方法の検討・提案
●
バックアップ
●
権限・セキュリティ管理 選定
●
●
ネットワーク・サーバ
監視
●
OS ・アプリケーション
●
システム・機器の稼働状況、 iDC ・回線等の選定
リソース状況・ログ出力、改竄検知 ●
負荷テスト
●
障害対応
構築
●
問い合わせ対応・サポート
● ●
サーバ、機器のセットアップ
●
社内外からの問い合わせ ラックマウント・ケーブリング
SSL 証明書取得・設定

5. インフラエンジニアのお仕事
定例業務
定例業務 非定例業務
設計、アーキテクト
●
管理
● ●
ボトルネックの解析・ログ解析
●
機器・設定情報の管理 高負荷プロセスの分析
●
リソース管理 ●
運用方法・監視方法の検討・提案
●
バックアップ
●
権限・セキュリティ管理 選定
●
●
ネットワーク・サーバ
監視
●
OS ・アプリケーション
●
システム・機器の稼働状況、 iDC ・回線等の選定
リソース状況・ログ出力、改竄検知 ●
負荷テスト
●
障害対応
構築
●
問い合わせ対応・サポート
● ●
サーバ、機器のセットアップ
●
社内外からの問い合わせ ラックマウント・ケーブリング
SSL 証明書取得・設定

6. 監視とは

8. 監視とは

システムやネットワークの状況変化を
知るための情報収集活動

9. なぜ監視が必要なのか

10. なぜ監視が必要なのか

大前提：ビジネス・サービスが動いている

高可用性が求められる

すべての障害を予期することは困難
機能停止 性能低下
機能監視 性能把握

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. 監視の種類を分類
機能監視 性能把握
●
L1 〜 L3 ネットワーク
●
L4 〜 L7 サービス
● HTTP(S) システムリソース
●
POP3(S)
CPU 使用量
●
●
● SMTP(S)
● IMAP(S) ●
メモリ使用量
DNS
Disk I/O
●
●
● SSH
● (S)FTP ●
Network( 遅延・帯域 )
●
DB への接続状態 ●
DB の内部状態
●
プロセス死活
●
ログ出力
● RAID

13. どうやって監視するか

14. どうやって監視するか

監視ツールを使う

メリット

既に欲しい機能が作り込まれている

オープンソース
 ZABBIX
 Hinemos
 Nagios
 hobbit(Xymon)

15. Google trend(world)
hobbit hinemos
zabbix Nagios

16. Google trend(Japan)
hobbit hinemos
zabbix Nagios

17. 監視ツール選定 (1)

機能

スケジューリング

人間のスケジュールに合わせた運用
例：バッチ処理時間帯はある程度の負荷を許容

柔軟性

プラグインで拡張可能か！？
Nagios の場合、プラグインの exit code で判定
0: OK
1: WARNING
2: CRITICAL

18. 監視ツール選定 (2)

性能
 Nagios の場合、 3 年前のマシン 1 台で 400 台く
らいが目安
Pentium4 3GHz, mem 1GB で検証→ 400 台、 4000 項目程度は OK

Nagios は AMQP と組み合わせてスケールアウト
もできるらしい ( 未検証 )

19. 監視ツール選定 (3)

運用

設定内容の管理

バージョン管理システム ( ハートビーツでは SVN)
で管理できると楽

テスト環境の用意

バージョン管理システムと組み合わせて
テスト環境を構築しています

テスト環境はメールが一切飛ばないようにしています

20. 監視設定手順
２．設定・動作確認 １．チェックアウト
Nagios(test)
３．コミット SVN リポジトリ
５．設定反映
4 ．チェックアウト
Nagios （１）
７．設定反映
Nagios （２） ６．チェックアウト

21. 監視のポイント

何のサービスが動いているか

最適な監視

必要なところ ( 使っているところ )

監視項目をむやみに増やしすぎない

使う側の視点

22. 監視サーバのネットワーク

２拠点から監視

別キャリアのネットワーク
Nagios(1)
Internet 監視対象サーバ
Nagios(2)

23. 監視項目例 (Web サイト )

外部 
内部
 HTTP/HTTPS  LoadAverage

表示されるまでの時間 
メモリ

文字列 
プロセス総数

ログイン 
ログ出力

シナリオ 
プロセス稼働状況

回線使用状況 
DB レプリケーション

Disk 残容量
 Disk I/O

24. 監視項目例 (JavaVM)

プロセス死活

ヒープ域不足 (Out of Memory)
 OOM Killer によりプロセスが Kill される

Tomcat/Jboss プロセスサイズ

ログ監視

25. 監視項目例 (MySQL)

Mysql Status の取得
 Web サーバから DB サーバへの接続

レプリケーションの状況

テーブルを作成して削除

26. システム監視だけじゃない！

大事なのはビジネスなので、そのレイヤーまで見る！
 IBM 用語で「センス アンド レスポンド」というそうです

例えば・・・

システムのログインユーザ数を監視 (DB へのクエリ結
果)
 広告からのサイト流入量を監視 (DB へのクエリ結果 )

27. 閾値の調整

閾値の決定ポリシー

サービスによって様々

運用しながら

誤報

なくすことはできない（宿命）

減らすことはできる

リトライチェック

根本的な解決を !

28. 誤報撲滅！

遠い場合 (EC2 、中国にあるサーバ )

パケットロスは容認

リトライ回数を増やす

対応しないアラートは誤報と同じ

「アラートを無視する習慣」につながるので、重点
的になくす！

「アラートを無視する習慣」がついたら一巻の終わ
り

29. 閾値の調整例

どこまでが正常なのか
 サイト表示： 3 秒〜 5 秒 ( 目標値 )

LoadAverage ： CPU のコア数

SWAP ： 20%

プロセス総数
Web サーバ (Apache­prefork) の場合
稼働中のプロセス総数
＋
(MaxClients­ 稼働中の httpd プロセス数 )

30. 対応の自動化

イベントハンドラの活用

LB から切り離す

落とし穴に注意
例： Apache の自動再起動スクリプト
 セマフォによるリソース管理の上限で Apache が自動起動されず、
web サービスが復旧しない

Apache 管理ユーザのセマフォの削除を手動で行い解決

31. 監視の種類を分類
障害監視 性能監視
●
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 使用量
●
ディスク空き容量
●
ログ出力

32. なぜ監視するか

変化の把握

ボトルネックの把握

チューニング
 スケールアウト / スケールアップ

後々必要になってくるので早い段階からの実装

キャパシティプランニング

このシステムでどれだけこなせるか

どのタイミングで増設が必要になるか

33. どうやって監視するか

ツールを使う
 MRTG
 Cacti
 Munin
 ZABBIX
 Hinemos

34. 何を監視するか

想定されるボトルネックはどこか？

想定されるトラブルは何か？

35. 監視項目例 (MySQL)
 Cacti
 Login Count /Session Count
InnoDB BuffrePool / I/O / Insert Buffer
Row Operations / Log Buffer Size.....

36. さいごに・・・
監視チームを作る

37. 監視チームを作る

監視と障害対応は切り離せない

一人ではやりきれない

夜間の障害対応

複数同時の障害

精神的・労務的な問題
 24 時間 365 日

4 人は最低必要 ( 休み無し )

38. 情報共有

アラートメールの送信先

インフラ担当だけでなく開発や企画担当の人も

ドキュメント ( 監視仕様書 )

人を育てるのにも有効

39. ドキュメントの書き方のコツ

ネットワーク構成図

アプリケーション構成図

対応フローの確定

監視項目ごとの状況確認方法

監視項目ごとの対応方法

40. アプリケーション構成図 ( 例 )
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 リポジトリ

41. 監視項目ごとの状況確認方法例

42. 復旧方法例 (1)

43. 復旧方法例 (2)

44. その他気をつける点

ドキュメントの二重管理

対応する人の決定

45. 対応する人の決定の補足

お見合いが一番怖い

ダウンタイムだけが伸びたら・・・ビジネスに影響大！

誰がボールを持っているか、常に明確に！

アラート同報だと誰がボールを持っているか不明確

深夜の場合、ボールを受け取った後や、対応中にホストダウン ( 居
眠り ) の可能性も・・・

ハートビーツの場合、ひとりずつ電話をかけるのでボールの持ち
主は明確になります
対応完了のご連絡をいただけない場合、ベストエフォートでリ
マインドもできます

46. 終
ご清聴ありがとうございました