信頼性および回復性の高いクラウド・トポロジのプラクティスについて
信頼性の高いアプリケーションは次のとおりです。
- 障害から正常に回復し、完全リカバリの前に最小限の停止時間とデータ損失で引き続き機能します。
- 高可用性(HA)で、かなりの停止時間なしで正常な状態で動作します。
- 優れたディザスタリカバリ(DR)設計により、リージョン障害から保護されます。
信頼性のあるアプリケーションを構築するには、これらの要素がどのように連携し、コストにどのように影響するかを理解することが不可欠です。これは、許容可能な停止時間、ビジネスの潜在的なコスト、およびリカバリ中に必要な機能を判断するのに役立ちます。
信頼性を考慮した設計
クラウド・アプリケーションを作成する場合は、次を使用して信頼性を構築します。
- 要件を定義します。
クラウドおよびビジネス・ニーズにもたらすワークロードに基づいて、可用性およびリカバリの要件を定義します。
- アーキテクチャのベスト・プラクティスを適用します。
実証済の演習に従い、アーキテクチャで考えられる障害ポイントを特定し、アプリケーションが障害にどのように対応するかを決定します。
- シミュレーションと強制的なフェイルオーバーを使用したテスト。
フォルトをシミュレートし、強制フェイルオーバーをトリガーし、これらの障害の検出とリカバリをテストします。
- アプリケーションを一貫してデプロイします。
信頼性の高い繰返し可能なプロセスを使用して本番環境にリリースし、可能な場合は自動化します。
- アプリケーション・ヘルスをモニターします。
障害を検出し、潜在的な障害のインジケータを監視し、アプリケーションの状態を測定します。
- 障害を管理します。
障害が発生した場合を識別し、確立された戦略に基づいて対処する方法を決定します。
要件の定義
クラウドおよびビジネス・ニーズにもたらすワークロードに基づいて、可用性およびリカバリの要件を定義します。
ビジネス・ニーズを特定し、信頼性計画と一致させる際には、次の点を考慮してください。
- ワークロードとその要件の特定
ワークロードは、ビジネス・ロジックおよびデータ記憶域要件の観点から他のワークロードから論理的に分離された個別の機能またはタスクです。各ワークロードには、可用性、スケーラビリティ、データ整合性および障害時リカバリに関する様々な要件があります。
- 使用パターンの決定
アプリケーションの使用方法は、要件において役割を果たします。重要期間中と重要でない期間中の要件の違いを識別します。たとえば、月末処理を処理するアプリケーションは、月末に失敗することはできませんが、他の時点では失敗を処理する可能性があります。稼働時間を確保するために、重要な期間中にコンポーネントまたは冗長性を追加し、値が追加されなくなったときに削除できます。
- 重要なコンポーネントとパスの特定
システムのすべてのコンポーネントが他のコンポーネントほど重要であるとはかぎりません。たとえば、増分値を追加するが、必要に応じてワークロードを実行できるオプションのコンポーネントがある場合があります。これらのコンポーネントが、ワークロードの重要な部分のどこにあるかを理解します。これは、可用性および信頼性のメトリックのスコープを設定し、最も重要なコンポーネントに優先順位を付けるリカバリ戦略を計画するのに役立ちます。
- 外部依存関係およびダウンストリーム障害の影響の識別
ワークロードが外部サービスに依存している場合、これらの依存性の障害がワークロードの可用性に悪影響を与える可能性があります。統合を分離して、ダウンストリームの障害から分離する方法を実装します。
- ワークロードの可用性要件の決定
高可用性(HA)は通常、稼働時間ターゲットに関して定義されます。たとえば、99%のHAターゲットは、特定のリソースが年間3.65日間使用できないことを意味します。Oracle Cloud Infrastructure (OCI)は、高可用性環境を提供するように設計されています。OCIでは、サービスごとにサービス・レベル合意(SLA)が公開されており、これらのサービスへの稼働時間および接続性に関するOracleのコミットメントを説明しており、要件にどのように適合しているかを確認する必要があります。OCIの一部のサービスには、高レベルのHA (特に自律型データベースなどのOracle管理サービス)が組み込まれています。アプリケーション・アーキテクチャがビジネス要件を満たしていることを確認するには、外部依存関係を含むワークロードごとにターゲットSLAを定義します。アプリケーションの依存関係に加えて、可用性要件を満たすためのコストと複雑さを説明します。
- リカバリ・メトリックの設定—リカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)
RTOは、障害インシデント後にアプリケーションを使用できなくなる最大許容時間です。
RPOは、障害時に許容されるデータ損失の最大期間です。
これらの値を導出するには、リスク評価を実施し、停止時間または組織内のデータ損失のコストおよびリスクを理解していることを確認します。
- 災害の定義
障害時リカバリ計画および要件を十分に文書化することは重要ですが、このようなイベントのカオス的な性質によって混乱が生じる可能性があります。ビジネスの障害を構成するものを理解し、障害時に必要となる主要な役割を特定し、障害対応を開始するための明確に定義された通信計画を確立します。
アーキテクチャのベスト・プラクティスの適用
アーキテクチャを設計する場合は、ビジネス要件を満たすプラクティスの実装、障害ポイントの特定、および障害の範囲の最小化に焦点を当てます。
次のベスト・プラクティスを検討してください:
- 障害が発生する可能性がある場所を特定します。
アーキテクチャを分析して、アプリケーションで発生する可能性のある障害のタイプ、それぞれの影響の可能性、および可能性のあるリカバリ計画を特定します。
- HAおよびDRの要件に基づいて、必要な冗長性のレベルを決定します。
各ワークロードに必要な冗長性のレベルは、ビジネス・ニーズおよびアプリケーションの全体的なコストに対する要因によって異なります。
- スケーラビリティを考慮した設計
クラウド・アプリケーションは、使用状況の変化に対応できるようにスケーリングできる必要があります。個別のコンポーネントから始めて、可能な場合は常に変更をロードするようにアプリケーションを設計します。将来簡単に拡張できるように、設計時のスケーリング制限に留意してください。
- リクエストを分散するためのロード・バランシングの使用
ロード・バランシングは、異常なインスタンスをローテーションから削除することで、アプリケーションのリクエストを正常なサービス・インスタンスに分散します。状態情報を外部化すると、バックエンドのスケーリングがエンド・ユーザーに対して透過的になります。セッション内で状態が追跡される場合は、スティッキ性が必要になることがあります。
- 可用性と耐障害性の要件を設計に組み込む
リジリエンシとは、システムが障害から回復し、引き続き機能する機能です。可用性は、システムが機能し、動作している時間の割合です。シングル・ポイント障害の回避やサービス・レベル目標によるワークロードの分解など、高可用性ベスト・プラクティスを実装します。アプリケーション・コンティニュイティや非同期トランザクションなどのデータ・レイヤーの標準機能を利用して、可用性とリジリエンスの両方を確保します。
- DRの実装
特定されたRTOおよびRPO要件を満たすようにソリューションを設計します。RTO内でDRソリューションのすべてのコンポーネントをオンラインにできることを確認します。RPOに対応できるようにデータを保護します。データを格納、バックアップおよびレプリケートする方法は重要です。
- データのバックアップ
完全にレプリケートされたDR環境でも、定期的なバックアップは重要です。データを定期的にバックアップおよび検証し、本番データとバックアップ・データの両方にアクセスできる単一のユーザー・アカウントがないことを確認します。
- アプリケーション・データのレプリケーション方法の選択
アプリケーション・データは様々なデータ・ストアに格納され、可用性要件が異なる場合があります。各タイプのデータ・ストアのレプリケーション方法および場所を評価して、HA要件およびRPOを満たしていることを確認します。
- フェイルオーバーの影響と障害時の準備状況への影響の理解
ワークロード要件を満たすために、レプリケーション用に別のリージョンをインスタンス化する必要がありますか。フェイルバック時のデータ整合性を心配する必要がありますか。
- フェイルオーバーおよびフェイルバック・プロセスのドキュメント化とテスト
新しいデータ・ストアにフェイルオーバーする手順を明確に文書化し、定期的にテストして、正確で簡単に従うことができることを確認します。
- データ・リカバリ計画がRTOを満たしていることを確認する
バックアップおよびレプリケーション計画で、RTOおよびRPOを満たすデータ・リカバリ時間が指定されていることを確認します。参照データ、ファイル、データベースなど、アプリケーションで使用されるすべてのタイプのデータを説明します。
- データのバックアップ
シミュレーションおよび強制フェイルオーバーを使用したテスト
信頼性をテストするには、断続的にのみ発生する障害条件下でエンドツーエンドのワークロードがどのように実行されるかを測定する必要があります。
- 実際の障害をトリガーするかシミュレートして、一般的な障害シナリオをテストします
フォルト・インジェクション・テストを使用して、一般的なシナリオ(障害の組合せを含む)およびリカバリ時間をテストします。
- 負荷がかかっている場合にのみ発生する障害の特定
本番データまたは可能なかぎり本番データに近い合成データを使用してピーク負荷をテストし、アプリケーションが現実の条件下でどのように動作するかを確認します。
- ディザスタリカバリドリルの実行
障害時リカバリ計画を準備し、定期的にテストして機能することを確認します。
- フェイルオーバーおよびフェイルバック・テストの実行
アプリケーションの依存サービスがフェイルオーバーし、正しい順序でフェイルバックすることを確認します。
- シミュレーション・テストの実行
実際のシナリオのテストでは、対処が必要な問題を強調表示できます。シナリオは制御可能で、ビジネスに無停止である必要があります。シミュレーション・テスト計画の管理を通知します。
- ヘルス・プローブのテスト
重要なシステム・コンポーネントをチェックするために、ロード・バランサおよびトラフィック・マネージャのヘルス・プローブを構成します。テストして、適切に応答することを確認します。
- モニタリング・システムのテスト
監視システムが重大な情報と正確なデータを確実に報告し、潜在的な障害を特定できるようにします。
- テスト・シナリオにサードパーティ・サービスを含める
回復に加えて、サードパーティーのサービス中断による障害の可能性があるポイントをテストします。
- テスト中に発生した問題から学ぶ
テストで問題またはギャップが明らかになった場合は、追加のモニタリングを追加するか、運用プロセスを調整して、それらが識別され、対処されていることを確認します。
アプリケーションを一貫してデプロイする
デプロイメントには、Oracle Cloud Infrastructure (OCI)サービスおよびリソースのプロビジョニング、アプリケーション・コードのデプロイ、構成設定の適用が含まれます。更新には、3つのタスクすべてまたはそのサブセットが含まれる場合があります。
- アプリケーションのデプロイメント・プロセスの自動化
できるだけ多くのプロセスを自動化します。可能な場合は、本番環境での手動デプロイメントを排除する必要がありますが、速度と柔軟性を高めるために、これは低い環境で許容される可能性があります。
- 導入前に自動化を活用してコードをテスト
エンド・ユーザーが発見する問題を最小限に抑えるには、バグ、セキュリティの脆弱性、機能、パフォーマンスおよび統合のテストが重要です。テストが失敗した場合、コードが本番にリリースされないようにする必要があります。
- 可用性を最大化するためのリリース・プロセスの設計
デプロイメント中にリリース・プロセスでサービスをオフラインにする必要がある場合、アプリケーションはオンラインに戻るまで使用できません。プラットフォームのステージングおよび本番機能を利用します。可能な場合は、新しいデプロイメントをユーザーのサブセットにリリースして、過去1時間の障害を監視します。
- デプロイメントのロールバック計画があります。
最新の正常なバージョンに戻り、デプロイメントが失敗した場合の停止時間を最小限に抑えるロールバック・プロセスを設計します。デプロイメントの失敗時にロールバックを自動化すると、不要な停止時間を防ぐことができます。
- デプロイメントのログおよび監査
ステージングされたデプロイメント方法を使用する場合、複数のバージョンのアプリケーションが本番で実行されています。できるだけ多くのバージョン固有の情報を取得するための堅牢なロギング戦略を実装します。
- アプリケーションのリリース・プロセスの文書化
リリース・プロセスを明確に定義して文書化し、運用チーム全体が使用できるようにします。
アプリケーション・ヘルスのモニター
アプリケーションで監視およびアラートのベスト・プラクティスを実装して、障害を検出し、オペレータにアラートを送信して問題を修正できるようにします。
- サービス・コールに関するトレースの実装
ベースライン・パフォーマンス・データは、ユーザーに影響を与える前にパフォーマンスの問題をプロアクティブに識別するために使用できるトレンド・データを提供するのに役立ちます。
- 健全性プローブの実装
これらをアプリケーションの外部から定期的に実行して、アプリケーションの状態とパフォーマンスの低下を識別します。これらのプローブは、単なる静的ページ・テストではなく、全体的なアプリケーション・ヘルスを反映する必要があります。
- 長時間実行されるワークフローのチェック
問題を早期に捕捉すると、ワークフロー全体をロールバックしたり、複数の補正トランザクションを実行する必要性を最小限に抑えることができます。
- システム、アプリケーションおよび監査ログの保守
集中管理されたロギング・サービスを使用してログを格納します。
- 早期警告システムの設定
一時的な例外やリモート・コール待機時間など、アプリケーションのヘルスのキー・パフォーマンス・インジケータ(KPI)を識別し、それぞれに適切なしきい値を設定します。しきい値に達した場合、操作にアラートを送信します。
- 複数のオペレータによるアプリケーションの監視および手動リカバリ・ステップの実行のトレーニング
トレーニングを受けたオペレータが常に少なくとも1つアクティブになっていることを確認します。
障害の管理
リカバリ計画を作成し、データのリストア、ネットワーク停止、依存サービス障害およびリージョン全体のサービス中断に対応していることを確認します。リカバリ計画では、VM、ストレージ、データベースおよびその他のOCIサービスを検討します。
- OCIサポートの対話の計画
必要になる前に、OCIサポートに連絡するためのプロセスを確立します。
- 災害復旧計画の文書化とテスト
アプリケーション障害のビジネス・インパクトを反映する障害時リカバリ計画を作成します。リカバリ・プロセスをできるだけ自動化し、手動のステップを文書化します。障害時リカバリ・プロセスを定期的にテストして、計画を検証および改善します。
- DRコーディネーションに必要な主要な役割の理解
DR作業が適切に調整され、アプリケーションがビジネス価値に基づいて優先されることを確認します。
- アプリケーション障害の準備
自動的に処理されるフォルト、機能が低下するフォルト、アプリケーションが使用できなくなるフォルトなど、様々な障害に備えます。アプリケーションは、一時的な問題をユーザーに通知する必要があります。
- データ破損からのリカバリ
データ・ストアで障害が発生した場合は、ストアが再度使用可能になったとき(特にデータがレプリケートされた場合)に、データの不整合がないかどうかを確認します。バックアップからの破損データのリストア。
- ネットワークの停止からのリカバリ
キャッシュされたデータを使用して、アプリケーション機能を低下させてローカルで実行できる場合があります。そうでない場合は、アプリケーションの停止時間を検討するか、別のリージョンにフェイルオーバーしてください。接続がリストアされるまで、データを別の場所に格納します。
- 依存サービス障害からのリカバリ
まだ使用可能な機能およびアプリケーションの応答方法を決定します。
- リージョン全体のサービス中断からのリカバリ
リージョン全体のサービス中断はほとんどありませんが、特に重要なアプリケーションでは、サービス中断に対処するための戦略が必要です。アプリケーションを別のリージョンに再デプロイしたり、トラフィックを再分散できる場合があります。
- DRテストから学び、プロセスを改善
DRテスト中に発生した問題が取得され、それらの問題を修正する計画が将来のテストまたはフェイルオーバーで対処されていることを確認します。