オープニングトーク： 複雑なシステムへようこそ July 20th, 2022 Meiko Hori Chaos Night #1

自己紹介 Meiko Hori 堀　明子 Customer Reliability Engineer @ Autify ● 略歴 ○ SIerに十数年所属。客先常駐 SES暮らし ■ Webアプリ開発/システム運用/プロジェクトリーダー ○ 2020年8月よりAutifyに参画 ○ 書籍「カオスエンジニアリング」共訳 ● 趣味 ○ 絵と音楽（作る/歌う/聴く） ○ 旅と食（北アフリカから中米まで）

Autifyとわたしのお仕事 Webアプリケーションの自動テスト Autify for Web 14日間無料トライアル受付中 https://autify.com/ja/trial ネイティブアプリケーションの自動テスト Autify for Mobile デモリクエスト受付中 https://autify.com/ja/mobile

Autifyとわたしのお仕事 Contract Data Support Data Company Data Analytics Customer Success Platform お客様の状況把握 Prod DB お客様 プロダクト お客様の活用支援 CSM カスタマーサクセスチーム 「お客様の支援を支援する」データ基盤 を作ってます。詳細はブログへ https://blog.autify.com/ja/autify-cs-to ol-and-activities-2 CRE

本日のテーマ 複雑なシステムと、それに対する学びを深めるアプローチとしての カオスエンジニアリング

事前アンケートの結果 あなたにとってカオスエンジニアリングとはどのようなものか、一番近 いものをお選びください。 「まだよくわからないが気 になる」＋「実践してみたい が何からやればよいかわ からない」の合計 = 83.3%

複雑なシステム vs シンプルなシステム ● システムへの入力に対し、予測が容易な出力が返ってくる ● 構成要素に依存関係が少ない シンプルなシステム System 入力 出力 User Owner

複雑なシステム vs シンプルなシステム ● 複数の構成要素が互いに依存しあっている ● システムへの入力に対し、返ってくる出力の予測が難しい 複雑なシステム Service A 入力 出力 User Owner X Service B Service C External system E Data store D Owner Z Owner Y

複雑なシステム vs シンプルなシステム ● 各人がシステムに対して描くメンタルモデルが異なる ● 個別の各構成要素の振る舞いは理解していても、全体としてどの ような振る舞いをするかを誰も把握しきれない 複雑なシステム Service A 入力 出力 User Owner X Service B Service C External system E Data store D Owner Z Owner Y New joiner N ?

どんなことが起こりうる？ ● 外部システムの予期せぬ振る舞いにより、それに依存する要素が 期待通りの動作をしなくなった ○ Hyrumの法則 ある程度以上のAPIのユーザーがいれば、契約で約束されたこと はもはや力を持ちません。観測されるシステムのあらゆる振る舞 いに対し、他者が依存するようになるのです。 ● 呼び出し元側へ想定外のエラーコードが返却された結果、ユーザー にとって不可解な画面が表示された ● 特定の条件下でリトライロジックが機能しなかった などなど 複雑なシステムでは、これらが積み重なった結果思い がけない大きな障害に繋がる場合がある

どんなことが起こりうる？ ● 外部システムの予期せぬ振る舞いにより、それに依存する要素が 期待通りの動作をしなくなった ○ 例：Hyrumの法則 ある程度以上のAPIのユーザーがいれば、契約で約束されたこと はもはや力を持ちません。観測されるシステムのあらゆる振る舞 いに対し、他者が依存するようになるのです。 ● 呼び出し元側に想定外のエラーコードが返却された結果、ユー ザーにとって不可解な画面が表示された ● 特定の条件下でリトライロジックが機能しなかった などなど どうやって 「予期せぬ」「想定外の」「特定の条件下」 を見つけよう？ 🤔

素朴な疑問 そもそも複雑性を排除して、もっとシステムをシンプルにできた ら、未知の事象も減らせるのではないか？ もっと入念にテストしたら、複雑な依存関係に起因する予期せ ぬ障害を防げるのではないか？

実験 vs テスト テスト ● システムについて既に知られた特性が、期待通りであることを確認する ● 主に、検証を行いたい対象が明らかになっているものに効果的 実験 ● 仮説を立て、その仮説の反証を試みる ○ 反証されなかった場合は、仮説の信用度が上がる ○ 反証された場合は、新たなシステムの特性に関する学びが得られる ● システムの 未知の特性 を見つけるのに効果的 カオスエンジニアリングの アプローチは主に実験寄り

