1. NoSQL vs SQL

데이터베이스는 크게 SQL(관계형) 과 NoSQL(비관계형) 두 가지로 나뉩니다. MySQL, PostgreSQL 같은 전통적인 데이터베이스가 SQL이고, DynamoDB, MongoDB 같은 것이 NoSQL입니다. 어떤 것이 더 좋다기보다는 용도에 따라 선택하는 것이 중요합니다.

전통적 아키텍처 (RDBMS)

수직 스케일링이란 서버 한 대의 CPU, RAM을 업그레이드하는 것이고, 수평 스케일링은 서버 여러 대를 추가하는 것입니다.

NoSQL 특징

쉽게 말해: SQL은 엑셀 시트처럼 정해진 열(컬럼)이 있고, 여러 시트를 JOIN으로 연결합니다. NoSQL은 JSON처럼 유연한 구조로, 필요한 데이터를 한 곳에 모아둡니다.

💡 NoSQL vs SQL은 옳고 그름이 아님 → 데이터 모델링 방식이 다를 뿐

2. DynamoDB 개요

DynamoDB는 AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스입니다. "완전 관리형"이란 서버 설치, 패치, 백업 등을 AWS가 알아서 해준다는 의미입니다. 개발자는 데이터 저장과 조회에만 집중하면 됩니다.

특징

Multi-AZ란 여러 가용 영역(데이터센터)에 데이터를 복제해서 하나가 장애가 나도 서비스가 계속되는 것입니다. IA(Infrequent Access) 는 자주 접근하지 않는 데이터를 저렴하게 저장하는 옵션입니다.

기본 구조

DynamoDB
    │
    └─ Table
           │
           ├─ Item (행) - 최대 400KB
           │      │
           │      ├─ Attribute (열)
           │      ├─ Attribute
           │      └─ Attribute
           │
           └─ Item
                  └─ ...

쉽게 이해하기: Table은 엑셀 파일, Item은 한 행(row), Attribute는 각 열(column)의 값입니다. 단, DynamoDB는 각 Item마다 다른 Attribute를 가질 수 있어서 유연합니다.

데이터 타입

Scalar는 단일 값(문자열, 숫자 등), Document는 중첩 구조(JSON의 배열이나 객체), Set은 중복 없는 값들의 집합입니다.

3. Primary Key

Primary Key는 테이블에서 각 아이템을 고유하게 식별하는 키입니다. DynamoDB에서는 두 가지 방식으로 Primary Key를 구성할 수 있습니다.

Option 1: Partition Key (HASH)

┌────────────────────────────────────────────────────┐
│  User_ID (PK)  │  First_Name  │  Last_Name  │ Age │
├────────────────┼──────────────┼─────────────┼─────┤
│  7791a3d6-...  │     John     │   William   │  46 │
│  873e0634-...  │    Katie     │    Lucas    │  31 │
│  a80f73a1-...  │    Oliver    │     -       │  24 │
└────────────────────────────────────────────────────┘

• Partition Key는 고유해야 함
• 높은 카디널리티 선택 (데이터 분산)

카디널리티(Cardinality) 란 해당 키가 가질 수 있는 고유한 값의 개수입니다. 예: 성별(남/여)은 카디널리티가 낮고, 주민등록번호는 카디널리티가 높습니다. 카디널리티가 높을수록 데이터가 골고루 분산됩니다.

Option 2: Partition Key + Sort Key (HASH + RANGE)

┌─────────────────────────────────────────────────────────────┐
│  User_ID (PK)  │  Game_ID (SK)  │  Score  │    Result      │
├────────────────┼────────────────┼─────────┼────────────────┤
│  7791a3d6-...  │      4421      │   92    │      Win       │
│  873e0634-...  │      4521      │   77    │      Win       │
│  873e0634-...  │      1894      │   14    │     Lose       │
└─────────────────────────────────────────────────────────────┘
                       ↑
              같은 PK, 다른 SK (조합이 고유)

