System Monitoring Column ＜システム監視コラム＞障害対応事例：「階層」を行き来して原因を切り分ける

はじめに

「障害対応の考え方：「階層」を意識してシステムを理解する」では、システムを構成する階層と、階層同士がどう協調して動くのか、を見てきました。ここでは「階層を上下に行き来しながら障害対応をする例」について見ていきます。

1. 動画配信システムでのトラブルと原因を特定した例

リアルタイムに動画を複数拠点へ配信するシステムで、生放送中に、いくつかの拠点で映像がブラックアウトし、見られなくなることがありました。本例を使って、原因特定までの流れを見ていきます。

1.1 システムの概要

ある拠点で撮影された動画をリアルタイムにサーバーにストリーミングで送り、そのサーバーから、あちこちに点在する拠点へストリーミング配信し、各拠点が受信。その受信した画像をユーザが閲覧する、といったシステムです。

1.2 アプリケーション層の確認

最初に、画像データを受信し、それを各拠点に配信するサーバーのアプリケーションバグを疑いました。開発元に掛け合い、本番環境と同等の規模での負荷テストを実施すると同時に、アプリケーションでの処理内容について、ヒアリングを繰り返しました。
結局、本番よりも大きな規模での配信の実験を繰り返し、アプリケーションの不具合ではなさそうだ、という結論に至ったので、次は、ネットワークに原因がないか、調査しました。

1.3 ネットワーク帯域のキャパシティプランニングへの疑問

サーバーを設置しているデータセンターのネットワーク構成と、各拠点のネットワークの条件、ネットワーク帯域のキャパシティプラニング（容量設計）を精査しました。各方面から情報を集めたところ、データセンター内のサーバーからデータセンター外部へのネットワーク帯域が 100Mbps であることが判明しました。

配信先の拠点を調査したところ、ブラックアウトが発生するのは、配信先拠点数が想定よりも多い場合であることがわかりました。普通に配信する拠点数の場合でも 60～70Mbps 程度の帯域を必要としたため、このネットワーク帯域に関するキャパシティプラニングを疑いました。

プラニングを行った動画配信事業者に確認したところ、100Mbps 近くの実行性能を実験で確認したので問題ないとのことでしたが、実はこの実験は、FTP (File Transfer Protocol）で巨大ファイルの転送を行い計測した結果でした。

1.4 プロトコルによってデータ転送の作法が異なる

FTPと動画ストリーミング配信に用いたプロトコルとではデータ転送の作法が異なっており、FTPでの転送実験結果を、単純に動画配信に適用することはできません。

そこで、配信を実施している時間のネットワークのパケットをキャプチャし、プロトコルの通信状況を解析して、頻繁に輻輳が発生していることを突き止め、キャパシティプラニングの再検討をお願いしました。

2. 「階層」を行き来して、トラブル原因を特定する

上記の例では、「アプリケーションの動き」「ネットワークのトポロジーや帯域」、「プロトコルの特性」を理解した上で、実際にネットワーク上を流れるパケットを解析し分析しました。

このように、システムに何らかのトラブルが発生した場合、アプリケーションやネットワーク、ハードウェアなど、「階層」の視点を変えて原因を追究していく必要があります。

Tag： システム監視 障害対応

• 

  障害対応の考え方：「階層」を意識してシステムを理解する

• 

  サーバー監視とは？目的と重要性、監視対象と監視方法について解説