イベント概要
以下の勉強会に参加してきたので、そこで得た知見を残す。
ちなみに対象の章は、１～２章です。
原則
カオスエンジニアリングにおける原則が載った記事は以下。
参加してみて得た知識
線形と非線形の違い
線形とは、１か所とかで他とつながっており、
影響範囲などが予測しやすいシンプルなシステムのこと。
非線形とは、動的に複数個所でつながっており、
動作させてみて初めて問題個所が浮き彫りになったりする。
そして、ある部分の変更における影響範囲が直線的か、そうでないかが
この線形と非線形の名前の由来である。
当然、影響範囲の特定や仕様変更に伴う見積もりの計算とかも、
線形システムの方が単純である。
少し変えたら少し変わるのが、線形。
少しの変更が全部変えるなど、予測しにくいものは非線形。
つまりは、モノリシックシステムであろうとも、
一か所の変更や障害が予期せず多数箇所に波紋しているようなら、それも非線形といえますね。
意図しないユースケースの発見につながる
システムが複雑化すればするほど、システムの利用者は開発者などが想定していた使われ方とは全く異なる使われ方をする。
このような本来意図していなかった望ましくないような使われ方による損害を回避するためにも、ハイリスクなものにおける実験活動は重要である。
カオスエンジニアリングとテストは違う
テストだけでは限界がある。
本番環境でのみ出るバグがあるからだ。
しかし、本番環境でのテストはなかなか難しい。
ゆえにカオスエンジニアリング。
それによって、想定外を減らしていく。
つまり、本質的複雑さを取り除いて、ビジネスやITへの安心感をもたらしていく。
複雑さと器用に向き合う
ビジネスの成長のためには、一定の複雑さが回避できない。
でもそうすると、今度は予期しないことが起きやすい。
これによって事業の継続性を損なわないために、
本番環境において実験を継続的に行い、事前にハイリスクな脅威をつぶしておくために必要な手法といえる。
運用ビューの事前設計のための実験である
以下の本では、運用ビューというシステムだけではカバーできない部分を
事前に運用ビューとして定義する。
この中には、機能的な観点も、データ系の観点も含んで考えているのが、
この本における文脈である。
カオスエンジニアリングを読んでいて思ったのは、
それによって、システムだけでなくビジネス全体への信頼性向上、耐障害性などにつながっていきやすい。
３つの軸でバランスのいい所を探しやすい
経済性というビジネス価値の軸
ワークロードという運用者の労働における負担
可用性やセキュリティなどの安全性
これらすべてをバランスよく満たす部分を探さなくてはいけない。
書籍には以下のような３つを輪ゴムで連結した簡易モデルで表現されていた。
どれか２つを強く満たしても、もう１つから重心部分(3つの線分が交わるところ)への距離が伸びきって、ゴムの限界値を超えて切れてしまう。つまり満たせなくなってしまうということ。
つまり、３つの軸は互いに影響を及ぼしあっている。
ゆえにバランスのいい所を探すことは困難を極める。
もしも対象の事業における満たさなくてはならない、
強い関心を集める安全性というものが何なのか？
わからないメンバーでしか構成されていない時に、カオス実験によって各〇から重心までの限界値を知ることができるという恩恵がある。
事例
あまりにも安全性を高めることにコストを使い続けていては、
運用する人たちにサービス残業や長時間労働をしいるなどのワークロード上の問題
得るリターン以上に出費という経済正常の問題
などによって、事業が継続できなくなってしまっては安全性すら満たせなくなってしまう。
実験によって、継続的に「この辺が重心位置だよね」という箇所を探し続ける。
理由としては、環境変化によって重心位置が変わってしまうから。
事業方針の強化につながる
カオス実験は認知できていなかった脆さを表面化させる。
事業方針などを最初に打ち出していようとも、
この不確実性の高い社会の中で最初から脆さなどを認知できているようなケースなんて
かなり少ないのが実情。
自社サービスだったりとかすると、自分たちの事業活動の裏の側面をクリティカルにかんげるなんて、なかなか難しいものだったりする。
そんな時に、カオス実験を通して露呈した脆さに対して、
「その脆さはあえて受け入れる」と判断するのか？
それとも、「その脆さにはコストをかけてでも対策する」と判断するのか？
その判断軸、つまり事業方針をより強固なものとする。
これはある意味、事業の良い部分を際立たせる活動でもある。
まとめ
カオスエンジニアリングは、実験によって想定外の使われ方による大きな損害を抑制し、
安心感をもってビジネスを回していくために必要なもの。
これは複雑化したビジネスでこそ、より威力を発揮する。
想定外のことを実験を通して学び続けることで、バックアップ戦略などの土台作りにもなる。
感想
非線形システムの怖い体験話
非線形の話は一番印象に残っている気がします。
というのも、筆者は大規模分散モノリシックアーキテクチャの案件に入っていた経験があり、しかも以下の特徴がありました。
システムオブシステムズという、複数のシステムの系からなるアーキテクチャ
各構成要素のシステムは、別々の組織で運用されることが前提
テスト基盤はなし
という、まさに超非線形＆超複雑系システム！！
動作させて初めて問題が発覚するなんてことはざらにある状態。
こういったものほど、カオスエンジニアリングは必須であり、
その実験を通して、
どういった安全性を担保すべきか？
システムが落ちた場合に、運用でカバーするのか？ そこにかかるコストは？
何を監視すべきなのか？
といったことを定義する姿勢が求められる。
モデリングと組み合わせて行う
コードベースでカオスエンジニアリングを行うことは、
複雑なものをさらに複雑化させて議論するようなものだと感じる。
よって、ビジネスサイドも巻き込んで行う必要がある以上、
モデリングなどの図解ベースでカオスエンジニアリングを行うことが必須と感じる。
特に、カオスエンジニアリングを行うには、
チームトポロジー×脅威アジャイルモデリングが必須
といってもいいかもしれない。
脅威モデリングとカオスエンジニアリングは密接に関係している
以前書いた記事でこんなものがあるので参考までに。
さらにそのためには、脅威モデリングが必須といっても過言ではないので、
以下の記事も参考にしていただきたい。