システム運用で押さえておきたい「管理すべき情報」とは
「階層を行き来する視点」の具体例
前回では、システム運用に必要な技術として、システム全体を階層で把握したうえで、
- 階層を上から下へ降りていくという視点
- 下から上へ階層を積み上げていく
という2つの視点を紹介してきた。この「階層を行き来する視点」の具体例として、筆者がかつて経験したトラブルの事例を紹介しよう。
それは、リアルタイムに動画を配信するシステムだ。ある拠点で撮影された動画をリアルタイムにサーバーにストリーミングで送り、そのサーバーから、あちこちに点在する拠点へストリーミング配信し、各拠点が受信。その受信した画像をユーザーが閲覧する、というものであった。
ここでのトラブルというのは、その生放送中に、いくつかの拠点で映像がブラックアウトし（画面が暗くなってしまい）、映像が見られなくなった、というものである。
アプリケーション層の確認
当然ながら、最初に画像データを受信し、それを各拠点に配信するサーバーのアプリケーションのバグが疑われた。そこで、開発元に掛け合い、本番環境と同等の規模での負荷テストを実施すると同時に、アプリケーションでの処理内容についてのヒヤリングを繰り返した。
結局、本番よりも大きな規模での配信の実験を繰り返し、アプリケーションの不具合ではなさそうだ、という結論に達した。アプリケーションには問題なさそうだ、ということで、次は、ネットワークを疑うことになる。
ネットワーク帯域のキャパシティプランニングへの疑問
サーバーが設置されているデータセンターのネットワーク構成と、各拠点のネットワークの条件、また動画のリアルタイム配信ということで、ネットワーク帯域のキャパシティプランニング（容量設計）を精査することになる。そこで、各方面から情報を集めたところ、データセンター内のサーバーからデータセンター外部へのネットワーク帯域が100Mbpsであることが判明した。
そのため、配信先の拠点を調査したところ、ブラックアウトが発生するのは、配信先拠点数が想定よりも多い場合であることが判明した。普通に配信する場合でも、60M～70Mbps程度の帯域を必要とする拠点数だったのだ。我々は、このネットワーク帯域に関するキャパシティプランニングを疑った。
プランニングを行った動画配信事業者のエンジニアに確認したが、100Mbps近くの実効性能を実験で確認したので、問題ないとの返事でだった。後から確認したところ、この実験は、FTP（FileTransferProtocol）で巨大ファイルの転送を行い計測した結果であるとのことだった。
当たり前の話ではあるが、FTPと動画のストリーミング配信に用いたプロトコルとではデータ転送の作法が異なっており、FTPでのファイル転送の結果を単純に動画配信に適用することはできない。そこで、配信を実施している時間の、ネットワークの様子をパケットキャプチャツールを使ってキャプチャし、プロトコルの通信状況を解析して、頻繁に輻輳が発生している証拠を突き止めた。
「階層」の視点を変えて原因を追及するIT技術の総合力が勝利
最終的には、この配信事業者のエンジニアに対して、キャパシティプランニングの再検討を促すこととなった。
このように、システムに何らかのトラブルが発生した場合、アプリケーションやネットワーク、場合によってはハードウェアなど、「階層」の視点を変えて原因を追及していく必要がある。上記の事例では、「アプリケーションの動き」「ネットワークのトポロジーや帯域」、そして「プロトコルの特性」を理解したうえで、実際にネットワーク上を流れるパケットを解析し分析することとなった。
このことは、すべての階層をまたいだIT技術の総合力ともいうべきものであり、特定の何らかの技術があればいい、というものではない。
