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

テクノロジーはどこにでもあります。あなたの業界がどれほど危険にさらされているかに応じて、テクノロジー製品やシステムの失敗は、あなたが知っているように、完全に無視できるレベルから寿命の終わりまでの範囲に収まります。

病院のメインフレーム?なんか大事。携帯電話の Candy Crush アプリの回復力?おそらく、優先順位の全体的なリストでは少し低いでしょう。

ネットワークの分散システムでは、障害は避けられません。大災害の防止は、堅牢で水密なセキュリティ設計から始まります。それ以外に、他に何ができるでしょうか。

Netflixのカオスエンジニアリングとは?

2015 年 9 月 20 日。

西部戦線ではすべてが静まり返っていましたが、突然、いくつかの重要な企業のアマゾン ウェブ サービスサーバーが何も言わずにダウンしました。

多くの大企業は、顧客に数時間サービスを提供できませんでした。しかし、Netflix はほんの数分で立ち直りました。どうやって? Netflix の社内文化は、災害発生時にシステムとエンジニアの両方を同様に準備するために、リアルタイムで実装された多くの「失敗を誘発する」プラクティスを含むように進化しました。

同社の経営陣は、このようなイベントの調査と準備のために、システムの含まれる部分でサーバーの停止をシミュレートすることを意図的に実施しました。これにより、システムの穴を特定し、前述のような重大な故障が発生した場合でも、サービスを中断することなく継続できる冗長性を構築することができました。

これらの意図的な「カオス エンジニアリング」演習により、エンジニアは、この種の終末の出来事を念頭に置いて構築した予防的インフラストラクチャのおかげで、大失敗を乗り越えるための十分な競争力を得ることができました。

大きな波が襲ったとき、他の誰も準備ができていませんでした。 Netflix のシステムは、自分自身を守るのに十分強力でした。結論?これらの混沌とし​​た首謀者たちは、ここで何かを企んでいるのかもしれません。

あなたを愛する人を意図的に絶滅させる

「カオス エンジニアリングは、システムが生産中の乱流条件に耐えられるという信頼を築くために、システムで実験を行う規律です。」

カオス宣言の原則

これは、カオス エンジニアリングの核心であり、本質的に、提示された課題に対処するための目と手がある勤務時間中にシステムに課せられる「避難訓練」です。脆弱性が露呈すると、特定のシステムが障害を許容する能力がテストされます。

2011 年の当初の状況では、カオス エンジニアリングは Netflix の IT 部門に関係していました。彼らの経営陣は、1 台以上のコンピューターを意図的に無効にしたときのチームの取り組みがどれほど回復力があるかをテストしたいと考えていました。これらの後退により、IT チームは、システム全体の問題になり、外部から悪用される前に主要な弱点を特定することができました。

本当の失敗?それは非常に高価になる可能性があり、それは金銭的な意味を超えています.セキュリティが実質的に失われていないダウンタイムであっても、収益を得る機会を多く失う可能性があります。なぜ緊急事態があなたを盲目にするのを待つのですか?

狂気の背後にあるサル

一部の企業は、開発者のチームを部門の垣根を越えて同胞と戦う「レッドチーム」モデルを採用するでしょう。ただし、Netflix が述べた典型的な例では、「シミアン アーミー」を利用しています。これらのボットは、公平かつ完全にランダムに汚い仕事をします。

正気じゃない?おそらく、素人には。 『カオス・モンキーズ』の作者、アントニオ・ガルシア・マルティネスの言葉:

「私たちのオンライン活動のすべての重要な機能をホストするサーバーの「農場」である「データセンター」に入るサルを想像してください。サルはランダムにケーブルを引き裂き、デバイスを破壊します。サルが責任を負う情報システムを設計することが課題です。これらのサルがいつ到着し、何を破壊するかは誰にもわからないにもかかわらず、それが機能するということです。」

