自分の冒険を選択せよ - カオス工学、QCon New York 2017にて

NetflixのシニアカオスエンジニアであるNora Jones氏が、QCon New York 2017でカオス工学(chaos engineering)について講演した。その中で氏は、カオス工学の導入に関するさまざまなステージを示すとともに、JetとNetflixでの自身の経験について話した。

Jones氏の講演は、カオス工学の背景にある 論理的根拠の説明から始まった。カオス工学は、失敗は避けられない、遅かれ早かれ必ず起こるものだ、という事実を認めるものだ。Jones氏はそれを、コンピュータは複雑である、従って故障する、という例で説明する。

可用性を確保する方法は、ユニットテストや回帰テスト、統合テストというように、さまざまなテスト手法を通じて確立されている。カオス工学はこれに新たなレベルを加える。２つのグループのいずれかのみが必要だという考え方もあるが、氏は、最高の可用性を達成するにはどちらも必要だと考えている。

カオス工学では、実験を通じてシステムを強化する。その哲学を取り入れた初期のツールとして広く知られているのが、サービスをシャットダウンすることでそのレジリエンスをテストするように設計された自動ツールであるChaos Monkeyだ。Chaos Monkeyは数年前のものだが、カオス工学が登場したのは最近である。

組織にカオスを導入する過程として、Jones氏は５つのフェーズを提示する。各フェーズはその前のフェーズよりも洗練されており、より具体的なシナリオをカバーし、新たなツールを導入する。

最初のフェーズはカオスの初期導入だ。すでにカオス(渾沌)が存在する組織にカオスを導入するのは難しい、とJones氏は指摘する。実験的に生み出したカオスと、実際の問題や機能停止を原因とするカオスの区別が付かなくなるからだ。従って、定常状態が出発点として必要となる。

次の問題は、どうやってカオスを始めるのか、ということだ。Jones氏が勧めるのは、すでに起きた状態の再現から始める方法だ。穏やかな低下と再始動は、小さく始めるには適切な出発点になる。例えば、余分なWebサーバあるいはデータベースサーバを起動すれば、想定されるような障害がほとんどのシステムで発生する。小規模から始める方法としては、QA環境で実行するという方法も推奨できる。

Jones氏はさらに、さまざまなフェーズを通じて導入する方法を重視する。運用中のシステムを故意にシャットダウンするような方法は過激であり、導入作業は繊細に扱われなくてはならない。

第２のフェーズは、カスケード故障(Cascading failure)の発生に関するものだ。カスケード故障とは故障の連鎖で、ひとつのシステムの故障が他のシステムの故障を引き起こすことで始まり、それが続くものだ。カスケード故障は、非常にまれな状況によってそれが引き起こされるまで、長期に渡って潜んでいる場合が少なくない。

Jones氏は、自身がJetで行なった実験について説明する。氏のチームは、発生させたい障害の種別を決定して、QA内で実行した。その結果、想定とは異なる障害が発生し、QAが１週間にわたって停止する事態となったのだ。この実験は潜在的な運用障害を明らかにしたという点で成功すると同時に、このようなアプローチのメリットを明らかにするという重要性を再確認させるものでもあった。障害は常に何らかの不都合を引き起こすものだが、このような障害が運用時にコントロール不能な状況で発生した場合、その損害は極めて大きなものになるということを、開発者とステークホルダは認識する必要がある。

次のフェーズは障害注入ライブラリ(failure injection library)の構築である。このライブラリは、コードを通じてカオスを直接注入することにより、カオス実験をより詳細にコントロールできる。Jones氏は、サンプルのF#ライブラリをGitHubで公開している。次のスニペットは、カオスを注入するエントリポイントとなる関数を定義するものだ。

let chaos (name:string) (shouldChaos:unit -> bool) (chaos:Async<unit>) : AsyncFilter<_,_,_,_> =
    fun (service:AsyncArrow<_,_>) req -> async {
       if shouldChaos() then 
            printfn "%s" name
            do! chaos
        return! service req 
}

第4のフェーズは、Chaos Automation Platform (ChAP)による連続的なカオスだ。ChAPはFITの欠点を克服すべく設計されたもので、FITと同じくNetflixが開発した。ChAPの目標は、あらゆるものに対してカオス実験を継続的に実行することだ。ChAPは爆発半径の最小化を重視している。特定のインスタンスに障害を集中させる。FITにオーケストレーションを追加する。

最後となる5番目のフェーズは、システム内の対象領域へのカオスの注入だ。Jetでの経験では地理的レプリケーションを対象とした。このシステムはKafkaに強く依存しており、いくつかの問題を抱えていた。チームはカオステストの対象とするKafkaに特化した、一連のシナリオを作成した。そこで得た教訓は、前述したように、カオス実験で引き起こした障害と通常の障害との区別が困難であるということだ。カオス実験を行なう前には、定常状態が必要である。

最後の言葉としてJones氏は、カオス工学の採用戦略の定義を提案している。 この戦略を最も効果的にするには、企業の文化に合わせた調整が必要となる。例えば、強制的な適用が効果的か、あるいはチームやメンバを納得させる必要があるか、というような点だ。