• 조합이 고유해야 함
• 같은 Partition Key → 데이터 그룹화

실제 예시: 게임 앱에서 한 유저(User_ID)가 여러 게임(Game_ID)을 플레이한 기록을 저장할 때 사용합니다. User_ID로 그룹화하고, Game_ID로 정렬하면 "특정 유저의 모든 게임 기록"을 효율적으로 조회할 수 있습니다.

Partition Key 선택 가이드

영화 DB에서 최적의 Partition Key는?
 
❌ movie_language → 값이 적음, 영어에 편중
❌ producer_name → 카디널리티 낮음
❌ leader_actor_name → 카디널리티 중간
✅ movie_id → 가장 높은 카디널리티!

4. Read/Write Capacity Modes

DynamoDB는 읽기/쓰기 용량을 관리하는 두 가지 모드를 제공합니다. 얼마나 많은 요청을 처리할 수 있는지를 결정하는 중요한 설정입니다.

모드 비교

Provisioned: 미리 "초당 100번 읽기, 50번 쓰기"처럼 용량을 예약합니다. 예측 가능한 트래픽에 적합하고 비용이 저렴합니다.

On-Demand: 사용한 만큼만 과금됩니다. 갑자기 트래픽이 폭주해도 자동으로 처리하지만, 단가가 비쌉니다. 신규 서비스나 트래픽 예측이 어려울 때 적합합니다.

💡 모드 전환: 24시간에 한 번

5. Write Capacity Units (WCU)

WCU는 DynamoDB에서 쓰기 작업의 처리량을 측정하는 단위입니다. Provisioned 모드에서 미리 할당해야 하며, 시험에서 계산 문제가 자주 출제됩니다.

정의

• 1 WCU = 1KB 이하 아이템 1개/초 쓰기
• 1KB 초과 시 더 많은 WCU 소비

핵심 공식: 필요한 WCU = 초당 쓰기 수 × (아이템 크기 / 1KB) (크기는 올림 처리)

계산 예시

예시 1: 10개/초, 아이템 크기 2KB

10 × (2KB / 1KB) = 20 WCU

예시 2: 6개/초, 아이템 크기 4.5KB

6 × (5KB / 1KB) = 30 WCU  ← 4.5 → 5로 올림

예시 3: 120개/분, 아이템 크기 2KB

(120/60) × (2KB / 1KB) = 4 WCU

계산 팁: 항상 1) 초당 횟수로 변환 2) 아이템 크기를 1KB 단위로 올림 3) 두 값을 곱하면 됩니다.

6. Read Capacity Units (RCU)

RCU는 읽기 작업의 처리량 단위입니다. WCU와 다르게 읽기 일관성(Consistency) 에 따라 계산이 달라지므로 주의해야 합니다.

정의

• 1 RCU = 4KB 이하 아이템
  • Strongly Consistent: 1개/초
  • Eventually Consistent: 2개/초
• 4KB 초과 시 더 많은 RCU 소비

Strongly vs Eventually Consistent Read

쉽게 이해하기: DynamoDB는 데이터를 여러 서버에 복제합니다. 데이터를 쓰면 모든 서버에 복제되는 데 약간의 시간이 걸립니다.

• Eventually Consistent: 복제가 완료되지 않은 서버에서 읽을 수도 있음 (약간 오래된 데이터 가능, 하지만 저렴)
• Strongly Consistent: 반드시 최신 데이터를 읽음 (비용 2배)

Application → DynamoDB
                 │
           ┌─────┼─────┐
           │     │     │
        Server1 Server2 Server3
           │           │
         write    ────→ replication (지연 가능)
           │           │
         read ←────    read (Eventually: 오래된 데이터 가능)

계산 예시

예시 1: 10 Strongly Consistent/초, 4KB

10 × (4KB / 4KB) = 10 RCU

예시 2: 16 Eventually Consistent/초, 12KB

