カオスエンジニアリングの五つの原則｜科目A-1（応用情報技術者） 令和7年 春期午前試験 問49
出典：令和7年春期 午前 問49
分野：ソフトウェア開発管理技術 ／ 開発プロセス・ 手法
分散システムの脆弱性を実験によって発見する手法であるカオスエンジニアリングには，五つの原則がある。この原則のうちの三つは，"定常状態における振る舞いの仮説を立てる"，"実世界の事象を多様化させる"，"継続的に実行できるよう実験を自動化する"である。あと二つの原則の組みはどれか。
- ア："開発環境で実験を行う"，"影響範囲を局所化する"
- イ："開発環境で実験を行う"，"影響範囲を広く捉える"
- ウ："本番環境で実験を行う"，"影響範囲を局所化する"
- エ："本番環境で実験を行う"，"影響範囲を広く捉える"
TSUNAGARU-ADVICE
まず押さえたいこと
カオスエンジニアリングでは、実際の利用条件に近い本番環境で実験することが原則です。開発環境だけでは、本番特有の負荷・構成・通信・利用者の振る舞いを十分に再現できず、潜在的な問題を見落とす可能性があります。
迷ったときの判断軸
本番環境で実験する一方、利用者への被害を避けるため、対象や時間を限定して影響範囲をできるだけ局所化することが重要です。「本番で現実的に試すが、障害の波及は最小限に抑える」という組合せで判断しましょう。
科目Bにつなげるために
特にプロフェッショナルデジタルスキル（システム）試験合格を目指す方は、カオスエンジニアリングを無計画に障害を起こす手法ではなく、仮説・観測可能な定常状態・限定された実験・迅速な中止手段を準備して耐障害性を検証する活動として理解しましょう。
カオスエンジニアリングは、システムにあえて小さな障害を起こし、障害が発生しても安定して動き続けられるかを確認する考え方です。
大規模なシステムでは、多くのサーバやサービスが連携して動いています。そのため、どこか一部に障害が起きても、サービス全体が止まらないようにしておく必要があります。
カオスエンジニアリングでは、本番環境または本番に近い環境で、サーバ停止、通信遅延、急なアクセス増加などを意図的に発生させます。そして、システムが想定どおりに動き続けられるかを測定します。
重要なのは、無計画にシステムを壊すことではありません。あらかじめ仮説を立て、影響範囲を小さくし、万一問題が起きてもすぐ止められるようにして実験します。
もし実験中にエラーが増えたり、応答が極端に遅くなったりすれば、その部分は本番障害につながる弱点だと分かります。実際の大きな障害が起きる前に、改善点を見つけられることがメリットです。
つまりカオスエンジニアリングは、「本番で起こり得る障害を小さく再現し、システムの弱点を事前に見つける訓練」と考えると分かりやすいです。
したがって、ウが適切です。
❌他選択肢が誤りの理由ア："開発環境で実験を行う"，"影響範囲を局所化する"
⇒影響範囲の局所化は正しい原則ですが、カオスエンジニアリングでは実際のシステムの挙動を確かめるため、本番環境での実験が原則とされています。
イ："開発環境で実験を行う"，"影響範囲を広く捉える"
⇒実験は本番環境で行い、影響範囲は可能な限り局所化するのが原則です。両方とも原則と反対です。
エ："本番環境で実験を行う"，"影響範囲を広く捉える"
⇒本番環境で実験する点は正しいですが、障害の影響が利用者やシステム全体へ広がらないよう、影響範囲は局所化します。