[NHN FORWARD 2021] Redis 야무지게 사용하기

NHN Cloud·nhn-forward-2021 ·2021년·

#high-availability#performance#redis#persistence#caching#data-structures

AI 요약

Redis를 cache·counter·queue·log 저장소로 쓸 때의 데이터 패턴부터 persistence·HA 아키텍처 선택, 그리고 single-thread 특성에서 오는 운영 장애 지점까지 폭넓게 정리한다. 각 접근 방식의 트레이드오프를 짚어 상황에 맞는 선택 기준을 제시한다.

핵심 포인트

접근 패턴별로 Look-aside(miss 시 DB 조회, 사전 warming 필요), write-around(cache-DB 불일치 가능), write-through(일관성 보장하나 매 write 비용)를 expire time과 함께 설계
자료구조 선택: 단순 count는 INCR, 연속 정수 방문 여부는 Bitmap, 대규모 cardinality는 고정 12KB HyperLogLog, polling 없는 queue는 List blocking pop, 소규모 log·broker는 append-only Stream
persistence는 RDB(작고 빠른 복구, 최근 변경 손실)와 AOF(높은 내구성, rewrite 필요)를 손실 허용 범위로 선택. HA는 replication→Sentinel 자동 failover→Cluster shard 순으로 판단. KEYS→SCAN, DEL→UNLINK, allkeys-LRU와 fork copy-on-write 대비 maxmemory를 물리 메모리 절반으로

왜 읽나Redis를 단순 캐시를 넘어 운영하는 개발자에게 자료구조·persistence·HA·장애 예방을 한 번에 훑는 실전 체크리스트.

챕터별 상세

010:10 – 5:35

Cache access pattern과 warming

반복 조회되고 자주 변하지 않는 data에 Redis를 적용해야 cache가 의미 있음을 짚는다. Look-aside는 miss 때 DB에서 읽어 채워 Redis 장애에도 원본을 쓸 수 있지만 DB 부하가 급증할 수 있어 사전 warming이 필요하다. Write-around는 DB와 cache가 달라질 수 있고 write-through는 일관성을 지키지만 매 write 비용과 미사용 data 낭비가 있으므로 expire time을 함께 설계한다.

단순 count는 INCR, 연속 정수 ID의 방문 여부는 Bitmap, 복원할 필요 없는 대규모 cardinality는 고정 12KB의 HyperLogLog로 처리한다. List의 blocking pop은 polling 없는 queue를 만들고 RPUSHX는 실제 사용 중인 timeline만 미리 채우게 한다. Append-only Stream은 시간 기반 ID·tail 방식 구독·consumer group을 제공해 작은 규모의 log와 message broker에 활용할 수 있다.

Memory data는 재시작과 사람의 실수로 사라지고 복제본도 잘못된 명령을 그대로 반영하므로 cache 외 용도에는 별도 backup이 필요하다. RDB는 특정 시점 snapshot이라 작고 복구가 빠르지만 최근 변경을 잃을 수 있고, AOF는 모든 변경 command를 남겨 내구성이 높지만 file이 커져 rewrite가 필요하다. 손실 허용 범위에 따라 RDB, 매초 fsync AOF, 또는 둘을 함께 선택한다.

단순 replication은 master 장애 때 replica 승격과 application endpoint 변경을 수동으로 해야 한다. Sentinel은 홀수 개 monitor가 master failure를 감지해 자동 failover하고 client에게 새 master를 알려준다. Cluster는 최소 3개 master에 data를 shard하고 각 node가 서로 감시한다. 자동 복구가 필요한지, scale-out sharding까지 필요한지를 차례로 물어 standalone·replication·Sentinel·Cluster를 고르는 기준을 제시한다.

전체를 막는 KEYS는 SCAN으로, 큰 key의 DEL은 background UNLINK로 바꾸고 한 key에 지나치게 많은 item을 넣지 않는다. noeviction 대신 workload에 맞는 allkeys-LRU와 넉넉한 TTL을 써 cache stampede를 줄인다. RDB fork와 replication 초기화 때 copy-on-write로 memory가 두 배까지 늘 수 있어 maxmemory를 물리 memory 절반 수준으로 잡고, used_memory_rss와 fragmentation을 관찰해 필요할 때 active defrag를 켠다.