カオスエンジニアリング

📖 もうちょい詳しく

何が新しいの？

むかしのシステム試験は「壊れないことを確かめる」ものでした。カオスエンジニアリングは逆で、「わざと壊して、どう壊れるかを先に見る」という考え方です。たくさんのサーバーが連携する今の仕組みでは、どこか一部が落ちるのは避けられません。だからこそ、落ちたときの動きを本番が混む前に知っておこう、という発想です。

どうやって動いてるの？

まず「ふだんはこのくらい正常に動いているはず」という基準を決めます。そのうえで、サーバーを1台わざと止めたり、通信をわざと遅くしたりして、本番に近い環境で小さな異常を注入します。注入のあいだも反応速度やエラー率を見張り、想定外に悪化したらすぐ実験を止めます。基準からどれだけずれたかを見て、弱点を直していきます。

何ができるの？

「いざ障害が起きたら、利用者にどんな影響が出るか」を、本物の事故が起きる前に確かめられます。たとえば1台落ちても自動で別の台に切り替わるか、画面が真っ白にならず一部だけ縮退して動くか、といった点です。直すべき弱点が前もって見つかるので、夜中の緊急対応を減らせます。

🌱 身近なたとえ

避難訓練で例えると分かりやすいです。本当の火事を待ってから逃げ方を考えるのではなく、ふだんから煙を想定して避難経路を試しておきます。実際に歩いてみて初めて「この扉は重くて開けにくい」と気づけます。カオスエンジニアリングも、わざと小さな「障害の訓練」をして、本番が止まる前に弱点を直しておく取り組みです。

✅ まず覚えるポイント

• 「壊れないこと」ではなく「壊れたときの動き」を確かめる手法です
• まず「正常な状態」の基準を決めてから実験します
• 止めたり遅くしたりして、わざと異常を注入します
• 影響が大きくなりすぎたら、すぐ実験を止められるようにしておきます
• 目的は弱点を先に見つけて、障害に強い仕組みに直すことです

🧭 よくある勘違い

ただ本番をめちゃくちゃに壊すことなの？

いいえ、無計画に壊すわけではありません。影響の範囲をできるだけ小さく絞り、悪化したらすぐ止める準備をしてから行います。仮説を立てて結果を観察する、計画的な実験です。

障害が起きないなら、やる必要はないのでは？

障害は「起きるかどうか」ではなく「いつか必ず起きるもの」として考えます。起きてから慌てるより、前もって弱点を知って直しておくほうが、被害を小さくできることが多いです。

テスト環境だけでやればいいのでは？

テスト環境でも価値はありますが、本番は構成や通信量が違い、再現しきれない問題が残りがちです。だからこそ、影響を絞ったうえで本番に近い環境で確かめる意味が大きいのです。

🧩 関連して覚えると楽な言葉

• SRE: ソフトウェアの考え方で運用の信頼性を高める職種・手法。カオスエンジニアリングと相性が良いです
• 高可用性 (high availability): 止まりにくい仕組みのこと。実験で確かめたい目標になります
• 災害復旧 (disaster recovery): 大きな障害から復旧する備え。壊れた後をどう戻すかの話です
• サーキットブレーカー: 障害の連鎖を断つ仕組み。実験で効き目を確かめる対象になります

🏁 ひとことでまとめ

避難訓練のように、わざと小さな障害を起こして弱点を先に直し、本番が止まりにくいシステムに育てる取り組みです。