# 모범 사례 10.3 - 중요 SAP 데이터의 가용성을 보장할 수 있도록 접근 방식 정의 SAP 애플리케이션의 비즈니스 데이터는 주로 데이터베이스에 저장되지만 바이너리(예: 실행 파일, 라이브러리, 스크립트), 구성 및 인터페이스에 대한 파일 기반 데이터도 포함될 수 있습니다. 선택한 접근 방식은 내구성, 일관성 및 복구 옵션이 데이터 중요도 및 허용 가능한 데이터 손실(RPO) 수준에 부합하는지 검토해야 합니다. **제안 사항 10.3.1 – MTTR 요구 사항을 평가하고 그 충족 방법을 식별** [안정성] [제안 사항 10.1.5 - 허용 가능한 최소 가동 시간(%)을 정의](best-practice-10-1.md) 에서 각 애플리케이션의 MTTR 요구 사항을 정의합니다. 장애 위험과 시스템 가용성을 보호하기 위한 메커니즘을 평가한 후에는 요구 사항이 충족될 수 있는지 확인하고 각 장애 시나리오에 대한 MTTR 기대치를 문서화합니다. 비용, 복잡성 또는 일관성에 대한 절충이 필요한 경우 비즈니스 소유자와 상의하여 합의를 도출합니다. **제안 사항 10.3.2 – 백업으로부터 복구가 필요한 장애 시나리오를 결정** 백업은 가용성을 보장 또는 복구하기 위한 보조 메커니즘인 경우가 많지만 대부분의 아키텍처는 어느 정도 백업에 의존합니다. 다음은 분석을 안내하는 데 사용할 수 있는 장애 시나리오의 예입니다. 시나리오 세분 수준, 분류 및 영향은 요구 사항 및 아키텍처에 따라 달라집니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/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/ko_kr/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)