[reinvent 2024] Amazon DynamoDB를 위한 데이터 모델링 핵심 개념

들어가며

DynamoDB의 구조에 대해 얼마나 많은 관심이 있으신가요?
이번 세션을 통해 DynamoDB의 구조에 대해 이해하였고 이에 대한 내용을 소개드리고자 합니다.

먼저, 아래의 사진을 DynamoDB로 생각해보면 어떻게 생각드시나요?
DynamoDB 데이터 모델링이 전화번호부처럼 작동하는 방식을 비유로 설명하겠습니다.

만약 전화번호부 책을 꺼내 들고 성으로 정렬된 목록에서 원하는 사람의 이름을 찾고 그 옆에 있는 전화번호를 확인해다고 생각하면 어떨까요? 예를 들어 ‘J’로 가서 Jason을 찾고, Jason의 성을 찾아 그의 전화번호를 알 수 있습니다.

이처럼 해당 내용만 상상으로만 시각화한다면 어려울 수 있습니다. 아래 사진을 보시면 이러한 설명에 대한 이해를 하실 수 있습 니다.

여기서 꼭 이해해야하는 중요한 부분이 있습니다. 
사진에서 보이는 것처럼 Las Vegas을 DynamoDB에서 파티션 키라고 부릅니다. 그 다음 중요 요소는 정렬 키가 있으며 이는 이름으로 정렬됩니다.

파티션 키와 정렬 키는 생소할 수 있지만 매우 중요한 역할을 하는데요 이에 대해 조금 더 상세히 알아보겠습니다.
파티션 키는 데이터를 그룹화 하는 기준이 되는 값 입니다. 예를 들어 전화번호부에서는 성을 기준으로 데이터를 그룹화 할 수 있습니다.

정렬 키는 파티션 키 내부에서 데이터를 정렬하는데 사용됩니다.
전화번호부에서 성을 기준으로 정렬한 후 이름을 추가로 정렬한다고 생각할 수 있습니다.
여기서 여러 성을 볼 수 있으며 그 뒤에는 전화번호, 우편번호, 엔터티 유형과 같은 정보가 포함됩니다.

만약 도시에 대한 정보를 찾으라는 요처에 성과 이름을 알고 있다면 어떨까요?
이 경우 마치 이진 탐색처럼 책을 열어 원하는 항목을 빠르게 찾아낼 수 있습니다. 
예를 들어 Hunter라는 성을 알고 있다면 그 성의 그룹(파티션)만 열어서 데이터를 빠르게 검색할 수 있습니다.
또한 이름도 알고 있다면 그 그룹 내에서 이진 탐색처럼 정렬 키를 사용해 데이터를 빠르게 찾을 수 있습니다.

예를 들어 “모든 Hunter” 또는 “모든 Shriver”를 찾으라는 요청이 있다면, 성을 기준으로 데이터를 그룹화했기 때문에 원하는 데이터를 빠르게 검색할 수 있습니다.

하지만 성이나 이름을 모른 채 단순히 “모든 Jason을 찾아라”라는 요청이 들어오면 데이터가 그런 기준으로 정렬되어 있지 않기 때문에 책 전체를 뒤져야 하기 때문에 많은 어려움이 있을겁니다.

파티션 키와 정렬 키의 개념은 Amazon DynamoDB와 밀접하게 연결되어 있습니다.
DynamoDB는 NoSQL 데이터베이스로 데이터를 효율적으로 저장하고 검색하기 위해 파티션 키와 정렬 키를 기본적으로 사용합니다.

DynamoDB를 효과적으로 사용하기 위해서는 아직 더 알아야 하는 개념이 있습니다.

추가적으로 알아보겠습니다.

DynamoDB – LSI, GSI 에 대해

DynamoDB를 효과적으로 사용하기 위해서는 LSI(Local Secondary Index)와 GSI(Global Secondary Index)를 알아야 합니다. 두 개념 모두 DynamoDB의 데이터 검색과 성능 최적화를 위한 필수적인 요소 입니다.

아래 사진은 LSI의 예시를 보여주는 사진이며 이에 대해 소개해드리겠습니다.

로컬 세컨더리 인덱스(LSI)는 테이블의 기본 파티션 키를 유지하면서 추가적으로 다른 정렬 키를 정의할 수 있는 인덱스 입니다. 기본 테이블과 같은 물리적 파티션을 공유하며 같은 파티션 키 내에서 데이터를 정렬하고 검색하는데 유용합니다. 

LSI 특징으로는 기본 테이블의 파티션 키를 변경하지 않고 정렬 키만 추가적으로 설정하기에 파티션 키를 유지할 수 있으며 동일한 파티션 키 안에서 데이터를 여러 정렬 기준으로 검색할 수 있습니다.

위 사진으로 활용 사례를 살펴보면 아래와 같습니다.

1. 파티션 키 : City
2. 정렬 키 : Entity (Casino, Hotel)
3. LSI 정렬 키 : Name (이름) – Venetian, JW Marriott

LSI를 알아보았으니 이제 GSI에 대해서도 알아볼 차례인데요 아래 사진을 통해 설명드리겠습니다.

GSI(Global Secondary Index)는 DynamoDB 테이블의 데이터를 다른 기준으로 검색할 수 있도록 해주는 인덱스 입니다. 기본 테이블의 파티션 키와 정렬키와는 전혀 다른 새로운 파티션 키와 정렬 키를 정의하여 유연한 데이터 검색을 도와줍니다. 

여기서 중요 핵심은 독립적이라는 부분입니다.
예를 들어 우편번호를 기준으로 데이터를 검색하게 되면 어떻게 될까요?

