カオスエンジニアリングによるAPIの回復力の向上

Gremlinチームは、組織のAPIが回復力があることを検証する方法として、シンプルなカオス実験を説明した。「game days」（ITシステムや人々のための消防訓練）を実行するように、カオス工学と技術の原則を使うことで、この新興領域で商用およびオープンソースのツールを適切に使えるようになるという価値を提供することができる。

Gremlin IncのPrincipal Site Reliability EngineerであるTammy Butow氏は、ブログ記事を次に示す議論で開始した。それは、多くの組織がWebベースのAPIを通じてサービスを公開（そして、コアビジネス価値を提供）しているが、同氏の経験では、そのAPIや関連するインフラが「二流市民」とよく思われていることである。組織が規模を拡大するにつれて、APIレイヤーに障害が発生するとユーザエクスペリエンスが低下したり、深刻度の高いインシデントが発生するリスクがある。関連するパターンでは、APIの使用が増加すると、関連するバックエンドシステムの負荷も増加する可能性があり、要求数の増加に伴って発生する負荷は、パフォーマンスや信頼性と線形な関係にならない可能性がある。したがって、エンジニアはそれを定式化して、負荷の増大、システムの劣化、インフラストラクチャの障害、リスクを軽減するために最終的な設計システムの影響を理解するために実験を行う必要がある。

Butow氏は、影響についての理解を開発し、実験の設計する最良の方法の1つは、Chaos EngineeringとGame Daysの原則を使うことであると提案している。そのフレーズに慣れていない読者に対して、QCon San FranciscoでAdrian Cockcroft氏は、game daysを「ITの消防訓練」と表現した。予期しないアプリケーションの動作やインフラの障害では、しばしばエンジニアが介入して状況を悪化させる。人々は反応する方法を訓練され、IT game daysの世界では同じ機能を果たしているため、日常生活の中で消防訓練は本当の火事の場合に人の命を救う。

Gremlinのブログ記事には、一般的なAPIゲートウェイに対して高負荷をシミュレートするためのサンプルスクリプトが用意されている。そして、Gremlinの商用"resilience as a service"SaaSプラットフォームを使って、APIゲートウェイを実行している計算インスタンスに障害（CPUやメモリの負荷の高いか、そうでなければ、全ての処理を完了する）をインジェクトする。Butow氏は、ブログ記事（そして以前に開催されたQCon London talkの講演で）で、カオス実験を開始する前に監視と観測可能性の要件が最重要だと強調している。

「一貫性を持ってカオス実験を実行することは、APIの回復力を測定するためにできることの1つです。高い可視性（監視）を確保し、フォールバックのカバレッジを増やすことは、自身のシステムを強化するのに役立ちます。」

カオス工学の規律は、主流の採用に向かっている。それは、Gremlinのような商用カオスツールやサービスビジネスによって引き起こされているわけではない。Netflix（創造者やオリジナルのchaos monkey）のようなその領域における先駆者、Chaos Toolkitのようなコミュニティ主導の取り組み、ExpediaやBloomberg（Kubernetes向けの「PowerfulSeal」カオスツールをオープンソースとしてリリースした企業）などのエンタープライズ組織による影響も受けている。

カオスエンジニアリングの人気の高まりは、組織が関連ツールを構築するか、購入するかを検討することにつながる。Gremlinチームは、エンジニアに次に示すトレードオフを検討することを薦めている。それは、独自のカオス実験プラットフォームを構築するためのTotal Cost of Ownership (TCO)、内部のシステムを外部のSaaSプラットフォームに公開できるか（そして、望ましいか）、現在のチームのスキルセット、プラットフォームのロードマップの観点でチームがどれくらいのコントロールする必要とするかである。Adaptive Capacity Labsの共同設立者であるJohn Alspaw氏のような、この領域における何人かのリーダーは、回復力のエンジニアリングの人に関る側面についても忘れてはならず、関連するツールよりも重要であると警告している。

Gremlinに関するその他の情報は、組織のウェブサイトでご覧になれます。初開催のChaos Confは、2018年9月28日にサンフランシスコで開かれる。