システムとカオスのテスト: クラウドの回復力へのアプローチ

[51CTO.com クイック翻訳]今日のデジタルテクノロジー時代では、ダウンタイムは企業にとって事業の中断と収益の損失を意味するため、回復力のあるクラウド コンピューティング アーキテクチャの構築が不可欠です。たとえば、COVID-19 パンデミックの際には、渡航禁止により、IT メンテナンス チームがデータ センター内のサーバーを現地で再起動してメンテナンスすることが困難になりました。これにより、データやソフトウェアへのユーザー アクセスに大きな障害が生じ、生産性の低下につながり、オンプレミスの施設がダウンした場合には業務が中断される可能性があります。

現時点での効果的な解決策は、会社のビジネスをクラウド コンピューティング インフラストラクチャに移行し、IT スタッフがリモートで作業して 24 時間体制の技術サポートを提供し、安全な運用を確保することです。ここでクラウドコンピューティングが救世主の役割を果たします。企業がクラウド コンピューティングの可能性を最大限に活用しようとするにつれて、クラウド運用の可観測性と回復力が不可欠になります。

テクノロジー主導のビジネス経済においては、クラウド コンピューティング サービスの停止は壊滅的な結果をもたらすでしょう。障害や停止が発生するとドミノ効果が発生し、システムのパフォーマンスが低下します。したがって、企業は体系的なテストとカオス テストを通じて、クラウド コンピューティング アーキテクチャに回復力を組み込む必要があります。

カオス テストは、大規模な分散システムにおけるカオス的な問題に対処するための、テスト可能なシステム ベースのアプローチです。回復力と可観測性の意味、そしてダウンタイムや業務の中断を回避するためにシステム テストとカオス テストがなぜ重要であるかを学びます。

クラウド コンピューティング サービスの停止を回避するには、企業は継続的かつ無秩序な方法でテストを行い、クラウド アーキテクチャに回復力を組み込む必要があります。

1. 可観測性

観測可能性は 2 つの側面から理解できます。一方では、観測可能性は、制御理論を通じて、外部出力を推測することによってシステムの状態を理解するプロセスとして解釈されます。一方では、観測可能性の規律と方法は不確実性と未知のものを測定することを目的としていると解釈しています。

システムまたはアプリケーションの特性を理解するのに役立ちます。クラウド コンピューティングにおける可観測性は、ドメイン、スケール、サービス全体にわたるエンドツーエンドの監視を活用するための前提条件です。監視はアプリケーションの問題や異常の根本原因を理解するために使用されるため、監視と可観測性を混同しないでください。監視は、何か問題が発生したときに IT 部門に通知し、可観測性は問題が発生した理由を理解するのに役立ちます。目的は異なりますが、相互に補完し合っています。

クラウド コンピューティング システムでは、ダウンタイムの短縮、アプリケーションの速度向上などを実現するために、可観測性と回復力が求められます。

2. 柔軟性

クラウド プラットフォームに移行する企業は、システムの安定性、信頼性、可用性、回復力を確保し、テストする必要があります。回復力は階層の最上位にあります。安定性により、システムやサーバーが頻繁にクラッシュすることがなくなります。可用性は、アプリケーションをさまざまな場所に分散して作業負荷を軽減することで、システムが正常に動作することを保証します。信頼性により、クラウド コンピューティング システムが効率的に動作し、利用可能であることが保証されます。ただし、企業が予期しない問題に対処したい場合は、回復力を継続的にテストすることが不可欠になります。

回復力とは、問題が予測され、システムがその問題に対処して自ら調整し、解決するようにテストされることを意味します。システムの復元力は自動的ではありません。回復力のあるシステムは、複雑なシステムと問題を認識し、エラーに対応するための段階的な手順を実行します。問題や障害の影響を軽減するには、継続的なテストが必要です。継続的なテストにより、クラウド コンピューティング サービスの障害を回避し、より高いパフォーマンスと効率を確保できます。

回復力は、フィールド回復力設計とカオス テストなどのシステム テスト方法を活用することで実現できます。

従来のテストとその不十分な点

従来のテストでは、アプリケーションのクラウド コンピューティング システムへのシームレスなセットアップと移行を保証し、さらにその実行と生産性を監視できます。これは、クラウド コンピューティング システムが設計上の考慮事項に従ってアプリケーションのパフォーマンスと機能を変更しないことを保証するのに十分です。

従来のテストでは、潜在的な隠れたアーキテクチャの問題や異常を発見するのに効果がないため、十分ではありません。一部の障害は、特定の条件が引き起こされたときにのみ可視化されるため、休眠状態にあるように見えます。

