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