36탄-9. AWS- AWS 분석 서비스 비용 최적화
EMR, Redshift, OpenSearch, Glue, S3 서비스에 대해 비용 최적화에 대해 알아본다!!
AWS 분석 서비스들에 대한 비용 최적화 방법을 알아보자.
<1> 비용 최적화 유형 2가지
<2> EMR 비용 최적화
<3> Redshift 비용 최적화.
<4> Amazon OpenSearch Service 비용 최적화.
<5> AWS GLUE 비용 최적화.
<6> Amazon S3 Cost Optimization
<1> 비용 최적화 유형 2가지
1
기술적 최적화
아키텍처, 디자인, 서비스, 리소스 선택, 서버리스 최적화
2
요금 최적화
장기 약정할인, RI , SP
<2> EMR 비용 최적화
1
작업 규모에 따라 적절한 크기에 클러스터 사용으로 비용을 줄일 수 있음
2
방법 4가지?
워크로드에 따른 클러스터 분리(클러스터 분리)
Spot 사용 (최대 90% 비용 절감)
EMRFS(S3) 사용하여 데이터 셋 저장 (컴퓨팅과 스토리지 분리)
Managed / Auto Scaling (동적 사용)
3
워크로드에 따른 클러스터 분리(클러스터 분리)?
배치쿼리와 대화형 쿼리 작업 분리
적절한 크기의 클러스터.
워크로드 특성상 일시작업은 EMR Serverless , EMR on EKS 사용
4
Spot 사용?
SLA가 없는 작업은 Spot 사용.
SLA가 있는 작업은 온디맨드 + Spot를 혼합해서 사용하자.
5
EMRFS(S3) 사용하여 데이터 셋 저장 (컴퓨팅과 스토리지 분리)?
저장공간을 위해 컴퓨팅 리소스를 사용할 필요가 없다.
6
Managed / Auto Scaling (동적 사용)?
자동 축소 / 확대로 안 쓰는 시간 비용 절감
<3> Redshift 비용 최적화.
1
Redshift 클러스트 리소스를 최적으로 활용.
2
방법 3가지
워크로드에 따른 클러스트 분리/혼합 사용 (프로비저닝 + 서버리스)
사용량에 따라 RA3 선택 (컴퓨팅/스토리지 분리)
동시성 확장 기능 활성화 (무료 사용 시간 추가)
3
워크로드에 따른 클러스트 분리/혼합 사용 (프로비저닝 + 서버리스)?
일시적 부하가 걸리는 배치 작업은 = 배치용 서버리스 사용
일시적 부하가 걸리는 보고서 생성 = 리포트용 서버리스 사용
상시 부하가 걸리는 시간별 ETL, 상시 보고서는 = Redshift Provisioned + S3 사용
데이터 쉬어링을 통해 Redshift 서버리스와 Redshift Provisioned 간 데이터 복제나 이동이 없이 데이터를 서로 액세스 할 수 있습니다.
스펙트럼을 통해 S3에 저장되어 있는 데이터도 사용할 수 있다
4
사용량에 따라 RA3 선택 (컴퓨팅/스토리지 분리)?
컴퓨팅과 스토리지가 분리되어 있는 타입, 독립적인 비용 지불.
스토리지 용량추가를 위해 더 큰 인스턴스를 사용하지 않아도 되어 비용 효율적이다.
RA3 xlplus , 4 xlarge , 16 xlarge 3가지 옵션이 있다.
5
동시성 확장 기능 활성화 (무료 사용 시간 추가)?
일시적인 클러스터를 추가하여 갑작스러운 동시 요청 급증에 대항.
각 클러스터는 하루에 최대 1시간 무료 동시성 확장 크레디트 확보.
<4> Amazon OpenSearch Service 비용 최적화.
1
리소스를 최적으로 활용하여 비용절감
2
방법 2가지?
UltraWarm / Cold Storage 사용 (최대 90% 비용 절감)
권장사항을 참고하여 전용 프라이머리 노드 인스턴스 유형 선택 (리소스 낭비 방지)
3
UltraWarm / Cold Storage 사용 (최대 90% 비용 절감)?
UltraWarm은 핫 스토리지 대신 Amazon S3와 캐싱 설루션을 사용해 성능을 개선합니다.
<5> AWS GLUE 비용 최적화
1
Glue 작업 실행 시 필요한 DPU자원을 최적으로 활용하여 비용 절감.
2
방법 3가지?
Flex 실행 옵션 (최대 35% 비용 절감)
Auto Sacling
DPU사용량 모니터링 (최적의 DPU를 결정한다.)
3
Glue 작업 실행 시 Flex 실행 옵션 사용 (최대 35% 비용 절감)?
Flex 실행은 긴급하지 않는 실행의 경우 Flex 실행 - 최대 5분,
스탠더드 드는 30~45초 스타트업 타임. 상시 가동. SLA에 민감한 경우 사용.
개발환경등에서 사용하면 좋다.
<6> Amazon S3 Cost Optimization
1
방법 3가지
가장 적합한 스토리지 클래스 사용
비활성화된 오브젝트의 자동 또는 수동 클래스 변경
S3 API 요청 비용 줄이기
2
가장 적합한 스토리지 클래스 사용?
데이터 접근 빈도 - 접근 빈도가 낮은 오브젝트는 낮은 스토리지에 저장.
저장 기간 - 최소 저장 비용 기간보다 빨리 오브젝트가 삭제되더라도 최소 저장 비용이 나온다.
동기화 대 비동기화
즉시 복구가 가능한 Glacier instant retrieval 이 있다.
Glacier Flexible Retrieval이나 Glacier Deep Archive와 같이 복구요청을 해도 바로 복구가 되지 않고 12시간 이상 복구 시간이 소요되는 클래스도 있다.
다양한 스토리지 클래스
S3 standard , S3 standard-IA , S3 Glacier Instant Retrieval 은 밀리초 접근.
S3 Glacier Flexible , S3 Glacier Deep Archive는 수분~수 시간 절감.
3
비활성화된 오브젝트의 자동 또는 수동 클래스 변경?
라이프 사이클 정책 예제
접근 패턴을 모르거나 불규칙한 데이터는 인텔리전트 티어링을 사용하는 경우가 있다.
4
S3 API 요청 비용 줄이기?
데이터를 압축하여 업로드 = API 호출비용 줄어든다.
DB자료 몰아보기
https://brunch.co.kr/@topasvga/3420
감사합니다.
