富士通クラウドテクノロジーズ インフラSRE部の吉村です。ふだんは監視やログデータ収集システムを担当しています。
この記事について
以前このブログでお伝えしていた、Cross2017やニフクラエンジニアミートアップでちょっとした発表を行いましたので、今回はその振り返り記事となります。
発表内容はニフクラにおけるストレージ監視についてです。 監視についての記事や情報は世の中わりとあるのですが、ストレージ機器を対象にした内容は珍しいかもしれません。
www.slideshare.net
内容としては特にストレージ機器特有の何かを取り扱っているわけではないのですが、おおよそニフクラの裏側で行われている監視で重要視していることを紹介できたらと思います。
あたらしい監視システムをつくることになった経緯
スライドにもありますが、もともとこの監視システムは2015年あたりにストレージ運用チームが抱えていた色々な悩みを解決するために作られました。 表に出るものも出ないものも含め、クラウドサービスの運用では様々な問題が起こります。 ストレージの管理をしているチームも例外ではなく、よくある悩みとして以下の様なものがありました。
- 利用しているストレージ機器のファームウェアに問題があり、想定した性能が出ない
- 急激にユーザーのストレージ利用量が想定以上のスピードで増え、容量枯渇が起きそうになる
- 「何かよくわからないが、仮想マシンについているディスクのIO性能が出ていないように見える」などの問い合わせ対応が難しい
もちろん当時も監視システムはありましたが、データの取得間隔が分単位であったり、(ストレージ機器の多さから)データを一覧することの手間が大きいなどという事情があり、きめ細かい監視や問題が起こる前に対応するということが難しくなっていました。
そこで、新たな監視システムに求められる要件として以下の3点が上がりました。
- 監視データは秒単位で取得する。可能なら1秒単位で後から確認できることが望ましい
- いろいろな種類のデータを横断的に確認できる。例としてはパフォーマンスの数値データとテキストログを組み合わせたり、物理サーバーとストレージの数値を見比べられるなど
- データは手間なく見れること。監視データを見るコストが高いと、どうしても傾向監視などが辛くなる傾向があるので避けたい
いま思うと随分雑な要件だったと思いますが、当時チームに入って半年程度の自分と同期の2人が担当となり取り組むことにしました。
監視システムの構成
なんだかんだあり、監視システムの大枠が完成しました。 スライドからの抜粋ですが以下のような構成になります。
監視システムをつくるにあたり、いくつかの工夫を加えています。
- 監視用のスクリプトを動かすサーバーをいちいち用意したり、サーバーが飛んだりしたときのことを考えたくない
非常に悲しいことですが、いつまでも動き続けられるサーバーはいません。 なにかの拍子に監視スクリプトが動作しているサーバーが故障することは十分に考えられます。
そういったときにいちいち作業を行うのは辛い(その間データが取れないのも困る)ので、監視スクリプトはMesos上のジョブとして動作させています。 Mesos+Marathonの組み合わせを使えば、仮にスクリプトを実行しているサーバー(VM)が飛んでも、大きなラグも無く別のサーバー上で動作を再開できます。
また、ニフクラは複数のリージョンに分かれているという事情から、ネットワークの問題などがあるときに一時的に他リージョンにあるストレージのデータが取得できないというケースがあります。 その場合は、MesosのSlaveとなるVMをそのリージョン内部に作成することで、監視スクリプトが動くサーバーとストレージ間にある問題を回避したりもしています。
- 一度取得したデータを複数のDBに送りたい
監視システムの構築途中、可視化の都合やチーム内の運用経験などの問題から、複数のDBにデータを送りたいというニーズが発生しました。 これを解決するため、取得したデータは一度Kafkaに転送して、そこから再度それぞれのDBに送るようにしています。
その結果、若干書かなければいけないコードは増えましたが、監視スクリプトとDBの結びつきを分離することができたり、 今後の新たなDBが増えたときの変更箇所も限定的になるというメリットが得られています。
- データを見るコストはできるだけ減らしたい
監視システムが構築できたら、あとは運用者は口を開けてアラートを待っていればいいのでしょうか？ もちろんそんなことはなく、アラートが鳴っているような非常対応時でなくてもデータを見る必要があるケースがたくさんあります。 よくあるのは、お客様からの問い合わせで特定の時間帯(数秒間のこともある)に問題がなかったかどうか調べるケースや、ストレージの負荷傾向を調べるときなどです。
弊社の以前のシステムで難しかったのがここで、データの閲覧に時間がかかったり、頭のなかでの変な読み替え(タイムゾーンやノード名など)が必要だったりすると、運用者にストレスがかかったり調査時間が長くなったりと良いことがありません。
今回のシステムではGrafana(+ Influxdb)をつかうことで、できるだけデータを見るときの手間を減らせるように努めています。 特にGrafanaのダッシュボードは優秀で、複数のデータソース(DB)から得たデータをつかって、グラフやログという形で自由に見せることができます。 これにより、特定のストレージ機器においてパフォーマンス値とイベントログを見比べたりすることや、複数の(機種が異なっていても)機器で共通する負荷傾向が現れていないか容易に確認することができます。
また、アノテーションという機能を併用することで、運用者が行ったタスクをグラフ上に表示することが可能となります。 例えば、ストレージに対する特定のメンテナンスタスクは、実施時間やメンテナンス実施者をダッシュボード上で直接確認できるようにしています。 これにより、ストレージ側のパフォーマンスデータだけでは推測しきれない事情(突然データ容量が増えているとか、気になる負荷があるなど)も把握できたりします。 (画像のオレンジの丸がアノテーション。一部のメンテナンス内容をグラフから確認できるようにしています)
他にも、パフォーマンスデータに対して注意を促すしきい値を表示したり、最近ではGrafanaから直接アラートを設定できるなど、運用上嬉しい機能が備わっており、 現在のストレージ監視システムはGrafanaに強く支えられている状態です。
さいごに
全体として、私達のチームが監視上重要視しているのは以下の3点です。
監視の仕組みが複雑になると、どうしても担当者以外には手が入れられない形になりがちです。
取得したデータそのものを見せるのではなく、ダッシュボードを挟むことで運用者の意図を伝え、皆で状況を確認したり数値に対しての議論が可能になるように思います。 また、変化が激しい環境だとアラートや運用閾値が陳腐化するのも早いので、たまにはデータを見つめてみることでふと気付くことがないか確認するようにしています。
この記事では、ニフクラで行われているストレージ監視について、簡単に紹介させていただきました。 当然、この構成が完成というわけではなく、これからも必要に応じて進化していくかと思いますが、 なにげなく使っているクラウドサービスの裏側にある試みについて少しでも知っていただければ幸いです。