クラウドサービスの信頼性を確保する方法

顧客の観点から見ると、クラウド サービスは問題なく機能するはずです。ただし、サービスの中断は避けられません。それは「それが起こるかどうか」という問題ではなく、厳密に言えば「いつ起こるか」という問題です。オンライン サービスがどれだけ慎重に設計され構築されたとしても、予期しない出来事が起こることは避けられません。違いは、サービス プロバイダーがこれらの状況をいかに予測し、タイムリーに回復するかにあります。それによって顧客体験を保証します。

設計の原則

クラウド サービスの 3 つの設計指針は、1. データの整合性、2. フォールト トレランス、3. 迅速な回復です。これらは、顧客がサービスにおいて少なくとも満たされることを期待する 3 つの主要な属性です。データの整合性とは、クライアントがサービスに委託した情報の忠実性を保護することを指します。フォールト トレランスとは、サービス プロバイダーが障害を検出し、サービスが中断されないように自動的に修正措置を講じる機能です。迅速な復旧機能とは、予期しない障害が発生した場合に、サービスを迅速かつ完全に復旧する能力を指します。

サービスプロバイダーとして、さまざまな潜在的な障害をできるだけ早く特定して発見し、サービス設計フェーズでこれらの状況を十分に考慮する必要があります。このような思慮深い計画は、予期しない課題が発生したときにどのようにサービスを提供し、どのように対応するかを正確に決定するのに役立ちます。サービスは、これらの障害シナリオから最小限の中断で回復できる必要があります。すべての障害ポイントや障害モードを予測することはできませんが、先見性、事業継続計画、そして多くの実践を通じて、緊急事態に備えるための一連の緊急時計画プロセスを開発することができます。

クラウド コンピューティングの特性によれば、共有インフラストラクチャと疎結合に依存するシステムで構成された複雑なシステムであり、多くの特性がプロバイダーの直接的な制御外にあると言えます。従来、多くの企業は、アプリケーション、インフラストラクチャ、および関連サービスを直接制御できるオンプレミスのコンピューティング環境を維持してきました。しかし、クラウド コンピューティングの使用が拡大するにつれて、多くの企業はコストを削減し、リソースの弾力性 (コンピューティング、ストレージ、ネットワーク リソースなど) を活用し、ビジネスの俊敏性を促進し、IT リソースをより効率的に活用するために、ある程度の制御を放棄することを選んでいます。

チームの役割を理解する

エンジニアリング サービス チームの観点から見ると、設計およびアーキテクチャ サービス (ボックス製品やオンプレミス ソリューションとは対照的) は、責任範囲の拡大を表します。オンプレミス展開用のソリューションを設計する場合、エンジニアリング チームは、ソフトウェア運用推奨事項で説明されているコンピューティング環境に基づいて、サービスを設計、構築、テストし、パッケージ化してリリースするだけで済みます。対照的に、サービスの設計、構築、テストの後、エンジニアリング サービス チームは、サービスの継続的な運用を確保するために、関連する展開と監視も実行する必要があります。緊急事態が発生した場合は、できるだけ早く解決する必要があります。また、エンジニアリング サービス チームは、サービス コンピューティング環境をさらに制御できないことがよくあります。

故障モード影響分析

多くのサービス チームは、サービスの信頼性を向上させ、障害の発生を防ぐために、障害モデル分析 (FMA) と根本原因分析 (RCA) を使用しています。これらは必要だが十分ではないというのが私の見解です。代わりに、設計チームは、より効果的な結果を確実に得るために、故障モード影響解析 (FMEA) を採用する必要があります。

FMA は、繰り返し可能な設計プロセスを通じて、サービス設計プロセスにおける障害を特定し、軽減することを目的としています。 RCA では、不利な結果につながる要因の性質、大きさ、場所、タイミングを特定して判断します。総合的なエンドツーエンドの FMEA アプローチの主な利点には、障害ポイントとモードの包括的な図表が含まれ、既知の障害のマッピングを軽減するためのエンジニアリング投資の優先順位リストが可能になります。

FMEA は、システム信頼性エンジニア技術の開発研究を利用して、起こりうる (複雑な) システム障害の問題を発見します。この研究は、重大度、発生頻度、検出能力を評価することで、障害の影響の観点から起こり得る問題を理解し、さまざまなリスクに基づいて必要なエンジニアリング投資の優先順位を決定できるようにすることを目的としています。

準備フェーズ: このステップでは、システムの整合性を理解し、システムのコンポーネント、データ ソース、データ ビジネス フローを含むシステムの完全な論理図を生成することが重要です。これはテンプレートを使用して行われ、設計チームが重要な手がかりを発見できる可能性のある障害ポイントを提供することで、全体的な分析結果が向上します。

コンポーネント間の相互作用を検出します。すべてがこのステップの範囲内にあります。前述のロジック図から始めて、すべてのコンポーネントが動作障害の影響を受けやすいかどうかを判断します。すべてのコンポーネント (コネクタ) 間の相互作用と、各コンポーネントがシステム全体でどのような役割を果たすかを理解します。