# 17 – SAP 아키텍처 패턴에서 비용 효율성 평가
**SAP 아키텍처 패턴 평가에 비용 고려 사항을 어떻게 통합합니까?** 아키텍처에 대한 결정을 내릴 때 설계 고려 사항의 일부로 비용 영향을 완전히 이해해야 합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-17.html)
# 모범 사례 17.1 - SAP 관리형 서비스 제품 사용 평가
AWS 공동 책임 모델에 따라 SAP on AWS 워크로드를 관리할 책임은 고객에게 있습니다. 선택적으로 서비스 공급 업체를 사용하여 SAP on AWS 워크로드를 관리할 수 있습니다. 서비스 공급 업체를 평가할 때 선행 및 지속적인 비용 관리에 대한 책임이 적절히 위임되어야 하고 지속적인 프로세스로 처리되어야 합니다.
여러 AWS 파트너가 SAP 환경 배포 및 운영을 위한 서비스를 제공합니다. 제공하는 서비스의 범위 및 성숙도는 파트너에 따라 다릅니다. 이러한 유형의 서비스는 예를 들어 중앙 집중식 지원 또는 자동화된 배포 서비스와 같이 효율성을 제공할 수 있습니다. 이러한 서비스는 전체 비용을 절감할 수 있으며 특정 비즈니스 요구 사항에 따라 평가해야 합니다. 파트너에 대해 [SAP 컨설팅 컴피턴시](https://aws.amazon.com/sap/partner-solutions/) 및 AWS 파트너 네트워크(APN) 등 AWS 컴피턴시를 평가합니다.
**제안 사항 17.1.1 – 비용 관리와 관련된 역할 및 책임을 이해**
관리형 서비스 제품마다 인프라, 라이선싱 및 서비스 비용 모델이 다릅니다. 비용 관리 책임이 어디에 있는지 결정합니다. 이 과정에서 다음과 같은 질문을 할 수 있습니다.
+ 공급 업체 비용이
+ 인프라 지출의 백분율을 기준으로 합니까?
+ 합의된 총 소유 비용(TCO)을 기준으로 합니까?
+ 크게 3단계(소규모, 중규모, 대규모)로 구분됩니까? 비용을 제어하고 이해할 수 있도록 적절한 변경 제어 프로세스가 마련되어 있습니까?
+ 인프라 비용의 가시성 및 투명성이 충분합니까?
+ 비용 거버넌스가 혁신과 유연성을 제한합니까?
**제안 사항 17.1.2 – 모든 당사자와 비용 관리 및 최적화 접근 방식에 동의**
사용 가능한 다양한 관리형 서비스 제품을 평가할 때 관리형 서비스 파트너의 비용 관리 접근 방식을 이해합니다. 조직의 지속적인 비용 최적화를 위해 어떻게 협력할 수 있습니까?
이 평가에는 주기적 검토 프로세스가 포함되어야 합니다. 또한 양쪽 당사자가 모두 재정적 이익을 얻을 수 있도록 파트너가 소유권을 갖도록 장려하는 공유 보상 모델과 같은 인센티브의 혜택을 받을 수 있습니다.
# 모범 사례 17.2 - SAP 애플리케이션 아키텍처 패턴의 비용 특성 평가
SAP 환경의 아키텍처를 개발할 때 인프라 구성 요소의 크기 및 위치 외에 구성 요소 수에 따른 비용도 고려합니다. 솔루션의 비즈니스 요구 사항을 설정하고, 위험 및 최적화 기회를 인식함으로써 상당한 비용 절감을 실현할 수 있습니다.
**제안 사항 17.2.1 – 선택한 SAP 설치 패턴을 검토**
각 SAP 애플리케이션에 대해 독립 실행형, 분산형 또는 고가용성(HA)과 같은 배포 패턴을 정의합니다. 비즈니스 요구 사항을 충족하기 위해 비용 및 안정성 특성이 최적의 균형을 이룬 아키텍처 패턴을 선택합니다. 유용한 접근 방식 하나는 비즈니스 중단 비용을 수량화한 후 거슬러 올라가며 작업하는 것입니다. 가용성에 영향을 미치는 개별 장애의 위험과 해당 위험을 축소하는 비용의 균형을 맞춥니다.
또한 아키텍처에 적절한 크기 조정이 가능한 유연성이 있는지 확인합니다. 운영 체제 라이선싱, 스토리지, 단일 호스트에서 여러 애플리케이션 서버 관리를 통해 비용을 절감할 수 있습니다. 애플리케이션 계층의 경우 지원되는 인스턴스 패밀리에서 CPU 및 메모리를 미세 단위로 지정한(가격은 거의 정비례) 인스턴스 크기를 사용할 수 있습니다. 더 작은 규모의 여러 인스턴스를 배포하면 인스턴스 재사용 및 워크로드 기반 크기 조정에 대한 옵션을 사용할 수 있습니다.
논리적 그룹화를 평가하고 구성 요소, 시스템(SID) 또는 환경을 결합하는 효과를 고려합니다. 이러한 활동으로 인해 운영 복잡성이 증가하고 안정성이 감소합니까?
+ 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)
+ SAP Lens [안정성]: [안정성 설계 원칙](reliability.md)
+ AWS Well-Architected Framework [안정성]: [안정성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
**제안 사항 17.2.2 – 멀티 테넌시 사용 또는 단일 호스트에서 다중 데이터베이스 호스팅에 대한 예외를 평가**
대부분의 데이터베이스에서 각 시스템의 크기를 독립적으로 조정하고 해당 시스템의 요구 사항에 맞게 유연한 인스턴스 크기 조정을 활용합니다. 경우에 따라 해당 권장 사항에서 벗어나는 것이 비용 측면에서 합리적일 수 있습니다. 예를 들면 다음과 같습니다.
+ HANA 기반 구성 요소에 사용 가능한 최소 EC2 인스턴스 크기보다 적은 메모리가 필요한 경우 [SAP HANA 멀티 테넌트 데이터베이스 컨테이너](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/623afd167e6b48bf956ebb7f2142f058.html)를 사용하는 것을 고려합니다. 컴퓨팅 리소스를 다른 구성 요소와 함께 호스트하면 효율적으로 사용할 수 있습니다.
+ Oracle 및 SQL Server를 포함한 관계형 데이터베이스용 코어 기반 데이터베이스 라이선싱 모델
+ 가동 시간 요구 사항 및 버전 종속성을 위해 밀결합되었거나 밀결합될 수 있는 애플리케이션. 여기에는 관리 도구(예: Solution Manager 및 SAP HANA Cockpit)와 일부 SAP NetWeaver Gateway 배포 옵션(Fiori 및 ECC)이 포함됩니다.
**제안 사항 17.2.3 – 복원력 및 확장성이 필요하지 않은 시스템에 대한 단일 호스트 설치 패턴의 사용을 평가**
개별 애플리케이션 또는 환경의 경우 단일 호스트 모델의 장점을 고려해야 합니다. 이를 통해 운영 체제 비용, 스토리지 복제, 소프트웨어 라이선스 비용 및 관리 서비스 비용을 절감할 수 있습니다. 특히 비프로덕션 환경에 대한 일반적인 아키텍처 옵션은 다음과 같습니다.
+ 데이터베이스, 애플리케이션 및 SAP 중앙 서비스를 공동 호스팅
+ 데이터베이스를 분리(데이터베이스 라이선싱을 최소화하기 위해). 자세한 내용은 [비용 최적화]: [모범 사례 18.3 - 라이선싱 영향 및 최적화 옵션 평가](best-practice-18-3.md) 를 참조하세요.
+ 애플리케이션과 SAP 중앙 서비스를 결합
**제안 사항 17.2.4 – 가장 비용 효율적으로 요구 사항을 충족하는 리전을 선택**
SAP 리전의 주요 선택 기준은 근접성, 데이터 상주 및 서비스 가용성입니다. 리전을 선택할 수 있는 배포의 경우 각 AWS 리전은 현지 시장 상황에 따라 가격이 책정되며, 따라서 AWS 서비스 가격이 리전마다 다르다는 점을 인식해야 합니다. 가격 차이와 잠재적 영향을 검토합니다.
**제안 사항 17.2.5 – 장애 발생 시 크기를 조정할 수 있는 아키텍처를 사용**
클라우드에서는 복구 메커니즘과 탄력성 덕분에 이중화 리소스를 활성화할 필요 없이 100% 용량으로 설계가 가능합니다. 비즈니스 요구 사항에 따라 보다 유연한 RTO 또는 RPO가 허용되는 경우 다음을 고려합니다.
데이터베이스:
+ 복구 지점 목표에서 허용하는 경우 프라이머리 데이터베이스 노드의 변경 사항을 적용하기 위해 동등한 컴퓨팅 용량이 필요하지 않은 세컨더리 또는 스탠바이 데이터베이스 노드를 고려합니다. 복구 시간 영향을 감안하여, 세컨더리 데이터베이스에 더 작거나 공유된 인스턴스를 배포하고 필요할 때만 확장할 경우의 비용 이점을 고려합니다. 더 작은 인스턴스를 사용하면 기본 시스템 인스턴스와 보조 시스템 인스턴스 간에 1:1 관계가 유지됩니다. 공유 인스턴스 아키텍처는 복제되지 않는 시스템 데이터베이스가 있는 세컨더리 데이터베이스를 단일 인스턴스로 풀링합니다. 장애 발생 시 복제되지 않는 시스템을 중지해야 전환이 가능합니다. 그러면 RTO가 증가합니다.
+ 세컨더리 SAP HANA 데이터베이스에 더 작은 인스턴스를 사용하는 경우 스탠바이의 더 작은 메모리 공간을 수용하고 비용을 절감하기 위해 메모리 미리 로드를 끕니다. SAP 도움말 문서 [Secondary System Usage(보조 시스템 사용량)](https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.05/en-US/9d62b8108063497f9d6aab08902b2e04.html)에 메모리 요구 사항이 추정되어 있습니다.
+ SUSE 설명서: [SAP HANA 시스템 복제 크기 조정 - 성능 최적화 시나리오 \$1 SUSE](https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-CostOpt-12/index.html)
+ 복구 시간 목표 및 복원력 요구 사항에서 허용하는 경우 다중 AZ 스토리지(예: Amazon FSx, Amazon EFS 또는 Amazon S3)를 사용하는 데이터 및 로그 백업 접근 방식을 고려합니다. 이러한 접근 방식을 사용하면 이중화 보조 리소스 없이 데이터를 지리적으로 보호할 수 있습니다. 장애가 발생한 경우 온디맨드로 보조 리소스를 생성하고 교차 위치 백업 및 로그 스토리지에서 신속하게 복원할 수 있습니다.
+ SAP on AWS 블로그: [스냅샷을 사용하여 SAP ASE 데이터베이스용 자동 복구 절차를 생성하는 방법](https://aws.amazon.com/blogs/awsforsap/how-to-use-snapshots-to-create-an-automated-recovery-procedure-for-sap-ase-databases/)
애플리케이션:
+ [AWS 인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 는 CloudWatch 경보를 사용하여 Amazon EC2 인스턴스를 모니터링합니다. 기본 하드웨어 장애로 인해 인스턴스가 손상된 경우 자동으로 인스턴스를 복구합니다. 해당 장애 시나리오가 충분한 보호를 제공하는지 평가합니다.
+ 애플리케이션 서버를 신속하게 재생성해야 하는 시나리오의 경우 옵션으로는 프로비저닝되었지만 실행되지 않는 EC2 인스턴스, 템플릿 AMI, 공통 스테이징 서버를 사용하는 스토리지 복제, 코드형 인프라(IaC) 등이 있습니다.
**제안 사항 17.2.6 – 장애 발생 시 컴퓨팅 용량 최소 비용을 고려**
여러 가용 영역에 SAP 구성 요소를 분산하면 장애 발생 시 용량 예약에 발생하는 비용을 절감할 수 있습니다. 여러 가용 영역에 구성 요소를 분산하면 워크로드의 일부가 이미 지리적으로 분산되어 있으므로 초과 용량이 필요하지 않습니다. 이는 AZ 장애 발생 시 영향 범위를 최소화합니다.
예를 들어 가용 영역 손실이 포함된 장애 시나리오에 대한 가용성 요구 사항이 100% 용량인 경우 두 개의 가용 영역에 200% 용량을 프로비저닝하는 대신 세 개의 가용 영역에 150% 용량을 프로비저닝합니다.
![\[SAP production account with three availability zones, each hosting application and database instances.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/images/example-three-availability-zone-architecture.png)
**제안 사항 17.2.7 – 스토리지만 기반으로 하는 복구 옵션 사용을 평가**
일반적으로 AWS에서는 가장 광범위한 장애 시나리오로부터 보호하기 위해 스토리지 복제보다 데이터베이스 복제를 권장합니다. 애플리케이션 계층 또는 덜 중요한 인스턴스의 경우 컴퓨팅 필요 없이 스토리지 복제를 사용하는 DR 솔루션을 사용하면 비용을 절감할 수 있습니다. 또한 변경 사항 관리와 관련된 복잡성도 최소화됩니다.
+ AWS 설명서: [CloudEndure 재해 복구 - Amazon Web Services](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ SAP 설명서: [SAP 애플리케이션의 CloudEndure Disaster Recovery](https://d1.awsstatic.com/products/CloudEndure/Disaster_Recovery_for_SAP_Applications.pdf)
+ AWS 설명서: [자동 백업을 다른 AWS 리전에 복제 - Amazon Relational Database Service(Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html)
**제안 사항 17.2.8 – 네트워킹 관련 비용을 이해**
SAP 고객은 온프레미스 네트워크와 Amazon VPC 간의 보안 연결이 필요한 경우가 많습니다. 적절한 크기로 조정된 Direct Connect, VPN 연결 또는 둘 다를 사용하면 비용을 최소화하면서 성능 및 안정성 요구 사항을 충족할 수 있습니다.
데이터 전송 비용은 리전, VPC 및 가용 영역 설계의 영향을 받습니다. 안정성 저하 없이 SAP 구성 요소의 배포 및 복제를 최적화할 수 있는 방법을 평가합니다.
예를 들어 대량의 데이터를 전송하는 두 시스템이 서로 다른 위치에 있는 경우 데이터 전송 비용에 미치는 영향을 고려해야 합니다.
+ AWS 설명서: [EC2 온디맨드 인스턴스 요금 – Amazon Web Services](https://aws.amazon.com/ec2/pricing/on-demand/)
+ AWS 설명서: [아키텍처 패턴 - 일반 SAP 가이드](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html)
추가 지침은 Well-Architected Framework 검토의 비용 원칙에서 찾을 수 있습니다 [(Plan for Data Transfer - Cost Optimization Pillar(데이터 전송 계획 - 비용 최적화 원칙) 참조)](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/plan-for-data-transfer.html) .
# 모범 사례 17.3 - 환경별로 비용 최적화된 설계 결정을 내리기 위한 비즈니스 요구 사항 이해
각 시스템 또는 환경의 비용을 각기 다른 특성에 따라 개별적으로 최적화합니다. 비즈니스 요구 사항에 부합하는 용량, 성능, 안정성 및 운영 시간을 고려합니다. 최종 사용자의 경험이나 비즈니스 프로세스에 덜 중요한 환경 또는 애플리케이션의 경우 스토리지, 컴퓨팅 및 운영 시간을 최소화하여 비용을 절감합니다. 구성 축소에 따른 비용 절감과 테스트 또는 지원을 위한 운영 요구 사항 간의 균형을 유지합니다.
**제안 사항 17.3.1 – 비프로덕션 환경에 프로덕션 데이터의 전체 복사본이 필요한지 평가**
비프로덕션에 프로덕션 데이터의 전체 복사본을 유지하면 스토리지 및 컴퓨팅 비용에 큰 영향을 미칩니다. 테스트 요구 사항을 계속 충족하면서 프로덕션 데이터의 복사본 수를 최소화하는 것을 고려합니다. 비프로덕션 환경 데이터 스토리지의 비용을 최소화하기 위한 옵션은 다음과 같습니다.
+ 개발 및 테스트 시스템에 더 적은 스토리지 용량을 사용합니다.
+ 데이터 슬라이싱 도구를 사용하여 비프로덕션 시스템에서 테스트 데이터를 더 작은 하위 집합으로 분할합니다.
+ 임시 프로덕션 사본의 사용을 고려합니다. 이러한 복사본은 온디맨드로 생성한 다음 비즈니스 요구 사항 또는 테스트가 통과한 후 신속하게 폐기 또는 아카이브할 수 있습니다.
+ 비프로덕션 시스템에서 SAP HANA 데이터베이스에 대한 SAP 권장 사항인 50% 작업 메모리가 필요한지 평가합니다.
**제안 사항 17.3.2 – 비프로덕션 환경에 항상 프로덕션 환경과 동일한 성능이 필요한지 평가**
비프로덕션 시스템 및 일부 지원 시스템은 사용자 집합이 작거나, 훨씬 적은 트랜잭션 볼륨을 처리하거나, 유연한 응답 시간 요구 사항이 있을 수 있습니다. 다음 사항을 고려하세요.
+ 더 작은 EC2 인스턴스 유형을 사용하여 워크로드에 대한 SAP 애플리케이션 성능 표준(SAPS)을 낮춥니다.
+ 더 적은 수의 애플리케이션 서버를 사용합니다.
+ 더 저렴한 Amazon EBS 스토리지 유형을 사용합니다(예: `io2` 대신 `gp3` ).
+ 비프로덕션 시스템 볼륨에 감소된 성능 특성을 사용합니다(예: 10,000 IOPS 대신 3,000 IOPS).
+ 클라우드의 탄력성 덕분에 로드 또는 크기 조정 테스트와 같이 프로덕션과 유사한 성능이 필요한 비프로덕션 테스트 리소스를 확장할 수 있습니다.
**제안 사항 17.3.3 – 비프로덕션 환경에 프로덕션 환경과 동일한 운영 시간이 필요한지 평가**
테스트, 교육 및 샌드박스 시스템과 같은 비프로덕션 환경은 프로덕션에 비해 운영 시간이 짧을 수 있습니다. 표준 시간대와 지원 팀 근무 시간을 고려하여 모든 시스템이 연중무휴 24시간 필요한지 여부를 결정합니다. 이 정보를 사용하여 가장 저렴한 가격 모델을 선택합니다.
예를 들어 온디맨드 요금 모델(약 23% 가동 시간)을 사용하여 주당 40시간 동안 SAP 교육 시스템을 실행하는 것이 3년 예약 인스턴스 또는 Savings Plan을 사용하여 100%로 상시 실행하는 것보다 저렴합니다.
**제안 사항 17.3.4 – 비프로덕션 환경에 프로덕션 환경과 동일한 안정성이 일관되게 필요한지 평가**
각 시스템의 개별 안정성 요구 사항에 부합하는 가장 비용 효율적인 아키텍처를 선택합니다. [안정성]: [모범 사례 10.1 - 비즈니스 요구 사항에 부합하는 SAP 워크로드 가용성 목표에 합의](best-practice-10-1.md) 를 참조하세요. 추가 지침은 AWS Well-Architected Framework의 [안정성 원칙 ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 에서 찾을 수 있습니다.
프로덕션 환경과 유사한 아키텍처가 테스트 전용으로 존재하는 경우 프로덕션을 미러링해야 하는 빈도를 고려합니다. 비프로덕션 환경에서 안정성 또는 성능 테스트를 위해 데이터베이스 고가용성이 필요한 경우 이러한 테스트 기간 외에 보조 인스턴스를 종료하거나 축소하여 비용을 절감할 수 있습니다.
자동화를 사용하고 항상 프로덕션과 같은 성능이 필요하지 않은 환경에 대해 온디맨드 요금을 사용하여 비용 이점을 실현할 수 있습니다.
**제안 사항 17.3.5 – 지원 및 레거시 시스템을 포함한 비핵심 시스템의 비즈니스 요구 사항을 평가**
환경이 참조용으로만 존재하거나 비즈니스 역할이 덜 중요한 경우 핵심 프로덕션 시스템과 비교하여 필요한 가동 시간, 성능 및 안정성 요구 사항을 평가합니다.
예를 들어 레거시 ERP 시스템은 이전 애플리케이션 전환 또는 비즈니스 구조 조정에서 참조용으로 유지해야 할 수 있습니다. 이 시스템의 비용은 필요할 때만 EC2 인스턴스를 실행하고 Amazon EBS 스토리지에 대해서만 비용을 지불하여 최적화할 수 있습니다. 보다 비용 효율적인 솔루션은 Amazon S3 및 Amazon S3 Glacier로 백업을 통해 시스템을 아카이브하는 것입니다.
# 모범 사례 17.4 - SAP 구성 요소에 대한 크기, 세분 수준 및 사용 가능한 최신 EC2 인스턴스 검토
더 작은 EC2 인스턴스가 SAP 워크로드에서 비용 유연성이 더 큽니다. 컴퓨팅을 사용하지 않을 때 종료하거나 피크 로드 중에만 확장할 수 있는 수평 확장 옵션을 제공하기 때문입니다. 애플리케이션 계층에서 일관된 EC2 인스턴스 크기를 채택하면 모든 워크로드에서 예약 인스턴스 및 Savings Plans 약정의 이점을 극대화하는 데 도움이 됩니다. 사용 가능한 최신 AWS SAP 인증 인스턴스를 고려합니다. 각 구성 요소에 대한 운영 영향, 라이선스 비용, 지원, 공유 및 재사용 가능성도 평가해야 합니다.
**제안 사항 17.4.1 – 유연성을 제공하기 위해 더 작은 애플리케이션 서버를 여러 개 배포하는 경우의 비용 이점을 평가**
많은 SAP 워크로드의 경우 애플리케이션 서버를 변경할 수 없도록 설계할 수 있습니다. 기본 유닛을 복제하여 수평으로 확장되는 표준 애플리케이션 서버 구성이 있으면 일관된 반복 가능한 유닛에 대한 옵션이 확보됩니다. 장점에는 재사용 가능성, 컴퓨팅 사용률, 예약 및 자동화가 있습니다. 운영 체제 라이선싱, 스토리지 복제 및 관리 비용과 같은 유닛별 요구 사항을 평가에 고려해야 합니다.
다음 사항을 고려하세요.
+ SAP on AWS 블로그: [DevOps for SAP – Driving Innovation and Lowering Costs(SAP용 DevOps - 혁신을 촉진하고 비용을 절감)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/) .
+ SAP on AWS 블로그: [AWS를 사용하여 SAP Application Auto Scaling 활성화](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
**제안 사항 17.4.2 - 지원되는 경우 SAP HANA 스케일 아웃 구성의 비용 이점을 평가**
SAP OLAP 워크로드는 [스케일 업 및 스케일 아웃](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/a165e192ba374c2a8b17566f89fe8419.html) 구성 모두에서 배포할 수 있습니다. SAP는 운영 복잡성을 줄이기 위해 스케일 아웃 전에 스케일 업할 것을 권장합니다. 하지만 스케일 아웃 구현은 상당한 컴퓨팅(SAPS)이 필요한 대규모 분석 또는 네이티브 SAP HANA 워크로드에 적용될 수 있습니다.
일부 경우에는 S/4HANA가 스케일 아웃 구성도 지원하지만 제한 사항이 있습니다. 다음 SAP Note를 참조하세요. [2408419 - SAP S/4HANA - Multi-Node Support](https://launchpad.support.sap.com/#/notes/2408419) [SAP 포털 액세스 권한 필요].
스케일 업과 스케일 아웃을 비교할 때 다음을 고려하세요.
+ [인증 EC2 인스턴스 크기](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23;v:105) (스케일 업 및 스케일 아웃에 사용 가능)
+ 각 인스턴스 패밀리의 EC2 메모리 GiB당 비용. 큰 EC2 인스턴스는 일반적으로 작은 인스턴스보다 GiB당 비용이 더 높습니다.
+ 스케일 아웃 배포에서 가중되는 데이터 배포 관리의 복잡성 및 운영 오버헤드. 다음 SAP Note를 참조하세요. [2081591 - FAQ: SAP HANA Table Distribution](https://launchpad.support.sap.com/#/notes/2081591) [SAP 포털 액세스 권한 필요]
# 모범 사례 17.5 - 비용 효율성을 개선하기 위해 온디맨드 용량 사용을 고려
온디맨드 요금 모델은 단축된 운영 시간, 단기 프로젝트, 실험 또는 단기간의 용량 확장(예: 성능 테스트)이 필요한 SAP 워크로드에 적합합니다. SAP 아키텍처에서 온디맨드 요금을 사용할 수 있는 영역을 결정합니다.
**제안 사항 17.5.1 – 연중무휴 24시간 운영 시간이 필요하지 않은 SAP 시스템에 온디맨드 사용을 평가**
온디맨드 요금 모델과 다른 요금 모델 간의 손익분기점을 기반으로 ([안정성]: [모범 사례 18.1 - Amazon EC2에 사용할 수 있는 결제 및 약정 옵션 이해](best-practice-18-1.md) 참조) 온디맨드가 최저 비용을 제공하는지 평가합니다. 이 평가의 일환으로 전체 Savings Plan 약정을 고려합니다.
일반적인 사용 사례에는 시험 업그레이드 및 개념 증명(POC)과 같이 연장된 업무 시간 또는 단기 비즈니스 실험 외에는 필요하지 않은 비프로덕션 시스템이 포함됩니다.
+ SAP on AWS 블로그: [AWS Systems Manager를 사용하여 분산 SAP HANA 시스템 자동 시작 또는 중지](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
**제안 사항 17.5.2 - 피크 로드에 대한 예약 또는 동적 크기 조정 옵션을 평가**
온디맨드 용량은 SAP 워크로드에서 일반적으로 짧은 기간 동안 용량 요구 사항이 급증하는 피크에 사용됩니다. 다음 사항을 고려하세요.
+ 기간, 월말, 연말 또는 계절성 피크와 같은 알려진 사용량 패턴 피크에 대해 일정 기반 SAP 애플리케이션 서버 크기 조정을 사용합니다.
+ 피크가 확실하지 않고 실시간 사용자 로드를 기반으로 크기를 조정해야 하는 경우 애플리케이션 계층 동적 크기 조정을 사용합니다. SAP를 인식하고 필요한 거버넌스 및 제어를 제공하는 메커니즘을 탐색합니다.
**참고:** 애플리케이션 계층 동적 크기 조정을 평가할 때 SAP 구성 요소의 상태 유지 특성으로 인해 SAP 애플리케이션 서버가 종료되는 경우 사용자 연결 및 배치 작업에 미치는 영향을 고려하세요. AWS, SAP 및 APN 파트너 개발 도구가 이 요구 사항을 해결하는 데 도움이 될 수 있습니다.
+ AWS 설명서: [Systems Manager Automation 작업 참조](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)
+ SAP 설명서: [SAP Landscape Management](https://www.sap.com/products/landscape-management.html)
+ SAP on AWS 블로그: [AWS를 사용하여 SAP Application Auto Scaling 활성화](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
# 모범 사례 17.6 - 공유 서비스 및 솔루션의 비용 이점과 영향 평가
여러 SAP 시스템에 동일한 기능이 필요한 경우 기존 솔루션을 사용하거나, 구성 요소를 공유하거나, 둘 다 사용하여 관리 및 비용을 중앙 집중화하는 것이 비용 효율적 옵션이 될 수 있습니다. 모니터링, 백업 및 연결은 AWS 계정 경계 내에서 또는 전용 계정에서 관리할 수 있는 일반적인 기능입니다. 표준화, 중복 감소, 복잡성 감소는 비용을 낮춥니다.
비용 절감을 위해 리소스를 공유하면서도 적절한 격리를 유지하고 운영에 영향을 미칠 수 있는 종속성이 부과되지 않는 적절한 방법을 모색합니다.
**제안 사항 17.6.1 – 각 공유 서비스에 대해 일대일 설정과 일대다 설정의 비용 이점을 비교**
SAP 환경의 표준 패턴은 다중 계정 전략의 일부로 비프로덕션 워크로드와 프로덕션 워크로드를 별도의 계정으로 분리하는 것입니다. 이것은 일부 서비스에서 논리적 경계가 될 수 있습니다. 세분화를 적용하는 관리 경계 및 리전, AZ, VPC 또는 계정 간의 데이터 전송 비용 영향을 포함하여 각 시나리오의 복잡성과 운영 비용을 고려합니다.
다중 계정 설계에서 일부 AWS 서비스는 비용을 절감하기 위해 중앙에서 호스트하고 허브 앤 스포크 설계의 여러 애플리케이션 및 계정에서 액세스할 수 있습니다. 이러한 서비스에는 다음이 포함됩니다.
+ 스포크 VPC의 모든 아웃바운드 트래픽에 대한 NAT 게이트웨이 포함 전용 VPC
+ 로드 밸런서 및 웹 디스패처를 위한 중앙 집중식 모델
+ 전송 및 기타 파일 공유 필요를 충족하기 위한 공유 Amazon EFS 또는 Amazon FSx
**제안 사항 17.6.2 – 기존 서비스를 재사용하여 비용을 절감할 수 있는 영역을 평가**
이 제안 사항은 여러 수준에 해당됩니다.
+ AWS가 서비스를 제공하는 경우 이러한 서비스는 종종 오버헤드를 최소화하며 사용량 기반 요금제를 사용합니다. 예를 들면 Amazon EFS, AWS Backint for SAP HANA, AWS Backup이 있습니다.
+ 비즈니스에는 운영 일관성 및 규모의 경제를 위해 사용해야 하는 일부 기능(예: 엔터프라이즈 백업)에 대한 전사적 표준이 있을 수 있습니다.
+ APN 파트너 솔루션은 특정 비즈니스 요구 사항에 따라 AWS Marketplace 또는 BYOL(기존 보유 라이선스 사용)을 통해 제공될 수 있습니다.
+ 라이선스 포함 AWS Marketplace 머신 이미지는 선결제 비용을 줄이는 데 도움이 될 수 있습니다. 이 시나리오에서는 라이선싱 제한을 고려해야 합니다. 다른 인스턴스 유형으로의 이식성을 제한하여 솔루션 유연성에 영향을 줄 수 있기 때문입니다.
**제안 사항 17.6.3 – 자체 구축, 구매 및 오픈 소스 접근 방식 사용의 영향을 이해**
AWS 솔루션이든 APN 파트너 솔루션이든 자체 구축, 오픈 소스, 기성품은 정도의 차이가 있습니다. 예로는 백업 솔루션, 고가용성(HA) 솔루션 및 공유 스토리지 솔루션이 있습니다.
자체 구축 접근 방식 또는 오픈 소스 솔루션 사용을 고려할 때 다음 사항을 고려해야 합니다.
+ 서비스 수준 계약
+ 구축 및 유지 관리에 필요한 기술
+ 서비스 중단이 비즈니스에 미치는 영향
또한 특정 비즈니스 요구 사항과 각 솔루션이 제공하는 기능을 기반으로 구매하려는 솔루션에 사용 가능한 상용 모델을 평가해야 합니다. 예를 들어 사용 권한 대 사용 건당 요금 지불, 그러한 요금이 계산되는 방식과 같은 상용 모델의 조건을 고려합니다.
# 모범 사례 17.7 - 자동화의 비용 이점 평가
AWS에서 자동화를 도입함으로써 얻을 수 있는 이점에는 효율성 및 생산성 향상이 포함될 수 있으며, 이는 조직의 비용 절감으로 이어질 수 있습니다.
**제안 사항 17.7.1 – 빌드 자동화 효율을 평가**
코드형 인프라를 사용한 빌드 프로세스 자동화는 출시 시간 및 생산성을 향상시킬 수 있는 비용 효율성이 있습니다. DevOps 모범 사례가 제공할 수 있는 품질, 일관성, 반복성 및 복구 가능성의 이점은 자동화 개발에 필요한 더 높은 선행 투자와 비교해야 합니다.
AWS Professional Services 또는 AWS 파트너와 협력하면 전문가의 경험을 활용하여 전반적인 노력을 줄일 수 있습니다.
AWS Launch Wizard for SAP는 자동화를 통해 SAP 배포를 가속화할 수 있습니다. SAP 모범 사례에 따라 AWS 기반 SAP HANA 애플리케이션의 크기 조정, 구성 및 배포를 안내하는 서비스입니다. 이 서비스는 무료이고 AWS가 지원을 제공합니다.
+ AWS 설명서: [코드형 인프라](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ AWS 설명서: [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ SAP on AWS 블로그: [AWS for SAP DevOps](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**제안 사항 17.7.2 – 운영에 대한 자동화 효율을 평가**
AWS 및 서드 파티 도구를 사용하여 운영 실행 및 모니터링을 자동화할 수 있는 방법을 조사하여 반복 가능한 작업의 비용과 수동 작업을 줄입니다. 다음 사항을 고려하세요.
+ AWS 서비스: [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
추가 지침은 [운영 우수성] [모범 사례 3.6 - 자동화를 사용하여 SAP 환경 작업 수행](best-practice-3-6.md) 을 참조하세요.