カオスエンジニアリング(カオスエンジニアリング)
回復力のあるシステムの実践
- 著者:
- Casey Rosenthal/Nora Jones/堀 明子/松浦 隼人(ケイシー ローゼンタール/ノラ ジョーンズ/ホリ メイコ/マツウラ ハヤト)
- 出版社:
- オライリー・ジャパン
- 出版日:
- 2022年06月17日頃
- ISBN:
- 9784873119885
- 在庫:
- 在庫あり
なぜ注目されているか
書籍紹介
エンジニアに向けカオスエンジニアリングの概要と行動原則を解説!
カオスエンジニアリングとは、本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にも耐えられるようにする取り組みです。マイクロサービスや分散技術に移行するにつれて、システムの複雑さが増していますが、カオスエンジニアリングによって脆弱性を発見し、顧客に影響を与える前に停止を防ぐことができます。本書は、エンジニアに向け、ビジネス目標を達成するために最適化を行いながら複雑なシステムを運用する方法を示します。
技書の森解説
分散システムの障害は「起こるかどうか」ではなく「いつ起こるか」の問題です。カオスエンジニアリングは、本番環境にあえて障害を注入し、システムが想定どおりに劣化するかを検証する規律として Netflix が体系化しました。本書は O'Reilly から刊行された同名書の邦訳で、 Casey Rosenthal らカオスエンジニアリングの実践者自身が原則、設計、組織への導入方法を解説しています。
内容は単なるツールの使い方ではなく、「何を実験するか」「仮説をどう立てるか」「結果をどう組織に還元するか」という方法論に重きが置かれています。障害注入ツール (Chaos Monkey 等) は手段にすぎず、本質は「未知の弱点を発見する実験文化の構築」であるという主張が繰り返し強調されます。 SRE やインフラエンジニアだけでなく、信頼性に責任を持つマネージャー層にも読まれているのはそのためです。
前提知識として、マイクロサービスや分散システムの基礎概念を持っていることが望ましいです。自社の本番環境でなぜ障害訓練が必要なのかを言語化し、経営やチームを巻き込む論拠を作りたいとき、本書の議論がそのまま説得材料になります。
言及 Qiita 記事 (24 件)
【超カンタン】毎回必ずうまくいく、超シンプルなバイブコーディングのやりかた
♡ 55cursor, #AI, AI駆動開発【あるある】小学校音楽会練習のカオスをエンジニアリングで解決してみた話
♡ 38問題解決Engineering Manager 不要論
♡ 35ポエム, マネジメント, エンジニアリングマネージャー雰囲気で分散システム使ってるやついる!?
♡ 32AWS, アルゴリズム, Database, 分散システム, QiitaEngineerFesta_設計AWS Summit Japan満喫方法 & ガバメントクラウド目線でのセッションレポート
♡ 16AWS, JapanAWSJr.Champions, ガバメントクラウド, AWSSummit2025, 2025JapanAWSJr.ChampionsKubernetes 上で HTTP 通信障害をシミュレートするカオステストをしてみよう
♡ 12kubernetes, istio, ChaosEngineering, Litmus, ChaosMeshAIネイティブ時代におけるジュニアエンジニアの生存戦略
♡ 8ポエム, AIAWS BuilderCardsで学ぶ、AWSセキュリティ基本の「き」 ~AWS BuilderCards日本語版開発者による、セキュリティ拡張パックの解説~
♡ 8AWS, Security, AWSCommunityBuilders, AWSBuilderCards現場ですぐ使える、アーキテクチャ設計の考え方
♡ 4アーキテクト, アーキテクチャ第09回 Customer系エンジニア座談会 を覗いて得た学び
♡ 4カスタマーサポート, 感想文, カスタマーサクセス
言及 Zenn 記事 (4 件)
この本に興味がある方におすすめ
この本に関連
関連記事
本棚を見ればエンジニアのレベルがわかる
エンジニアの本棚に並ぶ本の構成は、その人のスキルレベルとキャリアの方向性を映し出します。本棚の変遷パターンから、自分の現在地と次のステップを読み解く方法を紹介します。
セキュリティ本ガイド - Web 開発者が読むべき技術書の選び方
Web セキュリティの基礎から実践まで学べる技術書の選び方マトリクスと、読了後にやるべき 3 つのアクションを紹介します。
1 万行のコードより 1 冊の設計書が勝つ場面
大量のコードを書く力と、適切な設計を選ぶ力は別物です。コード量では解決できない問題に直面したとき、設計の知識がどう効くのかを具体例で解説します。
関連用語
オニオンアーキテクチャ
ドメインロジックを中心に据え、外側の層が内側に依存する同心円状のアーキテクチャ
C4 Model
ソフトウェアアーキテクチャを 4 つの抽象レベルで図示するモデル
アーキテクチャ
システム全体の構造設計。コンポーネントの分割と関係を決める最上位の設計判断
KISS 原則
Keep It Simple, Stupid - 設計をできるだけシンプルに保つことを求める原則
クリーンアーキテクチャ
ビジネスロジックを外部の技術的詳細から分離し、依存関係を内側に向けることで変更に強い設計を実現するアーキテクチャ原則
YAGNI
You Aren't Gonna Need It - 今必要でない機能を先回りして実装しない原則