DynamoDB

DynamoDB의 데이터는 테이블, 항목, 속성이라는 계층 구조로 구성된다. 테이블은 데이터를 저장하는 컨테이너이며, 관계형 데이터베이스의 테이블과 유사한 개념이다. 각 테이블에는 이름이 부여되고, 기본 키와 같은 메타데이터를 포함한다.

항목은 테이블 내의 개별 데이터 레코드에 해당한다. 각 항목은 고유하게 식별하는 기본 키를 반드시 가지며, 기본 키를 제외한 나머지 데이터는 속성의 집합으로 구성된다. 속성은 이름-값 쌍으로 이루어진 기본 데이터 단위이다. 속성의 값은 스칼라(문자열, 숫자, 이진수, 불리언, 널), 문서(리스트, 맵), 집합(문자열 집합, 숫자 집합, 이진수 집합)과 같은 다양한 데이터 유형을 가질 수 있다. 이는 DynamoDB가 키-값 및 문서 모델을 모두 지원하는 특징을 보여준다.

항목의 속성은 사전 정의된 스키마가 없으며, 각 항목마다 완전히 다른 속성 집합을 가질 수 있다. 이는 스키마리스 데이터 모델의 특징으로, 애플리케이션 요구사항 변화에 유연하게 대응할 수 있게 한다. 단, 쿼리 작업의 효율성을 위해 관련성이 높은 항목들은 유사한 속성 구조를 가지도록 설계하는 것이 일반적이다.

DynamoDB의 기본 키는 테이블 내 각 항목을 고유하게 식별하고 데이터의 물리적 저장 위치를 결정하는 필수 요소이다. 기본 키는 반드시 정의해야 하며, 파티션 키만으로 구성된 단순 키와 파티션 키와 정렬 키로 구성된 복합 키의 두 가지 유형이 존재한다.

단순 키는 하나의 파티션 키 속성만으로 구성된다. DynamoDB는 이 키 값을 내부 해시 함수의 입력으로 사용하여 데이터가 저장될 물리적 파티션을 결정한다. 따라서 GetItem 작업 시 정확한 파티션 키 값을 제공해야 항목을 검색할 수 있다. 복합 키는 파티션 키와 정렬 키의 조합으로 이루어진다. 이 경우, 파티션 키는 데이터가 저장될 파티션을 결정하는 데 사용되며, 정렬 키는 동일한 파티션 키 내에서 항목들을 정렬된 순서로 저장하는 역할을 한다. 복합 키를 사용하면 하나의 파티션 키 값에 여러 항목을 저장할 수 있으며, Query 작업을 통해 정렬 키 범위를 기준으로 관련 항목들을 효율적으로 검색할 수 있다.

기본 키 설계는 성능과 확장성에 직접적인 영향을 미친다. 파티션 키는 워크로드가 여러 파티션에 고르게 분산되도록 설계되어야 핫 파티션을 방지할 수 있다. 반면, 정렬 키는 항목을 논리적으로 그룹화하고 범위 기반 쿼리를 가능하게 하는 데 활용된다. 예를 들어, 사용자 ID를 파티션 키로, 타임스탬프를 정렬 키로 설정하면 특정 사용자의 시간순 활동 기록을 효율적으로 조회할 수 있다. 기본 키는 한 번 생성된 후 변경할 수 없으므로, 애플리케이션의 데이터 액세스 패턴을 사전에 신중하게 분석하여 설계하는 것이 중요하다.

DynamoDB의 성능과 비용은 프로비저닝된 용량 모드 또는 온디맨드 용량 모드를 통해 관리됩니다. 프로비저닝된 용량 모드에서는 애플리케이션의 예상 처리량 요구 사항에 따라 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)를 미리 설정합니다. 온디맨드 모드는 사용한 만큼만 비용을 지불하는 방식으로, 용량 계획 없이 유연하게 사용할 수 있습니다.

