kanshi de miraiコラム連載6回目となりました。

第1回から第5回までのテーマは「監視」「品質」「運用」「OSS」などでしたが、今回はシステムをいかに”把握する”か？をお伝えできればと考えています。

システムと一言で言っても、例えば「ネットワーク」「サーバー」「アプリケーション」というように機能毎に担当者が分かれている、更には「設計」「開発」「構築」「運用」というように各構築・運用フェーズで分業されているのが通常で、システムの全体像を捉える担当者がいないことが多いかと思います。

そのような状況下において、現在のシステムに求められていることは、

・継続的なサービスの提供
・投資コストの削減
・新しい技術の導入（システムの効率化やコスト削減効果などを期待）

などが挙げられます。

つまり安定的なサービス運用を前提としながらも、コスト削減を徹底して求められています。具体的に言いますと、システムの冗長化は必須になりますし、仮想化システムへの統合等も積極的に行われるようになっています。
一方で、社会的状況の変化からIPv6への対応を求められ、あるいは柔軟なシステム設計のためにOpenFlowなどの新しい技術への対応を求められてきたのが、この数年での変化ではないでしょうか。
このような複雑な状況の中では個別対応の対処法だけではなく、システム全体を俯瞰した視点を持つことが非常に重要になってきます。

システムの監視には、システムの変化を把握する性能監視、死活監視、状態監視、ログ監視等を行い、アラート検知や対応を行っていると思います。
その中でも性能監視は

・システムに対するパフォーマンスの把握（品質）
・システムリソースの変動を検知し、トラブルの予兆を把握（予兆検知）
・リソースの利用状況の把握（有効活用）

を目的としており、システムの動きそのものを把握することがあまり重要視されていないように思われます。
しかしながら、ITインフラに対する性能監視の必要性はここ数年で最低限考慮するべきものになってきたのではないかと感じています。

例えば性能監視においては、

・ハードウェアのリソース
・CPU使用率
・CPU負荷状態（Load Average）
・ストレージ容量
・メモリー容量
・データ読み書き回数（IOPS）
：

・ネットワークのリソース
・Traffic量
・Session数
・コネクション数
・エラーパケット数
・パケット破棄数
：

・レスポンス
・WEBサービスの応答速度
・TCPコネクションの応答速度
・PING応答有無と応答速度
：

などの情報を取得し、定められたしきい値より高いか低いかの変化をタイムリーに捉え、システムの状況変化をいち早く検知する仕組みを構築されているかと思います。

一方で、運用者の視点から見ると、多数の性能情報を一つ一つ確認し運用することは非常に困難であり、通常の動作からの違いを、昨日、先週、先月などの時間軸で比較し判断することは時間がかかり過ぎてしまいます。今生じている事象に対して、以前からの変動を確認するというのは重要なポイントではありますが、その稼働を割くのはなかなか難しいのではないでしょうか。

更に、しきい値による監視だけでは変動を検知できますが、動きを”把握する”ことはできません。ここで言う動きとは、周期性や傾向などの情報のことを指します。

その部分を補う手法として

・通常の機器リソース状態の把握（ベースライン）
・リソースの傾向把握（トレンドライン）
・リソースの比較（タイムシフト）

を性能監視へ付加することで、一時的な高負荷なのか元々リソースが不足しているのかの判断が可能になります。これがシステムの動きを”把握する”ポイントです。

性能監視の重要なポイントは、現在の値や過去との比較はもちろんのこと、各機器の通常状態のリソースやレスポンスの動きを把握し、そこからの変化を読み取り、対処を実施することで、性能監視の目的である、品質の向上やトラブル予兆の検知、ならびにリソースの有効活用が可能となります。

弊社製品ではこのシステムの動きの把握を基本機能として実装しており、一つのイベントに対してデータを収集しなおす必要がなく、問題点を洗い出すことが可能です。
このような機能が、今発生しているイベントに対して、いち早く対応できる手助けになればと考えています。

by 技術部技術課　今川　裕太