아마존 DynamoDB
1. 개요
1. 개요
아마존 웹 서비스에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스이다. 2012년 1월 18일에 정식 출시되었다. 아마존닷컴이 자사 대규모 서비스의 요구사항을 충족시키기 위해 내부적으로 개발한 키-값 저장소 기술을 기반으로 하여, 이를 클라우드 서비스로 공개한 것이 특징이다.
서버 프로비저닝, 패치 적용, 백업, 복구와 같은 데이터베이스 관리 작업을 자동화하여 개발자가 인프라 관리 부담 없이 애플리케이션 개발에 집중할 수 있도록 설계되었다. 키-값 및 문서 데이터 모델을 지원하며, JSON 형식의 문서를 저장하고 쿼리하는 데 적합하다.
가장 큰 장점은 예측 가능한 성능과 자동 확장성에 있다. 워크로드의 트래픽이 급증하거나 감소하더라도 이를 자동으로 감지하고 처리 용량을 조정하여 일관된 저지연 성능을 유지한다. 또한 데이터를 여러 가용 영역에 자동으로 복제하여 높은 내구성과 가용성을 제공한다.
주로 사용자 프로필, 쇼핑 카트, 게임 상태, IoT 디바이스 데이터와 같이 대규모로 접근해야 하는 데이터를 저장하는 데 널리 사용된다.
2. 주요 특징
2. 주요 특징
2.1. 완전관리형 서비스
2.1. 완전관리형 서비스
아마존 DynamoDB는 완전관리형 서비스로서, 사용자가 데이터베이스 서버의 프로비저닝, 설정, 패치, 백업, 복구와 같은 운영상의 번거로운 작업을 직접 관리할 필요가 없다. 이는 사용자가 인프라 관리가 아닌 애플리케이션 개발과 비즈니스 로직에 집중할 수 있도록 설계된 클라우드 컴퓨팅의 핵심 이점을 구현한 것이다. 서비스는 아마존 웹 서비스가 전적으로 관리하며, 사용자는 웹 콘솔, CLI, 또는 SDK를 통해 데이터베이스를 생성하고 사용하기만 하면 된다.
이러한 완전관리형 특성은 데이터베이스의 성능, 확장성, 내구성을 보장하는 데 필수적인 요소이다. 사용자는 하드웨어 용량 계획이나 클러스터 관리에 신경 쓸 필요 없이, 애플리케이션의 트래픽 패턴에 따라 데이터베이스가 자동으로 확장되도록 구성할 수 있다. 또한, 아마존 웹 서비스는 데이터의 다중 가용 영역에 걸친 복제와 자동 백업을 포함한 내구성 메커니즘을 기본적으로 제공하여 고가용성과 데이터 보호를 실현한다.
이 서비스 모델은 특히 빠르게 변화하는 워크로드를 처리하거나 예측 불가능한 트래픽을 겪는 애플리케이션에 유리하다. 개발 팀은 데이터베이스 운영 인력을 별도로 구성하거나 심화된 데이터베이스 관리 기술을 보유하지 않아도, 신속하게 확장 가능한 데이터 계층을 구축할 수 있다. 결과적으로 DynamoDB는 마이크로서비스 아키텍처, 서버리스 컴퓨팅, 그리고 실시간 애플리케이션을 위한 핵심 데이터 저장소로 널리 채택되고 있다.
2.2. 키-값 및 문서 데이터 모델
2.2. 키-값 및 문서 데이터 모델
아마존 DynamoDB는 키-값 저장소와 문서 데이터베이스의 특성을 결합한 하이브리드 데이터 모델을 제공한다. 이 모델의 핵심은 기본 키를 사용해 항목을 고유하게 식별하고, 그 항목 내부에 다양한 형태의 데이터를 유연하게 저장할 수 있다는 점이다.
키-값 모델에서는 파티션 키 또는 파티션 키와 정렬 키로 구성된 복합 기본 키가 각 항목의 주소 역할을 한다. 이 키를 통해 항목에 빠르게 접근할 수 있으며, 항목의 값 부분에는 어떠한 데이터도 저장할 수 있다. 이는 간단한 문자열부터 복잡한 중첩 객체까지 포함될 수 있어 유연성을 제공한다.
동시에 DynamoDB는 JSON 형식의 문서를 직접 저장하고 쿼리할 수 있는 문서 모델을 지원한다. 각 항목의 속성은 JSON 문서의 필드와 유사하게 구성되며, 배열이나 다른 문서를 중첩하는 것도 가능하다. 이는 애플리케이션 코드의 객체 구조를 데이터베이스에 그대로 반영하는 데 유리하다.
이러한 하이브리드 접근 방식은 스키마리스 특성을 강화한다. 테이블을 생성할 때 각 항목에 저장될 속성을 미리 정의할 필요가 없으며, 항목마다 완전히 다른 속성 집합을 가질 수 있다. 이로 인해 애플리케이션 요구사항이 빠르게 변화하는 환경에서 데이터 모델을 쉽게 진화시킬 수 있다.
2.3. 자동 확장성
2.3. 자동 확장성
아마존 DynamoDB의 자동 확장성은 애플리케이션의 트래픽 패턴 변화에 따라 데이터베이스 성능을 자동으로 조정하는 핵심 기능이다. 이 기능은 사용자가 수동으로 용량을 관리할 필요 없이, 예측 불가능한 워크로드에도 일관된 성능과 낮은 지연 시간을 제공하도록 설계되었다.
자동 확장성은 주로 프로비저닝된 용량 모드에서 작동하며, 아마존 CloudWatch 지표를 기반으로 테이블의 읽기 및 쓰기 용량을 동적으로 조정한다. 애플리케이션의 트래픽이 증가하면 DynamoDB는 용량을 늘려 성능을 유지하고, 트래픽이 감소하면 불필요한 비용을 절감하기 위해 용량을 줄인다. 이는 이커머스의 특정 판촉 기간이나 소셜 미디어 애플리케이션의 갑작스러운 사용량 증가와 같은 상황에서 특히 유용하다.
이러한 확장은 사용자 개입 없이 자동으로 이루어지며, 일반적으로 몇 분 내에 완료된다. 사용자는 최소 및 최대 용량 한도와 목표 활용률만 설정하면 되며, 서비스가 나머지 과정을 처리한다. 이를 통해 개발팀은 인프라 관리보다 애플리케이션 로직 개발에 더 집중할 수 있다.
또한, 온디맨드 용량 모드는 용량 계획이 전혀 필요 없는 완전한 자동 확장성을 제공한다. 이 모드에서는 시스템이 실제 트래픽에 맞춰 즉시 용량을 확장하므로, 변동성이 매우 크거나 예측하기 어려운 워크로드에 적합한 옵션이다.
2.4. 내구성 및 가용성
2.4. 내구성 및 가용성
아마존 DynamoDB는 데이터의 내구성과 서비스의 가용성을 보장하기 위해 여러 기술적 기반을 제공한다. 데이터는 자동으로 여러 가용 영역에 걸쳐 복제되어 저장되며, 이는 단일 데이터 센터의 장애가 발생하더라도 데이터 손실 없이 서비스가 지속될 수 있도록 설계되었다. 이러한 다중 가용 영역 복제는 아마존 웹 서비스의 글로벌 인프라를 활용하여 구현된다.
서비스의 가용성 측면에서 DynamoDB는 높은 수준의 서비스 수준 협약을 제공한다. 이는 애플리케이션이 예측 가능한 성능으로 데이터베이스에 지속적으로 접근할 수 있음을 의미한다. 내부 장애 조치 메커니즘은 사용자 개입 없이 자동으로 수행되어 서비스 중단 시간을 최소화한다. 이러한 특성은 온라인 게임, 금융 서비스, 실시간 분석과 같이 중단 없는 운영이 필수적인 사용 사례에 적합하게 만든다.
데이터 일관성 모델은 내구성과 가용성 보장과 밀접한 관련이 있다. DynamoDB는 애플리케이션의 요구에 따라 강력한 일관성 읽기와 최종적 일관성 읽기 중에서 선택할 수 있는 옵션을 제공한다. 강력한 일관성 읽기는 가장 최신의 쓰기 결과를 반환하지만, 최종적 일관성 읽기는 더 높은 읽기 처리량과 낮은 지연 시간을 제공할 수 있다. 이 유연성을 통해 개발자는 내구성, 가용성, 성능 간의 균형을 맞출 수 있다.
3. 핵심 구성 요소
3. 핵심 구성 요소
3.1. 테이블, 항목, 속성
3.1. 테이블, 항목, 속성
아마존 DynamoDB의 데이터 구조는 테이블, 항목, 속성이라는 세 가지 핵심 구성 요소로 이루어져 있다. 이는 관계형 데이터베이스의 테이블, 행, 열과 유사한 개념이지만, 스키마가 고정되어 있지 않다는 점에서 차이가 있다.
테이블은 데이터를 저장하는 기본 컨테이너이다. 각 테이블은 이름을 가지며, 무제한에 가까운 수의 항목을 저장할 수 있다. 테이블을 생성할 때는 데이터를 고유하게 식별하고 분산 저장을 위한 기준이 되는 기본 키를 반드시 정의해야 한다. 기본 키는 파티션 키만으로 구성된 단순 키와, 파티션 키와 정렬 키로 구성된 복합 키 두 가지 유형이 있다.
항목은 테이블 내에 저장되는 개별 데이터 레코드에 해당한다. 각 항목은 기본 키 속성을 포함하며, 그 외의 데이터는 속성의 집합으로 구성된다. 항목은 최대 400KB의 크기를 가질 수 있다. 속성은 항목을 구성하는 기본 데이터 단위로, 이름과 값의 쌍이다. 속성의 값은 문자열, 숫자, 이진 데이터, 불리언, 널, 리스트, 맵 등 다양한 데이터 타입을 지원한다. 같은 테이블 내의 서로 다른 항목들은 완전히 다른 속성 집합을 가질 수 있는데, 이것이 바로 스키마리스(또는 스키마 유연성)의 특징이다.
이러한 구조 덕분에 애플리케이션은 데이터 모델을 미리 엄격하게 정의하지 않고도, 필요에 따라 항목의 속성을 자유롭게 추가하거나 변경할 수 있다. 이는 애플리케이션 개발 속도를 높이고, 빅데이터와 같이 빠르게 변화하는 데이터를 처리하는 데 유리하다.
3.2. 기본 키
3.2. 기본 키
아마존 DynamoDB에서 기본 키는 테이블의 각 항목을 고유하게 식별하는 필수 속성이다. 기본 키는 테이블을 생성할 때 반드시 정의해야 하며, 이후에는 변경할 수 없다. 기본 키는 테이블의 데이터를 구성하는 핵심 요소로, 모든 데이터 작업의 효율성을 결정한다.
DynamoDB는 두 가지 유형의 기본 키를 지원한다. 첫 번째는 단일 속성으로 구성된 파티션 키이며, 두 번째는 파티션 키와 정렬 키로 구성된 복합 키이다. 파티션 키는 항목이 물리적으로 저장될 파티션을 결정하는 데 사용되며, 정렬 키는 동일한 파티션 키 내에서 항목들을 정렬된 순서로 저장하는 역할을 한다.
파티션 키만 사용하는 단순 키 구조에서는 키 값이 고유해야 한다. 예를 들어 사용자 ID를 파티션 키로 사용하는 경우, 각 사용자 ID는 테이블 내에서 하나의 항목만 가리킨다. 반면 파티션 키와 정렬 키를 함께 사용하는 복합 키 구조에서는 파티션 키 값이 동일하더라도 정렬 키 값이 다르면 서로 다른 항목으로 저장될 수 있다. 이는 주문 테이블에서 고객 ID를 파티션 키로, 주문 시간을 정렬 키로 사용하는 식의 계층적 데이터 모델링에 유용하다.
기본 키의 설계는 확장성과 쿼리 성능에 직접적인 영향을 미친다. 잘 설계된 파티션 키는 데이터와 워크로드를 여러 파티션에 고르게 분산시켜 핫스팟을 방지하는 데 중요하다. 또한 복합 키를 사용하면 정렬 키를 기준으로 효율적인 범위 쿼리를 수행할 수 있어, 보조 인덱스 없이도 다양한 데이터 접근 패턴을 지원할 수 있다.
3.3. 보조 인덱스
3.3. 보조 인덱스
아마존 DynamoDB의 보조 인덱스는 테이블의 기본 키 외에 다른 속성을 사용하여 데이터에 효율적으로 접근할 수 있게 해주는 기능이다. 보조 인덱스를 사용하면 기본 키로만 가능했던 쿼리 작업의 범위를 확장하여, 애플리케이션의 다양한 데이터 접근 패턴을 지원할 수 있다. DynamoDB는 주로 두 가지 유형의 보조 인덱스를 제공한다: 로컬 보조 인덱스와 글로벌 보조 인덱스이다.
로컬 보조 인덱스는 파티션 키는 테이블의 것과 동일하게 유지하되, 정렬 키를 다른 속성으로 대체한 인덱스이다. 이 인덱스는 기본 테이블과 동일한 파티션 키를 공유하기 때문에, 특정 파티션 키 값 내에서만 쿼리 성능을 향상시키는 데 사용된다. 반면, 글로벌 보조 인덱스는 파티션 키와 정렬 키 모두를 테이블의 기본 키와 다르게 정의할 수 있는 완전히 별개의 인덱스이다. 이를 통해 테이블 전체에 걸쳐 다른 속성 조합으로 데이터를 쿼리할 수 있는 유연성을 제공한다.
보조 인덱스를 생성하면 DynamoDB가 자동으로 인덱스의 항목을 관리한다. 테이블에 데이터를 쓰거나, 업데이트하거나, 삭제할 때마다 관련된 모든 보조 인덱스도 자동으로 동기화된다. 이는 개발자가 별도의 인덱스 유지 관리 로직을 작성할 필요가 없음을 의미한다. 각 보조 인덱스는 자체적인 읽기 용량 단위와 쓰기 용량 단위를 가지며, 테이블의 용량 설정과는 별도로 관리된다.
보조 인덱스는 데이터 모델링의 핵심 도구로, 단일 테이블 설계에서도 다양한 쿼리 요구사항을 충족시키는 데 필수적이다. 예를 들어, 사용자 ID를 파티션 키로 하는 테이블에서 생성 날짜나 다른 속성으로 정렬된 데이터를 빠르게 조회해야 할 때, 적절한 보조 인덱스를 생성하여 성능을 최적화할 수 있다.
4. 데이터 작업
4. 데이터 작업
4.1. CRUD 작업
4.1. CRUD 작업
DynamoDB는 CRUD 작업을 위한 핵심적인 API를 제공한다. CRUD는 데이터 관리의 기본이 되는 생성(Create), 읽기(Read), 업데이트(Update), 삭제(Delete) 작업을 의미한다. DynamoDB에서는 PutItem 작업을 통해 새로운 항목을 테이블에 생성하거나 기존 항목을 완전히 대체한다. 항목의 개별 속성 값을 읽기 위해서는 GetItem 작업을 사용하며, 이때 항목을 고유하게 식별하는 기본 키를 지정해야 한다.
데이터를 수정하는 작업은 UpdateItem 작업으로 수행한다. 이 작업은 기존 항목에 새로운 속성을 추가하거나, 기존 속성 값을 수정 및 삭제할 수 있으며, 원자성 있는 카운터 증가와 같은 조건부 업데이트도 지원한다. 항목을 삭제할 때는 DeleteItem 작업을 사용한다. 이 작업도 기본 키를 지정하여 특정 항목만 삭제한다.
이러한 모든 작업은 HTTP 요청을 통해 이루어지며, AWS SDK나 CLI를 통해 쉽게 호출할 수 있다. 각 작업은 필요한 경우 조건 표현식을 지정할 수 있어, 특정 조건이 충족될 때만 작업이 수행되도록 제어할 수 있다. 이는 데이터의 무결성을 유지하는 데 중요한 기능이다.
4.2. 쿼리와 스캔
4.2. 쿼리와 스캔
DynamoDB에서 데이터를 읽는 주요 방법은 쿼리와 스캔이다. 쿼리는 테이블이나 보조 인덱스의 기본 키 속성을 사용하여 특정 항목을 효율적으로 검색하는 작업이다. 파티션 키 값을 지정하고 필요에 따라 정렬 키 조건을 추가하여 원하는 항목 범위를 정밀하게 가져올 수 있다. 쿼리는 기본 키를 기준으로 하기 때문에 빠른 성능을 제공하며, 결과는 기본적으로 정렬 키 순서대로 반환된다.
반면 스캔은 테이블이나 인덱스의 모든 항목을 순차적으로 검사하는 작업이다. 필터 조건을 적용할 수 있지만, 데이터를 처음부터 끝까지 읽어야 하므로 테이블 크기가 클수록 처리 속도가 느리고 읽기 용량을 많이 소모한다는 단점이 있다. 따라서 가능하면 쿼리를 우선적으로 사용하고, 스캔은 불가피한 경우에만 제한적으로 활용하는 것이 성능과 비용 측면에서 바람직하다.
쿼리와 스캔 모두 선택적으로 필터 표현식을 적용하여 반환되는 항목을 추가로 걸러낼 수 있다. 그러나 필터는 데이터를 읽은 후에 적용되는 작업이므로, 쿼리나 스캔 자체가 소비한 읽기 용량 단위는 필터링 여부와 관계없이 동일하다. 효율적인 데이터 접근을 위해서는 적절한 기본 키 설계와 보조 인덱스 생성이 필수적이다.
4.3. 트랜잭션
4.3. 트랜잭션
아마존 DynamoDB의 트랜잭션 기능은 여러 항목에 걸친 데이터 무결성을 보장하는 원자성, 일관성, 고립성, 지속성 작업을 제공한다. 이 기능을 사용하면 애플리케이션에서 여러 읽기 및 쓰기 작업을 하나의 논리적 단위로 그룹화하여, 모든 작업이 성공하거나 모두 실패하도록 할 수 있다. 이를 통해 복잡한 비즈니스 로직을 안전하게 구현할 수 있으며, 특히 금융 거래, 재고 관리, 멀티플레이어 게임의 상태 업데이트와 같이 정확성이 중요한 사용 사례에 유용하다.
DynamoDB 트랜잭션은 트랜잭션 쓰기와 트랜잭션 읽기 두 가지 유형으로 구분된다. 트랜잭션 쓰기는 최대 100개의 항목에 대한 Put, Update, Delete, ConditionCheck 작업을 하나의 원자적 작업으로 묶을 수 있다. 트랜잭션 읽기는 최대 100개의 항목에 대해 강력한 일관된 읽기를 수행한다. 이 모든 작업은 단일 트랜잭션 내에서 동일한 AWS 리전의 하나 이상의 테이블에 대해 수행될 수 있으며, 표준 작업과 동일한 지연 시간 성능을 제공하도록 설계되었다.
트랜잭션 작업은 낙관적 동시성 제어를 사용하여 처리된다. DynamoDB는 트랜잭션을 커밋하기 전에 관련된 항목에 대한 변경 사항이 없는지 확인한다. 만약 트랜잭션 중 하나의 항목이라도 다른 요청에 의해 수정되었다면, 전체 트랜잭션이 취소되고 애플리케이션에 실패가 보고된다. 이 경우 애플리케이션은 트랜잭션을 재시도할 수 있다. 이 메커니즘은 데이터의 일관성을 유지하면서도 성능에 미치는 영향을 최소화한다.
이 기능은 개발자가 복잡한 롤백 로직을 직접 구현할 필요 없이, 여러 데이터 항목을 안전하게 수정할 수 있는 강력한 도구를 제공한다. 아마존 웹 서비스의 완전 관리형 서비스 특성상, 트랜잭션의 가용성과 내구성은 서비스 자체에 의해 보장되며, 사용자는 인프라 관리 부담 없이 애플리케이션 로직에 집중할 수 있다.
5. 용량 모드
5. 용량 모드
5.1. 프로비저닝된 용량 모드
5.1. 프로비저닝된 용량 모드
프로비저닝된 용량 모드는 아마존 DynamoDB에서 사용자가 테이블에 대해 초당 필요한 읽기 및 쓰기 처리량을 미리 정의하고 프로비저닝하는 방식이다. 이 모드는 애플리케이션의 트래픽 패턴이 비교적 예측 가능하거나 일정한 경우에 적합하며, 용량을 사전에 계획하여 비용을 최적화할 수 있다. 사용자는 테이블 생성 시 또는 이후에 필요에 따라 읽기 용량 단위와 쓰기 용량 단위를 설정한다.
이 모드에서는 설정한 용량 한도 내에서 요청이 처리되며, 용량을 초과하는 요청은 제한될 수 있다. 이를 관리하기 위해 DynamoDB는 자동 조정 기능을 제공하여 트래픽 변화에 따라 용량을 자동으로 늘리거나 줄일 수 있다. 또한, 프로비저닝된 용량은 예약 용량을 구매하여 장기적으로 비용을 절감할 수 있는 옵션도 제공한다.
프로비저닝된 용량 모드는 지속적으로 높은 성능이 필요하거나 비용 예측이 중요한 애플리케이션에 유용하다. 예를 들어, 정기적인 사용자 활동이 있는 웹 애플리케이션이나 특정 시간대에 트래픽이 집중되는 이커머스 플랫폼의 백엔드에 적합한 방식이다.
5.2. 온디맨드 용량 모드
5.2. 온디맨드 용량 모드
온디맨드 용량 모드는 아마존 DynamoDB에서 제공하는 용량 관리 방식 중 하나로, 사용자가 용량을 미리 계획하거나 프로비저닝할 필요 없이 애플리케이션의 실제 트래픽에 따라 데이터베이스가 자동으로 확장 및 축소되는 방식을 말한다. 이 모드는 예측하기 어렵거나 간헐적인 트래픽 패턴을 가진 애플리케이션, 또는 개발 및 테스트 단계의 워크로드에 적합하다. 사용자는 읽기 및 쓰기 요청 횟수에 대해서만 비용을 지불하며, 최소 비용이나 장기 약정 없이 사용할 수 있다.
이 모드에서는 DynamoDB가 지난 30분 동안의 트래픽 패턴을 지속적으로 모니터링하며, 급증하는 트래픽을 수용하기 위해 필요한 용량을 거의 실시간으로 조정한다. 이는 사용자가 프로비저닝된 용량 모드에서처럼 처리량 한도를 걱정하거나 용량 부족 오류를 처리할 필요가 없음을 의미한다. 시스템은 애플리케이션의 요청을 처리하는 데 필요한 만큼의 용량을 투명하게 제공한다.
온디맨드 모드는 특히 사용 패턴이 불규칙한 애플리케이션에 유리하다. 예를 들어, 특정 이벤트나 프로모션으로 인해 갑작스럽게 트래픽이 급증하는 이커머스 사이트, 하루 중 특정 시간에만 활성화되는 배치 처리 작업, 또는 사용 빈도가 낮은 관리 도구 등에서 효율적으로 사용될 수 있다. 또한, 초기 개발 단계에서 트래픽을 예측하기 어려울 때나 개념 검증(PoC)을 수행할 때도 유용하다.
단, 예측 가능하고 꾸준한 고성능 트래픽이 지속되는 경우에는 프로비저닝된 용량 모드가 더 비용 효율적일 수 있다. 사용자는 AWS 관리 콘솔을 통해 테이블 생성 시 또는 기존 테이블의 설정에서 두 용량 모드 간을 전환할 수 있으며, 하루에 한 번 변경이 가능하다.
6. 글로벌 테이블
6. 글로벌 테이블
글로벌 테이블은 아마존 DynamoDB가 제공하는 기능으로, 단일 테이블을 여러 AWS 리전에 자동으로 복제하여 전 세계적으로 빠른 읽기 및 쓰기 성능을 제공한다. 이를 통해 애플리케이션은 사용자와 지리적으로 가장 가까운 리전의 데이터에 접근할 수 있어 지연 시간을 크게 줄일 수 있다. 글로벌 테이블은 다중 리전 애플리케이션, 재해 복구, 지리적 중복성을 요구하는 사용 사례에 적합하다.
글로벌 테이블은 마스터-마스터 복제 방식을 사용한다. 각 리전의 테이블은 완전한 읽기/쓰기 기능을 갖춘 마스터로 동작하며, 한 리전에서 발생한 데이터 변경 사항은 일반적으로 1초 이내에 다른 모든 리전에 자동으로 복제된다. 이는 최종적 일관성 모델을 기반으로 하며, 애플리케이션은 어떤 리전에서든 데이터를 읽고 쓸 수 있다.
이 기능을 설정하려면 사용자는 원본 테이블이 있는 리전에서 글로벌 테이블을 생성하고, 복제를 추가할 대상 리전을 선택하기만 하면 된다. AWS 관리 콘솔, AWS CLI, 또는 AWS SDK를 통해 관리할 수 있으며, 복제에 대한 추가 비용은 데이터 전송 비용만 발생한다. 글로벌 테이블은 프로비저닝된 용량 모드와 온디맨드 용량 모드 모두에서 사용할 수 있다.
글로벌 테이블은 전 세계적으로 분산된 사용자 기반을 가진 서비스, 예를 들어 모바일 게임, 전자상거래 플랫폼, 소셜 미디어 애플리케이션 등에서 지역별 성능을 극대화하는 데 효과적이다. 또한 한 리전에 장애가 발생하더라도 다른 리전의 테이블을 통해 서비스 연속성을 유지할 수 있어 고가용성 아키텍처를 구성하는 핵심 요소가 된다.
7. 보안 및 접근 제어
7. 보안 및 접근 제어
7.1. IAM 정책
7.1. IAM 정책
아마존 DynamoDB의 보안 및 접근 제어는 AWS Identity and Access Management 정책을 통해 세밀하게 관리된다. IAM 정책은 JSON 형식의 문서로, DynamoDB 리소스에 대한 사용자, 그룹 또는 역할의 권한을 정의한다. 이 정책을 통해 특정 테이블에 대한 CRUD 작업 허용 여부나, 특정 속성에만 접근을 제한하는 것과 같은 세부적인 접근 제어가 가능하다.
IAM 정책은 최소 권한의 원칙에 따라 구성하는 것이 보안 모범 사례이다. 예를 들어, 웹 애플리케이션의 백엔드 역할만 특정 테이블에 데이터를 쓰는 권한을 부여하고, 다른 서비스는 읽기 전용 권한만 부여할 수 있다. 정책은 DynamoDB 서비스 자체에 대한 액션과 특정 Amazon 리소스 이름을 지정하여 적용 범위를 제한한다.
정책 문장은 효과(허용 또는 거부), 액션(수행할 API 작업), 리소스(대상 테이블 또는 인덱스), 조건(요청의 추가적인 제약 조건)의 주요 요소로 구성된다. 조건을 활용하면 요청자의 IP 주소 범위나 요청 시간대에 따라 접근을 제어하는 것도 가능하다. 이를 통해 DynamoDB에 저장된 데이터에 대한 무단 접근을 효과적으로 방지할 수 있다.
7.2. VPC 엔드포인트
7.2. VPC 엔드포인트
DynamoDB의 VPC 엔드포인트는 가상 사설 클라우드 내의 애플리케이션이 인터넷을 경유하지 않고도 DynamoDB 서비스에 비공개로 안전하게 연결할 수 있도록 해주는 기능이다. 이는 퍼블릭 인터넷을 통한 데이터 전송을 제거함으로써 데이터 유출 위험을 줄이고, 네트워크 대기 시간을 개선하며, 인터넷 게이트웨이나 NAT 게이트웨이와 같은 인프라 없이도 VPC 내부에서 DynamoDB에 접근할 수 있게 한다.
VPC 엔드포인트는 AWS 프라이빗 링크 기술을 기반으로 구축된 게이트웨이 VPC 엔드포인트 유형으로 제공된다. 사용자는 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 엔드포인트를 생성하고, 이를 특정 VPC 및 서브넷에 연결하며, 필요한 라우팅 테이블을 업데이트한다. 생성된 엔드포인트는 DynamoDB 서비스에 대한 트래픽을 VPC 내부의 AWS 백본 네트워크를 통해 직접 전달한다.
보안 측면에서 VPC 엔드포인트는 IAM 정책과 결합하여 세밀한 접근 제어를 구현할 수 있다. VPC 엔드포인트 정책을 통해 특정 IAM 역할이나 사용자가 해당 엔드포인트를 통해서만 DynamoDB에 접근하도록 허용하거나, 특정 API 작업만 수행하도록 제한할 수 있다. 이는 네트워크 보안과 애플리케이션 수준 보안을 함께 강화하는 효과적인 방법이다.
이 기능은 금융 서비스, 의료, 정부 프로젝트 등 높은 보안과 규제 준수 요구사항을 가진 환경에서 DynamoDB를 사용할 때 특히 유용하다. 또한, 하이브리드 클라우드 아키텍처에서 온프레미스 시스템이 AWS Direct Connect를 통해 VPC에 연결된 경우, DynamoDB VPC 엔드포인트를 활용하면 완전히 사설 네트워크 경로를 통해 데이터베이스에 접근할 수 있다.
7.3. 암호화
7.3. 암호화
아마존 DynamoDB는 데이터 보호를 위해 여러 계층에서 암호화를 제공한다. 기본적으로 DynamoDB 테이블에 저장된 모든 데이터는 암호화된다. 이 서버 측 암호화는 AWS Key Management Service에서 관리하는 기본 키를 사용하여 투명하게 수행되며, 사용자는 암호화 활성화 여부를 선택할 수 있다.
사용자는 AWS KMS를 통해 자체 고객 관리형 키를 생성하고 관리하여 암호화에 사용할 키를 직접 제어할 수도 있다. 이는 더욱 세분화된 보안 정책과 규정 준수 요구 사항을 충족하는 데 도움이 된다. 암호화는 테이블 데이터뿐만 아니라 테이블에 대한 글로벌 보조 인덱스 및 백업에도 적용된다.
DynamoDB의 암호화는 데이터를 저장할 때(저장 데이터 암호화)와 전송 중일 때(전송 계층 보안) 모두에 적용된다. AWS 관리형 키 또는 고객 관리형 키를 사용한 서버 측 암호화는 테이블 생성 시 또는 기존 테이블에 대해 활성화할 수 있다. 이 과정에서 성능 저하는 발생하지 않으며, 암호화된 데이터에 대한 모든 읽기 및 쓰기 작업은 투명하게 처리된다.
8. 모니터링 및 백업
8. 모니터링 및 백업
8.1. Amazon CloudWatch 지표
8.1. Amazon CloudWatch 지표
DynamoDB는 운영 상태를 모니터링하고 성능을 최적화하기 위해 Amazon CloudWatch와 긴밀하게 통합된다. CloudWatch는 DynamoDB 테이블에 대한 다양한 지표를 자동으로 수집하여 제공하며, 이를 통해 사용자는 데이터베이스의 성능과 용량 사용량을 실시간으로 파악할 수 있다. 주요 지표로는 읽기 및 쓰기 용량 단위의 소비량, 요청 지연 시간, 시스템 오류 수, 사용자 오류 수, 스로틀링 이벤트 등이 포함된다. 이러한 지표는 AWS Management Console의 CloudWatch 대시보드에서 시각적으로 확인하거나, API를 통해 프로그래밍 방식으로 접근할 수 있다.
사용자는 CloudWatch 지표를 기반으로 알람을 설정하여 특정 임계값을 초과할 때 알림을 받거나 자동화된 조치를 트리거할 수 있다. 예를 들어, 프로비저닝된 용량 모드에서 지속적으로 읽기 용량 단위를 초과하는 경우, 또는 온디맨드 모드에서 비정상적으로 높은 비용이 발생하는 패턴을 감지하는 데 유용하게 활용된다. 또한, 지표 수학 기능을 사용하여 여러 지표를 결합하거나 사용자 정의 지표를 생성하여 더 복잡한 모니터링 시나리오를 구성할 수도 있다.
CloudWatch를 통한 모니터링은 DynamoDB Accelerator와 같은 관련 서비스의 성능 추적이나, 글로벌 테이블의 복제 지연 시간 확인과 같은 고급 사용 사례에도 적용된다. 이러한 포괄적인 모니터링 기능은 애플리케이션의 가용성과 성능을 유지하면서, 필요에 따라 용량을 조정하거나 애플리케이션 로직을 최적화하는 데 중요한 근거를 제공한다.
8.2. PITR (특정 시점으로 복구)
8.2. PITR (특정 시점으로 복구)
PITR(특정 시점으로 복구)는 아마존 DynamoDB가 제공하는 자동화된 백업 및 복구 기능이다. 이 기능을 활성화하면 DynamoDB는 지난 35일 동안의 테이블 데이터에 대한 지속적인 백업을 생성한다. 이를 통해 사용자는 최대 1초 단위의 정밀도로 35일 이내의 특정 시점으로 테이블을 복원할 수 있다. 이는 운영상의 실수나 애플리케이션 결함으로 인한 데이터 손상을 신속하게 복구해야 하는 상황에서 매우 유용하다.
PITR 기능은 관리 콘솔, AWS CLI 또는 AWS SDK를 통해 간단히 활성화하거나 비활성화할 수 있다. 활성화되면 별도의 수동 작업 없이도 백그라운드에서 자동으로 증분 백업이 수행된다. 복원 작업을 수행하면 원본 테이블과는 별개의 새로운 테이블이 생성되며, 지정한 특정 시점(예: 데이터가 손상되기 5분 전)의 데이터 상태를 가지게 된다. 복원된 새 테이블의 이름, 암호화 설정, 용량 모드 등은 원본과 독립적으로 구성할 수 있다.
이 기능은 특히 규정 준수 요구사항이 엄격한 금융 서비스나 사용자 데이터를 처리하는 애플리케이션에서 중요한 역할을 한다. 데이터 손실 없이 최대 35일간의 복구 기간을 보장함으로써 비즈니스 연속성을 강화한다. PITR은 Amazon CloudWatch와 같은 모니터링 도구와 연동되어 백업 상태를 추적할 수 있으며, 수동 스냅샷 백업 기능과 함께 DynamoDB의 포괄적인 데이터 보호 체계를 구성한다.
8.3. 내보내기 기능
8.3. 내보내기 기능
아마존 DynamoDB의 내보내기 기능은 테이블 데이터를 다른 아마존 웹 서비스 서비스로 안전하게 추출하여 분석, 백업 또는 마이그레이션에 활용할 수 있게 한다. 이 기능을 사용하면 테이블의 전체 데이터나 특정 시점의 데이터를 아마존 S3 버킷으로 내보낼 수 있으며, 내보내기 작업 중에도 원본 테이블의 성능과 가용성에 영향을 주지 않는다.
내보내기 작업은 AWS Management Console, AWS CLI 또는 AWS SDK를 통해 시작할 수 있다. 사용자는 내보내기할 DynamoDB 테이블과 데이터를 저장할 대상 S3 버킷을 지정하면 된다. 내보내기된 데이터는 Apache Parquet 또는 JSON 형식으로 저장되며, 특히 Parquet 형식은 컬럼 기반 저장 방식으로 데이터 웨어하우스 분석 시 효율적이다.
이렇게 S3로 내보내진 데이터는 아마존 Athena를 사용해 직접 SQL 쿼리를 실행하거나, 아마존 EMR을 통해 빅데이터 처리를 하거나, 아마존 SageMaker에서 머신러닝 모델 학습에 사용하는 등 다양한 분석 워크플로우의 출발점이 될 수 있다. 또한, 장기 보관을 위한 백업이나 다른 데이터베이스로의 데이터 마이그레이션을 위한 중간 단계로도 유용하게 쓰인다.
내보내기 기능은 PITR (특정 시점으로 복구)이 활성화된 테이블에 대해 최근 35일 내의 특정 시점으로 데이터를 내보내는 옵션도 제공한다. 이를 통해 실수로 삭제되거나 손상된 데이터를 과거의 정상 상태로 복원하는 작업을 지원하며, 데이터 관리의 유연성과 안정성을 크게 향상시킨다.
9. 사용 사례
9. 사용 사례
9.1. 게임 플레이어 데이터
9.1. 게임 플레이어 데이터
아마존 DynamoDB는 온라인 게임에서 플레이어의 프로필, 인벤토리, 진행 상태, 세션 데이터와 같은 실시간 게임 데이터를 저장하고 관리하는 데 적합한 데이터베이스이다. 게임 서비스는 예측 불가능한 트래픽 패턴을 보이는 경우가 많으며, 특히 신규 콘텐츠 출시나 이벤트 시에는 급격한 접속자 증가가 발생할 수 있다. DynamoDB의 핵심 장점인 자동 확장성과 짧은 지연 시간은 이러한 변동성이 큰 부하 하에서도 일관된 성능을 제공하여 플레이어 경험을 유지하는 데 기여한다.
게임 내 플레이어 데이터는 일반적으로 키-값 저장소 모델에 잘 맞으며, 각 플레이어를 고유하게 식별하는 플레이어 ID를 기본 키로 사용하여 해당 플레이어의 모든 속성 정보를 하나의 항목으로 효율적으로 저장할 수 있다. 예를 들어, 플레이어의 레벨, 경험치, 아이템 목록, 친구 목록 등이 문서 형태로 저장된다. 또한 보조 인덱스를 활용하면 기본 키 외의 다른 속성(예: 길드 명, 레벨 범위)을 기준으로 빠르게 데이터를 조회할 수 있어, 리더보드 생성이나 특정 조건을 가진 플레이어 그룹 검색과 같은 기능을 구현하는 데 유용하다.
DynamoDB의 글로벌 테이블 기능은 전 세계에 분산된 플레이어를 위한 멀티플레이어 게임에 중요한 이점을 제공한다. 이 기능을 사용하면 여러 AWS 리전에 데이터를 자동으로 복제하여, 플레이어가 물리적으로 가장 가까운 리전의 데이터에 접근할 수 있게 한다. 이를 통해 지리적 위치에 따른 지연 시간을 최소화하고, 한 리전에 장애가 발생하더라도 다른 리전에서 게임 서비스를 계속할 수 있는 고가용성을 확보할 수 있다.
9.2. 쇼핑 카트
9.2. 쇼핑 카트
아마존 DynamoDB는 전자상거래 웹사이트나 애플리케이션에서 쇼핑 카트 기능을 구현하는 데 널리 사용되는 데이터베이스이다. 쇼핑 카트 데이터는 사용자 세션 동안 빠르게 생성, 읽기, 업데이트, 삭제 작업이 빈번하게 발생하며, 사용자별로 독립적인 데이터 구조를 가진다. DynamoDB의 키-값 저장소 모델은 각 사용자의 카트를 고유한 키로 쉽게 식별하고, 문서 데이터 모델을 통해 카트 내 상품 목록, 수량, 옵션 등 유연한 데이터를 JSON 형식으로 저장할 수 있어 이에 적합하다.
이 사용 사례에서 DynamoDB의 자동 확장성은 예측하기 어려운 트래픽 패턴, 예를 들어 특정 시간대의 할인 이벤트나 홍수 단계 트래픽에 대응하는 데 중요한 장점을 제공한다. 서버리스 아키텍처인 온디맨드 용량 모드를 사용하면 사용자 활동에 따라 실시간으로 용량이 조절되어, 카트 작업이 급증할 때도 성능을 유지하면서 비용을 최적화할 수 있다. 또한 내구성과 가용성을 기본으로 보장하여 카트 데이터의 손실 없이 안정적인 서비스를 제공한다.
쇼핑 카트 구현을 위해 일반적으로 사용자 ID를 기본 키로 하여 테이블을 설계한다. 이렇게 하면 특정 사용자의 카트 정보를 매우 짧은 지연 시간으로 조회할 수 있다. 카트 항목 추가나 수량 변경과 같은 작업은 단일 항목에 대한 쓰기 작업으로 효율적으로 처리된다. 또한 사용자가 장바구니를 오랜 기간 방치한 후 다시 방문하는 경우를 대비해 TTL(Time To Live) 속성을 설정해 오래된 카트 데이터를 자동으로 삭제하는 정리 작업에도 활용할 수 있다.
9.3. IoT 디바이스 상태
9.3. IoT 디바이스 상태
아마존 DynamoDB는 사물인터넷 디바이스에서 생성되는 대규모 상태 데이터를 처리하는 데 적합한 데이터베이스이다. 수천, 수백만 대의 IoT 디바이스가 센서 데이터, 위치 정보, 작동 상태 등을 지속적으로 전송할 때, 이는 매우 빠르게 변화하고 폭발적으로 증가하는 데이터 스트림을 형성한다. DynamoDB는 이러한 시계열적 특성을 가진 데이터를 실시간으로 저장하고 조회할 수 있는 높은 처리량과 낮은 지연 시간을 제공한다.
DynamoDB의 자동 확장 기능은 예측하기 어려운 IoT 데이터 유입 패턴에 효과적으로 대응한다. 디바이스 사용이 집중되는 시간대에 트래픽이 급증하더라도 서비스는 용량을 자동으로 조정하여 성능을 유지한다. 또한 온디맨드 용량 모드를 사용하면 트래픽 패턴을 미리 예측할 필요 없이 실제 발생한 읽기 및 쓰기 요청에 대해서만 비용을 지불할 수 있어 운영 부담을 줄인다.
개별 디바이스의 상태를 관리할 때는 디바이스 ID를 기본 키로 사용하는 것이 일반적이다. 이를 통해 특정 디바이스의 최신 상태를 빠르게 조회하거나 해당 디바이스의 과거 상태 기록을 시간 범위를 지정하여 효율적으로 쿼리할 수 있다. DynamoDB의 TTL 기능을 활용하면 일정 시간이 지난 오래된 상태 데이터를 자동으로 삭제하여 스토리지 비용을 관리할 수 있다.
글로벌 테이블 기능은 전 세계에 분산된 IoT 디바이스와 애플리케이션에 유용하다. 여러 AWS 리전에 데이터를 복제하여 디바이스와 지리적으로 가까운 엔드포인트에서 데이터에 접근할 수 있게 함으로써 지연 시간을 최소화하고 가용성을 높인다. 이는 글로벌 규모의 스마트 홈 시스템이나 산업용 IoT 플랫폼을 구축할 때 중요한 이점이 된다.
10. 장단점
10. 장단점
아마존 DynamoDB는 완전 관리형 NoSQL 데이터베이스로서, 특히 확장성과 성능에 중점을 둔 서비스이다. 주요 장점으로는 서버리스 아키텍처를 기반으로 한 탁월한 확장성이 있다. 사용자는 용량 계획이나 서버 관리 없이도 애플리케이션의 트래픽 증가에 따라 데이터베이스가 자동으로 확장되도록 할 수 있다. 또한 단일 자릿수 밀리초 수준의 짧은 지연 시간을 보장하여 실시간 애플리케이션에 적합하며, 기본적으로 제공되는 다중 리전 복제를 통한 고가용성과 내구성도 강점이다. 사용 편의성 측면에서도 완전 관리형 서비스이므로 운영 부담이 크게 줄어든다.
반면, DynamoDB에는 몇 가지 단점이나 고려 사항도 존재한다. 첫째, 쿼리 기능이 관계형 데이터베이스 관리 시스템에 비해 제한적이다. 복잡한 조인이나 임의의 조건을 통한 검색이 어려우며, 효율적인 데이터 접근을 위해서는 데이터 모델링 단계에서 테이블 설계와 보조 인덱스 사용을 신중하게 계획해야 한다. 둘째, 비용 구조가 사용 패턴에 따라 예측하기 어려울 수 있다. 읽기/쓰기 용량 단위나 저장 공간, 데이터 전송량 등 다양한 요소에 따라 요금이 부과되며, 특히 예측 불가능한 트래픽 패턴에서는 비용 관리가 복잡해질 수 있다.
또 다른 제약점은 락 기능의 부재이다. 특정 항목에 대한 배타적 잠금을 기본적으로 제공하지 않아, 동시에 같은 데이터를 수정하려는 시나리오에서 개발자가 낙관적 동시성 제어 등의 메커니즘을 직접 구현해야 할 수 있다. 마지막으로, 이 서비스는 아마존 웹 서비스 클라우드 플랫폼에 완전히 종속되어 있다. 따라서 다중 클라우드 또는 하이브리드 클라우드 전략을 추구하는 기업이나 특정 지역의 온프레미스 환경에서의 사용은 불가능하다는 점도 고려해야 한다.
