Amazon DynamoDB
1. 개요
1. 개요
Amazon DynamoDB는 AWS가 제공하는 완전관리형 NoSQL 데이터베이스 서비스이다. 이 서비스는 키-값 저장소와 문서 데이터베이스의 특성을 결합한 모델을 제공하며, 마이크로초 단위의 지연 시간과 관계없이 어느 규모에서나 일관된 성능을 보장하는 것을 주요 목표로 설계되었다. 서버리스 아키텍처를 기반으로 하여 사용자는 하드웨어 프로비저닝, 설정, 패치 적용 또는 클러스터 확장과 같은 인프라 관리 작업에서 완전히 벗어날 수 있다.
DynamoDB의 핵심은 높은 가용성과 내구성을 위한 자동 복제 및 다중 가용 영역에 데이터를 저장하는 구조에 있다. 데이터는 SSD 저장소를 사용하는 테이블에 저장되며, 애플리케이션의 트래픽 패턴에 따라 처리 용량을 자동으로 조정한다. 이는 예측 가능한 성능을 필요로 하는 모바일, 웹, 게임, 광고 기술, IoT 등 다양한 대규모 애플리케이션에 적합하다.
서비스는 2012년에 정식 출시되었으며, AWS의 핵심 데이터베이스 서비스 중 하나로 성장했다. 사용자는 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 서비스를 쉽게 이용할 수 있다. 요금 모델은 데이터 저장량, 읽기/쓰기 요청 횟수, 선택한 추가 기능(예: 스트림, 글로벌 테이블)에 따라 결정된다.
2. 핵심 개념
2. 핵심 개념
Amazon DynamoDB의 핵심 구성 요소는 테이블, 항목, 속성이다. 테이블은 데이터의 컨테이너이며, 각 테이블에는 여러 개의 항목이 저장된다. 항목은 하나의 데이터 레코드에 해당하며, 각 항목은 하나 이상의 속성으로 구성된다. 속성은 이름-값 쌍의 기본 데이터 단위이다. DynamoDB는 스키마가 없으므로, 같은 테이블 내의 항목들이 서로 다른 속성 집합을 가질 수 있다.
데이터를 효율적으로 구성하고 접근하기 위해 파티션 키와 정렬 키를 사용한다. 파티션 키는 항목의 물리적 저장 위치를 결정하는 단일 속성이다. 정렬 키는 파티션 키와 함께 사용되어 복합 기본 키를 형성하며, 같은 파티션 내에서 항목들을 정렬된 순서로 저장한다. 이 구조는 특정 항목에 대한 빠른 조회와 파티션 키 범위 내의 쿼리를 가능하게 한다.
성능 관리는 읽기 용량 단위와 쓰기 용량 단위를 통해 이루어진다. RCU는 초당 한 번의 강력한 일관성 읽기 또는 초당 두 번의 최종적 일관성 읽기에 해당하는 처리량 단위이다. WCU는 초당 최대 1KB 크기의 항목을 한 번 쓰는 처리량을 의미한다. 애플리케이션의 예상 트래픽에 따라 이 용량을 프로비저닝하여 성능을 보장한다.
이러한 개념들은 DynamoDB의 핵심 설계 원리를 이루며, 확장성과 성능에 직접적인 영향을 미친다. 테이블 설계 시 파티션 키 선택은 데이터 분산과 핫 파티션 방지의 핵심이며, 용량 단위 설정은 비용과 성능의 균형을 결정한다.
2.1. 테이블, 항목, 속성
2.1. 테이블, 항목, 속성
Amazon DynamoDB의 데이터 모델은 테이블, 항목, 속성이라는 기본 구성 요소로 이루어진다. 이 계층 구조는 관계형 데이터베이스의 테이블, 행, 열과 유사한 개념이지만, 스키마가 고정되어 있지 않다는 점에서 차이가 있다.
테이블은 데이터를 저장하는 기본 컨테이너이다. 각 테이블은 이름을 가지며, 무제한에 가까운 수의 항목을 저장할 수 있다. 테이블을 생성할 때는 데이터를 물리적으로 분산 저장하고 효율적으로 검색하기 위한 파티션 키를 반드시 정의해야 한다.
항목은 테이블 내의 개별 데이터 레코드에 해당한다. 각 항목은 하나 이상의 속성으로 구성된다. 항목은 고유하게 식별하기 위해 파티션 키와 선택적인 정렬 키로 구성된 기본 키를 가진다. 항목의 크기는 최대 400KB로 제한된다.
속성은 항목을 구성하는 기본 데이터 단위이다. 각 속성은 이름과 값을 가지며, 값은 스칼라, 문서, 집합과 같은 다양한 데이터 유형을 지원한다[1]. 동일한 테이블 내의 서로 다른 항목들은 완전히 다른 속성 집합을 가질 수 있으며, 이는 스키마리스 데이터 모델의 특징이다.
2.2. 파티션 키와 정렬 키
2.2. 파티션 키와 정렬 키
Amazon DynamoDB에서 모든 데이터 항목은 고유하게 식별하기 위해 기본 키를 가진다. 기본 키는 단순히 하나의 속성으로 구성된 파티션 키만 사용하거나, 파티션 키와 정렬 키를 조합한 복합 키로 구성될 수 있다.
파티션 키는 항목의 물리적 저장 위치를 결정하는 단일 속성이다. DynamoDB는 파티션 키 값을 내부 해시 함수에 입력하여 데이터가 저장될 특정 파티션을 결정한다. 이는 데이터를 여러 서버에 고르게 분산시키고 병렬 처리 성능을 확보하는 핵심 메커니즘이다. 따라서 파티션 키는 가능한 고르게 분포된 값을 가지는 속성을 선택하는 것이 중요하다. 정렬 키는 동일한 파티션 키 값을 공유하는 항목들을 정렬된 순서로 저장하는 데 사용되는 선택적 속성이다. 파티션 키와 정렬 키를 함께 사용하면 하나의 파티션 내에서 항목들을 효율적으로 질의할 수 있다.
파티션 키와 정렬 키의 조합은 데이터 접근 패턴에 큰 영향을 미친다. 복합 기본 키를 사용할 경우, 다음과 같은 유용한 질의 기능을 제공한다.
* 항목 범위 질의: 동일한 파티션 키 내에서 정렬 키를 기준으로 범위를 지정하여 여러 항목을 효율적으로 검색할 수 있다. (예: 특정 사용자(파티션 키)의 특정 날짜 범위(정렬 키) 내 주문 조회)
* 정렬된 결과: 기본적으로 정렬 키 기준 오름차순으로 결과가 반환되며, 내림차순으로도 질의할 수 있다.
다음은 기본 키 구성에 따른 데이터 접근 방식의 차이를 보여주는 표이다.
기본 키 유형 | 구성 요소 | 주요 질의 패턴 | 예시 (테이블: `UserOrders`) |
|---|---|---|---|
단순 키 (파티션 키만) | `UserID` (파티션 키) | `GetItem` (단일 항목), `Query` (전체 파티션 스캔) | `UserID=123`인 사용자 프로필 조회 |
복합 키 (파티션 키 + 정렬 키) | `UserID` (파티션 키) + `OrderDate` (정렬 키) | `GetItem` (단일 항목), `Query` (범위/정렬 질의) | `UserID=123`이고 `OrderDate`가 '2024-01-01'부터 '2024-03-31' 사이인 모든 주문 조회 |
테이블 생성 시 기본 키를 정의하면 이후에 변경할 수 없으므로, 애플리케이션의 주요 접근 패턴을 신중하게 고려하여 설계해야 한다. 다양한 질의 요구사항을 충족시키기 위해서는 보조 인덱스를 추가로 생성할 수 있다.
2.3. 읽기/쓰기 용량 단위
2.3. 읽기/쓰기 용량 단위
Amazon DynamoDB에서 읽기/쓰기 용량 단위는 데이터베이스의 처리 성능을 정의하고 측정하는 핵심 개념이다. 이 단위는 테이블이 초당 처리할 수 있는 읽기 및 쓰기 작업의 양을 결정하며, 사용자가 선택한 용량 모드에 따라 관리 방식이 달라진다.
읽기 용량 단위(RCU)는 초당 한 번의 강력한 일관성 읽기 또는 초당 두 번의 최종적 일관성 읽기를 처리할 수 있는 능력을 나타낸다. 여기서 '한 번의 읽기'는 최대 4KB 크기의 항목을 기준으로 한다. 쓰기 용량 단위(WCU)는 초당 최대 1KB 크기의 항목을 한 번 쓰는 작업을 처리할 수 있는 능력을 나타낸다. 항목 크기가 이 기준을 초과하면 필요한 용량 단위가 비례하여 증가한다[2].
사용자는 주로 두 가지 용량 모드 중 하나를 선택하여 이 단위를 관리한다. 프로비저닝된 용량 모드에서는 애플리케이션의 예상 트래픽에 따라 RCU와 WCU의 수를 미리 설정하고 비용을 지불한다. 반면, 온디맨드 용량 모드에서는 실제로 수행된 읽기 및 쓰기 작업량에 따라 자동으로 용량이 조정되며, 사용한 요청 단위만큼 비용이 청구된다. 두 모드 모두에서 DynamoDB는 할당된 용량 단위를 기반으로 데이터를 파티션에 분배하고 자동으로 확장을 처리한다.
3. 데이터 모델
3. 데이터 모델
Amazon DynamoDB의 데이터 모델은 기본적으로 키-값 스토어와 문서 데이터베이스의 특징을 결합한 형태이다. 각 테이블은 항목의 모음으로 구성되며, 각 항목은 고유한 파티션 키와 선택적인 정렬 키로 식별되는 기본 키를 가진다. 항목은 속성의 집합이며, 속성의 값은 스칼라, 문서, 집합 등 다양한 데이터 타입을 가질 수 있다. 이는 단순한 키-값 쌍 이상의 복잡한 데이터 구조를 단일 항목에 저장할 수 있게 해준다.
주요 데이터 접근 패턴은 기본 키를 통한 조회이다. 파티션 키만으로도 항목을 고유하게 식별할 수 있지만, 정렬 키를 추가하면 하나의 파티션 키 값 아래에 여러 항목을 논리적으로 그룹화하고 정렬된 순서로 효율적으로 쿼리할 수 있다. 이는 게임 플레이어 데이터, 센서 시계열 데이터, 주문-주문 항목 관계와 같은 패턴에 적합하다.
기본 키 외의 속성으로 효율적으로 쿼리하기 위해 보조 인덱스를 생성할 수 있다. 전역 보조 인덱스(GSI)는 기본 키와 다른 파티션 키와 정렬 키를 가질 수 있으며, 원본 테이블과 별도로 프로비저닝된 용량을 가지므로 쿼리 유연성을 크게 향상시킨다. 반면 로컬 보조 인덱스(LSI)는 원본 테이블과 동일한 파티션 키를 사용하지만 다른 정렬 키를 사용하며, 테이블 생성 시에만 정의할 수 있고 테이블의 쓰기 용량을 공유한다.
인덱스 유형 | 키 구성 | 생성/삭제 시기 | 용량 모드 | 주요 특징 |
|---|---|---|---|---|
전역 보조 인덱스(GSI) | 기본 키와 다른 파티션 키 및 정렬 키 | 언제든지 생성 및 삭제 가능 | 인덱스별로 독립적인 용량 프로비저닝 | 최종 일관성 쿼리 기본, 강력한 일관성 옵션 가능 |
로컬 보조 인덱스(LSI) | 기본 키와 같은 파티션 키, 다른 정렬 키 | 테이블 생성 시에만 정의 가능 | 원본 테이블의 쓰기 용량 공유 | 항상 강력한 일관성 쿼리 제공 |
이러한 데이터 모델 설계는 애플리케이션의 다양한 쿼리 요구사항을 지원하면서도 확장성과 성능을 보장한다. 개발자는 접근 패턴을 분석하여 적절한 기본 키와 보조 인덱스를 설계함으로써 단일 숫자 키 조회부터 복잡한 다중 속성 쿼리까지 효율적으로 처리할 수 있다.
3.1. 키-값 및 문서 구조
3.1. 키-값 및 문서 구조
Amazon DynamoDB의 데이터 모델은 기본적으로 키-값 저장소와 문서 데이터베이스의 특성을 결합한 형태이다. 각 테이블은 항목의 모음으로 구성되며, 각 항목은 고유한 파티션 키와 선택적인 정렬 키로 식별되는 기본 키를 가진다. 항목은 속성의 집합으로, 각 속성은 이름과 값을 가진다. 값은 DynamoDB가 지원하는 스칼라 데이터 타입(문자열, 숫자, 이진, 불리언, null)이나, 문서 타입(리스트, 맵), 집합 타입(문자열 집합, 숫자 집합, 이진 집합)으로 구성될 수 있다.
이 구조는 단순한 키-값 쌍을 넘어서, 중첩된 객체나 배열과 같은 복잡한 구조를 단일 항목에 저장할 수 있는 문서 모델의 유연성을 제공한다. 예를 들어, 사용자 프로필 항목 하나에 사용자 ID를 기본 키로 사용하고, 속성으로 이름, 주소(맵 타입), 태그(문자열 집합), 주문 기록(리스트 타입) 등을 함께 저장할 수 있다. 이는 반정형 데이터를 저장하고 조회하는 데 매우 효율적이다.
DynamoDB의 문서 모델 지원은 JSON 형식과의 호환성이 뛰어나다. 애플리케이션에서 JSON 객체를 DynamoDB 항목으로 직렬화하거나, 그 반대로 변환하는 작업이 간단하다. AWS SDK는 이 변환을 자동으로 처리한다. 이 모델은 스키마가 고정되어 있지 않다는 특징도 있다. 같은 테이블 내의 항목들이 서로 다른 속성 집합을 가질 수 있으며, 시간에 따라 새로운 속성을 추가하는 것도 자유롭다.
데이터 타입 범주 | 구체적 타입 | 설명 | 예시 |
|---|---|---|---|
스칼라 | 문자열(S), 숫자(N), 이진(B) | 단일 값. 가장 기본적인 타입이다. | `"Hello"`, `42`, `<이진 데이터>` |
스칼라 | 불리언(BOOL), NULL | 참/거짓 값 또는 빈 값 표현. | `true`, `false`, `NULL` |
문서 | 맵(M) | 속성 이름-값 쌍의 컬렉션. 중첩 구조 가능. | `{"name": "Kim", "age": 30}` |
문서 | 리스트(L) | 값의 정렬된 컬렉션. 다양한 타입 혼합 가능. | `["apple", 123, true]` |
집합 | 문자열 집합(SS), 숫자 집합(NS), 이진 집합(BS) | 고유한 스칼라 값의 정렬되지 않은 컬렉션. | `["red", "green", "blue"]` |
3.2. 보조 인덱스 (GSI, LSI)
3.2. 보조 인덱스 (GSI, LSI)
Amazon DynamoDB는 기본적으로 파티션 키와 선택적인 정렬 키로 구성된 기본 키를 통해 데이터에 접근합니다. 보조 인덱스를 사용하면 기본 키와 다른 속성을 쿼리의 기준으로 사용할 수 있어 데이터 접근 유연성을 크게 향상시킵니다. DynamoDB는 글로벌 보조 인덱스와 로컬 보조 인덱스라는 두 가지 유형의 보조 인덱스를 제공합니다.
GSI는 파티션 키와 정렬 키가 원본 테이블과 완전히 다를 수 있는 인덱스입니다. 이 인덱스는 자체 파티션 키(필수)와 정렬 키(선택)를 가지며, 원본 테이블과는 별도의 파티션 공간에 저장되어 독립적인 성능 특성을 가집니다. GSI를 생성할 때는 인덱스에 포함시킬 속성(프로젝션 속성)을 지정해야 하며, 모든 속성을 포함하는 KEYS_ONLY, 특정 속성만 포함하는 INCLUDE, 모든 속성을 포함하는 ALL 옵션이 있습니다. GSI는 테이블 생성 후에도 언제든지 추가하거나 삭제할 수 있지만, 쓰기 작업 시 원본 테이블과 인덱스 양쪽에 데이터를 기록해야 하므로 쓰기 용량 소비가 증가하고 최종 일관성 모델을 사용합니다[3].
LSI는 원본 테이블과 파티션 키를 공유하지만, 다른 정렬 키를 사용하는 인덱스입니다. 이는 동일한 파티션 키 값을 가진 항목들을 다른 정렬 키 기준으로 쿼리해야 할 때 유용합니다. LSI는 원본 테이블과 동일한 파티션 내에 저장되므로 강력한 일관성 읽기를 지원하는 것이 주요 특징입니다. 그러나 LSI는 테이블 생성 시에만 함께 생성해야 하며, 이후에는 추가하거나 삭제할 수 없습니다. 또한 각 테이블당 최대 5개의 LSI만 생성할 수 있습니다.
두 인덱스의 주요 차이점을 비교하면 다음과 같습니다.
특성 | 글로벌 보조 인덱스 (GSI) | 로컬 보조 인덱스 (LSI) |
|---|---|---|
키 스키마 | 원본 테이블과 다른 파티션 키 및 정렬 키 가능 | 원본 테이블과 동일한 파티션 키, 다른 정렬 키 |
생성 시기 | 테이블 생성 후 언제든지 생성 및 삭제 가능 | 테이블 생성 시에만 함께 생성 가능 |
일관성 | 최종 일관성만 지원 | 강력한 일관성 읽기 지원 |
용량 설정 | 원본 테이블과 별도로 읽기/쓰기 용량 단위 설정 | 원본 테이블의 용량을 공유 |
개수 제한 | 테이블당 최대 20개 | 테이블당 최대 5개 |
4. 성능 및 확장성
4. 성능 및 확장성
Amazon DynamoDB의 성능과 확장성은 프로비저닝된 용량 모드와 온디맨드 용량 모드라는 두 가지 주요 용량 모드를 통해 관리됩니다. 각 모드는 애플리케이션의 트래픽 패턴에 맞춰 선택할 수 있습니다.
프로비저닝된 용량 모드에서는 사용자가 테이블에 필요한 초당 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)를 미리 설정합니다. 이 모드는 예측 가능한 트래픽을 가진 워크로드에 적합하며, 설정된 용량을 초과하는 요청은 제한될 수 있습니다. 비용은 프로비저닝한 용량에 비례합니다. 이 모드에서는 자동 확장 기능을 활성화하여 트래픽 변화에 따라 용량을 자동으로 조정할 수 있습니다. 자동 확장은 사용자가 설정한 목표 사용률을 기준으로 용량을 늘리거나 줄입니다.
반면, 온디맨드 용량 모드는 사전 용량 계획 없이 요청 수에 따라 자동으로 확장됩니다. 이 모드는 예측하기 어렵거나 급변하는 트래픽, 또는 개발 및 테스트 환경에 유용합니다. 비용은 실제 수행된 읽기 및 쓰기 작업 횟수에 따라 청구됩니다. 두 모드 모두 DynamoDB가 데이터를 여러 파티션에 분산 저장하여 처리 성능을 선형적으로 확장할 수 있도록 지원합니다.
용량 모드 선택은 비용 최적화의 핵심입니다. 안정적인 트래픽에는 프로비저닝된 모드가 일반적으로 경제적이며, 자동 확장으로 피크 시간을 관리할 수 있습니다. 반면, 트래픽이 크게 변동하거나 예측 불가능한 경우 온디맨드 모드가 운영 부담을 줄여줍니다. 사용자는 애플리케이션의 요구 사항에 따라 두 모드 간에 언제든지 전환할 수 있습니다.
4.1. 프로비저닝된 용량 모드
4.1. 프로비저닝된 용량 모드
Amazon DynamoDB의 프로비저닝된 용량 모드는 애플리케이션의 트래픽 패턴을 사전에 예측할 수 있을 때 사용하는 전통적인 용량 관리 방식이다. 사용자는 테이블 또는 보조 인덱스별로 초당 필요한 읽기 용량 단위와 쓰기 용량 단위의 수를 직접 지정하여 프로비저닝한다. 이 모델에서는 용량을 미리 예약하고 그에 따라 비용을 지불하며, 프로비저닝된 용량을 초과하는 요청은 제한되어 처리에 실패할 수 있다[4].
이 모드의 주요 장점은 예측 가능한 성능과 비용 관리에 있다. 일관되고 안정적인 트래픽을 처리하는 애플리케이션에 적합하며, 사용량이 크게 변동하지 않는 경우 온디맨드 모드보다 비용 효율적일 수 있다. 또한, 자동 확장 기능을 활성화하면 설정한 최소/최대 임계값 범위 내에서 실제 트래픽에 따라 용량을 자동으로 조정할 수 있어 프로비저닝된 모델의 유연성을 높인다.
프로비저닝된 용량의 계획은 읽기 작업의 일관성 설정에 따라 달라진다. 최종적 일관성 읽기 작업은 강력한 일관성 읽기 작업보다 2배 많은 데이터를 처리할 수 있으므로, 동일한 읽기 용량 단위로 더 높은 처리량을 얻을 수 있다. 용량 변경은 수동으로 수행하거나 자동 확장을 통해 이루어지며, 변경 사항은 일반적으로 몇 분 내에 적용된다.
비교 요소 | 설명 |
|---|---|
비용 구조 | 프로비저닝한 RCU/WCU 수와 데이터 저장량에 따라 시간당 비용이 청구됨 |
적합한 경우 | 트래픽 패턴이 비교적 예측 가능하거나, 자동 확장과 함께 사용할 때 |
용량 관리 | 사용자가 직접 용량을 설정하고 모니터링하며 조정해야 함 |
성능 보장 | 프로비저닝한 용량 내에서는 일관된 성능과 낮은 지연 시간을 제공함 |
4.2. 온디맨드 용량 모드
4.2. 온디맨드 용량 모드
온디맨드 용량 모드는 애플리케이션의 트래픽 패턴을 예측하거나 용량 계획을 관리할 필요 없이, 실제 수행된 읽기 및 쓰기 요청 횟수에 대해서만 비용을 지불하는 방식이다. 이 모드는 예측 불가능하거나 급변하는 트래픽을 처리하는 애플리케이션, 또는 개발 및 테스트 단계의 워크로드에 적합하다. 사용자는 사전에 읽기/쓰기 용량 단위를 프로비저닝할 필요가 없으며, Amazon DynamoDB가 자동으로 워크로드를 수용할 수 있는 충분한 용량을 실시간으로 조정한다.
이 모드에서는 테이블 생성 시 또는 기존 테이블의 용량 모드를 변경할 때 용량 설정을 지정하지 않는다. DynamoDB는 애플리케이션이 요청을 수행함에 따라 백그라운드에서 용량을 관리한다. 비용은 표준 읽기 요청 단위와 쓰기 요청 단위당 가격으로 청구되며, 이는 프로비저닝된 용량 모드의 사용량 초과 요금과 동일한 구조를 가진다. 온디맨드 모드는 초당 수천 개의 요청에서부터 수백만 개의 요청까지 급격한 변화를 처리할 수 있도록 설계되었다.
온디맨드 모드와 프로비저닝된 모드 간의 전환은 가능하지만, 24시간 동안 특정 횟수로 제한된다. 두 모드 간의 주요 차이점은 다음과 같다.
특성 | 프로비저닝된 용량 모드 | 온디맨드 용량 모드 |
|---|---|---|
용량 계획 | 필요함. RCU/WCU를 사전 설정 | 필요 없음. 자동 조정 |
비용 구조 | 프로비저닝된 용량에 대한 시간당 요금 + 초과 사용량 요금 | 수행된 실제 읽기/쓰기 요청 건수당 요금 |
적합한 워크로드 | 안정적이거나 예측 가능한 트래픽 | 예측 불가능하거나 급증하는 트래픽, 간헐적 트래픽 |
성능 | 프로비저닝된 용량 내에서 일관된 성능 보장 | 요청에 따라 자동으로 확장되어 성능 유지 |
온디맨드 모드는 용량 관리의 운영 부담을 줄여주지만, 예측 가능하고 지속적으로 높은 트래픽을 처리하는 경우에는 프로비저닝된 모드보다 비용이 더 높을 수 있다. 따라서 애플리케이션의 트래픽 패턴과 비용 예산을 분석하여 적절한 용량 모드를 선택하는 것이 중요하다.
4.3. 자동 확장
4.3. 자동 확장
Amazon DynamoDB의 자동 확장 기능은 애플리케이션의 트래픽 패턴 변화에 따라 테이블의 읽기/쓰기 용량 단위를 자동으로 조정합니다. 이 기능은 프로비저닝된 용량 모드에서 사용할 수 있으며, 사전 정의된 목표 사용률을 기준으로 용량을 확장하거나 축소합니다. 이를 통해 애플리케이션 성능을 일정 수준으로 유지하면서, 수요가 적을 때는 비용을 절감하고 수요가 많을 때는 성능 저하 없이 처리할 수 있습니다.
자동 확장은 CloudWatch 지표를 모니터링하여 작동합니다. 사용자는 최소 및 최대 프로비저닝 용량 한도를 설정하고, 목표 사용률 백분율(예: 70%)을 지정합니다. 시스템이 이 목표 사용률을 초과하거나 미달하면, 자동 확장이 용량을 단계적으로 조정합니다. 조정은 일반적으로 5분 간격으로 평가되며, 변경은 점진적으로 이루어져 갑작스러운 변동을 완화합니다.
구성 요소 | 설명 |
|---|---|
목표 사용률 | 용량 조정을 트리거하는 기준 사용률입니다. 예를 들어 70%로 설정하면, 사용률이 70%를 초과하면 확장하고, 크게 미달하면 축소합니다. |
확장 쿨다운 | 용량 증가 후, 다음 조정 평가 전까지 대기하는 시간입니다. 과도한 확장을 방지합니다. |
축소 쿨다운 | 용량 감소 후, 다음 조정 평가 전까지 대기하는 시간입니다. 너무 빠른 축소로 인한 성능 문제를 방지합니다. |
이 기능은 트래픽 패턴이 예측 가능하지만 변동이 있는 애플리케이션에 적합합니다. 그러나 매우 빠르게 변화하는 스파이크 트래픽이나 초당 수만 건 이상의 극단적인 요구 사항에는 즉각적인 대응이 어려울 수 있습니다. 이러한 경우에는 온디맨드 용량 모드와 함께 사용하거나, 예측 가능한 큰 이벤트에 대비해 수동으로 용량을 미리 늘리는 것이 권장됩니다.
5. 데이터 작업
5. 데이터 작업
Amazon DynamoDB의 데이터 작업은 주로 CRUD (생성, 읽기, 갱신, 삭제) 작업을 중심으로 이루어진다. `PutItem`, `GetItem`, `UpdateItem`, `DeleteItem` 작업을 통해 항목을 관리한다. `UpdateItem` 작업은 기존 항목의 속성을 수정하거나 새 속성을 추가하며, 존재하지 않는 항목에 대해 사용하면 새 항목을 생성한다. 대량 작업을 위해 `BatchWriteItem`을 사용하여 최대 25개의 `PutItem` 또는 `DeleteItem` 요청을 단일 호출로 처리할 수 있으며, `BatchGetItem`을 통해 최대 100개의 항목을 읽을 수 있다. `Query` 작업은 파티션 키 값을 지정하고, 선택적으로 정렬 키 조건을 적용하여 해당 파티션 내에서 항목을 효율적으로 검색한다. `Scan` 작업은 테이블 또는 보조 인덱스의 모든 항목을 검색하지만, 필터 표현식을 적용하지 않으면 모든 데이터를 읽기 때문에 대규모 테이블에서는 비효율적일 수 있다.
조건부 쓰기 작업은 데이터의 무결성을 유지하는 데 중요한 역할을 한다. `PutItem`, `UpdateItem`, `DeleteItem` 작업 시 조건 표현식을 지정하여 특정 조건이 충족될 때만 작업이 수행되도록 할 수 있다. 예를 들어, 항목이 존재하지 않는 경우에만 새로 삽입하거나, 특정 속성 값이 예상한 값과 일치할 때만 업데이트하는 것이 가능하다. DynamoDB는 또한 다중 항목 트랜잭션을 지원한다. `TransactWriteItems` 작업을 사용하면 최대 100개의 항목에 대한 `Put`, `Update`, `Delete`, `ConditionCheck` 작업을 원자적으로(모두 성공하거나 모두 실패) 수행할 수 있다. `TransactGetItems` 작업을 사용하면 여러 테이블에서 최대 100개의 항목을 일관되게 읽을 수 있다. 이러한 트랜잭션 지원은 금융 거래나 주문 처리와 같이 정확성이 요구되는 사용 사례에 적합하다.
DynamoDB 스트림은 테이블의 항목 수준 변경 사항(생성, 수정, 삭제)을 시간 순서대로 캡처하고 24시간 동안 저장한다. 이 스트림 레코드에는 변경된 항목의 키와, 선택적으로 변경 전/후의 항목 이미지가 포함될 수 있다. 스트림은 AWS Lambda 함수와 쉽게 통합되어 변경 사항이 발생할 때마다 코드를 트리거할 수 있다. 이를 통해 실시간 애플리케이션 알림 생성, 검색 인덱스 동기화, 데이터 웨어하우스 복제, 변경 데이터 캡처(CDC) 파이프라인 구축 등이 가능해진다. 스트림은 테이블당 하나만 활성화할 수 있으며, 보기 유형을 설정하여 스트림 레코드에 포함되는 정보의 양을 제어한다.
작업 유형 | 주요 작업 | 설명 |
|---|---|---|
기본 CRUD | `PutItem`, `GetItem`, `UpdateItem`, `DeleteItem` | 단일 항목에 대한 생성, 읽기, 갱신, 삭제 작업을 수행한다. |
대량 작업 | `BatchGetItem`, `BatchWriteItem` | 여러 항목에 대한 읽기 또는 쓰기 작업을 효율적으로 처리한다. |
쿼리 및 스캔 | `Query`, `Scan` | `Query`는 파티션 키를 기준으로 효율적으로 검색하며, `Scan`은 전체 테이블을 순차적으로 읽는다. |
조건부 작업 | 조건 표현식 | 쓰기 작업 시 특정 조건이 참인 경우에만 작업을 수행하도록 한다. |
트랜잭션 | `TransactWriteItems`, `TransactGetItems` | 여러 항목에 대한 읽기 및 쓰기 작업을 원자적으로 처리한다. |
변경 데이터 캡처 | DynamoDB 스트림 | 테이블의 모든 변경 사항을 순서대로 기록하고, 이를 기반으로 이벤트 기반 처리를 가능하게 한다. |
5.1. CRUD 작업
5.1. CRUD 작업
Amazon DynamoDB에서 데이터에 대한 기본적인 생성, 읽기, 갱신, 삭제 작업은 PutItem, GetItem, UpdateItem, DeleteItem 등의 API 작업을 통해 수행된다. 각 작업은 항목 단위로 이루어지며, 파티션 키와 정렬 키로 구성된 기본 키를 사용하여 대상을 정확히 지정한다.
주요 작업의 특징은 다음과 같다.
작업 | API | 주요 특징 |
|---|---|---|
생성 | `PutItem` | 지정된 기본 키로 새 항목을 생성한다. 동일한 키를 가진 기존 항목이 있으면 덮어쓴다. |
읽기 | `GetItem` | 기본 키를 지정하여 단일 항목을 검색한다. 일관된 읽기 또는 최종 일관된 읽기 모드를 선택할 수 있다. |
갱신 | `UpdateItem` | 기존 항목의 속성을 수정, 추가 또는 삭제한다. 전체 항목을 교체하지 않고 특정 속성만 원자적으로 업데이트할 수 있다. |
삭제 | `DeleteItem` | 기본 키를 지정하여 단일 항목을 삭제한다. |
`PutItem`은 항목을 완전히 새로 쓰는 작업이며, 부분 업데이트에는 `UpdateItem`을 사용해야 한다. `UpdateItem` 작업은 조건부 업데이트를 지원하여 특정 속성 값이 조건을 만족할 때만 업데이트를 수행하도록 할 수 있다. 여러 항목을 한 번에 처리해야 하는 경우, `BatchGetItem`과 `BatchWriteItem` API를 사용하여 읽기 및 쓰기 작업의 효율성을 높일 수 있다. 이러한 일괄 처리 작업은 네트워크 왕복 횟수를 줄여 지연 시간을 단축하고 처리량을 최적화한다.
5.2. 조건부 쓰기 및 트랜잭션
5.2. 조건부 쓰기 및 트랜잭션
Amazon DynamoDB는 데이터 무결성을 보장하고 동시성 문제를 관리하기 위해 조건부 쓰기와 트랜잭션 기능을 제공한다.
조건부 쓰기는 `PutItem`, `UpdateItem`, `DeleteItem` 작업을 수행할 때 특정 조건이 참인 경우에만 작업을 실행하도록 한다. 조건은 속성의 존재 여부나 특정 값을 기준으로 정의할 수 있다. 예를 들어, 주문 상태가 "대기 중"일 때만 상태를 "처리 중"으로 업데이트하거나, 재고 수량이 0보다 클 때만 감소시키는 로직을 구현할 수 있다. 조건이 충족되지 않으면 작업은 실패하며, 클라이언트는 이 실패를 처리할 수 있다. 이 메커니즘은 낙관적 동시성 제어를 구현하는 데 유용하며, 여러 클라이언트가 동일한 항목을 동시에 수정할 때 발생할 수 있는 데이터 덮어쓰기 문제를 방지한다.
DynamoDB 트랜잭션은 여러 항목에 걸친 원자성, 일관성, 격리성, 지속성(ACID)을 보장한다. `TransactWriteItems`와 `TransactGetItems`라는 두 가지 주요 작업을 제공한다. `TransactWriteItems`는 최대 100개의 `Put`, `Update`, `Delete`, `ConditionCheck` 작업을 하나의 원자적 단위로 묶어 실행한다. 작업 중 하나라도 실패하면 전체 트랜잭션이 롤백된다. `TransactGetItems`는 여러 항목을 일관되게 읽어들인다. 트랜잭션은 온라인 거래 처리(OLTP) 애플리케이션, 금융 시스템, 재고 관리와 같이 정확성이 중요한 사용 사례에 적합하다. 단, 트랜잭션 작업은 표준 작업보다 더 많은 용량 단위를 소비하며, 제한 시간이나 충돌로 인해 실패할 경우 재시도 로직이 필요하다.
다음은 조건부 쓰기와 트랜잭션의 주요 특징을 비교한 표이다.
특징 | 조건부 쓰기 | 트랜잭션 (TransactWriteItems) |
|---|---|---|
적용 범위 | 단일 항목에 대한 작업 | 최대 100개 항목에 대한 다중 작업 |
보장 수준 | 단일 항목에 대한 조건 충족 | 다중 항목에 대한 ACID 속성 |
사용 작업 | `PutItem`, `UpdateItem`, `DeleteItem` | `Put`, `Update`, `Delete`, `ConditionCheck`의 조합 |
용량 소비 | 표준 쓰기 용량 단위 | 표준 쓰기 용량 단위의 2배 소비[5] |
주요 사용 사례 | 낙관적 동시성 제어, 간단한 상태 검증 | 재고 이체, 다중 엔티티 업데이트, 정확성이 요구되는 비즈니스 로직 |
5.3. 스트림 및 변경 데이터 캡처
5.3. 스트림 및 변경 데이터 캡처
Amazon DynamoDB 스트림은 테이블의 데이터 수정 이벤트(추가, 업데이트, 삭제)가 발생할 때마다 이벤트 레코드를 시간 순서대로 캡처하여 저장하는 기능이다. 이 스트림은 변경 데이터 캡처(CDC)를 구현하는 핵심 메커니즘으로 작동한다. 스트림에 기록된 각 레코드는 테이블 항목의 수정 내용과 메타데이터(예: 이벤트 시간, 시퀀스 번호)를 포함하며, 최대 24시간 동안 보존된다. 이를 통해 애플리케이션은 테이블에서 발생하는 실시간 데이터 변경 사항을 읽고 반응할 수 있다.
스트림을 활성화하면 AWS Lambda 함수를 트리거로 연결하여 이벤트를 처리하는 것이 일반적인 패턴이다. 예를 들어, 주문 테이블에 새 항목이 삽입되면 스트림이 이벤트를 생성하고, 연결된 Lambda 함수가 이를 읽어 실시간으로 주문 확인 이메일을 발송하거나 재고를 업데이트하는 로직을 실행할 수 있다. 스트림 레코드는 샤드라는 단위로 구성되며, 애플리케이션은 샤드 이터레이터를 사용해 레코드를 순차적으로 읽는다.
이 기능의 주요 사용 사례는 다음과 같다.
사용 사례 | 설명 |
|---|---|
실시간 분석 | 변경 사항을 Amazon Redshift나 Amazon OpenSearch Service 등으로 전송하여 대시보드 업데이트 |
구체화된 뷰 유지 | 여러 테이블의 데이터를 집계하여 단일 요약 테이블을 자동으로 유지 |
데이터 복제 | 다른 리전의 DynamoDB 테이블이나 다른 데이터 저장소로 데이터를 동기화 |
이벤트 기반 아키텍처 | 마이크로서비스 간 통신 또는 워크플로우를 트리거 |
스트림은 테이블 수준에서 활성화되며, 보기 유형을 설정하여 어떤 정보를 캡처할지 제어할 수 있다. 사용 가능한 옵션으로는 키 속성만, 새 이미지, 이전 이미지, 또는 새 이미지와 이전 이미지 모두를 포함하는 것이 있다. 이는 변경 전후의 데이터 상태를 비교하거나 감사 로그를 생성할 때 유용하다. 스트림을 통한 변경 데이터 캡처는 데이터 파이프라인을 구축하거나 애플리케이션 상태를 일관되게 유지해야 하는 복잡한 시스템에서 강력한 도구가 된다.
6. 보안 및 관리
6. 보안 및 관리
Amazon DynamoDB의 보안 및 관리는 IAM 정책, 암호화, 백업, 모니터링을 포함한 포괄적인 기능을 제공하여 데이터를 보호하고 운영 효율성을 유지한다.
접근 제어는 IAM을 통해 세밀하게 관리된다. 사용자, 그룹 또는 역할에 특정 DynamoDB 작업(예: PutItem, Query, Scan) 및 리소스(특정 테이블 또는 인덱스)에 대한 권한을 부여하는 정책을 생성할 수 있다. 조건 키를 사용하면 요청 소스 IP 주소나 특정 항목 속성 값에 기반한 접근 제어도 가능하다[6]. 모든 데이터는 기본적으로 AWS KMS를 사용한 서버 측 암호화로 보호되며, 고객 관리형 키를 사용할 수 있다.
데이터 보호를 위해 포인트 인 타임 복구 및 온디맨드 백업 기능을 제공한다. 포인트 인 타임 복구는 최근 35일 동안의 특정 시점으로 테이블을 자동으로 복원할 수 있게 한다. 온디맨드 백업은 장기 보관을 위해 수동으로 전체 테이블 백업을 생성하며, 백업은 자동으로 암호화되고 수명 주기 정책으로 관리할 수 있다. 복원 작업은 새 테이블을 생성한다.
모니터링은 Amazon CloudWatch와 통합되어 이루어진다. 소비된 읽기/쓰기 용량 단위, 시스템 오류, 사용자 요청 지연 시간 등 주요 지표를 실시간으로 추적할 수 있다. CloudWatch 경보를 설정하여 용량 사용률이나 오류율이 임계값을 초과할 때 알림을 받거나 AWS Lambda 함수를 트리거할 수 있다. 모든 API 호출은 AWS CloudTrail에 기록되어 감사 및 규정 준수 요구 사항을 충족하는 데 도움을 준다.
6.1. IAM 정책 및 암호화
6.1. IAM 정책 및 암호화
Amazon DynamoDB의 보안은 IAM 정책과 암호화를 중심으로 구성된다. IAM을 사용하여 데이터베이스 리소스에 대한 세밀한 접근 제어를 구현할 수 있다. 사용자, 그룹 또는 역할에 정책을 연결하여 특정 테이블이나 인덱스에 대한 CRUD 작업(예: `dynamodb:PutItem`, `dynamodb:Query`)을 허용하거나 거부할 수 있다. 또한 조건 키를 활용해 특정 IP 주소에서의 접근만 허용하거나, 요청이 암호화된 상태로 전송되어야 한다는 조건을 부여할 수 있다[7].
DynamoDB는 저장 데이터와 전송 중 데이터에 대한 암호화를 제공한다. 모든 테이블의 데이터는 기본적으로 AWS KMS에서 관리하는 키를 사용한 서버 측 암호화로 보호된다. 사용자는 AWS 관리형 키를 사용하거나, 직접 생성하고 관리하는 고객 관리형 키(CMK)를 선택할 수 있다. 전송 중인 모든 데이터는 TLS를 통해 암호화된다. 이러한 암호화는 성능 저하 없이 백업, 글로벌 테이블, 스트림 등 모든 데이터 관련 작업에 자동으로 적용된다.
보안 영역 | 구현 방식 | 주요 특징 |
|---|---|---|
인증 및 권한 부여 | AWS IAM 정책 | 테이블, 인덱스, 항목, 속성 수준의 세분화된 접근 제어 가능 |
저장 데이터 암호화 | AWS KMS를 이용한 서버 측 암호화 | 기본 활성화, AWS 관리형 키 또는 고객 관리형 키(CMK) 선택 |
전송 중 데이터 암호화 | TLS(Transport Layer Security) | 모든 네트워크 통신에 자동 적용 |
6.2. 백업 및 복원
6.2. 백업 및 복원
Amazon DynamoDB는 데이터의 내구성과 가용성을 보장하기 위해 자동화된 백업 및 복원 기능을 제공합니다. PITR(Point-in-Time Recovery) 기능은 지난 35일 동안의 특정 시점(초 단위)으로 테이블을 복원할 수 있게 합니다. 이는 실수로 데이터를 삭제하거나 손상시켰을 때 매우 유용합니다. PITR은 추가 비용이 발생하지만, 복구 시간 목표(RTO)와 복구 시점 목표(RPO)를 크게 단축시킵니다.
수동 백업을 위해서는 온디맨드 백업 기능을 사용할 수 있습니다. 사용자는 언제든지 전체 테이블의 스냅샷을 생성할 수 있으며, 이 백업은 삭제할 때까지 무기한 보관됩니다. 백업은 원본 테이블의 읽기/쓰기 성능에 영향을 주지 않으며, 백업 시점의 데이터 일관성을 보장합니다. 백업된 데이터는 Amazon S3에 안전하게 저장되지만, 사용자는 직접 관리하지 않아도 됩니다.
복원 작업은 새 DynamoDB 테이블을 생성하는 방식으로 이루어집니다. PITR을 통한 복원이나 온디맨드 백업으로부터의 복원 모두, 원본 테이블과는 별개의 새로운 테이블이 만들어집니다. 복원 시에는 테이블 설정(예: 암호화 키, 태그)을 유지하거나 변경할 수 있으며, 복원된 테이블의 용량 모드는 기본적으로 온디맨드 용량 모드로 설정됩니다. 이후 필요에 따라 프로비저닝된 용량 모드로 전환할 수 있습니다.
기능 | 설명 | 보존 기간/특징 |
|---|---|---|
PITR (Point-in-Time Recovery) | 특정 초 단위 시점으로 테이블 복원 | 활성화 시 최대 35일 이내의 복원 가능 |
온디맨드 백업 | 사용자가 수동으로 생성하는 전체 테이블 스냅샷 | 삭제 시까지 무기한 보관, 백업 시점 일관성 보장 |
복원 결과 | 원본과 별개의 새 테이블 생성 | 기본 용량 모드는 온디맨드로 설정됨 |
이러한 백업 메커니즘은 AWS Backup 서비스와 통합되어 중앙에서 관리 및 자동화 정책을 적용할 수 있습니다. 또한 글로벌 테이블을 사용하는 경우, 각 복제본 리전에서 독립적으로 PITR을 구성하고 관리해야 합니다.
6.3. 모니터링 및 알림
6.3. 모니터링 및 알림
Amazon DynamoDB의 운영 상태와 성능을 추적하기 위해 AWS CloudWatch와 통합된 다양한 모니터링 도구를 제공합니다. 주요 지표로는 소비된 읽기 용량 단위와 쓰기 용량 단위, 성공적인/실패한 요청 수, 시스템 오류, 쓰기 지연 시간 및 읽기 지연 시간 등이 있습니다. 이러한 지표는 CloudWatch 콘솔에서 시각화하거나, CloudWatch 경보를 설정하여 특정 임계값을 초과할 때 알림을 받거나 자동 조치를 트리거할 수 있습니다.
DynamoDB는 테이블 수준과 계정 수준의 지표를 모두 제공합니다. 또한 DynamoDB Accelerator(DAX)를 사용하는 경우 DAX 클러스터에 대한 별도의 지표 집합도 모니터링할 수 있습니다. 중요한 운영 지표를 예시로 들면 다음과 같습니다.
지표 이름 | 설명 | 일반적인 모니터링 목적 |
|---|---|---|
`ConsumedReadCapacityUnits` | 소비된 읽기 용량 단위 | 프로비저닝된 용량이 적절한지 확인 |
`ConsumedWriteCapacityUnits` | 소비된 쓰기 용량 단위 | 프로비저닝된 용량이 적절한지 확인 |
`ThrottledRequests` | 제한된 요청 수 | 용량 부족 또는 핫 파티션 문제 탐지 |
`SuccessfulRequestLatency` | 성공한 요청의 평균 지연 시간 | 애플리케이션 응답 시간 보장 |
`SystemErrors` | DynamoDB 내부 오류 수 | 서비스 건강 상태 확인 |
사용자는 CloudWatch 경보를 통해 이메일(Amazon SNS), AWS Lambda 함수 실행, 또는 Auto Scaling 정책 조정과 같은 알림 및 자동 대응 메커니즘을 구성할 수 있습니다. 또한 AWS CloudTrail을 활성화하여 DynamoDB에 대한 모든 API 호출을 로깅하고, 감사 및 보안 분석에 활용할 수 있습니다.
7. 사용 사례
7. 사용 사례
Amazon DynamoDB는 낮은 지연 시간과 높은 처리량을 요구하는 다양한 애플리케이션에 적합한 완전 관리형 NoSQL 데이터베이스 서비스이다. 주요 사용 사례는 다음과 같다.
게임 및 실시간 애플리케이션: 다중 사용자 온라인 게임이나 실시간 대화형 애플리케이션에서는 플레이어 프로필, 세션 상태, 리더보드 데이터와 같은 정보를 매우 빠르게 읽고 써야 한다. DynamoDB의 단일 자릿수 밀리초 지연 시간과 자동 확장 기능은 사용자 수가 급증하는 상황에서도 일관된 성능을 보장한다. 게임 내 아이템 인벤토리나 실시간 채팅 기록을 저장하는 데에도 효과적으로 사용된다.
IoT 및 시계열 데이터: 사물인터넷 디바이스에서 생성되는 대량의 센서 데이터나 애플리케이션 로그, 사용자 활동 추적 데이터를 처리하는 데 적합하다. 파티션 키를 디바이스 ID로, 정렬 키를 타임스탬프로 설정하면 특정 디바이스의 시간 범위 데이터를 효율적으로 쿼리할 수 있다. DynamoDB의 TTL 기능을 사용하면 데이터 보존 정책에 따라 오래된 데이터를 자동으로 삭제하여 관리 부담을 줄일 수 있다.
사용 사례 분야 | 저장 데이터 예시 | DynamoDB 활용 특징 |
|---|---|---|
캐싱 및 세션 저장소 | 사용자 세션, 웹 페이지 캐시, 데이터베이스 쿼리 결과 캐시 | 온디맨드 용량 모드로 예측 불가한 트래픽 처리, DynamoDB Accelerator와 통합 가능 |
e-커머스 및 카탈로그 | 사용자 장바구니, 제품 카탈로그, 주문 이력 |
캐싱 및 세션 저장소: 웹 애플리케이션의 상태 비저장 백엔드 앞에 상태 저장 계층으로 DynamoDB를 사용할 수 있다. 사용자 로그인 세션 정보나 자주 조회되는 데이터의 캐시를 저장하면 백엔드 관계형 데이터베이스 관리 시스템의 부하를 크게 줄일 수 있다. 특히 온디맨드 용량 모드는 트래픽 패턴이 불규칙한 애플리케이션에 유리하며, 더 낮은 지연 시간이 필요한 경우 DAX를 함께 사용할 수 있다.
7.1. 게임, IoT, 실시간 애플리케이션
7.1. 게임, IoT, 실시간 애플리케이션
Amazon DynamoDB는 짧은 지연 시간과 높은 처리량 요구사항을 가진 게임, 사물인터넷, 실시간 애플리케이션에 적합한 데이터베이스 서비스이다. 이들 사용 사례는 일반적으로 예측 불가능한 트래픽 패턴과 급격한 확장이 필요하며, DynamoDB의 관리형 서비스 특성과 탄력적인 확장 기능이 이를 효과적으로 지원한다.
게임 개발에서 DynamoDB는 플레이어 프로필, 인벤토리, 리더보드, 게임 상태와 같은 데이터를 저장하는 데 널리 사용된다. 예를 들어, 신규 게임 출시나 인기 이벤트 시 수백만 명의 플레이어가 동시에 접속해도, 온디맨드 용량 모드나 자동 확장을 통해 지연 시간을 유지하며 처리량을 자동으로 조정할 수 있다. 이는 게임 서버의 부하를 분산시키고 일관된 사용자 경험을 제공하는 데 핵심적이다.
사물인터넷 애플리케이션에서는 수십억 개의 디바이스에서 생성되는 시계열 데이터를 처리해야 한다. DynamoDB는 파티션 키와 정렬 키를 조합해 디바이스 ID와 타임스탬프를 효율적으로 구성함으로써, 대량의 센서 데이터를 빠르게 수집하고 쿼리할 수 있다. TTL(Time to Live) 기능을 사용하면 자동으로 오래된 데이터를 삭제하여 스토리지 비용을 관리할 수 있다.
실시간 애플리케이션, 예를 들어 협업 도구, 채팅 앱, 실시간 분석 대시보드 등은 데이터의 최신 상태를 매우 낮은 지연 시간으로 제공해야 한다. DynamoDB의 DynamoDB 스트림은 데이터 변경 사항을 실시간으로 캡처하여 이를 AWS Lambda 함수나 다른 애플리케이션에 전달할 수 있다. 이를 통해 사용자 인터페이스를 즉시 업데이트하거나 복잡한 이벤트 처리를 구현하는 것이 가능해진다.
사용 사례 | DynamoDB 활용 예 | 주요 이점 |
|---|---|---|
게임 | 플레이어 상태, 세션 데이터, 리더보드 저장 | 수직/수평 확장성, 밀리초 단위 응답 |
사물인터넷 | 디바이스 센서 데이터의 시계열 저장 및 쿼리 | 대량 쓰기 처리, TTL을 통한 자동 데이터 관리 |
실시간 앱 | 사용자 활동 피드, 실시간 채팅 메시지, 협업 편집 | 스트림 기반 실시간 처리, 고가용성 |
7.2. 캐싱 및 세션 저장소
7.2. 캐싱 및 세션 저장소
Amazon DynamoDB는 짧은 지연 시간과 높은 처리량을 제공하는 완전 관리형 서비스로, 캐싱 계층과 세션 저장소 구현에 효과적으로 사용될 수 있다. 이는 특히 웹 애플리케이션과 마이크로서비스 아키텀이처에서 자주 활용되는 패턴이다.
캐싱 계층으로서 DynamoDB는 자주 조회되는 데이터를 빠르게 제공하여 백엔드 데이터베이스의 부하를 줄이고 애플리케이션 응답 속도를 향상시킨다. TTL(Time To Live) 속성을 활용하면 캐시 항목에 자동 만료 시간을 설정할 수 있어, 오래된 데이터가 자동으로 삭제되도록 관리할 수 있다. 이는 데이터 정합성을 유지하면서도 캐시 무효화 로직을 단순화하는 데 도움이 된다. 또한 온디맨드 용량 모드를 사용하면 예측하기 어려운 캐시 요청 패턴에 맞춰 유연하게 용량을 조절할 수 있다.
세션 저장소로서 DynamoDB는 사용자 세션 데이터를 안정적으로 저장하는 데 적합하다. 각 사용자 세션은 고유한 세션 ID를 파티션 키로 하여 항목으로 저장되며, 필요한 모든 세션 속성을 문서 형식으로 포함할 수 있다. DynamoDB의 단일 자릿수 밀리초 지연 시간은 사용자 요청 처리에 필수적인 빠른 세션 조회를 보장한다. 여러 애플리케이션 인스턴스가 공유 세션 저장소로 동일한 DynamoDB 테이블을 가리키도록 구성하면, 무상태(Stateless) 애플리케이션 설계와 사용자 트래픽의 자동 확장이 용이해진다.
특징 | 캐싱 사용 사례 | 세션 저장소 사용 사례 |
|---|---|---|
주요 목적 | 데이터베이스 부하 감소, 응답 시간 개선 | 사용자 세션 상태의 중앙 집중식 관리 |
키 설계 | 쿼리 키 또는 객체 ID를 파티션 키로 사용 | 세션 ID를 파티션 키로 사용 |
주요 기능 | TTL(Time To Live)을 통한 자동 만료 | 빠른 읽기/쓰기 성능, 강력한 일관성 옵션 |
용량 모드 | 예측 불가한 트래픽에는 온디맨드, 안정적 패턴에는 프로비저닝 | 일반적으로 프로비저닝 모드로 예측 가능한 용량 관리 |
이러한 사용 방식은 Memcached나 Redis와 같은 전용 인메모리 캐시를 완전히 대체하지는 못할 수 있으나, 애플리케이션 스택을 단순화하고 운영 오버헤드를 줄이려는 경우, 특히 이미 AWS 생태계 내에서 DynamoDB를 사용 중이라면 매력적인 대안이 될 수 있다.
8. 장단점
8. 장단점
Amazon DynamoDB는 완전관리형 NoSQL 데이터베이스 서비스로서, 특정한 장점과 함께 몇 가지 고려 사항을 가지고 있다.
주요 장점은 뛰어난 확장성과 성능, 그리고 관리 부담의 최소화에 있다. 서버리스 아키텍처를 기반으로 하여 용량 계획이나 서버 프로비저닝 없이도 자동으로 처리량을 조정하고 데이터를 분산시킨다. 이는 예측 불가능한 트래픽 패턴을 가진 애플리케이션에 매우 적합하다. 또한 단일 자릿수 밀리초의 지연 시간을 보장하며, 내구성과 가용성을 위해 데이터를 자동으로 복제한다. 운영 측면에서는 하드웨어 프로비저닝, 패치 적용, 클러스터 확장과 같은 인프라 관리 작업이 완전히 AWS에 의해 처리되어 개발팀이 비즈니스 로직에 집중할 수 있게 한다.
반면, DynamoDB의 사용은 몇 가지 제약과 비용 고려 사항을 동반한다. 가장 큰 단점은 유연성 부족이다. 관계형 데이터베이스와 같은 복잡한 조인 쿼리나 임의의 SQL 쿼리를 지원하지 않으며, 데이터 접근 패턴은 주로 파티션 키와 정렬 키, 그리고 보조 인덱스를 통해 미리 설계되어야 한다. 비용 구조도 주의 깊게 검토해야 한다. 프로비저닝된 용량 모드에서는 사용하지 않는 용량에 대해서도 비용이 발생할 수 있으며, 온디맨드 모드는 예측 가능한 트래픽에서는 비용 효율이 떨어질 수 있다. 저장 비용 외에도 읽기/쓰기 작업, 글로벌 테이블 복제, 데이터 스트림 등 다양한 작업에 대해 별도로 요금이 부과된다.
다음 표는 주요 장단점을 요약하여 보여준다.
장점 | 단점 |
|---|---|
완전 관리형 서비스로 운영 오버헤드 극소화 | 복잡한 조인 및 유연한 쿼리 부재 |
자동 확장으로 예측 불가능한 트래픽 대응 용이 | 데이터 모델과 접근 패턴을 사전에 철저히 설계해야 함 |
단일 자릿수 밀리초의 빠른 응답 시간 | 비용 구조가 복잡하며, 사용 패턴에 따라 비용 효율성 변동 |
높은 가용성과 내구성 보장 (기본 3개 AZ 복제) | 스토리지 항목 크기(400KB) 및 초당 처리량에 제한 존재 |
AWS Lambda, Amazon S3 등 다른 AWS 서비스와의 긴밀한 통합 | 강력한 일관성 읽기는 표준 일관성 읽기보다 더 많은 용량 단위를 소비함 |
결론적으로, DynamoDB는 대규모 확장성, 낮은 지연 시간, 관리 편의성이 최우선인 애플리케이션, 특히 마이크로서비스 아키텍처, 실시간 분석, IoT 데이터 처리에 강력한 선택지이다. 그러나 복잡한 트랜잭션 관계나 임의의 애드혹 쿼리가 빈번한 경우에는 관계형 데이터베이스 관리 시스템이나 다른 유형의 NoSQL 데이터베이스가 더 적합할 수 있다.
9. 관련 서비스 및 통합
9. 관련 서비스 및 통합
Amazon DynamoDB는 AWS 생태계 내 다른 서비스들과 긴밀하게 통합되어 광범위한 애플리케이션 아키텍처를 구성할 수 있게 한다. 특히 서버리스 컴퓨팅 서비스인 AWS Lambda와의 통합은 대표적이다. DynamoDB 테이블에 데이터가 쓰이거나 수정되면 이를 DynamoDB 스트림을 통해 실시간으로 캡처할 수 있으며, 이 스트림을 이벤트 소스로 삼아 Lambda 함수를 자동으로 트리거할 수 있다[8]. 이는 복잡한 비즈니스 로직이나 데이터 변환 작업을 별도의 애플리케이션 계층 없이 구현하는 데 유용하다. 또한 Amazon API Gateway와 결합하면 DynamoDB를 백엔드 데이터 저장소로 사용하는 완전한 서버리스 REST API를 쉽게 구축할 수 있다.
대용량 데이터 처리 및 분석을 위해 Amazon S3 및 Amazon Redshift와의 통합도 중요하다. AWS Data Pipeline이나 AWS Glue를 사용하면 DynamoDB 테이블의 데이터를 정기적으로 Amazon S3에 내보내 백업하거나 보관할 수 있다. 반대로 S3에 저장된 JSON, CSV 형식의 데이터를 DynamoDB 테이블로 가져오는 작업도 가능하다. 분석 작업을 위해서는 DynamoDB 데이터를 Amazon Redshift나 Amazon EMR으로 복제하여 대규모 SQL 쿼리나 복잡한 데이터 처리 작업을 수행할 수 있다. 이는 DynamoDB의 운영 데이터와 분석 시스템을 효율적으로 연동하는 패턴이다.
다음은 주요 통합 서비스와 그 용도를 정리한 표이다.
통합 AWS 서비스 | 주요 용도 |
|---|---|
데이터 변경 시 이벤트 기반 비즈니스 로직 실행, 서버리스 백엔드 구성 | |
DynamoDB를 데이터 소스로 하는 RESTful API 노출 | |
데이터 백업, 보관, 대용량 데이터 임포트/익스포트 | |
운영 데이터를 데이터 웨어하우스로 복제하여 분석 쿼리 수행 | |
테이블 지표 모니터링, 용량 단위 사용량 추적 및 알람 설정 | |
테이블 및 항목 수준의 세분화된 접근 제어 정책 적용 |
이러한 통합을 통해 DynamoDB는 단순한 키-값 저장소를 넘어, 이벤트 주도 아키텍처, 마이크로서비스, 실시간 분석 파이프라인 등 현대적 애플리케이션의 핵심 구성 요소로 자리잡게 되었다.
9.1. AWS Lambda 및 API Gateway
9.1. AWS Lambda 및 API Gateway
Amazon DynamoDB는 AWS Lambda 및 Amazon API Gateway와 긴밀하게 통합되어 서버리스 애플리케이션 아키텍처의 핵심 데이터 계층을 구성한다.
AWS Lambda는 DynamoDB 테이블의 데이터 변경 사항에 직접 반응할 수 있다. DynamoDB 스트림을 활성화하면 테이블의 항목에 대한 생성, 수정, 삭제 이벤트가 실시간으로 기록된다. Lambda 함수는 이 스트림을 이벤트 소스로 구독하여, 예를 들어 주문이 생성될 때 재고를 감소시키거나 사용자 프로필이 업데이트될 때 검색 인덱스를 갱신하는 등의 비즈니스 로직을 트리거할 수 있다[9]. 이 통합은 전통적인 폴링 방식보다 효율적이며 완전한 서버리스 데이터 처리 파이프라인을 구축하는 데 필수적이다.
Amazon API Gateway는 DynamoDB에 대한 HTTP 기반의 안전한 접근 경로를 제공한다. API Gateway에서 정의한 RESTful API 엔드포인트는 Lambda 함수와 연결되고, 해당 함수는 내부적으로 DynamoDB에 대한 읽기 또는 쓰기 작업을 수행한다. 이 패턴은 클라이언트 애플리케이션이 데이터베이스에 직접 연결하지 않고도 데이터에 접근할 수 있게 하여 보안을 강화한다. 일반적인 사용 패턴은 다음과 같다.
클라이언트 요청 | API Gateway 경로 | Lambda 함수 역할 | DynamoDB 작업 |
|---|---|---|---|
`GET /users/{id}` | `/users/{id}` | 요청 매개변수를 파싱하여 `GetItem` 실행 | 사용자 항목 조회 |
`POST /items` | `/items` | 요청 본문을 검증하여 `PutItem` 실행 | 새 항목 생성 |
`PUT /orders/{orderId}` | `/orders/{orderId}` | 조건부 쓰기 로직 수행 | 주문 상태 업데이트 |
이 조합을 통해 개발자는 인프라 관리 부담 없이 확장성 높은 백엔드 API를 빠르게 구축할 수 있다. DynamoDB의 성능, Lambda의 이벤트 기반 실행, API Gateway의 관리형 API 계층이 결합되어 마이크로서비스 및 모바일 백엔드에 이상적인 플랫폼을 제공한다.
9.2. Amazon S3 및 Redshift
9.2. Amazon S3 및 Redshift
Amazon DynamoDB는 AWS의 다른 핵심 서비스들과 긴밀하게 통합되어 데이터 처리 파이프라인을 구축하거나 분석 워크로드를 지원합니다. Amazon S3와 Amazon Redshift는 이러한 통합에서 중요한 역할을 합니다.
DynamoDB의 데이터를 Amazon S3로 내보내는 작업은 장기적인 데이터 보관, 비용 효율적인 아카이빙, 또는 대규모 분석을 위한 준비 단계로 자주 사용됩니다. AWS Data Pipeline 또는 AWS Glue를 사용하면 DynamoDB 테이블의 데이터를 정기적으로 또는 일회성으로 S3에 내보낼 수 있습니다. S3에 저장된 데이터는 Amazon Athena를 사용해 SQL로 직접 쿼리하거나, Amazon EMR을 활용한 대규모 데이터 처리 작업에 사용될 수 있습니다. 또한 S트림을 통해 S3로 실시간 내보내기를 구성할 수도 있습니다.
보다 정형화된 분석을 위해서는 DynamoDB 데이터를 Amazon Redshift 데이터 웨어하우스로 로드하는 것이 일반적입니다. Redshift는 복잡한 조인과 집계 쿼리를 실행하는 데 최적화되어 있습니다. DynamoDB에서 Redshift로 데이터를 이동하는 방법은 주로 두 가지입니다. 첫째, 앞서 언급한 대로 DynamoDB 데이터를 먼저 S3로 내보낸 후, Redshift의 `COPY` 명령을 사용하여 적재하는 방식입니다. 둘째, AWS Glue를 ETL(추출, 변환, 로드) 작업 오케스트레이터로 사용하여 데이터를 변환하고 Redshift에 직접 로드할 수 있습니다.
이러한 통합은 DynamoDB의 운영 데이터베이스로서의 낮은 지연 시간 처리 성능과 S3의 거의 무제한적인 저장 공간, Redshift의 강력한 분석 능력을 결합합니다. 결과적으로 애플리케이션은 실시간 트랜잭션 처리와 역사적 데이터에 대한 심층 분석을 하나의 아키텍처 내에서 모두 수행할 수 있게 됩니다.
