システム運用で押さえておきたい「管理すべき情報」とは
「階層を行き来する視点」の具体例
前回では、システム運用に必要な技術として、システム全体を階層で把握したうえで、
- 階層を上から下へ降りていくという視点
- 下から上へ階層を積み上げていく
という2つの視点を紹介してきた。この「階層を行き来する視点」の具体例として、筆者がかつて経験したトラブルの事例を紹介しよう。
それは、リアルタイムに動画を配信するシステムだ。ある拠点で撮影された動画をリアルタイムにサーバーにストリーミングで送り、そのサーバーから、あちこちに点在する拠点へストリーミング配信し、各拠点が受信。その受信した画像をユーザーが閲覧する、というものであった。
ここでのトラブルというのは、その生放送中に、いくつかの拠点で映像がブラックアウトし(画面が暗くなってしまい)、映像が見られなくなった、というものである。
アプリケーション層の確認
当然ながら、最初に画像データを受信し、それを各拠点に配信するサーバーのアプリケーションのバグが疑われた。そこで、開発元に掛け合い、本番環境と同等の規模での負荷テストを実施すると同時に、アプリケーションでの処理内容についてのヒヤリングを繰り返した。
結局、本番よりも大きな規模での配信の実験を繰り返し、アプリケーションの不具合ではなさそうだ、という結論に達した。アプリケーションには問題なさそうだ、ということで、次は、ネットワークを疑うことになる。
ネットワーク帯域のキャパシティプランニングへの疑問
サーバーが設置されているデータセンターのネットワーク構成と、各拠点のネットワークの条件、また動画のリアルタイム配信ということで、ネットワーク帯域のキャパシティプランニング(容量設計)を精査することになる。そこで、各方面から情報を集めたところ、データセンター内のサーバーからデータセンター外部へのネットワーク帯域が100Mbpsであることが判明した。
そのため、配信先の拠点を調査したところ、ブラックアウトが発生するのは、配信先拠点数が想定よりも多い場合であることが判明した。普通に配信する場合でも、60M~70Mbps程度の帯域を必要とする拠点数だったのだ。我々は、このネットワーク帯域に関するキャパシティプランニングを疑った。
プランニングを行った動画配信事業者のエンジニアに確認したが、100Mbps近くの実効性能を実験で確認したので、問題ないとの返事でだった。後から確認したところ、この実験は、FTP(FileTransferProtocol)で巨大ファイルの転送を行い計測した結果であるとのことだった。
当たり前の話ではあるが、FTPと動画のストリーミング配信に用いたプロトコルとではデータ転送の作法が異なっており、FTPでのファイル転送の結果を単純に動画配信に適用することはできない。そこで、配信を実施している時間の、ネットワークの様子をパケットキャプチャツールを使ってキャプチャし、プロトコルの通信状況を解析して、頻繁に輻輳が発生している証拠を突き止めた。
「階層」の視点を変えて原因を追及するIT技術の総合力が勝利
最終的には、この配信事業者のエンジニアに対して、キャパシティプランニングの再検討を促すこととなった。
このように、システムに何らかのトラブルが発生した場合、アプリケーションやネットワーク、場合によってはハードウェアなど、「階層」の視点を変えて原因を追及していく必要がある。上記の事例では、「アプリケーションの動き」「ネットワークのトポロジーや帯域」、そして「プロトコルの特性」を理解したうえで、実際にネットワーク上を流れるパケットを解析し分析することとなった。
このことは、すべての階層をまたいだIT技術の総合力ともいうべきものであり、特定の何らかの技術があればいい、というものではない。
システム運用で管理すべき情報
前項では、システムを理解するうえで必要な情報を挙げてみたが、このほかに、システムを運用していくうえで必要となる、「管理すべき情報」を列挙する。
インシデント
インシデントとは、「事件、出来事、ハプニング」という意味で、システム運用では、なんらかのトラブルの発生を意味する。しかし、実際にシステムがダウンしたとか、本格的なトラブルに限定した話ではなく、例えばハードウェア、とくにCPUの温度やHDDの容量が指定の閾値を超えたことによって、アラートが発生したような、直接システムトラブルにつながらないようなイベントも、インシデントに含まれる。
インシデントの発生は、それに対応する運用担当者のアクションにつながる。したがって、過去にどのようなインシデントが発生したのか。またその発生時刻はいつで、どのようなタイミングであったのか、例えばユーザーのアクセスがシステムに殺到し、過負荷状態が続いているなかで発生したものなのか、あるいは、ユーザーの利用がほとんどない真夜中や早朝に発生したものなのかなど、そのインシデントが発生した条件も含めて記録に残しておき、その対処方法や対処結果を、運用業務の改善に役立てていくべきだ。
セキュリティ関連情報
セキュリティ関連情報には、
- システムにアクセスするためのアカウント情報
- アクセス権限を持っているユーザーの情報
- アクセス履歴
- ファイアウォールやパケットフィルタの設定情報
- ミドルウェアなどのパッケージのバージョン番号
- セキュリティパッチの適用履歴情報
などが含まれる。情報セキュリティの第一人者、ブルース・シュナイアー(BruceSchneier)が、『セキュリティは鎖みたいなものであり、一番弱いところが全体の強度となる』と言っているように、セキュリティは一度設定すれば完了というものではなく、常に新たな脅威が出てくる。現在どのような状態であり、セキュリティ上のどういう対策を講じる必要があるのかを、常に把握しておく必要がある。
また、運用対象のシステム(通常はOSや利用しているソフトウェア)に関連するセキュリティのアップデート情報については、常に動向を把握しておく必要がある。セキュリティ情報については、セキュリティ関連企業各社が、常に最新情報を提供してくれるので、それをどう収集し、自分たちにとって必要なものを取捨選択し、運用チームで共有していくかは、重要なポイントとなるだろう。
トラブル履歴
過去に発生したトラブルと、その対処結果については、履歴を残して、常に参照できるようにしておくべきだ。それは、同じシステムにおいては、同じようなトラブルが再発する傾向が高いからだ。
こういった過去の履歴や対処方法を、定期的にサマリーにまとめ、「FAQ」(よくある質問)として文書化し、運用担当者が常に参照できるようにしていく。
変更履歴
システムの構成情報や設定情報については、運用していく中で日々変化していくものである。「いつ」「誰が」「どのような変更を行ったか」を、常に捕捉し続けることで、問題が発生した際に、「どこの時点での問題か」「原因はどこにあるか」といったことが突き止めやすくなる。
また、システムのパフォーマンスを改善する目的で、パフォーマンスに直結する設定項目を変更することもあるだろう。
モニタリング情報の履歴
CPU負荷をモニタリングしている場合、過去の履歴データを一定期間保存することにより、例えば、「毎週金曜日の午後だけCPU負荷が増加する」といった傾向が明らかになる。このような傾向を把握することで、CPU負荷が増大する原因の追求や、対策の立案が可能となる。
また、HDDの空き領域の減少スピードや、ログファイルの増大のペースを把握することで、HDDが溢れそうな時期をあらかじめ認識し、トラブルが発生する前に対処することが可能になることもある。