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