間もなく開催されるChaos Conf 2020を前に、InfoQでは、カオスエンジニアリングコミュニティが関心を持つ話題を探るべく、Adrian Cockcroft、Yury Niño Roa両氏に話を聞くことにした。おもな話題は以下のとおりだ — カオスエンジニアリングの企業内における採用はいまだ不均一な状況にある。心理的安全性を獲得する上で、"game days"の実施には明確なメリットがある。カオスエンジニアリングの将来は、セキュリティを重視した試験の導入と、より大規模な障害モードを想定した試験のスケールアップに向かっている。
AWSでクラウドアーキテクチャ戦略を担当するVPのCockcroft氏と、ADL Digital Labのシニア・サイトリライアビリティエンジニアであるNiño Roa氏は、ともにChaos Conf 2020で講演を行う。Chaos Conf 2020は、10月6~8日に開催される無料の仮想イベントで、Gremlinチームの主催によって、カオスエンジニアリングコミュニティを対象として行われる。InfoQでは、信頼性や"DevOpsループの完結"など、イベントの重要なテーマをいくつか取り上げる予定である。
game daysの使用は目新しいプラクティスではないが、インタビューに応じた両氏はいずれも、インシデント管理の実施と安全の保証された障害環境での改善という、game dayのメリットを強調した。Googleが以前に論じていたように、"心理的安全性(psychological saferty)"の概念は、ハイパフォーマンスチームを作り上げる上で重要不可欠なものだ。運用時障害への対処において、強いプレッシャの下で行動する場合、この概念はさらに重要なものになる。
プラットフォームとアプリケーションの両方に可観測性を実装しておくことが、運用チームと開発チームへのフィードバックを獲得するためには不可欠だ。DevOpsプラクティスの目的は、開発者と運用技術者を隔てるサイロの排除を支援することにある。しかしながらChaos Confチームは、"開発者から運用への一方的な流れが作られて、開発者が運用性と信頼性の高いアプリケーションを開発するための、運用側からのフィードバックがない場合が非常に多い"、と指摘している。
自動化を推進し、カオスエンジニアリングを通じて開発者と運用技術者を結び付けることにより、フィードバックを目的として収集されたメトリクスの忠実性と有用性を高めることが可能になるのだ。
以下は、InfoQがNiño Roa氏、Cockcroft氏と交わした議論の内容を編集したものである。
InfoQ: カオスエンジニアリングの採用は、企業組織内ではどの程度の成功を収めているのでしょうか?
Niño Roa: 企業によってかなり差があると思います。銀行の場合、各社は相互の、あるいはFinTechからの競争圧力を強く感じています。Casey Rosenthal氏によると、金融機関の姿勢は、"現金を扱っているので、カオスエンジニアリングは実施できない"というものから、"プラクティスとしてカオスエンジニアリングを早急に取り上げる"というものに転換しています。CapitalOneのような大手銀行での成功例が多数あります。カオスエンジニアリングを極めて有用かつ堅実なプラクティスであると認めているのです。
Rosenthal氏とNora Jones氏の著書 "Chaos Engineering: System Resiliency in Practice" で述べられているように、カオスエンジニアリングを使った事前の試験実施が、大企業やスタートアップにとって有用であることは実証されています。同書には、カオスエンジニアリングを採用したSlack、Google、Microsoft、LinkedIn、CaptalOneによる視点、実例、ストーリが紹介されています。
Cockcroft: カオスエンジニアリングは特に、クラウドへの移行傾向が顕著な大企業や、金融サービスのような高度にクリティカルな企業で成功を収めています。
継続的デリバリやDevOps、クラウドコンピューティングなどと同じく、近代化プログラムの一部として、カオスエンジニアリングは位置付けられているのです。ただし、大部分の企業はまだ着手したばかりで、運用改善プログラムの基本的な部分として使用しているのは"大規模なディジタルネイティブ"企業に限られているのが現状です。
InfoQ: "バリューフローを理解し、効果的な可観測性を実装して、フィードバックに応答する"ということが、カオスエンジニアリングの前提としてよく挙げられているのですが、一般的な企業はこの点において、十分に成熟していると言えるのでしょうか?
Cockcroft: 今挙げられたようなことがカオスエンジニアリングの前提だとは思いません。ツーリングや可観測性の状況に関わらず、どのような企業でも、スタッフが定期的なgame dayトレーニングを行うことにはメリットがあります。
私はいつも、最初は社員から、次に机上演習の実施、"what-if"テストのシミュレーション、という順序で進めています。これによって、ツーリングとプロセスのギャップが実際に何であるかが明らかになります。スケジュールを立てて、game dayの実行毎のゴールを定めることで、より現実的になり、企業の能力も向上します。
始める前にたくさんの前提条件があるのではなく、継続的な改善プロセスを作り上げることです。
Niño Roa: 状況や国によりますが、一般的な企業はこの面では十分に成熟していると思います。
私の国などの大企業では、可観測性の概念が取り入れ始められたばかりです。例えば政府関係のエンティティなどでは、可観測性に投資可能なリソースは非常に限られています。オンコールに従事していて、ログとトレースと監視の区別を知らないユーザに会ったこともあります。そういった一部の人たちにとっては、可観測性パイプラインの構築は夢物語なのです。
可観測性については、とにかく始めることをお勧めします — どんな事でも、最初の一歩を踏み出すのが一番大変なのです。もう少し実際的な作業は、最初にアーキテクチャデザインを確認して、監視対象として意味のある部分の概要を把握することから始まります。それが終われば、次は"Service Level Indicators (SLIs)"や"Service Level Objectives (SLOs)"など、ターゲットとするメトリクスのベースラインをサービス毎に設定して、システムの動作内容を把握する必要があります。収集した情報を使用すれば、カオスエンジニアリングのマニフェストの最初の原則である、仮説の立案に着手できます。
InfoQ: 企業組織において、心理的安全性はどの程度重要なのでしょうか?
Niño Roa:心理的安全性は組織において重要なものです。企業規模やビジネスドメインに関わらず、その成功は、チームメンバが現在の役割の中において、どの程度受け入れられ、尊重されていると感じられるかに直接関係しています。
カオス試験やgame daysは、企業組織内に心理的安全性をプロモートするための完璧な方法だと思います。安全な形式で試験ができると分かっていれば、失敗した場合の恥ずかしさや不安感を持たずにすみます。感情的な基盤ができたことによって、何が起きて誰がトラブルに巻き込まれているのかを悩むことなく、自分が学習することに集中できるのです。
Cockcroft: 企業でもスポーツチームでも、成功するチームには同じ特徴があります。報告者が避難されたり叩かれたりせずに問題を安全に表面化する、ということができない組織が、問題を体系的に修正したり防止したりする方法を学ぶことはありません。例えばMercedes Formula Oneチームの現在の優位性と、彼らが失敗を語り、問題に対処する様子を見れば、それが必然的な結果であることが分かるでしょう。その他のチームにはもっと多くの内部抗争があり、それが過去数年間にわたってMercedesの後塵を拝してきた理由なのです。
InfoQ: この1年間にカオスエンジニアリングコミュニティから現れた話題やアイデアの中で、最もエキサイティングなものは何でしたか?次の1年には、どのようなことを期待すべきでしょうか?
Cockcroft: 今最も興味深いのは、個々のマイクロサービスやリクエストフローから、より大規模な障害モデルシナリオに重点が移りつつあることです。
Niño Roa: 昨年の"Security Chaos Engineering"と"Security Chaos Engineering"は、悪意を持った条件に耐え得る信頼性をシステム機能内部に構築する上で、継続的に統合する必要のあるセキュリティ能力を実装する機会を提供してくれました。このプラクティスのスポンサでアドボケートのAaron Rinehart氏が、"Chaos Engineering: System Resiliency in Practice"に素晴らしい一章を書いてくれています。氏はさらに、セキュリティに関するカオスやレジリエンスに関する多くのリソースや議論、経験をまとめて、これを一冊の書籍にする用意をしているところです。
間もなく開催されるChaos Conf 2020仮想イベントの詳細は、無償の参加登録とともに、カンファレンスのWebサイトに紹介されている。