Redis,
껍데기 제거

Redis가 빠르다는 말은 모든 명령이 공짜라는 뜻이 아니다. 일반 명령 실행은 주 실행 경로에서 직렬화되므로 O(N) 명령, 큰 응답, blocking command가 다른 client의 대기 시간을 늘릴 수 있다.

I/O thread는 네트워크 read/write 일부를 병렬화할 수 있지만 임의의 명령을 동시에 실행해 원자성을 깨는 worker pool이 아니다.

TCP stream에는 message boundary가 없고 client connection 하나의 요청/응답 순서는 보존된다는 점, O(1)과 O(N), p50과 p99 차이를 먼저 설명할 수 있어야 한다.

0–3분 RESP frame, 3–7분 event loop, 7–10분 pipeline/RTT, 10–13분 blocking/slow command, 13–15분 trace와 SLOWLOG 판독 순서로 학습한다.

accept된 socket이 readable event를 만들고 parser가 RESP array를 command와 argument로 해석한다. key lookup과 command body가 실행된 뒤 reply buffer가 writable event에서 flush된다. pipeline은 왕복을 줄이지만 서버 작업량을 없애지 않는다.

lab은 ACL 인증을 강제하므로 아래 RESP2 transcript는 labapp으로 AUTH한 뒤 PING한다. frame 길이와 CRLF가 틀리면 protocol error가 난다. secret은 명령에 하드코딩하지 않지만 평문 loopback payload에는 포함된다.

make lab-up MODE=standalone
set -a; . ./.env; set +a
printf '*3\r\n$4\r\nAUTH\r\n$6\r\nlabapp\r\n$%s\r\n%s\r\n*1\r\n$4\r\nPING\r\n' \
  "${#REDIS_APP_PASSWORD}" "$REDIS_APP_PASSWORD" | nc 127.0.0.1 "${STANDALONE_PORT:-6379}"
# expected: +OK then +PONG; never share the capture or shell trace

bounded connection pool, command timeout, connect timeout, abort signal, retry budget를 별도로 둔다. multiplexing client에서 긴 blocking command는 전용 connection으로 분리하고 pipeline batch 크기를 제한한다.

const product = await redis.get(key, { signal: deadline.signal });
if (product === null) return loadWithCoalescing(key);
// retries: idempotent reads only; one bounded retry with jitter

GET product:42: DNS/connection 또는 pool checkout → RESP encode → kernel send → server parse → dictionary lookup → expire check → value encode → socket flush → client decode → application deadline 기록. 각 구간을 한 덩어리의 'Redis latency'로 부르지 않는다.

격리된 lab에서 큰 string upload·allocation 중 PING을 sampling하고 UNLINK enqueue 시간을 기록한다. big key 생성은 production에서 금지하며 별도 HTTP load로 지연 기준선을 비교한다.

make lab-failure SCENARIO=big-key
make lab-test-load

integration은 RESP2/RESP3 client 모두 PING/GET을 확인한다. load는 동일 QPS에서 sequential과 pipeline의 p50/p99 및 bytes를 비교한다. failure는 blocking client 종료 후 probe p99가 기준선으로 돌아오는지 확인한다.

request 크기, reply 크기, pipeline in-flight 수를 함께 제한한다. throughput만 보지 말고 queueing이 드러나는 p99, event-loop latency, client pool wait를 같은 시간축에 둔다.

raw protocol 캡처에는 AUTH credential과 값이 들어갈 수 있다. 교육 artifact에서는 loopback만 캡처하고 secret·session·PII payload를 redaction한다.

SLOWLOG GET, LATENCY DOCTOR/HISTORY, INFO commandstats, instantaneous_ops_per_sec, network bytes와 application pool wait를 수집한다. SLOWLOG는 server execution time 중심이므로 client RTT를 대체하지 않는다.

p99 급등 시 ① client pool/RTT ② SLOWLOG·commandstats ③ big key/큰 reply ④ CPU와 fork/defrag ⑤ blocking client 순으로 확인한다. DEBUG나 KEYS 같은 위험 명령은 incident 중 임의 실행하지 않는다.

RESP transcript, command trace diagram, sequential/pipeline histogram, big-key 장애 전후 metric snapshot, redacted incident note를 보관한다.

학습자가 I/O threading과 command execution을 구분하고, 동일 부하에서 pipeline의 RTT 절감과 big-key의 cross-client p99 악화를 숫자로 설명할 때 완료다. 실제 수치가 없으면 unverified다.

Q: pipeline이 명령을 병렬 실행하는가? Q: SLOWLOG 2ms인데 application이 80ms인 세 가지 원인은? Q: blocking command를 일반 pool에서 분리해야 하는 이유는?

Redis 자료구조 선택은 command 개수만 줄이는 문제가 아니다. cardinality, element 크기, access pattern, TTL 단위, cluster key 배치가 맞지 않으면 O(1) 명령도 메모리 overhead와 hot key를 만든다.

Big-O는 N의 정의가 command마다 다름을 이해한다. 전체 key 수, collection 길이, 반환 element 수, member 문자열 길이를 command 문서에서 각각 확인한다.

0–5분 use case→자료형, 5–9분 encoding 전환, 9–12분 complexity/overhead, 12–15분 MEMORY USAGE와 big-key failure로 진행한다.

string은 bytes이며 counter/bitmap도 같은 논리형을 쓴다. hash/list/set/zset은 작고 제한된 원소에서 compact encoding을 쓸 수 있고 임계값을 넘으면 표현이 바뀐다. Stream은 radix-tree 계열 노드에 entry를 묶는다. 정확한 encoding 이름과 임계값은 실제 8.8 설정에서 OBJECT ENCODING과 CONFIG GET로 확인한다.

HyperLogLog는 근사 distinct count, geo는 sorted-set 기반 좌표 인덱스, bitmap은 dense integer domain에 적합하다. 오차·좌표 정밀도·sparse domain 비용을 숨기지 않는다.

아래는 자료형별 최소 동작이다. TYPE, OBJECT ENCODING, MEMORY USAGE를 결과와 함께 저장한다.

SET product:42 '{"name":"pen"}'
HSET session:abc user 7 scope read
LPUSH retry:q job-1
SADD product:42:tags stationery blue
ZADD rank 99 user:7
XADD jobs * type reindex id 42
SETBIT active:2026-07 7 1
PFADD uv user:7
GEOADD stores -79.3832 43.6532 toronto

자료형마다 maximum cardinality와 element bytes를 schema처럼 선언하고 write 전에 거부한다. 전체 collection 조회 대신 pagination/score range/stream count를 제한하며 key 하나가 tenant 전체를 담지 않게 shard key를 설계한다.

const MAX_TAGS = 64;
if (tags.length > MAX_TAGS) throw new DomainError('too_many_tags');
await redis.hSet(productKey(id), encodeBoundedProduct(product));

ZADD rank 99 user:7은 key lookup → type 확인 → member lookup → score insert/update → 구조 재배치 → dirty counter/replication/AOF propagation → integer reply로 이어진다. O(log N)만 보고 allocator와 persistence 비용을 제외하지 않는다.

격리 lab에 큰 string을 만들고 PING tail, MEMORY USAGE, UNLINK enqueue를 함께 기록한다. collection 전체 반환과 DEL 비교는 packaged scenario가 아니므로 production data 복제본에서 임의 실행하지 않는다.

