Docker로 Redis 배포하기 완벽 가이드: 영속성과 비밀번호 인증으로 데이터 손실 방지

마침내 Redis 컨테이너를 실행했습니다. 여러 인터페이스를 테스트해 보니 데이터 읽기와 쓰기도 정상입니다. 그런데 다음 날 컴퓨터를 켜고 서비스 상태를 확인하니 데이터가 모두 사라져 있었습니다. 눈앞이 캄캄해집니다.

여러분도 이런 일을 겪었을 수 있습니다. Docker 컨테이너를 재시작한 뒤 Redis의 데이터가 처음부터 없었던 것처럼 사라집니다. 사용자 로그인 상태도 없어지고, 장바구니는 비어 있으며, 캐시 데이터도 사라집니다. 더 큰 문제는 왜 이런 일이 생겼는지, 어떻게 해결해야 하는지 모른다는 것입니다.

솔직히 저도 처음 이 문제를 겪었을 때 당황했습니다. 작은 프로젝트였고 테스트 환경의 데이터가 갑자기 사라졌습니다. 운영 환경에는 영향이 없었지만, 아무것도 할 수 없다는 느낌이 무척 불편했습니다. 나중에야 컨테이너 자체가 본질적으로 ‘임시’라는 사실을 알게 되었습니다. 컨테이너를 삭제하면 데이터가 사라지고, 영속성을 설정하지 않은 상태에서 컨테이너를 재시작해도 데이터가 손실될 수 있습니다.

이 글에서는 다음 내용을 단계별로 설명합니다.

• RDB와 AOF 영속성 설정으로 컨테이너 재시작 때문에 Redis 데이터가 사라지지 않게 합니다.
• 비밀번호 인증 설정으로 Redis에 대한 무단 접근을 막습니다. 일부 기업의 Redis는 비밀번호가 없어 해커에게 침입당하고 채굴에 악용되기도 했습니다.
• 설정 파일 마운트로 Redis 배포를 표준화하고 유지보수하기 쉽게 만듭니다.
• 로그 확인, 상태 확인, 성능 최적화 등을 포함한 운영 환경 모범 사례를 알아봅니다.

백엔드 개발자나 운영 엔지니어는 물론 Docker를 처음 접하는 초보자도 이 글을 따라 한 번 실습하면 운영 수준의 Redis 컨테이너를 배포할 수 있습니다.

Redis 컨테이너에서 데이터가 사라지는 이유는 무엇인가요?

먼저 비유를 들어 보겠습니다. Docker 컨테이너는 호텔 객실과 같습니다. 체크아웃하면 방에 있던 물건이 모두 치워집니다. 컨테이너도 마찬가지입니다. 본질적으로 임시 환경이므로 컨테이너를 삭제하면 내부 데이터도 사라집니다.

Redis는 기본적으로 컨테이너 내부 파일 시스템에 데이터를 저장합니다. 컨테이너에서 데이터를 쓰면 Redis는 데이터를 /data/dump.rdb 또는 /data/appendonly.aof 같은 경로에 저장합니다. 문제는 이 경로들이 컨테이너 내부에 있다는 점입니다. 컨테이너를 삭제하거나 다시 생성하면 이 데이터도 함께 사라집니다.

실제 사례가 있습니다. 어느 스타트업의 개발자가 테스트 환경에서 Docker로 Redis를 배포하면서 영속성을 설정하지 않았습니다. 서버를 재시작하자 모든 사용자의 세션 데이터가 사라졌고, 로그인 상태가 초기화되었으며, 장바구니 데이터도 없어졌습니다. 테스트 환경이었지만 이 경험을 통해 팀은 컨테이너로 배포할 때 반드시 데이터 영속성을 고려해야 한다는 사실을 깨달았습니다.

통계에 따르면 Redis 컨테이너 데이터 손실 문제의 약 70%는 영구 저장소를 설정하지 않아서 발생합니다. 다시 말해 거의 모든 사람이 한 번쯤 빠지는 함정입니다.

