DynamoDB TTL 완전 가이드: 항목 만료

Time to Live(TTL)는 여러분이 항목에 저장한 타임스탬프가 지나면 DynamoDB가 항목을 자동으로 삭제하게 합니다. Unix 에포크 만료를 담는 속성 하나를 지정하면, DynamoDB가 만료된 항목을 백그라운드에서 거둬들입니다 — 수거 작업도, 추가 비용도 없습니다.

감사 로그 시나리오에서 각 테넌트에는 보존 정책이 있습니다: 이벤트를 90일, 또는 1년, 또는 규정 준수가 무거운 테넌트라면 7년 보관. TTL은 여러분 자신의 삭제 스윕을 실행하지 않고 그것을 집행하는 방법입니다.

DynamoDB TTL은 어떻게 작동하나요?

DynamoDB TTL은 여러분이 지정된 속성에 저장한 Unix 에포크(초) 타임스탬프가 지나면 항목을 자동 삭제합니다. 테이블에서 TTL을 활성화하고, 만료 속성을 지정하면, DynamoDB가 만료된 항목을 백그라운드에서 거둬들입니다 — 대개 며칠 안에, 쓰기 용량 비용 없이 말입니다. 만료된 항목은 물리적으로 삭제될 때까지 읽을 수 있는 상태로 남습니다.

• TTL은 Unix 에포크(초) 타임스탬프를 담는 속성 하나입니다. 그 시간이 지나면 항목은 삭제 대상이 됩니다.
• 삭제는 백그라운드이고 최선 노력형입니다 — 정확한 초가 아니라, 대개 만료 후 며칠 안에.
• TTL 삭제는 무료입니다 — 쓰기 용량을 소비하지 않습니다. 다만 글로벌 테이블에서는 복제된 삭제가 다른 모든 복제본 리전에서 쓰기 비용이 듭니다.
• 만료되었지만 아직 삭제되지 않은 항목은 여전히 나타납니다 읽기에서, 그러니 즉시 숨겨야 한다면 만료 속성으로 필터링하세요.

문제: 오래된 데이터를 직접 만료시키는 것은 비싸다

TTL이 없으면 "90일보다 오래된 이벤트 삭제"를 집행하려면 여러분 자신의 수거기를 실행해야 합니다: 예약에 따라 오래된 항목을 스캔(또는 쿼리)하고 각각을 DeleteItem합니다. 그 스캔은 읽기 용량을 태우고, 삭제는 쓰기 용량을 태우고, 예약, 실패, 재시도를 여러분이 소유합니다.

대용량 감사 로그에서 그것은 데이터를 버리기 위한, 끊임없이 커지는 세금입니다. TTL은 그 일 전체를 무료로 DynamoDB로 옮깁니다.

TTL은 어떻게 작동하는가

테이블에서 TTL을 활성화하고 어느 속성이 만료를 담는지 알려줍니다. AWS 발표에 따르면, 여러분은 Unix 에포크 만료 타임스탬프를 담는 항목 속성을 지정하고, DynamoDB는 테이블 성능에 영향을 주지 않고 백그라운드에서 삭제를 자동으로 처리합니다.

정확성에 두 가지 속성이 중요합니다:

• 정확한 것이 아니라 최선 노력형입니다. DynamoDB는 만료된 항목을 스캔해 백그라운드에서 삭제합니다. 삭제는 대개 만료 후 며칠 안에 일어납니다. 항목은 타임스탬프 시점에 _대상_이 되지만 잠깐 남아 있을 수 있습니다.
• 만료된 항목은 거둬지기 전까지 여전히 읽을 수 있습니다. Query는 TTL이 지났지만 아직 삭제되지 않은 항목을 반환할 수 있습니다 — 그러니 "만료 = 즉시 보이지 않음"이 엄격한 요구사항이라면 만료 속성에 FilterExpression을 추가하세요.

그리고 TTL 삭제는 쓰기 용량을 소비하지 않으며, 이것이 그것을 직접 실행하는 수거기보다 엄격히 더 저렴하게 만드는 요인입니다.

실제 예제: 테넌트별 보존

각 감사 이벤트는 이벤트가 쓰일 때 설정되는 expiresAt 속성을 지닙니다 — now + 테넌트의 보존 창, 에포크 초 단위:

TTL은 expiresAt을 TTL 속성으로 하여 활성화됩니다. acme의 90일 이벤트가 1782259200을 넘으면, DynamoDB가 대략 이틀 안에 스스로 그것을 삭제합니다. 규정 준수 테넌트의 이벤트는 아주 먼 미래의 expiresAt을 지니므로 살아남습니다 — 같은 테이블, 같은 메커니즘, 항목마다 다른 보존.

쓰기 쪽은 그저 이벤트를 만들 때 숫자 하나를 더하는 것입니다. DynamoDB Expression Builder에서 SET expiresAt = :ttl 절을 구성하고 타입 지정된 :ttl 값을 검증할 수 있습니다.

만료되었지만 거둬지지 않은 이벤트를 읽기에서 즉시 숨기려면, 쿼리의 FilterExpression에 expiresAt > :now를 추가하세요 — 다만 필터가 읽기 비용을 줄이지 않는다는 점을 기억하세요 (query 대 scan).

DynoTable에서 해보기

고전적인 TTL 버그는 잘못된 expiresAt입니다: 초 대신 밀리초로 저장되거나, ISO 문자열로 저장되어, 항목이 결코 만료되지 않거나 즉시 사라집니다. 그것을 잡는 유일한 방법은 실제로 저장된 값과 그 타입을 보는 것입니다.

DynoTable은 각 항목의 속성을 DynamoDB 타입과 함께 보여주므로, 실제 보존을 TTL에 맡기기 전에 expiresAt이 문자열도, 밀리초도 아닌 에포크 초 단위의 Number인지 확인할 수 있습니다.

함정과 다음 단계

• 에포크 초, Number로. 이것이 단연코 가장 흔한 TTL 실수입니다. 밀리초 값은 만료를 약 50,000년 뒤로 밀어내고, ISO 문자열은 완전히 무시됩니다. 타입과 단위를 검증하세요. 값을 TTL 변환기에 붙여넣어 보세요 — 초인지 밀리초인지 자동으로 감지하고 정확히 이 실수를 표시합니다.
• 삭제 타이밍에 의존하지 마세요. 만료와 삭제 사이에 며칠이 지날 수 있습니다. "만료되는 즉시 사라짐"이 중요하다면, 읽기에서 속성으로 필터링하세요. 행이 물리적으로 사라졌다고 가정하지 마세요.
• TTL 삭제는 Streams에 나타납니다. TTL 삭제는 시스템 생성으로 표시된 스트림 레코드를 방출합니다 — 만료되는 이벤트가 사라지기 전에 S3로 아카이빙하는 표준 훅입니다. DynamoDB Streams를 참고하세요.
• TTL 삭제는 여전히 GSI에 영향을 줍니다. 항목을 제거하면 그것이 속했던 모든 보조 인덱스에서도 제거됩니다 — 이것이 의도된 정리이지만, 인덱스가 개수를 이끌었다면 알아둘 가치가 있습니다.

TTL은 이벤트 생애의 끝을 저렴하게 처리합니다. 다음 질문은 애초에 쓰기에 무엇을 지불하는가입니다 — 온디맨드 대 프로비저닝 용량.

DynoTable을 다운로드해 TTL을 켜기 전에 여러분 항목의 속성 타입을 살펴보고 TTL 속성이 Unix 에포크 Number인지 확인하세요.