기본 테이블에서는 파티션 키가 City가 될 것이고 정렬 키가 Entity 가 될 것입니다.
하지만 GSI 구조로 본다면 도시가 아니라 우편번호를 파티션 키로 사용되며 GSI 정렬 키로 Name(이름)을 사용합니다.  

하지만 DynamoDB에서 GSI(Global Secondary Index)를 사용할 때 우편번호를 기준으로 데이터를 검색한다고 하더라도 우편번호가 같은 항목들 중 일부만 포함될 수 있습니다. 
GSI는 기본 테이블과 별도로 작동하며 필요한 데이터만 복제해 저장하기 때문입니다.

이 방식을 통해 우편번호를 기준으로 데이터 검색은 가능하지만 몇 가지 제약이 있습니다. 
예시로 들면 우편번호만 알고 있는 경우 해당 우편번호로 데이터를 검색할 수 있습니다.
“우편번호가 88901인 모든 항목 검색” 처럼 말이죠.

불가능한 작업은 우편번호는 알지만 도시 이름을 알지 못하는 경우에는 데이터를 정확히 찾을 수 없습니다.
왜냐하면 우편번호와 도시는 항상 정확히 일치하지 않을 수 있기 때문입니다.

동일한 우편번호가 여러 도시와 관련될 수 있고 GSI는 우편번호에 따라 데이터를 정리하기 때문에 도시 기반 검색과는 무관합니다.

LSI(Local Secondary Index)와 GSI(Global Secondary Index)에 대해 알아보았는데요,
그렇다면 항목을 업데이트 해야 할 때는 어떻게 해야 할까요?

기본 테이블(Base Table)에서 작업을 수행하는 경우 업데이트 내용을 LSI와 GSI에도 반영하고 싶을 것입니다.
그러나 간단하게 하려면 기본 테이블에서만 업데이트를 수행하고 다른 두 곳에는 전파되도록 두는 것이 좋습니다.

로컬 세컨더리 인덱스(LSI)는 같은 책 안에 있기 때문에 즉시 업데이트 될 수 있으며 이 부분은 LSI의 장점 중 하나입니다.  반면 글로벌 세컨더리 인덱스(GSI)는 다른 책에 저장되므로 결국 전파되긴 하지만 시간이 약간 걸립니다.

결론적으로 아래와 같이 정리 할 수 있는데요
LSI는 즉각적으로, GSI는 “결국(eventually)” 업데이트됩니다.
전파는 일반적으로 몇 밀리초 이내에 이루어지지만 상황에 따라 더 오래 걸릴 수 있습니다.

DynamoDB를 더 효과적으로 사용하기 위해 추가적인 개념을 알아보았습니다. 그 외 DynamoDB의 알아보아야 할 내용들은 무엇이 있을까요? 이어서 DynamoDB의 특징에 대해 설명드리겠습니다.

DynamoDB의 추가적인 특징

우선 DynamoDB는 데이터를 고르게 분산시키기 위해 해시(Hash) 알고리즘을 사용합니다.

입력값의 변화가 출력값에 큰 영향을 미치기 때문에 해시를 사용하면 데이터를 매우 고르게 분산시킬 수 있습니다. 아래 사진은 선반에 책을 어떻게 배치해야 하는지 Hash 예시를 보여줍니다.

DynamoDB에서 데이터가 너무 커질 때는 어떻게 해야 할까요?

DynamoDB의 각 파티션은 최대 10GB의 데이터를 저장할 수 있습니다. 데이터가 많아져 파티션 크기 한도를 초과하면 DynamoDB는 자동으로 새로운 파티션을 생성하여 데이터를 분할합니다.

아래 사진은 DynamoDB에서 한 파티션에 지나치게 많은 요청(트래픽) 이 몰릴 때 발생하는 문제와 이를 해결하는 방식을 보여줍니다. 이를 위한 해결법으로는 책장(파티션)을 나눠서 요청을 분산시켜야 합니다.

이와 같은 상황들을 대처하려면 DynamoDB의 파티션에 대해 잘 알고 있어야 합니다. 이에 마지막으로 DynamoDB 파티션의 기본 개념에 대해 정리하고자 합니다.

아래 사진은 파티션의 작동 원리를 잘 설명하고 있습니다. 이 부분에 대해 설명드리겠습니다.

1) 파티션 생성 기준

테이블은 데이터를 저장하기 위해 하나 이상의 파티션으로 시작합니다.
초기 파티션 수는 테이블의 요구 사항(데이터 크기, 쓰기/읽기 처리량)에 따라 결정됩니다.

2) 파티션 크기 제한

각 파티션은 최대 10GB 까지 데이터를 저장할 수 있습니다.
데이터 크기가 커지거나 읽기/쓰기 작업량이 증가하면 자동으로 새로운 파티션이 생성됩니다.

3) 읽기/쓰기 처리량 제한

각 파티션은 읽기와 쓰기 처리량에 제한이 있습니다. 읽기 용량(RCU)는 최대 3,000RCU 이며 쓰기 용량(WCU)는 최대 1,000WCU 입니다. 이 제한을 초과하면 성능 저하가 발생할 수 있으므로 필요에 따라 파티션이 분리됩니다.

정리드리면 DynamoDB 파티션은 데이터를 저장하고 검색하는 기본 단위로 데이터 크기와 트래픽 증가에 따라 자동으로 확장됩니다. 파티션 키와 분할 메커니즘을 이해하면 DynamoDB의 확장성과 성능을 최대한 활용할 수 있습니다.

결론