(16/2) × (12KB / 4KB) = 24 RCU

예시 3: 10 Strongly Consistent/초, 6KB

10 × (8KB / 4KB) = 20 RCU  ← 6 → 8로 올림

7. Partitions & Throttling

DynamoDB는 데이터를 파티션(Partition) 이라는 저장 단위로 나눠서 관리합니다. 파티션을 이해하면 성능 문제(Throttling)를 예방할 수 있습니다.

Partition 내부 구조

Application
    │
    ▼
Hash Function
    │
    ├─→ Partition 1 (ID_13, ID_27, ...)
    ├─→ Partition 2 (ID_45, ID_89, ...)
    └─→ Partition 3 (...)

• Partition Key → 해시 함수 → 파티션 결정
• WCU/RCU는 파티션에 균등 분배

중요: 100 WCU를 할당하고 파티션이 4개면, 각 파티션은 25 WCU만 사용 가능합니다. 특정 파티션에 요청이 몰리면 문제가 발생합니다.

Throttling 원인

Throttling이란 할당된 용량을 초과해서 요청이 거부되는 현상입니다.

Throttling 해결책

Exponential Backoff: 요청 실패 시 1초, 2초, 4초, 8초... 처럼 대기 시간을 점점 늘려가며 재시도하는 방식입니다. AWS SDK에 기본 포함되어 있어 별도 구현이 필요 없습니다.

8. DynamoDB API - 쓰기

DynamoDB에서 데이터를 쓰는 주요 API들입니다.

PutItem

• 새 아이템 생성 또는 전체 교체 (같은 PK)
• WCU 소비

주의: 같은 Primary Key로 PutItem을 호출하면 기존 아이템이 완전히 교체됩니다. 일부 속성만 수정하려면 UpdateItem을 사용하세요.

UpdateItem

• 기존 아이템 속성 편집 또는 새 아이템 추가
• Atomic Counter: 숫자 속성 무조건 증가

Atomic Counter 예시: 조회수를 1 증가시킬 때, 여러 사용자가 동시에 호출해도 모든 증가가 정확히 반영됩니다. 동시성 문제를 걱정할 필요 없습니다.

Conditional Writes

• 조건 만족 시에만 쓰기/수정/삭제
• 동시 접근 제어에 유용
• 성능 영향 없음

조건 표현식:

attribute_exists / attribute_not_exists
attribute_type
contains / begins_with (문자열)
IN, between
size (문자열 길이)

9. DynamoDB API - 읽기

DynamoDB에서 데이터를 읽는 세 가지 방법입니다. 효율성과 비용이 크게 다르므로 적절한 방법을 선택해야 합니다.

GetItem

• Primary Key로 읽기 (HASH 또는 HASH+RANGE)
• Eventually Consistent (기본), Strongly Consistent (옵션)
• ProjectionExpression: 특정 속성만 조회

가장 효율적인 읽기: 정확한 Primary Key를 알 때 사용합니다. 단일 아이템을 직접 가져오므로 가장 빠르고 저렴합니다.

Query

Query 예시: "user_id가 123인 사용자의 2024년 1월 이후 주문들"처럼 특정 파티션 내에서 조건에 맞는 아이템들을 효율적으로 가져옵니다.

Scan

• 전체 테이블 스캔 → 비효율적
• RCU 많이 소비
• 페이지네이션 사용 (최대 1MB)
• Parallel Scan: 빠르지만 RCU 더 소비

💡 Query > Scan (가능하면 Query 사용)

왜 Scan이 비효율적인가?: Scan은 테이블의 모든 아이템을 읽은 후 조건에 맞는 것만 반환합니다. 100만 개 중 10개만 필요해도 100만 개를 모두 읽어야 하므로 RCU를 많이 소비합니다.

10. DynamoDB API - 삭제

데이터를 삭제하는 두 가지 방법입니다.

DeleteItem

