DynamoDB에 대한 생각(개인적인 의견)

DynamoDB는 fully managed serverless NoSQL db이다. 서버리스라는 특징이 내가 특별히 관리하지 않아도 aws에서 해주는 것들이 많다. 심플한 데이터 백업과 복원, Encryption기능 지원, IAM Role 기반 접근제어, SSD에 저장하여 보장된 속도(사실 몽고디비랑 큰 차이는 모르겠다), 간단한 스케일 조정 등의 장점이 있다.

그러나 난 사용하면서 매우 난처하고 고생 스러웠던 점들이 있었다. 장점도 많으나 두드러지게 제한된 것들과 아쉬운 것들이 많았다.

1. 특이하고 제한적인 Key체계

dynamoDB에는 두가지 유형의 key체계가 있다.
하나는 우리가 일반적으로 알고 있는 primary key이고 다른 하나는 hash key와 range key를 동시에 사용하는 방식이다.

PK방식을 사용하면 테이블 내에 각 아이템들은 다른 pk를 가지고 있다. rdb의 pk와 같고 mongodb의 _id와 같다고 봐도 될듯하다. 사실 차이는 있는 듯하다. DynamoDB에서는 pk가 hash방식으로 저장되는 위치를 나타낸다고 하는데.. 어플리케이션을 만드는 입장에서 속도가 크게 차이 없으니 그리 특별함을 모르겠다.

Hash & Range key 방식을 처음 보고 맨붕이 왔다. 도무지 이해가 안됐다. (사실 지금도..) 내가 지금까지 이해 한바로는 Hash Key는 저장을 하는 위치를 나타내고 Range Key는 같은 Hash Key 내에서 순서를 나타낸다고 한다고 한다. 이 두개의 키를 조합해서 각 item을 구분한다. 즉, hash와 range key가 같은 두개의 아이템음 없다는 것이다. (처음에 이걸 잘못 이해해 삽질을 많이했다. 문서를 차근차근 잘 읽어야 했었다....)

사실 여기까지만 보면 이상이 없아 보인다. 키는 모든 디비에 필요하고 잘 만 지정하면 되니 말이다.

2. Query와 Sorting의 문제

query를 할 때 키 값이 꼭들어가야한다. key값을 넣지 않고 query할 수 없다... 그리고 sorting은 특정 hash 내에서만 range key만을 활용해서 할 수 있다.

다른 디비는 그냥 index만 잡으면 sorting할 수 있는 거에 비해 많이 제한적이다.

전체 데이터에 대해서 sorting하려고 할때 는 Global Secondary Index라는 Index를 지정해야 하는데 이를 위해서 모든 아이템에 의미 없는 값을 넣어야 했다. 자세한건 다른 포스트에서 다뤄 볼까한다.

3. Batch를 하기 매우 어렵다.

Batch로 insert는 25개가 최대다. 그리고 batch update는 없다. mongodb를 사용할 때는 조건만 주고 update가 가능하나 DynamoDB는 하나의 아이템만 변경할 수 있다.
처음에 설계를 잘못해서 전체 아이템에 attribute 하나를 추가할때 하나씩 변경하는 배치 프로그램을 짜서 돌려야 했다.. 다른 db는 명령어 하나면 될것을...

4. db tool이 없음

dynamoDB 테이블을 보려면 aws console로만 볼 수 있다. 그외 방법은 cli와 coding이 있다....
어떤 착한분이 오픈소스로 툴을 만들어 주기를 바래본다.

5. 생각 보다 높은 학습 곡선

우리가 친숙하게 사용했던 DB와는 다른 개념들이 많다. 그리고 여러가지 제약이 많기 때문에 될거 같은 것들 안되는 경우가 많다. 그래서 내가 원하는 기능을 구현하기 위해서는 생각 보다 많은 양의 자료를 보고 공부해야한다.

6. 마지막으로 자료가 별로 없다.

특별히 공개해놓은 자료가 많지 않았다. 나는 Go로 개발을 했는데 Go를 활용해서 DynamoDB연동을 한 예제도 찾기 힘들었고.. 대부분 nodejs가 많았다. 때문에 aws document를 보고 다 했다. 문서는 또 다 영어다.. ㅠ 한글 번역은 볼 수 없는 상태니.. 영어로 보는게 더 낫다.

그럼에도 사용할 만한 이유

너무 단점을 많이 썼나 싶다. 그럼에도 dynamodb를 사용하는 건 역시 fully managed인 듯하다. db 만 관리하는 사람이 없는 환경에서는 확실히 장점이 크다.

그리고 aws의 다른 서비스와 연계하여 서비스를 개발할때는 dynamodb를 사용하는 게 좋다. 접근제어도 간단하게 IAM role을 부여함으로써 간단하게 할 수 있다.
특히 AWS SAM(Serverless Application Model)을 사용할 때는 간단하게 template파일을 작성하면 테이블 구성도 다 해주니 매우 편하다.

처음에 익숙해지는 데까지 시간이 좀 걸리긴하나. 익숙해지면 그렇게 어렵게 느껴지지는 않는다.

다 구현하고 나서 이제 관리에대한 부담이 느껴지지 않는 것도 장점이다. 스케일 업다운도 간단하게 가능하고, 데이터 백업과 복구가 간단하고, 보안에 대한 걱정도 없다.

결론

개인적인 의견으로 회사내에 전담으로 db관리자와 인프라 관리자가 별도로 없다면 써볼만 하다.
그렇다고 적극 추천하지는 못하겠다.
일단 간단한 기능 개발에 한번 써보고 판단해 보는 것도 나쁘지 않을 것 같다.
상황에 따라 개발 복잡도에 따라 기능 요구도가 적합한지 잘 따져 보고 써야 할 듯하다.
예를 들어 url shortener와 같이 순서가 특별히 중요하지 않고 빠른 검색이 필요하다면 dynamodb가 적합할 것이다. 하지만 다양한 방식으로 sorting이 필요한 데이터라면 아무래도 다른 db를 사용하는 것이 더 좋을 듯하다.