make lab-failure SCENARIO=big-key
make lab-metrics

각 자료형의 round-trip과 잘못된 type 오류를 integration에서 검사한다. load는 cardinality/element bytes를 단계적으로 올려 latency knee를 찾고, failure는 big-key 작업 중 작은 GET probe의 p99와 timeout 비율을 기록한다.

MEMORY USAGE는 key/value와 allocator 할당의 샘플 추정치이며 전체 RSS와 같지 않다. 작은 key 수백만 개는 payload보다 dictionary, object, allocator overhead가 더 클 수 있다.

key 이름과 collection member도 민감정보로 취급한다. email·token·좌표를 평문 key에 넣지 않고 tenant namespace와 비가역 식별자를 사용한다.

샘플 기반 key cardinality, MEMORY USAGE, SCAN+TYPE, commandstats의 usec_per_call, network output을 추적한다. --bigkeys는 전체 scan 비용과 production 영향이 있으므로 rate-limit한다.

big key 발견 시 owner와 TTL을 확인하고 새 schema로 dual-write/backfill한 뒤 traffic을 전환한다. 즉시 삭제가 필요하면 영향 평가 후 UNLINK와 rate limit을 쓰며, 잘라낸 데이터의 복구 경로를 먼저 확보한다.

자료형 decision table, cardinality budget, encoding 전환 실험, command complexity 표, big-key histogram과 migration plan을 만든다.

모든 capstone key에 자료형·최대 크기·TTL·source of truth·cluster slot 전략이 있고 big-key failure의 cross-client p99가 측정되면 완료다. encoding은 실제 runtime 출력이 없으면 unverified다.

Q: 10억 중 sparse user ID의 활성 여부에 bitmap이 불리한 이유는? Q: HLL을 billing count에 쓰면 안 되는 이유는? Q: O(1) GET이 느려질 수 있는 payload 요인은?

cache hit가 정답이라는 보장은 없다. cache-aside는 애플리케이션이 miss와 invalidation race를 소유하고, read/write-through 계열은 그 책임을 library/provider로 이동시킬 뿐 source of truth를 만들지 않는다.

권위 DB의 transaction boundary, 허용 stale window, 정상/오류 miss 비용, idempotency, endpoint별 latency/error budget을 먼저 정한다.

0–4분 cache-aside race, 4–7분 TTL/negative cache, 7–11분 stampede·avalanche·penetration, 11–15분 coalescing·jitter·early refresh와 부하 비교로 구성한다.

GET은 key lookup 때 만료 여부를 확인할 수 있고 miss를 반환한다. TTL은 consistency protocol이 아니며 expiration, eviction, failover가 모두 miss를 만들 수 있다. hot key는 shard 수와 무관하게 그 key의 slot owner와 network에 집중된다.

최소 cache-aside는 null과 cached negative sentinel을 구분하고 TTL에 jitter를 준다.

const raw = await redis.get(key);
if (raw === 'NEG') return null;
if (raw !== null) return JSON.parse(raw);
const row = await db.product.find(id);
await redis.set(key, row ? JSON.stringify(row) : 'NEG',
  { EX: row ? 60 + randomInt(0, 15) : 5 });
return row;

동일 process의 miss는 single-flight로 병합하고 cross-process refresh lease는 짧게 둔다. stale-while-revalidate는 business stale budget 안에서만 허용한다. refresh 확률은 remaining TTL과 refresh cost로 계산하고 retry 폭풍을 별도 budget으로 막는다.

return coalescer.do(key, async () => {
  const cached = await readVersioned(key);
  if (cached) return cached;
  return loadAndSetWithJitter(key, { staleBudgetMs: 5000 });
});

GET product:42 miss → coalescer leader 선출 → DB read → version 검증 → SET product:42 payload PX ttl → waiters fan-out. DB commit과 cache invalidation 사이에 old-value 재삽입 race가 있으므로 versioned key 또는 compare-before-set을 사용한다.

상품 key를 지운 직후 수백 동시 요청을 보내 baseline과 coalesced origin query 수를 비교한다. hot-key mode는 같은 ID에 집중하고 avalanche mode는 같은 TTL의 수천 key를 동시에 만료시킨다.

make lab-failure SCENARIO=cache-stampede
make lab-failure SCENARIO=hot-key
make lab-failure SCENARIO=ttl-avalanche

integration은 hit/miss/negative/invalidation을 DB와 대조한다. load는 unique-key와 hot-key 분포를 분리한다. failure는 stampede에서 origin max concurrency≤1/process, timeout/error budget, stale age, 회복 시간을 검증한다.

hit ratio 하나로 최적화하지 않는다. byte hit ratio, payload bytes, serialization CPU, origin queries, stale age, p99를 본다. negative cache cardinality는 공격자가 키를 무한 생성하지 못하게 제한한다.

authorization 결과를 tenant/user 경계 없이 cache하지 않는다. key에 tenant와 policy version을 포함하고 민감 응답은 최소 필드만 저장하며 negative cache가 resource 존재 여부 oracle이 되지 않게 한다.

cache_result={hit,miss,negative,stale,error}, origin_query_total, coalesced_waiters, refresh_reason, cached_age_ms, key-class별 bytes를 기록한다. raw key나 value는 metric label/log에 넣지 않는다.

miss 급증 시 eviction/expiration/deploy/invalidation/Redis error를 구분한다. origin 보호를 위해 concurrency limit와 stale serve를 정책 범위에서 켜고, TTL 일괄 연장이나 전체 flush는 승인 없이 하지 않는다.

key schema, source-of-truth matrix, stale budget, cache state machine, stampede/hot-key/avalanche graphs, invalidation race test와 rollback 절차를 제출한다.

동시 miss에서 origin 부하 상한, hot-key p99, avalanche 회복 시간, stale 최대값이 수치 기준을 만족하고 cache 장애 시 상품 조회의 정책 동작이 테스트될 때 완료다.

Q: TTL jitter와 request coalescing이 각각 막는 것은? Q: negative cache가 penetration 공격을 완전히 막지 못하는 이유는? Q: DB commit 뒤 DEL만으로 old value 재삽입을 막지 못하는 race를 그려라.

TTL 만료는 약속된 시각 이후 key가 관찰되지 않게 하는 수명 정책이지 그 시각에 메모리가 즉시 반환된다는 scheduler 약속이 아니다. eviction은 TTL과 무관하게 maxmemory 압력 때문에 살아 있는 key를 제거할 수 있다.

working set, resident memory, cache miss cost, durable/ephemeral key 분류, TTL 분포와 host/container memory limit을 알아야 한다.

0–4분 expire semantics, 4–8분 maxmemory/policy, 8–11분 근사 LRU/LFU, 11–15분 avalanche·eviction·noeviction failure를 실행한다.

Redis는 key access 시 passive expiration과 주기적인 active expiration을 함께 사용한다. Redis 8.8의 일반 command 경로는 현재 command 실행 전에 performEvictions를 호출해 기존 초과분을 줄이고, 실패하면 DENYOOM command를 거부한다. 따라서 하나의 큰 write는 실행 중 maxmemory를 크게 초과할 수 있고 다음 command 경계에서 eviction/OOM이 드러난다. LRU/LFU는 exact global order가 아니라 sampling 기반 근사치다.

