모범 사례 10.2 - 가용성 및 용량 요구 사항에 적합한 아키텍처 선택

SAP on AWS를 배포하는 대부분의 고객의 요구 사항에 적합한 SAP 가용성에 대한 표준 아키텍처 패턴이 있습니다. 다음 제안 사항을 사용하여 가용성 및 용량 요구 사항을 최상으로 충족하는 패턴을 결정합니다. 비즈니스 요구 사항에 대해 각 장애 시나리오의 위험 및 영향을 평가합니다.

SAP의 가용성에 대한 추가 정보는 다음 백서에 나와 있습니다. Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침) .

제안 사항 10.2.1 – SAP 시스템에 필요한 모든 구성 요소 및 AWS 서비스를 식별

핵심(데이터베이스, 애플리케이션 서버, 중앙 서비스, 글로벌 파일 시스템)에서 시작하여 선택적 구성 요소(예: 웹 디스패처, SAProuter, 클라우드 커넥터)로 확장되는 SAP 시스템의 모든 필수 기술 구성 요소를 식별합니다. 이러한 구성 요소를 지원하는 데 필요한 AWS 서비스를 결정합니다.

제안 사항 10.2.2 – SLA, 내구성, 가용성 및 기록 데이터를 장애 발생 가능성에 대한 가이드로 사용

장애 발생 가능성은 주관적입니다. 게시된 서비스 수준 계약(SLA) 및 과거 성능은 향후 장애 발생 위험을 안내하는 데만 사용할 수 있습니다. 그러나 다양한 시나리오의 가정된 빈도는 여전히 유용한 데이터 포인트입니다. 통계적으로 1년에 한 번 발생할 가능성이 있는 장애가 아직 발생한 적이 없는 장애보다 설계 결정에 더 큰 영향을 미칠 수 있습니다.

다음 정보를 사용하여 서비스를 더 잘 이해할 수 있습니다.

도메인 이름 서비스, 로드 밸런서, 서버리스 기능 등 다른 지원 서비스의 장애 가능성도 평가해야 합니다.

자세한 내용은 Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침) 백서 에서 확인할 수 있습니다.

제안 사항 10.2.3 – 클러스터링, 복원력 및 로드 밸런싱에 대한 옵션을 평가

SAP 시스템은 가용성을 보장하기 위해 여러 메커니즘을 사용하여 여러 호스트에 분산할 수 있습니다. 예를 들어 클러스터링 솔루션을 사용하여 단일 장애 지점(예: SAP 데이터베이스 및 SAP 중앙 서비스)을 보호할 수 있습니다. SAP 애플리케이션 계층은 수평으로 크기를 조정할 수 있으며 로드 밸런싱을 사용하여 웹 디스패처를 고가용성으로 만들 수 있습니다.

제안 사항 10.2.4 - 가용 영역 내에서 EC2 인스턴스 패밀리의 가용성을 결정

일부 Amazon EC2 인스턴스 패밀리(예: X 및 U)는 일부 AZ에서 사용할 수 없습니다. AWS 계정 팀 또는 AWS Support에 문의하여 사용하려는 EC2 인스턴스 패밀리가 의도한 가용 영역에서 사용 가능한지 확인하세요. 논리적 AZ 식별자는 계정마다 다를 수 있습니다. 자세한 내용은 AWS 설명서를 참조하세요.

제안 사항 10.2.5 – 용량을 보장하기 위한 전략을 조사

용량을 보장할 수 있는 최선의 방법은 장애 발생 시 유사한 크기의 인스턴스를 사용할 수 있도록 하는 것입니다. 다른 전략으로는 클라우드 네이티브 옵션(예: 온디맨드 인스턴스, EC2 인스턴스 복구) 또는 공유 용량 재할당이 있습니다.

최소 2개의 AZ에서 SAP 단일 장애 지점을 지원하는 Amazon EC2 인스턴스의 용량을 약정하여 필요할 때 용량을 사용할 수 있도록 하는 것이 좋습니다.

EC2 용량은 영역 단위 예약 인스턴스 또는 온디맨드 용량 예약 을 사용하여 예약할 수 있습니다. 영역 단위 예약 인스턴스와 온디맨드 용량 예약은 모두 동일한 AWS 조직의 AWS 계정 간에 공유할 수 있으므로 심각한 장애(예: 전체 AZ 장애)가 발생한 경우 다른 환경의 희생 용량을 사용하는 접근 방식이 가능합니다.

용량 예약에 대한 추가 지침은 다음에서 확인할 수 있습니다.

제안 사항 10.2.6 – 여러 가용 영역에 걸쳐 VPC를 설계

초기 설계가 1~2개의 AZ만 사용하는 경우에도 여러 가용 영역에서 인스턴스를 프로비저닝할 수 있도록 VPC와 서브넷을 설계합니다. 그러면 설계에 복원력이 확보되고 서비스에 대한 연결 및 액세스를 사전에 확인하는 데 도움이 됩니다.