クラウド上のシステム監視入門編～システムを作ったその先に～

Copyright 2017 FUJITSU CLOUD TECHNOLOGIES LIMITED
クラウド上のシステム監視入門編
~システムを作ったその先に~
20181024_Nifcloud_Meetup_LTSRE部吉村
富士通クラウドテクノロジーズ株式会社
インフラSRE部
吉村晃

トピック
クラウド環境での監視(初心者向け)
• IaaSでそもそも監視いる？
• VM立ててみたけど、どうやって監視しよう
• なにを監視したらいい
ニフクラ運用上でやった監視紹介(参考までに)
• ニフクラで作ったVMを監視してみた
• IaaS運用上で必要な監視

自己紹介
プロフィール
• 吉村晃
• 富士通クラウドテクノロジーズ (ニフティ2014年入社)
• インフラSRE部(IaaSのインフラ寄り運用部隊)
• ストレージ寄り(≠物理)の運用・監視などを主に担当
業務でよくお世話になるもの
業務でみているVM数は大体300~
• DRサービス用システム
• 監視システム
• ログ基盤

クラウド環境での監視
Confidential ｜ 4

IaaSでそもそも監視いる？
いります
なぜ監視するのか
• IaaSの責任分界点(OSから上は見ない/見えない)
• システムが見通せない ≒ 正しい構成が取れない
• (サービス自体のメトリクスは利用者が見る必要がある)

ノー監視で起きるだろうこと
問題解決(or サポート)が遅くなる/できなくなる
• (特にIaaSは)インフラ/OS両面の事象を突き合わせないとそもそも
答えにたどり着けない
ボトルネックを特定できない
• スケールアップ/アウト or アプリに手を入れるかどっちにする？
サービスで重要なことが洗い出せない
• ビジネス上の指針をどこに持つのか

VM立ててみたけど、どうやって監視しよう
監視SaaSを使う
• 対象が少ない・ある程度予算を積める・インフラ担当
監視ソフト(OSS)を立てる
• 対象が多い・カスタマイズ・ストレージ持てる・(担当がいる)
 有償ソフトを使う(自分は詳しくないので分からず)

予算感(公式の価格から適当に推測)
監視SaaS(5ホストくらいはフリープランで見れたり)
• Mackerel : 1800円/ホスト x 月
• DATADOG : 1700円/ホスト x 月
OSS運用
• 運用人件費 : <好きな数字を思い浮かべる>
• VM+ストレージ(最低構成)
• 9000円/月 ( AWS : t2.medium + 300GB gp2 EBS )
• 21000円/月(ニフクラ : e-Medium4 + 300GB 標準ディスク )
ざっくり100-150ホストを超えてくるとトントン？
• ※ 正直運用持つくらいならSaaSにしたほうが良さそう

ちなみに、ニフクラ基本監視というのもあります
コンパネから無料で簡易メトリックが取得できる

個人的に監視で重視すること
 監視内容より、普段の状況を知っていることのほうが重要
• 「何かが起きている」ことが分かれば最初の壁は超えている
 システムは変わるし、利用状況も変わる。監視も変わる
• 足りない監視・アラートは都度足していく
• 「監視疲れ」を避けるため、見ないデータ(アラート)は入れない
 注力するのはドメイン知識の獲得であって、仕組みではない
• 仕組みはSaaSなどで極力省力化し、振る舞いについて共有する
• (監視が安定するまでに数ヶ月~年単位で時間がかかることもある)

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

ニフクラ運用・利用上で
やっている監視紹介
(時間があれば)
Confidential ｜ 12

事例1 ログ基盤の監視
ニフクラIaaSに関連するログを集める基盤の監視
• 大体数十~数百ホスト(VM)で構成されるシステム

事例1 で困ったことと対策
VM数が多く、全体として機能しているか不明な時がある
• 一見動いているように見えるが、よく見ると一部のログが来てない
• 各所で冗長化しているので、一部が壊れても動いている
対策 : 基本的な監視を徹底 & キーポイントを別途監視
• 不意のハング・負荷高騰・リソース枯渇は基本監視で対応(Zabbix)
• 流れているログ量も監視し、サービスとしての正常性を担保
• ElasticSearchに届いているログ量に著しい変化がないか
• システムの中心にあるKafkaでメッセージ処理遅延がないか

事例1 監視導入のBefore & After
Before
• トラブル時にどこが原因なのか追うのがキツイ(50VM程度調べる？)
• VM数が多く、全体として機能しているか不明な時がある
After :
• 基本的なトラブル(CPU/Diskなど)はすぐ対象が分かり対応できる
• アラート上がってない限りは基本大丈夫
• ログ流量から、概ねの動作確認がすぐできる
• 「個々のコンポーネントは生きていたけど、実は動いてなかった」を防げる

事例2 複数拠点にある物理ストレージ機器の監視
ニフクラの各リージョンに存在するストレージ機器の監視
• 秒単位の監視・継続できる監視・リージョン間のNW

事例2 で困ったことと対策
秒単位の監視を継続的にできるようにしたい
• ベンダの監視ツールはうまく対応できなかった(監視間隔・一元化)
• 不安定なNWや、監視システム自体の異常に対応する必要がある
対策 : 複数機種を一元的に管理する監視スクリプトを書いた
• 監視内容・間隔は自由に設定できる
• スクリプト実行するノードを工夫することでNW問題を回避
• 監視システムが正常に動作しているかのチェック・修正を自動化

事例2 監視導入のBefore & After
Before
• 5分間隔の監視データしかなく、オペレーションに自信が持てない
• いちいち機種毎に別のツールで調べる手間があった
After :
• 秒単位のデータを元に調査、回答などができるようになった
• より顧客の利用状況に近いデータで議論できるようになった
• 一元化したダッシュボードで、様々なストレージを横断的に確認可
• 自分たちが運用上重要だとみなす項目をより理解し改善できる

まとめ
 最低限の監視からでも始めましょう
 監視SaaSなどを有効活用する
 大きい・特殊な環境だと監視システムを作ることも視野に
 監視も成長するので、サービスの一部として捉える
 最終的には「その」システムに対する知見が要る
 監視が安定するまでは時間がかかることを意識する

クラウド上のシステム監視入門編～システムを作ったその先に～

クラウド上のシステム監視入門編～システムを作ったその先に～

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie クラウド上のシステム監視入門編～システムを作ったその先に～

Ähnlich wie クラウド上のシステム監視入門編～システムを作ったその先に～ (20)

Mehr von 富士通クラウドテクノロジーズ株式会社

Mehr von 富士通クラウドテクノロジーズ株式会社 (20)