• 개별 아이템 삭제
• Conditional Delete 가능

DeleteTable

• 테이블 전체 삭제
• 모든 아이템 DeleteItem보다 훨씬 빠름

팁: 테이블의 모든 데이터를 지우고 싶다면, 아이템을 하나씩 삭제하지 말고 테이블 자체를 삭제 후 재생성하세요. 훨씬 빠르고 비용도 절약됩니다.

11. Batch Operations

여러 아이템을 한 번에 처리하는 API입니다. 네트워크 왕복 횟수를 줄여 성능을 향상시킵니다.

BatchWriteItem

BatchGetItem

UnprocessedItems/UnprocessedKeys: Batch 작업 중 일부가 실패하면 이 필드에 실패한 항목들이 담겨 반환됩니다. 이 항목들을 Exponential Backoff로 재시도해야 합니다.

12. PartiQL

DynamoDB의 독자적인 API 대신 익숙한 SQL 문법으로 데이터를 조작할 수 있게 해주는 쿼리 언어입니다.

개요

• SQL 호환 쿼리 언어
• SELECT, INSERT, UPDATE, DELETE 지원
• 여러 테이블 쿼리 가능
• Batch 작업 지원

사용 환경

• AWS Console
• NoSQL Workbench
• DynamoDB APIs
• AWS CLI / SDK

SELECT * FROM Users WHERE User_ID = '7791a3d6-...'

주의: PartiQL은 내부적으로 DynamoDB API로 변환됩니다. SQL처럼 보이지만 JOIN은 지원되지 않으며, DynamoDB의 제약(Primary Key 필요 등)은 그대로 적용됩니다.

13. Local Secondary Index (LSI)

인덱스는 다른 방식으로 데이터를 조회할 수 있게 해주는 기능입니다. LSI는 같은 Partition Key 내에서 다른 속성으로 정렬해서 조회하고 싶을 때 사용합니다.

개요

• 대체 Sort Key (Partition Key는 동일)
• 테이블당 최대 5개
• 테이블 생성 시에만 정의 가능

┌─────────────────────────────────────────────────────────────────────────┐
│  User_ID (PK)  │  Game_ID (SK)  │  Score  │  Game_TS (LSI)            │
├────────────────┼────────────────┼─────────┼───────────────────────────┤
│  7791a3d6-...  │      4421      │   92    │  2021-03-15T17:43:08      │
│  873e0634-...  │      1894      │   77    │  2021-02-11T04:11:31      │
└─────────────────────────────────────────────────────────────────────────┘
                                                    ↑
                                             Alternative Sort Key

실제 예시: 게임 기록 테이블에서 기본적으로 Game_ID로 정렬되어 있지만, "특정 유저의 게임 기록을 시간순으로 보고 싶다"면 Game_TS를 Sort Key로 하는 LSI를 만들면 됩니다.

Attribute Projections

인덱스에 어떤 속성을 포함할지 결정합니다. 포함된 속성만 인덱스에서 바로 조회 가능합니다.

• KEYS_ONLY: 키만
• INCLUDE: 지정 속성
• ALL: 모든 속성

14. Global Secondary Index (GSI)

GSI는 LSI보다 강력합니다. 완전히 다른 Partition Key로 데이터를 조회할 수 있습니다. 마치 같은 데이터를 다른 방식으로 정리한 별도의 테이블처럼 동작합니다.

개요

• 대체 Primary Key (HASH 또는 HASH+RANGE)
• 별도 RCU/WCU 프로비저닝 필요
• 테이블 생성 후에도 추가/수정 가능

TABLE (User_ID로 쿼리)           GSI (Game_ID로 쿼리)
┌────────────────────────┐      ┌────────────────────────┐
│ User_ID │ Game_ID │... │      │ Game_ID │ Game_TS │... │
├─────────┼─────────┼────┤      ├─────────┼─────────┼────┤
│ 7791... │  4421   │    │      │  4421   │ 2021... │    │
│ 873e... │  1894   │    │      │  1894   │ 2021... │    │
└────────────────────────┘      └────────────────────────┘