읽기 작업의 용량은 항목 크기과 읽기 일관성에 따라 결정됩니다. 1개의 RCU는 초당 최대 4KB 크기의 항목에 대해 강력한 일관성 읽기를 한 번 수행하거나, 최대 8KB 크기의 항목에 대해 최종적 일관성 읽기를 두 번 수행할 수 있는 능력을 제공합니다. 쓰기 작업의 경우, 1개의 WCU는 초당 최대 1KB 크기의 항목을 한 번 쓰는 능력을 의미합니다. 항목 크기가 이 단위를 초과하면 추가 용량 단위가 소비됩니다.

용량 단위는 테이블 수준에서 설정되지만, 실제 소비는 개별 파티션에 걸쳐 균등하게 분배되지 않을 수 있습니다. 불균등한 접근 패턴으로 인해 특정 파티션의 용량이 고갈되면 핫 파티션 문제가 발생하고, ProvisionedThroughputExceededException 오류를 초래할 수 있습니다. 이를 방지하기 위해서는 접근 패턴이 고르게 분산되는 파티션 키를 설계하는 것이 중요합니다.

DynamoDB는 키-값 저장소와 문서 데이터베이스의 특성을 결합한 데이터 모델을 제공한다. 핵심 데이터 단위는 항목이며, 각 항목은 고유한 기본 키를 통해 식별된다. 이 모델은 사전처럼 키를 통해 해당 값을 빠르게 조회하는 키-값 구조의 단순함을 바탕으로 하면서도, 값 부분에 JSON이나 XML과 같은 구조화된 문서를 저장할 수 있는 유연성을 더했다.

값으로 저장되는 문서는 중첩된 객체나 배열을 포함할 수 있다. 예를 들어, 사용자 프로필을 나타내는 항목의 기본 키가 사용자 ID라면, 그 값에는 이름, 주소, 그리고 주문 내역 배열과 같은 복잡한 속성들이 하나의 문서로 저장될 수 있다. 이는 관계형 데이터베이스에서 여러 테이블을 조인해야 얻을 수 있는 정보를 단일 항목 내에 포함시킬 수 있음을 의미한다. DynamoDB는 문서 내의 중첩된 속성에 대해서도 직접적인 쿼리와 업데이트를 지원한다.

이 데이터 모델의 장점은 스키마의 유연성에 있다. 테이블을 생성할 때 각 항목이 가져야 할 속성(기본 키 제외)을 미리 정의할 필요가 없다. 동일한 테이블 내의 서로 다른 항목들은 완전히 다른 구조의 속성 집합을 가질 수 있다. 이는 애플리케이션 요구사항이 빠르게 변화하거나, 다양한 데이터 유형을 저장해야 할 때 큰 강점으로 작용한다.

이러한 하이브리드 모델 덕분에 DynamoDB는 단순 조회부터 복잡한 세부 정보 저장까지 광범위한 애플리케이션 요구를 충족시킨다. 데이터 접근은 항상 항목의 기본 키를 통해 이루어지며, 문서 내부의 비키 속성에 대한 효율적인 쿼리를 위해서는 보조 인덱스를 생성해야 한다.

DynamoDB의 보조 인덱스는 테이블의 기본 키와 다른 속성을 사용하여 데이터를 쿼리할 수 있게 해주는 데이터 구조이다. 기본 키만으로는 충분하지 않은 다양한 액세스 패턴을 지원하기 위해 사용된다. 보조 인덱스는 크게 글로벌 보조 인덱스(Global Secondary Index, GSI)와 로컬 보조 인덱스(Local Secondary Index, LSI) 두 가지 유형으로 구분된다.

글로벌 보조 인덱스는 기본 키와 완전히 다른 파티션 키와 정렬 키를 가질 수 있다. 이 인덱스는 원본 테이블과 별도의 파티션 공간을 차지하며, 자체적인 읽기/쓰기 용량 단위를 프로비저닝해야 한다. GSI를 생성할 때는 인덱스에 포함시킬 속성(프로젝션 속성)을 선택할 수 있으며, 이는 키 속성만 포함, 특정 속성만 포함, 또는 모든 속성을 포함하는 방식으로 설정된다. GSI는 테이블 생성 후 언제든지 추가하거나 삭제할 수 있다는 장점이 있다.

