[AWS] DynamoDB: Effective Dynamo

DynamoDB를 성능/비용 효율적으로 설계하고 사용하는 방법을 간단히 정리해본다.

온디맨드 VS 프로비저닝

DynamoDB의 가장 큰 장점은, 온디맨드가 실제 사용량을 기반으로만 비용이 청구된다는 것이다. 사용량에 맞춰서 자동으로 확장되며, 사용하지 않거나 무료 사용량 이내에서만 쓴다면 비용이 거의 $0로 나온다.
이상적인 서버리스 시스템의 대표적인 예라고 할 수 있다.

사용량이 일정하다면 프로비저닝이 나을 수도 있지만, 온디맨드 모드가 SPIKE 트래픽 등을 처리하기엔 더 용이하다.
그래서 나는 온디맨드를 좀 더 권장한다. 온디맨드를 써보다가 사용량이 일정한 것 같다면 그때 프로비저닝으로 전환해도 된다. 프로비저닝이 이상적인 경우에는 최대 6-7배 정도 저렴할 수 있다.

처리량 제한

DynamoDB는 거의 무제한으로 처리량을 확장할 수 있지만, 진짜 무제한은 아니다. 제한사항들이 좀 있어서 이걸 좀 감안하고 사용해야 한다.

프로비저닝 모드라면 원하는 만큼 처리량을 지정할 수 있고, 온디맨드를 사용한다면 4000 WCU부터 시작해서 요청한다면 원하는 만큼 무제한으로 처리량 제한을 늘리는 것이 가능하다.
하지만 파티션 단위로는 늘릴 수 없는 제한이 있다. (3000 RCU, 1000 WCU) <- 중요하다.

할당량 늘리기

DynamoDB는 계정 수준에서 최대 처리량에 제한이 걸려있다.
늘려달라고 요청하면 늘려주니까, 부하가 많을 것 같다면 잔뜩 올려놓는게 좋다.

요청하면 늘려준다.

파티션 구조와 핫 파티션

DynamoDB는 기본적으로, CassandraDB와 비슷한 내부 구조를 갖고 있다고 보면 된다.
"파티션 키"와 "정렬 키"로 구성되는데, "파티션 키"를 기준으로 어떤 파티션에 분산해서 저장할지를 결정한다.

DynamoDB 자체는 읽기/쓰기 처리량을 무제한으로 확장할 수 있지만, 파티션 단위로는 제한이 있다.
파티션 별 초당 3000 RCU, 1000 WCU 정도로 HARD LIMIT이 걸려있고, 만약 특정 파티션에만 작업이 몰린다면 스토틀링이 걸리게 된다.
그래서 고부하 시스템에서는 단일 파티션에 과한 작업이 몰리지 않도록 분산하는 것이 중요해진다.

쓰기 최적화: 파티션 샤드

부하를 분산시키고 처리량을 진짜 무제한으로 늘려야 한다면, 파티션 키를 A#1, A#2 같은 식으로 마개조해서 고르게 분산시키는 꼼수가 필요해진다.

https://aws.amazon.com/ko/blogs/tech/alipeople-modernization-1/
이걸 파티션 샤딩이라고 부른다. 샤드 키를 기준으로 파티션 키를 동적으로 만들고 집어넣는 것이다.

이러면 다시 샤드 단위로 파티션이 분산되기 때문에, 핫 파티션 현상을 완화할 수 있다.
다만 이러면 읽을때 처리가 굉장히 불편해진다는 단점이 있다...

Bulk Write: BatchWriteItem API

당연하지만, 쓰기를 하나씩 하는것보단 묶어서 하는 것이 빠르다.
DynamoDB도 배치 쓰기 API를 제공하며, 이걸 쓰면 좀 더 빠르게 대량 쓰기를 처리할 수 있다.

근데 유의해야할 점은, 이걸 쓴다고 해서 처리량을 늘릴 수 있는 것은 아니라는 것이다. 10개를 Batch로 동시에 쓰는 것과, 1개를 10번씩 날리는 것은 동일한 WCU를 소모한다.
더 빠르게 넣기 때문에 WCU를 소모해서 더 빠르게 스토를링이 걸릴 수도 있다.

