DynamoDB Index 이해하기 | LSI, GSI 그리고 Index와 Throttling

들어가며

지금까지 DynamoDB의 기본 개념과 WCU·RCU, 그리고 트래픽 관리 방법에 대해 알아보았습니다.

 

하지만 DynamoDB를 사용하다 보면 기본 Partition Key만으로는 원하는 데이터를 조회하기 어려운 경우가 있습니다. 예를 들어 사용자 ID는 알고 있지만 이메일로 조회하거나, 주문 날짜를 기준으로 데이터를 조회해야 하는 상황이 발생할 수 있습니다.

이때 사용하는 기능이 바로 Secondary Index입니다.

 

이번 글에서는 DynamoDB의 Index 개념과 LSI(Local Secondary Index), GSI(Global Secondary Index)의 차이, 그리고 Index가 Throttling과 어떤 관계가 있는지 알아보겠습니다.

---

1. Index란?

https://www.scaler.com/topics/aws/dynamodb-indexes/

Index는 기존 테이블과 다른 Key를 사용하여 데이터를 조회할 수 있도록 만든 보조 조회 구조입니다.

예를 들어 사용자 테이블의 Partition Key가 user_id라고 가정해보겠습니다.

user_id	email	name
user001	a@test.com	Kim
user002	b@test.com	Lee

기본 테이블에서는 user_id로만 조회할 수 있습니다. 하지만 이메일을 기준으로 사용자를 조회해야 한다면 기본 Key만으로는 조회할 수 없습니다. 이때 email을 Index로 생성하면 이메일을 이용한 조회도 가능해집니다.

즉, Index는 조회 가능한 기준(Key)을 추가하는 기능이라고 이해하면 됩니다.

---

2. LSI(Local Secondary Index)

https://www.wakuwakubank.com/posts/639-aws-dynamodb-introduction

LSI(Local Secondary Index)는 기본 테이블과 동일한 Partition Key를 사용하면서 Sort Key만 변경할 수 있는 Index입니다.

예를 들어 게시글 테이블이 다음과 같다고 가정해보겠습니다.

기본 테이블

• Partition Key : user_id
• Sort Key : CreatedAt

즉, 기본 테이블에서는 특정 사용자의 게시글을 작성 시간(CreatedAt) 기준으로 조회할 수 있습니다.이때 이미지처럼

Partition Key는 그대로 UserId를 유지하고, Sort Key를 PostId로 변경한 LSI를 생성할 수 있습니다.

 

기본 테이블

• UserId + CreatedAt
• 특정 사용자의 게시글을 작성일 순으로 조회

LSI

• UserId + PostId
• 특정 사용자의 게시글을 게시글 ID 기준으로 조회

이처럼 LSI는 같은 Partition Key를 사용하는 데이터에 대해 다양한 정렬 기준을 제공하는 기능입니다.

 

LSI 특징

• 기본 테이블과 동일한 Partition Key를 사용한다.
• Sort Key만 변경하여 새로운 조회 기준을 제공한다.
• 테이블 생성 시에만 생성할 수 있다.
• 기본 테이블과 같은 파티션에 저장된다.
• 동일한 사용자의 데이터를 여러 기준으로 조회할 때 적합하다.
• 결과적으로 하나의 사용자(UserId)에 대해서는 두 가지 조회 방식이 가능해집니다.

---

3. GSI(Global Secondary Index)

https://www.wakuwakubank.com/posts/639-aws-dynamodb-introduction

GSI(Global Secondary Index)는 Partition Key와 Sort Key를 모두 변경할 수 있는 Index입니다.

• 기본 테이블의 Primary Key는 다음과 같습니다.
  • Partition Key : UserId
  • Sort Key : CreatedAt
  즉, 기본 테이블에서는 특정 사용자의 게시글을 작성일 기준으로 조회할 수 있습니다.
  • UserId = user001
  이라면 해당 사용자가 작성한 게시글 목록을 조회할 수 있지만, 게시글 ID(PostId) 만 알고 있는 경우에는 원하는 데이터를 바로 조회할 수 없습니다.

기본 테이블

• UserId + CreatedAt
• 특정 사용자의 게시글을 작성일 순으로 조회

GSI

• Partition Key : PostId
• 게시글 ID만으로 게시글 조회

즉, 기존에는 사용자(UserId)를 알아야만 데이터를 조회할 수 있었지만, GSI를 생성하면 PostId만으로도 원하는 게시글을 바로 조회할 수 있습니다.

 

이처럼 GSI는 기본 테이블과 완전히 다른 Partition Key를 사용할 수 있기 때문에 새로운 조회 패턴을 추가하는 데 사용됩니다. 따라서 이메일, 주문번호, 게시글 ID처럼 다양한 기준으로 데이터를 조회해야 하는 서비스에서 많이 활용됩니다.

 