Docker Volume의 역할

Volume(데이터 볼륨)은 이 문제를 해결하는 핵심입니다. 중요한 파일을 컴퓨터의 로컬 디스크가 아니라 클라우드 드라이브에 저장하는 것과 비슷합니다.

-v 매개변수로 호스트 디렉터리를 컨테이너에 마운트하면 데이터가 호스트에 저장됩니다. 컨테이너를 삭제해도 데이터는 남아 있고, 컨테이너를 재시작해도 계속 읽을 수 있습니다. 운영 환경에서 데이터 볼륨을 반드시 마운트해야 하는 이유입니다.

간단히 정리하면 다음과 같습니다.

• 데이터 볼륨을 마운트하지 않음 = 데이터가 컨테이너 내부에 존재 = 컨테이너를 삭제하면 데이터도 사라짐
• 데이터 볼륨을 마운트함 = 데이터가 호스트 디렉터리에 존재 = 컨테이너를 삭제해도 데이터가 유지됨

기본 Redis 컨테이너 빠르게 배포하기

영속성을 설명하기 전에 가장 간단한 Redis 컨테이너부터 배포해 보겠습니다. 그러면 ‘영속성이 없는 상태’가 어떤 것인지 직접 확인할 수 있습니다.

기본 컨테이너 시작하기

터미널을 열고 다음 명령을 실행합니다.

docker run -d --name redis-basic -p 6379:6379 redis:latest

각 옵션의 의미는 다음과 같습니다.

• -d: 백그라운드에서 실행합니다.
• --name redis-basic: 관리하기 편하도록 컨테이너에 이름을 지정합니다.
• -p 6379:6379: 컨테이너의 6379 포트를 호스트의 6379 포트에 매핑합니다.
• redis:latest: 최신 버전의 Redis 이미지를 사용합니다.

명령을 실행하면 로컬에 이미지가 없는 경우 Docker가 Redis 이미지를 자동으로 내려받고 컨테이너를 시작합니다.

컨테이너가 정상인지 확인하기

docker ps로 컨테이너 상태를 확인합니다.

docker ps

redis-basic의 상태가 Up으로 표시되면 컨테이너가 정상적으로 실행 중인 것입니다.

이제 컨테이너에 들어가 Redis에서 데이터를 읽고 쓸 수 있는지 테스트합니다.

docker exec -it redis-basic redis-cli

Redis 명령줄에 들어간 뒤 데이터를 하나 저장해 봅니다.

set test "hello"
get test

"hello"가 반환되면 Redis가 정상적으로 작동하는 것입니다.

이 기본 버전의 문제점

괜찮아 보이지 않나요? 하지만 치명적인 문제가 세 가지 있습니다.

1. 데이터가 영속되지 않음: 컨테이너를 재시작하면 데이터가 사라집니다.
2. 비밀번호 보호가 없음: 누구나 Redis에 연결해 데이터를 읽고 쓸 수 있습니다.
3. 기본 설정 사용: 메모리 제한과 영속성 정책 등을 사용자 정의할 수 없습니다.

컨테이너를 재시작하고 데이터가 사라지는지 직접 확인해 볼 수 있습니다.

docker restart redis-basic
docker exec -it redis-basic redis-cli
get test

앞서 저장한 test 키가 사라진 것을 확인할 가능성이 큽니다. 영속성을 설정하지 않은 결과입니다.

RDB 영속성 설정하기(스냅샷 방식)

Redis에는 RDB와 AOF라는 두 가지 영속성 방식이 있습니다. 먼저 비교적 간단해서 입문자에게 적합한 RDB부터 알아보겠습니다.

RDB란 무엇인가요?

RDB는 Redis Database의 약자로, ‘데이터베이스 스냅샷’을 뜻합니다. Redis의 메모리 데이터를 사진으로 찍는다고 생각하면 됩니다. Redis는 일정한 간격으로 현재의 모든 데이터를 dump.rdb 파일에 저장합니다.

