本屋をぶらついていたらタイトルが目に留まったので読んでみることにした。
目次は以下。
CHAPTER 01 : カオスエンジニアリング誕生の背景
CHAPTER 02 : カオスエンジニアリングの概要
CHAPTER 03 : カオスエンジニアリングの実践
CHAPTER 04 : カオスエンジニアリングツール
CHAPTER 05 : CI/CDとカオスエンジニアリング
CHAPTER 06 : セキュリティとカオスエンジニアリング
CHAPTER 07 : 海外および国内におけるカオスエンジニアリング
CHAPTER 08 : エンタープライズへの導入に向けて
カオスエンジニアリングは名前は聞くけどやったこともないし、何かを読んだこともなかったので基本的なことから書かれているのがとても助かった。
カオスエンジニアリングの誕生はシステム全体が複雑化し、そのような状況下の中で障害箇所をすべて把握、対策することは困難なため、あえて障害を起こすして脆弱性を検証していくために考えられたというのが面白い。障害を前提として対策を日々考えていくのは対応力も身につきそうだなと思った。
以下のNetflix が提案しているカオスエンジニアリングの原則が紹介されている。 principlesofchaos.org
ここに書かれている原則は以下の5つ。
- 影響範囲を局所化する(Minimize Blast Radius)
- 定常状態における振る舞いの仮説を立てる(Build a Hypothesis around Steady State Behavior)
- 実世界の事象は多様である(Vary Real-world Events)
- 本番環境で検証を実行する(Run Experiments in Production)
- 継続的に実行する検証の自動化(Automate Experiments to Run Continuously)
カオスエンジニアリングを行うためのシステムとしては回復性と可観測性、自動化が高いシステムであることが必須と言っても良さそうだ。故障しないのではなくすぐに回復できるようなシステム、システムの状態を監視できる仕組み、継続的にテストを行うために低負荷でシステムを復旧できるような自動化。これらが最低限揃っていることで初めてカオスエンジニアリングを行うことができそう。どれか一つでもないとそもそもシステムダウンしたり、システムが落ちているかわからなかったり、作業者が高負荷になってしまうなどの別の問題が出てしまうのだろう。
この中で可観測性はモニタリングの代わりになるものではなく補完し合うものと紹介がされている。そのため必要なのは、ロギング・メトリクス・トレースといった3種類のデータを取得・活用できるようにする必要性が説明されている。このあたりはカオスエンジニアリングをしないとしても取得しておくべきものを定義しておくのが重要だなと思った。
後半はカオスエンジニアリングを行うためのツールの紹介、また実際にツールを用いてのCI/CD の組み立て方が紹介されている。自分でも少し試してみることができるのでわかりやすかった。
その後はセキュリティ、人・プロセスに対する導入などについても書かれているがこのあたりは知識が足りていないので読むだけになってしまった。もう少し勉強をしてから再度読み直してみたいと思う。
CHAPTER 07 では国内外の発表についてまとめられていてとても助かった。国内でもいくつもの会社が発表しており、見たことない資料もたくさんあったので紹介されているリンクを順に読んでみようと思った。
まとめ
- やってないけど興味があるレベルで読むのにはちょうどよい内容だった
- 自分のシステムで実行するかはともかく、回復性と可観測性でシステムを見直してみたいと思った
- このあとオライリー本も出るようなのでそれまでにもう少し勉強をしておこうと思う