warm throughput 설정

다이나모에는 웜 스루풋이라는 것이 있다.
다이나모를 SPIKE 트래픽을 감당하기 위해서 자동으로 스케일아웃을 하지만, 딜레이가 있다보니 경우에 따라서는 스로틀링이 걸릴 수도 있다.

웜 스루풋은 그걸 위한 세부 조정 옵션이다.
미래의 스파이크 트래픽을 예상해서 "이 정도 갑자기 확 쓸 수 있을 것 같다"고 알려주는 것이다.

기본값은 이렇게 되어있는데, 실제로 트래픽이 늘어난다면 자동으로 증가한다.
그리고 한번 올라간 값은 내려가지 않는다.

하지만 직접 값을 올려놓을 수도 있는데, 그러면 나중에 SPIKE 트래픽이 들어와도 스케일링 딜레이를 적게 가져가면서 처리를 할 수 있다. 그 대신 추가 비용이 발생한다.
다만 이게 진짜 스케일링을 물리적으로 하는건 아니고, 미리 준비만 하는 느낌이다.

그리고 비용적으로 그렇게 부담이 되진 않는다. 늘린다고 해서 비용이 계속 누적되는건 아니고, 일회성 비용이다.
수동으로 증가시킨 유닛당 USD 0.00013 정도를 뜯고 끝난다.

복잡한 읽기

복잡한 필터링 기능이나 집계 등이 필요해진다면, 사실 그건 DynamoDB에 맞지 않는 접근법이다. 다이나모는 파티션 단위로만 접근해서 조회하는 것에 최적화되어있다. 그 영역을 벗어난다면, 성능적으로도, 비용적으로도 별로 좋지는 않다.

다행히 DynamoDB는 다른 시스템과의 통합이 꽤 잘 설계되어있어서, DynamoDB를 데이터 소스로 삼고 실제 복잡한 조회는 다른 시스템으로 부어서 돌리는 사용 패턴이 꽤 괜찮을 수 있다.

대형 데이터셋에 대한 집계가 필요하다면 Athena와의 조합이 상당히 좋다.
https://blog.naver.com/sssang97/224294652868

비용 최적화

DynamoDB는 비용을 줄일 수 있는 수단을 몇가지 제공한다.

Saving Plan

가장 간단한 비용 절감안은 Saving Plan For Database가 있다.
미리 원하는 만큼 달러를 선결제해두면, 거기서 차감하면서 할인을 해주는 형태다.
온디맨드의 경우에는 18% 정도 깎아준다.

https://aws.amazon.com/ko/savingsplans/database-pricing/

Table Class - IA(Infrequent Access) Class

DynamoDB는 S3처럼 스토리지 계층이 나뉘어있다.

이렇게 테이블 생성 단계에서 선택할 수 있다.

IA라는 스토리지를 선택하면, 스토리지 비용이 좀 더 저렴한 대신 읽기/쓰기 비용이 비싸진다.
그래서 데이터 양이 많지만 읽기/쓰기가 많지 않은 백업형 데이터에 더 적절하다.

IA를 쓰면 저장비용이 기존 대비 2.5배쯤 저렴해진다.

대신 읽기/쓰기 비용은 1.2배쯤 비싸다.

TTL

다이나모는 TTL 기반의 삭제 기능을 기본적으로 제공한다.
영속성이 필요한 데이터가 아니라면 이걸 사용해서 스토리지를 절약하는 것도 좋은 접근법이다.
게다가 무료 기능이라서 부담없이 쓰기 좋다.
https://blog.naver.com/sssang97/223346539870

참조
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html
https://stackoverflow.com/questions/53843829/what-tps-can-dynamodb-handle
https://aws.amazon.com/ko/blogs/tech/alipeople-modernization-1/
https://aws.amazon.com/ko/blogs/tech/sec-cloud-amazon-dynamodb-cost-optimization-journey/
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/warm-throughput.html
https://aws.amazon.com/ko/blogs/tech/how-to-optimize-amazon-dynamodb-costs/