장점은 복구 속도가 빠르다는 것이고, 단점은 마지막 스냅샷 이후의 데이터가 손실될 수 있다는 것입니다. 예를 들어 5분마다 스냅샷을 저장하도록 설정했다면 Redis 장애 시 최악의 경우 최근 5분 동안의 데이터가 사라질 수 있습니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

RDB 설정 매개변수

Redis의 RDB 영속성은 save 매개변수로 제어합니다. 형식은 다음과 같습니다.

save <초> <변경된 key 수>

예를 들면 다음과 같습니다.

• save 900 1: 900초(15분) 동안 최소 1개의 key가 변경되면 스냅샷을 저장합니다.
• save 300 10: 300초(5분) 동안 최소 10개의 key가 변경되면 스냅샷을 저장합니다.
• save 60 10000: 60초 동안 최소 10000개의 key가 변경되면 스냅샷을 저장합니다.

이 세 규칙은 ‘또는’ 관계이므로 하나만 충족해도 저장이 실행됩니다.

데이터 볼륨을 마운트해 영속성 구현하기

RDB를 설정하는 것만으로는 충분하지 않습니다. 호스트에 데이터 볼륨도 마운트해야 합니다. 그래야 컨테이너를 삭제해도 dump.rdb 파일이 호스트 디렉터리에 남아 있습니다.

먼저 데이터 디렉터리를 만듭니다.

mkdir -p ~/redis-data

그런 다음 데이터 볼륨을 사용하는 Redis 컨테이너를 시작합니다.

docker run -d \
  --name redis-rdb \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --save 60 1 --dir /data

핵심 옵션은 다음과 같습니다.

• -v ~/redis-data:/data: 호스트의 ~/redis-data 디렉터리를 컨테이너의 /data 디렉터리에 마운트합니다.
• --save 60 1: 60초 동안 최소 1개의 key가 변경되면 스냅샷을 저장합니다. 테스트용 설정이며 운영 환경에서는 간격을 늘릴 수 있습니다.
• --dir /data: RDB 파일의 저장 경로를 지정합니다.

영속성이 작동하는지 검증하기

컨테이너에 들어가 데이터를 몇 개 저장합니다.

docker exec -it redis-rdb redis-cli
set user:1 "张三"
set user:2 "李四"

Redis가 스냅샷을 저장하도록 60초를 기다린 뒤 컨테이너를 재시작합니다.

docker restart redis-rdb

컨테이너에 다시 들어가 데이터가 남아 있는지 확인합니다.

docker exec -it redis-rdb redis-cli
get user:1

"张三"이 반환되면 영속성 설정에 성공한 것입니다.

호스트의 ~/redis-data 디렉터리를 확인하면 dump.rdb 파일도 볼 수 있습니다. 이것이 Redis의 스냅샷 파일입니다.

AOF 영속성 설정하기(로그 추가 방식)

RDB는 간단하지만 마지막 스냅샷 이후의 데이터가 손실될 수 있다는 단점이 있습니다. 비즈니스에서 데이터 안전성이 중요하다면 AOF를 사용해야 합니다.

AOF란 무엇인가요?

AOF는 Append Only File의 약자로, ‘추가 전용 로그 파일’을 뜻합니다. Redis에서 쓰기 작업(set, del, incr 등)이 실행될 때마다 해당 명령을 appendonly.aof 파일 끝에 추가하는 방식입니다.

비유하면 RDB는 사진 촬영이고 AOF는 영상 촬영입니다. RDB는 일정한 간격으로 사진을 한 장씩 찍지만 AOF는 모든 동작을 실시간으로 기록합니다.

장점은 데이터 안전성이 더 높다는 것입니다. everysec 정책을 사용하면 최대 1초 분량의 데이터만 손실됩니다. 단점은 파일 크기가 RDB보다 크고 복구 속도가 조금 느리다는 점입니다.

