View a markdown version of this page

모범 사례 17.2 - SAP 애플리케이션 아키텍처 패턴의 비용 특성 평가 - SAP Lens

모범 사례 17.2 - SAP 애플리케이션 아키텍처 패턴의 비용 특성 평가

SAP 환경의 아키텍처를 개발할 때 인프라 구성 요소의 크기 및 위치 외에 구성 요소 수에 따른 비용도 고려합니다. 솔루션의 비즈니스 요구 사항을 설정하고, 위험 및 최적화 기회를 인식함으로써 상당한 비용 절감을 실현할 수 있습니다.

제안 사항 17.2.1 – 선택한 SAP 설치 패턴을 검토

각 SAP 애플리케이션에 대해 독립 실행형, 분산형 또는 고가용성(HA)과 같은 배포 패턴을 정의합니다. 비즈니스 요구 사항을 충족하기 위해 비용 및 안정성 특성이 최적의 균형을 이룬 아키텍처 패턴을 선택합니다. 유용한 접근 방식 하나는 비즈니스 중단 비용을 수량화한 후 거슬러 올라가며 작업하는 것입니다. 가용성에 영향을 미치는 개별 장애의 위험과 해당 위험을 축소하는 비용의 균형을 맞춥니다.

또한 아키텍처에 적절한 크기 조정이 가능한 유연성이 있는지 확인합니다. 운영 체제 라이선싱, 스토리지, 단일 호스트에서 여러 애플리케이션 서버 관리를 통해 비용을 절감할 수 있습니다. 애플리케이션 계층의 경우 지원되는 인스턴스 패밀리에서 CPU 및 메모리를 미세 단위로 지정한(가격은 거의 정비례) 인스턴스 크기를 사용할 수 있습니다. 더 작은 규모의 여러 인스턴스를 배포하면 인스턴스 재사용 및 워크로드 기반 크기 조정에 대한 옵션을 사용할 수 있습니다.

논리적 그룹화를 평가하고 구성 요소, 시스템(SID) 또는 환경을 결합하는 효과를 고려합니다. 이러한 활동으로 인해 운영 복잡성이 증가하고 안정성이 감소합니까?

제안 사항 17.2.2 – 멀티 테넌시 사용 또는 단일 호스트에서 다중 데이터베이스 호스팅에 대한 예외를 평가

대부분의 데이터베이스에서 각 시스템의 크기를 독립적으로 조정하고 해당 시스템의 요구 사항에 맞게 유연한 인스턴스 크기 조정을 활용합니다. 경우에 따라 해당 권장 사항에서 벗어나는 것이 비용 측면에서 합리적일 수 있습니다. 예를 들면 다음과 같습니다.

  • HANA 기반 구성 요소에 사용 가능한 최소 EC2 인스턴스 크기보다 적은 메모리가 필요한 경우 SAP HANA 멀티 테넌트 데이터베이스 컨테이너를 사용하는 것을 고려합니다. 컴퓨팅 리소스를 다른 구성 요소와 함께 호스트하면 효율적으로 사용할 수 있습니다.

  • Oracle 및 SQL Server를 포함한 관계형 데이터베이스용 코어 기반 데이터베이스 라이선싱 모델

  • 가동 시간 요구 사항 및 버전 종속성을 위해 밀결합되었거나 밀결합될 수 있는 애플리케이션. 여기에는 관리 도구(예: Solution Manager 및 SAP HANA Cockpit)와 일부 SAP NetWeaver Gateway 배포 옵션(Fiori 및 ECC)이 포함됩니다.

제안 사항 17.2.3 – 복원력 및 확장성이 필요하지 않은 시스템에 대한 단일 호스트 설치 패턴의 사용을 평가

개별 애플리케이션 또는 환경의 경우 단일 호스트 모델의 장점을 고려해야 합니다. 이를 통해 운영 체제 비용, 스토리지 복제, 소프트웨어 라이선스 비용 및 관리 서비스 비용을 절감할 수 있습니다. 특히 비프로덕션 환경에 대한 일반적인 아키텍처 옵션은 다음과 같습니다.

  • 데이터베이스, 애플리케이션 및 SAP 중앙 서비스를 공동 호스팅

  • 데이터베이스를 분리(데이터베이스 라이선싱을 최소화하기 위해). 자세한 내용은 [비용 최적화]: 모범 사례 18.3 - 라이선싱 영향 및 최적화 옵션 평가 를 참조하세요.

  • 애플리케이션과 SAP 중앙 서비스를 결합

제안 사항 17.2.4 – 가장 비용 효율적으로 요구 사항을 충족하는 리전을 선택

SAP 리전의 주요 선택 기준은 근접성, 데이터 상주 및 서비스 가용성입니다. 리전을 선택할 수 있는 배포의 경우 각 AWS 리전은 현지 시장 상황에 따라 가격이 책정되며, 따라서 AWS 서비스 가격이 리전마다 다르다는 점을 인식해야 합니다. 가격 차이와 잠재적 영향을 검토합니다.

제안 사항 17.2.5 – 장애 발생 시 크기를 조정할 수 있는 아키텍처를 사용

클라우드에서는 복구 메커니즘과 탄력성 덕분에 이중화 리소스를 활성화할 필요 없이 100% 용량으로 설계가 가능합니다. 비즈니스 요구 사항에 따라 보다 유연한 RTO 또는 RPO가 허용되는 경우 다음을 고려합니다.

