# 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/)