AOF의 세 가지 동기화 정책

AOF에는 안전성과 성능 사이의 균형이 서로 다른 세 가지 동기화 정책이 있습니다.

1. appendfsync always: 쓰기 작업마다 즉시 디스크와 동기화합니다.

   • 가장 안전하며 데이터가 거의 손실되지 않습니다.
   • 성능이 가장 낮아 동시 요청이 많은 환경에는 적합하지 않습니다.

2. appendfsync everysec: 1초마다 동기화합니다(권장).

   • 성능과 안전성의 균형이 좋습니다.
   • 최대 1초 분량의 데이터가 손실될 수 있습니다.
   • 운영 환경에서는 이 방식을 권장합니다.

3. appendfsync no: 운영체제가 동기화 시점을 결정합니다.

   • 성능이 가장 높습니다.
   • 더 많은 데이터가 손실될 수 있으므로 권장하지 않습니다.

AOF 영속성을 사용하는 Redis 시작하기

앞에서와 마찬가지로 먼저 데이터 디렉터리가 있는지 확인합니다.

mkdir -p ~/redis-data

컨테이너를 시작합니다.

docker run -d \
  --name redis-aof \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --appendonly yes --appendfsync everysec --dir /data

핵심 매개변수는 다음과 같습니다.

• --appendonly yes: AOF 영속성을 활성화합니다.
• --appendfsync everysec: 1초마다 동기화합니다.
• --dir /data: 데이터 디렉터리를 지정합니다.

잠시 뒤 데이터 디렉터리를 확인하면 appendonly.aof 파일이 생성된 것을 볼 수 있습니다.

ls ~/redis-data/

혼합 영속성(Redis 4.0 이상에서 권장)

Redis 4.0부터는 RDB와 AOF의 장점을 결합한 혼합 영속성 모드를 공식적으로 권장합니다.

• RDB는 빠른 복구를 담당합니다.
• AOF는 데이터 안전성을 담당합니다.

활성화하려면 설정 파일에 다음 한 줄을 추가합니다.

aof-use-rdb-preamble yes

혼합 영속성의 장점은 Redis를 재시작할 때 먼저 RDB 스냅샷을 불러와 빠르게 복구한 뒤, RDB 이후에 기록된 AOF 로그의 증분 데이터를 재생해 데이터의 완전성을 보장한다는 점입니다.

솔직히 Redis 4.0 이상을 사용한다면 RDB와 AOF 중 무엇을 고를지 고민하기보다 바로 혼합 영속성을 사용하는 편이 좋습니다.

설정 파일로 Redis 관리하기(운영 환경 권장)

앞에서는 --appendonly yes --appendfsync everysec처럼 명령줄 매개변수로 Redis를 설정했습니다. 하지만 매개변수가 많아지면 명령이 너무 길어지고 읽기 어려우며 유지보수도 힘들어집니다.

운영 환경에서는 일반적으로 설정 파일로 Redis를 관리합니다.

설정 파일을 사용해야 하는 이유

설정 파일에는 다음과 같은 장점이 있습니다.

• 모든 설정을 한곳에서 관리하므로 한눈에 파악할 수 있습니다.
• Git에 저장해 버전 관리하기 쉽습니다.
• 팀원이 같은 설정을 공유할 수 있습니다.
• 설정을 변경할 때마다 명령을 다시 입력할 필요가 없습니다.

Redis를 장기간 실행할 예정이라면 번거롭더라도 설정 파일을 사용하는 것이 좋습니다.

표준 설정 파일 가져오기

Redis 공식 표준 설정 파일을 Docker 컨테이너에서 복사할 수 있습니다.

mkdir -p ~/redis-config
docker run --rm redis:latest cat /etc/redis/redis.conf > ~/redis-config/redis.conf

이 명령은 Redis의 기본 설정 파일을 ~/redis-config/redis.conf에 저장합니다.