로컬 보조 인덀이스는 원본 테이블과 동일한 파티션 키를 공유하지만, 다른 정렬 키를 사용한다. 이는 동일한 파티션 키 값을 가진 항목들을 다른 정렬 키 기준으로 쿼리해야 할 때 유용하다. LSI는 테이블 생성 시에만 정의할 수 있으며, 삭제나 수정이 불가능하다. 또한, LSI는 원본 테이블과 용량 단위를 공유하며, 항목 크기 제한에 인덱스 키 속성의 크기가 포함된다는 점이 GSI와 다르다.

두 인덱스의 주요 차이점을 비교하면 다음과 같다.

보조 인덱스를 설계할 때는 쿼리 패턴, 데이터 일관성 요구사항, 비용 효율성을 종합적으로 고려해야 한다.

DynamoDB의 자동 확장 기능은 애플리케이션의 트래픽 패턴에 따라 테이블의 읽기/쓰기 용량 단위를 자동으로 조정한다. 이 기능을 활성화하면 사용자는 용량 계획에 대한 부담을 줄이고, 예상치 못한 트래픽 급증에도 성능을 유지할 수 있다.

자동 확장은 CloudWatch 지표를 기반으로 작동한다. 설정한 목표 사용률에 도달하면 DynamoDB는 용량을 늘리기 시작한다. 반대로 트래픽이 감소하면 일정 시간 후에 용량을 줄여 비용을 최적화한다. 이 조정은 사용자가 설정한 최소 및 최대 용량 한도 내에서 이루어진다.

이 기능은 특히 워크로드가 변동적이거나 예측하기 어려운 애플리케이션에 유용하다. 사용자는 수동으로 용량을 모니터링하고 조정할 필요 없이, 일관된 성능과 가용성을 보장받을 수 있다. 또한, 온디맨드 용량 모드와는 달리, 프로비저닝된 용량 모드에서 비용을 예측 가능하게 관리하려는 경우에 적합한 옵션이다.

글로벌 테이블은 단일 AWS 리전이 아닌 여러 리전에 걸쳐 DynamoDB 테이블의 복제본을 자동으로 생성하고 유지 관리하는 기능이다. 이 기능은 전 세계적으로 분산된 애플리케이션에 낮은 지연 시간의 데이터 액세스와 높은 가용성을 제공하기 위해 설계되었다. 사용자는 하나의 리전에 기본 테이블을 생성한 후, 복제를 원하는 다른 리전들을 지정하기만 하면 된다. DynamoDB는 이후 모든 데이터 쓰기 작업을 지정된 모든 리전의 복제본 테이블에 자동으로 전파하여 최종적 일관성을 보장한다[2].

글로벌 테이블의 주요 구성 요소와 동작 방식은 다음과 같다.

이 아키텍처는 재해 복구 솔루션을 구축하는 데 유용하며, 한 리전에 장애가 발생하더라도 다른 리전의 테이블을 통해 서비스를 지속할 수 있다. 또한 사용자의 지리적 위치에 가까운 리전에서 데이터를 읽고 쓸 수 있게 함으로써 애플리케이션의 응답 속도를 크게 향상시킨다. 글로벌 테이블을 사용하려면 모든 복제본 리전의 테이블이 동일한 기본 키 스키마를 가져야 하며, 자동 확장 또는 온디맨드 용량 모드 중 하나를 선택해야 한다.

TTL(Time to Live)은 DynamoDB 테이블에서 항목의 수명을 정의하고 자동으로 삭제하는 기능이다. 사용자는 항목의 속성 중 하나를 TTL 속성으로 지정하고, 그 속성에 유닉스 시간 형식의 타임스탬프 값을 저장한다. DynamoDB는 백그라운드에서 이 속성 값을 주기적으로 확인하여, 현재 시간이 저장된 타임스탬프를 지난 항목들을 자동으로 테이블에서 삭제한다. 이 삭제 작업은 일반적인 쓰기 용량 단위(WCU)를 소비하지 않으며, 일반적으로 48시간 이내에 완료된다[3].

