お問い合わせ

障害対応事例:「階層」を行き来して原因を切り分ける

障害対応の基本的な考え方 (3)
障害対応の基本的な考え方 (3)

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

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

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

システムの概要

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

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

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

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

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

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

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

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

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

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

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

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

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

関連コンテンツ

アールワークスのシステム運用サービス

システム監視・障害対応

【システム監視・障害対応サービス】
24時間365日のシステム監視を行い、障害発生時には、エンジニアが手順書と技術的ノウハウに基づき、サービスを即時復旧します。障害対応手順書の作成から当社にて行います。詳しくはこちらから。


運用設計

【運用設計サービス】
お客様システムに即した監視項目、運用フロー(障害発生時/定常時/メンテナンス時)を設計します。現状の監視・運用フローを見直したい場合に適切です。
詳しくはこちらから。

サービスへのお問い合わせ

システム運用サービスに関する資料のご送付をご希望の方、
サービス内容についてのお問い合わせご希望の方は、
お問い合わせフォームまたは電話番号よりご連絡ください。

03-5946-8405

お問い合わせはこちら

ご相談・お問い合わせはこちらから

サービスについてのご相談、資料のご請求など、お気軽にお問い合わせください。

03-5946-8400 平日 10:00 - 18:00
page top