설정 파일 사용자 정의하기

텍스트 편집기로 redis.conf를 열고 다음 설정을 찾아 수정합니다.

1. 네트워크 설정

# 모든 IP의 연결 허용(운영 환경에서는 내부 IP로 변경 권장)
bind 0.0.0.0

# 보호 모드 비활성화(비밀번호 활성화 후 비활성화 가능)
protected-mode no

2. 비밀번호 인증

# 접속 비밀번호 설정
requirepass YourStrongPassword123

3. 영속성 설정

# RDB 영속성
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

# AOF 영속성
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# 혼합 영속성(Redis 4.0 이상)
aof-use-rdb-preamble yes

# 데이터 디렉터리
dir /data

4. 최대 메모리 설정

# 최대 메모리를 512MB로 제한
maxmemory 512mb

# 메모리 제거 정책: 가장 최근에 적게 사용된 key 삭제
maxmemory-policy allkeys-lru

5. 로그 설정

# 로그 수준: debug, verbose, notice, warning
loglevel notice

# 로그 파일 경로(빈 문자열이면 표준 출력으로 전송)
logfile ""

설정 파일로 컨테이너 시작하기

설정 파일 수정이 끝나면 -v 매개변수로 컨테이너에 마운트합니다.

docker run -d \
  --name redis-prod \
  -p 6379:6379 \
  -v ~/redis-config/redis.conf:/usr/local/etc/redis/redis.conf \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

마지막의 redis-server /usr/local/etc/redis/redis.conf는 지정한 설정 파일로 Redis를 시작하라는 의미입니다.

설정이 적용되었는지 검증하기

컨테이너에 들어가 설정을 확인합니다.

docker exec -it redis-prod redis-cli -a YourStrongPassword123
config get save
config get appendonly
config get maxmemory

반환된 값이 설정 파일에 작성한 내용과 같으면 설정이 적용된 것입니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

Redis 비밀번호 인증 설정하기(3가지 방법)

실제로 어느 회사는 Redis에 비밀번호를 설정하지 않은 채 인터넷에 직접 노출했습니다. 결국 해커에게 침입당해 서버가 채굴 장비로 악용되었습니다. 농담이 아니라 실제로 발생한 사례입니다.

반드시 비밀번호를 설정해야 하는 이유

Redis는 기본적으로 비밀번호가 없어 누구나 연결해 데이터를 읽고 쓸 수 있습니다. Redis 포트가 인터넷에 노출되어 있거나 회사 내부 네트워크를 신뢰할 수 없다면 비밀번호를 설정하지 않는 것은 아무런 보호 없이 운영하는 것과 같습니다.

운영 환경에서는 반드시 비밀번호를 설정해야 합니다. 이는 최소한의 보안 기준입니다.

방법 1: 명령줄 매개변수로 비밀번호 설정하기

가장 간단한 방법은 컨테이너를 시작할 때 --requirepass 매개변수를 추가하는 것입니다.

docker run -d \
  --name redis-pwd \
  -p 6379:6379 \
  redis:latest \
  redis-server --requirepass "MyStr0ng#P@ssw0rd"

빠른 테스트에는 적합하지만 비밀번호가 명령줄 기록에 노출되므로 운영 환경에는 적합하지 않습니다.

방법 2: 설정 파일에 비밀번호 설정하기(권장)

redis.conf에 다음 한 줄을 추가합니다.

requirepass YourStrongPassword123

그런 다음 앞에서 설명한 방법대로 설정 파일을 마운트해 컨테이너를 시작합니다.

운영 환경의 표준 방식입니다. 비밀번호가 명령줄 기록에 노출되지 않고 팀에서 관리하기도 쉽습니다.

권장하는 비밀번호 복잡도는 다음과 같습니다.

• 16자 이상
• 대문자, 소문자, 숫자, 특수 문자 포함
• 흔한 단어나 생일을 사용하지 않음

방법 3: 실행 중인 컨테이너에서 동적으로 설정하기

