AWSでクラウドアーキテクチャストラテジを担当するVPのAdrian Cockcroft氏は先頃、障害発生時においても正常に運用できるレジリエントなシステムの構築方法について、自身の考えを公開した。ツールとして氏が取り上げたのは、迅速な検出と対応に務めること、STPA(System Theoretic Process Analysis、系統駆動型の障害検出(lineage driven fault detection)、SPOF(Single Point of Failure)の思想、リスク優先度設定、という５つのテクニックだ。氏は先日のQCon San Franciscoでも、継続的レジリエンスの考え方を備えたシステム構築において望まれる、クラウドのレジリエンスパターンについて私見を述べている。
システムにはさまざまな障害モードが考えられるが、それぞれが異なるレジリエンスの側面をテストするものだ、とCockcroft氏は指摘する。しかしながら、氏が特に重要だとするのは、静かに発生するシステム障害と、頻度の低いコンポーネント障害である。氏は言う。
システムは、多層防御によって障害を吸収できる安全マージンを維持すると同時に、最も可能性が高く最も影響の大きいリスクに対処するための障害モードを優先する必要があります。
さらに氏は、"学習する組織、ディザスタリカバリテスト、ゲームディ、カオスエンジニアリングツールといったものはすべて、継続的にレジリエントなシステムにおける重要なコンポーネントである"、と述べている。Netflixでサイト信頼性を担当するシニアエンジニアの Ryan Kitchens氏は、Netflixのチームがインシデントの防止と対応に備える上で、これらの手法を活用していると説明した。
Cockcroft氏が推奨する最初のテクニックは、迅速な検出と対応を可能にすることだ。発生した障害を短期間で解決する上で、迅速な検出は不可欠である。エンジニアは、可観測性システムにある遅延について理解し、重要なメトリクスについては１秒単位で収集する必要がある、と氏は指摘する。その上で氏は、MTTR(Mean Time to Repair)の重要性とともに、防止したインシデントの追跡方法を確立することの重要性も強調している。Kitchens氏が言うように、"うまくいかなかったことの理由の一面には、どうすればうまくいくのかを理解することがある、ということを我々は理解しなければならない"のだ。
ふたつめのテクニックは、安全なオペレーションの維持を可能にする上で必要なシステム制約に関するものだ。Cockcroft氏は、Nancy G. Leveson氏が著書"Engineering a Safer World"で説明した、STPA(System Theoretic Proess Analysis)アプローチの採用を推奨している。STPAは、システムの基本的なコントロールダイアグラムを基本に、システムの各コンポーネントに対して、設計レベルから備えるべき安全上の制約と要件を特定するものだ。一般的にコントロールパターンは３つの層に分割される — ビジネスファンクション、ビジネスファンクションを管理するコントロールシステム、コントロールシステムを監視するヒューマンオペレーションである。このアプローチでは、コンポーネント間のコネクションと、障害によって与えられる影響が強調されている。
Cockcroft氏が推奨する第３のテクニックは系統駆動型障害検出だ。このアプローチは、システムで最も重要なビジネス駆動機能を起点とし、その機能が意図通り動作した場合に関わるバリューチェーンが続く。これは"事実上、障害モデル分析に対するトップダウン・アプローチであり、ボトムアップアプローチを採用した場合に問題となって身動きを取れなくするような、考えられるあらゆるトラップを回避するもの"だ。
第4のテクニックは、システムに単一障害点(single point of failure)が存在しないようにすることだ。高度にレジリエンスなシステムは３つの成功方法を持った、コーラムベースの(quorum-based)アルゴリズムを備えるべきだ、とCockcroft氏は推奨する。"３つの成功方法が存在すれば、障害が発生した場合でも２つの方法が残っています。データが破損したならば、３つのうちのどれが不適切であるかを特定することが可能になるのです"、と氏は延べている。
最後に氏が掲げるテクニックは、リスクに優先順位を付けることだ。その方法として氏は、ISO標準のエンジニアリングテクニックであるFMEA(Failure Mode and Effects Analysisの活用を推奨する。このテクニックでは、考えられる障害モードをリストアップした上で、それらの障害の発生可能性、重要度、可監視性について、1を最良とする１から10のスケールで評価する。これらの推定値を掛け合わることで、それぞれの障害モードを、1から1000のRPN(Risk Priority Number)に基づいてランク付けることが可能になる。例えば、非常に頻度が高く、永続的な影響があり、0ないし低い可監視性を持ったインシデントは、1000のRPNを持つことになる。
Cockcroft氏の見解としては、STPAがコントロールハザードのトップダウンの視点を提供するのに対して、FMEAは障害モードの優先順位によるボトムアップの視点を促すものだ。STPAは全般的にFMEAよりも、特にヒューマンコントロールやユーザエクスペリエンスに関しては障害のカバレッジに優位性がある、というのが氏の意見である。
QCon San Franciscoでの先日の講演でも、Cockcroft氏は、クラウドベースのアプリケーションを構築する上で、レジリエンス的にグッドプラクティスと氏が考えるものについて公開している。先程紹介した３つのルールもこの中に含まれる。さらに氏は、リージョン間でディザスタリカバリを行う場合、キャパシティの小さなリージョンからより大きなリージョンへのフェールオーバを目標とするべきだ、という意見を述べている。こうすることで、フェールオーバが容量不足によってさらなる影響を与えるような状況を回避することが可能になる。同じ理由から、障害発生したリージョンから、より近く、よりレイテンシの低いリージョンにフェールオーバすることで、フェールオーバの成功率を高めることができる。
次に氏は、"カオスファースト"の考え方を取り入れることの重要性を強調した上で、自身がNetflixに在籍した頃、リージョンに最初に導入するアプリがchaos monkeyであったと語った。これにより、アプリケーションとそれを管理するチームは、最初から障害対処の用意をせざるを得なくなる。最後に氏は、継続的レジリエンスに関する自身のコンセプトとして、運用ワークロードに対する概念導入への抵抗感を低減するため、カオスエンジニアリングの基本的なブランドを変えたいという考えを明らかにした。継続的デリバリにはテスト駆動開発とカナリアリリースが必要なように、継続的レジリエンスにはテストと運用の自動化が不可欠だ、と断じた上で氏は、十分なテストを行ったコードパスとプロセスと、その中で障害軽減化を実現することの重要性を強調している。
完璧なシステムを構築することは不可能だが、これらのテクニックを使うことで"最大のリスクに注目し、運用中のシステムに対する影響を最小化する"ことが可能になる、とCockcroft氏は言う。honeycombのCTOであるCharity Major氏は、次のように述べている。
開発するシステムにおいて運用上発生する問題や障害モデルを理解し、可能なものは自動修正し、不可能なものは影響を抑制し、中核的な機能を提供する運用ワークロードを人的に可能な限りシフトするということは、常にエンジニアの責任になるのです。