이 기능은 주로 데이터 보존 정책을 구현하거나 저장소 비용을 절감하며, 애플리케이션 로직을 단순화하는 데 사용된다. 예를 들어, 사용자 세션 데이터, 이벤트 로그, 임시 캐시 데이터, 만료된 오퍼 코드 등 일정 기간 후에 더 이상 필요하지 않은 데이터를 처리하는 데 적합하다. TTL이 활성화된 테이블에서는 삭제될 항목을 애플리케이션 코드에서 명시적으로 찾아 삭제할 필요가 없어 운영 부담이 줄어든다.

TTL 삭제 작업은 다음과 같은 특징을 가진다.

관리자는 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 TTL을 활성화하고 모니터링할 수 있다. TTL 속성 값이 숫자 데이터 형식이 아니거나, 값이 과거가 아닌 미래의 시간을 가리키는 경우 해당 항목은 삭제 대상에서 제외된다.

DynamoDB는 여러 항목에 걸친 ACID 트랜잭션을 지원한다. 이는 애플리케이션에서 여러 GetItem, PutItem, UpdateItem, DeleteItem 작업을 하나의 원자적 단위로 묶어 실행할 수 있게 해준다. 트랜잭션 내의 모든 작업은 모두 성공하거나 모두 실패하는 방식을 보장한다.

트랜잭션 작업은 TransactWriteItems와 TransactGetItems라는 두 가지 주요 API 작업을 통해 수행된다. TransactWriteItems는 최대 100개의 항목에 대한 쓰기 작업(삽입, 업데이트, 삭제)을 하나의 트랜잭션으로 처리한다. TransactGetItems는 최대 100개의 항목에 대한 일관된 읽기 작업을 원자적으로 수행한다. 이 과정에서 다른 트랜잭션 작업과의 충돌이 감지되면 전체 트랜잭션이 취소되고 재시도할 수 있도록 한다.

트랜잭션 지원은 특정 사용 사례에 매우 유용하다. 예를 들어, 금융 시스템에서 한 계좌에서 출금하고 다른 계좌로 입금하는 작업을 동시에 처리해야 하거나, 전자상거래 시스템에서 주문 생성과 재고 감소를 동시에 수행해야 할 때 활용된다. 이는 데이터의 정확성과 무결성을 유지하는 데 필수적이다.

트랜잭션 사용 시 고려해야 할 주요 제약 사항은 다음과 같다.

DynamoDB는 키-값 저장소와 문서 데이터베이스의 특성을 결합한 서비스로, 데이터에 대한 기본적인 CRUD 작업을 수행하기 위한 핵심 API를 제공한다. 이 API들은 테이블 내의 특정 항목을 대상으로 하는 작업들로 구성된다.

주요 작업은 다음과 같다.

* GetItem: 테이블의 기본 키를 사용하여 단일 항목을 읽는다. 기본 키를 정확히 알고 있을 때 가장 효율적으로 항목을 검색하는 방법이다. 읽기 일관성을 최종적 일관성이나 강력한 일관성 중에서 선택할 수 있다[5].

* PutItem: 새로운 항목을 테이블에 삽입한다. 지정한 기본 키를 가진 항목이 이미 존재하면, 기존 항목을 새 항목으로 완전히 대체한다.

* UpdateItem: 기존 항목의 속성을 수정한다. 항목 전체를 교체하는 PutItem과 달리, 특정 속성만 추가, 업데이트 또는 삭제할 수 있다. 조건부 업데이트를 사용하여 특정 조건이 충족될 때만 업데이트를 수행하도록 할 수 있다.

* DeleteItem: 기본 키를 지정하여 테이블에서 단일 항목을 삭제한다. 조건부 삭제를 적용할 수도 있다.

이 작업들은 모두 단일 항목을 대상으로 한다는 공통점이 있다. 여러 항목을 한 번에 처리해야 하는 경우, 트랜잭션 API를 사용하거나 일괄 처리 작업을 활용할 수 있다. 예를 들어, BatchGetItem은 최대 100개의 항목을 한 번의 요청으로 가져올 수 있으며, BatchWriteItem은 최대 25개의 PutItem 또는 DeleteItem 작업을 집합적으로 처리한다. 이러한 일괄 작업은 네트워크 왕복 횟수를 줄여 성능을 향상시키고 비용을 절감하는 데 도움이 된다.

