DynamoDB 인덱스 개선으로 비용 절감하기

최근 회사에서 진행한 DynamoDB 글로벌 보조 인덱스 최적화를 통해 월 2,000달러의 비용을 절감할 수 있었다

---

 

문제 : 왜 인덱스 하나의 비용이 월 2,000달러나 나오는데?

• 인덱스 프로젝션 속성이 ALL이면, 그만큼 데이터를 저장하고, 조회하고, 쓰는데 비용이 부과되었기 때문이다.

인덱스는 생성 시 함께 프로젝션(저장) 될 속성을 선택할 수 있다.

 

2024.07.20 - [분류 전체보기] - DynamoDB 알아가기(1) - 인덱스(index), 쓰로틀링(throttling)

• KEYS_ONLY: 인덱스와 같은 Key만 포함
• INCLUDE: 특정 항목을 지정하여 포함 (예: name, phone 등)
• ALL: 모든 속성 포함

 

예를 들어 user 테이블이 다음과 같다고 하자.

이때 snsId라는 값은 sns_index라는 글로벌 인덱스이고, ALL로 프로젝션 속성이 설정되어 있다.

속성	userId	snsId	point
	파티션 키	글로벌인덱스

 
이 유저는 sns Id를 보유하고 있다.
이때, ALL이라는 속성이라면, 해당 인덱스를 보유한 유저의 필드가 하나라도 변경되는 순간 인덱스 테이블까지 같이 변경된다.
예를 들어, 만약 다른 필드인 point값이 변경되는 순간, 글로벌 인덱스 테이블에 있던 point값도 변경이 일어나게 된다.
 
실제 해당 인덱스 비용의 문제 원인도 이러했다.
 
1. user 테이블에 자주 변경되는 필드가 존재한다.

• ALL 속성에 의하여 sns_index 테이블에도 같이 변경이 일어난다.

2. sns_index는 잘 쓰이지 않았다.
 
3. 대부분의 유저가 snsId를 보유했다.

• 모든 속성이 프로젝션 되다 보니, sns_index 테이블은 기본 유저 테이블과 거의 동일한 용량을 차지하고 있었다.
• RCU(읽기 용량 유닛), WCU(쓰기 용량 유닛), 데이터 저장 비용이 두 배로 증가하게 된다.

---

 

문제 해결 과정 : KEYS_ONLY 속성의 인덱스 재생성

1. 새로운 sns_id_index 인덱스를 생성한다.
   1. 기존의 sns_index는 수정이 불가능하다.
   2. KEYS_ONLY 속성을 사용하여 오직 파티션 키(userId)와 sns Id만 프로젝션 한다.
   3. WCU와 RCU를 얼마로 설정할지는 운영 시에 알 수 있기에, 우선은 기본 테이블의 값을 따라간다.
2. sns_id_index로 쿼리 해, 파티션 키(userId)와 sns Id를 조회한다
3. 이후, 해당 파티션 키(userId)를 이용해 user 테이블을 재조 회한다.

---

 

결과 : 모니터링으로 완벽한 마이그레이션 하기

수정 후 정상 마이그레이션이 되었는지 기존 sns_index의 WCU / RCU 사용량을 모니터링하고 후속 조치를 취했다.
하지만 한 번에 마이그레이션을 성공하지 못했다.
 
1. 아주 미세한 사용량 발견했다.

• 사람이 어떻게 완벽한가... sns_id_index로 마이그레이션을 놓친 로직을 발견할 수 있었다.

결국 WCU / RCU 각각이 0에 수렴하는 것을 3일 정도 지켜보고 기존 sns_index를 삭제할 수 있었다.
 
2. WCU / RCU 사용량 조절하기

• 실제 배포 전에는 어느 정도 인덱스가 읽고 쓰이는지 정확히 판단할 수 없다.
• 적은 수치로 진행했다간, 쓰로틀링이 발생할 수 있다.
• 기본 테이블의 아주 큰 수치로 설정하였다가 모니터링을 통해, 평균 WCU / RCU 치를 알아, 이 비용 또한 대폭 감소할 수 있었다.

 
이번 최적화를 통해 불필요하게 발생하던 약 월 2,000달러의 비용을 줄일 수 있었다.
고도의 기술은 아닐지라도, 간단하게라도 기존 설정을 재검토하고 최적화하는 것이 큰 변화를 줄 수 있단 걸 느낀 것 같다.