カラフルなアナロジー。ただし、すべてのシミアンが残忍なわけではありません。たとえば、Doctor Monkey はシステムのパフォーマンスを監視します。しかし、Chaos Kong が訪問に立ち寄ったときは、すべての賭けがオフになっています。このキャラクターは AWS アベイラビリティーゾーン全体をダウンさせます。

関連:セキュリティの脆弱性はどのように評価されますか?

カオスエンジニアリングと科学的方法

カオス エンジニアリングは、実験を行う者にとって、体系的な洞察の貴重な情報源として機能します。ここで試されるのは開発者だけではありません。それは自律的に存在するシステムでもあります。

サルの樽をテーブルに放り出す前に、カオス エンジニアリングでは少し下地を作る必要があります。

  1. 最初に、システムにとって「安定した」、健康で機能的な状態であると考えるものを特定する必要があります。これは、具体的な結果を測定する「コントロール」になります。
  2. 組織化された障害の侵入によって、この状態がどのようにバランスを崩すかを考え始めます。システムの封じ込められた制御可能な領域にのみ影響を与えるマルウェアの調査を計画してください。
  3. 「侵入者」を導入し、システムが応答できるようにします。
  4. ホメオスタシスにある間、現在のシステムと以前の動作の違いを観察して解釈します。脆弱性を検出するかフルスケールに到達するまで、どちらか早い方まで、影響の「爆発範囲」を広げます。

機能的なシステムを混乱させるのが難しいほど、変化や衝撃に対する回復力に自信を持つことができるという考え方です。このアプローチは、システムのさまざまな側面が、障害発生時に互いの障害をどのように補償するかを示しています。

「単一のコンポーネントが 100% の稼働時間を保証することはできないため (そして最も高価なハードウェアでさえ最終的には失敗します)、システム全体の可用性に影響を与えることなく個々のコンポーネントが失敗してもよいクラウド アーキテクチャを設計する必要があります。」

Netflixのブログ

このようにシステムをいじっても、カスタマー エクスペリエンスにほとんど影響を与えない場合もあります。また、重大なセキュリティ上の欠陥が明るみに出る場合もあります。現在、特に Netflix では、ユーザー レベルでシステム障害を隠すための不測の事態がシステムの基盤に組み込まれています。

関連:ゼロデイ エクスプロイトとは?

カオスエンジニアリングは価値がありますか?

批評家は、たとえ一時的かつ偶発的なものであっても、顧客の体験に影響を与える価値のあるバックエンド ゲームはないと言うでしょう。ただし、カオスエンジニアリングに賛成する人は、これらの「計画された停止」は、AWS が 2015 年に経験したものよりもはるかに小さいことを意味しているという事実に反論するでしょう。最初のインシデントを計画することが最善の準備方法である可能性があります。全体として影響を受けるユーザーは少なくなります。計算はうまくいきます。

問題の人間の側から見ると、目の前でサーバー クラッシュを経験し、それを適切に処理したエンジニアは、将来的にはより警戒心が強くなり、何が起きても対処する知的能力が向上するという考え方があります。仕方。結果として生じるより強力なシステムは、多くの場合、それ自体を物語っています。

シリコンバレー: 夢が死ぬ場所

彼らは、あなたがそれを大きくしたいのであれば、あなたの最愛の人を殺すことをいとわなければならない、またはこの場合、他の人にあなたのために喜んで彼らを殺させなければならないと言います.開発の最初からセキュリティが最前線にある場合、チームは、顧客が自由に使用できる、侵入不可能で安全な何かを完成させる可能性がはるかに高くなります。

職場での体験をゲーム化することで、この分野での成功の見通しがわくわくします。最終結果が質の高いものになると、誰もがレベルアップします。私の Netflix は問題なく動作し、混乱の背後にいるのは狂人だけです。

カオス エンジニアリングについてしっかり理解したところで、別のソフトウェア開発方法論で知識を広げてみませんか?アジャイルは、従業員を統合し、クリーンで効率的なコードを生成するために組み込むことができる優れたシステムです。