クラウドレジリエンスへのアプローチ - システムおよびカオステスト

【51CTO.com クイック翻訳】

今日のデジタル テクノロジー時代では、ダウンタイムはダウンタイムを意味し、回復力のあるクラウド構造の構築が必須です。たとえば、COVID-19 パンデミックの間、IT メンテナンス チームはデータセンター内のサーバーをローカルで再起動できなくなりました。ローカル ハードウェアに障害が発生すると、すべてのデータやソフトウェアへのアクセスに大きな障害が生じ、生産性が低下し、ビジネス全体の損失につながる可能性があります。しかし、上記の問題の解決策は、すべての IT 操作をクラウド インフラストラクチャに移行し、リモート メンバーによる 24 時間 365 日の技術サポートによって保護することです。ここでは雲は本質的に神のような存在です。

最近、多くの企業がクラウドの可能性を最大限に活用しており、ダウンタイムが切断やビジネスの損失につながるため、クラウド運用の可観測性と回復力が不可欠になっています。

今日のテクノロジー主導のビジネス経済において、クラウドの障害を想像することは壊滅的な結果をもたらすでしょう。障害や停止が発生するとドミノ効果が発生し、会社のシステムパフォーマンスに影響を及ぼします。したがって、組織や企業にとって、カオスと体系的なテストを通じてクラウド ファブリックにクラウドの復元力を組み込むことが重要になります。この記事では、回復力と可観測性の意味と、回復力とカオス テストがダウンタイムを回避するためになぜ重要であるかについて説明します。

クラウドの障害を回避するために、企業は継続的かつ無秩序な方法でテストを行い、クラウド アーキテクチャに回復力を組み込む必要があります。

1.) 可観測性

観測可能性は 2 つの方法で理解できます。 1 つは制御理論によるもので、これは外部出力を推測することによってシステムの状態を理解するプロセスとして観測可能性を説明します。もう 1 つの側面は、観測可能性の規律と方法、つまり不確実性や未知のものを測定するために使用される規律と方法について説明します。
クラウドでの可観測性は、ドメイン、規模、サービス全体にわたるエンドツーエンドの監視を活用するための前提条件です。監視はアプリケーションの問題や異常の根本原因を理解するために使用されるため、可観測性と監視を混同しないでください。監視は何か問題が発生したときに通知しますが、観測可能性は問題が発生した理由を理解するのに役立ちます。それぞれ目的は異なりますが、互いに補完し合っています。

クラウド システムは、ダウンタイムの短縮、アプリケーションの速度向上などを実現するために、監視可能で回復力に優れている必要があります。

2.) 柔軟性

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

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

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

従来のテストとその欠点

従来のテストでは、アプリケーションがクラウド システムに直接インストールおよび移行されていることを確認し、そのパフォーマンスと生産性を監視します。クラウド システムがアプリケーションのパフォーマンスと機能を設計どおりに変更しないことを保証するだけで十分です。

従来のテストでは、潜在的な隠れたアーキテクチャの問題や異常を発見するのに効果がなく、特定の条件がトリガーされた場合にのみ表示される障害もあるため、十分ではありません。

クラウドの高可用性の約束

スコット・ガスリー氏はクラウドの将来と展望について、「デジタル空間は加速しています。クラウドにより、ムーアの法則の速度で拡張でき、より少ないインフラストラクチャを使用して迅速に拡張できます」と述べています。パンデミックの影響で人々が在宅勤務を余儀なくされているため、クラウドへの投資は急増していない。しかし、この前例のない需要により、すべてのハイパースケーラーはスロットリングと優先順位付けの制御を導入する必要があり、これはパブリック クラウドのオンデマンドの弾力性とは相反するものです。

パブリック クラウドでは、停止やダウンタイムに関して課題がないわけではありません。たとえば、Gmail や Youtube など複数の Google サービスがダウンした最近の Google の障害は、パブリック クラウドでは必ずしもシステム ダウンタイムがないわけではないことを示しています。したがって、パンデミックによって、弾力性のあるクラウド システムにいくつかの新たな視点が加わったと言えます。

1. オンライントラフィックが予期せず急増しても、システムはスムーズに動作し、変更されないこと
2. クラウド プロバイダーが追加のリソース割り当て要求を拒否または制限した場合に備えて、システムは機能とリソース プールを管理するための代替方法を見つける必要があります。
3. システムは、未知の場所を処理し、ハイブリッド作業環境（ネットワーク ファイアウォールの外側に多数のエンドポイントが存在する可能性がある）に移行できるように、アクセス可能で安全である必要があります。

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

クラウドネイティブアプリケーション設計だけでは回復力は実現できない

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

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

