# 성능 효율성
성능 효율성 원칙에서는 컴퓨팅 리소스를 효율적으로 사용하여 요구 사항을 충족하고 수요 변경 및 기술 변화에 따라 이러한 효율성을 유지하는 데 중점을 둡니다. 성능 최적화는 성능을 모니터링 및 측정하고 변화하는 요구 사항을 충족하도록 컴퓨팅 인프라를 조정하는 데이터 기반 프로세스여야 합니다.
# 13 – 최적의 컴퓨팅 솔루션 선택
**SAP 워크로드에 최적인 컴퓨팅 솔루션을 선택하는 방법은 무엇입니까?** SAP 도구 및 기존 워크로드의 지표를 사용하여 성능 요구 사항을 평가하고 추정합니다. 컴퓨팅 요구 사항을 워크로드에 가장 적합한 SAP 지원 인스턴스에 매핑합니다. 인스턴스 유형에 대한 특정 스토리지 또는 네트워크 요구 사항과 선택한 AWS 리전 및 가용 영역에서 필요한 인스턴스 유형의 가용성을 고려합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-13.html)
자세한 내용은 다음 정보를 참조하세요.
+ AWS 설명서: [SAP용 Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/)
+ SAP 설명서: [인증 및 지원되는 SAP HANA Hardware](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/iaas.html#categories=Amazon%20Web%20Services)
+ SAP Note: [1656099 - AWS의 SAP 애플리케이션: DB/OS 및 Amazon EC2 제품 지원](https://launchpad.support.sap.com/#/notes/1656099) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1656250 - SAP on AWS: Support prerequisites(1656250 - SAP on AWS: 지원 사전 조건)](https://launchpad.support.sap.com/#/notes/1656250) [SAP 포털 액세스 권한 필요]
# 모범 사례 13.1 - 성능 요구 사항 평가 또는 추정
기존 SAP 시스템의 용량 및 사용 패턴을 조사하여 향후 하드웨어 요구 사항을 추정할 수 있습니다. SAP는 신규 및 기존 시스템용 하드웨어 크기 조정을 위한 여러 도구를 제공합니다. 크기 조정 추정을 추가로 검증하기 위해 개념 증명(POC) 배포 및 성능 테스트를 사용할 수 있습니다.
**제안 사항 13.1.1 – 소스 하드웨어의 SAPS 성능 지표를 참조**
SAP 벤치마크 하드웨어는 [SAP 애플리케이션 성능 표준(SAPS)](https://www.sap.com/about/benchmark/measuring.html) 을 사용하며, 이는 SAP 환경에서 시스템 구성의 성능을 설명하는 하드웨어 독립적 측정 단위입니다. 온프레미스 서버 하드웨어에 대한 SAPS 값을 얻으려면 기존 하드웨어 공급 업체 및 SAP 벤치마크 디렉터리에 문의하세요.
SAPS 기반 크기 조정은 기본 용량 요구 사항을 최소한으로 변경하는 마이그레이션(종종 리프트 앤 시프트 마이그레이션이라고 함)에 적합합니다.
**제안 사항 13.1.2 – SAP EarlyWatch Alert 보고서 및 모니터링 도구에서 과거 사용량 세부 정보를 참조**
[SAP EarlyWatch Alert](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html) 보고서는 최대 메모리 및 CPU 사용량 같은 SAP 애플리케이션의 사용률 정보를 제공합니다. 월말 결산 및 대규모 배치 로드와 같은 여러 피크 이벤트에 걸친 이러한 보고서의 전체적 분석은 시스템 사용에 대한 귀중한 인사이트를 제공할 수 있습니다.
EarlyWatch 외에도 인프라 수준 모니터링 도구는 더 세분화된 추가 인사이트를 제공할 수 있습니다.
**제안 사항 13.1.3 – SAP HANA 크기 조정 보고서를 사용하여 컴퓨팅 요구 사항을 추정**
SAP HANA로 마이그레이션할 때 대상 컴퓨팅의 크기를 추정하는 데 SAP가 제공하는 도구를 사용합니다. 이러한 도구에서 생성된 출력은 SAP HANA 데이터베이스에 대한 하드웨어 크기 조정 요구 사항을 자세히 설명합니다.
+ SAP 설명서: [HANA 플랫폼의 SAP HANA Administration 가이드](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/bdf26308bb571014b7bcd3bcd586aecd.html)
+ AWS 설명서: [SAP HANA 크기 조정](https://docs.aws.amazon.com/sap/latest/sap-hana/migrating-hana-sizing.html)
+ SAP Note: [1793345 – HANA의 SAP Suite 제품군 크기 조정](https://launchpad.support.sap.com/#/notes/1793345) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1872170 – ABAP on HANA sizing report(S/4HANA, Suite on HANA...)](https://launchpad.support.sap.com/#/notes/1872170) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2296290 – SAP BW/4HANA의 새로운 크기 조정 보고서](https://launchpad.support.sap.com/#/notes/2296290) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1958910 - HANA 데이터베이스의 EarlyWatch Alert](https://launchpad.support.sap.com/#/notes/1958910) [SAP 포털 액세스 권한 필요]
**제안 사항 13.1.4 – 그린필드 구현 및 기능 변경 사항에 SAP Quick Sizer를 사용**
SAP Quick Sizer는 신규 SAP 구현의 크기 조정 또는 변경 중인 SAP 구현(예: 사용자 기반 증가, 새로운 기능 또는 모듈)에 사용할 수 있습니다. 이 도구는 애플리케이션의 요구 사항을 하드웨어 사양으로 변환하는 데 도움이 됩니다. 최상의 결과를 얻으려면 기술 팀과 기능 팀이 협력하여 Quick Sizer 도구에 값을 입력해야 합니다.
복잡한 구현의 크기 조정을 검증하려면 SAP 전문가 크기 조정을 사용하는 것이 좋습니다.
SAP 도구 및 서비스에 대한 자세한 내용은 다음을 참조하세요.
+ SAP 설명서: [SAP: Sizing Benchmarks](https://www.sap.com/about/benchmark/sizing.html)
**제안 사항 13.1.5 – 크기 조정 정확성을 위해 개념 증명 배포를 사용**
AWS 서비스의 유연성을 활용하여 SAP 워크로드를 적절한 규모로 설정하고 비즈니스 요구 사항의 변화에 따라 크기를 조정할 수 있습니다. 개념 증명(POC)을 사용하여 클라우드로의 마이그레이션을 테스트하고 성능 요구 사항을 분석합니다. 이는 비용 및 성능 모두에서 워크로드를 적절한 규모로 설정하는 데 도움이 될 수 있습니다.
# 모범 사례 13.2 - SAP 워크로드에 적합한 EC2 인스턴스 선택
AWS는 SAP와 협력하여 AWS 서비스가 다양한 인스턴스 유형에서 SAP 소프트웨어를 구현 및 운영하는 데 적합하도록 합니다. 관련 SAP Note 및 설명서의 지침을 사용하여 적합한 인스턴스를 식별합니다. EC2 인스턴스 패밀리는 다양한 CPU 및 메모리 비율은 물론 SAP 워크로드를 실행하는 데 적합한 스토리지 및 네트워크 처리량 특성을 제공합니다. 성능 지표, SAPS 수치 및 컴퓨팅 추정치를 사용하여 요구 사항을 적절한 인스턴스 유형에 매핑합니다. 선택한 리전 및 가용 영역에서 이러한 인스턴스의 가용성을 확인합니다.
**제안 사항 13.2.1 – 지원되는 데이터베이스, 운영 체제 및 AWS 서비스에 대한 SAP 지침을 준수**
AWS는 SAP 제품을 배포하는 데 사용할 수 있는 서비스를 제공합니다. SAP Note: [1656099 - AWS의 SAP 애플리케이션: DB/OS 및 Amazon EC2 제품 지원](https://launchpad.support.sap.com/#/notes/1656099) 에서는 현재 지원되는 SAP 제품, 데이터베이스 및 운영 체제 조합과 Amazon EC2 인스턴스 유형에 대해 설명합니다.
AWS CLI를 사용하여 [인스턴스 유형 제품을 설명](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html) 하면 특정 AZ 내 개별 인스턴스 유형의 가용성을 결정할 수 있습니다.
+ AWS 설명서: [SAP용 Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/)
+ SAP 설명서: [SAP NetWeaver benchmarks](https://www.sap.com/dmc/exp/2018-benchmark-directory/#/sd?filters=v:4a9e824336e2837bf9081e423d576dba)
**제안 사항 13.2.2 – 하드웨어 지표 및 SAPS를 사용하여 선택을 안내**
각 SAP 지원 Amazon EC2 인스턴스 패밀리는 특정 vCPU/메모리 비율을 제공합니다. 성능 프로필을 이해하려면 요구 사항에 따라 각 인스턴스 패밀리를 평가해야 합니다. 현재 세대의 Amazon EC2 인스턴스( [AWS Nitro](https://aws.amazon.com/ec2/nitro/) 기반)는 최고의 성능을 제공하므로 배포 시나리오에서 사용 가능하고 인증된 경우 사용해야 합니다.
SAP 애플리케이션 서버는 범용(`m*`) 또는 메모리 최적화(`r*`) 인스턴스를 사용할 수 있습니다. 더 높은 vCPU/메모리 비율 요구 사항이 있는 경우 컴퓨팅 최적화(`c*`) 인스턴스를 사용하는 것을 고려합니다. AnyDB 데이터베이스 서버의 경우 메모리 최적화(`r*`) 인스턴스가 필요한 코어 대 메모리 비율에 적합하지만, 특히 배포에 CPU별 라이선싱이 적용되는 경우 추가 분석을 수행하여 크기 조정을 검증해야 합니다. 메모리에서 실행되는 SAP HANA 데이터베이스의 경우 메모리 최적화(`r*`, `x*`, `u*`)가 유일한 옵션입니다.
**제안 사항 13.2.3 – SAP HANA 하드웨어 디렉터리 및 메모리 요구 사항을 사용하여 SAP HANA용 EC2 인스턴스를 선택**
AWS는 Amazon EC2 인스턴스의 하위 집합에 대해 SAP HANA 워크로드를 실행하기 위한 SAP HANA 인증을 받았습니다. 이러한 인스턴스에 대한 자세한 내용 및 지원되는 IaaS 애플리케이션 유형(OLAP, OLTP, SAP Business One, 스케일 아웃)은 다음을 참조하세요. [인증 및 지원되는 SAP HANA Hardware](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23) 및 [SAP용 Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/) .
데이터베이스 크기 및 실제 작업 메모리 사용량에 따라 메모리 요구 사항과 인스턴스 선택이 결정됩니다.
비프로덕션 워크로드의 경우 추가 옵션이 존재합니다. 다음 블로그를 참조하세요.
+ SAP on AWS 블로그: [SAP HANA 비프로덕션 워크로드를 위한 더 작은 X1e 인스턴스](https://aws.amazon.com/blogs/awsforsap/smaller-x1e-instances-for-sap-hana-non-production-workloads/)
**제안 사항 13.2.4 – EC2 인스턴스의 기능 및 처리량 특성을 인지**
Amazon EC2 인스턴스에는 다양한 기능 및 처리량 특성이 있으므로 특히 I/O 및 처리량 요구 사항이 높은 워크로드의 경우 사용 사례를 기반으로 이를 평가해야 합니다. 여기에는 [Elastic Network Adapter(ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html#ena-performance) 를 통한 향상된 네트워킹, I/O 성능, Amazon EBS 최적화, 배치 그룹 적합성이 포함됩니다. 전체 기능 목록은 다음을 참조하세요.
+ AWS 설명서: [범용 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose-instances.html)
+ AWS 설명서: [메모리 최적화 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html)
+ AWS 설명서: [컴퓨팅 최적화 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compute-optimized-instances.html)
# 모범 사례 13.3 – 시스템 또는 구성 요소의 독립적 크기 조정이 가능한 아키텍처 선택
SAP 시스템 및 구성 요소는 제약 없이 크기를 조정할 수 있는 유연성이 있어야 합니다. 이는 할당된 하드웨어 내에서 또는 일부 구성 요소의 수평 크기 조정을 사용하여 달성할 수 있습니다. 이러한 크기 조정이 가능한 아키텍처를 고려하고 관련된 절충을 평가합니다.
**제안 사항 13.3.1 – 시스템 간 또는 구성 요소 간 성능 영향을 고려**
구성 요소 간에 부정적인 성능 영향을 방지할 수 있도록 개별 시스템 또는 구성 요소를 격리합니다. 더 작은 규모의 여러 인스턴스를 배포하면 인스턴스 재사용, 워크로드 기반 크기 조정 및 온디맨드 용량에 대한 옵션을 사용할 수 있습니다. 비용 때문에 리소스 사용을 최적화하려는 경우에는 예외가 있습니다. 자세한 내용은 비용 원칙을 참조하세요.
**제안 사항 13.3.2 – 최대 성능을 위해 용량 유연성을 고려**
애플리케이션 서버와 같은 구성 요소의 크기 조정이 가능한 아키텍처를 선택하면 성능 요구 사항에 부합하게 용량을 조정하고 월말 처리 또는 계절성 피크를 포함한 예외적인 수요에 맞게 확장할 수 있습니다.
# 모범 사례 13.4 - 대기 시간이 최소화되는 리전 및 가용 영역 선택
SAP 인스턴스를 최종 사용자, 중요 인터페이스 및 시스템 내부 트래픽에 영향을 미치는 주요 비즈니스 프로세스의 대기 시간을 최소화하는 리전 및 가용 영역에 배포합니다.
**제안 사항 13.4.1 – 성능이 최적화되는 리전 및 클라우드 연결을 선택**
SAP 최종 사용자 및 기업 데이터 센터와의 근접성을 기반으로 리전을 선택합니다. 데이터 전송 요구 사항을 수용할 수 있도록 모든 클라우드 연결 옵션(예: Direct Connect 및 VPN)의 크기를 조정합니다.
SAP 성능 도구를 사용하여 사용자 응답 시간 분석(예: 네트워크, GUI, 애플리케이션 및 데이터베이스)을 이해하고 대기 시간 증가로 인한 네트워크 왕복 시간 변화의 영향을 평가합니다. 서로 다른 위치에 있는 시스템 간의 빈도가 높고 대기 시간이 짧은 인터페이스에 중점을 두는 것이 좋습니다.
대기 시간 증가가 특정 최종 사용자 그룹에 영향을 미치는 경우 최종 사용자 컴퓨팅 서비스 및 가속기를 사용하는 것을 고려합니다.
+ AWS 설명서: [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ AWS 설명서: [AWS Global Accelerator란 무엇입니까? - AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ SAP on AWS 블로그: [Amazon AppStream 2.0에 SAP GUI 배포](https://aws.amazon.com/blogs/desktop-and-application-streaming/deploying-sap-gui-on-amazon-appstream-2-0/)
**제안 사항 13.4.2 – 시스템 내부 대기 시간에 대한 SAP 지침을 인지**
SAP는 애플리케이션과 데이터베이스 간 트래픽 및 SAP HANA 시스템 복제에 허용 가능한 네트워크 대기 시간에 대한 지침을 제공합니다.
+ SAP Note: [1100926 - FAQ: 네트워크 성능](https://launchpad.support.sap.com/#/notes/1100926) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2543171 - 애플리케이션 측 및 데이터베이스 간의 지연 시간 문제](https://launchpad.support.sap.com/#/notes/2543171) [SAP 포털 액세스 권한 필요]
이러한 노트에 수록된 데이터베이스와 애플리케이션 서버 간 연결에 대한 지침은 단일 데이터 센터에서 실행되는 시스템을 기반으로 한 것으로, 다중 AZ 배포의 복원력 이점이 반영되지 않았습니다. 가용 영역은 한 AWS 리전에서 의미 있는 거리(최소 10km)로 분리되고 이중화 전원, 네트워킹 및 연결을 갖춘 하나 이상의 개별 데이터 센터입니다.
AWS의 고가용성(HA) SAP 아키텍처는 일반적으로 SAP 애플리케이션 서버 인스턴스를 포함하여 인프라를 여러 AZ에 걸쳐 배포합니다. 상당한 수의 데이터베이스 호출을 수행하는 SAP 트랜잭션 또는 배치 작업이 있는 경우 데이터베이스와 동일한 AZ에 상주하는 SAP 애플리케이션 서버에서 이러한 작업을 실행하는 것이 좋습니다. 또한 최종 사용자의 경우 SAP 로그온 그룹(트랜잭션 SMLG)을 사용하고 백그라운드 처리 작업의 경우 배치 서버 그룹(트랜잭션 SM61)을 사용합니다. 그러면 SAP 워크로드에서 대기 시간에 민감한 부분이 올바른 애플리케이션 서버에서 실행됩니다. NIPING과 같은 도구를 사용하여 대기 시간을 측정합니다.
SAP는 SYNC 모드에서 SAP HANA 동기 복제를 지원하기 위해 약 1.0ms의 대기 시간을 권장하며, 이는 가용 영역 간에 달성 가능합니다.
+ SAP 설명서: [SAP HANA 네트워크 요구 사항](https://assets.cdn.sap.com/sapcom/docs/2016/08/1cd2c2fb-807c-0010-82c7-eda71af511fa.pdf)
**제안 사항 13.4.3 – SAP HANA 스케일 아웃에 배치 그룹을 사용**
SAP HANA 스케일 아웃 배포에서 노드 간 통신에 대한 SAP 인증을 충족하려면 클러스터 배치 그룹을 사용해야 합니다.
+ AWS 설명서: [배치 그룹 - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-cluster)
# 14 – 최적 스토리지 솔루션 선택
**SAP 워크로드에 최적인 스토리지 솔루션을 선택하는 방법은 무엇입니까?** 이 스토리지를 구성하는 방법은 시스템 성능에 영향을 미칩니다. AWS는 SAP 데이터베이스, 애플리케이션 및 백업의 스토리지 요구 사항을 충족하기 위해 블록, 파일 및 객체 스토리지를 포함하는 광범위한 서비스를 제공합니다. SAP가 벤치마킹하고 인증한 지침을 따르는 것이 좋습니다. SAP HANA의 경우 매우 구체적인 지침이 있습니다. 다른 데이터베이스는 워크로드와 일치시키려면 더 많은 분석이 필요합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-14.html)
# 모범 사례 14.1 - 기능에 부합하는 탑재 지점 및 볼륨 연결 생성
SAP 파일 시스템에는 고유한 성능 및 공유 요구 사항이 있습니다. 예를 들어 데이터베이스의 성능 프로필은 많은 수의 읽기 I/O 작업을 지원하기 위해 데이터 파일 시스템을 요구할 수 있지만 로그 파일 시스템은 처리량의 제약을 받을 가능성이 더 높습니다. 모든 애플리케이션 서버가 로그 및 전송 파일에 액세스할 수 있도록 `sapmnt` 및 `trans` 와 같은 파일 시스템을 공유해야 합니다. 이러한 차이점을 인식하여 성능 병목 현상이 없고 액세스 요구 사항이 충족되도록 파일 시스템을 볼륨에 매핑해야 합니다.
**제안 사항 14.1.1 – 각 시스템의 SAP 파일 시스템 및 디렉터리 요구 사항을 식별**
SAP 파일 시스템에는 시스템 디렉터리(root, boot), 실행 파일, 페이지 또는 스왑, 애플리케이션별 요구 사항이 포함됩니다. 다음을 고려하여 각 요구 사항을 분석해야 합니다.
+ 파일 시스템이 용량에 도달했을 때(100% 사용됨) 미치는 영향(특히 root 디렉터리)
+ AMI 또는 배포 패턴에 포함되는지 여부를 포함한 빌드 일관성
+ 복원력 요구 사항
+ 공유 요구 사항
+ 성능 프로필
핵심 SAP 파일 시스템 요구 사항은 SAP 설명서 SAP Required Filesystems and Directories(SAP에 필요한 파일 시스템 및 디렉터리)에 나열되어 있습니다. 이를 기준으로 사용하고 조직에 고유한 기타 요구 사항을 포함합니다.
**제안 사항 14.1.2 – 파일 시스템 기능과 일치하도록 적절한 AWS 스토리지 서비스를 매핑**
파일 시스템은 로컬 또는 공유(NFS/SMB)일 수 있습니다. 공유 파일 시스템의 경우 호스트된 NFS 서버와 비교하여 안정성 및 가용성 이점을 제공하는 Amazon EFS, Amazon FSx와 같은 AWS 서비스를 사용하는 것을 고려합니다.
Amazon EC2 인스턴스 스토어는 인스턴스에 임시 블록 수준 스토리지를 제공하는 또 다른 파일 시스템 옵션입니다. 지속성, 인스턴스 유형 간 가용성이 없고 인스턴스 복구를 사용할 수 없기 때문에 사용을 권장하지 않습니다.
**제안 사항 14.1.3 – 지원되는 파일 시스템 유형을 사용**
SAP 지원 Linux 배포판은 다양한 파일 시스템 유형을 권장합니다. 이후 버전은 XFS를 기반으로 표준화되고 있지만, 지원을 검토하여 운영 체제 및 데이터베이스 버전에 성능이나 기능 영향이 없는지 확인해야 합니다.
+ SAP Note: [405827 - Linux: Recommended file systems](https://launchpad.support.sap.com/#/notes/405827) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2972496 - SAP HANA 파일 시스템 유형](https://launchpad.support.sap.com/#/notes/2972496) [SAP 포털 액세스 권한 필요]
# 모범 사례 14.2 - 성능 요구 사항에 부합하는 Amazon EBS 유형 선택 및 구성
각 파일 시스템 기능 및 스토리지 서비스에 대해 스토리지 레이아웃 지침과 튜닝 옵션을 평가하여 IOPS 및 처리량 성능이 최적화되었는지 확인합니다.
**제안 사항 14.2.1 – EBS 볼륨 유형에 대한 스토리지 특성 및 옵션을 평가**
AWS에는 고유한 특성을 가진 다양한 볼륨 유형이 있어 SAP 워크로드의 다양한 성능 요구 사항을 충족할 수 있습니다. 기록 데이터 또는 크기 조정을 사용하여 IOPS 및 처리량 요구 사항을 평가합니다. 성능, 내구성, 유연성 및 비용을 고려하여 볼륨 유형을 선택합니다.
볼륨 유형 `gp3` , `io1` 및 `io2` 의 IOPS 및 처리량은 볼륨 크기와 독립적입니다.
볼륨 유형 `gp2` 의 IOPS 및 처리량은 볼륨 크기에 따라 다릅니다. 필요한 IOPS 및 처리량을 사용할 수 있으려면 볼륨을 더 크게 지정해야 할 수 있습니다.
+ AWS 설명서: [Amazon EBS 볼륨 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
**제안 사항 14.2.2 – LVM 스트라이핑 메커니즘을 사용하여 선형으로 크기 조정**
단일 EBS 볼륨으로 성능 요구 사항을 충족할 수 없는 경우 논리적 볼륨 관리(LVM)를 사용한 스트라이핑을 고려합니다. 예를 들어 단일 볼륨의 처리량이 250MiB/s인 경우 4개 볼륨에 걸쳐 스트라이프 세트가 있으면 1,000MiB/s의 처리량을 제공할 수 있습니다.
볼륨은 크기 및 성능 특성이 동일해야 합니다.
SAP HANA 벤치마크 테스트에서 데이터 볼륨에 256KB 스트라이프 크기를 사용하고 로그 볼륨에 64KB 스트라이프 크기를 사용하여 최상의 성능을 얻었습니다.
처리량, I/O 및 연결된 볼륨 수에 대한 인스턴스 제한에 유의해야 합니다.
+ AWS 설명서: [EBS 볼륨에 LVM 논리 볼륨 생성](https://aws.amazon.com/premiumsupport/knowledge-center/create-lv-on-ebs-volume/)
+ SAP Note: [2931808 - Usage of Logical Volume Manager(LVM) with SAP HANA](https://launchpad.support.sap.com/#/notes/2931808) [SAP 포털 액세스 권한 필요]
+ AWS 설명서: [운영 체제 및 스토리지 구성 - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/operating-system-and-storage-configuration.html#:~:text=Configure%20Storage%20for%20SAP%20HANA)
**제안 사항 14.2.3 – SAP HANA 성능을 보장하도록 AWS 제공 스토리지 지침을 준수**
AWS는 SAP와 협력하여 정의된 성능 벤치마크에 따라 SAP HANA 워크로드용 스토리지를 인증합니다. AWS가 제공하는 구성에는 SAP TDI 5 Storage KPI의 프레임워크 내에서 성능, 비용, 내구성이 균형 있게 반영되어 있습니다. 호환 스토리지 레이아웃은 설명서에 자세히 설명되어 있으며 시작 마법사 및 빠른 시작 배포에 사용됩니다.
+ AWS 설명서: [SAP HANA용 스토리지 구성 - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-storage-config.html)
AWS 구성과 다른 경우 하드웨어 검사 도구를 실행하는 것이 좋습니다.
+ SAP Note: [1943937 - 하드웨어 구성 검사 도구 - Central Note](https://launchpad.support.sap.com/#/notes/1943937) [SAP 포털 액세스 권한 필요]
범용 SSD와 프로비저닝된 IOPS SSD 중에서 선택할 때 범용 SSD가 SAP KPI를 충족한다는 점을 이해하고 있어야 합니다. SAP HANA와 같은 인 메모리 데이터베이스는 데이터베이스 시작 시 디스크에서 메모리로 데이터를 로드해야 합니다. 성능이 우수한 스토리지 솔루션 및 설계는 시작 시간을 크게 단축하고 스토리지 성능에 의존하는 백업 및 복원과 같은 작업의 속도를 향상할 수 있습니다.
대규모 시스템 또는 가동 시간 요구 사항이 매우 높은 시스템은 프로비저닝된 IOPS가 유리할 수 있습니다. 최상의 배포 패턴에 대한 추가 지침은 AWS 팀에 문의하세요.
** 제안 사항 14.2.4 – 성능이 우수한 로컬 백업을 저렴한 비용을 사용하기 위해 `st1` 스토리지 사용 **
SAP 솔루션에 백업 저장을 위한 로컬 스토리지가 필요한 경우 저렴한 비용으로 높은 처리량을 제공하는 `st1` 인스턴스 유형을 사용하는 것을 고려합니다. `st1` 은 자주 액세스하는 처리량 집약적 워크로드를 위해 설계된 저비용 블록 스토리지 유형입니다.
SAP HANA의 경우 2단계 백업의 성능 및 비용 영향을 피할 수 있도록 AWS Backint Agent for SAP HANA를 사용하는 것을 고려합니다.
# 모범 사례 14.3 - SAP 사용 사례에 대한 Amazon EFS 및 Amazon FSx 성능 적합성 평가
Amazon EFS(Linux) 및 Amazon FSx(Windows)는 여러 가용 영역에 걸쳐 배치할 수 있는 고내구성 및 고가용성 파일 시스템을 제공합니다. 두 솔루션 모두 고성능을 제공하도록 설계되었지만 네트워크 파일 시스템 사용을 선택할 때는 액세스 패턴을 고려해야 합니다. 예를 들어, 많은 수의 소용량 파일, 고도의 병렬 쓰기 또는 높은 쓰기/읽기 비율은 적합하지 않을 수 있습니다. SAP 워크로드의 경우 SAP HANA XSA, Java 실행 파일 또는 많은 수의 작업 및 스풀 로그에 적용될 수 있습니다.
**제안 사항 14.3.1 – 크기 조정 및 성능 옵션을 평가**
Amazon EFS에는 범용 및 최대 I/O라는 두 가지 성능 모드와 버스팅 모드 및 프로비저닝된 모드라는 두 가지 성능 모드가 있습니다. SAP 애플리케이션의 경우 범용 성능 모드가 일반적으로 충분한 I/O를 제공합니다. 파일 시스템의 데이터 양이 처리량 요구에 비해 적은 경우와 같이 프로비저닝된 처리량을 고려해야 하는 시나리오가 있을 수 있습니다.
+ AWS 설명서: [Amazon Elastic File System(EFS) \$1 FAQ - 크기 조정 및 성능](https://aws.amazon.com/efs/faq/#Scale_and_performance)
+ AWS 설명서: [Amazon FSx for Windows File Server 기능 \$1 크기 조정 및 성능](https://aws.amazon.com/fsx/windows/features/#Performance_and_scale)
**제안 사항 14.3.2 - 단기 요구 사항을 위해 임시 프로비저닝을 고려**
마이그레이션 또는 일회성 작업과 관련된 사용 사례에는 이벤트 기간 동안 성능 특성을 조정할 수 있는 임시 파일 시스템이 유용할 수 있습니다.
# 모범 사례 14.4 - 스토리지 대안으로 메모리를 고려
지원되는 시나리오에 대해 데이터베이스 또는 애플리케이션 계층에서 메모리를 사용할 때의 성능 이점을 고려합니다. SAP HANA는 기본적으로 메모리를 사용하지만 로드를 최적화하거나 정적 데이터를 오프로드하는 옵션의 이점을 누릴 수 있습니다. 관계형 데이터베이스는 캐싱을 활용해야 하며 애플리케이션 서버는 스왑이 요구 사항인지 고려해야 합니다.
**제안 사항 14.4.1 – SAP HANA에 대해 메모리 사용을 최적화**
SAP HANA 메모리 요구 사항과 운영 체제 메모리 지표 간의 상관 관계를 이해하여 메모리 병목 현상이 성능에 영향을 미치지 않도록 해야 합니다.
+ SAP 문서: [SAP HANA 메모리 사용량 및 운영 체제](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ca10596b37f04909a96614553cb8ab1d.html#:~:text=Virtual%2C%20Physical%2C%20and%20Resident%20Memory&text=On%20most%20SAP%20HANA%20hosts,operational%20use%20by%20a%20process.)
+ SAP Note: [1999997 - FAQ: SAP HANA 메모리](https://launchpad.support.sap.com/#/notes/1999997) [SAP 포털 액세스 권한 필요]
호스트 재시작을 포함하지 않는 시나리오에서 데이터베이스 시작 성능을 향상하려면 SAP HANA Fast Restart 옵션을 사용하는 것을 고려합니다. SAP HANA Fast Restart 옵션은 RAM의 일부를 운영 체제가 재시작할 때까지 영구 메모리로 취급되는 임시 파일 시스템( `tempfs` )으로 할당하고 컬럼 스토어의 주요 부분을 해당 `tempfs` 에 배치하도록 허용합니다. 이 부분은 인덱스 서버 재시작 또는 크래시에도 유지됩니다. 그러므로 스토리지로부터 다시 로드(I/O를 사용)가 필요하지 않습니다.
+ SAP 문서: [HANA 빠른 재시작 문서](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ce158d28135147f099b761f8b1ee43fc.html)
**제안 사항 14.4.2 – 관계형 데이터베이스에 데이터베이스 캐싱을 사용**
읽기 IOP 요구 사항이 높은 관계형 데이터베이스의 경우 데이터베이스 캐싱을 사용하면 처리량 및 데이터 검색 대기 시간을 크게 개선할 수 있습니다. 캐시는 데이터베이스에 대한 인접 데이터 액세스 계층 역할을 하여 읽기 성능이 향상됩니다.
다음 설명서에서는 캐싱 사용 사례에 대한 정보를 제공하지만 이 세부 정보는 대부분 AWS 데이터베이스와 관련되므로 관계형 데이터베이스 구성과 관련된 정보는 SAP Note를 참조하세요.
+ AWS 설명서: [캐싱](https://aws.amazon.com/caching/) ( [데이터베이스 캐싱](https://aws.amazon.com/caching/database-caching/) 포함)
**제안 사항 14.4.3 – SAP 애플리케이션의 스왑 공간 요구 사항을 평가**
물리적 메모리 리소스가 고갈되면 SAP는 스왑을 사용하여 비활성 페이지를 전용 디스크 기반 저장 영역으로 이동합니다. 스왑이 있으면 메모리 부족으로 인해 애플리케이션이 크래시하는 것을 방지할 수 있지만 스왑이 자주 사용되지 않도록 구성 파라미터와 메모리 크기 조정을 적용하는 것이 좋습니다.
스왑 사용이 예상되는 경우 추가 성능 문제를 방지하기 위해 할당된 볼륨의 특성을 평가합니다. 스왑은 호스트에서 물리적 메모리가 고갈될 때 SAP 애플리케이션에서 메모리 부족 상황이 발생하는 것을 방지할 수 있습니다.
+ SAP Note: [153641 - R/3 64비트 커널의 스왑 공간 요구 사항](https://launchpad.support.sap.com/#/notes/153641) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2999334 - SWAP Utilization](https://launchpad.support.sap.com/#/notes/2999334) (HANA 관련) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2488097 - FAQ: Windows ABAP 서버의 메모리 사용량](https://launchpad.support.sap.com/#/notes/2488097) [SAP 포털 액세스 권한 필요]
# 모범 사례 14.5 – 적절한 백업 솔루션 및 일정 선택
백업 방법에 따라 스토리지에서 읽기 및 쓰기 작업이 모두 크게 증가하여 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다. 볼륨이 크고 기간이 길 수 있는 데이터베이스 수준 백업은 특히 그렇습니다
**제안 사항 14.5.1 – 적절한 백업 기간을 결정**
비즈니스 요구 사항에 따라 백업 작업을 실행하는 데 가장 적절한 기간을 정의합니다. 야간 배치 일정, 허용 가능한 런타임과 같은 주요 종속성을 고려합니다.
**제안 사항 14.5.2 – 백업의 성능 영향을 최소화하는 옵션을 고려**
스토리지 또는 네트워크 제약 조건을 분석하고 백업의 영향을 최소화하는 옵션을 평가합니다. 여기에는 데이터베이스 또는 스토리지 수준에서 델타 변경 백업을 사용하여 기간을 단축하는 것이 포함될 수 있습니다. 안정성 원칙을 참조하여 이로 인해 백업의 일관성 또는 전체 복원 시간에 부정적인 영향이 미치지 않도록 하세요.
+ SAP Lens [안정성]: [모범 사례 12.1 - 일관된 비즈니스 데이터 복구를 위한 방법 수립](best-practice-12-1.md)
# 15 - 운영 체제, 데이터베이스 및 SAP 애플리케이션 계층에 대한 튜닝 옵션 평가
**다양한 튜닝 옵션이 SAP 시스템 성능에 미치는 영향을 어떻게 이해하고 계산합니까?** SAP 소프트웨어 제품, 지원되는 운영 체제 및 데이터베이스, 버전의 다양한 조합에 따라 성능 권장 사항의 차이가 크므로 단일 문서에 성능 우수성 권장 사항의 전체 목록이 포함되지 않습니다. 이를 감안하여 다음 지침을 대부분의 SAP 사용 사례에 적용해야 하며, 해당되는 경우 특정 초점 영역이 언급될 것입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-15.html)
# 모범 사례 15.1 - SAP 성능에 대한 운영 체제 지침을 준수
SAP는 배포하는 SAP 소프트웨어에 지원되는 각 운영 체제에서 최적의 성능을 보장하기 위해 튜닝하는 방법에 대한 구체적인 지침을 제공합니다. 관련 튜닝 파라미터를 이해하고 운영 체제별 옵션을 활용하여 성능 튜닝을 보다 용이하고 보다 동적으로 수행하려면 배포하는 운영 체제에 대한 모든 관련 SAP 설명서를 읽어야 합니다.
**제안 사항 15.1.1 – 설치, 버전 업데이트 또는 인프라 변경 전에 운영 체제 관련 SAP Note를 검토**
운영 체제를 빌드 또는 업데이트할 때(자동화를 통해 또는 수동으로) SAP 소프트웨어와 운영 체제 버전의 조합에 적절한 성능 설정이 적용되었는지 확인합니다.
**제안 사항 15.1.2 – 운영 체제 공급 업체가 제공하는 SAP 튜닝을 평가**
Red Hat 및 SUSE는 SAP 실행에 최적화된 도구와 구성이 포함된 이미지 및 리포지토리를 제공합니다. 이들은 AWS Marketplace에서 또는 기존 보유 구독 사용(BYOS) 모델을 통해 사용할 수 있습니다.
공급 업체는 운영 체제가 SAP 애플리케이션에 최적화되도록 노력하고 있습니다. 공급 업체 제공 튜닝 도구(예: `saptune` 또는 Red Hat Enterprise Linux용 (Ansible) 시스템 역할)를 사용하면 알려진 성능 튜닝 기준을 정의하는 데 도움이 될 수 있습니다. 특정 SAP 워크로드를 가장 잘 수용하도록 운영 체제를 튜닝하는 작업은 여전히 필요하지만 이러한 도구를 사용하면 가장 일반적인 요구 사항을 조사, 계산 및 적용하는 데 들어가는 작업량을 줄일 수 있습니다. 또한 `tuned` 데몬과 연결된 구성을 CPU 수 및 가용 메모리를 포함하여 시스템에서 수집한 정보를 사용하여 동적으로 조정할 수도 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-15-1.html)
**제안 사항 15.1.3 – 운영 체제에 관련 네트워크 파라미터를 적용**
SAP 시스템 성능은 특히 SAP HANA 스케일 아웃 데이터베이스 설계에서 또한 시스템 환경의 여러 애플리케이션 서버 인스턴스와 데이터베이스 인스턴스 간의 통신에서 잘못된 네트워크 구성으로 인해 심각한 영향을 받을 수 있습니다. AWS에서 대부분의 경우 인스턴스의 최대 네트워크 처리량은 인스턴스 패밀리 및 크기에 따라 결정되지만 운영 체제 수준 및 SAP 소프트웨어 자체의 네트워크 설정 조정이 영향을 미칠 수 있습니다.
다음 AWS 및 SAP 권장 사항을 참조하세요.
+ AWS 설명서: [동일한 Amazon VPC의 Amazon EC2 Linux 인스턴스 간에 네트워크 처리량 벤치마킹](https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/)
+ AWS 설명서: [Elastic Network Adapter – Amazon EC2용 고성능 네트워크 인터페이스](https://aws.amazon.com/blogs/aws/elastic-network-adapter-high-performance-network-interface-for-amazon-ec2/)
+ AWS 설명서: [클러스터 배치 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-cluster)
+ SAP Note: [2198693 - Key Monitoring Metrics for SAP on Amazon Web Services(AWS)](https://launchpad.support.sap.com/#/notes/2198693) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1612283 - 하드웨어 구성 기준 및 지침](https://launchpad.support.sap.com/#/notes/1612283) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2081065 - SAP HANA 네트워크 문제 해결](https://launchpad.support.sap.com/#/notes/2081065) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1100926 - FAQ: 네트워크 성능](https://launchpad.support.sap.com/#/notes/1100926) [SAP 포털 액세스 권한 필요]
# 모범 사례 15.2 - 하드웨어 선택에 맞춰 데이터베이스 파라미터 수정
SAP는 기본 데이터베이스의 특정 파라미터를 수정하여 SAP 시스템의 성능을 최적화하기 위한 구체적인 지침을 제공합니다. 이러한 파라미터는 데이터베이스 유형에 고유하며 분석 또는 트랜잭션 유형 애플리케이션을 지원하는지 여부에 따라 달라질 수 있습니다.
**제안 사항 15.2.1 – SAP HANA 관련 튜닝 파라미터를 검토(해당되는 경우)**
운영 체제 및 SAP HANA 데이터베이스 파라미터는 성능에 큰 영향을 미칠 수 있습니다. 운영 체제 및 스토리지 구성에 대한 SAP on AWS 권장 사항을 따르세요.
+ AWS 설명서: [SAP HANA on AWS – 운영 체제 및 스토리지 구성](https://docs.aws.amazon.com/sap/latest/sap-hana/operating-system-and-storage-configuration.html)
메모리 할당 등 SAP HANA 파라미터에 대한 지침은 SAP Note 및 설명서를 참조하세요.
+ SAP Note: [2000000 - FAQ: SAP HANA 성능 최적화](https://launchpad.support.sap.com/#/notes/2000000) [SAP 포털 액세스 권한 필요]
+ SAP 설명서: [HANA Parameter: global\$1allocation\$1limit](https://help.sap.com/viewer/009e68bc5f3c440cb31823a3ec4bb95b/2.0.05/en-US/514ab38a2e574c85a70ebba80ff16d99.html#loio514ab38a2e574c85a70ebba80ff16d99__configSPS05_id_805)
+ SAP Note: [1999997 - FAQ: SAP HANA 메모리](https://launchpad.support.sap.com/#/notes/1999997) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2926166 - 전반적인 SAP HANA 메모리 할당을 제한하는 방법](https://launchpad.support.sap.com/#/notes/2926166) [SAP 포털 액세스 권한 필요]
**제안 사항 15.2.2 – 비 SAP HANA 데이터베이스에 대한 데이터베이스 튜닝 가이드를 검토**
SAP 시스템의 기본 데이터베이스에 관계없이 시스템 성능은 부분적으로 데이터베이스를 튜닝하는 방법에 따라 달라집니다. 각 데이터베이스에는 사용 가능한 컴퓨팅, 메모리 및 디스크 스토리지를 기반으로 튜닝에 대한 특정 권장 사항이 있습니다. 특정 데이터베이스 파라미터는 선택한 기본 EC2 인스턴스 크기에 따라 다릅니다. 예를 들어 사용 가능한 물리적 메모리는 Oracle 데이터베이스의 `db_cache_size` 를 제한합니다.
사용하는 데이터베이스와 관련된 정보는 다음을 참조하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-15-2.html)
# 모범 사례 15.3 - 하드웨어 선택에 맞춰 SAP 파라미터 수정
SAP 애플리케이션 파라미터를 조정하면 애플리케이션 성능을 개선하는 데 도움이 될 수 있습니다. 이러한 파라미터는 기본 하드웨어 구성 및 운영 체제 유형에 따라 달라지는 경우가 많습니다.
** 제안 사항 15.3.1 – SAP가 `PHYS_MEMSIZE에 따라 자체 튜닝하도록 허용` **
커널 릴리스 7.40 이상을 사용하는 최신 버전의 SAP 소프트웨어에서는 특정 파라미터의 자체 튜닝이 가능하며 권장됩니다. 예를 들어 많은 파라미터가 인스턴스(PHYS\$1MEMSIZE)에서 사용 가능한 기본 메모리와 관련된 공식을 통해 도출됩니다. 그러므로 변화하는 성능 요구 사항을 충족하기 위해 SAP 소프트웨어의 기반이 되는 EC2 인스턴스의 크기를 조정할 때 메모리 파라미터가 자동으로 조정될 수 있습니다.
+ SAP 설명서: [SAP 메모리 관리: 파라미터 참조](https://help.sap.com/viewer/f146e75588924fa4987b6c8f1a7a8c7e/LATEST/en-US/493431b15cce5717e10000000a42189b.html)
+ SAP Note: [2085980 – Kernel 릴리스 7.40의 메모리 관리 새로운 기능](https://launchpad.support.sap.com/#/notes/2085980) [SAP 포털 액세스 권한 필요]
**제안 사항 15.3.2 – SAP 스왑 공간 및 최대 메모리 사용량을 검토**
SAP on AWS을 실행할 때 디스크의 스왑 공간을 과도하게 사용하면 Amazon EBS에서 I/O 크레딧이 고갈되어 성능이 저하될 수 있습니다. AWS에서 사용 가능한 다양한 [EBS 스토리지 옵션](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 을 평가하고 성능 요구 사항을 충족하도록 스왑 공간을 구성합니다.
+ SAP Note: [1597355 - Linux의 스왑 공간 권장 사항](https://launchpad.support.sap.com/#/notes/1597355) [SAP 포털 액세스 권한 필요]
+ SAP 설명서: [스왑 공간 요구 사항](https://help.sap.com/saphelp_nw73/helpdata/en/49/325e42e93934ffe10000000a421937/frameset.htm)
# 모범 사례 15.4 – 복구 및 가용성 옵션에 대한 성능 튜닝을 고려
Well-Architected 안정성 및 운영 우수성 원칙을 참고하여 선택한 복구 및 복원력 요구 사항에 따라 SAP 시스템 튜닝을 평가하여 성능 영향을 최소화해야 합니다. 백업 중 시스템 성능, 선택한 데이터베이스의 클러스터링 옵션(예: 동기식 및 비동기식 SAP HANA 시스템 복제), 여러 SAP 애플리케이션 서버 인스턴스로 로드 분산과 같은 항목을 고려합니다.
**제안 사항 15.4.1 – 백업 및 복구 솔루션에 대한 성능 권장 사항을 검토**
지원되는 각 데이터베이스마다 백업 및 복구 작업 성능을 최적화하기 위한 다양한 권장 사항이 있으며, 이러한 권장 사항은 서드 파티 제품을 포함하여 백업 및 복원 관리를 위해 선택한 소프트웨어 솔루션과 연동하는 경우가 많습니다. AWS의 예에는 AWS Backint Agent for SAP HANA를 사용할 때 EBS 볼륨 및 동시성 파라미터 설정의 최대 IOPS 및 처리량 구성이 포함됩니다.
일반적으로 EC2 인스턴스와 백업 스토리지 대상(예: EBS 볼륨, S3 버킷, EFS 파일 시스템) 간의 처리량 향상을 위한 지침을 따르면 백업 및 복구 성능을 향상할 수 있습니다. 예를 들어 Amazon S3를 백업용 리포지토리로 사용하는 경우 Amazon S3용 AWS Command Line Interface(CLI)를 사용하면 최대 동시 요청 수 또는 멀티파트 청크 크기와 같은 [구성 파라미터](https://awscli.amazonaws.com/v2/documentation/api/latest/topic/s3-config.html) 를 변경하여 성능을 향상할 수 있습니다.
자세한 내용은 다음을 참조하세요.
+ AWS 설명서: [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-installing-configuring.html#aws-backint-agent-performance-tuning)
+ AWS 설명서: [SAP NetWeaver on AWS – 백업 및 복구](https://docs.aws.amazon.com/sap/latest/sap-netweaver/backup-and-recovery.html)
+ SAP on AWS 블로그: [가용성 및 안정성을 위한 구축](https://aws.amazon.com/blogs/awsforsap/sap-on-aws-build-for-availability-and-reliability/)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-15-4.html)
**제안 사항 15.4.2 – 클러스터링 파라미터의 구성을 검토**
SAP HANA 및 기타 데이터베이스에 대한 클러스터링 옵션은 기본 인스턴스와 장애 조치 인스턴스 간의 클러스터에서 확인된 연결(즉, 하트비트)에 의존하는 경우가 많습니다. SAP 관리자는 시스템에서 작업이 발생할 수 있는 속도와 통신 중단이 오탐되는 경우 발생할 수 있는 장애 조치 부작용의 가능성을 균형 있게 고려해야 합니다. 시간 초과 파라미터 및 관련 설정에 대한 권장 사항을 따르세요.
+ AWS 설명서: [SAP HANA on AWS: SLES 및 RHEL용 고가용성 구성 가이드](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html)
+ AWS 설명서: [SAP HANA on AWS 운영 가이드: 네트워킹](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-networking.html)
+ AWS 설명서: [SAP on AWS – 페이스메이커를 사용한 IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-ibmdb2/sap-ibm-pacemaker.html)
+ SAP Note: 1612105 - [DB6: FAQ on Db2 High Availability Disaster Recovery(HADR)](https://launchpad.support.sap.com/#/notes/1612105) [SAP 포털 액세스 권한 필요]
+ 운영 체제별 설명서: [SUSE Linux SAP HSR 크기 조정 성능 최적화 시나리오](https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-PerfOpt-12/index.html)
+ 운영 체제별 설명서: [페이스메이커 클러스터의 크기 조정에서 자동화된 SAP HANA 시스템 복제](https://access.redhat.com/articles/3004101)
# 16 - 지속적인 성능 및 최적화 옵션 이해
**성능 변화와 최적화 기회를 측정하기 위해 어떤 프로세스 및 절차를 사용하고 있습니까?** 과거 모니터링 데이터에서 애플리케이션 성능 요구 사항의 기준을 식별하고 관련 경고를 설정하여 편차가 발생하면 시스템 관리자에게 알립니다. 시스템 관리자가 수동 또는 자동 작업으로 이러한 문제를 해결할 수 있는 절차를 수립합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-16.html)
# 모범 사례 16.1 – 성능 평가를 위한 데이터 확보
SAP 시스템의 성능을 평가하고 최적 성능이 아닌 경우 조치를 취하려면 리소스 모니터링에 관한 Well-Architected Framework 성능 우수성 지침에 설명된 대로 컴퓨팅, 메모리, 스토리지 및 네트워킹에 대한 모니터링 데이터를 수집해야 합니다. Well-Architected Framework 운영 우수성 원칙에 명시된 대로 시스템의 현재 상태를 이해하고, 핵심 성과 지표를 설정하고, 진단을 위해 적시에 지표를 수집하는 것이 성능 문제를 조사하는 데 중요합니다.
+ Well-Architected Framework [성능 효율성]: [리소스를 모니터링하여 예상 성능을 제공하는지 확인](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html)
+ Well-Architected Framework [운영 우수성]: [워크로드 상태 파악](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**제안 사항 16.1.1 – 성능 지표와 관련된 데이터를 수집 및 저장**
관련 SAP 모니터링 데이터를 수집하고 확인하려면 SAP용 AWS Data Provider를 설치 및 구성하고 SAP 워크로드를 지원하는 특정 모니터링 도구에서 지표를 설정해야 합니다. 모니터링 및 추가 권장 사항에 대한 자세한 내용은 운영 우수성 원칙에서 확인할 수 있습니다.
+ AWS 설명서: [AWS Data Provider for SAP(SAP용 AWS Data Provider)](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html)
+ SAP Lens [운영 우수성]: [모범 사례 1.1 - SAP on AWS 모니터링을 위한 사전 조건 구현](best-practice-1-1.md)
+ SAP Lens [운영 우수성]: [모범 사례 1.2 – SAP에 대한 인프라 모니터링 구현](best-practice-1-2.md)
+ SAP Lens [운영 우수성]: [모범 사례 1.3 - SAP에 대한 개별 애플리케이션 모니터링 구현](best-practice-1-3.md)
# 모범 사례 16.2 - 기준 성능 요구 사항 설정
모든 SAP 애플리케이션에는 고유한 성능 요구 사항이 있습니다. 과거 모니터링 데이터를 사용하면 SAP 관리 팀이 이러한 애플리케이션의 기준 성능을 파악하여 성능 변화의 범위를 식별 및 이해할 수 있습니다. 의도하지 않은 CPU 스파이크, 스토리지 처리량 델타, 메모리 사용 증가, 보다 복잡한 성능 저하와 같은 이상 현상을 감지하기 위해 관련 경고를 설정할 수 있습니다. 이 모니터링 데이터를 사용하여 성능을 추가로 미세 튜닝할 수 있습니다.
**제안 사항 16.2.1 – SAP 관련 KPI를 반영하는 데이터를 수집 및 평가**
이 제안 사항은 Well-Architected Framework 성능 효율성 원칙의 [리소스 모니터링](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html)에 관한 추가 제안 사항과 밀접한 관련이 있습니다.
이 일반 지침 외에도 SAP 관련 KPI에는 대화 응답 시간, 버퍼 스왑, 사용된 메모리가 포함됩니다. 이러한 KPI는 실행 중인 SAP 소프트웨어 유형 및 버전에 따라 다를 수 있습니다. KPI 및 모니터링 권장 사항에 대한 자세한 내용은 이 문서의 운영 우수성 원칙에 나와 있습니다.
+ SAP Lens [운영 우수성]: [모범 사례 1.2 – SAP에 대한 인프라 모니터링 구현](best-practice-1-2.md)
+ SAP Lens [운영 우수성]: [모범 사례 1.3 - SAP에 대한 개별 애플리케이션 모니터링 구현](best-practice-1-3.md)
# 모범 사례 16.3 - 데이터를 사용하여 성능 추세 식별
성능 기준이 설정된 후에는 시스템 관리자가 시간에 따른 추세를 모니터링하여 KPI가 원하는 기준 내에서 안정적으로 유지되는지 확인해야 합니다. 성능 데이터가 허용할 수 없는 KPI 값을 향하는 추세를 보이는 경우 시스템 관리자는 성능 영향을 방지 또는 완화하기 위한 조치를 취할 수 있습니다.
**제안 사항 16.3.1 – 주기적으로 SAP 시스템 성능 검토를 수행**
시스템 관리자가 KPI를 정기적으로 검토하면 성능 관련 데이터의 추세를 식별하고 어떤 경고가 가장 유용한지 결정하는 데 도움이 될 수 있습니다 그런 다음 이러한 경고를 사용하여 추세가 지속되는 경우 알림을 자동화하고 잠재적인 성능 문제를 해결하기 위한 자동 수정 조치(예: 성능 지표에 대한 응답으로 SAP 파라미터를 동적으로 변경)를 설정할 수 있습니다. KPI 및 관련 추세의 예는 SAP EarlyWatch Alert 보고서에서 확인할 수 있으며, 경우에 따라 유용한 추가 지표를 사용하여 사용자 지정할 수 있습니다. SAP 서비스 수준 보고는 SAP 워크로드에 대한 서비스 수준 계약(SLA)이 있는 경우에도 유용할 수 있습니다.
+ SAP 설명서: [Service Level Reporting](http://support.sap.com/slr)
+ SAP Note: [1040343 - SAP EarlyWatch Alert](https://launchpad.support.sap.com/#/notes/1040343) [SAP 포털 액세스 권한 필요]
+ SAP Note: [1829914 - EWA Reports 사용자 지정](https://launchpad.support.sap.com/#/notes/1829914) [SAP 포털 액세스 권한 필요]
**제안 사항 16.3.2 – 추세 식별을 위해 과거 데이터를 보존**
시스템 동작의 추세를 이해하려면 미리 결정된 기간 동안 성능 데이터 및 관련 로그를 보존해야 합니다. 모든 SAP 시스템의 성능 튜닝은 일, 주, 월 단위의 과거 기간 동안 성능 추세 또는 주기적 성능 이벤트를 구성하는 요소를 이해하는 능력에 좌우됩니다. 성능 영향을 관찰하기 위해 데이터를 보존해야 하는 일반적인 이벤트는 다음과 같습니다.
+ 월말 및 연말 재무 처리
+ 비즈니스 이정표 부근에서 보고 요구 사항 증가(예: 대규모 반기 세일 시작 후)
+ 비즈니스 내에서 대규모로 신규 SAP 사용자 온보딩
+ 인프라 크기 조정, 데이터베이스 패치, 운영 체제 버전 업데이트 또는 SAP 소프트웨어 업그레이드와 같은 기술 변경
# 모범 사례 16.4 - 성능 문제 식별 및 해결
주요 지표가 성능 저하를 나타내는 경우 근본 원인을 해결하기 위한 프로세스를 수립합니다. 자동화(동적 크기 조정에 대한 다음 모범 사례 참조)를 사용하면 수동 개입의 필요성을 줄일 수 있습니다. 그러나 이것이 불가능한 경우 관리자를 위한 자동화된 경고 프로세스가 필수적입니다.
**제안 사항 16.4.1 – 성능 경고를 적절히 구성**
Well-Architected Framework 성능 효율성 원칙에 언급된 모니터링 및 경고에 관한 지침을 따르고 추가 기능을 제공하는 SAP 경고 기능을 활용합니다. [운영 우수성] [1 - 상태를 이해하고 대응할 수 있도록 SAP 워크로드를 설계](design-principle-1.md) 에서도 추가 세부 정보를 확인할 수 있습니다.
+ Well-Architected Framework [성능 효율성]: [모니터링](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitoring.html)
+ SAP 설명서: [SAP NetWeaver Alert Monitor](https://help.sap.com/doc/7a827019728810148a4b1a83b0e91070/1610 001/en-US/frameset.htm?frameset.htm)
**제안 사항 16.4.2 – 성능 인시던트의 자동 수정**
성능 인시던트 관리에는 Well-Architected Framework 운영 우수성 원칙에 자세히 설명된 운영 관련 모범 사례가 포함되지만 잠재적인 성능 저하를 사전에 감지하고 자동으로 수정하면 성능 문제 악화를 방지하고 최종 사용자 경험을 개선할 수 있습니다. 성능 문제를 완화하기 위한 자동화된 프로세스가 불가능한 경우 운영 팀이 성능 문제에 대응하는 방법을 자세히 규정한 런북을 작성하면 성능 인시던트에 대한 대응을 가속화할 수 있습니다.
+ SAP Lens [운영 우수성]: [모범 사례 1.8 - 자동 응답 및 복구 기술을 사용하여 모니터링 경고에 대응](best-practice-1-8.md)
+ Well-Architected Framework [운영 우수성]: [모범 사례: 운영](https://docs.aws.amazon.com/wellarchitected/latest/framework/oe-operate.html)
# 모범 사례 16.5 - 크기 조정을 통해 성능 요구 충족
AWS에서 워크로드를 운영하는 주요 이점 중 하나는 사용 사례에 요구되는 성능에 맞게 컴퓨팅 용량을 늘리거나 줄일 수 있고 스토리지 성능 특성을 변경할 수 있다는 것입니다. SAP 워크로드의 경우 성능 병목 현상을 방지하기 위해 해당되는 경우 동적 크기 조정을 사용합니다. SAP HANA 데이터베이스 클러스터 확장과 같이 동적 확장이 불가능한 시나리오에서는 수동 배포 프로세스를 사용합니다.
**제안 사항 16.5.1 – 사후 대응식으로 SAP 워크로드 크기를 조정**
워크로드 성능 요구 사항의 동적 변화에 대응하여 적절히 SAP 리소스의 크기를 조정합니다. 가능한 경우 자동화를 사용하여 확장 또는 축소하되, 이것이 가능하지 않은 경우(예: 데이터베이스 인스턴스 확장) 수동으로 수행할 수 있는 프로세스를 수립합니다. 고려 사항:
+ 요구를 충족하기 위해 필요에 따라 애플리케이션 서버 용량 추가/제거 또는 인스턴스 크기 변경
+ 프로그래밍 방식으로 가상 리소스를 재배포하도록 SAP 파라미터를 변경
+ [해당되는 경우 AWS에서 스토리지 유형을 수정하여](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) (예: Amazon EBS `gp3` 을 `io2` 로 또는 그 반대로) 스토리지 성능을 최적화
**제안 사항 16.5.2 – SAP 워크로드를 예측 가능하도록 크기 조정을 예약**
자동 방식이든 수동 방식이든 예측 가능한 성능 패턴을 기반으로 SAP 워크로드를 확장 또는 축소하는 것이 좋습니다. 예를 들어 SAP ECC 시스템에서 월말 재무 처리로 인해 애플리케이션 서버 인스턴스의 처리 요구 사항이 예측 가능한 수준으로 20% 증가하는 경우 시스템 관리자는 사전에 애플리케이션 서버의 수 또는 크기를 늘렸다가 예측 가능한 수준으로 사용량이 감소하면 인스턴스를 축소할 수 있습니다.
# 모범 사례 16.6 - 분석을 위해 프로덕션 로드 시뮬레이션 메커니즘 개발
테스트 시스템에 프로덕션 데이터를 복제하면 시스템 관리자는 프로덕션 SAP 워크로드를 시뮬레이션하고 스트레스 및 볼륨 테스트와 같은 중요한 성능 테스트를 수행할 수 있습니다. 이러한 유형의 테스트는 잠재적인 성능 병목 현상을 식별하고 실제 프로덕션 환경에서 발생하는 성능 문제를 방지하는 데 도움이 될 수 있습니다.
**제안 사항 16.6.1 – SAP 시스템에서 자동화된 스트레스 및 볼륨 테스트를 수행**
AWS에서 실행하는 프로덕션 데이터를 테스트 환경에 복사하는 것은 비교적 쉽습니다(예를 들어 [프로덕션 환경의 EBS 스냅샷](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/ec2-backup.html) 을 사용하여 새 테스트 인스턴스를 생성). 그러나 수동 또는 자동 복사 후 단계를 올바르게 수행하려면 주의가 필요합니다. 이러한 복사 후 단계에는 트랜잭션 BDLS를 통한 논리적 시스템 이름 변경, 민감한 프로덕션 데이터 스크램블링 또는 삭제, 관련 테스트 시스템에 대한 통합 설정이 포함될 수 있습니다. 또 다른 추가 이점은 이러한 격리된 성능 테스트 시스템이 영구적일 필요가 없다는 것입니다. 필요에 따라 인스턴스를 프로비저닝, 구성 및 종료할 수 있기 때문입니다.
그런 다음 여러 방법으로 테스트 시스템에 로드를 부과할 수 있습니다.
+ AWS에서는 [분산 로드 테스트](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 솔루션이 자동화된 로드 테스트를 위한 유용한 옵션일 수 있습니다.
+ SAP 소프트웨어에서 [eCATT(Extended Computer Aided Test Tool)를 통해 스크립트 생성 및 자동화](https://wiki.scn.sap.com/wiki/display/ABAP/eCATT)
+ 서드 파티 자동 테스트 솔루션을 사용
+ 운영 체제 수준에서 스크립트를 작성하여 SAP 시스템 내에서 적절한 프로그램을 대규모로 시작
# 모범 사례 16.7 - 성능 데이터를 기반으로 크기 조정 및 구성을 지속적으로 최적화
사고 대응 프로세스 외부에서 정기적으로 성과 지표를 검토합니다. 이렇게 하면 너무 작거나, 너무 크거나, 더 이상 사용되지 않는 시스템 구성 요소를 찾을 수 있습니다. 실제 사용자 로드에 적절하게 시스템 구성 요소의 크기를 조정하는 데 중점을 두고 SAP 워크로드에 대한 성능 최적화 주기를 설정해야 합니다. 이 활동은 사용자 경험을 개선하고 아키텍처에서 불필요한 부분을 제거하며 워크로드의 비용 효율성 및 복원력을 모두 개선하는 데 도움이 됩니다.
**제안 사항 16.7.1 – 과거 성능 지표를 가이드로 사용하여 정기적으로 아키텍처 크기를 적절하게 조정**
구성 요소의 규모를 적절하게 조정할 수 있는 기회를 위해 정기적으로 SAP 워크로드를 검토합니다. 비즈니스 성능 요구 사항에 더 잘 부합하도록 스토리지, 컴퓨팅, 네트워크 및 지원 서비스를 확장 또는 축소해야 하는지 여부를 고려합니다.
자세한 내용은 다음 리소스를 참조하세요.
+ SAP Lens [비용 최적화]: [모범 사례 20.5 - 최적화 기회를 위해 사용량을 검토](best-practice-20-5.md)
+ SAP Lens [운영 우수성]: [모범 사례 4.4 - 주기적 워크로드 검토를 수행하여 복원력, 성능, 민첩성 및 비용 최적화](best-practice-4-4.md)
+ AWS 설명서: [적절한 규모 결정](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)