Query 작업은 파티션 키와 선택적으로 정렬 키 조건을 사용하여 테이블 또는 보조 인덱스에서 항목을 검색한다. Query는 파티션 키 값을 지정해야 하며, 동일한 파티션 키 값을 가진 모든 항목을 효율적으로 가져온다. 정렬 키를 사용하면 범위 조건(예: between, begins with)을 적용하여 결과를 필터링하고 정렬할 수 있다. Query는 기본적으로 결과를 정렬 키 순서로 반환하며, 테이블의 특정 세그먼트만 읽기 때문에 비용 효율적이고 성능이 예측 가능하다.

반면, Scan 작업은 테이블의 모든 항목을 순차적으로 읽는다. 필터 조건을 적용할 수 있지만, 이는 데이터를 읽은 후에 처리되므로 테이블 전체를 스캔하는 비용이 발생한다. Scan 작업은 대규모 데이터 세트에서 사용할 경우 처리량을 많이 소모하고 응답 시간이 길어질 수 있다. 따라서 가능한 한 Scan보다는 Query를 사용하는 것이 권장된다.

두 작업 모두 선택적 필터 표현식을 지원하여 반환되는 항목을 제한할 수 있다. 그러나 핵심 차이는 필터 적용 시점에 있다. Query는 키 조건으로 먼저 데이터를 필터링한 후 나머지 항목에 필터를 적용하는 반면, Scan은 모든 데이터를 읽은 후에 필터를 적용한다. 이로 인해 Scan은 읽기 용량을 더 많이 소비한다.

다음은 Query와 Scan의 주요 특성을 비교한 표이다.

애플리케이션 설계 시 데이터 액세스 패턴을 분석하여 Query를 최대한 활용하고, Scan 사용을 최소화하는 것이 읽기/쓰기 용량 단위 비용 절감과 성능 최적화의 핵심이다.

파티션 키 설계는 DynamoDB의 성능, 확장성, 비용 효율성을 결정하는 가장 중요한 요소 중 하나이다. 잘 설계된 파티션 키는 데이터를 여러 파티션에 고르게 분산시켜 처리량을 극대화하고, 핫 파티션 문제를 방지한다.

파티션 키 선택 시 고려해야 할 주요 원칙은 다음과 같다.

* 높은 카디널리티: 가능한 한 많은 고유 값을 가진 속성을 선택해야 한다. 예를 들어, 사용자 ID, 장치 ID, 세션 ID 등이 적합하다. 이는 자동으로 데이터와 워크로드를 여러 파티션에 분산시킨다.

* 균등한 액세스 패턴: 파티션 키 값에 따른 읽기 및 쓰기 요청이 시간에 따라 고르게 분포되어야 한다. 특정 키 값에 대한 요청이 집중되면 해당 파티션만 과도하게 사용되는 핫 파티션이 발생한다.

* 쿼리 요구사항 반영: 파티션 키는 가장 빈번하게 실행되는 Query 작업의 기준이 되어야 한다. Query 작업은 반드시 파티션 키 값을 동등 조건으로 지정해야 하기 때문이다.

파티션 키 설계 전략으로는 복합 기본 키를 구성하거나, 파티션 키 값을 인위적으로 생성하는 방법이 있다. 복합 기본 키는 파티션 키와 정렬 키를 조합하여, 하나의 파티션 키 내에서 정렬 키를 기준으로 효율적인 데이터 정렬 및 필터링을 가능하게 한다. 또한, 예측 가능한 핫 키(예: STATUS 속성의 'PROCESSING' 값)가 있을 경우, 파티션 키에 난수 접미사나 계산된 해시를 추가하는 샤딩 기법을 사용하여 데이터를 여러 파티션 키로 분산시킬 수 있다.