실제 예시: 주문 테이블이 Order_ID로 조회되도록 설계되어 있는데, "특정 상품(Product_ID)의 모든 주문"을 조회하고 싶다면? Product_ID를 Partition Key로 하는 GSI를 만들면 됩니다.

GSI Throttling ⚠️

• GSI에서 Throttle 발생 시 → 메인 테이블도 Throttle!
• GSI Partition Key 신중히 선택
• GSI WCU 적절히 할당

LSI vs GSI 비교

시험 핵심: LSI는 테이블 생성 시에만 만들 수 있고, GSI는 언제든 추가 가능합니다. GSI가 Throttle되면 메인 테이블 쓰기도 실패할 수 있으니 주의하세요!

15. Optimistic Locking

여러 클라이언트가 동시에 같은 데이터를 수정하려 할 때 데이터 충돌을 방지하는 기법입니다. "낙관적"이라는 이름은 "충돌이 거의 없을 것"이라고 가정하고, 실제 충돌 시에만 처리하기 때문입니다.

개념

• Conditional Writes를 이용한 낙관적 잠금
• 버전 번호로 충돌 감지

DynamoDB Table
User_ID: 7791...
Name: Michael
Version: 1
 
Client 1: UPDATE Name = 'John' WHERE Version = 1 ✅ → Version = 2
Client 2: UPDATE Name = 'Lisa' WHERE Version = 1 ❌ (Version이 이미 2)

작동 원리: 각 아이템에 version 속성을 추가합니다. 수정 시 "현재 version이 내가 읽은 값과 같을 때만 수정"하고, 성공하면 version을 1 증가시킵니다. 다른 클라이언트가 먼저 수정했다면 version이 달라져서 실패합니다.

16. DynamoDB Accelerator (DAX)

DAX는 DynamoDB 전용 캐시 서비스입니다. 자주 읽는 데이터를 메모리에 저장해두어 응답 속도를 밀리초에서 마이크로초로 단축합니다.

개요

• 완전 관리형 인메모리 캐시
• 마이크로초 지연 (캐시 히트 시)
• DynamoDB API 호환 (코드 수정 불필요)

캐시란?: 자주 사용하는 데이터를 빠른 저장소(메모리)에 임시 보관하는 것입니다. 같은 데이터 요청 시 DynamoDB까지 가지 않고 캐시에서 바로 반환합니다.

특징

DAX vs ElastiCache

Application
    │
    ├─→ DAX → DynamoDB
    │   (개별 객체 캐시, Query/Scan 캐시)
    │
    └─→ ElastiCache
        (집계 결과 저장)

DAX vs ElastiCache 선택: DynamoDB 데이터를 그대로 캐싱하려면 DAX, 애플리케이션에서 계산한 결과(예: 통계, 랭킹)를 저장하려면 ElastiCache를 사용합니다.

17. DynamoDB Streams

DynamoDB Streams는 테이블의 변경 사항을 실시간으로 캡처하는 기능입니다. 데이터가 추가/수정/삭제될 때마다 이벤트가 발생하고, 이를 다른 서비스(Lambda 등)에서 처리할 수 있습니다.

개요

• 테이블의 아이템 수준 변경 (생성/수정/삭제) 스트림
• 순서 보장

아키텍처

Table → DynamoDB Streams → Kinesis Data Streams → Lambda/KCL/Firehose
        (create/update/delete)        │
                                      ├─→ OpenSearch (인덱싱)
                                      ├─→ SNS (알림)
                                      ├─→ DDB Table (파생 테이블)
                                      ├─→ Redshift (분석)
                                      └─→ S3 (아카이브)

