『カオスエンジニアリング（O'Reilly）』の参考文献を読み込む
当ブログは、O'Reillyから出版された訳書「カオスエンジニアリング」の書評となります。当書籍の最も感銘を受けた点がカオスエンジニアリングが科学として体系的にまとめられており、ソフトウェアに限らず多くの分野における研究と実践に基づいて理論が展開されている点でした。そのため、概要紹介、書評に留まらず、参考文献として引用されている論文や書籍•記事を個人的に読み本書の背景理論となった部分について中心的に学んでいきます。
本書の訳者であり、現職Autifyの同僚の堀 明子さんに献本いただき、本書を読むきっかけをいただきました。物理本には同じく訳者で同僚の松浦 隼人さんとともにサインをいただきつつ、個人的に電子版も買いました。
ブログカバーには表紙に採用されている新世界ザル、Common marmoset（Callithrix jacchus）をあつらえています。耳がフサフサでペットとして人気の動物らしいです。
ここから内容に入りますが、大体寝起きで書いており、文体の不揃いなどはうまくスルーしてください。だいたい朝4時ごろ布団の中でスマホぽちぽちして書いてるんだと想像していただければ。
著者陣
本書は、Casey RosenthalさんとNora Jonesさんによって執筆され、2020年4月に出版された、『Chaos Engineering』の訳書です。
Casey RosenthalさんはかつてNetflixのカオスエンジニアリングチームのエンジニアリングマネージャーを務めており、本書内で解説されているCI/CDに続くCV(Continuous Verification)のためのプラットフォームを提供するVericaのCEOを務めている方です。
Nora JonesさんはAWS re:Invent 2017にて、NetflixのSenior chaos engineerとして、カオスエンジニアリングについての講演（Why we need more chaos - chaos engineering, that’s it）をされ、現在はincident responseやincident reportのためのプロダクトを提供するJeliのCEOをされています。
両者ともに最前線でChaos Engineeringに向き合ってきた方々であることが経歴からも伺えます。
本書の概要
本書はまずカオスエンジニアリングの基本となる原則と理論を説明しています。前半の章を読むだけで、「カオスエンジニアリングって本番環境で障害を起こすやつだよね？」とか「NetflixのChaos monkey、Chaos kongのやつだよね？」という浅い理解を正確なものにしてくれます。カオスエンジニアリングにとって本番環境は絶対の条件ではなく、Chaos monkeyなどは一つのツール実装の形に過ぎないことが明確に説明されます。
そして、Slack、Google、Microsoft、LinkedIn、Capital Oneの５社の実践例が解説されます。多数のユーザーをグローバルに抱え、それを自前のデータセンターで運用しているような大規模な例から、監査が求められる金融サービスにおいてリスクをコントロールしながらChaos Engineeringを適用している例まで幅広く網羅されています。どれか一社の例は読者の境遇に近くなるようになってるのが印象的です。典型的なWebサービスを運営しているクラウドプラットフォーム上に展開している会社にとってはLinkedInの事例は面白いのではないか、と思います。
最後に、応用としてデータベースエンジニアリング（データベース自体の開発）やセキュリティ分野へのカオスエンジニアリングの展開について、最前線で行われてる事例と考え方が解説されます。まさに、Chaos Engineeringの起源から現在、未来までを見通すことができる一冊と言えるでしょう。
ここからは、読み進めていく中で気になった概念についてさらに深ぼって調べていきます。出てくるキーワードによって本書がどのような内容を解説しているのか、Chaos Engineeringはどのような分野にinspiredされながら育ってきたのか、感じることができるでしょう。
Human Factors and Safety Systems
カオスエンジニアリングを説明するにあたり、Resilient engineeringの分野が基礎となっている点を本書は前書きにて言及しています。
“レジリエンスエンジニアリングは、大規模にデプロイされたソフトウェアのような社会技術的なシステムを俯瞰する際に、信頼性やセキュリティを含む安全性の問題を見極めるためのレンズの役割を果たすもので、カオスエンジニアリングの基礎であると実証されています。”
特に著者は、Lund UniversityにてHuman Factors & Safety Systemsについて学ぶことを当大学のリサーチャーであるJohn Allspawに薦められたことへの感謝と言及をしています。Lund Universityは世界トップ100にランクされているスウェーデンの大学です。その大学が提供するHuman Factors & Safety Systemsでは、文字通りhuman factorとsafety systemを学ぶことができます。
Human factorsについてはいくつかの解説がありますが、人的ミスの最小化やパフォーマンスを向上させることを目的とし、製品、環境、システム、組織の最適化のために人間特性に関する知識を適用するものだとされています。
Human factors applies knowledge of human characteristics to optimise the design of products, equipment, environments, systems and organisations.
おそらく似たような響きの学問としてErgonomics（人間工学）という言葉がありますが、引用した記事によると、これらは互換性を持った使われ方をするようです。UKではErgonomicsが好まれる傾向にありUSAではHuman Factorsが一般的な用語として好まれています。
Netflix cloud migration
Netfilixは2008年にデータセンターからクラウドへの移行を発表しました。本書によると完全なるデータセンターの脱却には8年もの歳月がかかったと補足しています。2016年に完全なクラウドへの移行を報告しています。
Our journey to the cloud at Netflix began in August of 2008 (omit) The majority of our systems, including all customer-facing services, had been migrated to the cloud prior to 2015 (omit) We are happy to report that in early January, 2016, after seven years of diligent effort, we have finally completed our cloud migration and shut down the last remaining data center bits used by our streaming service!
クラウド移行の目的は2008年にデータベースの破損によってDVDの出荷ができなくなったインシデントによって明らかになった、単一障害点となる垂直スケールから水平方向にスケール可能な分散システムへの移行の必要性からです。
That is when we realized that we had to move away from vertically scaled single points of failure, like relational databases in our datacenter, towards highly reliable, horizontally scalable, distributed systems in the cloud.
この様々な意思決定の中で、データセンターでの垂直運用を前提としたアーキテクチャから脱却するため、現在有名となっている様々なプラクティスが導入されています。
一つのモノリスから数百のマイクロサービスアーキテクチャへ
NoSQLデータベースを用いた正規化
予算の承認、中央集権的なリリース、数週間要するハードウェア調達などは、各エンジニアリングチームがそれぞれ意思決定し各々がDevOps環境を選択するようになる
さらに、このクラウド移行の主要な目的ではなかったものの効率的なリソース配備が可能になったために、コスト削減にもつながりました。
Chaos Monkey and Chaos Kong; Netflix architecture updates
Chaos Monkeyはシンプルなアプリケーションで、全クラスタのインスタンス情報一覧をひととおり読んでから1つのインスタンスをランダムに選び、業務時間中のどこかのタイミングで警告なしに停止するもので、インスタンスが消失する障害がどのクラスタでも起きうるという想定のもとに、Netflixではこれは毎営業日行われました。
アプリケーション実装はGo言語にて記述され、SpinnakerとMySQL (5.6以上）に依存しています。SpinnakerはNetflixで利用されているContinuos Deliveryプラットフォームです。
その後2012年のクリスマスイブにAWSのELBの機能停止障害が発生したことをきっかけにChaos engineeringの取り組みはアップグレードされます。
AWSのELB障害はAWSが公開したpostmortemによるとstateデータの誤った消去が原因とのことでした。
The service disruption began at 12:24 PM PST on December 24th when a portion of the ELB state data was logically deleted.
Netflix目線でのpostmortemでは、このELB障害によって、US、Canada、Latin Americaでのサービス障害に繋がったと報告しています。
The outage primarily affected playback on TV connected devices in the US, Canada and Latin America. Our service in the UK, Ireland and Nordic countries was not impacted.
彼らのインフラ設計は互いのリージョンで疎結合な設計になっていたため、UKなど他リージョンには影響が及ばなかったものの、リージョンが落ちてもなおサービスを維持する設計への更新への意欲を述べていました。具体的にはリージョンレベルでのフェールオーバーを行うアーキテクチャが実装されました。
Netflixは各チームがそれぞれ裁量を持ち中央集権的に設計方法を揃えるような文化ではなかったため、リージョンが落ちうることを前提に設計することを期待として明確にするため、Chaos KongというAWS regionのダウンをシミュレーションするものを導入したと、その後のブログ”Chaos Engineering Upgraded”にて説明しています。ここで印象深かったのは、複雑性に関してのスタンスでした。
At Netflix we have an extremely complex distributed system (microservice architecture) with hundreds of deploys every day. We don’t want to remove the complexity of the system; we want to thrive on it. We want to continue to accelerate flexibility and rapid development.
数百のマイクロサービスを持つ複雑な分散システムでありつつも、その複雑性を廃そうとするのではなく、複雑なシステムとともに生き残る前提で論理を組み立てている。そのための一つのマネージメントの形がChaos Engineeringとして現れている。
リージョンレベルでのフェールオーバーに関して、50分もの時間がかかってしまう問題があり、それを10分以内に全てのフェールオーバープロセスが完了させる大きな仕事を”Project Nimble: Region Evacuation Reimagined”にて報告されました。当ブログでは50分かかるフェールオーバーの内訳を詳説したうえで、即座にサービスを起動しウォームアップ無しにトラフィックを受け付けられるようにする必要性があった旨を説明しています。
We set ourselves an aggressive goal of being able to fail over traffic in less than 10 minutes. In order to hit that kind of speed, we needed to eliminate the long poles. We needed services to start up instantly and be ready to take traffic without a warm-up period.
中央集権的なAutoscaling toolを作ったり全てのサービスのCDに手を入れるようなbig changeを避け、かつAutoscalingの仕組みは維持できるような考慮の結果、大きな負担なく本番ワークフローからは隠れた”Dark” groupを各サービスごとに用意する設計が施されたようです。
Principles of Chaos Engineering
オフィシャルに明文化されたChaos Engineeringの規律が、”Principles of Chaos Engineering”です。このドキュメントはGitHub repository chaos-eng/chaos-eng.github.ioにて管理されています。一枚ペラの端的な説明で重要なポイントを抑えることができます。特に冒頭の一文により、Chaos Engineeringがテストではなく実験の一形態である、という非常に重要な点を強調しています。
Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
本番環境にて行うことを推奨する有名な要素とともに、影響範囲を局所化するというリスクコントロールの重要性についても述べられており、この規律だけでChaos Engineeringに対する不信と誤解への回答となっている点が印象的です。
Advanced principles
Build a Hypothesis around Steady State Behavior
Vary Real-world Events
Run Experiments in Production
Automate Experiments to Run Continuously
Minimize Blast Radius
実験の継続的な自動実行についてはハードルが高いように感じると思いますが、本書を読めばすぐに分かる通りこれらを全てを必ずやらなければならないわけではありません。最初は手動からでも少しずつ必要に応じて発展的なやり方にアップデートしていくことを勧められています。
加えて、本書ではカオスエンジニアリングの規律は、Karl Popperのprinciple of falsifiability（反証可能性の原則）に大きく影響を受けていると言及しています。Falsifiabilit Principleとは、科学と非科学を区別するための方法であり、ある理論が科学的であると見なされるためには、その理論が考えられる限りにおいて誤りであることを証明できなければならない、というもの。
It suggests that for a theory to be considered scientific it must be able to be tested and conceivably proven false.
基準として、古典的な帰納主義的説明(Inductive reasoning)を偽証、すなわち演繹的論理(deductive reasoning)に置き換えた。
Popperが挙げた例は「All swans are white」という理論である。ヨーロッパ人が数100万のswanを観察し帰納法的証拠(Inductive evidence)からこの考えを提示した。しかし、のちにオーストラリアで黒いswanが発見される。
つまり、ある理論を確認する観測をいくらしても将来の可能性によって理論が否定される可能性は常にあり、帰納法では確実にできない。
これに対して、Popperは反証に基づく別の科学的方法を提示する。ある理論に対してどんなに多くの確証があってもたった一つの反証があればその理論を否定すできる。科学は、理論が誤りであることが示され現象をよりよく説明する新しい理論が導入されたときに進化する、と言え考え方。
Popper proposed an alternative scientific method based on falsification. However many confirming instances there are for a theory, it only takes one counter observation to falsify it. Science progresses when a theory is shown to be wrong and a new theory is introduced which better explains the phenomena.
システム思考における鞭効果
シンプルなソフトウェアシステムは線形的に変化するのに対して複雑なシステムは非線形的に変化し、Peter Sengeの”The Fifth Discipline: The Art & Practice of The Learning Organization”の中ではその相互作用を視覚的に捉える考え方として（鞭効果あるいはBullwhip effectという言葉を使ってるわけではありませんが）説明しています。
つまるところ、小さな変化がムチがしなるが如く遥か遠くのシステムの出力を生み出す、という現象について「フィードバック」という概念を用いてシステム思考を実践することでとある行動がどのように互いを強めたり打ち消したりするかを理解すること。フィードバックは直線ではなく環状に影響が循環するループであり、このプロセスには自己強化型(Reinforcing)とバランス型(Balancing)という二種類が存在することを指摘している。
There are two distinct types of feedback processes: reinforcing and balancing. Reinforcing (or amplifying) feedback processes are the engines of growth. Whenever you are in a situation where things are growing, you can be sure that reinforcing feedback is at work.
鞭のように小さな変化が大きな変化を生み出す構造はこのReinforcing feedbackである。マネージャーの期待によって部下のパフォーマンスが上がって行ったり、教師の無関心が教師が思った以上に子供に対して悪影響を与えたりする効果もこの概念によって説明可能とのことだ。
In reinforcing processes such as the Pygmalion effect, a small change builds on itself. Whatever movement occurs is amplified, producing more movement in the same direction. A small action snowballs, with more and more and still more of the same, resembling compounding interest. Some reinforcing (amplifying) processes are “vicious cycles,” in which things start off badly and grow worse.
AWS re:Invent 2017 Why we need more chaos - chaos engineering, that’s it
著者の一人で、2017年当時NetflixでSenior chaos engineerだったNora JonesさんによるAWS re:Invent 2017でのプレゼンテーションです。12分という短いプレゼンで非常によく概要が実例とともにわかりやすくまとまっています。
本書の補完情報として参考になったのは、NetflixにおけるビジネスKPIはSPS(Stream starts per second)という「再生ボタンが押せるかどうか」としている点でした。
Law of Requisite Variety by W. Rose Ashby
昨今のソフトウェアシステムの複雑性を認識するにあたり、1958年にW.R.Ashbyにより出版された“Requisite Variety and Its Implications for the Control of Complex Systems,”のなかで提唱されたLaw of Requisite Varietyがシステムの依存関係とそれがもたらす複雑性について説明している。
システムBを完全に制御するシステムAは、少なくともシステムBと同じくらいかそれ以上に複雑である
Casey Rosenthal
ここ内容に関連する論文がインターネット上に公開されていた。
朝6時寝起きの頭でも理解できる解説を探してYouTubeでの動画解説をいくつか見つけ、わかりやすかったのでリンクを残しておく。
Ashby's Law of Requisite Variety and Systems in Operations Management
Frederick Brooksによる複雑性の分類
複雑性に立ち向かうにあたって、Frederick Brooksが1980年代に提唱した２つの区別、偶発的(Accident)な複雑性と本質的(Essence)な複雑性が参照されていました。これはソフトウェア・エンジニアリングコミュニティでは有名な標語となっている"No Silver Bullet"がタイトルに添えられたIFIP Tenth World Computing Conference 1986への寄稿、"No Silver Bullet - Essence and Accident in Software Engineering"にて提唱されました。
彼の論文の中では、ソフトウェアを難しくする4つの特性として、Complexity、Conformity、Changeabiltity、Invisibilityを特定し、その中でも彼のComplexityについての考え方が様々なpaperに影響を与えている。個人的には1986年の段階で書かれたpaper内でのNo code solutionやAIに関する洞察は2023でも通用しうる点が多かったのが印象的だった。
この論文は他書籍でも参照されてるのを見ていて、例えば”Modern Software Engineering: Doing What Works to Build Better Software Faster”でもこの複雑性の分類を著者のDavid Farleyはこう説明している。ざっくり言うと、ソフトウェアが解決する問題領域自体の複雑性、銀行アカウント残高計算やロケットの経路計算などを、essential complexityと分類している。一方でそれ以外のものをaccidental complexityと表現しておりデータの永続化やスクリーン表示などコンピューターを有効に使うためにやるためのものであって、問題解決自体と直接関連しないものを指す、という考え方をとっている。
If the concept of “essential and “accidental” complexity is new to you, these are important ideas first described in Fred Brooks’ famous paper “There is No Silver Bullet,” mentioned earlier in this book.
The essential complexity of a system is the complexity that is inherent in solving the problem that you are trying to solve, how to calculate the value of a bank account, how to total the items in a shopping cart, or even how to calculate the trajectory of a spaceship, for example. Addressing this complexity is the real value that our system offers.
The accidental complexity is everything else—the problems that we are forced to solve as a side effect of doing something useful with computers. These are things like persistence of data, displaying things on a screen, clustering, some aspects of security…in fact anything that is not directly related to solving the problem at hand.
Onion architectureやClean architectureにおける考え方の根底にあるものと近似しており、実際本書ではこれらのアプリケーションアーキテクチャについても言及がされている。
また、O’Reilly出版の”97 Things Every SRE Should Know”のLaura Nolanによる一節”Complex: The Most Overloaded Word in Technology”内でもソフトウェアエンジニアとシステムエンジニア間での複雑性の意味しがちなところの違いについて言及しており、複雑性についての議論の際の基礎教養となっていることが窺える。ただ、Laura Nolanは、この概念ではソフトウェアエンジニアが考えてるcomplexityを説明しきれていないとしているのが興味深い。彼女は、複雑性について理解を難しくさせるものとした上で、Bob MoselyとPeter Marksによる論文”Out of the Tar Pit”を引用している。
Out of the Tar Pitでは、Brooks氏のcomplexityの捉え方に対して（少し）否定的な立場をとった上で、Functional programmingとCodd’s relational data modelという二つのアプローチによって複雑性を軽減する考えを示している。その根底にある複雑性への分析は、状態のハンドリング、コードボリューム、フローコントロールがソフトウェアシステムをわかりづらくする、というものだ。
We believe that the major contributor to this complexity in many systems is the handling of state and the burden that this adds when trying to analyse and reason about the system. Other closely related contributors are code volume, and explicit concern with the flow of control through the system.
ここまで見てきて、なんとなくカオスエンジリアリングの著者の文脈で言及したいessential complexityと、ソフトウェアアーキテクトないしアプリケーションを中心の関心たるエンジニアとの間でessentialだと認識している複雑性に少しズレがある気がしていた。これは自分の実体験でも様々な原因（関心度の高い領域の違い、アーキテクチャやソフトウェア品質特性に対する理解度の違いなどなど）でessentialだと主張するところは主観的な違いが発生してきた。Software EngineerとSystem engineer (SRE, etc)の間での違いについてLaura Nolan氏の次の一節が非常に腑に落ちた。正しく変更する難しさについての言及か、安定して動くことに対しての言及か。
Software engineers’ primary concern is the difficulty of making correct changes without introducing errors. Systems engineers’ primary concern is stability of the deployed software in production.
カオスエンジニアリングの本書籍において比較的この分類に対してはふわっとした解釈をしているのだろうと関連文献を見ていく中で理解した（もちろんだからといってこの書籍の価値は揺るがないが）。
“ソフトウェアに新しい機能を追加したり、可用性やセキュリティのような安全のための特性を加えるには、複雑性の増加を伴います。
要するに、複雑なシステムをシンプルなシステムに落とし込もうとすることは推奨できません。偶発的な複雑性は常に仕事の副産物として生じますし、本質的な複雑性は新しい機能によってもたらされます。”
動的安全モデル
レジリエンスエンジニアリングの分野でよく評価されているモデル。本書内ではそれをソフトウェアエンジニアの分野に応用した考え方を構築している。Jens RasmussenのDynamic Safety Modelが実際に理論の基礎となった考え方で、1997年にRisk management in a dynamic society: a modelling problemというタイトルで論文が発表されている。
本論文において読者視点でよく引用されるのが次の図である。この図では3つの境界のなかで適した仕事の最適化を行う努力の様を示している（と理解した）。
その3つは、Functionally acceptable performance、unaccepatable workload、Economic Failureであり、これをベースにカオスエンジリアリングではEconomic、Worload、Safetyを支柱とした上でエンジニアは仕事をそれとなく最適化するという考え方をする。
“動的安全モデルは3つの特性を持っています。経済性（Economics）、ワークロード（Workload）、そして安全性（Safety）です（図2-1）。これらの特性にゴムバンドでくくりつけられ、その真ん中にいるエンジニアを想像してみましょう。勤務中は、エンジニアはゴムバンドの中を動き回ることができますが、エンジニアが特性から遠ざかりすぎるとゴムバンドは切れてゲームオーバーになってしまいます。”
本書では非常に納得感のあるエンジニアの特性を言及している。エンジニアは経済性（例えばインフラコスト）についての感覚はある程度つくし、ワークロード（例えば勤務可能な勤続時間）についてもそうで、これらに敏感だから仕事やワークフローの自動化について積極的に取り組む。しかし、セキュリティも含めた安全性になるととたんに許容可能な安全性について意識して学んだり訓練していないと境界線があいまいなケースが多い。自分も株式市場への上場のための準備の過程で身をもって体験したことや、極めてセンシティブな個人情報を扱うソフトウェアシステムの構築、セキュリティへの関心が強い低レイヤーなシステムの設計をフルフルやったことなどによって、意思決定が必要な際にリスク評価ができるようになった（とはいってもたかが知れてる）が、そのような経験はあまり一般的ではない分scratchから行う議論がうまくいかない経験をよくしている。
さらに目に見えるところに対してより注意が向くという特性から経済性とワークロードに対しての最適化の意識は向くが、安全性に対する最適化は意識から薄くなってしまう。そして、カオスエンジニアリングはこの安全性に対しての直感を養う一助になる。カオスエンジニアリングの実験で得られた結果はエンジニアが直感で安全性を理解する証拠となる。
複雑性の経済的支柱
このモデルは、Kent Beckが発表したを応用したものだと説明されている。Kent Beck自身は、University of TrentoのEnrico Zaninottoが2002年のThe Extreme Programming Coferenceのkeynoteで発表した内容基づいてこれを公開している。若干登場人物の相関関係が日本語で示すにはややこしかったので洋書での言及も載せておく。直接Kent Beckのpostを見ても冒頭でEnrico Zaninottoの発表についての言及があるので明らかではある。
This model is an adaptation of a model presented by Kent Beck,3 which was informed by a presentation by Professor Enrico Zaninotto, Dean of Economics at the University of Trento.
このポストでは、複雑性について頭を悩ませる4つの要素、States, Interdependencies. Uncertainty, and Irreversibilityがあるとし、車産業では著名であったフォード生産方式がどのようなプラクティスでStateを減らしてきたを言及した上で、Facebookのプロダクト開発を例に取りこれらの複雑性に対して取りうるアクションをXPの文脈を交えて説明している。
カオスエンジニアでは、このモデルを応用し複雑性の経済的支柱を4つ示している。States（状態）、Relationship（関係）、Environment（環境）、そしてReversibility（可逆性）である。Kent Beckのポストを読んでから書籍を読み返すと、カオスエンジニアの書籍内では元の文脈を壊さない範囲でうまく言葉を言い換えていることが伺えた。
Antifragility（抗脆弱性）
カオスエンジリアリングと類似した考え方に、Nassim Talebによって提唱された Antifragility（抗脆弱性）というものがある。この概念は、Antifragile: Things That Gain from Disorderという彼の書籍で詳細に読むことができる。
カオスエンジニアリングとの違いについて、本書カオスエンジニアリングではこう説明していた。
カオスエンジニアリングと抗脆弱性の重要かつ決定的な違いは、カオスエンジニアリングは人間の運用者たちがより回復力を持つチームになれるよう、すでにシステムに内在しているカオスに関する教育を行うことです。一方の抗脆弱性は、システムに対しカオスを追加するのに応じて、システムが屈せずに強化されていくことを望むものです。
違いを強調する背景として、Antifraglityにはカオスエンジニアリングが土台とするレジリエンスエンジニアリングやヒューマンファクター、安全システムに関する学術研究とは相入れない指針を提示していると指摘している点がある。たとえば、このような点を本書は指摘していた。
システムの堅牢性を高める最初の一歩は弱点を探し除去することだ、とAntifraglityは言うが、レジリエンスエンジニアリングでは欠点よりもうまくいっている点を探す方が有益という立場をとる
冗長性の追加を堅牢にする手段として提示しているが、冗長性の追加は安全の失敗につながる事例がレジリエンスエンジリアリングの文献に多数見られる
冗長性の追加における安全性の失敗について本書が例に挙げたのが1986年のチャレンジャー号の爆発事故。ロケットと飛行機の話はこの分野だと毎回出るし、なんならカンファレンスのプレゼンテーションのスライドに乗せているのをよく見かける。凄惨さを訴えかけるには十分すぎる事件だから、というのも一端だろう。
The Challenger disaster occurred 73 seconds after its Jan. 28 launch, killing all seven of its crew, when a faulty joint in the right rocket booster allowed hot gases to escape and sear through an adjacent tank of explosive hydrogen.
The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASAという書籍内でこの事例について詳細に語っている。
この事故の原因の一端となったのがO-ringという部品だが、これは過去実績のあったTitanという製品の設計に基づいてprimary/secondaryと冗長性（Redundancy）の高いシステムになるように考慮されていたものであった。
The Titan had one O-ring, the shuttle design had two—a primary and a secondary to back up the first. Both Thiokol and NASA believed that the second O-ring provided a redundancy that further increased the safety and reliability of the original Titan design.
しかし、Titanの設計ではこのO-ringの冗長性のために他の箇所でも必要な設計差分があったと、本書では説明していた。
These design changes—especially the elongated tang necessary to support two rings—altered the functioning of the joint. In reality, the SRB joints were a different, and untried, design.
全ページしっかり読めてなく関連しそうな箇所を数十ページ飛ばし読みした程度だが、かなり詳細にNASAでの議論過程や設計内容が入っており、ロケット技術に詳しくなくても楽しめる内容のようだった。
ChAP: Chaos Automation Platform
カオスエンジニアリングにおいて影響範囲を局所化することは重要な原則としてすでに紹介したが、Netflixではこれをツールとして支援するためのプラットフォームを構築していることを、同社のブログポストChAP: Chaos Automation Platformで説明している。
まずこのツールは特定の少数のリクエストのみ実験対象クラスターに送る、といったことをサポートする。実験中のメトリクスはグラフで可視化される。
To limit this blast radius, in ChAP we take a small subset of traffic and distribute it evenly between a control and an experimental cluster.
さらにError budgetを超えた際に自動で実験を終了するCircuit Breakerの実装が用意されているのも興味深い。
Slack: Disasterpiece Theater
Slackにおけるカオスエンジニアリングの取り組みを彼らはDisasterpiece Theater（惨劇シアター）と呼んでいる。本書の第4章はこの取り組みについて詳しく説明しているのだが、publicに公開されているブログや講演などがあるかどうか見てみた。
まず全然関係ないかもしれないが同名のコメディがTVショーで1980年代初頭あったらしい。
本題に戻るとSlackのPrincipal EngineerであったRichard CrowleyがDisasterpiece Theater: Slack’s process for approachable Chaos Engineeringというブログポストを公開していた。当時1000万DAUの規模まで成長していたSlackにおいて、新しいコードに対するFault torelanceをテストする機会があまり取れていなかったことを問題視していた。
このポストの中で彼が参照したのがJames HamiltonがLISA 07で公開した論文On Designing and Deploying Internet-Scale Servicesである。この論文では運用しやすいサービスを運営するための一連のプラクティスについて言及しており、Design for failureやRedundancy、fault recoveryなど現在でも失敗エラー時でも”正しく”動くシステム設計についての言及がされている。
Google DiRT
GoogleのSite Reliabity EngineeringにおけるひとつのトピックであるDisaster Recovering Testingのプログラムは2006年から始められており、その目的はまだ明らかになっていないリスクを炙り出すために意図的に障害を引き起こすというものであった。
障害発生時のロールプレイの形で始まったことがOreillyのSite Reliability EngineeringのAccelarating SREs to On-Call and Beyondにて紹介されていました。
Google SRE teams address these challenges through a time-honored tradition of regular disaster role playing. Among other names, this exercise is commonly referred to as “Wheel of Misfortune” or “Walk the Plank.” The sense of humorous danger such titles lend the exercise makes it less intimidating to freshly hired SREs
印象的だったGoogleにおける取り組みもコントロールされたカオスを選ぶという点で、世の中に雑に認識されているカオスエンジリアリングのイメージとはここでもギャップがある点が浮き彫りになる。
そして、もうひとつ面白いのは、人々は緊急事態が演習の一部であると知るとインシデントに対して手ぬるい対応をしがちなため、なるべく本番と同じ緊急度で扱うことを求めている点。学校の火災訓練でだらだらと校庭に集合するあの現象なのだろう。Lea WinermanのFighting Fire with Psychologyという論文（2004年）は関連資料として引用されており、そこでは意外と人は火災時もパニックに陥ったりはしない、といったいくつかの発見が報告されている。
Hyrum’s law
Hyrum’s lawは次のフレーズでまとめられるユーザーのサービス信頼性に対する期待値について言及した考え方。
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
APIだと分かりやすく、仕様に書いていない振る舞いがあったとしても「実際こういうふうに振る舞うっぽい」っていうのがそのまま期待値変わっていくのを観測したことがある。
なお、Hyrumは当記事を公開時Googleのソフトウェアエンジニア。
I'm a Software Engineer at Google, working on large-scale code change tooling and infrastructure. Prior to that, I spent five years improving Google's core C++ libraries.
このほかにもたくさん面白い話にまつわる参考文献があったが、いったんここで終わりにしておく。
この記事が気に入ったらサポートをしてみませんか？