컨테이너가 이미 실행 중이고 비밀번호를 임시로 변경해야 한다면 컨테이너에 들어가 다음 명령을 실행합니다.

docker exec -it redis-pwd redis-cli
config set requirepass "NewPassword123"

이 방법은 재시작하면 설정이 사라지므로 긴급 상황의 임시 변경에만 적합하며 장기간 사용할 수는 없습니다.

비밀번호로 Redis에 연결하기

비밀번호를 설정한 뒤 Redis에 연결하는 방법은 두 가지입니다.

방법 1: 명령줄에서 비밀번호를 직접 전달하기

docker exec -it redis-pwd redis-cli -a "MyStr0ng#P@ssw0rd"

방법 2: 먼저 연결한 뒤 인증하기

docker exec -it redis-pwd redis-cli
auth MyStr0ng#P@ssw0rd
set test "hello"

비밀번호가 틀리면 다음 오류가 발생합니다.

(error) NOAUTH Authentication required.

이때 auth 명령으로 다시 인증하면 됩니다.

애플리케이션 연결 설정

애플리케이션에서 Redis에 연결하려면 연결 문자열에 비밀번호를 추가해야 합니다.

redis://:YourStrongPassword123@localhost:6379

또는 코드에서 설정합니다.

// Node.js 예제
const redis = require('redis');
const client = redis.createClient({
  host: 'localhost',
  port: 6379,
  password: 'YourStrongPassword123'
});

Docker Compose로 배포하기(팀 협업에 권장)

앞에서는 모두 docker run 명령으로 컨테이너를 시작했습니다. 하지만 명령이 너무 길고 매번 다시 입력해야 한다는 단점이 있습니다.

팀에서 작업하거나 여러 컨테이너를 관리해야 한다면 Docker Compose가 더 좋은 선택입니다.

Docker Compose를 사용하는 이유

Docker Compose의 장점은 다음과 같습니다.

• 설정을 docker-compose.yml 파일에 작성해 버전 관리할 수 있습니다.
• 복잡한 명령을 기억하지 않아도 한 번에 시작할 수 있습니다.
• 팀원이 같은 설정을 사용하므로 환경이 일관됩니다.
• Redis + MySQL + Nginx처럼 여러 컨테이너를 관리하기 쉽습니다.

전체 docker-compose.yml 설정

docker-compose.yml 파일을 만듭니다.

version: '3.8'

services:
  redis:
    image: redis:7.2-alpine
    container_name: redis-prod
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis-config/redis.conf:/usr/local/etc/redis/redis.conf
      - ./redis-data:/data
    command: redis-server /usr/local/etc/redis/redis.conf
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  redis-data:
    driver: local

핵심 설정은 다음과 같습니다.

• image: redis:7.2-alpine: 가벼운 Alpine 버전을 사용합니다.
• restart: always: 컨테이너가 중단되면 자동으로 재시작합니다.
• volumes: 설정 파일과 데이터 디렉터리를 마운트합니다.
• healthcheck: 10초마다 Redis가 정상인지 확인합니다.

한 번에 시작하기

설정 파일을 준비한 뒤 같은 디렉터리에서 다음 명령을 실행합니다.

docker-compose up -d

-d는 백그라운드 실행을 의미합니다. Docker Compose가 네트워크를 생성하고 데이터 볼륨을 마운트한 뒤 컨테이너를 자동으로 시작합니다.

실행 상태 확인하기

docker-compose ps

로그 확인하기

docker-compose logs -f redis

-f는 tail -f처럼 로그를 계속 출력한다는 의미입니다.

컨테이너 중지하기

docker-compose down

이 명령은 컨테이너를 중지하고 삭제하지만 데이터 볼륨은 삭제하지 않으므로 데이터는 남아 있습니다.

컨테이너 재시작하기

docker-compose restart redis

설정 확장하기