파티션 키를 설계할 때 데이터와 워크로드가 특정 파티션에 집중되지 않도록 균등하게 분산시키는 것이 핵심이다. 이는 DynamoDB가 데이터를 저장하고 처리하는 기본 단위인 파티션의 성능 한계를 고려해야 한다. 각 파티션은 최대 3000 RCU(읽기 용량 단위) 또는 1000 WCU(쓰기 용량 단위)의 처리량을 지원한다. 특정 파티션 키 값에 대한 요청이 이 한계를 초과하면, 해당 파티션은 성능 병목 현상을 겪게 되며 요청은 제한될 수 있다.

핫 파티션을 방지하기 위한 일반적인 전략은 다음과 같다.

애플리케이션의 액세스 패턴을 철저히 분석하는 것이 중요하다. 예를 들어, 타임스탬프를 단독 파티션 키로 사용하면 특정 시간대에 모든 쓰기가 하나의 최신 파티션으로 집중될 수 있다. 대신, 파티션 키를 YYYY-MM-DD 형식의 날짜와 SHARD_ID의 조합으로 설계하면 하루의 트래픽도 여러 파티션에 분산시킬 수 있다. 또한, 자동 확장 기능은 용량을 조정하지만, 근본적인 데이터 분산 문제를 해결하지는 않는다. 따라서 설계 단계에서 핫 파티션을 방지하는 데이터 모델을 수립하는 것이 가장 효과적인 방법이다.

읽기 용량 단위와 쓰기 용량 단위를 프로비저닝 모드에서 적절히 설정하는 것이 비용 관리의 기본이다. 예측 가능한 트래픽에는 프로비저닝된 용량을, 변동이 심한 트래픽에는 온디맨드 용량 모드를 사용하여 비용을 절감할 수 있다. 자동 확장 기능을 활성화하면 트래픽 패턴에 따라 용량을 자동으로 조정하여 과도한 프로비저닝을 방지한다.

효율적인 쿼리와 스캔 사용은 직접적인 비용 영향을 미친다. Query는 파티션 키를 지정하여 특정 파티션 내에서만 데이터를 검색하므로, Scan 작업보다 훨씬 적은 읽기 용량을 소비한다. Scan은 전체 테이블을 순차적으로 읽기 때문에 비용이 높고 성능이 떨어지므로, 반드시 필요한 경우에만 제한적으로 사용해야 한다. 또한 Query나 Scan 작업 시 FilterExpression을 사용하면, 필터링은 클라이언트 측에서 적용되기 전에 읽기 용량을 이미 소모했음을 주의해야 한다[7].

Time to Live 기능을 사용하여 만료된 데이터를 자동으로 삭제하면 저장 비용을 지속적으로 절감할 수 있다. 또한 DynamoDB Accelerator를 읽기 집약적인 애플리케이션에 사용하면, 캐시에서 데이터를 제공하여 백엔드 테이블에 대한 읽기 부하와 비용을 크게 줄일 수 있다. 데이터 아카이빙 정책을 수립하고, 자주 액세스하지 않는 오래된 데이터는 AWS Glue 등을 사용해 Amazon S3 같은 저비용 저장소로 내보내는 것도 고려해야 한다.

AWS Lambda는 DynamoDB 테이블의 데이터 변경을 트리거로 하여 서버리스 방식의 비즈니스 로직을 실행할 수 있게 한다. DynamoDB 스트림을 활성화하면 테이블의 항목에 대한 생성, 수정, 삭제 이벤트가 순서대로 기록된다. Lambda 함수는 이 스트림을 구독하여 이벤트를 실시간으로 처리한다. 예를 들어, 주문 테이블에 새 항목이 추가되면 Lambda 함수가 자동으로 실행되어 재고를 감소시키거나 확인 이메일을 발송할 수 있다. 이 아키텍처는 완전한 서버리스 애플리케이션의 백엔드 핵심을 구성한다.

