かつては、ソフトウェア・システムは高度に管理されたオンプレミスの環境で運用され、管理者達によって管理されていました。今日では、クラウドへの移行は躊躇なく行われており、舞台は完全にシフトしています。システムはもはや一枚岩のようなローカルなものではなく、多くのグローバル化された非連結システムが一体となって動作し、多くの場合は空気のようなマイクロサービスの形で動作しています。
この10年でサイトリライアビリティエンジニアが注目を浴びるようになったのは当然のことです。現代のITインフラストラクチャでは、ショーを継続的に開催するために、堅牢なシステム思考とリライアビリティエンジニアリングが必要とされています。ダウンタイムはオプションではありません。2020年のITICのダウンタイムのコスト調査では、98%の組織が1時間のダウンタイムに15万ドル以上のコストがかかると回答しています。88%が、60分のダウンタイムで30万ドル以上のコストがかかると回答しています。また、40%の企業が、1時間のダウンタイムで100万ドルから500万ドル以上のコストがかかると報告しています。
このようなシステムの回復力を高めるために、カオスエンジニアリングという学問が登場しました。カオス検証を伴うシステムのストレステストを行うと、アキレス腱が明らかになります。悪条件をシミュレートすることで、エンジニアはセーフガード、サーキットブレーカー、インシデントレスポンスメカニズムを統合することができます。この記事では、この混沌としたな芸術形態に飛び込んでいきます。
カオスエンジニアリングとは?
カオスコミュニティによると「カオスエンジニアリングは，本番運用における乱気流に耐えるシステム能力に自信を持つためにシステムを検証実験する学問です」とされています。
ほとんどのエンジニアのこの規律への最初の接点はおそらくChaos Monkeyでしょう。これはNetflixが発明したツールで、エンジニアがNetflixのアーキテクチャ内でインスタンスやサービスを擬似的にランダムに終了させて、可用性が高く、回復力のあるサービスを実装できるようにするために、本番環境でインスタンスをランダムに終了させる役割を担っています。当時、NetflixはAmazon Web Servicesに移行したばかりで、インフラストラクチャがフォールアウトに耐え、自動的に自己回復できることを証明するフレームワークを作成する必要がありました。
Netflixはこのフレームワークに、Netflixのサービス間のリクエストを失敗させ、システムが自動的に劣化することを検証実験する「Failure Injection Testing」（FIT）などのテクニックを追加しました。もちろん、Amazon EC2 (Elastic Compute Cloud) リージョン全体の障害をシミュレートするChaos Kongのような、Simian Army内のツールもあります。このようなツールの融合が、現在カオスエンジニアリングとして知られている分野へと発展しました。
カオスエンジニアリングの原理
どんな検証実験でも、その設計には4つのことが必要です：前提条件と仮説、独立変数、従属変数、そしてもちろん、コンテキストです。これらの原則は、カオスエンジニアリング検証実験を設計するための道標を提供します。
- 定常状態の動作に関する仮説を構築する。
- 比較群と実験群の両方を利用して、現実世界の動作を誘発する。
- 実験グループに失敗を注入することで、本番環境での検証を実行する。
- 検証実験を自動化して継続的に実行し、システムが回復力があるという仮説を反証することを試みる。
実行可能な仮説は次のようになります。 「システムにX,Y,Zを注入している間、許容範囲は定常状態の8%を超えません」
頑健な検証実験は、システム内のいくつかのコンポーネントの可用性の損失を誘発する必要があります。検証実験は、ハッピーパスを避けて、実世界の事象を模倣する必要があります。テストは、過去のシステム停止のシナリオを再現しながら、すべての可能な入力を利用しなければなりません。
Related Reading: What is Chaos Testing?
テストの種類には以下のようなものがあります。
- ハードウェアの故障（またはそれに同等のバーチャルな条件）
- ネットワークの遅延/障害の変更(サービス間のリクエストに遅延を注入)
- リソース不足・過度の負荷
- 依存関係の障害（データベースなど）
- リトライストーム（Thundering Herd など）
- 機能的なバグ（例外）
- レース条件 (スレッド化と同時実行)
- アマゾンのリージョン全体を利用できないようにする
- サービス間のリクエストの失敗、または内部サービスの失敗
定常状態は、カオス検証実験の実行前、実行後、そして潜在的に実行中の環境の状態を定義します。この仮説を変更すると偏差が生じますが、これは次なる調査対象になります。そして、更なる調査が必要であり、潜在的には改善が適用されるべき場所であることを保証します。
実験を実行した後、システムが期待された定常状態に戻らない場合は、レッドアラートを出す必要があります。堅牢なシステムは、自己修復を行い、平衡状態または定常状態に再調整します。許容範囲を定義することにより、平衡からの偏差を計算することができます。
実験は、構想時には手動でテストする必要があるが、その後は自動化フレームワークに追加する必要があります。Netflixは平日の間Chaos Monkey を継続的に実行していますが、Chaos Kong の演習は月に一度しか実行していません。すべての企業は自社にとって最適なアプローチを必要とします。
カオスエンジニアリングツール
カオス検証実験を設計している間は、爆発半径を最小化することが不可欠であり、理想的には一度に1つの小さな失敗をすることが必要です。検証実験は慎重に測定し、低リスクであることを確認してください：少数のユーザを含む、ユーザフローを制限する、ライブデバイスの数を制限するなど。 検証を開始する際には、クライアントやデバイスのサブセットまたは少数のグループの機能を検証するための失敗を取り入れるのが賢明です。これらの低リスクの検証が成功したら、本番サーバ全体に均等に分散されたトラフィックのごく一部に影響を与える小規模な拡散検証実験の実行に進むことができます。
小規模な拡散実験の主な利点は、断線の可能性があるしきい値を越えないことです。これにより、過渡的なエラーに対するシステムの回復力を実証しながら、シングルリクエストのフォールバックやタイムアウトを検証することができます。この実験はフォールバック（制限ありの限定的な運用）の論理的な正しさを検証しますが、大規模フォールアウト時のシステムの特性については検証しません。
以下にツールを紹介します。
- Chaos Monkey：カオスエンジニアリングの元祖。このツールは現在も保守されており、現在はNetflixが当初開発したソフトウェアの変更を迅速かつ確実にリリースするための継続的なデリバリープラットフォームであるSpinnakerに統合されています。
- Mangle：アプリケーションやインフラストラクチャのコンポーネントに対してカオスエンジニアリングの実験を実行し、回復力と耐障害性を迅速に評価することができます。最小限の事前設定で障害を導入できるように設計されており、K8S、Docker、vCenter、またはSSHを有効にしたリモートマシンなど、さまざまなツールをサポートしています。
- Gremlin： カオス・アズ・ア・サービス（CaaS）をプロダクト化した元NetflixやAmazonのエンジニアによって設立されました。Gremlinは有料サービスで、コマンドラインインターフェース、エージェント、直感的なWebインターフェースを提供しており、カオス実験をあっという間にセットアップすることができます。心配しないでください。大きな赤いHALTボタンがあるので、顧客体験に悪影響を及ぼす攻撃があった場合に、Gremlinのユーザーは実験をロールバックすることができます。
- Chaos Toolkit：オープンなAPIと実験結果を公開するための標準JSONフォーマットを作成することで、カオス検証実験をより簡単にしようとするオープンソースのプロジェクト。AWS、Azure、Kubernetes、PCF、Googleのクラウド実験を実行するための多くのドライバを提供している。また、PrometheusやSlackなどの監視システムやチャットのための統合も含まれています。
カオスエンジニアリングになぜ投資するのか？
カオスエンジニアリングに投資する理由は数多くあります。まず、BCP（事業継続計画）や災害復旧のフレームワークを導入することが求められます。これらのフレームワークを実装することで、組織の運用上の脆弱性に対する意識を明らかにし、それに対処するための積極的なアプローチを示すことができるため、競合他社と比較して戦略的優位性を得ることができます。これにより、利害関係者や顧客からの信頼を得ることができます。
さらに、EU域内で重要インフラ産業を営む組織は、ネットワークと情報システムのセキュリティに関するEU指令の要求事項を遵守しなければならず、インシデント対応能力の導入が法的に義務づけられることになります。
カオスエンジニアリングは実験的なアプローチであるため、システムの挙動や、ある状況下ですべての可動部分がどのように相互作用しているかを全体的に見ることができ、システムの技術的側面とソフト的側面（人的要因）についての洞察を導き出すことができます。カオスエンジニアリングは、分散システムの複雑な性質のために、従来の方法では検出が困難であったセキュリティ脆弱性を発見することを可能にします。これには、人的要因、不適切な設計、または回復力の欠如によって引き起こされる損失が含まれる可能性があります。例えば、従来型のアプローチでは、敵対的なプロセスに焦点を当てた赤と紫のチーム演習で構成されますが、カオスエンジニアリングでは、企業はセキュリティシステムやチームがアクティブな脅威にどのように対応するかをテストすることができます。
Integrate.io: システム回復力とセキュアなデータ統合
Integrate.ioでは、システムの回復力に誇りを持っています。私たちは、以下のような最先端のデータセキュリティと暗号化技術を私たちのプラットフォームに組み込んでいます。
- 認定されたAmazon Web Service (AWS)技術によってホストされた物理的なインフラストラクチャ
- 欧州一般データ保護規則（GDPR）の基準を満たすための準備を進めています。
- すべてのウェブサイトとマイクロサービスのSSL/TLS暗号化（トランジット時と休止時の暗号化）
- フィールドレベル暗号化
- 業界標準の暗号化を使用したIntegrate.ioプラットフォームで、いつでも機密データを暗号化。
- 当社のセキュリティ証明書と暗号化アルゴリズムの継続的な検証
- 外部ネットワークからのシステムへのアクセスや、内部のシステム間のアクセスを制限するファイアウォール
当社のデータセキュリティ基準についてもっと知りたい方は、今すぐIntegrate.ioのオンラインデモを予約してください。
