こんにちは。冬場に太りがちのとりです。
2023年3月9日～10日に開催された、ソフトウェアシンポジウム JaSST’23 Tokyoに参加しセッション拝聴してきましたので、レポートします。今回は他にもレポート記事が公開されると思いますので、まだ参加された事が無い方はこれらの記事で興味を持って次回JaSSTのご参加に繋がればとっても嬉しいです。
私は、今回のJaSSTでは基調講演と企画セッションで発表頂いたカオスエンジニアリングテーマの講演が印象的でしたので、要約レベルですがどんなセッションだったか紹介します。
ただ基調講演に関しては、同時通訳頂いた内容に更に私のフィルターがかかるので、講師の方の言いたい事と、もしかしたらニュアンスが違う点も出てくるかもしれませんがご容赦ください。
基調講演「Chaos Engineering to Continuous Verification」
講師：Casey Rosenthal 氏（Verica）
講師のCasey Rosenthal氏は、VericaのCEO（共同設立者でもある）で以前は長年Netflixでカオスエンジニアリングチームのエンジニアマネージャーを務めていたそうです。カオスエンジニアリングのバイブルとも言える下記書籍を執筆された著名な方でもあります。
Chaos Engineering: System Resiliency in Practice／Casey Rosenthal (著), Nora Jones (著)
なお、基調講演はグラレコが取り入れられています。こちらは後日JaSST公式サイトに掲載予定と聞いていますので、気になる方は後日確認いただけるとより理解が深まるかもしれません。
カオスエンジニアリングとは（事前にインプットした知識）
カオスエンジニアリングという言葉。日本ではまだ馴染みが無いと思いますが、恥ずかしながら私もJaSSTに参加するまで言葉を聞いた事がある程度でした。という事で事前に少し調べました。
カオスエンジニアリングとは、開発環境や本番環境のシステムに意図的に障害を発生させ、システム復旧までの経過を見ることによりシステムのウィークポイントを発見するといったエンジニアリング手法です。
後半で紹介する企画セッションでも触れられていましたが、一般的なソフトウェアテストが仕様や期待結果が分かった上でそれ通りの結果が得られるかをテストするのに対し、カオスエンジニアリングはあらかじめ知られていないし理解もされていないものに対してのアプローチで、検証というより実験に近い手法になります。
Casey Rosenthal氏の講演の内容はとても情報量が多かったので、私なりに語られた内容をピックアップして書き出してみます。
Casey Rosenthal氏のこれまでのプロジェクト
まず、Casey Rosenthal氏ご自身が関わってきたプロジェクトについて紹介されました。
・ Netflixでカオスモンキー（CHAOS MONKEY）が開発された契機
・ Netflixでの事例
・ カオスオートメーションプラットフォームCHAPを作成した話
画面はサービス間のトラフィックの流れを可視化したビュー（と認識）。エラーが含まれるトラフィックやエラーノードは赤色や黄色で表示されています。あくまでサービス全体像のイメージだと思いますが、どのトラフィックによりどこのシステムがエラーとなるか予測は難しいと想像できます。
アベイラビリティ（availability）事例
アベイラビリティ（availability）は日本語に訳すと「可用性」にあたり、どのくらいシステムが正常な状態で継続的に作動し続けるかという指標の一つです。講演では以下の様なアベイラビリティの事例が紹介されました。
・ Gamedayの事例
Gamedayについては、システムに障害が起きた際にどう対処するか、皆で集まって実際のシステムに対して試す日というように説明されていました。
・ 一部サービスの障害がサービス全体の障害に繋がった事例
各サービスを担当するチーム間で起こりうる問題の可能性を話し合えていれば防げただろうといった話がありました。
・ 安全の為に導入されたコードフリーズにより障害が発生した事例
近代的な複雑なシステムでは予測できなかっただろうといった話がありました。
Casey Rosenthal氏のプロジェクトで一般公開されているサイトの紹介もありました。
VOIDというサイトで様々な企業から提供を受けたインシデントレポートを参照できるサービスとの事。日本ではなかなかこの様な企業間のオープンな取り組みは見られないので私も非常に興味を持ちました。時間が取れたら一度使用してみたいと思います。
VOID（The Verica Open Incident Database）
アベイラビリティ（availability）の誤解について
アベイラビリティ（availability）について持たれやすい誤解として、必ずしも効果的とは言えない7つの対応手段について紹介されました。
括弧の中は私がつけた直訳です。ニュアンスが違っていましたらすみません。
誤解1. Remove the People Who Cause Accidents（事故を起こす人を排除する）
誤解2. Document Best Practices and Runbooks（ベストプラクティスとランブックの文書化）
誤解3. Defend against Prior Root Causes（根本的な原因に対する事前防衛）
誤解4. Measure Reliability Quantitatively（信頼性を定量的に評価する）
誤解5. Avoid Risk（リスクを回避する）
誤解6. Simplify（簡略化する）
誤解7. Add Redundancy（冗長性を持たせる）
特に以下の内容が印象に残りました。
誤解1.の説明では、事故を起こす人を排除しても逆に事故が増えるといった話が、前回自身が執筆したパラドックスの話にも似て印象的でした。高いスキルを持つ人はそれ相応の役割を持つがゆえにアクシデントにも遭遇しやすく、事故を対処するナレッジを持つのもその高いスキルを持つ人なので、そこを排除すると逆効果という話です。また、そもそも人は事故を起こす確率は誰でも同じだとも仰ってました。
誤解3.の説明内で語られた内容で、エンジニアは誰でもミスをするのでインシデントの混入を防ぐ事はできないとした上で、ディレクターが個人間のコミュニケーションをさせていなかった事が悪かったのかもしれない、アベイラビリティを軽視して十分な予算をかけなかった事が悪かったのかもしれない、といった様なインシデントの解析に様々な切り口での考え方をするべき…という様な話が印象的でした。
また、誤解6.で語られた内容で、複雑性はゼロにする事はできないと。より信頼性の高いシステムを作ろうとすると、必然的に複雑性も高まる事になるとの話がありました。このあたりの話題は、最後の質疑応答の時間でもやり取りされてました。
この様な事例から、後の企画セッションでも触れられていますが、カオスエンジニアリングというのは、一般的なソフトウェアテストの様に特定の観点や特定のスコープに対してのアプローチではなく、未知の部分に対して実験的なアプローチを行い様々な視点で対処手段を分析するものというイメージを持てました。
本基調講演では他にも上に挙げきれないくらいとても貴重な話を伺えましたが、カオスエンジニアリングについて少なからず事前理解が無いと、正直理解が大変な内容でもありました。（あと同時通訳の方々お疲れ様でした）
次に紹介する企画セッションも合わせて拝聴したところ、より理解が進んだのでとても良かったです。
企画セッション「カオスエンジニアリングの裏話」
講師：堀 明子氏（オーティファイ）、松浦 隼人氏（オーティファイ）
同日に同じカオスエンジニアリングをテーマとしたセッションがあり、こちらも拝聴しました。
講師の堀 明子氏、松浦 隼人氏はお二人とも、当社も日ごろお世話になっているオーティファイ株式会社の方々で（松浦氏は同社の取締役CTO）、基調講演で紹介したCasey Rosenthal氏の著書「Chaos Engineering」を翻訳された方々でもあります。
和訳版 カオスエンジニアリング ―回復力のあるシステムの実践／Casey Rosenthal (著), Nora Jones (著) 堀 明子 (翻訳), 松浦 隼人 (翻訳)
わたしたちの関わるシステムは複雑である
我々が普段関わっているWebシステムやスマートフォンのアプリケーションなどは、個別の構成要素の振る舞いはわかっていても、互いにどう干渉しあって全体としてどう振る舞うのかは把握が難しいといった事を話されました。
Unknown unknownsに対処する
我々が普段対応しているソフトウェアテストと、カオスエンジニアリングがそれぞれどういった位置付けなのか、「KnownとUnknown（知っている、知らない）」と「KnownsとUnknowns（理解している、理解していない）」を組み合わせた有名な表を用いて説明されました。
ソフトウェアテストはKnown knowns（知っているし理解している）、探索的な部分はUnknown knowns（知らないが理解している）と位置付けし、期待値を理解した上で実施されている。それに対してカオスエンジニアリングやオブザーバビリティは、Unknown unknowns（知らないし理解していない）ものに対するアプローチであると話されました。
説明頂いた内容から、カオスエンジニアリングはソフトウェアテストに代わりうるものでは無く、Unknown unknownsをカバーするアプローチ方法である事がわかりました。
余談ですが、known knownsの論法は2002年当時のアメリカ国務長官ドナルド・ラムズフェルド氏の記者会見での発言が非常に有名です（興味ある方は調べてみてください）
その上で下記キーワードをに沿って、カオスエンジニアリングの性質を説明されました。
・ テスト vs 実験（Testing vs Experiments）
・ 妥当性確認 vs 検証（Validation vs Verification）
・ 定常状態（Steady state）
・ 影響範囲（Blast radius）
それぞれ話されていた内容の要約を載せます。
テストと実験、妥当性確認と検証について
・テスト vs 実験（Testing vs Experiments）
テスト（Testing）は、システムの既に知られた特性に対して期待値通りである事を検証する。実験（Experiments）は、仮説を立てて実験（反証）を試みる。システムの未知の特性を見つけるのに効果的。
テストと実験を対比して説明されていました。カオスエンジニアリングは後者の実験的なアプローチに該当します。
・妥当性確認 vs 検証（Validation vs Verification）
妥当性確認（Validation）は、個々の要素が期待通りに実装されているかという検証に重きを置く。検証（Verification）は、ビジネスケースと総合的な出力に重きを置く。
妥当性確認と検証を水道水のケースに例えられて説明され、カオスエンジニアリングのアプローチは、検証寄りであると話されていました。
どちらの比較も我々が対応しているソフトウェアテストとカオスエンジニアリングの対比に当てはまり、非常にカオスエンジニアリングをイメージしやすくなるご説明だったと思います。
カオスエンジニアリングの発展原則
後半の定常状態（Steady state）と影響範囲（Blast radius）については、カオスエンジニアリングの発展原則に沿って説明されていました。
カオスエンジニアリングの発展原則は以下の様な内容です。
1. 定常状態に関する仮説を立てる
2. 実世界の事象を多様化させる
3. 本番環境で実験する
4. 継続的に実行できるよう実験を自動化する
5. 影響範囲を局所化する
お話頂いた内容の要約を書き出します。
1. 定常状態に関する仮説を立てる
コードが動く動かないという事では無く、ある一定の状態になっているかという事を仮説に立てる。中のコンポーネントを妥当性確認するのではなく、あくまで出力、状態を確認するという様なお話でした。
2. 実世界の事象を多様化させる
エンジニアは経験から簡単に変えられる変数やイベントを対象に選びがち。ただ変えるのではなく多様化（Vary）させる事が重要で、よりユーザに近いハイレベルな変数を変化させるべきと考えるという様なお話でした。
3. 本番環境で実験する
4. 継続的に実行できるよう実験を自動化する
こちらの原則に関しては、わかりやすい内容という事で説明は割愛、詳細は書籍を読んでいただきたいとの事でした。
5. 影響範囲を局所化する
実験が影響する範囲をシステムの中ではなく、ユーザー体験から見て実験がどう影響するかを見るべきという様なお話や、シャドートラフィックを作るなどの影響範囲を局所化する手段をいくつかご説明いただきました。
翻訳者ならではの話として、Varyという言葉から変化ではなく多様化の意図を汲み取ったといったお話や、Blast Radiusは直訳すると「爆発半径」となるけれど、分かりやすさを優先して「影響範囲」と翻訳されたといった話を交えて説明いただき、大変興味深かったです。
講師の松浦さんからも、和訳の技術書を読んで内容が内容が飲み込めない時に、英語原本
のワードを直訳して著者の意図を感じ取るのも面白いといった事を話されていました。
最後に
カオスエンジニアリングを知った際の印象は、学校の避難訓練だったり、自衛隊の訓練の様なものを思い浮かべました。ちなみにカオスエンジニアリングの考え方が生まれたきっかけ…触発されたものの一つとして、消防士の訓練があるそうです。
また宇宙飛行士の訓練では、訓練インストラクターが宇宙飛行士に事前に伝えないままわざと機器の故障を起こすというものがあります。故障が発生した際に手順書を見ながら原因を突き止め、必要な処置が行えるか…こんな本番さながらの訓練を繰り返し宇宙での不測の事態に備えており、まさにカオスエンジニアリングはこれを目指してるのだろうなと思いました。
私たちが対応しているソフトウェアテストとはまた別のアプローチになりますが、大変興味深い内容でした。昨日、紹介されている書籍を部内で見かけたので、時間があれば借りて読んでみたいと思います。
講師の方々ありがとうございましたー。