クラウドコンピューティングの高可用性の約束

マイクロソフトのクラウド コンピューティング事業責任者であるスコット ガスリー氏は、クラウド コンピューティングの将来と展望について次のように語っています。「デジタル分野では加速が見られます。クラウド コンピューティングにより、ムーアの法則のペースで規模を拡大できるだけでなく、迅速に拡大し、インフラストラクチャの使用を減らすことも可能になります。」 COVID-19パンデミックにより企業の従業員は自宅からのリモートワークを余儀なくされたため、クラウドコンピューティングへの投資は急増しませんでした。しかし、この前例のない需要により、すべてのハイパースケーラーはスロットリングと優先順位付けの制御を採用する必要があり、これはパブリック クラウドのオンデマンドの弾力性の原則に反しています。

パブリック クラウドは、停止やダウンタイムが発生すると問題が発生する可能性もあります。たとえば、最近 Google で発生したシステム障害では、Gmail や Youtube など複数の Google サービスが停止しましたが、これはパブリック クラウドでもシステム障害が発生する可能性があることを示しています。したがって、この流行は、弾力性のあるクラウド コンピューティング システムにいくつかの視点を追加します。

1. システムはスムーズに実行され、オンライン トラフィックの予期しない急増があっても変化しない必要があります。

2. 追加のリソース割り当て要求がクラウド コンピューティング プロバイダーによって拒否または制限された場合に備えて、システムは機能とリソース プールを管理するための代替方法を見つける必要があります。

3. システムは、未知の場所を処理し、ハイブリッド作業環境（ネットワーク ファイアウォールの外側に複数のエンドポイントが存在する可能性あり）に移行できるように、アクセス可能で安全である必要があります。

COVID-19 パンデミックにより、弾力性のあるクラウド システムの継続的テストとカオス テストの価値が浮き彫りになりました。回復力があり、徹底的にテストされたシステムは、追加の混雑したトラフィックを安全かつシームレスで安定した方法で管理できます。未知のトラフィックを検出するには、カオス テストとカオス エンジニアリングが必要です。

クラウドネイティブアプリケーション設計だけでは回復力を実現するには不十分

パブリック クラウドでは、クラウド コンピューティング プロバイダーによって提供される基本機能のギャップ、多層/マルチテクノロジ インフラストラクチャ、クラウド コンピューティング システムの分散性により、アプリケーションの回復力アーキテクチャがさらに重要になります。これにより、基盤となるインフラストラクチャの可用性と回復力がクラウド プロバイダーによって提供されている場合でも、クラウド アプリケーションが予期しない方法で失敗する可能性があります。

アプリケーションの回復力の適切な基盤を確立するために、クラウド エンジニアは、設計プロセス中にアプリケーション層の回復力をテスト、評価、および特徴付ける次の戦略を採用する必要があります。

1. 適切に設計された全体的なソリューション アーキテクチャ フレームワークを活用し、可用性と災害復旧のためのクラウド ネイティブ機能を採用します。

2. クラウド アーキテクトおよびテクニカル アーキテクトと協力して、可用性の目標を定義し、アプリケーションおよびデータベース レイヤーの回復力プロパティを導き出します。

モデリング中に、予想される使用パターンまたは観察された使用パターンに基づいて仮想的な障害モデルを定義し、ビジネスへの影響に基づいてこれらの障害モードのテスト計画を作成します。

アーキテクチャ主導のテスト アプローチを採用することで、企業はクラウド アプリケーションの運用開始前に基本レベルの回復力を把握し、パフォーマンス修復活動に十分な時間を割り当てることができますが、クラウド ネイティブ アプリケーション設計における未知の障害や障害ポイントの複数の側面についてアプリケーションをテストする必要があります。

カオステストとサイト信頼性エンジニアリング

カオス テストは、クラウド コンピューティング アーキテクチャに意図的にストレスや異常を導入して、システムの回復力を体系的にテストする方法です。

まず、カオス テストは実際にシステムをテストすることの代わりになるものではないことを明確にすることが重要です。それはエラーを測定するための単なる別の方法です。カオス テストを通じて、IT チームは何が起こり、どのように対処するかを把握できます。しかし、最も重要なのは、当初は見落とされていたシステムの観測性と回復力のギャップを測定するのに役立つことです。

Netflix は、2011 年にクラウド コンピューティングに移行したときに、この強力なテスト アプローチを先駆的に導入しました。カオス テストは非効率性を明らかにし、開発チームが変更を加え、回復力を測定および改善できるようにガイドし、クラウド アーキテクトが設計をより深く理解して変更できるように支援します。

