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