CASE1~5 を眺めていただくと分かるように、システム障害発生直後からすぐに原因が特定できるケースは稀で、大抵は 1 つのシステム障害に対して複数の原因が考えられることが多いです。それでもおおよその勘所があると数ある原因をいくらか絞り込んで調査初動を早めることができるので、押さえておくと良いでしょう。

原因を調査するにあたり、優先順位を決める方法

まずはアラートやモニタリング情報を把握するところから始まります。

AWS 等のクラウドサービスを利用していると CPU 負荷やメモリ使用量、各種ログをモニタリングできる機能が大抵付随するため、基本的にはクラウドサービス内でアラートやモニタリング情報を確認することが多いかと思われます。あるいは自社で導入している監視サービスのアラートやモニタリング情報、他にもサーバーへ ssh してログを確認することもあります。

これらを駆使し、システム障害発生の原因になっている可能性の高い候補から順に調査していきます。

原因特定のための調査例（データベース設定・構成・負荷）

各論に入ります。本来なら 7 つのシステム障害発生原因毎に書き出したいのですが記事ボリュームが大きくなりすぎるため、今回は頻出しやすい データベース設定・構成・負荷 に絞り解説します。

データベースにおけるシステム障害の代表的な例は CPU 負荷が 100%に達する ことで発生するもので、大抵はアラートやモニタリング情報で確認可能です。以下では CPU 負荷が 100%に達する原因をどのように特定するか見ていきます。

CPU 負荷が 100%に達する原因

CPU 負荷が高い時は、付随してモニタリングに変化が現れやすい情報があります。代表的なものが

データベース接続数の増加
書き込み IOPS 数の増加
スロークエリの増加

です。まずは上記 3 つのうちどれに該当しているかを調べてください。

show processlist;
show full processlist;

いずれかのコマンドをインターバル設けながら複数回実行してスロークエリの発生を確認しつつ、どのクエリが時間かかっているのかを特定するのも 1 つの方法です。

まとめ

システム構成の全体図を把握しておくと、障害が発生しうるポイントを把握しやすくなります
ケースバイケースで何が原因となりうるかを押さえておくと、調査の初動が早くなります
調査の優先順位はアラートやモニタリングを確認して決めましょう
データベースの障害で CPU が 100%になる場合、付随してモニタリング情報に変化が現れることが多いのでそちらも確認しましょう

記事一覧に戻る

【Trouble shooting hack】Web サービスにおけるシステム障害の原因特定アプローチ

想定読者

当記事で言及すること

当記事で言及しないこと

当記事で取り上げる「Web サービスにおけるシステム障害」の定義

システム障害の原因の大まかな区分

どんな時に発生したシステム障害かで、疑う原因を絞り込む

CASE1: 新機能リリース後

CASE2: 各種バージョンアップ対応後

CASE3: システム構成変更後（サーバーリプレース含む）

CASE4: テレビ番組で Web サービスが紹介されている最中

CASE5: BOT が Web サービスへ大量にアクセスしている最中

原因を調査するにあたり、優先順位を決める方法

原因特定のための調査例（データベース設定・構成・負荷）

CPU 負荷が 100%に達する原因

1. データベース接続数の増加の場合

2. 書き込み IOPS 数の増加の場合

3. スロークエリの増加の場合

まとめ