TTL/PTTL은 -2(없음), -1(만료 없음), 비음수 remaining lifetime을 구분한다. SET의 TTL option을 원자적으로 사용한다.

SET lab:ttl value PX 5000
PTTL lab:ttl
CONFIG GET maxmemory maxmemory-policy

TTL은 base±jitter로 분산하고 write 결과에서 OOM/noeviction을 명시적으로 분기한다. cache write 실패는 관측 가능한 bypass가 될 수 있지만 session/limiter write 실패는 endpoint 정책에 따라 fail-closed한다.

try { await redis.set(key, value, { EX: ttlWithJitter(60, 0.2) }); }
catch (e) {
  if (isMaxmemoryError(e) && role === 'cache') return recordBypass();
  throw new DependencyUnavailable('redis_write_rejected');
}

Redis 8.8의 SET k v EX 60 경로는 command 전 maxmemory 검사·eviction/OOM 판단 → value 교체 → absolute expire metadata → memory accounting → replication/AOF propagation → reply 순서다. 이 SET의 큰 allocation은 같은 command 뒤에 즉시 post-eviction되지 않아 일시 초과할 수 있고, 다음 command 전 eviction에서 자기 key나 다른 tenant key가 사라질 수 있다.

격리 cache instance의 maxmemory를 낮추고 동일 TTL key를 채운 뒤 read load를 준다. allkeys-lfu에서는 evicted_keys와 예상치 못한 miss, noeviction에서는 write error와 application 분기를 기록한다.

make lab-failure SCENARIO=ttl-avalanche
LAB_ALLOW_DESTRUCTIVE=1 ./scripts/lab-admin.sh standalone node scripts/failure.mjs eviction --policy allkeys-lfu
LAB_ALLOW_DESTRUCTIVE=1 ./scripts/lab-admin.sh standalone node scripts/failure.mjs eviction --policy noeviction

integration은 TTL state(-2/-1/remaining)와 KEEPTTL/overwrite를 확인한다. load는 uniform·Zipfian access에서 policy별 hit ratio를 비교한다. failure는 threshold alert→eviction/error→회복 상태 전이를 검증한다.

used_memory/maxmemory 70% 경고, 80% page, 85% write shed 검토를 lab 기본 threshold로 둔다. 이는 workload 측정 전의 project policy이며 RSS, fragmentation, fork headroom을 별도로 예약한다.

tenant A가 key flood로 tenant B의 session을 evict하지 못하게 trust class별 instance/limit를 분리한다. TTL 없는 key 생성 권한과 CONFIG 변경 권한은 application ACL에서 제거한다.

INFO memory의 used_memory/maxmemory/mem_fragmentation_ratio, INFO stats의 expired_keys/evicted_keys/keyspace_hits/misses, command error와 TTL histogram을 같은 dashboard에 둔다.

eviction 급증 시 신규 key class/deploy, TTL 누락, payload 성장, traffic shift를 찾는다. 무조건 maxmemory를 올리기 전에 host headroom과 fork peak를 계산하고, policy 변경은 canary에서 hit/error 변화를 본다.

key class별 TTL/policy 표, TTL histogram, eviction benchmark, OOM error contract, threshold alert와 recovery timeline을 제출한다.

synchronized expiration과 eviction miss가 재현되고, 모든 write path가 noeviction error를 의도대로 처리하며 threshold가 metric 기반으로 설명될 때 완료다.

Q: expired_keys와 evicted_keys의 원인 차이는? Q: volatile-lru가 TTL 없는 key만 남겨 OOM을 만들 수 있는 이유는? Q: exact LRU가 아닌 것이 운영 판단에 주는 영향은?

used_memory는 payload 합계가 아니며 RSS와도 같지 않다. allocator size class, dictionary/object metadata, fragmentation, replication buffers, client buffers, child COW가 container OOM을 결정할 수 있다.

virtual/resident memory, page, fork, COW, cgroup/container limit, allocator fragmentation과 peak write rate를 이해한다.

0–4분 accounting, 4–7분 object/encoding, 7–11분 fork+COW, 11–15분 capacity sheet와 rewrite/fork failure를 다룬다.

Redis process는 allocator를 통해 메모리를 얻고 freed pages가 즉시 OS RSS로 돌아가지 않을 수 있다. background child가 RDB/AOF rewrite를 하는 동안 parent write가 page를 dirty하게 만들면 COW로 물리 메모리가 늘어난다. active defrag는 fragmentation을 줄일 수 있지만 CPU/latency 비용이 있다.

서버 전체, key 표본, allocator 통계를 따로 수집한다. MEMORY DOCTOR 결과는 진단 힌트이며 capacity proof가 아니다.

redis-cli INFO memory
redis-cli MEMORY STATS
redis-cli MEMORY USAGE product:42 SAMPLES 20
redis-cli MEMORY DOCTOR

capacity = dataset estimate + client/replication buffers + allocator/fragmentation allowance + peak COW + OS/agent reserve로 계산한다. observed p99 payload와 p99 write rate를 넣고 평균값만 쓰지 않는다.

dataset = sum(keyCount[class] * sampledP99Bytes[class])
cow = peakWriteBytesPerSec * longestChildSeconds
requiredHost = dataset + buffers + fragAllowance + cow + osReserve

HSET session:1 field value는 existing encoding 확인 → 필요 시 확장/encoding 전환 → allocator allocation → old allocation free → dictionary/object accounting → child가 있으면 touched page COW → reply로 이어질 수 있다.

쓰기 churn을 유지한 채 BGREWRITEAOF와 BGSAVE를 각각 실행해 fork duration, current_cow_size/peak, RSS, p99를 기록한다. 별도 big-key workload로 작은 probe 지연도 측정한다. host 여유 메모리가 확보된 lab에서만 실행한다.

make lab-test-load
make lab-failure SCENARIO=aof-rewrite
make lab-failure SCENARIO=fork-latency
make lab-failure SCENARIO=big-key

integration은 capacity collector가 INFO/MEMORY 필드를 파싱하는지 본다. load는 key count×payload grid를 실행한다. failure는 child 시작 전/중/후 RSS·COW·p99와 memory limit 접근 시 application error를 비교한다.

memory pressure는 단순 OOM 직전에만 나타나지 않는다. allocator work, page fault, reclaim/swap, fork page-table 복사, defrag가 tail latency를 높일 수 있다. swap은 낮은 평균 latency를 보장하는 안전망이 아니다.

MEMORY USAGE/SCAN 결과와 heap artifact에는 key 이름과 PII가 노출될 수 있다. 최소 ACL의 전용 진단 계정, redaction, 짧은 보관 기간을 적용한다.

used_memory, used_memory_rss, allocator_active/resident, fragmentation ratio/bytes, mem_not_counted_for_evict, client/replication buffers, latest_fork_usec, current/peak COW, host PSI와 swap을 수집한다.

RSS 급증 시 dataset 성장, buffer, fragmentation, child COW를 먼저 분리한다. rewrite 중이면 write rate와 child progress를 보고 headroom이 위험할 때 traffic/write shedding 또는 replica 승격 계획을 사용한다. process kill은 durability/failover 평가 뒤 선택한다.

capacity worksheet, key sample report, encoding transition chart, rewrite/fork timeline, headroom policy와 OOM recovery decision tree를 제출한다.