실제 활용 예시: 주문 테이블에 새 주문이 들어오면 → Stream으로 Lambda 트리거 → 재고 테이블 업데이트 + 알림 발송. 이런 이벤트 기반 아키텍처를 쉽게 구현할 수 있습니다.

Stream Record 유형

특징

• 보존 기간: 24시간
• Shard 자동 관리 (프로비저닝 불필요)
• 활성화 전 데이터는 소급 적용 안 됨

Lambda 연동

• Event Source Mapping 사용
• 동기 호출
• Lambda에 적절한 권한 필요

18. Time To Live (TTL)

TTL은 아이템에 만료 시간을 설정하여 자동으로 삭제되게 하는 기능입니다. 세션 데이터나 임시 데이터 관리에 유용합니다.

개요

• 만료 타임스탬프 후 자동 삭제
• WCU 소비 없음 (무료)

비용 절감 포인트: TTL 삭제는 WCU를 소비하지 않습니다. 오래된 데이터를 직접 DeleteItem으로 지우면 WCU 비용이 발생하지만, TTL을 사용하면 무료입니다.

특징

주의: TTL로 설정한 시간이 지나도 즉시 삭제되지 않습니다. AWS가 백그라운드에서 처리하므로 며칠 내에 삭제됩니다. 삭제 전까지는 조회될 수 있으니 필터링이 필요합니다.

사용 사례

• 현재 데이터만 유지 (저장 비용 절감)
• 규정 준수 (데이터 보존 기간)
• 세션 데이터 관리

19. DynamoDB Transactions

Transaction은 여러 작업을 하나의 단위로 묶어 모두 성공하거나 모두 실패하게 만드는 기능입니다. 은행 송금처럼 "A 계좌에서 출금 + B 계좌에 입금"이 반드시 함께 처리되어야 하는 경우에 필수입니다.

개요

• 여러 테이블의 여러 아이템에 대한 원자적 작업
• ACID 보장

ACID란?: Atomicity(원자성: 전부 성공 또는 전부 실패), Consistency(일관성), Isolation(격리성), Durability(지속성). 데이터베이스 트랜잭션의 4가지 핵심 속성입니다.

특징

비용 2배인 이유: Transaction은 내부적으로 2단계로 처리됩니다. 1) Prepare: 모든 조건 확인 2) Commit: 실제 적용. 이 과정에서 용량을 2배 소비합니다.

작업

용량 계산 (시험 중요!)

예시 1: 3 Transactional 쓰기/초, 5KB

3 × (5KB / 1KB) × 2 = 30 WCU

예시 2: 5 Transactional 읽기/초, 5KB

5 × (8KB / 4KB) × 2 = 20 RCU  ← 5 → 8로 올림

사용 사례

• 금융 거래
• 주문 관리
• 멀티플레이어 게임

20. Session State Cache

웹 애플리케이션에서 사용자 세션 정보(로그인 상태, 장바구니 등)를 저장하는 방법입니다. DynamoDB는 서버리스 특성 덕분에 세션 저장소로 자주 사용됩니다.

DynamoDB vs 기타

💡 DynamoDB: 서버리스 Key/Value 저장소로 세션 상태 저장에 적합

21. Write Sharding

특정 Partition Key에 쓰기가 집중되는 Hot Partition 문제를 해결하는 기법입니다. Partition Key에 임의의 접미사를 붙여 데이터를 분산시킵니다.

문제: Hot Partition

투표 앱에서 Candidate_ID를 PK로 사용:
- Candidate_A → Partition 1 (과부하!)
- Candidate_B → Partition 2 (과부하!)

해결: Suffix 추가

┌──────────────────────────────────────────┐
│  Candidate_ID + Suffix  │  Vote_ts  │... │
├─────────────────────────┼───────────┼────┤
│  Candidate_A-11         │ 1631...   │    │
│  Candidate_A-20         │ 1631...   │    │
│  Candidate_B-17         │ 1631...   │    │
│  Candidate_B-80         │ 1631...   │    │
└──────────────────────────────────────────┘