프로젝트에 다른 서비스가 있다면 같은 docker-compose.yml에서 함께 관리할 수 있습니다.

version: '3.8'

services:
  redis:
    # Redis 설정...

  mysql:
    image: mysql:8.0
    # MySQL 설정...

  app:
    build: .
    # 애플리케이션 설정...
    depends_on:
      - redis
      - mysql

이렇게 하면 프로젝트를 시작할 때 Redis, MySQL, 애플리케이션이 함께 실행되고 의존 관계도 자동으로 처리됩니다.

자주 발생하는 문제 해결과 모범 사례

Redis 컨테이너를 실행한 뒤에도 다양한 문제를 만날 수 있습니다. 이 절에서는 자주 발생하는 문제를 해결하는 방법과 운영 환경의 모범 사례를 설명합니다.

Redis 로그 확인하기

문제가 생기면 가장 먼저 로그를 확인해야 합니다.

최근 로그 100줄을 확인합니다.

docker logs --tail 100 redis-prod

tail -f처럼 로그를 계속 출력합니다.

docker logs -f redis-prod

Docker Compose를 사용한다면 다음 명령을 실행합니다.

docker-compose logs -f redis

로그를 보면 컨테이너가 정상적으로 시작되었는지, 설정 파일에 오류가 있는지, 비정상적인 연결이 있었는지 등을 파악할 수 있습니다.

컨테이너 상태 확인

상태 확인을 사용하면 Docker가 Redis의 정상 작동 여부를 자동으로 검사하고, 이상이 있으면 자동으로 재시작할 수 있습니다.

docker-compose.yml에 다음 내용을 추가합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 3s
  retries: 3

10초마다 redis-cli ping을 실행하고, 연속 3회 실패하면 컨테이너를 비정상 상태로 표시한다는 뜻입니다.

restart: always도 설정되어 있으면 비정상 상태의 컨테이너가 자동으로 재시작됩니다.

성능 최적화 권장 사항

1. 최대 메모리 제한하기

Redis는 기본적으로 사용 가능한 메모리를 모두 사용하므로 운영 환경에서는 반드시 제한해야 합니다.

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru는 메모리가 가득 차면 가장 최근에 적게 사용된 key를 삭제한다는 의미입니다.

2. 위험한 명령 비활성화하기

운영 환경에서 위험한 명령이 있습니다.

• FLUSHALL: 모든 데이터를 삭제합니다.
• FLUSHDB: 현재 데이터베이스를 비웁니다.
• KEYS *: 모든 key를 나열하며 Redis를 차단할 수 있습니다.

설정 파일에서 다음 명령을 비활성화할 수 있습니다.

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""

3. 영속성 빈도 조정하기

쓰기 작업이 특히 많다면 RDB 스냅샷 간격을 적절히 늘릴 수 있습니다.

save 900 1
save 300 10
save 60 10000

이는 대부분의 환경에 적합한 기본 설정입니다. Redis를 주로 캐시로 사용하고 데이터 손실에 민감하지 않다면 간격을 더 느슨하게 조정할 수 있습니다.

보안 강화 권장 사항

1. 인터넷에 직접 노출하지 않기

Redis를 인터넷에 직접 노출해서는 안 됩니다. 원격 접근이 꼭 필요하다면 SSH 터널이나 VPN을 사용합니다.

설정 파일에서 내부 IP를 바인딩합니다.

bind 127.0.0.1 192.168.1.100

2. 강력한 비밀번호 사용하기

비밀번호는 16자 이상이며 대문자, 소문자, 숫자, 특수 문자를 포함해야 합니다.

requirepass Th1s!sA$tr0ngP@ssw0rd2024

3. 데이터 정기 백업하기

영속성을 설정했더라도 정기적으로 백업해야 합니다. 예약 스크립트를 만들어 매일 새벽 dump.rdb와 appendonly.aof를 백업 디렉터리에 복사합니다.