estimated dataset와 observed used_memory/RSS 오차를 설명하고, peak COW를 포함한 memory limit에서 rewrite와 load가 error budget 안에 있을 때 완료다. host별 결과 없이 capacity는 unverified다.

Q: DEL 뒤 used_memory는 줄었는데 RSS가 유지될 수 있는 이유는? Q: fork child가 dataset 두 배를 즉시 복사하지 않아도 peak가 위험한 이유는? Q: mem_fragmentation_ratio 하나만 보면 안 되는 이유는?

AOF나 RDB를 켰다고 Redis가 자동으로 업무의 source of truth가 되지 않는다. durability는 crash 후 재생 가능한 범위이고, consistency·backup 격리·업무 제약·감사 이력은 별도 문제다.

RPO/RTO, fsync와 page cache, process/host/region failure, fork/COW, checksum, backup retention과 restore ownership을 정의한다.

0–4분 RDB/AOF timeline, 4–8분 appendfsync, 8–11분 rewrite/fork/COW, 11–15분 kill/restart와 restore drill로 진행한다.

RDB는 특정 시점 dataset을 child가 직렬화한다. AOF는 write command를 기록하고 fsync 정책에 따라 OS page cache와 stable storage 사이의 손실 window가 달라진다. Redis 7.0 이상 multipart AOF에서 rewrite child는 새 base AOF를 만들고 parent는 새 incremental AOF에 계속 append한다. 완료 시 base·increment 파일 목록을 담은 임시 manifest를 지속한 뒤 manifest를 atomic 교체하며, Redis 7 미만의 단일 AOF+rewrite buffer 설명을 그대로 적용하지 않는다.

설정과 진행 상태를 먼저 저장하고 명시적 snapshot을 실행한다. CONFIG SET은 lab 전용이며 image config 파일이 실제 source다.

redis-cli CONFIG GET save appendonly appendfsync
redis-cli INFO persistence
redis-cli BGSAVE
redis-cli BGREWRITEAOF

application은 SET success를 business commit으로 기록하지 않는다. job 결과는 idempotency key와 DB status를 함께 쓰고 Redis persistence profile별 RPO를 API contract에 반영한다.

await db.transaction(async tx => {
  await tx.jobResult.insertOnce(idempotencyKey, result);
  await tx.outbox.insert({ type: 'job.completed', idempotencyKey });
});
// Redis status is a projection, not the authoritative commit.

SET job:1 done은 memory mutation → replica/AOF propagation queue → AOF buffer/write → fsync policy 경계 → client reply 순서를 가진다. reply 시점과 disk/replica durability는 설정과 failure timing에 따라 다르므로 동일시하지 않는다.

고유 sequence를 지속 기록하면서 SIGKILL/restart하여 마지막 acknowledged sequence와 복구된 sequence 차이를 측정한다. 별도로 rewrite 중 write churn을 주어 RSS/COW/p99를 측정한다. volume 사본에서 restore하고 원본 backup은 변경하지 않는다.

make lab-test-restart
make lab-failure SCENARIO=aof-rewrite
# PSEUDOCODE — no packaged restore command: copy the volume,
# restore it into an isolated Redis, then verify fixture/checksum/RPO/RTO.

integration은 재시작 뒤 fixture와 TTL을 검사한다. load는 persistence off/RDB/AOF everysec/always의 throughput·p99를 같은 host에서 비교한다. failure는 measured RPO/RTO, corrupt/truncated artifact 처리, checksum과 restore query를 검증한다.

fork page-table cost, COW peak, AOF buffer, disk bandwidth와 fsync tail을 capacity에 포함한다. rewrite 자동 trigger가 traffic peak와 겹치지 않는다는 가정은 금지한다.

RDB/AOF/backup은 삭제된 secret과 PII도 retention 동안 포함할 수 있다. 전송·저장 암호화, 접근 통제, checksum/signing, 폐기 절차와 redacted fixture를 적용한다.

rdb_bgsave_in_progress, rdb_last_bgsave_status/time_sec, aof_rewrite_in_progress, aof_last_write_status, aof_delayed_fsync, current/peak COW, latest_fork_usec, disk latency를 alert와 연결한다.

persistence 오류 시 write 계속 여부를 설정과 업무 RPO에 따라 판단하고 artifact를 먼저 보존한다. 마지막 정상 backup의 checksum, restore 격리 환경, recovered sequence, application reconciliation을 순서대로 확인한다.

durability matrix, crash-loss ledger, throughput/p99 table, rewrite COW chart, versioned backup/checksum, restore transcript와 reconciliation report를 만든다.

설정별 measured RPO/RTO가 정책과 일치하고 깨끗한 환경에서 backup을 restore해 application invariant를 확인하면 기능 검증이다. 실제 재해·다중 AZ 복구는 수행 전까지 unverified다.

Q: AOF everysec의 acknowledged write가 crash에서 손실될 수 있는 경계는? Q: backup file 존재가 restore 가능성을 증명하지 않는 이유는? Q: persistence와 source of truth의 차이는?

replica와 Sentinel이 있으면 모든 acknowledged write가 보존된다는 주장은 틀리다. 기본 replication은 비동기이고 Sentinel은 합의된 데이터 로그가 아니라 primary 발견·감시·failover 조정을 제공한다.

offset, network partition, failure detector, quorum과 majority 차이, RPO/RTO, read-after-write/session consistency를 설명할 수 있어야 한다.

0–4분 replication stream/backlog, 4–7분 resync, 7–11분 Sentinel quorum/failover, 11–15분 stale read와 acknowledged-loss 실험으로 진행한다.

primary는 write stream과 offset을 replica에 전송한다. 짧은 단절은 repl backlog 범위에서 partial resync가 가능하고 범위를 벗어나면 full resync가 필요하다. Sentinel quorum은 down 판정에 필요하고 failover authorization에는 Sentinel majority도 필요하다.

role, offset, link, lag를 primary와 replica에서 함께 읽는다. WAIT는 지정 replica acknowledgement를 기다릴 수 있지만 강한 durability나 선형화 보장은 아니다.

redis-cli -p 6379 INFO replication
redis-cli -p 6380 INFO replication
redis-cli -p 26379 SENTINEL MASTER mymaster
redis-cli -p 6379 WAIT 1 1000

client는 Sentinel에서 현재 primary를 재발견하고 bounded exponential backoff로 reconnect한다. write retry에는 idempotency key를 요구한다. write 직후 같은 request의 read는 primary를 사용하며 replica read는 명시한 stale budget에서만 허용한다.

await writePrimary(orderProjection, { idempotencyKey });
const view = needsReadYourWrite
  ? await primary.get(key)
  : await boundedLagReplica({ maxLagMs: 250 }).get(key);

SET session:revoked 1은 primary memory/AOF → client ACK와 독립적으로 replica socket/offset으로 전파된다. ACK 직후 primary가 격리되고 아직 받지 못한 replica가 승격되면 새 primary에는 그 key가 없을 수 있다.

replica link에 latency/pause를 주고 primary write 직후 replica read를 대조한다. 이어 sequence writer의 ACK ledger를 보관하면서 primary를 격리·failover하고 새 primary의 최대 sequence와 차이를 계산한다. 데이터 손실 실험은 disposable namespace에서만 한다.