데이터베이스:

  • 복구 지점 목표에서 허용하는 경우 프라이머리 데이터베이스 노드의 변경 사항을 적용하기 위해 동등한 컴퓨팅 용량이 필요하지 않은 세컨더리 또는 스탠바이 데이터베이스 노드를 고려합니다. 복구 시간 영향을 감안하여, 세컨더리 데이터베이스에 더 작거나 공유된 인스턴스를 배포하고 필요할 때만 확장할 경우의 비용 이점을 고려합니다. 더 작은 인스턴스를 사용하면 기본 시스템 인스턴스와 보조 시스템 인스턴스 간에 1:1 관계가 유지됩니다. 공유 인스턴스 아키텍처는 복제되지 않는 시스템 데이터베이스가 있는 세컨더리 데이터베이스를 단일 인스턴스로 풀링합니다. 장애 발생 시 복제되지 않는 시스템을 중지해야 전환이 가능합니다. 그러면 RTO가 증가합니다.

  • 세컨더리 SAP HANA 데이터베이스에 더 작은 인스턴스를 사용하는 경우 스탠바이의 더 작은 메모리 공간을 수용하고 비용을 절감하기 위해 메모리 미리 로드를 끕니다. SAP 도움말 문서 Secondary System Usage(보조 시스템 사용량)에 메모리 요구 사항이 추정되어 있습니다.

  • 복구 시간 목표 및 복원력 요구 사항에서 허용하는 경우 다중 AZ 스토리지(예: Amazon FSx, Amazon EFS 또는 Amazon S3)를 사용하는 데이터 및 로그 백업 접근 방식을 고려합니다. 이러한 접근 방식을 사용하면 이중화 보조 리소스 없이 데이터를 지리적으로 보호할 수 있습니다. 장애가 발생한 경우 온디맨드로 보조 리소스를 생성하고 교차 위치 백업 및 로그 스토리지에서 신속하게 복원할 수 있습니다.

애플리케이션:

  • AWS 인스턴스 복구 는 CloudWatch 경보를 사용하여 Amazon EC2 인스턴스를 모니터링합니다. 기본 하드웨어 장애로 인해 인스턴스가 손상된 경우 자동으로 인스턴스를 복구합니다. 해당 장애 시나리오가 충분한 보호를 제공하는지 평가합니다.

  • 애플리케이션 서버를 신속하게 재생성해야 하는 시나리오의 경우 옵션으로는 프로비저닝되었지만 실행되지 않는 EC2 인스턴스, 템플릿 AMI, 공통 스테이징 서버를 사용하는 스토리지 복제, 코드형 인프라(IaC) 등이 있습니다.

제안 사항 17.2.6 – 장애 발생 시 컴퓨팅 용량 최소 비용을 고려

여러 가용 영역에 SAP 구성 요소를 분산하면 장애 발생 시 용량 예약에 발생하는 비용을 절감할 수 있습니다. 여러 가용 영역에 구성 요소를 분산하면 워크로드의 일부가 이미 지리적으로 분산되어 있으므로 초과 용량이 필요하지 않습니다. 이는 AZ 장애 발생 시 영향 범위를 최소화합니다.

예를 들어 가용 영역 손실이 포함된 장애 시나리오에 대한 가용성 요구 사항이 100% 용량인 경우 두 개의 가용 영역에 200% 용량을 프로비저닝하는 대신 세 개의 가용 영역에 150% 용량을 프로비저닝합니다.

그림: 정상 작동 중인 150% 용량의 3개 가용 영역 아키텍처의 예

제안 사항 17.2.7 – 스토리지만 기반으로 하는 복구 옵션 사용을 평가

일반적으로 AWS에서는 가장 광범위한 장애 시나리오로부터 보호하기 위해 스토리지 복제보다 데이터베이스 복제를 권장합니다. 애플리케이션 계층 또는 덜 중요한 인스턴스의 경우 컴퓨팅 필요 없이 스토리지 복제를 사용하는 DR 솔루션을 사용하면 비용을 절감할 수 있습니다. 또한 변경 사항 관리와 관련된 복잡성도 최소화됩니다.

제안 사항 17.2.8 – 네트워킹 관련 비용을 이해

SAP 고객은 온프레미스 네트워크와 Amazon VPC 간의 보안 연결이 필요한 경우가 많습니다. 적절한 크기로 조정된 Direct Connect, VPN 연결 또는 둘 다를 사용하면 비용을 최소화하면서 성능 및 안정성 요구 사항을 충족할 수 있습니다.

데이터 전송 비용은 리전, VPC 및 가용 영역 설계의 영향을 받습니다. 안정성 저하 없이 SAP 구성 요소의 배포 및 복제를 최적화할 수 있는 방법을 평가합니다.

예를 들어 대량의 데이터를 전송하는 두 시스템이 서로 다른 위치에 있는 경우 데이터 전송 비용에 미치는 영향을 고려해야 합니다.

추가 지침은 Well-Architected Framework 검토의 비용 원칙에서 찾을 수 있습니다 (Plan for Data Transfer - Cost Optimization Pillar(데이터 전송 계획 - 비용 최적화 원칙) 참조) .