Amazon API Gateway는 DynamoDB에 대한 HTTP 기반의 안전한 액세스 계층을 제공한다. API Gateway는 RESTful API 또는 WebSocket API를 생성하여 클라이언트 요청을 받고, 이를 AWS Lambda 함수나 직접 Amazon DynamoDB에 대한 통합으로 라우팅할 수 있다. 이를 통해 웹 또는 모바일 애플리케이션은 API 엔드포인트를 통해 DynamoDB의 데이터를 안전하게 조작할 수 있다. API Gateway는 인증, 권한 부여, 속도 제한, 요청/응답 변환과 같은 기능을 관리하여 애플리케이션 개발자가 인프라보다 비즈니스 로직에 집중할 수 있게 한다.

이 두 서비스와 DynamoDB의 통합은 일반적인 서버리스 마이크로서비스 패턴을 구현한다. 아래 표는 이 통합을 활용한 일반적인 흐름을 보여준다.

이 패턴은 인프라 관리 부담을 크게 줄이면서도 확장성과 보안성을 갖춘 애플리케이션을 빠르게 구축할 수 있는 기반을 제공한다.

DynamoDB Accelerator(DAX)는 아마존 웹 서비스(AWS)의 완전관리형 인메모리 캐시 서비스이다. 이 서비스는 DynamoDB 테이블을 위한 초고속 캐시 계층을 제공하여, 마이크로초 단위의 응답 시간으로 데이터를 읽을 수 있게 한다. DAX는 애플리케이션의 읽기 처리량 요구 사항을 충족시키면서도 DynamoDB 테이블에 가해지는 읽기 부하를 크게 줄여준다.

DAX는 캐시 일관성을 유지하면서 작동한다. 캐시에 데이터를 쓸 때는 DynamoDB 테이블에 직접 쓰기가 이루어지며, DAX는 이후의 읽기 요청에 대해 캐시된 데이터를 반환한다. 데이터가 업데이트되면 DAX는 캐시의 해당 항목을 무효화하여 애플리케이션이 항상 최신 데이터를 읽도록 보장한다. 이 아키텍처는 기존 애플리케이션 코드를 거의 수정하지 않고도 쉽게 통합할 수 있도록 설계되었다.

주요 사용 사례는 읽기 집약적인 워크로드이다. 예를 들어, 사용자 프로필 조회, 제품 카탈로그 읽기, 소셜 미디어 피드 또는 게임 리더보드와 같이 초당 수백만 건의 요청을 처리해야 하는 애플리케이션에 적합하다. DAX를 사용하면 읽기 용량 단위(RCU)를 과도하게 프로비저닝하지 않고도 짧은 지연 시간과 높은 처리량을 달성할 수 있다.

DAX 클러스터는 여러 노드로 구성되며, 필요에 따라 노드 수를 늘리거나 줄일 수 있다. 클러스터 내에서 데이터는 자동으로 파티셔닝되고 복제되어 가용성과 내구성을 제공한다. 비용 모델은 선택한 노드 유형과 클러스터를 운영한 시간에 기반한다.

게임 산업은 DynamoDB의 주요 사용 사례 중 하나이다. 게임 서버는 수백만 명의 플레이어로부터 초당 수만 건의 요청을 처리해야 하는 경우가 많으며, DynamoDB의 단일 자릿수 밀리초 지연 시간과 거의 무제한에 가까운 처리량 확장성이 이러한 요구 사항에 적합하다.

플레이어 프로필, 인벤토리, 업적, 세션 데이터, 리더보드 점수와 같은 게임 상태 정보를 저장하는 데 널리 사용된다. 예를 들어, 플레이어 ID를 파티션 키로, 데이터 유형(예: 'PROFILE', 'INVENTORY')을 정렬 키로 사용하는 복합 기본 키 구조를 설계할 수 있다. 이렇게 하면 하나의 Query 작업으로 특정 플레이어의 모든 관련 데이터를 효율적으로 가져올 수 있다. 실시간 리더보드 구현에는 정렬 키를 점수로, 파티션 키를 게임 모드나 지역으로 설정한 글로벌 보조 인덱스(GSI)를 활용하여 빠른 순위 조회가 가능하다.