make lab-up MODE=replication
docker compose --env-file .env exec -T lab-app-sentinel sh -ec '
  export LAB_ALLOW_DESTRUCTIVE=1 REDIS_ADMIN_PASSWORD="$REDIS_SENTINEL_PASSWORD";
  export PRIMARY_URL="redis://default:${REDIS_SENTINEL_PASSWORD}@redis-primary:6379/0";
  export REPLICA_URL="redis://default:${REDIS_SENTINEL_PASSWORD}@redis-replica:6379/0";
  node scripts/failure.mjs replica-stale-read'
make lab-test-failover

integration은 Sentinel discovery와 role change 후 reconnect를 확인한다. load는 write rate별 byte/offset lag를 측정한다. failure는 old-primary ACK ledger, promoted offset, lost/duplicate sequence, RTO와 client error window를 출력한다.

backlog, replica output buffer, full-sync snapshot/COW와 catch-up traffic이 memory·disk·network를 동시에 압박한다. 작은 backlog는 잦은 full resync 비용으로 되돌아온다.

Sentinel, primary, replica는 각각 ACL/TLS와 분리된 credential을 사용한다. replica와 backup도 동일한 PII 통제를 받으며 외부 client가 REPLICAOF, FAILOVER, SENTINEL SET을 실행하지 못하게 한다.

role, connected_slaves, master_link_status, master_last_io_seconds_ago, master_repl_offset/slave offset, backlog histlen, sync_partial/full, Sentinel events와 client reconnect/error를 같은 timeline에 둔다.

failover 후 old primary를 즉시 traffic에 복귀시키지 않는다. 새 role/offset, client routing, 데이터 차이, split-brain write 여부를 확인하고 authoritative DB/outbox로 reconcile한 뒤 old node를 replica로 재편입한다.

topology, quorum 계산, lag histogram, stale-read proof, ACK-loss ledger, failover timeline, reconciliation report와 split-brain decision tree를 제출한다.

clean Sentinel startup, automatic client rediscovery, stale read와 acknowledged loss 가능성의 재현 결과, measured RTO/RPO가 있으면 기능 검증이다. 실제 multi-node/AZ fault tolerance는 별도 수행 전까지 unverified다.

Q: quorum=2인 3 Sentinel에서 failover가 항상 가능한가? Q: WAIT가 acknowledged write loss를 완전히 제거하지 못하는 이유는? Q: partial resync 가능 여부를 무엇이 결정하는가?

Cluster는 key 수를 slot에 나눌 뿐 CPU·bytes·QPS를 자동 균등화하지 않는다. 하나의 hot key/tagged tenant는 한 slot owner에 남고, cross-slot transaction과 script에는 제약이 있다.

CRC16 기반 16,384 slot, consistent routing cache, replication/failover, network partition, multi-key atomicity requirement를 이해한다.

0–4분 slot/tag, 4–7분 MOVED/ASK, 7–11분 reshard, 11–15분 hot-slot과 failover 및 node add/remove 검증으로 진행한다.

node는 slot ownership과 cluster bus gossip을 유지한다. MOVED는 이후 요청의 owner가 바뀌었음을, ASK는 migration 중 다음 요청만 import node에 ASKING 후 보내라는 뜻이다. key tag는 첫 번째 유효한 {...} substring만 hash한다.

cluster-aware client는 redirect를 처리한다. redis-cli -c 없이 direct node를 호출해 redirect를 관찰하고 CLUSTER KEYSLOT으로 co-location을 확인한다.

redis-cli -p 7000 CLUSTER KEYSLOT 'inventory:{sku42}'
redis-cli -p 7000 CLUSTER KEYSLOT 'fence:{sku42}'
redis-cli -p 7000 GET product:42
redis-cli -c -p 7000 GET product:42

cluster-aware client의 slot map refresh, bounded redirect 횟수, topology bootstrap endpoint 여러 개, retry idempotency를 설정한다. CROSSSLOT을 key tag 남용으로 숨기기 전에 API를 single-key/DB transaction으로 재설계한다.

const cluster = createCluster({
  rootNodes: seeds, maxCommandRedirections: 4,
  retryDelayOnMoved: 25, retryDelayOnFailover: 100,
});

GET product:42은 client가 slot 계산 → cached owner로 전송 → migration이면 ASK 또는 stale map이면 MOVED → topology/one-shot route 갱신 → target 실행 → reply로 이어진다. redirect retry가 application deadline을 초과하거나 non-idempotent command를 중복할 수 있음을 처리한다.

지속 load 중 slot range를 reshard해 raw client와 cluster client의 MOVED/ASK/error/p99를 비교한다. 이어 hot tag를 한 slot에 집중하고 primary를 정지해 replica failover와 client recovery를 측정한다.

make lab-up MODE=cluster
LAB_ALLOW_DESTRUCTIVE=1 ./lab/scripts/cluster-reshard.sh
# PSEUDOCODE — hot-slot load and targeted primary-stop drills are not packaged.
# Add bounded load, stop the slot owner, then record client recovery and cluster_state.

integration은 clean 3-primary/3-replica startup, 모든 slot coverage, key tag와 CROSSSLOT을 확인한다. load는 node별 QPS/bytes/skew를 본다. failure는 redirect 성공률, duplicate count, RTO와 cluster_state를 기록한다.

reshard는 scan/migrate network와 source/target CPU·memory를 쓴다. key 수 균등만 보지 말고 key bytes, command complexity, hotness, replica headroom을 node별로 추정한다.

client port와 cluster bus port를 허용된 node 사이에만 연다. 모든 node의 ACL/TLS 정책을 일관되게 배포하고 topology endpoint, credential, MIGRATE 관련 권한을 application에서 제한한다.

cluster_state, slots assigned/ok/pfail/fail, known_nodes, messages sent/received, node별 used_memory/QPS/network, redirect/CROSSSLOT/error, slot별 sampled heat를 관측한다.

reshard 중 오류 급증 시 cluster_state와 migration/import state, target headroom, client redirect support를 확인하고 이동을 일시 중단한다. node 제거 전 slot=0, replica 관계, client seed 목록을 확인하며 강제 forget은 승인 절차를 따른다.

slot/key-tag 설계, node별 load heatmap, clean startup transcript, reshard redirect timeline, add/remove checklist, failover recovery와 duplicate ledger를 제출한다.

clean cluster startup, cluster-aware integration, live reshard 중 bounded error/redirect recovery, hot-slot detection, node add/remove drill이 실행되면 기능 검증이다. 실제 multi-node fault tolerance는 별도 환경 전까지 unverified다.

Q: MOVED와 ASK의 client 처리 차이는? Q: {tenant} tag가 workload skew를 만드는 경우는? Q: Cluster가 cross-slot transaction을 자동 조정하지 않는 이유는?

MULTI/EXEC는 관계형 DB transaction과 같은 rollback을 제공하지 않는다. queue 단계 오류와 실행 중 command 오류가 다르며, EXEC 안의 일부 command가 오류여도 앞선 command 효과를 자동 되돌리지 않는다.

critical section, compare-and-set, optimistic retry, idempotency, external side effect, cluster slot과 execution deadline을 이해한다.

0–3분 command atomicity, 3–7분 MULTI/EXEC/WATCH, 7–11분 Lua/Function, 11–15분 blocking·duplicate·rollback failure를 다룬다.