1.全体的なソリューション アーキテクチャに適切に設計されたフレームワークを活用し、可用性と災害復旧のためにクラウド ネイティブ機能を採用します。
2.クラウド アーキテクトおよびテクニカル アーキテクトと協力して、可用性の目標を定義し、アプリケーションおよびデータベース レイヤーの回復力プロパティを導き出します。
A. 脅威モデリングと併せて、予想される使用パターンまたは観察された使用パターンに基づいて仮想障害モデルを定義し、ビジネスへの影響に基づいてこれらの障害モードのテスト計画を確立します。

アーキテクチャ主導のテスト アプローチを採用することで、組織は稼働前にクラウド アプリケーションの回復力の基本レベルを把握し、パフォーマンス修復アクティビティに十分な時間を割り当てることができます。しかし、クラウド ネイティブ アプリケーションの設計では、未知の障害や複数の障害点についてアプリケーションをテストする必要が依然としてあります。

カオステストとエンジニアリング

カオス テストは、クラウド ファブリックに意図的にストレスや異常を導入して、システムの回復力を体系的にテストする方法です。

まず、カオス テストはシステムを実際にテストすることの代替にはなりません。これはエラーを測定する別の方法にすぎません。システムに劣化を導入することで、IT チームは何が起こったか、どのように反応するかを確認できます。重要なのは、テストによって、テスターが当初は見落とされていたシステムの可観測性と回復力のギャップを測定できるようになることです。

Netflix は、2011 年のクラウドへの移行時に初めてこのテスト手法を模倣し、それ以来、効果的にこれに基づいて構築してきました。カオス テストは非効率性を明らかにし、開発チームが回復力を変更、測定、改善できるようにガイドし、クラウド アーキテクトが設計をより深く理解して変更するのに役立ちます。
継続的、体系的、かつ混沌としたテストにより、クラウド インフラストラクチャの復元力が向上し、システムの復元力が効果的に高まり、最終的には管理チームと運用チームが構築しているシステムに対する信頼が高まります。

回復力のある企業は、回復力のある IT システムを部分的または全体的にクラウド インフラストラクチャ上に構築する必要があります。

カオスおよびサイト信頼性エンジニアリングを使用すると、企業は次の方法で回復力を高めることができます。
• クラウドとインフラストラクチャの回復力
• 継続的な監視を通じてデータの回復力を実現します。
• 高ストレス条件下でもユーザーインターフェースが安定していることを保証することで、ユーザーと顧客エクスペリエンスの回復力を実現します。
• セキュリティをガバナンスおよび制御メカニズムと統合することでネットワークセキュリティを強化
• インフラストラクチャ、アプリケーション、データに対する回復力のあるサポート

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

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

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

カオステストの実行方法

カオス テストは、クラウド構造の 7 つの層のいずれかに異常を導入することで実行でき、回復力への影響を評価するのに役立ちます。

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

カオス テストを成功させるために必要な手順は次のとおりです。
1. 特定:システムの主な弱点を特定し、仮説と期待される結果を作成します。エンジニアは、仮想フレームワーク内でどのような種類の障害を注入するかを識別し、評価する必要があります。
2. シミュレーション:実際のイベントに基づいて、生産プロセスに異常を注入します。これにより、システム内で発生する可能性のあるシナリオがカバーされます。これにより、アプリケーションまたはネットワークの停止、あるいはノード障害が発生する可能性があります。
3. 自動化:これらの実験を、おそらく 1 時間ごと、1 週間ごとなどに自動化します。これにより、カオス エンジニアリングでは欠点となる継続性が確保されます。
4. 継続的なフィードバックと改善:実験には 2 つの結果があります。回復力を確保したり、対処する必要がある問題を特定したりできます。どちらのアプローチも良い結果をもたらし、そこからフィードバックを得てシステムを改善することができます。

システムに対して偽の攻撃やシーケンスを誘発する他の具体的な方法としては、次のものが考えられます。
1. ネットワーク遅延の増加
2. 予定されているタスクを中止する
3. マイクロサービスの切断
4. システムをデータセンターから切断する

要約する

今日のデジタル時代では、アプリケーションの効率的なパフォーマンスを実現するために、クラウドの回復力を強化することが不可欠になっています。継続的かつ体系的なテストは、プロジェクトのライフサイクル中に不可欠ですが、パブリック クラウドに過負荷がかかった場合にクラウドの回復力を確保するためにも重要です。長期間の停止や将来の中断を防ぐことで、企業は顧客に提供するサービスの耐久性を確保できるだけでなく、大幅なコストを節約できます。したがって、大規模な分散システムではカオス エンジニアリングが必須になります。

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