• Random Suffix: 무작위 숫자
• Calculated Suffix: 계산된 값 (예: 해시)

트레이드오프: Write Sharding을 사용하면 쓰기는 분산되지만, 읽을 때는 모든 접미사(예: Candidate_A-1 ~ Candidate_A-100)를 조회해서 합쳐야 합니다.

22. Write Types 비교

DynamoDB에서 여러 클라이언트가 동시에 같은 데이터를 쓸 때 어떻게 처리되는지 이해해야 합니다.

예시로 이해하기: 조회수가 0인 상태에서 두 사용자가 동시에 조회수를 1 증가시키려 한다면?

• Concurrent: 둘 다 0을 읽고 1로 덮어씀 → 결과 1 (잘못됨)
• Atomic: 각각 +1 적용 → 결과 2 (정확함)
• Conditional: 첫 번째만 성공, 두 번째는 재시도 필요

23. Large Objects 패턴

DynamoDB는 아이템당 최대 400KB만 저장할 수 있습니다. 이미지나 문서 같은 큰 파일은 어떻게 처리할까요?

문제

• DynamoDB 아이템 최대 400KB
• 큰 파일 저장 불가

해결: S3 + DynamoDB

Application → S3 (이미지 업로드)
           → DynamoDB (메타데이터 저장: S3 URL)
 
Application ← DynamoDB (메타데이터 조회)
           ← S3 (이미지 다운로드)

핵심 패턴: 큰 파일은 S3에, 메타데이터(파일명, 크기, S3 URL 등)는 DynamoDB에 저장합니다. 이렇게 하면 DynamoDB의 빠른 검색 기능과 S3의 대용량 저장 기능을 모두 활용할 수 있습니다.

S3 객체 메타데이터 인덱싱

S3 Upload → Lambda → DynamoDB (메타데이터 저장)
                           │
                           └─→ API: 날짜별 검색, 용량 집계, 속성 필터

24. DynamoDB Operations

테이블의 데이터를 정리하거나 복사하는 운영 작업들입니다.

테이블 정리

테이블 복사

25. DynamoDB 보안 & 기능

DynamoDB의 보안 설정과 부가 기능들입니다.

보안

백업

PITR(Point-in-time Recovery): 최근 35일 내 원하는 시점으로 테이블을 복원할 수 있습니다. 실수로 데이터를 삭제해도 복구 가능합니다.

글로벌 기능

Global Tables: 서울, 도쿄, 버지니아 등 여러 리전에 동일한 테이블을 두고 자동으로 동기화합니다. 전 세계 사용자에게 낮은 지연 시간을 제공하고, 한 리전이 장애가 나도 다른 리전에서 서비스를 계속할 수 있습니다.

26. Fine-Grained Access Control

사용자마다 자신의 데이터에만 접근하도록 제한하는 기능입니다. 멀티테넌트 애플리케이션에서 A 사용자가 B 사용자의 데이터를 볼 수 없게 합니다.

개요

• Cognito/Web Identity Federation으로 사용자별 AWS 자격 증명
• IAM 조건으로 DynamoDB API 접근 제한

조건 예시

{
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

→ 사용자는 자신의 데이터만 접근 가능

실제 예시: 모바일 앱에서 사용자가 Cognito로 로그인하면 고유한 ID(sub)를 받습니다. IAM 정책에서 "user_id가 자신의 sub과 같은 아이템만 접근 가능"으로 설정하면, 각 사용자는 자신의 데이터만 볼 수 있습니다.

핵심 요약

시험에서 자주 출제되는 핵심 개념들을 정리합니다.

Capacity 계산 (시험 필수!)

인덱스

캐시

시험 팁: WCU/RCU 계산 문제가 자주 출제됩니다. 항상 1) 초당 횟수 2) 아이템 크기 올림 3) 일관성 모드(Eventually는 /2) 4) Transaction은 x2 를 체크하세요!