일반 command는 실행 중 다른 client command와 interleave되지 않는다. MULTI 뒤 command는 queue되고 EXEC에서 순서대로 실행된다. WATCH된 key가 EXEC 전 바뀌면 optimistic transaction은 abort한다. script/function 실행도 다른 command를 막으므로 계산과 key 수를 제한해야 한다.

WATCH+MULTI에서 DECR 뒤 idempotency SET NX를 두면 ambiguous reply 재시도 시 stock이 다시 감소하고 SET만 실패할 수 있으며 rollback되지 않는다. duplicate-safe 최소 경로는 같은 hash tag의 stock과 request ID를 bounded Lua/Function에서 먼저 검증한 뒤 한 atomic unit으로 적용한다.

EVAL "local prior=redis.call('GET',KEYS[2]); if prior then return {'DUPLICATE',prior} end; local stock=tonumber(redis.call('GET',KEYS[1]) or '-1'); local qty=tonumber(ARGV[1]); if not qty or qty<=0 then return redis.error_reply('BAD_QTY') end; if stock<qty then return {'INSUFFICIENT'} end; redis.call('DECRBY',KEYS[1],qty); redis.call('SET',KEYS[2],ARGV[2],'PX',ARGV[3]); return {'APPLIED',ARGV[2]}" 2 stock:{sku42} idem:{sku42}:req-9 1 accepted 300000

원자 update는 입력 key/value 수와 loop bound가 정해진 versioned Function으로 배포한다. request id 결과를 같은 atomic unit에 저장하되 외부 DB·HTTP side effect는 outbox/DB constraint로 보호한다.

const result = await redis.fCall('reserve_v2', {
  keys: ['stock:{sku42}', 'idem:{sku42}:req-9'],
  arguments: ['1', '300000'],
});
await db.orders.insert({ requestId: 'req-9' }); // UNIQUE(request_id)

EXEC는 WATCH validity 검사 → queued command 순차 실행 → 각 reply 배열 생성 → replication/AOF에 transaction 경계 전파 → client decode로 이어진다. reply 배열의 error element를 client가 무시하면 partial logical failure를 성공으로 오인한다.

두 client로 WATCH contention을 만들고 abort/retry를 측정한다. bounded lab에서 긴 Lua loop를 실행해 probe p99를 올린다. 응답 전달 전에 connection을 끊어 command 실행 여부가 ambiguous한 duplicate retry를 만든다.

make lab-test-lock
# PSEUDOCODE — WATCH contention, script-block, and reply-drop injectors are not packaged.
# Add disposable clients, bounded timeouts, and assert one result per request ID.

integration은 EXEC abort, queue-time error, execution-time error 배열, script/function SHA/version을 확인한다. load는 contention별 retry/p99를 측정한다. failure는 동일 request ID 두 번에도 stock·order가 한 번만 바뀌는지 본다.

MULTI queue, 큰 argv/reply, script intermediate allocation과 WATCH retry 증폭을 제한한다. script 평균 시간이 아니라 max/p99 실행 시간과 touched keys를 배포 gate로 둔다.

EVAL/FCALL 권한과 function load 권한을 분리한다. user input을 Lua source로 조합하지 않고 ARGV로 전달하며 script log/error에 token·PII를 넣지 않는다.

transaction abort/retry, idempotency hit, duplicate suppressed, script/function call latency/error, SLOWLOG, latency events, ambiguous outcome count를 수집한다.

script latency incident에서는 offending SHA/function과 caller를 식별하고 새 traffic을 차단한다. SCRIPT KILL 가능 조건과 이미 write한 script의 위험을 구분하며 restart는 failover/durability 평가 뒤 선택한다. duplicate는 DB/request ledger로 reconcile한다.

atomicity matrix, transaction error transcript, versioned function source/hash, contention graph, ambiguous-response duplicate ledger와 DB invariant proof를 제출한다.

rollback 오해를 반례로 설명하고, function max latency가 budget 안이며 duplicate request에서 Redis projection과 DB invariant가 한 번만 적용되면 완료다.

Q: EXEC array의 세 번째 command 오류가 첫 두 command를 되돌리는가? Q: WATCH abort와 network timeout을 같은 방식으로 retry하면 안 되는 이유는? Q: Lua가 외부 API 호출 transaction을 만들 수 없는 이유는?

lock 획득 성공은 lease 기간 내 유일한 실행을 보장하지 않는다. client pause, 긴 GC, scheduler stop, partition, failover가 lease 만료 뒤 old holder와 new holder를 동시에 실행시킬 수 있다. Redis lock은 DB unique/check constraint를 대체하지 않는다.

lease와 mutex 차이, monotonic counter, stale writer rejection, clock drift, pause failure, idempotency와 linearizable storage를 이해한다.

0–4분 SET NX PX/token unlock, 4–8분 lease failure, 8–12분 fencing, 12–15분 Redlock tradeoff와 재고 duplicate failure를 다룬다.

SET key token NX PX ttl은 key가 없을 때 value와 expiry를 한 command로 설정한다. unlock은 value가 자신의 random token과 같은지 검사한 뒤 DEL하는 script/function이어야 한다. 그러나 이 mutual-exclusion attempt는 downstream stale write를 막지 못한다.

token 없는 DEL은 다른 소유자의 갱신된 lease를 지울 수 있다. compare-and-delete를 사용한다.

SET lease:sku42 7f2c... NX PX 5000
EVAL "if redis.call('GET',KEYS[1]) == ARGV[1] then
  return redis.call('DEL',KEYS[1]) else return 0 end" 1
  lease:sku42 7f2c...

권위 저장소가 발급한 monotonic fencing token을 모든 재고 write에 전달하고 WHERE last_fence < :fence 조건으로 stale holder를 거부한다. 비동기 failover 가능한 Redis의 INCR만으로 token의 영구 단조성을 가정하지 않는다. lease 연장 실패 뒤 side effect는 idempotency/DB constraint로 종결한다.

const { leaseToken, fence } = await acquireInventoryLease(sku);
await db.execute(
  'UPDATE inventory SET qty=qty-1,last_fence=? WHERE sku=? AND qty>0 AND last_fence<?',
  [fence, sku, fence],
);

holder A가 lease/fence=10 획득 → 8초 정지, TTL=5초 만료 → B가 lease/fence=11 획득해 DB write → A 재개. fencing이 없으면 A가 B 결과를 덮어쓸 수 있고, DB가 last_fence<10을 거부하면 안전하게 실패한다.

holder A를 lease보다 길게 SIGSTOP하고 B를 시작한 뒤 A를 SIGCONT한다. fencing off에서는 중복 side effect를 재현하고 fencing on에서는 stale write rejection을 확인한다. 실제 결제/재고 backend에는 실행하지 않는다.

./lab/failure lease-pause --ttl 5s --pause 8s --fencing off
./lab/failure lease-pause --ttl 5s --pause 8s --fencing on

integration은 NX contention, token-safe unlock, expiry와 renewal을 검사한다. load는 high contention에서 acquisition/p99를 측정한다. failure는 duplicate effect count와 stale fence rejection count를 DB ledger로 검증한다.

lease TTL을 평균 작업 시간으로 정하지 않는다. max observed pause+network+work에 margin을 둬도 완전 보장은 없으며, 긴 TTL은 failure recovery를 늦춘다. renewal storm과 lock key cardinality를 제한한다.

