# ベストプラクティス 10.3 – 重要な SAP データの可用性を確保するアプローチを定義する SAP アプリケーション用のビジネスデータは、主にデータベースに保存されますが、バイナリ (実行可能ファイル、ライブラリ、スクリプトなど)、構成、インターフェイスの場合はファイルベースのデータを含むこともあります。選択したアプローチの耐久性、整合性、および復旧オプションを調べて、データの重要性や許容可能データ損失率 (RPO) に合うことを確認する必要があります。 **提案 10.3.1 – MTTR 要件を評価して、要件を満たす方法を特定する** [信頼性] [提案 10.1.5 – 最小許容稼働率を定義する](best-practice-10-1.md) で、各アプリケーションの MTTR 要件を定義します。障害のリスクとシステムの可用性を保護するメカニズムを評価した後は、要件を満たせることを確認し、各障害シナリオで予想される MTTR を文書化します。コスト、複雑さ、または整合性の点で妥協が必要な場合は、ビジネス所有者と協議して、合意を得ます。 **提案 10.3.2 – バックアップからの復旧が必要になる障害シナリオを判断する** バックアップは、多くの場合、可用性を確保または復旧するための 2 次的なメカニズムですが、ほとんどのアーキテクチャは何らかの形でバックアップに依存します。以下は、分析の参考になる障害シナリオの例です。シナリオ、分類、および影響の詳細度は、要件とアーキテクチャによって異なります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-10-3.html) **提案 10.3.3 – データのレプリケーションが必要な場所を決める** データのレプリケーションは、同じデータのコピーを複数の場所に置くことによって信頼性を高めるために使用され、多くの場合、RPO が低いシステムの要件です。可用性または復旧のためにレプリケーションが必要かどうかを判断するときには、サービスがゾーン別 (Amazon EC2 および Amazon EBS とそれらがサポートするデータベースなど) かリージョン別 (共有ストレージと Amazon S3 など) かを考慮してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-10-3.html) [AWS DataSync](https://aws.amazon.com/datasync/) を使用して、必要な場合、 [Amazon EFS](https://aws.amazon.com/premiumsupport/knowledge-center/datasync-transfer-efs-cross-region/) と [Amazon FSx](https://aws.amazon.com/blogs/aws/aws-datasync-update-support-for-amazon-fsx-for-windows-file-server/) の両方をリージョンにまたがって保護できます。 [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) は、AWS アカウント間も含め、アベイラビリティーゾーンまたはリージョン間でインスタンスを継続的に複製します。 **Amazon S3 レプリケーション** バックアップやその他のオブジェクトストレージは、Amazon S3 に保存されることがあり、以下を使用して複製できます。 [Amazon S3 レプリケーション](https://aws.amazon.com/s3/features/replication/) . **提案 10.3.4 – 一貫した構成データとバイナリを確保する戦略を立てる** 予測可能な動作と障害後のテスト済みセットアップを確保するためには、一貫性のある構成データとバイナリが重要です。これには、オペレーティングシステムのパッケージ、アプリケーションのパラメータ、およびクラスター構成が含まれます。回復力のためのもの (追加のアプリケーションサーバー、セカンダリデータベースノードなど) も含め、アプリケーションのすべてのインスタンスについて整合性を確保する方法を決めます。 Amazon EFS、Amazon FSx、および Amazon S3 は、共有バイナリまたは構成を集中管理できる耐久性の高い場所を提供します。 [運用上の優秀性] [ベストプラクティス 2.1 - バージョン管理と設定管理を使用する](best-practice-2-1.md) の柱のバージョン管理と構成管理のメカニズムを参照してください。 **提案 10.3.5 – データ整合性のための包括的アプローチを持つ** 重要な SAP データの整合性を確保するためのアプローチは、単一のデータセットに注目するだけでなく、データセット内とシステム内およびデータセット間とシステム間の依存性も考慮する必要があります。例えば、プルの元になるソースシステムではなく SAP BW システムを復旧する必要がある場合、変更ポインターにはどのような影響が予想され、整合性のある復旧を確保するためにどのようなメカニズムが存在しているでしょうか? **提案 10.3.6 – データを再生または再送信できるインターフェイスの戦略を立てる** システム間のデータ交換について、統合が疎結合かどうかと、ソースまたはターゲットでデータを再生または再送信できるかどうかを判断します。シナリオを中断したり、停止中にキャッシュしたりできるキューイング機能があるかどうかをレビューします。 **提案 10.3.7 – データバンカーの使用を評価する** 偶発的な削除や悪意ある行動などの状況により、オンラインデータが使用不能または入手不能になるような障害シナリオでは、データの保護または復旧可能性を確保するために異なるアプローチが必要になることがあります。 ネットワーク分離とアクセスコントロールをカバーするセキュリティフレームワークでの予防が最良の防御ですが、復旧と回復のコンテキストで影響を考慮する必要があります。 保持期間が限られた *書き込み専用* バックアップアカウントを使用するのが、このようにまれですが潜在的に高い影響力を持つシナリオでの一般的なアプローチです。 + SAP Lens [セキュリティ]: [ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する](best-practice-8-3.md)