TOP ＞ アプリ／OS ＞ Chaos Monkeyとカオスエンジニアリング（下）
関連カテゴリー： マネジメント
Chaos Monkeyとカオスエンジニアリング（下）
2020/06/05
かつてはDVDの宅配レンタル企業だった米Netflixが、分散クラウドシステムを使った動画配信企業へと変貌を遂げる中で打ち出したのが、稼働中のシステムにわざと障害を起こすという手法と、それを実現するツール「Chaos Monkey」だ。自分たちが動かしているシステムに障害を注入して弾力性を高めるというその発想は、大小さまざまなソフトウエア開発企業で受け入れられた。
（前回から続く）
現在のバージョンのChaos Monkeyを利用するには、同じくNetflix製のオープンソースの継続的デリバリープラットフォーム「Spinnaker」と、MySQL互換のデータベースのバージョン5.6以降を使う必要がある。企業によっては、Chaos Monkeyを採用するうえでの制約となるかもしれない。
Chaos Monkeyの動作の設定はSpinnakerを通じて行い、サービスの構成や、仮想マシンやコンテナのインスタンスに障害を発生させる頻度などを指定する。
Chaos Monkeyの導入は、問題解決に向けた第一歩にすぎない。システムの弾力性の問題を解決する作業は複雑である。Chaos Monkeyで明らかになるのは、システムの弱点だけだ。その原因を探り、解決策を考え出せるかどうかは、DevOpsやシステムエンジニアリングのチーム次第である。
「ツール自体は費用がかからないが、ツールに反応するために必要な作業には費用がかかる」とOrzell氏は言う。また、カオスエンジニアリングに本腰を入れるとしたら、新機能の開発から弾力性の強化へとリソースを振り向ける必要がある。「どちらにどの程度割り振るかというバランスは企業によってさまざまで、力の入れ具合は各社で判断する必要がある」
Netflixがカオスエンジニアリングを提唱し始めたばかりの頃は、特に金融機関から否定的な反応が多く上がったと、Chaos Engineeringには書かれている。
だが、カオスエンジニアリングがいかにリスクが高いといえども、金融機関も障害に見舞われることはある。手に負えない重大な事態を招かないために、カオスエンジニアリングのような事前対応型の戦略を取り入れてリスクを理解するという方向へと、多くの金融機関が意識を変えた。同書では、アーリーアダプターの例として、米Capital Oneが紹介されている。