ownership token은 충분한 entropy를 사용하고 로그에 전체 값을 남기지 않는다. tenant namespace, ACL, TLS를 적용하고 공격자가 임의 lock/fence key를 만들거나 지우지 못하게 한다.

lease_acquire result/latency, contention, renewal failure, lease_age, work_duration/ttl ratio, stale_fence_rejected, duplicate_effect, DB constraint conflict를 수집하며 token은 hash prefix만 기록한다.

duplicate 작업 의심 시 lock key를 강제 삭제하지 말고 request/fence/side-effect ledger를 확인한다. 신규 작업을 차단하고 authoritative DB invariant로 reconcile한 뒤 lease service와 pause/partition timeline을 분석한다.

failure timeline, unsafe DEL counterexample, lease state machine, fencing schema/SQL, duplicate ledger, correctness-vs-best-effort decision record를 제출한다.

pause 후 중복 실행이 fencing 없이 재현되고 fencing으로 stale write가 거부되며 DB constraint가 최종 invariant를 보존하면 완료다. Redlock 포함 어떤 lock도 실험만으로 모든 network model에서 안전하다고 주장하지 않는다.

Q: unique token unlock이 해결하는 문제와 못 푸는 문제는? Q: fencing token을 lock server가 아닌 downstream이 검사해야 하는 이유는? Q: best-effort lock이 적합한 예와 correctness-critical 반례는?

XACK는 처리 side effect가 정확히 한 번 발생했다는 증명이 아니라 PEL에서 delivery 책임을 제거하는 명령이다. Pub/Sub는 offline subscriber를 위해 message를 보관하지 않는다. Stream을 Kafka의 무조건 대체재로 부르지 않는다.

at-most/at-least-once, idempotency, consumer crash boundary, retention, ordering scope, backpressure, replay와 poison message를 이해한다.

0–4분 Stream/ID, 4–8분 group/PEL/ACK, 8–11분 claim/retry/trim, 11–15분 Pub/Sub loss와 abandoned pending recovery를 실행한다.

XADD는 ordered entry ID와 field/value를 Stream에 추가한다. XREADGROUP의 '>'는 아직 group에 전달되지 않은 entry를 소비자에게 배정하고 PEL에 기록한다. XACK 전 crash는 redelivery를 만들 수 있고 XAUTOCLAIM은 idle pending을 다른 consumer로 옮긴다.

group 생성→produce→consume→ack의 최소 경로다. MKSTREAM과 start ID 의미를 의식한다.

XGROUP CREATE jobs workers 0 MKSTREAM
XADD jobs * type resize jobId j-1
XREADGROUP GROUP workers c1 COUNT 10 BLOCK 1000 STREAMS jobs >
XACK jobs workers 1710000000000-0
XPENDING jobs workers

worker는 DB UNIQUE(job_id) 또는 idempotency ledger로 side effect를 commit한 뒤 XACK한다. max attempts/age 뒤 DLQ Stream에 원인과 원본 ID를 기록하고 ACK한다. claim idle threshold는 p99 처리 시간보다 충분히 커야 한다.

const inserted = await db.jobResults.insertOnce(entry.jobId, result);
if (inserted || await db.jobResults.exists(entry.jobId)) {
  await redis.xAck('jobs', 'workers', entry.id);
}

XREADGROUP은 group last-delivered ID 탐색 → entry 선택 → consumer PEL/group PEL delivery metadata 기록 → reply → worker side effect → XACK로 PEL 제거 순서다. reply 뒤 crash와 side effect 뒤 ACK 전 crash는 서로 다른 duplicate window다.

Pub/Sub subscriber를 끊은 동안 publish 후 재연결해 gap을 기록한다. Stream consumer는 read 후 ACK 전에 kill하여 pending을 방치하고 idle threshold 후 XAUTOCLAIM으로 회수한다.

./lab/failure pubsub-loss --disconnect 5s
./lab/failure stream-pending --kill-after-read --claim-after 10s

integration은 group start ID, ACK, pending, claim, retry, trim edge를 확인한다. load는 producer/consumer rate와 backlog/PEL age를 측정한다. failure는 duplicate side effect가 DB idempotency로 0인지, Pub/Sub gap이 관찰되는지 검증한다.

Stream length, entry bytes, field-name repetition, PEL cardinality와 consumer count를 capacity에 포함한다. approximate MAXLEN/MINID trim은 retention을 제한하지만 PEL·consumer recovery 의미를 사전에 시험한다.

message payload에는 secret/PII를 넣지 않고 opaque ID로 권위 저장소를 조회한다. consumer group/stream별 ACL과 tenant namespace를 사용하며 DLQ 접근을 더 제한한다.

produced/processed/acked/retried/dead-letter totals, XLEN, group lag, XPENDING count, oldest idle, delivery count, claim count, processing/queue age와 Pub/Sub subscriber gap을 기록한다.

PEL age 급증 시 consumer health, downstream latency, poison entry를 확인한다. 무작정 XACK/trim하지 말고 sample payload를 redaction해 원인을 분류하고, idempotent claim 또는 DLQ 이동 후 backlog 회복률을 감시한다.

delivery state machine, crash-window table, pending recovery transcript, Pub/Sub loss ledger, retention/capacity sheet, DLQ replay runbook을 제출한다.

Pub/Sub loss와 abandoned PEL이 재현되고 claim/retry 뒤 DB side effect가 한 번이며 backlog가 policy 시간 안에 회복되면 완료다. Kafka 대체 적합성은 별도 workload 비교 전까지 unverified다.

Q: XACK 전/후 crash window는 어떻게 다른가? Q: XPENDING이 0인데 처리 결과가 유실될 수 있는 설계는? Q: Pub/Sub가 적합한 이벤트와 부적합한 업무 command 예시는?

fixed window의 '분당 100회'는 경계 양쪽에서 200회 burst가 가능하다. multi-region의 독립 counter는 global strict limit가 아니다. session TTL은 logout/revoke 전파를 자동 보장하지 않는다.

identity/tenant trust boundary, wall versus monotonic time, burst allowance, abuse cost, endpoint availability policy, token hashing/rotation과 replica staleness를 정의한다.

0–4분 limiter 알고리즘, 4–8분 atomic script/time, 8–11분 region/failure policy, 11–15분 session revoke와 tenant escape tests를 다룬다.

fixed window는 counter+expiry, sliding log는 timestamp sorted set, sliding counter는 bucket 합, token bucket은 tokens와 last-refill state를 원자 갱신한다. 서버 TIME을 쓰면 client clock 차이를 줄이지만 region 간 하나의 global serial order를 만들지는 않는다.

INCR 후 첫 요청에만 EXPIRE를 두 command로 하면 crash window가 있다. bounded Lua/Function으로 increment와 TTL을 한 execution unit에 둔다.

local n = redis.call('INCR', KEYS[1])
if n == 1 then redis.call('PEXPIRE', KEYS[1], ARGV[1]) end
return {n, redis.call('PTTL', KEYS[1])}

key는 rl:{tenant}:{route}:{subjectHash}와 session:{tenant}:{tokenHash}를 사용한다. API는 allowed, remaining, retryAfterMs, policyVersion을 반환한다. raw session token은 Redis·log에 저장하지 않고 revoke write/read는 primary를 사용한다.

