📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code 멀티 에이전트 — Teams
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🗄️database/ redis

Redis 영속성과 클러스터

약 2분
2026년 3월 24일
GitHub에서 보기

Redis 영속성과 클러스터

데이터 영속성 — AOF와 RDB 스냅샷

Redis는 인메모리 저장소라 프로세스가 재시작되면 기본적으로 데이터가 사라진다. 이를 방지하기 위해 두 가지 영속성(Persistence) 옵션을 제공한다.

RDB 스냅샷 (Redis Database)

특정 시점(Point-in-Time)의 전체 데이터를 바이너리 파일(.rdb)로 저장한다.

  • SAVE 900 1 — 900초 안에 1건 이상 변경되면 스냅샷 저장
  • BGSAVE 명령으로 자식 프로세스를 fork해서 비동기로 저장하기 때문에 메인 스레드를 막지 않는다.
  • 파일 크기가 작고 복구가 빠르다. 단, 마지막 스냅샷 이후의 쓰기는 유실된다.

AOF (Append Only File)

모든 쓰기 명령(SET, XADD, JSON.SET 등)을 로그 파일(.aof)에 순서대로 기록한다. 재시작 시 로그를 처음부터 재실행해서 복구한다.

  • appendfsync always — 매 명령마다 디스크 동기화. 가장 안전하지만 느림.
  • appendfsync everysec — 1초마다 동기화. 성능과 안전의 균형. 최대 1초치 유실.
  • appendfsync no — OS에 맡김. 가장 빠르지만 유실 위험.
  • 파일이 점점 커지기 때문에 주기적으로 BGREWRITEAOF로 압축(rewrite)해야 한다.

두 방식을 함께 쓰는 이유

RDBAOF
데이터 유실스냅샷 주기만큼최대 1초 (everysec 기준)
복구 속도빠름느림 (명령 재실행)
파일 크기작음커질 수 있음
손상 위험낮음파일 손상 가능

두 방식을 함께 활성화하면 Redis는 재시작 시 AOF로 복구(더 최신 상태)하고, AOF가 손상됐을 때 RDB를 백업으로 사용한다. 거래 주문, 결제처럼 유실이 허용되지 않는 데이터에는 이 이중 구성이 적합하다.


Redis 클러스터 (Cluster)

단일 Redis 인스턴스는 메모리 한계와 단일 장애점(SPOF) 문제가 있다. Redis Cluster는 이를 해결하기 위한 공식 분산 구성이다.

슬롯 기반 데이터 분산

클러스터는 키 공간을 16,384개의 해시 슬롯으로 나눈다. 키가 들어오면 CRC16(key) % 16384로 슬롯을 결정하고, 해당 슬롯을 담당하는 노드로 라우팅한다.

노드 A: 슬롯 0 ~ 5460
노드 B: 슬롯 5461 ~ 10922
노드 C: 슬롯 10923 ~ 16383

레플리카와 자동 장애 복구

각 마스터 노드에 레플리카를 둔다. 마스터가 응답하지 않으면 레플리카가 자동으로 마스터로 승격(Failover)되어 서비스가 중단되지 않는다.

해시 태그 (Hash Tag)

여러 키를 같은 노드에 배치하고 싶을 때 {} 해시 태그를 사용한다. {user:1}:orders와 {user:1}:profile은 user:1 부분만 슬롯 계산에 사용되어 같은 노드에 저장된다. 트랜잭션(MULTI/EXEC)이나 다중 키 명령(MGET)은 같은 슬롯의 키에만 사용할 수 있기 때문에 키 설계 시 반드시 고려해야 한다.

database 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • Redis 영속성과 클러스터
  • 데이터 영속성 — AOF와 RDB 스냅샷
  • RDB 스냅샷 (Redis Database)
  • AOF (Append Only File)
  • 두 방식을 함께 쓰는 이유
  • Redis 클러스터 (Cluster)
  • 슬롯 기반 데이터 분산
  • 레플리카와 자동 장애 복구
  • 해시 태그 (Hash Tag)