# 10 – 내결함 설계
**장애를 견디도록 SAP 워크로드를 설계하려면 어떻게 해야 합니까?** 비즈니스 요구 사항에서 거슬러 올라가며 SAP 인프라 및 데이터의 가용성 목표를 충족하기 위한 접근 방식을 정의합니다. 각 장애 시나리오에서 복원력 요구 사항, 허용 가능한 데이터 손실 및 평균 복구 시간(MTTR)은 구성 요소 및 해당 구성 요소가 지원하는 비즈니스 애플리케이션의 중요도에 비례해야 합니다. SAP 가용성을 위해 제공되는 아키텍처 패턴은 대부분의 고객 요구 사항을 충족하지만 정의하는 기준에 따라 조정할 수 있습니다. 이러한 기준에는 각 장애에 대해 인지된 위험 및 영향이 포함되며 비용 및 성능도 고려되어야 합니다. 모든 경우에서 초기 및 주기적 테스트를 사용하여 결정 사항을 검증합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-10.html)
자세한 내용은 다음 정보를 참조하세요.
+ AWS 설명서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) ( [장애 시나리오](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-failure-scenarios) 및 아키텍처 패턴 포함)
+ AWS 설명서: [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ AWS 설명서: [여러 데이터 센터 고가용 네트워크 연결](https://d0.awsstatic.com/aws-answers/AWS_Multiple_Data_Center_HA_Network_Connectivity.pdf)
+ SAP 설명서: [SAP HANA 시스템 아키텍처 개요](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/1b4477a539ab4b77a3bfe2a6835b5e0e.html)
# 모범 사례 10.1 - 비즈니스 요구 사항에 부합하는 SAP 워크로드 가용성 목표에 합의
가용성 목표에 대한 이해는 조직에 중요한 요소에 집중하기 위한 첫 번째 단계입니다. 그러면 아키텍처 패턴을 평가하는 데 사용할 수 있는 기준을 정의하는 데 도움이 됩니다.
**제안 사항 10.1.1 – SAP 애플리케이션 범위 및 상호 종속성을 식별**
AWS에서 배포한 또는 배포할 SAP 애플리케이션을 식별합니다. 위치에 관계없이 이러한 애플리케이션의 종속성을 이해합니다.
**제안 사항 10.1.2 – 장애 영향을 기반으로 시스템을 분류**
계획된 가용성 및 장애 위험에 따른 시스템 분류를 위한 공개 표준은 없습니다. 미션 크리티컬 또는 매우 중요와 같은 용어를 사용하여 시스템을 정의하면 패턴 정의, 애플리케이션 그룹화 식별 및 비용 정당화에 도움이 될 수 있습니다. 프로덕션 애플리케이션은 중단으로 인한 영향이 서로 다를 수 있습니다. 고려해야 할 요소는 다음과 같습니다.
+ 수익 창출 또는 수익 보고
+ 대외 또는 대내
+ 핵심 비즈니스 vs 기술 지원
+ 다른 시스템과 밀겹합 vs 소결합
비프로덕션 환경도 비즈니스를 간접적으로 지원하는 데 중요한 역할을 할 수 있습니다. 이들 역시 전송 경로(예: 일반 비즈니스 및 프로젝트)와 지원 역할(예: 개발, 단위 테스트, 프로덕션 복사본 및 교육)을 고려하여 프로젝트 단계 및 규모에 따라 분류해야 합니다.
**제안 사항 10.1.3 - 중단으로 인한 비즈니스 영향을 평가**
영향은 측정 가능하고 중단 기간을 고려해야 합니다. 영향 영역의 예로는 보건 및 안전, 재정, 법률, 규제 또는 브랜드가 있습니다.
**제안 사항 10.1.4 - 규정 준수 및 규제 요구 사항을 이해**
비즈니스 연속성을 보장하는 데 도움이 되도록 데이터 상주 및 위치 간 거리에 대한 규정 준수 또는 규정 요구 사항을 이해합니다.
**제안 사항 10.1.5 - 허용 가능한 최소 가동 시간(%)을 정의**
각 시스템 또는 시스템 그룹에 대해 비즈니스 요구 사항에 부합하는 허용 가능한 가용성 비율을 합의하고 문서화합니다. 이 맥락에서 다음 용어가 사용됩니다.
+ MTTR - 평균 복구 시간
+ RTO - 복구 시간 목표
+ RPO - 복구 시점 목표
용어에 대한 전체 설명은 Well-Architected Framework [안정성]: [가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 에서 찾을 수 있습니다. SAP의 안정성에 대한 추가 정보는 다음 백서에 나와 있습니다.
+ AWS 설명서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
# 모범 사례 10.2 - 가용성 및 용량 요구 사항에 적합한 아키텍처 선택
SAP on AWS를 배포하는 대부분의 고객의 요구 사항에 적합한 SAP 가용성에 대한 표준 아키텍처 패턴이 있습니다. 다음 제안 사항을 사용하여 가용성 및 용량 요구 사항을 최상으로 충족하는 패턴을 결정합니다. 비즈니스 요구 사항에 대해 각 장애 시나리오의 위험 및 영향을 평가합니다.
SAP의 가용성에 대한 추가 정보는 다음 백서에 나와 있습니다. [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) .
**제안 사항 10.2.1 – SAP 시스템에 필요한 모든 구성 요소 및 AWS 서비스를 식별**
핵심(데이터베이스, 애플리케이션 서버, 중앙 서비스, 글로벌 파일 시스템)에서 시작하여 선택적 구성 요소(예: 웹 디스패처, SAProuter, 클라우드 커넥터)로 확장되는 SAP 시스템의 모든 필수 기술 구성 요소를 식별합니다. 이러한 구성 요소를 지원하는 데 필요한 AWS 서비스를 결정합니다.
**제안 사항 10.2.2 – SLA, 내구성, 가용성 및 기록 데이터를 장애 발생 가능성에 대한 가이드로 사용**
장애 발생 가능성은 주관적입니다. 게시된 서비스 수준 계약(SLA) 및 과거 성능은 향후 장애 발생 위험을 안내하는 데만 사용할 수 있습니다. 그러나 다양한 시나리오의 가정된 빈도는 여전히 유용한 데이터 포인트입니다. 통계적으로 1년에 한 번 발생할 가능성이 있는 장애가 아직 발생한 적이 없는 장애보다 설계 결정에 더 큰 영향을 미칠 수 있습니다.
다음 정보를 사용하여 서비스를 더 잘 이해할 수 있습니다.
+ [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) 는 AWS에 영향을 줄 수 있는 이벤트가 발생할 경우 이를 알리고 수정 지침을 제공합니다.
+ [AWS 이벤트 사후 요약](https://aws.amazon.com/premiumsupport/technology/pes/) 은 AWS 서비스 가용성에 영향을 미치는 모든 주요 서비스 이벤트에 대해 제공됩니다.
+ [Amazon 컴퓨팅 서비스 수준 계약](https://aws.amazon.com/compute/sla/) 에는 컴퓨팅 서비스에 대한 SLA가 나열되어 있습니다.
+ AWS 설명서: [Amazon EBS 내구성 및 가용성](https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/durability-and-availability-3.html)
+ AWS 설명서: [Amazon EFS 데이터 보호 및 가용성](https://aws.amazon.com/efs/faq/#Data_protection_and_availability)
+ AWS 설명서: [AWS Direct Connect 복원력 권장 사항](https://aws.amazon.com/directconnect/resiliency-recommendation/?nc=sn&loc=4&dn=2)
도메인 이름 서비스, 로드 밸런서, 서버리스 기능 등 다른 지원 서비스의 장애 가능성도 평가해야 합니다.
자세한 내용은 [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침) 백서](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) 에서 확인할 수 있습니다.
**제안 사항 10.2.3 – 클러스터링, 복원력 및 로드 밸런싱에 대한 옵션을 평가**
SAP 시스템은 가용성을 보장하기 위해 여러 메커니즘을 사용하여 여러 호스트에 분산할 수 있습니다. 예를 들어 클러스터링 솔루션을 사용하여 단일 장애 지점(예: SAP 데이터베이스 및 SAP 중앙 서비스)을 보호할 수 있습니다. SAP 애플리케이션 계층은 수평으로 크기를 조정할 수 있으며 로드 밸런싱을 사용하여 웹 디스패처를 고가용성으로 만들 수 있습니다.
+ AWS 설명서: [Windows용 SAP NetWeaver 배포 및 운영 가이드 - 고가용성 시스템 배포](https://docs.aws.amazon.com/sap/latest/sap-netweaver/net-win-high-availability-system-deployment.html)
+ AWS 설명서: [SAP on AWS – 페이스메이커를 사용한 IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-ibmdb2/sap-ibm-pacemaker.html)
+ AWS 설명서: [고가용성을 위한 SQL Server 배포](https://docs.aws.amazon.com/sap/latest/sap-netweaver/sql-server-deployment-for-high-availability.html)
+ SAP 설명서: [High Availability Partners](https://wiki.scn.sap.com/wiki/display/SI/High+Availability+Partner+Information)
**제안 사항 10.2.4 - 가용 영역 내에서 EC2 인스턴스 패밀리의 가용성을 결정**
일부 Amazon EC2 인스턴스 패밀리(예: X 및 U)는 일부 AZ에서 사용할 수 없습니다. AWS 계정 팀 또는 AWS Support에 문의하여 사용하려는 EC2 인스턴스 패밀리가 의도한 가용 영역에서 사용 가능한지 확인하세요. 논리적 AZ 식별자는 계정마다 다를 수 있습니다. 자세한 내용은 AWS 설명서를 참조하세요.
+ AWS 설명서: [AWS 리소스의 AZ ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)
**제안 사항 10.2.5 – 용량을 보장하기 위한 전략을 조사**
용량을 보장할 수 있는 최선의 방법은 장애 발생 시 유사한 크기의 인스턴스를 사용할 수 있도록 하는 것입니다. 다른 전략으로는 클라우드 네이티브 옵션(예: 온디맨드 인스턴스, EC2 인스턴스 복구) 또는 공유 용량 재할당이 있습니다.
최소 2개의 AZ에서 SAP 단일 장애 지점을 지원하는 Amazon EC2 인스턴스의 용량을 약정하여 필요할 때 용량을 사용할 수 있도록 하는 것이 좋습니다.
EC2 용량은 [영역 단위 예약 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) 또는 [온디맨드 용량 예약](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-using.html) 을 사용하여 예약할 수 있습니다. 영역 단위 예약 인스턴스와 온디맨드 용량 예약은 모두 동일한 AWS 조직의 AWS 계정 간에 공유할 수 있으므로 심각한 장애(예: 전체 AZ 장애)가 발생한 경우 다른 환경의 희생 용량을 사용하는 접근 방식이 가능합니다.
용량 예약에 대한 추가 지침은 다음에서 확인할 수 있습니다.
+ AWS 설명서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
**제안 사항 10.2.6 – 여러 가용 영역에 걸쳐 VPC를 설계**
초기 설계가 1\$12개의 AZ만 사용하는 경우에도 여러 가용 영역에서 인스턴스를 프로비저닝할 수 있도록 VPC와 서브넷을 설계합니다. 그러면 설계에 복원력이 확보되고 서비스에 대한 연결 및 액세스를 사전에 확인하는 데 도움이 됩니다.
# 모범 사례 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)
# 모범 사례 10.4 - 비즈니스 요구 사항에 기반한 일련의 기준에 따라 설계 검증
비즈니스 요구 사항에 따라 장애 위험, 비즈니스에 미치는 영향, 허용 가능한 절충을 균형 있게 고려하여 일련의 기준을 설정합니다. 이러한 기준을 사용하여 설계를 검증하고 필요에 따라 조정합니다.
**제안 사항 10.4.1 – 중단이 비즈니스에 초래하는 비용을 평가**
AWS 서비스 또는 SAP 구성 요소의 장애는 복원력 및 복구 전략에 따라 SAP 시스템에 다르게 영향을 미칩니다. 장애 유형에 따라 중단 기간(RTO) 및 잠재적 데이터 손실(RPO)이 결정됩니다.
각 장애에 대해 중단 위험과 비즈니스 비용을 평가하세요. 예를 들어 영향을 받을 수익 창출 프로세스가 있습니까? 시스템 사용 중단과 관련된 시간당 비용은 얼마입니까?
**제안 사항 10.4.2 – 아키텍처 비용을 평가**
SAP 환경에서 AWS 월별 청구서의 최대 요소는 일반적으로 Amazon EC2 및 스토리지 관련 서비스입니다. 안정성 요구 사항을 충족하는 최상의 아키텍처를 선택할 수 있도록 비용 영향을 이해합니다. 주요 비용 요소는 다음과 같습니다.
+ 하드웨어 사용률이 극대화되지 않은 배포 패턴
+ 이중화된 데이터 복제
+ 운영 체제 라이선스 비용
+ 클러스터링 소프트웨어 라이선스 비용
+ 유지 관리, 테스트 및 숙련된 리소스와 관련된 비용
자세한 내용은 [비용 최적화]: [비용 최적화 모범 사례](cost-optimization.md) 를 참조하세요.
**제안 사항 10.4.3 – 프레임워크의 다른 원칙에 대해 설계를 평가**
안정성은 단독으로 설계할 수 없고 AWS Well-Architected Framework의 나머지 원칙에 대해 평가해야 합니다. 이를 평가하기 위해 다음과 같은 질문을 할 수 있습니다.
+ 운영 우수성 - 솔루션을 관리할 수 있는 경험과 기술이 있습니까?
+ 보안 - 복제, 복구 등의 과정에서 데이터가 보호되고 있습니까?
+ 성능 - 복제 또는 백업 작업이 사용자 성능에 영향을 줍니까?
+ 비용 최적화 - 솔루션 비용이 가정된 위험과 일치합니까?