# 비용 최적화
비용 최적화 원칙에는 전체 수명 주기 동안 시스템을 개선하고 구체화하는 지속적인 프로세스가 포함됩니다. 이 최적화는 최초 개념 증명 설계부터 프로덕션 워크로드 운영까지 지속되어야 합니다. 올바른 솔루션 및 가격 책정 모델을 선택한 다음 비즈니스 성과를 달성하고 비용을 최소화할 수 있는 비용 인식 시스템을 구축합니다. 시간이 지남에 따라 비용 최적화를 실현하려면 삭제 또는 축소할 수 있는 데이터, 인프라 리소스 또는 분석 작업을 식별해야 합니다.
# 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) 을 참조하세요.
# 18 – 비용 효율성을 위한 SAP 컴퓨팅 리소스 평가
**SAP 워크로드에 대한 컴퓨팅 및 스토리지 옵션을 어떻게 평가합니까?** SAP를 구현하거나 AWS로 마이그레이션할 때 비용 목표를 충족하기 위해 SAP 워크로드에 대한 비용 효율적인 EC2 인스턴스 및 스토리지 솔루션을 선택해야 합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-18.html)
# 모범 사례 18.1 - Amazon EC2에 사용할 수 있는 결제 및 약정 옵션 이해
온디맨드 요금과 비교하여 상당한 할인을 제공하는 예약 인스턴스 및 Savings Plans 사용을 고려합니다. 1년 및 3년 약정 기간과 전체 선결제, 부분 선결제, 선결제 없음의 세 가지 결제 옵션으로 사용할 수 있습니다.
**제안 사항 18.1.1 – 요금 모델 간 손익분기점을 이해**
[예약 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html) 는 표준 예약 인스턴스(온디맨드 요금에서 최대 72% 할인)와 컨버터블 예약 인스턴스(온디맨드 요금에서 최대 54% 할인)로 구분됩니다. [Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#plan-types) 는 Compute Savings Plans(온디맨드 요금에서 최대 66% 할인)과 EC2 Instance Savings Plans(온디맨드 요금에서 최대 72% 할인)으로 구분됩니다.
Amazon EC2 온디맨드 시간당 요금 대비 실현할 수 있는 할인율은 다음 요인에 따라 달라집니다.
+ 선택한 약정 기간
+ 선택한 결제 옵션
+ 선택한 예약 인스턴스 또는 Savings Plan 유형
+ 인스턴스 패밀리
메모리 최적화 인스턴스 패밀리(예: `X1` 및 `X1e` )는 약정에 따른 절감 효과가 더 크므로 SAP, 특히 SAP HANA 워크로드의 경우 요금 옵션을 이해하는 것이 중요합니다.
AWS 요금 계산기의 고급 옵션을 사용하여 손익분기점을 계산합니다. 이 계산기에서 사용되는 가정을 알고 있어야 합니다. 이를 설명하기 위해 다음 공식을 사용하여 각 인스턴스 패밀리에 대해 예약 인스턴스 또는 Savings Plan을 사용하는 것이 온디맨드를 사용하는 것보다 낮은 TCO를 제공하는 지점을 계산하는 예를 알아보겠습니다.
*(약정의 유효 시간당 요금 / 온디맨드의 시간당 요금) \$1 730시간*
각 [RI 약정 기간과 유형](https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/) 및 각 [Savings Plan 약정 기간과 유형](https://aws.amazon.com/savingsplans/pricing/) 에 대한 유효 시간당 요금을 참조하세요. 다양한 손익분기점을 보여주는 다음 예를 비교합니다.
*예 1: 버지니아 북부(us-east-1)에서 M5 패밀리의 경우 선결제 없는 3년 표준 예약 인스턴스 또는 EC2 Savings Plan이 더 낮은 TCO를 제공하는 손익분기점은 월 315시간(월요일부터 금요일까지 하루 약 16시간)입니다.*
*예 2: 버지니아 북부(us-east-1)에서 X1 인스턴스 패밀리의 경우 선결제 없는 3년 표준 예약 인스턴스 또는 EC2 Savings Plan이 더 낮은 TCO를 제공하는 손익분기점은 월 235시간(월요일부터 금요일까지 하루 약 12시간)입니다.*
포괄적인 지침( [비용 관리](https://aws.amazon.com/aws-cost-management/) 및 Well-Architected Framework [비용 최적화 원칙](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) )을 사용합니다. 다음 [SAP on AWS 요금 가이드](https://docs.aws.amazon.com/sap/latest/general/sap-on-aws-pricing-guide.html) 에서도 AWS에서 실행되는 SAP 워크로드와 관련된 지침을 제공합니다. 비용을 분석할 때 모든 AWS 요금(AWS 중국 리전 제외)은 미국 달러(USD)로 표시되지만 지불 시 대체 통화를 선택할 수 있습니다. 다음을 참조하세요. [현재 AWS에서 지원되는 통화](https://aws.amazon.com/premiumsupport/knowledge-center/supported-aws-currencies/) .
+ AWS 설명서: [Savings Plans - Compute Savings Plans 및 예약 인스턴스](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris)
+ AWS 설명서: [Savings Plans - 플랜 유형](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#plan-types)
+ AWS 설명서: [예약 인스턴스의 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html)
**제안 사항 18.1.2 – SAP와 관련된 각 요금 모델의 고려 사항을 이해**
시간당 요금 할인 외에도 예약 인스턴스 및 Savings Plans의 다른 이점도 고려해야 합니다. 이 AWS 설명서: [Savings Plans 및 RI 비교표](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris) 에는 예약 인스턴스와 Savings Plans가 비교되어 있습니다.
[영역 단위 예약 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) 는 특정 가용 영역 내에서 용량 예약을 제공하는 데 사용할 수 있습니다. Savings Plans는 용량 예약을 제공하지 않지만 [온디맨드 용량 예약](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 과 결합하여 영역 단위 예약 인스턴스와 동일한 기능을 제공할 수 있습니다. 용량 전략에 대한 자세한 내용은 [안정성]: [모범 사례 10.2 - 가용성 및 용량 요구 사항에 적합한 아키텍처 선택](best-practice-10-2.md) 을 참조하세요.
[Amazon EC2 스팟 인스턴스](https://aws.amazon.com/ec2/spot) 를 사용하면 AWS 클라우드에서 사용하지 않는 EC2 용량을 활용할 수 있습니다. 스팟 인스턴스는 온디맨드 인스턴스 가격 대비 최대 90% 할인된 가격으로 이용할 수 있습니다. AWS는 AWS에 용량이 필요할 경우 2분 전에 통지하여 스팟 인스턴스를 회수할 수 있습니다. 그러므로 스팟 인스턴스는 일반적으로 SAP 워크로드를 실행하는 데 적합하지 않습니다.
또한 [온디맨드 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) 를 사용하는 경우 시스템이 시작될 때마다 애플리케이션 성능에 미치는 영향 외에도 필요한 운영 시간을 기반으로 SAP 시스템 및 기본 EC2 인스턴스를 중지 및 시작하는 경우 이것이 미치는 추가적인 운영상의 영향을 고려해야 합니다.
**제안 사항 18.1.3 – 예약 인스턴스 및 Savings Plans 약정의 통합 청구 및 공유를 위한 기업 전략을 평가**
[통합 결제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 를 사용하면 예약 인스턴스 및 Savings Plans가 AWS 조직 내 모든 계정의 사용량에 적용됩니다. 조직의 관리 계정은 관리 계정을 포함하여 해당 조직의 모든 계정에 대해 예약 인스턴스 할인 및 Savings Plans 할인 공유를 해제할 수 있습니다. 즉, 예약 인스턴스 및 Savings Plans 할인은 공유가 해제된 계정 간에 공유되지 않습니다. 예약 인스턴스 또는 Savings Plans 할인을 공유하려면 두 계정 모두 공유가 설정되어 있어야 합니다. 이 기본 설정은 영구적이 아니며 언제라도 변경할 수 있습니다.
+ AWS 설명서: [AWS Organizations 통합 결제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
+ AWS 설명서: [예약 인스턴스 및 Savings Plans 할인 공유 해제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html)
약정 공유 전략을 결정하는 핵심 요소는 조직에서 채택한 전반적인 [AWS 계정 전략](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 입니다. SAP 워크로드가 자체 전용 AWS 계정에서 실행되는지 아니면 AWS에서 호스트되는 다른 워크로드와 함께 실행되는지도 고려해야 합니다. 예약 인스턴스 및 Savings Plans 할인이 조직의 통합 결제에 어떻게 적용되는지 이해하려면 다음을 참조하세요.
+ AWS 설명서: [통합 결제 이해](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/con-bill-blended-rates.html#Instance_Reservations)
SAP Note: [1656250 - SAP on AWS: Support prerequisites(1656250 - SAP on AWS: 지원 사전 조건)](https://launchpad.support.sap.com/#/notes/1656250) [SAP 포털 액세스 권한 필요]에 자세히 설명된 대로 SAP on AWS는 유료 [AWS Support 계약](https://aws.amazon.com/premiumsupport/) (예: Business Support 또는 Enterprise Support)이 체결된 경우에만 지원됩니다. 비용 및 요구 사항에 따라 적절한 Support 플랜을 결정합니다.
+ AWS 설명서: [AWS Support 플랜 비교](https://aws.amazon.com/premiumsupport/plans/)
AWS는 조직 내의 각 멤버 계정에 대해 독립적으로 Support 비용을 계산합니다.
# 모범 사례 18.2 - EC2 인스턴스 선택을 위한 주요 고려 사항으로 비용을 사용
워크로드에 적합한 SAP 인증 EC2 인스턴스를 선택하면 비용을 최적화할 수 있습니다. 가능한 경우 데이터에 기반한 의사 결정을 내릴 수 있도록 각 시스템에 대한 철저한 분석을 수행합니다. 일반 지침은 Well-Architected Framework [Cost Optimization Pillar - Cost-Effective Resources(비용 최적화 원칙 - 비용 효율적 리소스)](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-cost-effective-resources.html)에서 찾을 수 있습니다.
**제안 사항 18.2.1 – 리전에서 사용 가능한 최신 세대 인스턴스를 선택**
최신 세대의 Amazon EC2 인스턴스는 최저의 비용으로 더 나은 성능을 제공하는 경우가 많으므로 배포 시나리오에 대해 사용 가능하고 인증된 경우 사용해야 합니다.
+ AWS 설명서: [SAP용 Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/)
+ AWS 설명서: [리전별 인스턴스 유형 가용성](https://aws.amazon.com/sap/instance-types/#region-availability)
**참고**
일부 Amazon EC2 인스턴스 패밀리(예: `X1` 및 고용량 메모리)는 리전 내의 일부 가용 영역에서 사용하지 못할 수 있습니다. 계획 단계에서 SAP 워크로드에 필요한 인스턴스 유형이 대상 가용 영역에서 사용 가능한지 확인해야 합니다.
**제안 사항 18.2.2 – 비용과 성능 요구 사항을 균형 있게 고려**
각 SAP 지원 Amazon EC2 인스턴스 패밀리는 [SAPS](https://www.sap.com/about/benchmark/measuring.html#:~:text=SAP%20Application%20Performance%20Standard%20(SAPS)%20is%20a%20hardware%2Dindependent,order%20line%20items%20per%20hour.)로 측정된 특정 성능을 제공합니다. 성능 요구 사항에 따라 각 인스턴스 패밀리를 평가해야 합니다. SAPS당 비용 및 GiB당 비용 비율을 이해하는 것이 좋습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-18-2.html)
워크로드 구성 요소에 [SAPS](https://www.sap.com/about/benchmark/measuring.html#:~:text=SAP%20Application%20Performance%20Standard%20(SAPS)%20is%20a%20hardware%2Dindependent,order%20line%20items%20per%20hour.) (CPU)보다 메모리가 더 필요한 경우 메모리 1GiB당 비용이 가장 낮은 인스턴스 패밀리를 선택해야 합니다. 구성 요소에 메모리보다 SAPS(CPU)가 더 필요한 경우 SAPS당 가장 낮은 비용을 제공하는 인스턴스 패밀리를 선택해야 합니다.
AMD 프로세서로 구동되는 SAP 인증 인스턴스 패밀리는 일반적으로 유사한 Intel 기반 EC2에 비해 10%의 비용 절감 효과를 제공합니다. 예를 들면 동일한 성능 KPI에 대해 `C5a` 는 `C5` 패밀리보다 10% 저렴합니다.
비프로덕션 SAP HANA 워크로드의 경우 SAP Note: [2271345 - 비프로덕션 사용을 위해 비용 최적화된 SAP HANA 하드웨어](https://launchpad.support.sap.com/#/notes/2271345) [SAP 포털 액세스 권한 필요]에 자세히 설명된 요구 사항을 충족하는 인스턴스 패밀리 중 하나를 사용하는 것을 고려합니다.
**제안 사항 18.2.3 – 증가 프로필 및 최대 용량 요구 사항의 예측 가능성을 검토**
기존의 AWS 기반 SAP 환경 또는 동종 마이그레이션은 새로운 그린필드 환경 구현 또는 이종 마이그레이션보다 예측 가능한 증가 및 사용 패턴을 보일 가능성이 높습니다.
과거 증가 데이터가 부족한 시스템의 경우 단기 또는 중기 증가에 충분한 EC2 인스턴스 크기를 선택할 때의 비용 이점을 고려해야 합니다. 요구 사항이 변화함에 따라 인스턴스 크기를 조정하도록 계획합니다. 리소스 소비가 변화함에 따라 아키텍처 설계가 서로 다른 EC2 인스턴스 패밀리 간에 이동할 수 있는 유연성을 제공하는지 확인해야 합니다.
마찬가지로, 최대 용량에 대한 변경이 고려되었는지 평가해야 합니다.
SAP HANA 환경의 크기를 조정할 때 데이터베이스 크기뿐만 아니라 작업 메모리 요구 사항도 고려합니다. SAP HANA 크기 조정 보고서 및 도구를 참조하여 크기와 사용량을 추정하세요.
**제안 사항 18.2.4 – 인스턴스 약정 유연성을 고려**
약정 기간 도중 구성 요소(예: SAP HANA 데이터베이스)가 확장되어야 하는 경우 이로 인해 다른 인스턴스 패밀리로 이동해야 하는지 평가합니다. 이는 요금 모델 선택에 영향을 미칩니다.
+ AWS 설명서: [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)
# 모범 사례 18.3 - 라이선싱 영향 및 최적화 옵션 평가
SAP 워크로드를 AWS로 이동할 때 SAP 워크로드에 필요한 소프트웨어 라이선스에 상업적 영향이 있을 수 있습니다. 이러한 영향과 사용 가능한 옵션을 이해해야 합니다.
**제안 사항 18.3.1 – 소프트웨어 라이선스에 대한 CPU 및 메모리의 영향을 이해**
라이선스 비용을 최적화하기 위해 지원되는 SAP용 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/) 에서 사용 가능한 다양한 vCPU/메모리 비율을 평가합니다.
+ SAP 설명서: [vCPU 또는 메모리로 라이선스가 부여된 SAP 구성 요소](https://www.sap.com/documents/2015/05/849f654b-277c-0010-82c7-eda71af511fa.html)
+ SAP 설명서: [SAP HANA 할당 메모리 풀 및 할당 제한](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/bd43f1c0bb571014bf5acf22f379fd3d.html)
Oracle 기반 환경의 경우 다음을 검토하세요.
+ [Oracle License Considerations, Licensing Oracle Software in the Cloud Computing Environment](http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf)
+ Oracle Premium Support requirements, SAP Note: [2069760 - Oracle Linux 7.x SAP 설치 및 업그레이드](https://launchpad.support.sap.com/#/notes/2069760) [SAP 포털 액세스 권한 필요]
Microsoft Windows 및 SQL Server 환경의 경우 다음을 검토하세요.
+ AWS 설명서: [AWS 기반 Microsoft 라이선스](https://aws.amazon.com/windows/resources/licensing/)
+ SAP Note: [2139358 - SQL Server의 라이선스 약관 변경 영향](https://launchpad.support.sap.com/#/notes/2139358) [SAP 포털 액세스 권한 필요]
IBM Db2 환경의 경우 다음을 검토하세요.
+ [Eligible Public Cloud BYOSL Policy](https://www.ibm.com/software/passportadvantage/eligible_public_cloud_BYOSL_policy.html)
+ AWS 설명서: [AWS License Manager를 사용하여 IBM 라이선스 사용 추적](https://aws.amazon.com/blogs/mt/track-ibm-license-usage-with-aws-license-manager/)
CPU 또는 메모리가 ISV 및 서드 파티 제품 라이선스에 미치는 영향을 이해합니다.
+ 라이선스 비용을 최적화하기 위해 [Optimize CPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html) 기능을 사용하는 것을 고려합니다.
+ 소프트웨어 라이선스 및 관련 비용을 관리하기 위해 [AWS License Manager](https://docs.aws.amazon.com/license-manager/latest/userguide/license-manager.html) 를 사용하는 것을 고려합니다.
+ AWS 설명서: [Amazon EC2 인스턴스 유형별 물리적 코어](https://aws.amazon.com/ec2/physicalcores/)
**제안 사항 18.3.2 – 운영 체제 구매 옵션을 이해**
각 SAP 지원 운영 체제에서 일련의 구매 옵션을 사용할 수 있습니다.
1. Amazon EC2 제공 라이선스
1. AWS Marketplace 제공 라이선스
1. 기존 보유 라이선스 사용(BYOL)
운영 체제에 따라 사용할 수 없는 옵션도 있습니다. 가장 비용 효율적인 옵션을 결정하려면 요구 사항과 라이선스 계약을 평가해야 합니다. 다음 운영 체제 비용을 Amazon EC2 비용의 일부로 포함할 수 있습니다.
+ Windows Server
+ Red Hat Enterprise Linux
+ SUSE Linux Enterprise Server
AWS Marketplace를 통해 다음 운영 체제를 구매할 수 있습니다.
+ Red Hat Enterprise Linux for SAP(Red Hat Enterprise Linux 기반 EC2 비용에 기초)
+ SUSE Linux Enterprise Server for SAP(Amazon Linux 기반 EC2 비용에 기초)
다음 운영 체제에 기존 보유 라이선스(BYOL)를 사용할 수 있습니다.
+ Windows Server
+ Red Hat Enterprise Linux1
+ SUSE Linux Enterprise Server
+ Red Hat Enterprise Linux for SAP2
+ SUSE Linux Enterprise Server for SAP2
+ Oracle Enterprise Linux(Oracle Premium Support 요구 사항은 SAP Note: [2069760 - Oracle Linux 7.x SAP 설치 및 업그레이드](https://launchpad.support.sap.com/#/notes/2069760) 에 자세히 설명되어 있음) [SAP 포털 액세스 권한 필요]
1 SAP Note: [2871484 - Red Hat Enterprise Linux의 SAP 지원 변형](https://launchpad.support.sap.com/#/notes/0002871484) [SAP 포털 액세스 권한 필요]를 참조하세요. SAP는 RHEL 8부터 SAP 워크로드에 표준 Red Hat Enterprise Linux를 더 이상 지원하지 않습니다.
2 이러한 제품은 장기 지원을 제공하여 업그레이드에 대한 운영 비용을 절감할 수 있습니다. 자세한 내용은 SUSE 설명서: [SUSE Enterprise Support Policy](https://www.suse.com/support/policy-products/) 및 Red Hat 설명서: [Red Hat Enterprise Support Policy](https://access.redhat.com/support/policy/updates/errata/#Long_Support) 를 참조하세요.
**제안 사항 18.3.3 – 라이선싱 제한을 완화하기 위해 Amazon EC2 전용 호스트 사용을 고려**
Amazon EC2는 고객이 전용 하드웨어에 액세스할 수 있는 전용 호스트를 제공합니다. 전용 인프라에서 [이미 라이선스를 보유한 소프트웨어](https://aws.amazon.com/windows/resources/licensing/#Bring_existing_licenses_to_Dedicated_Hosts) 를 사용할 수 있습니다. Amazon EC2 전용 호스트는 Windows Server 및 SQL Server 라이선스를 포함하여 소프트웨어 라이선스를 관리하는 데 도움이 되는 서비스인 [AWS License Manager](https://aws.amazon.com/license-manager/) 와 통합됩니다.
**제안 사항 18.3.4 – 기가바이트당 또는 코어당 라이선스 모델에서 전환할 때의 비용 이점을 평가**
클라우드로 마이그레이션의 일부로 SAP Runtime 데이터베이스 라이선스 모델을 사용하는 것을 고려합니다.
SAP는 고객이 Runtime 데이터베이스 라이선스 모델에 따라 SAP HANA, SAP ASE 및 서드 파티 데이터베이스의 라이선스를 사용할 수 있는 기능을 제공합니다. SAP로부터 라이선스를 부여받은 Runtime 데이터베이스는 SAP로부터 라이선스를 부여받은 소프트웨어 및 SAP 지정 사용자를 지원하기 위한 용도로만 사용됩니다. SAP의 Runtime 데이터베이스는 일반적으로 SAP Application Value(SAV)라고 하는 SAP 소프트웨어 요금의 백분율로 라이선스가 부여됩니다.
Runtime 라이선스는 기가바이트의 메모리 또는 CPU 코어 수를 기반으로 하지 않습니다. SAP Runtime 데이터베이스 라이선스는 SAP 라이선스 계약에 포함되는 모든 환경에 적용되므로 특히 비프로덕션 시스템이 여러 개 있는 경우 기가바이트 또는 코어당 라이선스 모델에 비해 비용 이점을 제공할 수 있습니다.
SAP 라이선스 계약 내에서 SAP HANA Database Runtime 라이선스를 사용할 수 있는 권한이 이미 있는 경우 SAP HANA를 기본 데이터베이스로 사용할 수 없는 SAP 구성 요소에 대해 SAP ASE Database Runtime 라이선스를 추가로 사용할 수 있는 권한이 있는지 또는 해당 구성 요소에 SAP HANA를 사용하는 것과 관련된 인프라 비용을 절감할 수 있는지 확인해야 합니다.
+ SAP 설명서: [SAP Licensing Guide](https://www.sap.com/documents/2015/05/849f654b-277c-0010-82c7-eda71af511fa.html) 를 참조하거나 SAP 계정 팀에 문의하세요.
# 모범 사례 18.4 - 필요한 특성을 기반으로 스토리지 옵션의 비용 영향 평가
SAP 시스템을 호스트, 아카이브, 보호하기 위한 서비스로 객체 스토리지, 파일 스토리지 및 블록 스토리지 서비스 중에서 선택합니다. 비용을 절감하고 민첩성을 향상하도록 스토리지를 설계합니다.
**제안 사항 18.4.1 – 워크로드의 I/O 및 처리량 요구 사항에 부합하게 설계하는 가장 비용 효율적인 방법을 평가**
대부분의 SAP 요구 사항에서는 EBS 볼륨에 SSD(솔리드 스테이트 디스크)를 사용하는 것이 좋습니다. 비용 효율적인 선택을 위해 대부분의 SAP 워크로드에 적합한 범용 Amazon EBS 유형으로 시작하는 것이 좋습니다. 시간이 지남에 따라 CloudWatch 지표 및 애플리케이션/데이터베이스 모니터링을 사용하여 사용량을 검토합니다. 더 높은 I/O 또는 처리량이 필요한 경우 일반적으로 프로비저닝된 IOPS Amazon EBS 유형으로 충족할 수 있습니다.
+ AWS 설명서: [Amazon EBS 볼륨 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
비용과 성능을 균형 있게 고려하려면 SAP HANA 데이터 및 로그 볼륨에 사용되는 스토리지 구성이 SAP 스토리지 KPI를 충족해야 합니다. 다음 문서에 설명된 스토리지 레이아웃은 SAP TDI 지침에 대해 테스트되었습니다. [SAP HANA Tailored Data Center Integration](https://www.sap.com/documents/2016/05/e8705aae-717c-0010-82c7-eda71af511fa.html)
+ AWS 설명서: [SAP HANA용 스토리지 구성](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-storage-config.html)
**제안 사항 18.4.2 – 스토리지 크기 및 구성에 대한 동적 변경을 계획**
데이터 사용량 또는 IOPS 요구 사항에 따라 스토리지를 적절한 크기로 조정하여 스토리지 비용을 최적화합니다.
필요에 따라 동적으로 볼륨 크기를 확장합니다. 애플리케이션 업그레이드와 같이 향상된 성능이 필요한 작업 중에 볼륨 유형을 변경하는 옵션을 평가합니다.
+ AWS 설명서: [볼륨 수정 요청](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)
비용 관리를 보장하기 위해 모든 분리된 또는 사용되지 않는 볼륨을 정기적으로 검토합니다.
+ AWS 설명서: [Amazon EBS 볼륨 또는 스냅샷 정보 나열](https://aws.amazon.com/premiumsupport/knowledge-center/ebs-volume-snapshot-ec2-instance/)
**제안 사항 18.4.3 – 객체 스토리지의 비용 이점을 평가**
SAP 시스템의 핵심 데이터는 데이터베이스 내에 포함되며 Amazon EBS에 상주합니다. Amazon S3는 백업 또는 아카이브와 같은 보조 데이터와 이미지 또는 문서와 같은 대형 객체를 위한 저렴한 객체 스토리지를 제공할 수 있습니다. 보존 및 내구성 요구 사항에 적합한 [스토리지 유형](https://aws.amazon.com/s3/) 을 선택하여 비용을 추가로 최적화할 수 있습니다.
**제안 사항 18.4.4 – 공유 파일 시스템의 비용 이점을 평가**
Amazon Elastic File System(Amazon EFS)은 스토리지를 프로비저닝 또는 관리하지 않고도 파일 데이터를 공유할 수 있는, 한 번 설정으로 완료되고 탄력적인 서버리스 파일 시스템입니다. 성능 및 가용성 요구 사항에 따라 적절한 스토리지 클래스를 선택하여 비용을 추가로 최적화할 수 있습니다.
Amazon FSx는 Windows Server에 구축된 완전관리형 파일 스토리지 솔루션으로, 가용성 및 내구성이 뛰어납니다. 데이터 중복 제거 기능이 중복 데이터를 제거하여 추가로 비용을 최적화할 수 있습니다.
Amazon EFS 또는 Amazon FSx의 일반적인 SAP 사용 사례에는 `sapmnt`, 전송, 인터페이스 파일, 백업 저장, 소프트웨어가 있습니다. Amazon EFS 또는 Amazon FSx를 사용하면 자체 고가용성 NFS 솔루션을 배포하는 것보다 비용 이점이 있습니다.
+ AWS 설명서: [Amazon EFS](https://aws.amazon.com/efs/)
+ AWS 설명서: [Amazon FSx](https://aws.amazon.com/fsx/)
# 19 - 스토리지 비용 효율성을 위해 SAP 데이터 사용 최적화
**스토리지 및 메모리 관련 비용을 최소화하기 위해 SAP 데이터 사용을 최적화하는 방법은 무엇입니까?** 비용을 고려하여 데이터베이스 스토리지, 백업 및 지원 파일 시스템을 설계하고 정기적으로 위치, 보존 및 하우스키핑 전략을 평가합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-19.html)
# 모범 사례 19.1 - 액세스 및 보존 요구 사항 이해
데이터에 액세스하고 보존하는 방법을 이해합니다. 활성 데이터, 문서 관리 시스템 및 백업을 고려합니다.
**제안 사항 19.1.1 – SAP 시스템에서 다양한 유형의 비즈니스 데이터를 분류**
비즈니스 관점에서 다양한 데이터 유형 및 데이터 액세스 빈도(데이터 온도)를 분류함으로써 SAP 시스템에서 데이터를 아카이브 또는 오프로드할 기회를 식별하여 비용을 최적화할 수 있습니다.
다음은 SAP 시스템에서 볼 수 있는 몇 가지 일반적인 데이터 유형입니다.
+ 참조 - 값이 자주 변경되지 않는 데이터. 예: 도시, 국가 및 환율
+ SAP 마스터 데이터 - 값이 거의 변경되지 않는 데이터. 예: SAP Customer Master, 제품
+ 감사 - 감사 목적으로 보관되는 데이터. 예: 변경 로그
+ 트랜잭션 - 일상적인 비즈니스 운영의 일부로 생성된 데이터. 예: 판매 주문
+ 분석 - 분석 및 의사 결정을 지원하기 위해 생성된 데이터. 예: 월별 매출 보고
다음과 같이 데이터 온도를 분류합니다.
+ 핫 - 자주 액세스하는 데이터
+ 웜 - 자주 액세스하지 않는 데이터
+ 콜드 - 산발적으로만 액세스하는 데이터
다음과 같이 보존 요구 사항을 분류합니다.
+ 재해 복구(DR) 목적으로 보존
+ 참조 목적으로 보존
+ 규정 준수 또는 감사 목적으로 보존
# 모범 사례 19.2 - 정기적인 하우스키핑을 통해 불필요한 데이터 삭제
비용을 절감하기 위해 정기적인 하우스키핑 및 재구성 작업을 통해 데이터베이스 크기 및 기타 파일 시스템 사용을 최소화하여 데이터 공간을 축소합니다.
**제안 사항 19.2.1 – SAP 기술 테이블에서 크기 조정을 검토하고 정기적으로 하우스키핑을 수행**
SAP는 기술 테이블의 데이터 관리에 대한 포괄적인 지침을 제공합니다. 이러한 테이블의 증가를 식별하고 해결함으로써 스토리지 및 컴퓨팅 비용을 절감할 수 있습니다. 이는 데이터베이스 크기와 메모리 요구 사항 간의 직접적인 관계 때문에 SAP HANA 인스턴스와 특히 관련이 있습니다.
+ SAP Note: [2388483 - 방법: 기술 표의 데이터 관리](https://launchpad.support.sap.com/#/notes/2388483) [SAP 포털 액세스 권한 필요]
테이블(특히 기본 테이블로 표시된 항목)의 상대적 크기를 얻으려면 참조되는 ‘largest table’ SQL 문을 사용하세요. 기존 SAP 고객에서 빈번한 예는 삭제 또는 아카이브할 수 있는 완료된 SAP 워크플로 항목의 수가 많다는 것입니다. 마이그레이션 전에 하우스키핑을 수행하면 일정 및 성능도 향상될 수 있습니다. SAP HANA를 사용하는 경우 보고서 '/SDF/HDB\$1SIZING'이 정리 세부 정보 및 예상 디스크 요구 사항을 제공할 수 있습니다.
**제안 사항 19.2.2 – 로그, 추적, 인터페이스 파일 및 백업의 자동 또는 정기적 정리를 통해 파일 시스템 증가를 제어**
스토리지 비용은 사용량에 따라 결정되므로 장애 분석에 더 이상 유용하지 않은 파일의 복사본 및 백업의 승수 효과 외에도 기준 사용량을 최적화할 수 있는 기회가 있습니다.
+ SAP Note: [2399996 - 방법: SAP HANACleaner로 자동 SAP HANA Cleanup 구성](https://launchpad.support.sap.com/#/notes/2399996) [SAP 포털 액세스 권한 필요]
# 모범 사례 19.3 - 압축, 재구성 및 회수 전략 사용
SAP에서 지원하는 모든 데이터베이스는 공간 회수 메커니즘을 제공합니다. 이러한 메커니즘은 메모리 또는 EBS 볼륨 확장과 관련된 비용 증가를 최소화하기 위한 정기적인 유지 관리 활동의 일부여야 합니다.
**제안 사항 19.3.1 – 데이터베이스 압축을 사용**
압축은 SAP HANA의 기본 특징입니다. 다른 데이터베이스에서 압축을 사용하려면 추가 라이선스가 필요할 수 있지만 비용 및 성능 이점을 위해 조사해야 합니다. 다음 노트는 다양한 데이터베이스의 출발점을 제공하지만 추가 정보는 SAP 및 데이터베이스 설명서를 참조하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-19-3.html)
**제안 사항 19.3.2 – 데이터베이스 재구성 및 회수 작업을 사용**
유기적 사용 또는 대상 지정 아카이브 및 정리 작업으로 인해 데이터베이스 내에서 사용되지 않은 공간은 공간 절약을 실현하기 위해 재구성 또는 회수 작업이 필요할 수 있습니다. 공간을 정기적으로 회수함으로써 전반적인 증가와 스토리지 또는 메모리 추가 요구 사항을 줄일 수 있습니다 다음 노트는 다양한 데이터베이스의 출발점을 제공하지만 SAP 및 데이터베이스 설명서를 참조하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-19-3.html)
# 모범 사례 19.4 - 개선을 위해 백업 전략 검토
SAP on AWS를 실행할 때 백업 및 보존에 대한 접근 방식을 평가하여 위치, 보존 및 복구와 관련된 비용을 최적화해야 합니다.
**제안 사항 19.4.1 – 백업 위치를 평가**
Amazon S3는 저렴한 비용, 내구성, 스토리지 클래스 옵션 때문에 SAP 시스템 백업용으로 제안되는 장기 스토리지 솔루션입니다. Amazon EBS 볼륨의 데이터를 Amazon S3로 복사하려면 특정 시점 스냅샷, 통합 데이터베이스 도구 또는 직접 API 호출을 사용하여 데이터를 전송할 수 있습니다.
스냅샷은 *증분* 백업입니다. 즉, 가장 최근 스냅샷 이후에 변경된 디바이스의 블록만 저장됩니다. 이렇게 하면 스냅샷을 생성하는 데 필요한 시간이 최소화되고 데이터를 복제하지 않아 스토리지 비용이 절약됩니다.
데이터베이스 백업 솔루션은 일관성을 보장하기 위해 데이터베이스 상태를 인식해야 합니다. AWS는 Amazon S3와 직접 통합되는 SAP HANA 백업 솔루션(AWS Backint for SAP HANA)을 추가 비용 없이 제공합니다. 다른 SAP 지원 데이터베이스의 경우 Amazon S3로의 직접 백업을 지원하는 데이터베이스 공급 업체 또는 서드 파티 제공 백업 도구를 사용할 수 있습니다.
+ SAP 설명서: [Featured backup solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=backup)
임시 요구 사항 또는 스테이징 영역의 경우 먼저 Amazon EBS로 백업해야 할 수 있습니다. 이러한 사용 사례의 경우 `ST1` 볼륨 유형은 백업에 적합한 처리량 및 성능 특성을 제공하는 저렴한 HDD 볼륨입니다. SAP 데이터베이스를 디스크에 백업해야 하는 경우 `ST1` 을 선택하면 전체 스토리지 비용을 절감할 수 있습니다.
+ AWS 설명서: [Amazon EBS 볼륨 유형](https://aws.amazon.com/ebs/features/#Amazon_EBS_volume_types)
백업에 Amazon EFS를 사용하는 경우 EFS-Infrequent Access를 고려합니다. 이 스토리지 클래스는 일상적으로 액세스하지 않는 파일의 스토리지 비용을 줄여줍니다. Amazon EFS One Zone-Infrequent Access는 데이터가 하나의 가용 영역에만 상주하므로 백업에 권장되지 않습니다.
**제안 사항 19.4.2 – 표준 백업에 대한 보존 정책을 검토 및 구현**
비용을 관리하기 위해 비즈니스 요구 사항에 부합하는 보존 정책을 구현해야 합니다. Amazon S3는 GB당 비용, 최소 저장 기간 요금, 검색 요금(해당되는 경우)과 같은 특성으로 다양한 사용 사례에 맞게 설계된 여러 스토리지 클래스를 제공합니다. 백업에 대한 보존 및 액세스 요구 사항을 이해하면 요구 사항에 가장 적합한 스토리지 클래스를 결정하는 데 도움이 됩니다.
S3 수명 주기 정책을 사용하면 애플리케이션을 변경하지 않고 자동으로 다른 스토리지 클래스로 전송할 수 있습니다. 예를 들어 보존 기간이 더 짧은 백업은 이러한 클래스와 관련된 최소 저장 기간 요금 및 검색 요금으로 인해 S3-IA 또는 Amazon S3 Glacier보다 S3 Standard에 더 적합할 수 있습니다. 감사 목적의 월별 백업과 같이 보존 기간이 더 긴 백업은 필요한 보존 기간에 따라 S3-IA 또는 Amazon S3 Glacier에 더 적합합니다.
+ AWS 설명서: [Amazon S3 저장소 클래스](https://aws.amazon.com/s3/storage-classes)
+ AWS 서비스: [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html)
+ AWS 설명서: [Amazon EFS 수명 주기 관리](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)
+ AWS 서비스: [AWS Backup](https://aws.amazon.com/backup)
**제안 사항 19.4.3 – 임시 백업에 대한 전략을 수립**
시스템 또는 연결된 파일 시스템의 임시 백업이 요구 사항일 수 있습니다. 이러한 백업은 변경 전에 또는 특정 시점의 시스템 상태에 대한 참조로 필요할 수 있습니다. 이러한 백업은 표준 보존 기간과 다를 수 있으므로 삭제를 포함한 스토리지 사용 및 수명 주기 정책이 해당 백업의 개별 요구 사항에 가장 비용 효율적이 되도록 별도의 일정 또는 프로세스를 채택해야 합니다.
**제안 사항 19.4.4 – 복구 접근 방식에 따라 백업 설정을 검토**
백업은 시스템을 이전 시점으로 되돌리고 장애 시나리오로부터 방어하는 데 사용됩니다. 강력하지만 과도하지 않은 백업 스토리지 사용을 통해 비용 효율성을 보장하려면 복구 접근 방식을 검토해야 합니다. 더 세분화되고 오래된 백업의 요구 사항에 대한 가정을 재검토합니다. 복구 시 이러한 이전 백업이 필요한지 여부를 결정합니다.
예를 들어 데이터베이스 백업과 파일 시스템 백업을 모두 사용하는 것이 유효한 전략입니다. 그러나 기본 복구 메커니즘이 데이터베이스 복원 도구를 사용하는 경우 보존을 축소하거나 일부 볼륨의 스냅샷 백업을 삭제하여 비용을 최적화할 수 있는 기회가 있을 수 있습니다.
+ AWS 설명서: [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ AWS 설명서: [AWS Trusted Advisor 모범 사례 점검 항목](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
# 모범 사례 19.5 - 라이브 데이터에 계층화 옵션 고려
SAP HANA 관련 컴퓨팅 비용의 주요 요소는 필요한 메모리 용량입니다. 그러므로 데이터 오프로드 및 계층화 옵션을 사용하면 컴퓨팅 비용을 절감할 수 있습니다. 다른 데이터베이스에는 계층화 옵션이 있을 수 있지만 여기서는 강조되지 않았습니다. 사용 가능한 옵션을 파악하려면 데이터베이스 공급 업체에 문의하세요.
**제안 사항 19.5.1 – SAP HANA OLAP 기반 워크로드에 대해 동적 계층화, 확장 노드 및 NLS(Near-Line Storage)를 평가**
SAP HANA 동적 계층화는 기록 데이터를 관리하기 위한 SAP HANA 데이터베이스의 선택적 추가 기능입니다. 동적 계층화의 목적은 자주 액세스하지 않는 데이터를 관리하기 위해 (SAP HANA의 인 메모리 스토어와 반대로) 디스크 중심 열 기반 스토어로 SAP HANA 메모리를 확장하는 것입니다. 동적 계층화는 네이티브 SAP HANA 사용 사례에만 사용할 수 있으며 HANA의 BW(Business Warehouse) 또는 BW/4 HANA 사용 사례에는 사용할 수 없습니다.
SAP HANA 확장 노드는 웜 데이터를 저장하기 위해 특별히 설정되고 예약된 특수 목적 SAP HANA 작업자 노드입니다. SAP HANA 확장 노드를 사용하면 SAP BW(Business Warehouse) 또는 네이티브 SAP HANA 분석 사용 사례의 웜 데이터를 저장할 수 있습니다. SAP HANA 확장 노드에 저장할 수 있는 전체 데이터 양은 확장 노드의 총 메모리 양의 1배에서 2배 사이입니다.
SAP IQ가 포함된 SAP BW NLS(Near-Line Storage)를 사용하면 BW 외부의 콜드 데이터를 HANA 또는 BW/4 HANA 데이터베이스에 저장할 수 있습니다. NLS는 콜드 데이터를 HANA 데이터베이스에서 이동하여 SAP IQ 서버의 스토리지에 저장합니다.
+ AWS 설명서: [SAP 데이터 계층화](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**제안 사항 19.5.2 – OLTP 기반 워크로드에 대해 데이터 에이징 및 SAP HANA NSE(Native Storage Extension)를 평가**
데이터 에이징은 디스크 영역에 자주 액세스하지 않는 데이터를 저장하여 SAP HANA 메모리를 확보합니다.
+ AWS 설명서: [SAP 데이터 계층화](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**제안 사항 19.5.3 – 대규모 분석 데이터에 데이터 레이크 사용을 고려**
SAP 및 비 SAP 데이터를 분석할 때 S3 기반 데이터 레이크는 비용 효율적인 데이터 스토리지 옵션을 제공합니다.
+ SAP on AWS 블로그: [SAP on AWS를 사용하여 데이터 레이크 구축](https://aws.amazon.com/blogs/awsforsap/building-data-lakes-with-sap-on-aws/)
# 모범 사례 19.6 - 아카이빙 및 오프로딩 옵션 평가
자주 액세스하지 않는 데이터를 아카이브하거나 대형 객체를 니어라인 스토리지로 오프로드하는 옵션을 고려하면 인프라 및 백업 비용을 절감할 수 있습니다.
**제안 사항 19.6.1 – 자주 액세스하지 않는 데이터가 있는 대규모 테이블에 대한 아카이빙을 구현**
특히 SAP HANA 데이터베이스의 경우 아카이빙 전략을 사용하여 데이터베이스 증가를 관리하면 비용 이점이 있습니다.
+ SAP 설명서: [데이터 아카이빙](https://help.sap.com/viewer/6c8d90ed795242279e9103a8acad9cbe/LATEST)
**제안 사항 19.6.2 – Amazon S3를 대상으로 지원하는 아카이빙 도구를 평가**
Amazon S3는 뛰어난 가용성 및 내구성으로 설계되었으며 다양한 비용 효율적인 스토리지 클래스를 제공합니다. 따라서 가장 낮은 총 소유 비용(TCO)으로 SAP 아카이브 데이터를 저장하는 데 이상적입니다.
+ AWS 설명서: [Amazon S3 저장소 클래스](https://aws.amazon.com/s3/storage-classes)
+ SAP 설명서: [SAP Certified Archiving Solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?filters=v:296)
**제안 사항 19.6.3 – 대형 객체에 데이터 관리 시스템을 사용**
송장 및 이미지와 같은 대형 객체에 대해 SAP 데이터베이스 외부에서 데이터를 오프로드하고 관리하기 위한 옵션과 비용 이점을 이해합니다. 데이터 액세스에 대한 비즈니스 요구 사항, 구현 노력 및 지속적 관리의 복잡성을 고려합니다.
대형 객체는 데이터베이스 크기를 증가시켜 리소스 및 백업 비용을 높입니다. 데이터 관리 시스템 옵션은 더 저렴한 스토리지 솔루션을 제공할 수 있습니다.
+ SAP 설명서: [SAP Document Management](https://help.sap.com/viewer/0f3e26f224d9419688b3d25d7c2e46fe/LATEST/en-US/4af6e75227db9972e10000000a4450e5.html)
+ SAP 설명서: [Search for Certified ILM Solutions](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=BC-ILM)
# 20 – 가시성, 계획 및 거버넌스로 비용 관리
**비용 최적화 및 인식을 보장하기 위해 클라우드 재무 관리(CFM)를 어떻게 실행합니까?** 시작부터 운영에 이르기까지 어떻게 SAP 클라우드 인프라 예산 관리를 설정하고 비즈니스 요구 사항에 맞춰 지속적으로 사용량을 최적화합니까?
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-20.html)
# 모범 사례 20.1 - 프로젝트 단계에서 소비 모델 및 환경 사용량 계획
마이그레이션 또는 구현 프로젝트 등 프로젝트 중에 단계적 접근 방식으로 시스템을 배포하는 경우가 많습니다. 또한 크기 조정 및 사용 프로필을 설정하는 안정화 기간도 있습니다. 이 기간 동안 유연성과 온디맨드 인스턴스 기능을 활용하여 비용을 최소화합니다.
**제안 사항 20.1.1 – 필요한 경우에만 시스템을 배포하도록 계획**
리드 타임을 단축하려면 필요한 경우에만 시스템을 배포할 수 있는 옵션을 제공해야 합니다. 단기 프로젝트 시스템의 경우 온디맨드 인스턴스를 사용하여 필요한 기간 동안 프로젝트 시스템을 구축합니다.
**제안 사항 20.1.2 – 예상 기간 및 사용 프로필에 따라 요금 옵션을 평가**
프로젝트 기간과 업무 시간은 요금 모델에 영향을 미칩니다. 온디맨드 요금 모델이 프로젝트 시작 시 기본적으로 선택되는 경우가 많습니다. 적절한 경우 더 저렴한 옵션으로 조정할 수 있도록 예산을 정의하고 평가합니다.
**제안 사항 20.1.3 – 사용하지 않는 시스템을 일시 중단 또는 폐기하도록 계획**
프로젝트가 더 이상 활성 상태가 아니거나 목적을 달성한 경우 인스턴스 종료에 따른 비용 절감과 폐기에 따른 스토리지 절감을 고려합니다. 일반적으로 프로젝트는 마이그레이션 중에 시스템의 복사본을 여러 개 생성합니다. 사용되지 않는 시스템은 종료해야 합니다.
# 모범 사례 20.2 - 다양한 가격 책정 방식을 활용하는 다년 계획 비용 모델 설정
요금 모델을 최대한 활용하여 AWS에서 제공하는 할인을 극대화할 수 있도록 용량 요구 사항에 대한 다년 계획을 수립합니다. 비용 기준을 설정하고 비용을 추적합니다. 클라우드 요금 모델은 변화하는 비즈니스 요구 사항에 대응하여 탄력적으로 인프라를 조정할 수 있는 유연성을 제공합니다. 장기 Savings Plan 또는 예약 인스턴스를 약정하기 전에 최소 3년간 예상되는 SAP 시스템 사용량을 이해하고 계획합니다. 테스트, SAP Quick Sizer 출력 및 증가 예측을 사용하여 데이터를 기반으로 약정 계획을 수립하고 워크로드에 대한 최대 할인을 활용합니다.
**제안 사항 20.2.1 – 주요 비즈니스 이벤트를 이해하여 용량 추정치를 설정**
SAP 워크로드는 일반적으로 사용 패턴 및 운영 시간이 알려져 있어 안정적입니다. SAP 시스템에 대해 잘 파악된 안정 상태 용량 기준을 설정합니다. 이 작업은 배포 초기 몇 주 동안 성능 테스트 및 프로덕션 환경 모니터링을 통해 수행할 수 있습니다.
다음을 고려하여 안정 상태 용량 추정치를 최소 3년 범위로 확장합니다.
+ 인수, 합병, 매각과 같은 주요 비즈니스 이벤트
+ 데이터 스토리지 요구 사항 또는 비즈니스 프로세스 빈도에 영향을 줄 수 있는 규정 변경
+ 정상적인 비즈니스 운영으로 인한 데이터 증가(데이터가 스토리지 크기 외에 컴퓨팅 크기에도 영향을 미치므로 SAP HANA와 같은 인 메모리 데이터베이스에 특히 중요)
+ 주요 시스템 업그레이드, 시스템 교체 또는 폐기
**제안 사항 20.2.2 – 1년 또는 3년 약정이 적절한지 평가**
용량 추정치를 사용하여 3년 약정 컴퓨팅을 활용할 때 가능한 할인을 극대화할 수 있는 SAP 워크로드의 양을 평가합니다. 다음 사항을 고려하세요.
+ SAP 워크로드의 모든 컴퓨팅 요구 사항에 3년 약정을 고려할 수 있습니까?
+ 변화하지 않을 것이라고 확신하는 일부 요구 사항에 3년 약정을 고려할 수 있습니까? 예: SAP 기본 애플리케이션 서버 또는 프라이머리 데이터베이스.
+ SAP 워크로드가 향후 SAP 용량 요구 사항의 변화로 인해 컴퓨팅 요구 사항이 감소할 때 초과 컴퓨팅 약정을 사용할 수 있는 보다 광범위한 AWS 조직의 일부입니까?
+ SAP 워크로드가 보다 광범위한 AWS 조직의 일부이며 연중무휴 24시간 운영할 필요가 없는 비프로덕션 환경에 대한 컴퓨팅 약정을 공유할 수 있습니까?
+ 중기 용량 변화의 경우 3년 컴퓨팅 계획을 약정하는 이점이 초과 또는 미사용 용량 낭비보다 더 큽니까(예: 단기 약정 대비 손익분기점이 20개월)?
+ 단기적으로 주요 비즈니스 변경 또는 교체의 영향을 받을 가능성이 있는 애플리케이션에 대해 단기 약정(1년)을 고려할 수 있습니까?
+ 환율 변동이 고려해야 할 문제입니까? AWS 요금은 미국 달러(USD)입니다(AWS 중국 제외). 고정 환율이 바람직한 경우 가능하면 전체 선결제 요금 모델을 고려할 수 있습니다.
할인을 극대화하기 위해 워크로드 용량 요구 사항을 약정 기간과 일치시키는 계획을 수립합니다.
![\[Timeline showing SAP workload capacity allocation over 3 years with different commitment types.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/images/example-timeline-of-planning-sap-on-aws-compute-commitments.png)
**제안 사항 20.2.3 – 할인폭을 늘리기 위해 컴퓨팅 유형을 고정하는 것이 적절한지 평가**
SAP 워크로드는 일반적으로 제한된 세트의 AWS 컴퓨팅 유형만 사용하므로 할인을 극대화하기 위해 특정 컴퓨팅 패밀리 또는 특정 인스턴스 유형을 약정하는 것이 워크로드에 적합한지 고려해야 합니다. 컴퓨팅에 대한 가장 할인이 높은 두 요금 모델은 EC2 Instance Savings Plans 및 표준 예약 인스턴스입니다.
다음 사항을 고려하세요.
+ 환경에서 자주 사용되는 컴퓨팅 유형을 식별하여 이에 대한 특정 EC2 Instance Savings Plans 또는 표준 예약 인스턴스를 구매하는 것을 고려합니다. 예를 들어 여러 SAP 애플리케이션을 위한 애플리케이션 서버에 `m5.xlarge` 를 사용 중인 경우입니다. 항상 이 약정을 사용할 가능성이 높기 때문에 이는 EC2 전용 Savings Plan 또는 표준 예약 인스턴스를 구매하기에 좋은 후보입니다.
+ 워크로드 증가 또는 비즈니스 이벤트로 인해 EC2 패밀리를 변경할 가능성이 높은 컴퓨팅 구성 요소를 식별합니다. 이러한 항목에는 보다 일반적인 Compute Savings Plans 또는 컨버터블 예약 인스턴스를 구매하는 것이 좋습니다. 예를 들어 SAP HANA 데이터베이스가 6개월 만에 크기 증가로 인해 EC2 `r5` 에서 `x1e` 컴퓨팅 패밀리로 이동해야 하는 경우입니다. 이는 단기 컨버터블 예약 인스턴스 또는 Compute Savings Plans에 적합한 후보입니다.
+ 일반 컴퓨팅 가격과 특정 컴퓨팅 가격의 손익분기점을 식별하고 약정 유형을 선택할 때 이를 고려합니다. 예를 들어 3년 차에 크기 조정 변경이 있는 경우 3년 컨버터블 예약 인스턴스를 약정하는 것보다 3년 동안 표준 예약 인스턴스를 구매하는 것이 더 저렴할 수 있습니다. AWS 예약 인스턴스 Marketplace에서 잔여 예약 인스턴스 가치를 판매하는 것도 고려할 수 있습니다.
+ 인스턴스 유형을 변경하기 전에 AWS Marketplace 판매자 비공개 제안 또는 연간 구독 소프트웨어의 사용을 식별합니다. 이렇게 하면 추가 소프트웨어 비용이 발생하지 않습니다. 두 플랜 모두 지정된 기간 동안 한 Amazon EC2 인스턴스에서 소프트웨어 제품을 실행하도록 약정함으로써 비용을 절감할 수 있습니다. 예를 들어 `r4.xlarge` 인스턴스에서 실행할 소프트웨어에 대한 연간 구독을 구매했습니다. 인스턴스 유형을 `r5.xlarge` 로 변경하기로 결정했습니다. 연간 구독은 더 이상 인스턴스에 연결되지 않지만 여전히 활성 상태입니다. 그 결과 `r5.xlarge` 에서 소프트웨어에 대한 추가 온디맨드 요금이 설정됩니다. 인스턴스 크기를 변경하기 전에 연간 구독이 만료될 때까지 기다리는 것이 좋습니다.
**제안 사항 20.2.4 – Savings Plans, 예약 인스턴스 또는 둘 다 더 적합한지 평가**
SAP 워크로드에 적합한 경우 Savings Plans와 예약 인스턴스를 혼합하여 다양한 모델의 이점을 확보합니다. 약정 기간 및 컴퓨팅 요구 사항을 전체적으로 계산한 다음 요금 모델을 선택합니다.
Savings Plans와 예약 인스턴스의 차이점에 대한 자세한 내용은 [비용 최적화]: [모범 사례 18.1 - Amazon EC2에 사용할 수 있는 결제 및 약정 옵션 이해](best-practice-18-1.md) 및 [Compute Savings Plans 및 예약 인스턴스](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris) 에서 찾을 수 있습니다.
[안정성]: [모범 사례 10.2 - 가용성 및 용량 요구 사항에 적합한 아키텍처 선택](best-practice-10-2.md) 을 고려하세요. 여기서는 Savings Plans와 예약 인스턴스 간의 용량 예약 기능 차이점과 절충에 대해 설명합니다.
**제안 사항 20.2.5 – 예산 및 추적 목적을 위해 용량 계획을 비용 모델로 변환**
Savings Plans, 예약 인스턴스 선택, 온디맨드 예산을 최소 3년간의 SAP 환경에 대한 AWS 지출을 추정하는 비용 계획으로 전환합니다. 컴퓨팅 추정치를 다른 AWS 비용과 결합하여 예산 책정 및 추적 목적으로 SAP 워크로드 비용 모델을 완성합니다.
SAP 비용을 추정할 때 다음 항목을 포함해야 합니다.
+ 컴퓨팅 연결 스토리지 비용(예: Amazon EBS 볼륨)
+ 공유 파일 스토리지 비용(예: Amazon EFS 및 Amazon FSx)
+ 백업 스토리지 비용(예: Amazon S3 및 Amazon S3 Glacier)
+ 네트워크 및 VPC 비용(예: Elastic Load Balancer, NAT 게이트웨이, Transit Gateway, 네트워크 아웃바운드 비용, Direct Connect 및 VPN)
+ 관리 및 거버넌스 서비스 비용(예: CloudWatch 세부 지표, AWS CloudTrail 및 AWS Config)
+ 보안 서비스 비용(예: AWS WAF, Amazon GuardDuty 및 AWS Shield)
+ AWS Support 비용(Business 또는 Enterprise)
+ 자격이 있는 기업 할인 프로그램 또는 대량 구매 할인을 고려합니다(자세한 내용은 AWS 계정 관리자에게 문의).
+ 통화: AWS 요금은 미국 달러(USD)입니다. 청구 통화를 선택할 수 있으며 청구서는 USD로 계산되며 경쟁력 있는 환율로 원하는 통화로 환산됩니다.
# 모범 사례 20.3 - 이상 탐지를 포함하여 비용 할당 및 추적을 위한 예산 및 메커니즘 수립
Well-Architected Framework에는 재무 관리를 구현하기 위한 [지침](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) 이 있습니다. 비즈니스 요구 사항에 따라 연간, 분기별, 월별 또는 일일 예산으로 클라우드 비용 예상치를 설정합니다. 정기적으로 사용량에 따라 예측을 조정하고 패턴 및 이상을 식별합니다. 계정 및 태깅 전략을 사용하여 비용 할당 메커니즘을 설정합니다.
**제안 사항 20.3.1 – 비용 및 결제 도구를 사용하여 지출 가시성을 확보**
SAP 시스템은 사용 패턴이 정적인 경우가 많습니다. 영구적으로 또는 프로젝트 단계에서 온디맨드 요금 모델을 사용하는 경우 Amazon EC2 비용이 변동할 수 있습니다. 데이터 볼륨 관리 전략이 수립되지 않으면 Amazon EBS 및 Amazon S3 비용이 예상보다 높을 수 있습니다.
적은 설정 작업으로 지출 가시성을 확보할 수 있는 도구는 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 입니다. 고급 기계 학습(ML) 기술을 사용하여 비정상적인 지출 및 근본 원인을 식별하므로 조치를 취할 수 있습니다. [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 를 사용하여 예상 비용 및 사용량을 기반으로 맞춤 예산을 설정합니다. 임계값을 초과할 경우 알리도록 예산 경고를 구성합니다.
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costop_bottom) 및 [AWS 결제 및 비용 관리](https://docs.aws.amazon.com/account-billing/) 는 가시성 및 분석을 위한 도구를 제공합니다.
추가 지침은 Well-Architected Framework [비용 최적화]: [지출 및 사용량 인식](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) 에서 찾을 수 있습니다.
**제안 사항 20.3.2 – 태그를 사용하여 지출을 분석 및 할당**
개별 계정, 리소스, 사업부 및 SAP 환경을 기반으로 AWS 리소스 요금을 식별하는 데 도움이 되는 [비용 할당 태그](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what) 를 생성할 수 있습니다. 이러한 태그는 AWS 결제 보고서에 표시되며 Cost Explorer를 사용하여 분석할 수 있습니다. 비용 할당 태그를 사용하여 개별 SAP 환경과 관련된 비용을 결정할 수 있습니다. 더 이상 필요하지 않은 임시 환경 또는 프로젝트 환경과 같은 특정 환경과 관련된 비용을 축소하거나 제거하기 위해 조치를 취해야 하는지 여부를 알리는 데 도움이 됩니다. 비용 할당 태그가 연결되지 않은 리소스를 식별하는 프로세스가 있어야 합니다. 이러한 리소스에 비용 할당 태그를 추가하는 데 필요한 작업을 구현합니다.
+ SAP on AWS 블로그: [SAP on AWS 태깅 권장 사항](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
# 모범 사례 20.4 - 비용 관련 승인 절차 및 제어 설정
클라우드 준비를 위해 기존 비용 평가 프로세스를 조정해야 할 수도 있습니다. 올바른 재무 관행 및 정책을 구현하는 방법을 숙지하기 위해 [AWS 클라우드 금융 관리 안내서](https://aws.amazon.com/executive-insights/content/cloud-financial-management-reference-guide)를 검토합니다.
**제안 사항 20.4.1 – 관리자에게 비용 영향을 교육**
책임을 할당하고 비용 최적화에 대한 인센티브를 제공하는 메커니즘을 도입합니다.
**제안 사항 20.4.2 – IAM 제어를 사용하여 특정 사용자만 인스턴스를 프로비저닝할 수 있도록 허용**
비용 관리를 보장하기 위해 계정 경계 내에서 리소스 유형 및 직무에 부합하는 IAM 정책을 사용합니다. 예를 들어 샌드박스 계정의 소규모 시스템은 프로젝트 팀 내에서 제어하도록 허용하지만 프로덕션 계정의 대규모 인스턴스에는 추가 승인 프로세스 및 액세스 제한이 있을 수 있습니다.
# 모범 사례 20.5 - 최적화 기회를 위해 사용량을 검토
정기적으로 SAP 워크로드를 검토하여 비용 최적화 기회를 식별합니다. 정기 검토는 다음 사항에 중점을 두어야 합니다. AWS 청구서와 SAP 워크로드 예산 간에 발견되는 차이 및 이상을 최소화, 모든 SAP 클라우드 리소스의 크기가 적절하고 과도하게 프로비저닝되지 않았는지 확인, SAP 워크로드의 비용 효율성을 향상시킬 수 있는 새로운 AWS 서비스 릴리스 또는 비용 절감을 이해.
**제안 사항 20.5.1 – 초기 계획보다 사용량이 많은 경우 추가 비용을 최소화**
계획되지 않은 비즈니스 이벤트 또는 추가로 필요한 성능으로 인해 클라우드 사용량이 예상 비용 모델을 초과하여 증가할 수 있습니다. 새로운 비용을 최적화하기 위해 이러한 변경 사항을 분석합니다. 변경 사항이 지속적인 경우 추가 Savings Plan 약정 또는 예약 인스턴스를 고려합니다.
단기간만 추가 용량이 필요한 경우 추가 비용을 최소화하기 위해 자동 크기 조정 또는 예약된 온디맨드 인스턴스 용량을 사용하는 수평적 확장 메커니즘(예: 추가 SAP 애플리케이션 서버)을 고려합니다.
**제안 사항 20.5.2 – SAP 워크로드 사용량 지표를 검토하고 가능한 경우 추가로 적절히 크기 조정**
SAP 시스템을 지원하는 구성 요소를 정기적으로 검토하여 적절한 크기인지 확인합니다. CloudWatch 지표를 사용하여 다음을 고려합니다.
+ SAP EC2 컴퓨팅이 적절한 크기입니까? CPU 또는 메모리 사용률이 낮습니까? 더 작은 EC2 인스턴스 크기로 이동할 수 있습니까?
+ SAP 스토리지가 적절한 크기입니까? 프로비저닝되었지만 사용되지 않은 초과 공간이 있습니까? 볼륨 크기를 줄일 수 있습니까?
+ SAP 스토리지의 성능이 적절합니까? 줄일 수 있는 초과 IOPS 또는 MBps가 프로비저닝되었습니까?
+ 백업 및 스냅샷이 적절하게 관리되고 있습니까? Amazon S3 Infrequently Accessed 또는 Amazon S3 Glacier에 아카이브할 수 있는 백업 복사본이 S3 Standard에 너무 많습니까?
+ 최적화를 위한 추가 영역을 식별하려면 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 및 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 와 같은 도구를 사용합니다. SAP Note: [1656099 - AWS의 SAP 애플리케이션: DB/OS 및 Amazon EC2 제품 지원](https://launchpad.support.sap.com/#/notes/1656099) [SAP 포털 액세스 권한 필요]에 따라 SAP 특정 컴퓨팅 및 스토리지 제한 사항을 인식합니다.
조사 결과를 사용하여 정기적으로 SAP 워크로드 구성 요소를 계속 적절한 크기로 조정하고 Savings Plans 및 예약 인스턴스 사용을 극대화합니다.
**제안 사항 20.5.3 – 새로운 AWS 서비스를 이해하고 추가 비용 최적화를 달성할 수 있는 경우 구현을 계획**
AWS는 정기적으로 새로운 서비스를 출시하고 주기적으로 가격을 인하합니다. 새로운 SAP on AWS 서비스 발표를 검토하고 최소 12개월마다 아키텍처에서 이를 활용할 계획을 수립합니다. AWS와의 Enterprise Support 계약의 일부로 테크니컬 어카운 관리자(TAM)가 있는 경우 정기 신규 서비스 브리핑 및 최적화 논의에서 도움을 받을 수 있습니다.
최신 발표 및 뉴스를 위해 [SAP on AWS 블로그](https://aws.amazon.com/blogs/awsforsap/) 및 [새로운 소식](https://aws.amazon.com/new/) 피드를 구독합니다.
SAP 워크로드의 지속적인 최적화에 대한 자세한 내용은 [운영 우수성]: [모범 사례 4.4 - 주기적 워크로드 검토를 수행하여 복원력, 성능, 민첩성 및 비용 최적화](best-practice-4-4.md) 를 참조하세요.