DynamoDB를 이용해 Ranking 구하려다 삽질만 하다.

시작은 아래에서 부터..

http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/GSI.html

몇 일 전 동료가 Ranking을 구하는데 scheduler를 돌리겠다고 했다. 

GSI 개념을 언뜻 알고 있던 난, 그거 왜 함? 그냥 GameTitle에 GSI hasy key걸고 Score에 GSI Range Key 걸고 query하면 바로 나올껄? Scheduler나 Processor Job 만드는 것보다 훨씬 쉬운거 아님?

그 후 3일 간의 삽질이 시작되었고 동료와 난 DynamoDB에 Deep(?) Dive했다.

DynamoDB 참 매력적인 녀석이다, 비용은 비싸기는 하지만 Infra 운영 필요 없이 Sharding, Replication, H/A 모두 지원해준다. 사실 Cassandra로 이미 구축 되어 있는 시스템을 DynamoDB로 Integration 중이였다. 이유는 Cassandra 운영을 위해 컨설팅 비용, 운영 인력 충원 비용이나 DynamoDB 운영비용이나 크게 차이 나지 않을 것 같았고 다른 부서에서 DynamoDB로 Integration 했다는 소문에 팔랑귀를 가진 우리는 흔들렸다.

차근 차근 알아 보자

• AWS 문서의 Game Score 방법이 가능 한 것 인가?
• 가능하다. 하지만 제한된 환경에서 가능하다.

• GSI는 무엇인가?
• DynamoDB의 index는 두 가지 종류가 존재한다. Hash Key, Range Key. Range Key는 Hash Key의 보조 인덱스로 반드시 Hash Key와 짝을 이룬다. Table 생성 시 Hash Key는 필수로 지정되어야 하고 Range Key는 Optional이다. 이후 생성된 Table에 Index를 추가 할 수 있는데 GSI와 LSI이다. LSI의 경우는 Table의 Primary Hash Key를 그대로 사용하고 RangeKey만 달리 사용 하는 경우이다. GSI는 Table에 또 하나의 Hash Key와 Range Key를 지정 할 수 있다.

• Hash Key란?
• DynamoDB는 Partition 크기가 10G가 넘거나, Provisioning Throughput이 일정 수준 이상이 되면 Data에 대한 Partition을 나눈다. (Shading을 수행한다) Partition을 나눌 시 기준이 되는 Key가 Hash Key이다. Hash Key가 중복 되어 있는 Data는 한 Partition에 저장된다.

• 엇, 그럼 문제가 생길 수 있지 않은가?
• 그렇다. 우리 문제도 여기서 시작되었다. 이론적으로 한 Key를 가진 데이터는 10G가 이상 가지지 못한다. 하지만 우리 데이터는 한 payload에 100byte 수준으로 현실적으로 10G를 채울 수 없었다. 우리 문제는 Throughput이였다. 

• 좀 더 자세히..
• DynamoDB는 많은 양의 요청이 들어오면 병렬 처리를 위해 Partition 나눈다. 하지만 hash key가 같다면 Partition을 수행하지 못한다. 즉, 한 Hash Key가 같은 데이터에 요청 할 수 있는 Throughput은 한 Partition이 지원하는 Throughput을 넘지 못한다.

• 한 Partition이 지원하는 Throughput은?
• 쓰기 1000 (1초에 1KB payload를 1000번 쓰기 수행)
• 여담이지만 이를 위해 Queue는 필수 인 것 같다.
• 읽기 3000 (1초에 4KB payload를 3000번 읽기 수행)

• 그런데 GSI가 이것과 무슨 상관?
• 내부적으로 GSI의 Hash Key와 Range Key를 가지는 또하나의 Table을 생성한다. 그리고 Root Table에 쓰기가 발생 하면 GSI Table에 계속적으로 copy가 읽어 난다. 그래서 GSI를 만들면 Throughput 비용이 두 배 발생한다. Root Table의 Hash Key는 분산 되에 요청 Throughput을 감당 할 수 있어도 동일한 GSI의 Hash Key에 몰리는 Throughput은 버티지 못한다. 참고 : https://blogs.aws.amazon.com/bigdata/post/Tx3KPZDXIBJEQ4B/Scaling-Writes-on-Amazon-DynamoDB-Tables-with-Global-Secondary-Indexes

• 결국 우린 POC, 검색, AWS 질의에 3일을 보냈고 결국 불가하다는 결론을 내렸다. 물런 쓰기 1000 unit을 넘지 않은 환경에서는 아주 좋은 선택이 될 수 있을 것 같지만 우리 환경은 불행히도 그러지 못하였다.

사실 쓰고 보니 AWS 문서에 다 나와 있는 내용이고 기본중에 기본이 아닌가. 항상 문서 부터 정독하고 시작할 마음의 여유가 있으면 좋겠다.