LinuCシステムアーキテクト SA02試験の例題と解説

SA.09.1障害時の基本手順

LinuC システムアーキテクト SA02試験の出題範囲から「SA.09.1 障害時の基本手順」についての例題を解いてみます。

例題

IaaS 基盤上に構築した Web 3層モデルをベースとする Web サービスの運用中に、全体の数パーセントのリクエストが意図せず HTTP 500 エラーとなる障害が発生した。使われている主なミドルウェアは Apache、PHP、MySQL で、現時点で以下のことが分かっている。

障害を初めて確認した数日前に、MySQL サーバーの仮想マシンインスタンスをスケールアップした。
Apache のログから、エラーが発生したリクエストの送信元、クエリの内容、時間などが確認可能である。
PHP、MySQL のログにエラーは確認されていない。
原因調査のため、同じ IaaS 基盤上の独立したネットワークにある同一構成のステージング環境にて、上記エラーログに示されたクエリの内容を再現するリクエスト10件を実行したが、正常に処理が終了した。

現状のエラー率であれば本番環境は引き続き稼働してよいと判断しており、まずは原因究明を続けたい。次に取るべき行動として適切なものは次のうちどれか。2つ選びなさい。

本番環境の MySQL サーバーの仮想マシンインスタンスをもう一段階スケールアップする。
本番環境で元々記録されている動作ログのうち未確認のものを調査する。
ステージング環境にて PHP にデバッグ設定を追加した上で、調査に用いた10件のリクエストを再実行する。
ステージング環境にて MySQL を一時的に停止した上で、調査に用いた10件のリクエストを再実行する。
本番環境の Apache ログから、エラーリクエストの前後を含めた1000件のリクエストを新たに抽出し、それをステージング環境で実行し確認する。

※この例題は実際の試験問題とは異なります。

解答と解説

正解は、「２. 本番環境の動作ログのうち未確認のものを調査する。」と「５. 本番環境の Apache ログから、エラーリクエストの前後を含めた1000件のリクエストを新たに抽出し、それをステージング環境で実行し確認する。」です。

障害の原因究明時には、まだ分かっていないことを調査し、その結果を元に原因の可能性となる要素を絞り込んでいく、という作業が基本になります。アルゴリズムで言うところの二分探索のように、ある調査によって障害が存在する可能性の範囲が半分に絞り込まれていくような調査ができるのがベストです。また今回の場合、「同一構成のステージング環境があるが、初手ではエラーが再現しなかった」「本番環境の変更の緊急度は高くない」という前提なので、それを踏まえて次の行動を選択することになります。

選択肢 2 は基本的なことですが本番環境に手を入れることなく追加情報を得る手段になるので妥当と言えます。また、選択肢 5 は本番環境とステージング環境の違いの1つであるリクエストの内容に着目し、この違いをエラーの発生した本番環境により近づけて再現を試みるという目的になっており、妥当と言えます。

選択肢 1 は根本原因を確定させる前の本番環境の変更となっており、今回の前提にそぐわない行動と言えます。選択肢 3 は一見状況把握が進む施策に見えますが、現時点でステージング環境でエラーが再現していない以上、これだけで問題の切り分けが大きく進むような探索とは考えにくいです。選択肢 4 はおそらくステージング環境でエラーが発生することになりますが、そのエラーは自ら作り出しているだけであり、問題解決に寄与しないと想像されます。