GSI 특징

• Partition Key와 Sort Key를 모두 변경할 수 있다.
• 테이블 생성 이후에도 추가 및 삭제할 수 있다.
• 기본 테이블과 별도의 Index로 관리된다.
• 새로운 조회 기준이 필요할 때 가장 많이 사용되는 Secondary Index이다.
• 기본 테이블에 데이터가 저장되거나 수정되면 GSI도 함께 갱신된다.

---

4. LSI와 GSI 비교

구분	LSI	GSI
Partition Key 변경	불가능	가능
Sort Key 변경	가능	가능
생성 시점	테이블 생성 시만 가능	언제든 생성 가능
저장 위치	기본 테이블과 동일한 Partition	별도 Index
활용도	제한적	매우 높음

LSI는 같은 사용자 안에서 다른 기준으로 정렬하고 싶을 때 사용하고,

GSI는 새로운 조회 기준 자체를 추가하고 싶을 때 사용합니다.

---

5. Index와 Throttling의 관계

https://joudwawad.medium.com/dynamodb-indexes-deep-dive-afe86a1cac48

GSI는 단순히 조회 기능만 추가하는 것이 아니라 기본 테이블의 데이터를 다른 Key 구조로 저장하는 별도의 Index입니다.

예를 들어 기본 테이블에 새로운 게시글을 저장하면 데이터는 기본 테이블에만 저장되는 것이 아니라, GSI에도 함께 저장됩니다.

즉, 하나의 Write 요청이 발생하면 다음과 같은 작업이 자동으로 수행됩니다.

• 기본 테이블에 데이터 저장
• GSI에 동일한 데이터 저장

따라서 GSI를 생성하면 기본 테이블뿐 아니라 GSI도 함께 업데이트해야 하므로 추가적인 쓰기 처리량(WCU)이 사용됩니다. 또한 GSI를 여러 개 생성할수록 업데이트해야 하는 Index도 많아져 더 많은 처리량이 필요합니다.

 

읽기 요청에서도 특정 GSI에 트래픽이 집중되면 Throttling이 발생할 수 있습니다.

예를 들어 주문 정보를 저장하는 테이블이 있고, 주문 상태(order_status) 를 Partition Key로 사용하는 GSI를 생성했다고 가정해보겠습니다.

주문 상태는 다음과 같은 값을 가질 수 있습니다.

• PAYMENT_COMPLETED
• SHIPPING
• DELIVERED

그런데 관리자 페이지에서는 배송 준비가 필요한 주문을 확인하기 위해 대부분 다음과 같은 조회를 수행합니다.

order_status = PAYMENT_COMPLETED

결과적으로 수많은 사용자의 조회 요청이 모두 PAYMENT_COMPLETED Partition Key에 집중됩니다.

 

이 경우 기본 테이블은 정상적으로 동작하더라도, GSI의 PAYMENT_COMPLETED 파티션만 처리량을 초과하여 Throttling이 발생할 수 있습니다. 따라서 GSI를 설계할 때는 조회 요청이 특정 Partition Key에만 집중되지 않는지 함께 고려해야 합니다.

---

6. 마치며

이번 글를 정리하며 DynamoDB의 Index는 단순히 조회 속도를 높이기 위한 기능이 아니라, 서비스에서 필요한 다양한 조회 패턴을 지원하기 위한 데이터 구조라는 점을 이해할 수 있었습니다.

 

특히 LSI는 동일한 Partition Key를 유지하면서 Sort Key만 변경하여 같은 데이터에 대해 다양한 정렬 방식을 제공하고, GSI는 새로운 Partition Key를 사용할 수 있어 기본 테이블에서는 불가능했던 조회 패턴을 추가할 수 있다는 차이를 알게 되었습니다.

 

또한 Index는 별도의 조회 구조이지만 기본 테이블과 함께 관리되기 때문에 데이터를 저장하거나 수정하면 Index도 함께 갱신되며, 이 과정에서 추가적인 읽기·쓰기 처리량이 사용된다는 점도 확인할 수 있었습니다. 따라서 Index를 많이 생성하거나 특정 Index에 조회가 집중되면 Throttling이 발생할 수 있으며, 이를 방지하기 위해서는 조회 패턴을 먼저 분석하고 적절한 Partition Key를 설계하는 것이 중요하다는 점을 배웠습니다.

 

이번 내용을 통해 DynamoDB에서는 데이터를 저장하는 방식뿐만 아니라 어떻게 조회할 것인지까지 함께 고려하여 테이블과 Index를 설계해야 안정적인 성능과 비용 효율을 모두 확보할 수 있다는 점을 이해할 수 있었습니다.