게임의 트래픽 패턴은 출시 초기나 신규 콘텐츠 업데이트 시에 급증하는 특징이 있다. DynamoDB의 자동 확장 기능은 이러한 트래픽 스파이크를 사전 계획 없이 자동으로 처리하여 게임 가용성을 유지한다. 또한, 일시적인 로그인 토큰이나 짧은 유효 기간을 가진 이벤트 데이터를 관리하기 위해 TTL(Time to Live) 속성을 설정하면, 만료된 데이터를 자동으로 삭제하여 스토리지 비용을 절감하고 관리 부담을 줄일 수 있다.

DynamoDB는 쇼핑 카트와 같은 세션 기반의 일시적 데이터를 저장하고 관리하는 데 매우 적합한 데이터베이스 서비스이다. 쇼핑 카트 데이터는 일반적으로 사용자 세션 동안에만 존재하며, 높은 쓰기 및 읽기 처리량, 짧은 지연 시간, 그리고 유연한 스키마가 요구된다. DynamoDB의 키-값 및 문서 모델은 각 사용자의 카트를 하나의 항목으로 표현하기에 이상적이며, 카트에 담긴 상품 목록, 수량, 옵션 등을 JSON 형식의 문서로 유연하게 저장할 수 있다.

쇼핑 카트 구현을 위해 테이블의 기본 키는 사용자 ID(예: 세션 ID 또는 로그인된 사용자 ID)를 파티션 키로 설정하는 것이 일반적이다. 이를 통해 특정 사용자의 카트 데이터에 빠르게 접근할 수 있다. 카트 항목은 PutItem 작업으로 생성되거나, UpdateItem 작업을 사용하여 상품을 추가/제거하거나 수량을 변경할 수 있다. 조건부 업데이트를 활용하면 동시에 여러 사용자가 같은 카트를 수정하려는 상황에서 데이터 무결성을 보장할 수 있다.

비용 최적화와 데이터 관리 측면에서 TTL (Time to Live) 속성을 활성화하는 것이 좋다. 이를 통해 일정 시간(예: 30일)이 지난 미사용 카트 항목을 자동으로 삭제하여 스토리지 비용을 절감하고 데이터를 정리할 수 있다. 또한, 읽기/쓰기 용량 단위를 프로비저닝하거나 자동 확장을 설정하여 예상치 못한 트래픽 증가(예: 블랙프라이데이)에도 카트 서비스의 성능을 안정적으로 유지할 수 있다.

AWS DynamoDB는 IoT 디바이스에서 생성되는 대량의 시계열 상태 데이터를 저장하고 관리하는 데 적합한 데이터베이스이다. 디바이스의 센서 읽기 값, 연결 상태, 위치 정보, 배터리 잔량과 같은 데이터는 지속적으로 발생하며, 낮은 지연 시간으로 기록되고 빠르게 조회되어야 한다. DynamoDB의 높은 쓰기 처리량과 확장성은 이러한 요구 사항을 충족시킨다.

일반적인 설계 패턴으로, 파티션 키를 디바이스 ID로, 정렬 키를 타임스탬프로 구성한다. 이렇게 하면 하나의 디바이스가 시간 순으로 모든 상태 데이터를 단일 파티션에 저장할 수 있어, 특정 디바이스의 최근 상태 조회나 시간 범위 기반의 기록 조회(Query 작업)가 효율적으로 수행된다. 또한 TTL 기능을 활성화하여 특정 기간(예: 30일)이 지난 오래된 데이터를 자동으로 삭제함으로써 스토리지 비용을 관리할 수 있다.

아키텍처는 IoT Core나 Kinesis Data Streams와 같은 서비스를 통해 디바이스 데이터를 수집하고, AWS Lambda 함수를 트리거하여 DynamoDB 테이블에 데이터를 처리 및 저장하는 방식으로 구성된다. 실시간 대시보드나 분석을 위해 최신 데이터는 DynamoDB에서 직접 조회하고, 장기적인 추세 분석을 위해 Amazon Kinesis Data Firehose를 사용해 데이터를 Amazon S3 및 Amazon Redshift 같은 데이터 웨어하우스로 동시에 전송할 수도 있다.