•
내 워크로드 특성에 따른 Amazon DynamoDB 비용 최적화하기
Amazon DynamoDB의 특징
•
초당 수백만 개 이상의 요청을 가변적으로 처리할 수 있다.
•
엔터프라이즈 READY
◦
테이블 사이즈가 1PB이거나 1KB이어도 사이즈에 관계없이 운영 환경의 성능에 영향을 미치지 않으며 동일한 시간에 끝나는 백업이나,
◦
최대 35일 이내에선 원하는 시간으로 데이터를 복구할 수 있는 기능
◦
동일하게 운영 환경에 성능 영향을 주지 않으면서 S3로 데이터를 추출할 수 있는 기능
•
서버리스
◦
고객의 트래픽 패턴에 따라 Auto Scaling을 사용할 수 있는 프로비저닝 모드
◦
필요한 만큼 즉시 용량을 제공하는 온디맨드 모드를 모두 지원A
Amazon DynamoDB의 비용 구조 살펴보기
•
일반적으로 컴퓨팅, 스토리지 비용이 데이터 전송 비용에 압도적이기 때문에 이 둘에 집중하는 것이 좋다.
•
프로비저닝 모드
◦
WCU, RCU 는 한시간 단위로 과금됨.
→ 스파이크성 트래픽보다는 꾸준한 워크로드가 선호된다.
◦
내가 사용할 컴퓨팅 용량을 미리 프로비저닝
◦
AWS Lambda와 비슷하게 요청 당 비용을 지불하는 차이
◦
낮에 최대 트래픽을 찍고 새벽에 최저 트래픽을 찍는 일반적인 웹 트래픽이라면 온디맨드 모드로 사용했을 때 더 많은 요금이 발생됨.
•
스토리지 비용 - 월별 GB당 과금
Computing과 Storage 옵션 소개
Computing
•
프로비저닝
◦
RCU, WCU 선택
◦
Auto Scaling 여부도 선택
▪
고정 비용이 트래픽에 따라 가변 비용으로 바뀜. → 결과적으로 비용이 줄어들게 됨.
▪
Target Utilization 기본값 70% → 이부분 설명은 아래 오토 스케일링 세션에서 설명…
◦
테이블 마다 이런 선택을 테이블 별로 해야하기 때문에 테이블을 관계형 데이터베이스처럼 엔티티 별로 만드시지 말고, 여러 개의 엔티티를 하나의 테이블에서 디자인하는 싱글 테이블 디자인을 고려해야함.
→ 시계열 데이터를 다룬다거나 하나의 테이블에서 특정 엔티티만을 주기적으로 추출해야 하는 것과 같은 몇가지 특수한 목적이 아니라면 DynamoDB에서는 작은 여러 개의 테이블보다 하나의 큰 테이블이 더 많은 장점을 갖는다.
•
온디멘드
•
Target Utilization 70%의 의미는…
◦
화면에서 실제 과금의 기준이다!
◦
파란색 선인 Provisioned Read/Write를, 주황색 선인 실제 여러분이 소비한 Consumed Read/Write보다 30%보다 더 여유있게 설정하겠다고 이해하면 됨.
◦
주황색이 70% 유지..
•
Target Utilization 90%로 설정한다면 현재보다 파란선과 주황선의 폭이 좁아지고,,, 50%로 설정하면 폭이 넓어진다.
•
비용만으로만 보면 Target Utlization을 높게잡는 것이 좋을듯 하나….
◦
실제 워크로드는 예측하기 어렵다.
→ 무조건 Target Utilization을 높이는 것은 더 많은 Throttling을 유발할 수 있다.
•
파란색과 주황색 선의 폭이 넓을 수록 실제 사용하는 것보다 많은 컴퓨팅 비용이 부과된다.
◦
사용되지 않고 남은 WCU/RCU는 현재 그림과 같이 DynamoDB 내부에 토큰이라는 개념으로 쌓이고 스파이크 트래픽이 유입되는 케이스에서 버스팅 용도로 사용될 수 있다.
•
특정 파티션에 달느 파티션보다 트래픽이 몰리는 경우, 다른 파티션에 남아있는 WCU/RCU를 즉시 빌려 사용할 수 있는 Adaptive Capacity라는 기능도 있다.
•
버스팅과 Adatpvie Capacity는 따로 설정없이 내부에서 이미 자동으로 동작하고 있는 기능
•
파티션 당 1,000 WCU와 3,000 RCU라는 컴퓨팅 용량 제약은 변하지 않기 때문에, 키 디자인이 가장 중요한 것은 변하지 않는다.
•
온디맨드 모드를 사용한다고 해서 Throttling이 완벽하게 사라지는 것은 아니다.
→ 여전히 기본인 키 디자인이 매우 중요한 이유이다.
•
온디맨드 모드로 테이블을 생성하면 내부에선 4개의 파티션으로 테이블이 시작되며, 온디맨드 모드에서는 파티션의 개수가 4, 8, 16, 32처럼 한번에 두 배씩 증가한다.
•
다만, 한번 파티션이 증가하면 약 30분 동안은 재파티셔닝이 되지 않는다.
◦
대규모 서비스 오픈 전에는 그냥 온디맨드 모드로 오픈하면 바로 장애 상황을 맞이할 수 있다.
◦
이럴 때는 프로비저닝 모드로 WCU나 RCU를 설정해 미리 파티션의 개수를 늘려 놓은 후 온디맨드 모드로 서비스를 오픈하는 전략 필요.
•
트래픽이 이전 피크 트래픽의 두 배가 될때마다, 내부에선 자동으로 파티션의 개수를 두 배씩 증가시킨다.
•
프로비저닝, 온디맨드 모드 상관없이 테이블 생성 후부터 파티션의 개수는 늘어나거나 유지되기만 하고, 사용하지 않아도 줄어들지 않는다.
•
개발이나 검증 환경처럼 하루 중 잠깐씩 사용하거나 갑자기 스파이크 치는 워크로드라면 온디맨드 모드가 적합하다.
•
워크로드가 스토리지 양은 적은데 컴퓨팅을 매우 많이 사용하는 것이라면, 보통은 예상 트래픽보다 오버 프로비저닝을 하고, 짬깐씩 유입되는 스파이크 트래픽을 대응하고, 프로비저닝 모드를 사용하며 약정할인인 Reserved Capacity를 구매해 사용하는 것이 더 비용이 적게 나옵니다.
•
여전히 예측할 수 없는 급격한 스파이크성 워크로드라면 Reserved Capacity를 사용할 수는 없지만 고객 경헙을 위해 온디맨드 모드가 적합하다.
Storage 옵션
옵션 1: 오래된 데이터 삭제
옵션 2: 데이터 분할
DynamoDB Standard-IA의 주요 장점
•
첫째, 테이블 단위의 설정 작업
◦
Standard-IA는 Standard 스토리지 클래스에 비해 스토리지 비용이 60% 저하고 컴퓨팅 비용이 20% 높다.
◦
한달에 한번은 Standard → Standard-IA로 변경 후 다시 Standard로 돌아올 수도 있다.
•
둘째, 웹 콘솔에서 클릭 한번이면 바로 변경됨.
◦
변경 중에 서비스 순단과 같은 영향도 없다.
◦
Standard와 비용 구조 이외에는 차이점이 전혀 없다.
•
셋째, 인프라 레벨에서 쉽게 변경
◦
개발자의 오버헤드가 전혀 없다.
◦
온디맨드 컴퓨팅 모드에서도 적용 가능
•
DynamoDB 테이블의 비용 구조를 보았을 때…
◦
스토리지 비용은 적고 컴퓨팅 비용(데이터에 자주 액세스)이 많이 발생하는 워크로드라면,,,
▪
Standard Class + 프로비저닝 모드 + Reserved Capacity
◦
컴퓨팅 비용은 적고 스토리지 비용이 많이 발생하는 워크로드라면,,,
▪
Standard-IA Class(아직 Reserved Capcity 지원 안함)
비용 구조 분석 방법 및 절감 포인트 소개
비용 절감 포인트
•
비용 절감 포인트는…
◦
DynamoDB를 사용하는 과정에서 비용 절감할 수 있는 포인트
◦
사용 후 비용을 최적화 할 수 있는 포인트
사용 최적화
•
어트리뷰트 이름을 줄이면 스토리지 사용량이 줄어든다.
◦
관계형 데이터베이스는 우리가 Create Table을 통해 테이블의 스키마를 지정하면,
▪
동일 테이블 내 모든 아이템(혹은 row)는 동일한 스키마를 갖는 것을 전제로 하기 때문에 실제 디스크엔 어트리뷰트 이름을 제외하고 값만 저장된다.
◦
스키마리스한 특징을 갖는 NoSQL은 모든 아이템(혹은 row)의 스키마가 다를 수 있기 때문에 스토리지에 저장할 때 어트리뷰트 이름과 값을 함께 저장한다.
•
Secondary Index를 생성 시, All이 아닌 필요한 어트리뷰트만을 선택하는 것이다.
•
변경이 자은 데이터와 자주 변경되지 않는 데이터는 아이템 레벨에서 구분할 수 있는 것이 좋다.
•
몇달에 한번 테이블에서 대량 읽기와 같이 자주 사용되지 않는 액세스 패턴을 위해 Sencodary Index를 만들기 보다는 필요할 때 S3로 Export 기능을 사용하거나 ScAN API를 사용하는 것이 비용이 덜 들수 있따.
•
A,B,C 리전에서 글로벌 테이블을 사용하고 있다고 가정하면,,,
◦
A 리전에서 테이블을 1WCU를 소비해 하나의 아이템을 추가했다면,
◦
B, C 리전에서는 가각 1RWCU를 소비해 비동기로 복제한다.
•
리전 단위의 테이블에서는 무료인 TTL 기능을 사용해서 삭제
•
ACID를 지원하는 트랜잭션 기능은 내부적으로 2-Phase 커밋을 통해 실행됨에 따라, 동일 요청을 Batch API로 실행할 때보다 WCU/RCU 비용이 2배로 증가
→ 모든 Batch API를 트랜잭션으로 변경하기 보다는 일부 트랜잭션이 정말 필요한 부분에 사용을 고려해야 한다.
•
Strongly Consistent Read는 Eventually Consistent Read보다 2배 비쌈.
사용후 비용 절감
•
현재는 Standard Class + 프로비저닝 모드만 지원 (’23 2월 기준)
•
두 개의 컴퓨팅 모드는 하루에 한번씩 변경 가능하다.
•
Key-Value NoSQL에서는 Throttling을 0으로 만드는 것은 불가능하다
→ 키 디자인이 정말 중요하다.