【AWS re:Invent 2017】「カオスエンジニアリング」について

はじめに

re:Invent 2017　day4 keynote にて紹介された「カオスエンジニアリング」をご紹介します。

カオスエンジニアリングとは？

提案の背景

Netflix社がマイクロサービスを推し進めた結果、
それらの分散サービス同士の振る舞いによって起きる不具合を制御するために考案された
方法論の原則のようです。

Principles of Chaos Engineering

オライリーの書籍にもなっているようです。

Chaos Engineering – O’Reilly Media

もう少し具体的に

以下のプラクティスが提案されています。

• 定常状態の振る舞いの仮説を立てます
• 実世界の事象を変数化します
• 実験を本番環境で実行します
• 継続的に実行するため実験を自動化します
• 影響範囲を最小化します

※KeyNoteの日本語訳では”experiment”を「実験」ではなく「経験」と翻訳されていました。

まとめ

いかがでしょうか、
テスト駆動開発のような考え方をマイクロサービスに対して導入しているような形ですね。
KeyNoteの中ではやはり、

単体テスト→統合テスト→カオスエンジニアリング

という流れで紹介されていました。

また、SeleniumやJmeterのように、インフラの外側からのテストとなるので、
テストサービスの構築が必要となります。

そして、中でも本番環境で実験するというところが最もショッキングな点ではないでしょうか。
このパラダイムシフトを受け入れられるかどうかは、
今後のインフラ・SI企業の動向を左右しそうです。