運用管理
「階層」を使いこなせば解決への道筋が見える
前回はシステム運用を理解するために「階層」を上から下に降りていく、あるいは逆に下から上に積み上げていくという、2つの方法をご紹介しました。階層を切り替えて検証していくことで、トラブルの原因を追求するスピードは格段に上がります。では、具体的にはどのように階層の見方を変えていけば良いのでしょうか。
例えばある技術者は、「リアルタイムで動画を配信する」というシステムを運用していて、一部の中継拠点で生放送の最中に映像がブラックアウトするというトラブルに見舞われました。このケースの場合、①ある地点で撮影された動画をリアルタイムでサーバーにストリーミングで送る、②サーバーから点在している拠点へストリーミング配信、③各拠点が受信、④受信した動画をユーザーが閲覧する、という手順で動画が配信されていました。
まず疑うべきは「アプリケーション」です。この場合は、撮影された動画を最初に受信し、配信するサーバーのアプリケーションが疑われます。問題は拠点で起きているからです。この時は開発元に掛け合い、アプリケーションのテストを繰り返しました。結果、アプリケーションに問題はないことがわかりました。
次に疑うべきは「ネットワーク」です。具体的には、サーバーが設置されているデータセンターや各拠点のネットワーク構成、ネットワーク帯域のキャパシティプランニングを徹底的に調べました。すると、データセンター内のサーバーからデータセンター外部にデータを送るネットワークの帯域が100Mbpsであること、ブラックアウトが発生するのは想定よりも配信先の拠点数が多い場合であることがわかりました。さらに、想定された拠点数の場合でも、60～70Mbps程度の帯域が必要なこともわかりました。こうなると、キャパシティプランニングが疑われます。本当にネットワーク帯域は100Mbpsあるのか？ 技術者に確認すると、FTPで計測した実効性能なので問題ないとのこと。
しかし、FTPと動画のストリーミング配信では、プロトコルが異なります。そこで今度はネットワークの動作状況を調べたところ、実は頻繁に輻輳（回線がパンクすること）を起こしていることを突き止めたのです。最後は配信業者にキャパシティプランニングの再検討をお願いして、この件は解決しました。
このケースでは、「アプリケーション」から「ネットワーク」の階層へと視点を広げたことによって問題を解決できたのです。注目すべきは、アプリケーションの動きやプロトコルの特性などを理解していなければ、分析は不可能だったということ。特定の技術だけでは対応できなかったのです。システム運用担当者には総合的な力が必要だということが、この事例からもわかるのではないでしょうか。
