カオスエンジニアリング

エンジニアに向けカオスエンジニアリングの概要と行動原則を解説!
カオスエンジニアリングとは、本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にも耐えられるようにする取り組みです。マイクロサービスや分散技術に移行するにつれて、システムの複雑さが増していますが、カオスエンジニアリングによって脆弱性を発見し、顧客に影響を与える前に停止を防ぐことができます。本書は、エンジニアに向け、ビジネス目標を達成するために最適化を行いながら複雑なシステムを運用する方法を示します。

『カオスエンジニアリング』 (Casey Rosenthal、Nora Jones 著、堀 明子、松浦 隼人 訳、オライリー・ジャパン、2022 年 6 月刊) は、複雑になったシステムの弱点を実験によって先に見つけ、障害に自信を持って対処できる組織をつくるための理論と原則、実践方法を解説した書籍です。副題は回復力のあるシステムの実践、原書は Chaos Engineering です。書誌の紹介文はカオスエンジニアリングを、本番稼働中のサービスにあえて擬似的な障害を起こすことで実際の障害にも耐えられるようにする取り組みと説明しています。版元の紹介文によると、Netflix でカオスエンジニアリングチームを立ち上げた先駆者である著者に加え、さまざまな組織のリーダーたちが多角的に解説する構成で、障害対応の訓練を一回きりの行事で終わらせず、継続的な仕組みとして根づかせたい人に向いた一冊です。

イントロダクションと全 5 部 21 章、各社の事例から応用まで

目次は、Chaos Monkey の誕生から規律の明文化、コミュニティの誕生までをたどるイントロダクション「カオスの誕生」で始まります。第 I 部「舞台準備」の 1 章〜3 章で複雑なシステムとの向き合い方と原則の全体像を示し、第 II 部「原則の実践」の 4 章〜8 章では Slack、Google、Microsoft、LinkedIn、Capital One の取り組みが章ごとに紹介されます。第 III 部「人間的な要素」は先見性やループの中の人々、実験の選択に関する課題を、第 IV 部「ビジネス要因」は費用対効果やカオスの成熟モデル (CMM) を扱います。第 V 部「進化」は継続的ベリフィケーション、サイバーフィジカルなシステム、HOP との関係、データベースにおけるカオスエンジニアリング、セキュリティカオスエンジニアリングの事例へと広がり、21 章「おわりに」で締めくくられます。理論から事例、人と組織、応用へと視野を広げていく並びと読めます。

仮説と実験で複雑なシステムの弱点を探る考え方

マイクロサービスや分散技術を組み合わせたシステムでは、部品ごとのテストに合格していても、部品どうしのつながり方から想定外の障害が生まれます。カオスエンジニアリングは、正常に動いている状態を指標で定義し、障害を加えてもその状態が保たれるという仮説を立て、影響範囲を絞ったうえで実際に障害を起こして確かめる、という実験の手順でこの問題に向き合います。仮説が崩れたときに見つかるのは、設定の誤りやタイムアウトの連鎖、依存先の想定外の振る舞いといった、設計図を眺めているだけでは気づきにくい弱点です。インスタンスを無作為に止める Chaos Monkey はこの考え方の出発点として知られ、版元の紹介文が中心に置く ゲームデー は、チームが集まって計画的に障害を起こし、システムと人の対応の両方を確かめる場にあたります。第 V 部の継続的ベリフィケーションは、こうした実験を手作業の行事から日常的に回る仕組みへ移していく段階の話題として位置づけられます。

人と組織の章が厚い、SRE や運用の責任者が読む前提

目次を見る限り、特定のツールの操作手順を章として立てた構成ではなく、事例と原則、人と組織、費用対効果の議論が中心です。そのため、障害注入ツールの導入手順だけを手早く知りたい人には遠回りに感じられる可能性があります。一方で、分散システムやマイクロサービスの運用に携わった経験があり、障害の振り返りやオンコールで同じ種類の問題に何度も向き合ってきた人にとっては、なぜ本番に近い環境で実験するのか、実験をどう選び、費用対効果をどう説明するのかという問いに対して、5 社の事例と複数の視点から材料を得られます。SRE の実践を組織に広げる立場の人が、経営や他チームへ説明するための論点を整理する用途にも合います。

障害が起きてから原因を探すのではなく、起きる前に弱点を見つける運用へ切り替えたいと考えている SRE、インフラエンジニア、開発チームのリーダーにとって、本書は Netflix 以外の組織の取り組みも含めて、始め方と続け方の両方を見渡せる一冊です。自社でゲームデーを企画する前に第 I 部と第 II 部を通して読み、自分たちの組織に近い事例から手を付けると、最初の実験の範囲を決めやすくなります。