ベリフィケーション（検証）vs バリデーション（妥当性確認） バリデーション（妥当性確認） ● 個々の要素が期待通りに実装されていることの検証に重きを置く ● 水道水の妥当性を確認するには ○ 水道の配管や浄化、給水のシステムなど、水が届けられる過程にある全ての要 素が期待通りの状態であるかを検査する ベリフィケーション（検証） ● ビジネスケースと 総合的な出力 に重きを置く ● 水道水を検証するには ○ 蛇口から出てくる水（出力）が正常かどうか水質検査する カオスエンジニアリングの アプローチは主に検証、 ベリフィケーション寄り

カオスエンジニアリングによる未知への対処 問題が発生するよりも前に、システム全体としての振る 舞いを検証できるような実験を考えよう！ 複雑なシステムでは、構成要素の相互作用から予測困 難な未知の事象が発生しうる

カオス実験の進めかた カオスエンジニアリングの原則にのっとると ... 1. システムの「定常状態」を定める：正常な振る舞いを示す測定可能な出力を使用 2. 定義した「定常状態」に関する仮説を立てる：制御グループ（対照群）と実験グループのいず れにおいても継続すると想定 3. 実験グループに対し、実世界の事象（イベント）を反映する変数を導入する 4. 制御グループと実験グループの間に定常状態に関する差異を調べ、仮説の反証を試みる a. 仮説が反証されなければ、仮説の確からしさが上昇する → 自信の向上 b. 仮説が反証されれば、新たな発見が得られる → 未知だったシステムの特性が 既知に！

カオス実験の進めかた カオスエンジニアリングの原則にのっとると ... 1. システムの「定常状態」を定める：正常な振る舞いを示す測定可能な出力を使用 2. 定義した「定常状態」に関する仮説を立てる：制御グループ（対照群）と実験グループのいず れにおいても継続すると想定 3. 実験グループに対し、実世界の事象（イベント）を反映する変数 を導入する 4. 制御グループと実験グループの間に定常状態に関する差異を調べ、仮説の反証を試みる a. 仮説が反証されなければ、仮説の確からしさが上昇する → 自信の向上 b. 仮説が反証されれば、新たな発見が得られる → 未知だったシステムの特性が 既知に 「定常状態」とは？ 出力を測定する仕組み は備わっている？ 変数には何を入れれば よい？

実験をしようと思った時点で、考えることがいっぱい システムの出力として観測できるもので、エンドユーザーに提供して いるビジネス価値に沿った内容で表現できると理想的 (Netflixの場 合は、秒間ストリーミング開始件数：Streams Per Secondのような メトリクスを利用している) 定常状態がメトリクスの形で表現されるのであれば、継続的に取得 できる可観測性のインフラを整えることから 「定常状態」とは？ 出力を測定する仕組み は備わっている？ 変数には何を入れれば よい？ すでに具体的な懸念が仮説に表現されているのであれば、そこから 始めるとよい。一般的な実験としてはレイテンシの注入やプロセスの 終了など、多様なものをサポートするツールがある 一律に適用可能な解はない。チームで議論をするところからはじめよう

まとめ システムの複雑性は、システムの提供する価値に応じて必然的に増加する システムの未知の特性を発見するためには、テストよりも実験が効果的 システムが総合的に期待通りに稼働しているかを見るためには、バリデーション （妥当性確認）よりもベリフィケーション（検証）が効果的 カオスエンジニアリングは、実験とベリフィケーション（検証）に重きを置いて、複雑 なシステムの未知の特性を発見し、プロアクティブに対処可能としていく上で有用な 手法 効果的なカオス実験は一日にしてならず。実験の準備を行う過程へ一歩踏み出し て、チームで考えはじめた時点から価値が生まれる

おまけ 実験はコストがかかりすぎたり、十分な価値をもたらすと見なされず、日の目を見な いこともよくあります。ある程度の期間何かを試し、受け入れた後すぐに放棄してし まっても構いません。（中略）新たなアイディアを持って試す時間をとった時、あなた は着実に正しい方向に向かっています。 - Andy Fleener, 「カオスエンジニアリング」第10章より

参考資料 ● Principles of Chaos Engineering（カオスエンジニアリングの原則） ○ https://principlesofchaos.org/ ● Getting Started with Chaos Engineering • Nora Jones, Casey Rosenthal & James Wickett • GOTO 2020 ○ https://www.youtube.com/watch?v=vkxVaqS7q2Q ● Rethinking How the Industry Approaches Chaos Engineering ○ https://www.infoq.com/presentations/rethinking-chaos-engineering/ ● カオスエンジニアリング – 回復力のあるシステムの実践 ○ https://www.oreilly.co.jp/books/9784873119885/

ご清聴ありがとうございました！ 引き続き、皆様の発表をお楽しみください🎙