보존 기간
고친 사람 github-actions[bot]
보존 기간은 쌓인 데이터를 언제까지 들고 있다가 버릴지 미리 정해 둡니다. 기간이 다 된 데이터는 사람이 그때그때 판단하지 않아도 정해진 절차를 따라 없어집니다. 저장소가 끝없이 불어나지 않습니다. 남겨야 하는 기록은 그 기간 동안 확실히 남습니다.
쉽고 빠른 이해
보존 기간은 데이터를 언제까지 두었다가 버릴지 적어 둔 약속입니다. 「접속 기록은 석 달, 결제 기록은 다섯 해」처럼 데이터 종류마다 따로 적습니다.
적어 두지 않으면 지우는 판단이 매번 사람에게 넘어옵니다. 아무도 못 지우면 저장 비용이 계속 늡니다. 누군가 임의로 지우면 나중에 필요한 기록이 없어집니다.
도는 모양은 셋입니다.
- 데이터마다 언제부터 셀지 기준 시각을 붙입니다
- 기준 시각에서 정한 기간이 지났는지 주기로 확인합니다
- 지난 것은 지우거나 값싼 저장소로 옮깁니다
대가가 있습니다. 한번 지운 데이터는 되돌아오지 않습니다. 기간을 짧게 잡으면 나중에 해야 할 조사를 못 합니다. 길게 잡으면 비용과 유출 피해가 같이 커집니다.
상세
지하철역 분실물 보관소 벽에는 안내문이 한 장 붙어 있습니다. 우산은 한 달, 지갑은 여섯 달을 두었다가 처분한다고 적혀 있습니다. 물건이 들어오면 어느 줄에 해당하는지만 보고 그 줄에 적힌 달이 되었을 때 치웁니다.
보존 기간은 데이터를 만든 때부터 버릴 때까지 들고 있기로 미리 정한 길이입니다. 웹 서버의 접속 기록은 석 달만 두고 결제 기록은 다섯 해를 두기로 했다면, 그 석 달과 다섯 해가 각각의 보존 기간입니다. 데이터 한 건마다 따로 정하는 것이 아니라 로그·백업·메트릭처럼 데이터 종류마다 하나씩 겁니다.
정해 두지 않아도 시스템은 돕니다. 그러면 지우는 판단이 매번 사람에게 넘어옵니다. 지울 권한이 있는 사람이 「나중에 필요할지 모른다」며 미루면 저장소가 계속 불어납니다. 반대로 급한 김에 먼저 지운 데이터가 사고 조사에 꼭 필요한 기록일 수도 있습니다.
보존 기간은 그 판단을 미리 한 번 해 두는 장치입니다. 한 번 정해 두면 그 뒤로는 기계가 같은 규칙을 되풀이합니다. 지우는 일이 그날 누가 당직인지, 얼마나 바쁜지에 흔들리지 않습니다.
보존 기간을 세우는 세 가지 결정
기간의 길이 하나만 정하면 될 것 같지만, 그 숫자만으로는 기계가 움직이지 못합니다. 세 가지가 더 정해져야 「지워도 되는 데이터」를 골라낼 수 있습니다.
첫째는 무엇을 한 덩이로 볼 것인가입니다. 기록 한 줄마다 따로 셀 수도 있습니다. 하루치 파일 하나를 한 덩이로 묶어 셀 수도 있습니다. 덩이가 클수록 지우는 일이 싸집니다. 다만 아직 기간이 안 지난 데이터까지 끌려 나가지 않도록 덩이를 시간 순서로 잘라 두어야 합니다.
둘째는 언제부터 세느냐입니다. 같은 「석 달」이라도 기준 시각을 무엇으로 잡느냐에 따라 데이터가 없어지는 때가 달라집니다.
| 기준 시각 | 세는 법 | 잘 맞는 데이터 |
|---|---|---|
| 만든 때 | 저장된 순간부터 센다 | 감사 로그처럼 뒤에 고쳐지지 않는 기록 |
| 마지막으로 쓴 때 | 읽거나 고칠 때마다 다시 센다 | 세션·임시 파일처럼 안 쓰면 버려도 되는 것 |
| 사건이 일어난 때 | 데이터 안에 적힌 시각부터 센다 | 늦게 도착할 수 있는 측정값·거래 기록 |
표의 마지막 줄이 따로 있는 까닭은 데이터가 늦게 도착하기 때문입니다. 어제 일어난 일을 오늘 받아 저장하면 만든 때와 사건이 일어난 때가 하루 어긋납니다. 기간을 법이나 계약에 맞춰 지켜야 하는 쪽은 사건 시각을 기준으로 잡습니다. 세는 대상이 저장 행위가 아니라 사건이기 때문입니다.
셋째는 기간이 지난 다음에 무엇을 하느냐입니다. 지우는 것만이 답은 아닙니다. 값싼 저장소로 옮기거나, 자세한 값을 버리고 요약만 남기는 선택지도 있습니다.
기간을 밀고 당기는 힘
기간의 길이는 저장소 용량만 보고 정하지 않습니다. 늘리려는 요구와 줄이려는 요구가 서로 반대편에서 당깁니다. 그 줄다리기의 결과가 숫자로 적힙니다.
| 늘리는 쪽 | 줄이는 쪽 |
|---|---|
| 법이나 계약이 최소 보관 기간을 못 박는다 | 데이터가 쌓인 만큼 저장 비용이 는다 |
| 사고가 나면 그 전의 기록까지 거슬러 봐야 한다 | 들고 있는 동안은 유출될 수 있다 |
| 지난 흐름과 견주려면 과거 구간이 남아 있어야 한다 | 지워 달라는 요구를 받으면 지워야 한다 |
두 요구가 한 데이터에 같이 걸릴 때, 기간을 가운데 값으로 타협하지 않는 방법이 있습니다. 같은 데이터를 두 벌로 갈라 각각 다른 기간을 거는 것입니다. 사람을 알아볼 수 있는 원본은 짧게 둡니다. 누구인지 지운 통계 요약만 길게 남깁니다.
이렇게 갈라도 되는 까닭은 두 요구가 서로 다른 것을 보기 때문입니다. 늘리려는 쪽이 원하는 것은 대개 흐름입니다. 줄이려는 쪽이 걱정하는 것은 원본입니다.
만료를 집행하는 두 방법
정해 둔 기간이 지났다고 데이터가 스스로 사라지지는 않습니다. 누군가 기간이 지난 것을 찾아 치워야 합니다. 그 찾는 방법이 둘로 갈립니다.
하나는 한 건씩 골라 지우는 방법입니다. 저장소를 훑어 기준 시각이 지난 것만 골라 지웁니다. 어떤 조건이든 걸 수 있습니다.
그 대가가 둘입니다. 훑는 비용이 데이터 양을 따라 늡니다. 지우는 동안 저장소가 다른 요청을 늦게 처리하기도 합니다.
다른 하나는 덩이째 버리는 방법입니다. 앞서 첫째 결정에서 덩이를 시간 순서로 갈라 두었다면, 그 덩이가 그대로 지우는 단위가 됩니다.
저장할 때부터 시간 단위로 덩이를 갈라 둡니다. 하루치 파일 하나가 그런 덩이입니다. 한 테이블이나 저장소를 미리 정한 기준으로 쪼개 둔 덩이는 파티션이라고 부릅니다.
기간이 지난 덩이는 안을 들여다보지 않고 통째로 떼어 냅니다. 훑는 일이 없어서 데이터가 아무리 많아도 치우는 비용이 거의 같습니다. 대신 덩이 단위로만 지울 수 있습니다. 특정 사용자의 기록 하나만 빼 달라는 요구에는 이 방법이 듣지 않습니다.
flowchart TD
subgraph S1["한 건씩 훑기"]
A1["한 덩이 · 기간이 지난 기록과 안 지난 기록이 섞여 있다"]
A1 --> A2["처음부터 끝까지 훑는다"]
A2 --> A3["지난 것만 골라 지운다"]
end
subgraph S2["시간으로 갈라 두기"]
B1["옛 덩이 · 전부 기간이 지났다"]
B2["가운데 덩이"]
B3["새 덩이 · 갓 쌓였다"]
B1 --> B4["덩이째 떼어 낸다 · 안을 안 본다"]
end
A3 -.->|"같은 데이터를 저장할 때부터 갈라 두면"| B1
지우는 대신 단계를 밟기도 합니다. 갓 쌓인 데이터는 자주 읽힙니다. 시간이 지날수록 뜸해집니다. 그 차이에 맞춰 저장 방식을 바꿔 가며 마지막 칸에서만 지웁니다.
flowchart TD
A["갓 쌓인 원본 · 자주 읽는 저장소"] -->|"자주 읽는 기간이 지남"| B["뜸해진 구간 · 값싼 저장소"]
B -->|"원본 기간이 지남"| C["요약만 남기고 원본은 버림"]
C -->|"요약 기간이 지남"| D["요약도 만료 · 삭제"]
둘째 칸에서 하는 일을 아카이빙이라고 부릅니다. 데이터를 지우지 않습니다. 꺼내 보기 번거로운 대신 값이 싼 저장소로 옮깁니다.
셋째 칸에서 하는 일은 다운샘플링입니다. 초 단위로 쌓인 값을 시간 단위 평균 하나로 줄이면 자세한 값은 잃습니다. 흐름은 남고 크기는 크게 줄어듭니다.
이렇게 단계를 두면 기간을 하나로 정하지 않아도 됩니다. 원본을 들고 있는 기간과 요약을 들고 있는 기간을 따로 적습니다. 데이터가 나이를 먹을수록 다음 칸으로 넘깁니다.
삭제가 닿지 않는 사본
「지웠다」는 말이 실제로 무엇을 뜻하는지는 저장소마다 다릅니다. 많은 저장소가 지우라는 요청을 받으면 지웠다는 표시만 남기고 원래 바이트는 건드리지 않습니다. 이 표시를 툼스톤이라고 부릅니다.
데이터가 공간에서 빠지는 때는 나중에 정리 작업이 한 바퀴 돌 때입니다. 정리 작업은 저장소가 표시만 남은 데이터를 주기로 쓸어 담아 실제 공간을 돌려주는 일입니다. 컴팩션이나 가비지 컬렉션이 그런 작업입니다. 언제 도는지는 저장소가 정합니다.
사본도 문제입니다. 운영 중인 데이터는 대개 한 곳에만 있지 않습니다.
flowchart TD
O["원본 · 보존 기간이 끝나 지운다"]
subgraph S["사본마다 제 시계가 따로 돈다"]
R["복제본 · 짧다"]
B["백업 · 길다"]
I["색인 · 짧다"]
C["캐시 · 아주 짧다"]
end
O --> R
O --> B
O --> I
O --> C
B --> E["데이터가 없어지는 때"]
원본을 지워도 이 사본들에 남아 있으면 보존 기간을 지킨 것이 아닙니다. 그래서 기간을 정할 때는 사본이 몇 벌인지, 각 사본이 언제 없어지는지까지 같이 적습니다.
백업이 대개 가장 오래 남습니다. 데이터가 없어지는 때는 마지막 백업이 만료되는 때입니다.
TTL·축출과 갈리는 대목
셋 다 「때가 되면 데이터가 없어진다」는 이야기라 자주 섞여 쓰입니다. 무엇이 방아쇠를 당기는지가 다릅니다.
TTL(Time To Live, 살아 있을 시간)은 데이터 한 건에 붙여 두는 남은 수명입니다. 보존 기간은 데이터 종류 전체에 거는 규칙입니다. 그 규칙을 한 건씩 집행하는 수단의 하나가 TTL 입니다.
축출은 담을 공간이 모자랄 때 이미 들어 있는 것을 골라 내보내는 일입니다. 시간이 아니라 남은 공간이 방아쇠입니다. 그래서 축출은 공간이 넉넉하면 영영 안 일어납니다. 보존 기간은 공간이 남아돌아도 때가 되면 일어납니다.
셋을 방아쇠 · 거는 대상 · 안 지켰을 때로 나란히 놓으면 이렇습니다.
| 무엇이 방아쇠인가 | 무엇에 거나 | 안 지키면 | |
|---|---|---|---|
| 보존 기간 | 정해 둔 시간이 지남 | 데이터 종류 전체 | 규제를 어기거나 비용이 샌다 |
| TTL | 붙여 둔 수명이 다함 | 데이터 한 건 | 낡은 값이 계속 읽힌다 |
| 축출 | 남은 공간이 모자람 | 저장소 전체 | 새 데이터를 못 받는다 |
고를 때의 기준도 이 표에서 나옵니다. 데이터 종류 전체에 「언제까지」를 못 박아야 하면 보존 기간을 겁니다. 한 건씩 수명이 달라야 하면 TTL 을 붙입니다. 언제 없어지든 상관없고 공간만 안 넘치면 되는 데이터라면 보존 기간을 정하지 않고 축출에 맡깁니다.
관련 항목
보존 기간을 따로 정해 두는 데이터 종류
로그 · 감사 로그 · 메트릭 · 트레이스 · 시계열 데이터 · 백업 · 스냅샷 · 개인정보
기간이 끝난 데이터를 줄이거나 옮기는 수단
아카이빙 · 다운샘플링 · 롤업 · 압축 · 로그 회전 · 콜드 스토리지 · 계층형 저장소
만료를 기계가 집행하게 하는 장치
TTL · 축출 · 수명 주기 정책 · 툼스톤 · 컴팩션 · 가비지 컬렉션 · 파티셔닝
보존 기간이 걸리는 데이터를 담는 저장소
객체 스토리지 · 시계열 데이터베이스 · 데이터 레이크 · 데이터 웨어하우스 · 로그 수집 · 검색 색인
보존 기간 길이를 밀고 당기는 요구
저장 비용 · 규제 준수 · 전자 증거 개시 · 잊힐 권리 · 데이터 최소화 · 용량 계획
보존 기간과 함께 정하는 복구 목표
백업과 복구 · 복구 시점 목표 · 복구 시간 목표 · 증분 백업 · 세대 관리
보존 기간과 헷갈리는 이웃 개념
다른 이름: 데이터 보존 기간 · 리텐션 · retention period · retention