継続的、体系的、かつ混沌としたテストにより、クラウド コンピューティング インフラストラクチャの復元力が向上し、システムの復元力が効果的に強化され、最終的には管理チームと運用チームが構築しているシステムに対する信頼が高まります。

企業は、クラウド コンピューティング インフラストラクチャ上に部分的または完全に弾力性のある IT システムを構築する必要があります。

カオス テストとサイト信頼性エンジニアリングを使用すると、組織は次のように回復力を維持できます。

• クラウド コンピューティングとインフラストラクチャの弾力性。
• 継続的な監視を通じてデータの回復力を実現します。
• ユーザーと顧客は、高ストレス条件下でもユーザー インターフェイスが安定した状態を保つことで回復力を実感できます。
• セキュリティとガバナンスおよび制御メカニズムを組み合わせることで、回復力のあるサイバーセキュリティを実現します。
• インフラストラクチャ、アプリケーション、データに対する耐障害性の高いサポート。

完全なアプリケーションの回復力を構築するには、前述のクラウド アプリケーションの設計の側面に加えて、ソリューション アーキテクトは、特定の障害を注入して内部エラーをトリガーし、開発およびテスト フェーズ中に障害をシミュレートできるアーキテクチャ パターンも採用する必要があります。

障害のトリガーの一般的な例としては、応答の遅延、リソースの占有、ネットワークの停止、一時的な状態、ユーザーによる極端なアクションなどが挙げられます。

• 一般的に特定されるシナリオに対して、インシデント対応を継続的に監視、管理、自動化する計画を策定します。
• カオステストのフレームワークと環境を確立します。
• さまざまな重大度と組み合わせの障害を挿入し、アプリケーション層の動作を監視します。
• 異常な動作を特定し、上記の手順を繰り返して重大性を確認します。

カオステストの実行方法

カオス テストは、クラウド コンピューティング ファブリックの 7 つのレイヤーのいずれかに異常を導入することで実行でき、回復力への影響を評価するのに役立ちます。

Netflix が 2011 年に回復力ツール Chaos Monkey をリリースしたとき、多くの開発チームがそれをカオス エンジニアリング テスト システムに使用しました。ソフトウェア エンジニアによって開発された、同じことを実行するテスト システムである Gremlin という別のツールもあります。ただし、COVID-19 パンデミックの現在の状況でカオス テストを実行したい場合は、GameDay を使用できます。これにより、トラフィックの急激な増加によって発生する異常が刺激される可能性があります。たとえば、複数の顧客が同時にモバイル アプリケーションにアクセスする場合などです。 GameDay の目標は、回復力をテストするだけでなく、システムの信頼性を高めることにもあります。

カオス テストを成功させるには、次の手順を実行する必要があります。

1. 特定: システムの主な弱点を特定し、予想される結果とともに仮説を作成します。エンジニアは、仮想フレームワーク内でどのような種類の障害を注入するかを識別し、評価する必要があります。

2. シミュレーション: 実際のイベントに基づいて、生産プロセスに異常を注入します。これにより、システム内で発生する可能性のあるシナリオがカバーされます。これにより、アプリケーションまたはネットワークの停止、あるいはノード障害が発生する可能性があります。

3. 自動化: これらの実験は、おそらく 1 時間ごと、または 1 週間ごとなどに自動化する必要があります。これにより継続性が確保されますが、これはカオス エンジニアリングでは欠点です。

4. 継続的なフィードバックと改善: これらの実験には、回復力の確保、または対処が必要な問題の検出という 2 つの成果があり、そこからフィードバックを得てシステムを改善できます。

システムに対して偽の攻撃やシーケンスを誘発する他の具体的な方法としては、次のものが考えられます。

• ネットワーク遅延が増加しました。
• スケジュールされたタスクを中止します。
• マイクロサービスを切断します。
• システムをデータセンターから切断します。

結論

クラウドへの移行とクラウド コンピューティングの使用が急増している今日のデジタル時代では、アプリケーションの効果的なパフォーマンスを向上させるために、クラウド コンピューティングの弾力性を強化することが不可欠になっています。プロジェクトのライフサイクル中は、継続的かつ体系的なテストが不可欠であり、パブリック クラウドが過負荷になったときにクラウド コンピューティング アーキテクチャの回復力を確保する必要があります。長期間の停止を防ぐことで、企業は大幅なコストを節約し、損失を回避できるだけでなく、顧客に提供されるサービスの継続性を確保できます。したがって、カオステストは大規模分散システムを導入するための必須条件となります。

原題: Systematic and Chaotic Testing: A Way to Achievee Cloud Resilience、著者: Gaurav Aggarwal

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。