DynamoDB는 AWS에서 제공하는 관리형 NoSQL 데이터베이스 서비스입니다. NoSQL이 갖는 장점과 쉬운 사용성, 그리고 빠른 성능과 자동 확장 기능을 갖는데요.
DynamoDB의 장/단점에 대해 이해하고 제대로 사용하기 위해 꼭 필요하다고 생각하는 DynamoDB의 Read / Write Capacity에 대해 알아보고 제 생각을 정리해 봤습니다.
아젠다
- DynamoDB의 장점 / 단점
- Read / Write Capacity 조절의 필요성
1. DynamoDB의 장점 / 단점
제가 사용하면서 느꼈던 장점과 단점을 몇 가지 짚어볼게요.
장점:
- 데이터 모델링: 데이터 모델링이 유연합니다. 컬럼을 자유롭게 추가/삭제할 수 있고 데이터 타입도 다양하게 사용할 수 있어요.(JSON)
- 완전 관리형 서비스: 서버 관리에 대해 신경 쓰지 않아도 돼서 편리합니다.
- 자동 확장성: 애플리케이션이 성장함에 따라, 읽기/쓰기 요청이 폭발적으로 증가할 때도 자동으로 확장되니까 트래픽 변화에 유연하게 대응할 수 있습니다.
단점:
- 비용: 사용량이 적을 때는 저렴하지만, 대규모로 사용하게 되면 비용이 빠르게 증가할 수 있습니다. 특히 Read/Write Capacity를 제대로 관리하지 않으면 불필요한 비용이 발생할 수 있습니다.
- 트랜잭션 지원 제한: DynamoDB는 기본적으로 단순 조회나 삽입, 삭제 작업에 최적화되어 있지만, 복잡한 트랜잭션을 처리하는 데는 다소 한계가 있습니다.
2. Read / Write Capacity 조절의 필요성
DynamoDB를 사용하면서 가장 중요한 부분 중 하나가 바로 Read / Write Capacity 조절입니다. 비용 및 성능과 직결되어 있기 때문인데요.
DynamoDB는 크게 두 가지 Capacity 모드로 작동합니다.
- 프로비저닝 모드: 필요한 용량을 미리 설정
- 온디맨드 모드: 사용량에 따라 자동 확장
비용이 문제가 되지 않는다면 너무 쉽게 온디맨드를 선택해 사용할 수 있을 것입니다.
하지만 두 모드에 대해 가격을 계산해 보니 동일 요청에 대해 온디맨드가 7.5배 정도 비싸다는 것을 확인했습니다. (Dynamodb prices) - 쓰기 100만 건, 읽기 100만건 가정
따라서, 프로비저닝 모드를 사용해야 합니다;.
여기서 다행인 점은 프로비저닝 모드에서 Auto Scaling을 지원한다는 점입니다.
Read / Write Capacity를 정확히 산정하지 못하더라도 Auto Scaling 옵션을 사용해 자동으로 조정할 수 있습니다.
하지만 이 옵션만을 믿고 DynamoDB를 사용하다 보면 예상치 못한 비용이 발생할 수 있습니다.
너무 많은 요청을 DynamoDB가 처리한다면 많은 RCU (Read Capacity Units) / WCU (Write Capacity Units)를 사용할 수 있습니다.
DynamoDB에 요청을 추가할 때 항상 이 부분을 염두에 둬야 한다고 생각합니다.
극단적 예시로 오히려 Read/Write Capacity를 고정해 두고 사용한다면 무분별한 사용으로 많은 부하가 들어올 때 Latency가 증가하고 이때 Read / Write Capacity가 조절할 수 있을 것입니다.
저의 생각을 정리하자면 초기에 Read/Write Capacity를 정확하게 산정할 수 없을 때 프로비저닝 모드의 Auto Scaling을 적극적으로(최소 / 최대 크게) 사용하되, 서비스가 안정화되면 Auto Scaling를 소극적으로(최대 작게) 사용하는 게 좋다고 생각합니다. (Auto Scaling은 적게 사용할 때 Scale in 함으로 써 비용을 절감할 수 있기도 함)