const tokenHash = hmacSha256(sessionPepper, presentedToken);
const session = await primary.hGetAll(sessionKey(tenantId, tokenHash));
const decision = await limiter.consume({ tenantId, subjectHash, cost: 1 });

limiter FCALL은 key slot route → current time/state read → refill/window prune → cost 차감 또는 deny → TTL update → decision reply다. request가 timeout 뒤 retry되면 두 번 차감될 수 있으므로 request-ID dedupe가 필요한 endpoint를 구분한다.

window boundary에 burst를 집중하고 Redis를 차단해 endpoint별 fail-open/closed 결과를 확인한다. session revoke 직후 replica를 읽어 stale acceptance를 재현하고 primary-only 정책과 비교한다.

./lab/failure limiter-boundary --limit 100 --burst 200
./lab/failure limiter-outage --routes product,order
./lab/failure session-stale-revoke --replica-delay 2s

integration은 algorithm vectors, TTL, tenant separation, token rotation/revoke를 검사한다. load는 allowed+denied 총량과 p99를 본다. failure는 public read fail-open cap과 order fail-closed, revoke stale window를 검증한다.

sliding log는 request당 member가 생겨 high-cardinality 공격에 취약하다. subject cardinality, member retention, session fields/TTL과 script runtime을 capacity에 넣고 idle session을 bounded TTL로 정리한다.

tenant ID는 request body가 아니라 인증된 context에서 얻는다. session token은 high entropy, HMAC hash, rotation, Secure/HttpOnly/SameSite cookie를 사용하고 PII는 최소화한다. limiter key enumeration 권한을 차단한다.

limiter decision/reason/policyVersion, allowed/denied, dependency error, fail-mode activation, key cardinality, session create/rotate/revoke, stale-replica acceptance를 tenant tier별 저카디널리티 label로 집계한다.

limiter 장애 시 endpoint table대로 모드를 적용하고 global emergency cap을 gateway에 둔다. session incident는 primary routing, lag, revoke ledger를 확인하고 필요 시 session epoch를 증가시켜 전체 token을 무효화하되 blast radius 승인을 받는다.

algorithm decision record, golden vectors, endpoint fail-mode table, tenant escape tests, session threat model, revoke-lag graph와 emergency procedure를 제출한다.

boundary burst·Redis outage·stale revoke가 재현되고 algorithm 결과와 endpoint fail policy가 test oracle에 일치하며 tenant cross-access가 0일 때 완료다. global multi-region strictness는 별도 조정 계층 없이는 unverified다.

Q: fixed window의 double burst는 언제 생기는가? Q: order와 public product read의 fail mode가 달라야 하는 이유는? Q: session revoke read를 replica로 보내면 생기는 보안 결과는?

private network는 인증·암호화·tenant isolation을 대체하지 않는다. Redis key 이름, command argument, SLOWLOG, MONITOR, backup은 secret/PII 유출 경로가 될 수 있고, 관측 도구 자체가 위험 명령일 수 있다.

threat model, least privilege, certificate/secret rotation, data classification/retention, SLI/SLO/error budget, incident command와 restore RPO/RTO를 정의한다.

0–4분 ACL/TLS, 4–7분 secret/PII/namespace, 7–11분 metrics/alerts, 11–15분 redaction failure·runbook·restore drill로 진행한다.

ACL user는 command category와 key/channel pattern으로 권한을 제한할 수 있다. TLS는 transport를 보호하지만 endpoint의 메모리·log·backup 평문을 제거하지 않는다. SLOWLOG는 설정 threshold를 넘은 command의 실행 정보를 보존하고 INFO commandstats는 command별 집계를 제공한다.

lab app user는 필요한 command와 namespace만 허용한다. password 예시는 fixture이며 실제 secret은 file/secret store에서 주입하고 command line에 노출하지 않는다.

ACL SETUSER app on >lab-only ~product:* ~session:* \
  +get +set +del +unlink +hgetall +hset +pexpire +fcall
ACL SETUSER app -config -debug -monitor -shutdown -acl
ACL DRYRUN app CONFIG GET requirepass

app, stream-worker, sentinel/cluster operator, exporter, backup 계정을 분리하고 credential은 short-lived rotation 경로를 둔다. logger는 allowlisted field만 구조화하고 Redis URL, token, raw key/value, command args를 redaction한다.

logger.info('redis.command', {
  op: 'GET', keyClass: 'product', result: 'hit', latencyMs,
  tenantTier: classifyTenant(tenantId), // never tenantId/key/value
});

GET session:{tenant}:{tokenHash}은 TLS handshake/session → AUTH identity → ACL command/key check → lookup → reply encryption → application decode → redacted telemetry다. 어느 단계에서도 raw token/PII가 log label로 복제되지 않아야 한다.

canary secret/PII fixture를 의도적으로 unsafe logger에 통과시켜 log/artifact scanner가 build를 실패시키는지 확인한 뒤 safe logger와 비교한다. app ACL로 CONFIG/MONITOR/다른 tenant key를 시도하고 TLS trust/expiry failure도 검사한다.

./lab/failure pii-log --fixture canary@example.invalid
./lab/security acl-negative
./lab/security tls-negative --case untrusted-ca
./lab/validate-artifacts --deny-secrets --deny-pii

integration은 allowed/denied ACL matrix, TLS hostname/CA, rotation overlap을 확인한다. load는 TLS와 telemetry overhead를 측정한다. failure는 log scanner, alert route, failover runbook, clean restore의 evidence ID를 남긴다.

TLS buffers, client output buffers, exporter scan, SLOWLOG length와 log volume도 capacity에 포함한다. MONITOR는 production 상시 관측이 아니며 high-cardinality raw-key metric은 비용과 PII 위험을 동시에 만든다.

default user off, 최소 ACL, TLS verification, network allowlist, secret manager, rotation drill, key namespace enforcement, no raw PII, backup encryption/retention을 release gate로 둔다. DEBUG/MONITOR/CONFIG/SHUTDOWN/FLUSH 계열은 operator break-glass만 허용한다.

endpoint p50/p95/p99/error, Redis latency/SLOWLOG/commandstats, memory/RSS/fragmentation, expired/evicted, hit/miss, connection/reject/error, replica lag/sync, Sentinel failover, cluster state/slot를 alert owner·threshold·runbook URL과 연결한다.

공통 절차는 detect→scope→stabilize→preserve evidence→recover→validate→reconcile→postmortem이다. credential leak은 revoke/rotate와 log retention purge, memory는 traffic shed, lag/failover는 role/offset 확인, cluster는 slot coverage, backup은 격리 restore를 사용한다.

threat model, ACL matrix, TLS/rotation transcript, data inventory/retention, redaction scanner report, SLO dashboard, alert catalog, incident runbooks, backup checksum와 restore/reconciliation report를 제출한다.

negative ACL/TLS test, canary PII scanner, metric alert route, failover/restart 가능한 범위, clean backup restore가 실행 evidence와 연결되면 기능 검증이다. 보안 효과성과 실제 incident 대응 성과는 독립 검토·drill 전까지 unverified다.

Q: TLS가 막지 못하는 세 가지 PII 경로는? Q: exporter에 +@all을 주면 안 되는 이유는? Q: test pass와 restore drill이 각각 증명하는 verification level은?