レジリエンスなシステムはなぜ必要なのか - QCon LondonでTammy Butow氏がカオスエンジニアリングを論じる

Tammy Butow氏はQCon Londonで講演し、よりレジリエントなシステムが求められている理由と、それがカオスエンジニアリングのプラクティスによっていかに実現されるかを説明した。講演ではカオスエンジニアリングのための３つの主要な前提条件 -- 重要度の高い“SEV”インシデントの管理、監視、及び影響度の測定 -- が提示され、カオステストプラクティスを作り上げるためのガイドラインとツール、そしてプラクティスが紹介された。

GremlinのプリンシパルSREであるButow氏の講演は、レジリエントなシステムを定義することから始まった。

レジリエントなシステムとは、可用性と耐久性の高いシステムです。レジリエントなシステムは、障害発生時にも許容可能なレベルのサービスを維持することが可能です。

レジリエントなシステムは、(設定ミス、大規模な自然災害、コントロールされたカオスエンジニアリングなどの)難局を切り抜けることができるのです。

続いて、さまざまな業界に固有のIT障害に関するケーススタディが紹介され、レジリエンスの必要性が論証された。フィンテック業界では転職や転居、移動が頻繁だが、2014年、英国の“即時グロス決済(Real Time Gross Settlement)”システムに障害が発生し、予定されていた住宅購入取引が失敗するという事件があった。旅行業界でも障害が発生しており、2017年、British Airwaysで発生したITサービス障害では、8,000万ポンドの損害が発生したと見られている。Butow氏はその他にも、ITシステムのレジリエンス欠如による問題を示すケーススタディをいくつか紹介し、システムは障害を適切に処理するだけでなく、いかなる時と場所においても価値を提供しなければならない、と主張した。

紹介されたケーススタディにおけるユーザの最大の関心事は、システムの復元力、すなわち高可用性である。レジリエンスの高いシステム構築を促進する手段のひとつがカオスエンジニアリングの実践である。カオスエンジニアリングとは、システムの弱点を明らかにするように設計され、周到に計画された実験を行なうプラクティスである。その中核となる前提はホルメシスと同じく、“有害なものを注射して免疫を作る”というものだ。

Butow氏はカオスエンジニアリングをワクチンに例えて紹介した上で、カオスエンジニアとは、言うならばワクチンを研究するコンピュータ科学者だ、と説明した。SRE(Site Reliability Engineer)とプロダクションエンジニアは一般的に、データベースのフェールオーバテスト、あるいはアプリケーションの再起動とリカバリプロセスのような明確な定義はなくても、このラベルを使ってカオスエンジニアリングを実践する。

カオスエンジニアリングのプラクティスを効果的に実践する上で、主な前提条件が3つある。

1. 高重大度インシデントの管理
2. 監視
3. ダウンタイムの影響度測定

高重大度インシデント、あるいは“SEV”は慎重に扱う必要がある。Butow氏は高重大度インシデント管理プログラムの確立方法について、詳細に説明した -- これは、システムに重大な影響を及ぼす問題を記録、トリガ、トラッキングし、ビジネス価値の割り当てを行うプラクティスである。SEVには３つのレベルがあり、それぞれのインパクト、解決目標、コミュニケーション要件が定められている。

SEVライフサイクルの大まかな説明に続き、サービスレベル契約と目的 -- それぞれSLA、SLOと呼ばれている -- に基づいたSEVレベルの決定方法が論議された。このライフサイクルは、検出(detection)、診断(diagnosis)、軽減(mitigation)、予防(prevention)、終結(closure)、検出(detection)というステップで構成されている。チームはまず、自分たちの重要なシステム(トラフィック管理、データベース、ストレージなどが一般的)の障害管理に対応するSEVライフサイクルを特定しなければならない。これを実施する上で最も効果的な方法は、Adrian Cockcrfot氏が“ITの避難訓練”と評している、インシデントシミュレーション“game days”を行うことだ。

カオスエンジニアリングの第2の前提条件である監視では、効果的なメトリクスとログの集約に加えて、それらに対応する重要なサービスのダッシュボードの実装が必要となる。GoogleのSRE書籍から引用した監視の“4つのゴールデンシグナル”は、レイテンシ、トラフィック、エラー、飽和(saturation)である(これらはBrendan Gregg氏のUSEメソッドと、Tom Wilkie氏のREDアプローチを踏襲している)。監視せずにカオステストを実施しようとすれば、システム内で何が起こっているのか、障害による真の影響は何なのか、まったく分からなくなってしまう、とButow氏は警告する。

第3の前提条件として挙げられているのは、ダウンタイムの影響を計測することだ。基本的にエンジニアは、SEVが顧客やビジネスに与える影響を理解しておかなくてはならない。ここでの影響には、可用性や耐久性といったシステム特性の他、成果やコスト、時間(の損害)など、ビジネス上の影響も含まれる。

続いてTwillioによるカオスエンジニアリングのユースケースが紹介された。これはTwillioのエンジニアリングが開発とテストを行なった、同社の内部的な分散キューイングシステムである“Ratequeue”で発生した障害に関連する仮説が基になっている。業界が採用する分散システムの複雑性と予測不可能性が増大していることから、Twillioチームでは、可能な限りカオスエンジニアリングを実施して、カップリングのテストとシステムのレジリエンス向上を図ることを強く推奨している。

Ratequeue High AvailabilityとRatequeue Chaosを実装した後、数ヶ月前に運用移行した当社初の自動フェールオーバが、1分ほどで完了しました。

カオスエンジニアリングを始める前に、その目的とプラクティスを組織内で広く共有することが必要だ、とButow氏は警告する。

• カオスエンジニアリングのキックオフを全員参加で実施する
• 最新情報と進捗状況をEメールで送る
• メトリクスレビューを毎月実施する
• プレゼンテーションを行う

“Gremlin Chaos Engineering SaaS”プラットフォームの簡単なデモや、Netflix Simian Armyやchaos-toolkit、PowerfulSealといったオープンソースツールに関する説明も行なわれた。この分野における何人かの思想リーダ -- Adaptive Capacity Labsの創設者のひとりであるJohn Alspaw氏など -- が、レジリエンスエンジニアリングの人間側を忘れてはならない、と警告している点も特筆に値する。影響という面では、むしろ関連するツーリングよりも大きい存在だ、というのが氏の主張だ。

カオスエンジニアリングを実践し、改善の実現と計測を行って、“実行前と実行後のストーリをメトリクスで語ってほしい”という呼びかけで、講演は締め括られた。

1. 構築 — 新システムの構築/既存システムの改善
2. 取得 — オープンソースの利用/オープンソースへのコントリビューション
3. 購入 — サードパーティシステムの利用
4. ブラッシュアップ — ゲームデー/チームトレーニング
5. 破壊 — カオスエンジニアリング/障害インジェクション
6. 退去 — システム廃止/コード削除

Tammy Butow氏のQCon Londonでの講演“Why the World Needs More Resilient Systems”で使用されたスライド’(4MB PDF)はQCon Webサイトにある。また、ビデオ記録が今年後半にInfoQでリリースされる予定だ。興味を持った読者は、カオスエンジニアリングに関する詳細をGremlin Communityで読んだり、Gremlin Slackに参加してみたりするとよいだろう。