고처리량 시계열 스토어를 위한 스케일러블하고 비용 효율적인 액세스 패턴 설계
It looks like only the source citation was included in your message. Could you please provide the text you’d like translated? Once I have the content, I’ll keep the source line unchanged at the top and translate the rest into Korean while preserving the original formatting and technical terms.
Table Schema & Primary Key
| Attribute | Type | Role |
|---|---|---|
deviceId | String | Partition key → 파티션 키 |
timestamp | String (ISO‑8601, e.g., 2025-12-04T12:34:56Z) | Sort key → 정렬 키 |
temperature, humidity, pressure | Number | Payload → 페이로드 |
metadata | String (JSON) | Optional payload → 선택적 페이로드 |
ttl | Number (epoch seconds) | TTL attribute for expiration → 만료를 위한 TTL 속성 |
Why this PK?
왜 이 PK인가?
All readings for a device are stored together, enabling efficient range queries (deviceId = X AND timestamp BETWEEN …). A single‑item query for the latest reading can be performed with ScanIndexForward=false and Limit=1.
디바이스별 모든 측정값이 함께 저장되어 효율적인 범위 쿼리(deviceId = X AND timestamp BETWEEN …)가 가능하다. 최신 측정값을 가져오는 단일 항목 조회는 ScanIndexForward=false와 Limit=1을 사용하여 수행할 수 있다.
Source: …
인덱싱 전략
| 인덱스 | 파티션 키 | 정렬 키 | 사용 사례 |
|---|---|---|---|
| Primary Table | deviceId | timestamp | 디바이스당 포인트 조회 및 범위 쿼리 |
Global Secondary Index (GSI) – DeviceLatestGSI | deviceId | timestamp (내림차순 DESC 로 투영) | 전체 파티션을 스캔하지 않고 최신 데이터를 직접 조회 (Limit=1, ScanIndexForward=false) |
Optional GSI – MetricGSI | metricType (예: "temperature" 상수) | timestamp | 단일 메트릭에 대한 디바이스 간 시간 범위 쿼리 (드물게) |
참고: 기본 테이블만으로도 최신‑읽기 쿼리를 지원합니다; GSI는 동일 deviceId에 대한 동시 “최신” 읽기가 많이 발생해 핫‑파티션이 될 가능성이 있을 때만 선택적으로 사용하면 비용이 추가됩니다. 대부분의 경우 Limit=1을 사용한 기본 테이블만으로 충분합니다.
용량 모드 및 스케일링
| 모드 | 사용 시점 | 구성 |
|---|---|---|
| On‑Demand | 예측할 수 없는 급증, 손쉬운 시작, 용량 관리 불필요. | 자동으로 초당 10 k 쓰기 처리; 요청당 비용 지불. |
| Provisioned + Auto Scaling | 예측 가능한 트래픽, 비용을 제어하고 싶을 때. | 15,000 RCUs와 5,000 WCUs로 시작 (각 쓰기 ≤ 1 KB는 1 WCU 소모). 자동 스케일링 목표 70 % 활용도 설정. |
비용 비교 (대략, US East 1, 2025년 12월):
- On‑Demand 쓰기: 백만 쓰기 요청 단위당 $1.25 → 초당 10 k 쓰기(≈ 일일 2,600만 쓰기) 기준 약 $12.5 k/월.
- Provisioned 5,000 WCUs ≈ 시간당 WCU당 $0.65 → 월 $2.3 k에 자동 스케일링 버퍼 추가.
On‑Demand가 더 간단하고, 트래픽이 안정적이면 Provisioned가 더 저렴할 수 있습니다.
Hot‑Partition 위험 완화
- 균일한
deviceId분포: 디바이스 ID가 무작위인지 확인하세요 (예: UUID 또는 해시). - 몇몇 디바이스가 트래픽을 독점하는 경우: 샤딩을 사용하세요 –
deviceId앞에 무작위 샤드 접미사를 붙입니다 (예:deviceId#shard01). 샤드 개수를 작은 설정 테이블에 저장하고; 애플리케이션이 모든 샤드를 조회해 결과를 병합합니다. 이렇게 하면 파티션 간 쓰기 용량이 분산됩니다.
데이터 보존 (TTL)
숫자 속성 ttl = timestampEpoch + 30 days 를 추가합니다.
이 속성에 DynamoDB TTL을 활성화합니다; DynamoDB는 만료된 항목을 자동으로 삭제합니다(보통 만료 후 48 시간 이내).
- 추가 Lambda가 필요 없으며, 비용을 낮게 유지합니다.
읽기 성능 최적화
- Projection: GSI에 필요한 속성만 유지합니다(예:
temperature,humidity,pressure,timestamp). 이렇게 하면 읽기 크기와 비용이 감소합니다. - Consistent vs. eventual reads: 대부분의 쿼리에는 eventual consistency를 사용합니다(더 저렴하고, 4 KB당 0.5 RCU). 최신 데이터와 같이 신선도가 중요한 경우에는 strongly consistent 읽기를 사용합니다(4 KB당 1 RCU).
- BatchGetItem을 사용하여 여러 디바이스의 최신 읽기 값을 한 번에 가져옵니다.
보조 서비스 (선택 사항)
| 서비스 | 목적 |
|---|---|
| AWS Kinesis Data Streams | 들어오는 센서 데이터를 버퍼링하고, 급격한 쓰기 폭주를 완화하며, Lambda 소비자를 통해 DynamoDB에 전달합니다. |
| AWS Lambda (TTL cleanup) | 정확히 30 일에 삭제가 필요할 경우, 예약된 Lambda가 ttl이 만료에 가까운 항목을 조회하고 삭제할 수 있지만, 일반적으로 DynamoDB TTL가 충분합니다. |
| Amazon CloudWatch Alarms | ConsumedWriteCapacityUnits, ThrottledRequests, SystemErrors를 모니터링하여 스케일링이나 알림을 트리거합니다. |
| AWS Glue / Athena | S3( DynamoDB Streams → Lambda → S3)로 내보낸 히스토리 데이터에 대한 ad‑hoc 분석을 수행합니다. |
트레이드‑오프 요약
| 트레이드‑오프 | 영향 |
|---|---|
| 온‑디맨드 vs. 프로비저닝 | 온‑디맨드는 운영을 단순화하지만, 지속적인 10 k writes/s에서는 약 30 % 더 비쌀 수 있습니다. 프로비저닝은 용량 계획이 필요하지만 자동 스케일링을 통해 비용을 절감할 수 있습니다. |
| 샤딩 vs. 단순성 | 샤딩은 편향된 디바이스 트래픽으로 인한 핫‑파티션 위험을 없애지만, 쿼리 로직에 복잡성을 추가합니다(디바이스당 다중 샤드). |
| TTL vs. Lambda 정리 | TTL은 저비용이며, 최종 삭제(최대 48 h 지연)됩니다. Lambda는 정밀한 제어를 제공하지만 컴퓨팅 비용이 추가됩니다. |
| 최신 읽기를 위한 GSI | 높은 부하에서도 O(1) 읽기 지연을 보장하지만, 추가 쓰기 비용이 발생합니다(각 쓰기가 GSI를 업데이트). 기본 테이블에서 Limit=1만으로 충분할 경우 불필요한 경우가 많습니다. |
| 강력 일관성 vs. 최종 일관성 | 강력 읽기는 읽기 비용이 두 배가 되므로, 즉시 최신성이 필요한 경우에만 사용합니다. |
요약
- 빠른 포인트 조회 (
QuerywithdeviceId+Limit=1,ScanIndexForward=false). - 효율적인 시간 범위 쿼리 (
QuerywithdeviceIdandtimestamp BETWEEN …). - DynamoDB TTL을 통한 자동 30일 만료.
- 온‑디맨드 또는 프로비저닝된 용량과 자동 스케일링을 사용한 비용 효율적인 고처리량 쓰기, plus optional sharding to avoid hot partitions.