2019年5月29日開催のニフクラ エンジニアミートアップ「令和初のクラウド監視超入門　監視ツール活用の基礎」における富士通クラウドテクノロジーズ株式会社仮想インフラサービス部吉村晃氏のLT資料。

1. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
クラウド上のシステム監視 入門編
~「入門 監視」を例に考えてみる~
20190529_Nifcloud_Meetup_LTSv.1.0

2. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
トピック
◼クラウド環境での監視(初心者向け)
• IaaSでそもそも監視いる？
• どういうところから始めたらよいか
• なにを監視したらいい
◼監視デザイン・アンチパターンとニフクラ
• いくつかのパターンと自分たちを見比べてみる

3. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
自己紹介
◼プロフィール
• 吉村 晃
• 富士通クラウドテクノロジーズ (ニフティ2014年入社)
• 仮想インフラサービス部(IaaSのインフラ周り運用部隊)
• 主にVMware関連の運用・監視・ツール基盤などを担当
◼業務でよくお世話になるもの
◼業務でみている管理VM数は大体300~
• DRサービス用システム
• 監視システム
• ログ基盤

4. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
クラウド環境での監視
Confidential ｜ 4

5. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
IaaSでそもそも監視いる？
◼いります
◼なぜ監視するのか
• IaaSの責任分界点(OSから上は見ない/見えない)
◼監視無しだとどうなるか
• 問題解決(or サポート)が遅くなる/できなくなる
• ボトルネックを特定できない
• ビジネス上の指針を持てなくなる
( https://pfs.nifcloud.com/security/ )

6. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
とはいえ監視って何から始めれば
◼最近良い本が出ていました
◼監視についてざっくり知るには十分
• デザインパターン・アンチパターン
• アラート対応
• 各種メトリクスの取扱い など
• ひとまず監視の原則(~4章)を読む(1h位)
◼この本をベースにまず触ってみることが大事
• 物足りなくなったらGoogleのSRE本や、「詳解 システムパフォーマンス」
などへどうぞ
O'Reilly Japan - 入門 監視
https://www.oreilly.co.jp/bo
oks/9784873118642/

7. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
なぜ監視を触ってみることが大事か
◼監視内容より、普段の状況を知っていることのほうが重要
• 「何かが起きている」ことが分かれば最初の壁は超えている
◼システムは変わるし、利用状況も変わる。監視も変わる
• 「監視疲れ」を避けるため、見ないデータ(アラート)は入れない
• データに依存する場所も多いが触ってないと気づきにくい
◼注力するのはドメイン知識の獲得であって、仕組みではない
• 仕組みはSaaSなどで極力省力化し、振る舞いについて共有する
• (監視が安定するまでに数ヶ月~年単位で時間がかかることもある)

8. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
なにを監視する
◼最初は各OSで見える基本的な要素で十分
• CPU / Mem / Disk / Network( 使用率・枯渇・周期 )
• 問題時に知りたいのは何時が起点なのか、何をしていたのか
• これらの情報を確認できるだけで大分助かるはず
◼Application performance management(APM)
• アプリケーションやDBなど関して、より特化した情報が見える
• レスポンスタイム・エラー率・重いクエリなど

9. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
FJCTインフラ部(私の周り)と
「入門監視」デザイン・アンチパターン
(時間があれば)
Confidential ｜ 9

10. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
アンチパターン1 (「入門 監視」より)
◼「ツール依存」
• 何かを始めるのにまずツールありきで考えてしまう
• 万能ツール(銀の弾丸)は無いのに求めてしまう
◼若干当てはまる部分はあります
• とりあえず / でやろう とか
◼得意分野から外れていないかは気にしたほうが良い
• ツール乗り換えを考慮して、あえて2系統でやってみることも
• 利用者を考えると見るツールはまとめたほうが良い
( 複数のデータソースを扱える などを活用すると楽)
(面子配慮)

11. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
アンチパターン4 (「入門 監視」より)
◼「監視を支えにする」
• 監視(+運用)でカバーできるから良いかと考えてしまう
• 監視を増やしても壊れているシステムが直るわけではない
◼運用者としてはできる限り避けたい流れのため意識してます
• あのアラートたまに上がるけど、昔からある謎のやつだしなー
• まずいな、とりあえずアラート仕込んでおこう(そして月日が経ち…)
◼監視も腐っていくので振り返りが必要
• 今も根本対策できないんだっけ？ → 設定・構成変更。自動対応
• 今月多かったアラートで手を入れられるやつはないか → 集計

12. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
デザインパターン1 (「入門 監視」より)
◼「組み合わせ可能な監視」
• データ収集・分析・可視化・アラートなどでツールを分ける
• 各コンポーネントを取り替え可能にする
◼監視対象の規模に応じて、監視システムの規模を調整
• 最初から巨大な監視システムは要らない(扱う手間が大きい)
• (+Agent)一本だったり、 + + だったり
◼監視システムを気軽に止められるかはポイント(かもしれない)
• コンポーネント = 1つのことを(可用性を保った上で)うまくやる
• 性能限界への対応・新規ツールへの乗り換えで考える範囲が減る
(年単位で見ると、ツールの切り替えは発生する)

13. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
デザインパターン2 (「入門 監視」より)
◼「ユーザ視点での監視」
• 監視するポイントは沢山あるが、ユーザに近いところからやろう
• Webサーバが何台生きているかよりも、レスポンスコードがどうか
◼インフラのデータ + ユーザでの見え方の突き合わせは大事
• 時に矛盾したデータが出てくる事もあるが、片方だけだと気づけない
◼可能なら内部・外部でのデータを比べられるようにする
• 物理ストレージ機器とVMに付く仮想ディスクのレイテンシは違う
Storage DiskVolume
VM
OS
ESXi
インフラで見える
レイテンシ
ユーザで見える
レイテンシ
ネットワークとか
バスとか色々
そもそも違うものが手元にある

14. Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
まとめ
◼ 最低限の監視からでも始めましょう
◼ 「入門 監視」が取っ掛かりとしては良い
◼ 監視も成長するので、サービスの一部として捉える
• 監視が安定するまでは時間がかかることを意識する
◼ 色々大変なポイントはありますが、チームで取り組めるといいですね
• SaaS利用などお金も絡むシーンも多いので、決裁権に近い人もぜひ