Azure Cosmos DB for NoSQL の回復性に関する推奨事項
この記事には、Azure Cosmos DB for NoSQL の回復性を実現するための推奨事項が含まれています。 推奨事項の多くには、準拠していないリソースの識別に役立つ補助的な Azure Resource Graph (ARG) クエリが含まれています。
回復性に関する推奨事項の影響マトリックス
各推奨事項は、次の影響マトリックスに従ってマークされます:
| Image | 影響 | 説明 |
|---|---|---|
|
高 | 直ちに修正が必要です。 |
|
Medium | 3 から 6 か月以内に修正してください。 |
|
低 | 確認が必要です。 |
回復性に関する推奨事項の概要
可用性
高可用性のために少なくとも 2 つのリージョンを構成する
Cosmos DB でセカンダリ リージョンを有効にして、より高い SLA を実現することが重要です。 そうしてもダウンタイムは発生せず、マップ上のピンを選択するのと同じくらい簡単です。 厳密な整合性を利用する Cosmos DB インスタンスでは、1 つのリージョンで障害が発生した場合に書き込み可用性を維持するように少なくとも 3 つのリージョンを構成する必要があります。
潜在的な利点: SLA と回復性を強化します。
詳細情報:「Cosmos DB for NoSQL の信頼性 (高可用性)」
Resources
| where type =~ 'Microsoft.DocumentDb/databaseAccounts'
| where
array_length(properties.locations) < 2 or
(array_length(properties.locations) < 3 and properties.consistencyPolicy.defaultConsistencyLevel == 'Strong')
| project recommendationId='cosmos-1', name, id, tags
障害復旧
単一の書き込みリージョンを持つ複数リージョンアカウントのサービスマネージド フェールオーバーを有効にする
Cosmos DB は、高いアップタイムと回復性を誇ります。 それでも、問題が発生する可能性があります。 サービス マネージド フェールオーバーでは、1 つのリージョンがダウンした場合でも、Cosmos DB は次に使用可能なリージョンに自動的に切り替わるので、ユーザー操作は必要ありません。
Resources
| where type =~ 'Microsoft.DocumentDb/databaseAccounts'
| where
array_length(properties.locations) > 1 and
tobool(properties.enableAutomaticFailover) == false and
tobool(properties.enableMultipleWriteLocations) == false
| project recommendationId='cosmos-2', name, id, tags
複数リージョンの書き込み機能を評価する
複数リージョンの書き込み機能を使用すると、複数のリージョン間で高可用性のアプリケーションを設計できますが、一貫性の要件と競合の解決には注意が必要です。 不適切なセットアップでは、可用性が低下し、未処理の競合が原因でデータが破損する可能性があります。
潜在的な利点: 高可用性を強化します。
参考資料:
Resources
| where type =~ 'Microsoft.DocumentDb/databaseAccounts'
| where
array_length(properties.locations) > 1 and
properties.enableMultipleWriteLocations == false
| project recommendationId='cosmos-3', name, id, tags
データの持続性の要件を反映した適切な整合性モードを選択する
グローバルに分散されたデータベースでは、整合性レベルは、リージョンの障害時のデータの持続性に影響します。 復旧計画のデータ損失許容度について理解しておいてください。 より強力なものが必要がない限りはセッション整合性を使用します。書き込みの待機時間が長くなり、読み取り専用の停止による書き込みリージョンへの影響が発生する可能性があります。
潜在的な利点: データの持続性と回復を強化します。
詳細情報:「Azure Cosmos DB の整合性レベル」
継続的バックアップ モードを構成する
Cosmos DB のバックアップは常にオンであり、データ の問題に対する保護を提供します。 Microsoft サポートに連絡する必要があり、復元時間が長くなる定期モードとは異なり、連続モードでは、障害が起こる前の時点までのセルフ サービス復元が可能になります。
潜在的な利点: より高速なセルフ サービスのデータ復元。
詳細情報:「Azure Cosmos DB のポイントインタイム リストア機能を使用した継続的バックアップ」
Resources
| where type =~ 'Microsoft.DocumentDb/databaseAccounts'
| where
properties.backupPolicy.type == 'Periodic' and
properties.enableMultipleWriteLocations == false and
properties.enableAnalyticalStorage == false
| project recommendationId='cosmos-5', name, id, tags
システムの効率性
クエリ結果が完全にドレインされていることを確認する
Cosmos DB には 4 MB の応答制限があり、その結果、大規模なクエリまたはパーティションにまたがるクエリのページ分割された結果が得られます。 各ページには可用性が表示され、次への継続トークンが提供されます。 完了するまですべてのページを走査するには、コード内の while ループが必要です。
潜在的な利点: データの取得効率を最大化します。
詳細情報:「Azure Cosmos DB for NoSQL の改ページ処理」。
クライアントでシングルトン パターンを維持する
接続がクライアントに関連付けられているため、各アカウントとアプリケーションに対して SDK クライアントの単一インスタンスを使用することが重要です。 コンピューティング環境には開いている接続に制限があり、超過した場合は接続に影響します。
潜在的な利点: 接続と効率を最適化します。
詳細情報:「Azure Cosmos DB SDK を使用した回復性があるアプリケーションの設計」。
アプリケーションの回復性
クライアントに再試行ロジックを実装する
Cosmos DB SDK では、再試行によって多くの一時的なエラーが自動的に管理されます。 それでも、SDK が一律に対処できない特定のケースを対象とする追加の再試行ポリシーをアプリケーションで実装することが重要です。そうすることでより堅牢なエラー処理が保証されます。
潜在的な利点: エラー処理の回復性を強化します。
詳細情報:「Azure Cosmos DB SDK を使用した回復性があるアプリケーションの設計」。
監視
Cosmos DB の正常性を監視し、アラートを設定する
Azure Cosmos DB リソースの可用性と応答性を監視し、ワークロードに対してアラートを設定することをお勧めします。 これにより、予期しないイベントの処理にプロアクティブな状態を維持できます。
潜在的な利点: プロアクティブな問題管理。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示