#!/bin/bash
DATE=$(date +%Y%m%d)
cp ~/redis-data/dump.rdb ~/redis-backup/dump-$DATE.rdb
cp ~/redis-data/appendonly.aof ~/redis-backup/appendonly-$DATE.aof

운영 환경 체크리스트

Redis를 배포하기 전에 다음 체크리스트를 확인합니다.

• ✅ 영속성을 설정했는가(RDB+AOF 혼합 모드 권장)
• ✅ 비밀번호 인증을 활성화했는가
• ✅ 데이터 볼륨을 호스트 디렉터리에 마운트했는가
• ✅ 설정 파일을 사용자 정의했는가(기본 설정을 그대로 사용하지 않기)
• ✅ 로그를 정상적으로 확인할 수 있는가
• ✅ 상태 확인을 설정했는가
• ✅ 최대 메모리를 제한했는가
• ✅ 위험한 명령을 비활성화하거나 이름을 변경했는가
• ✅ 정기 백업 전략을 마련했는가
• ✅ 인터넷에 직접 노출하지 않았는가(또는 VPN/SSH 터널 사용)

Redis 성능 모니터링하기

컨테이너에 들어가 메모리 사용량을 확인합니다.

docker exec -it redis-prod redis-cli -a your_password
info memory

영속성 상태를 확인합니다.

info persistence

연결 수를 확인합니다.

info clients

이 글을 여기까지 따라 했다면 이제 운영 수준의 Redis 컨테이너를 성공적으로 배포했을 것입니다. 데이터가 영속되고 비밀번호 인증이 적용되었으며 설정도 표준화되었습니다.

결론

처음의 상황으로 돌아가 보겠습니다. 금요일 저녁에 Redis를 배포했는데 월요일 아침에 데이터가 모두 사라졌습니다. 이제 그 이유를 알고 있습니다. 영속성을 설정하지 않아 데이터가 컨테이너 내부에만 존재했고, 재시작하자 사라진 것입니다.

이 글에서는 다음과 같은 전체 해결 방법을 살펴봤습니다.

• RDB 스냅샷 영속성: 데이터를 주기적으로 저장하고 복구가 빠르며 백업에 적합합니다.
• AOF 로그 영속성: 쓰기 작업을 실시간으로 기록해 데이터 안전성이 높고 최대 1초 분량만 손실됩니다.
• 혼합 영속성(권장): RDB와 AOF의 장점을 결합해 빠른 복구와 데이터 안전성을 모두 제공합니다.
• 비밀번호 인증: 세 가지 설정 방법이 있으며 운영 환경에서는 반드시 활성화해야 합니다.
• 설정 파일 관리: 배포를 표준화하고 유지보수와 팀 협업을 쉽게 만듭니다.
• Docker Compose: 한 번에 시작할 수 있으며 설정을 코드로 관리합니다.

지금 Docker Redis를 사용하고 있다면 바로 다음 항목을 확인해 보세요.

1. 데이터 볼륨을 마운트했나요?(-v ~/redis-data:/data)
2. 영속성을 활성화했나요?(RDB, AOF 또는 혼합 모드)
3. 비밀번호를 설정했나요?(requirepass)
4. 설정 파일을 사용자 정의했나요?(기본 설정을 그대로 사용하지 마세요.)

운영 환경에서 Redis를 배포할 때 이 네 가지는 반드시 지켜야 할 기본 원칙입니다. 이를 적용하면 데이터 손실이나 무단 접근을 걱정하지 않아도 됩니다.

마지막으로 이 글을 저장해 두었다가 다음 Redis 배포 때 참고해 보세요. 팀에서도 Docker로 Redis를 배포하고 있다면 이 글을 공유해 배포 규칙을 통일하고 시행착오를 줄일 수 있습니다.

참고로 이 글의 설정은 모두 Redis 7.x 버전을 기준으로 합니다. 다른 버전을 사용한다면 Redis 공식 문서를 확인해 설정 항목이 달라졌는지 검토하세요.