살면서 도플갱어를 만난다면 죽는다는 무서운 말이 있지만,,
Redis는 도플갱어를 만나도 죽지 않습니다,,
나와 동일한 또 다른 나,,?
오히려 좋아,,🍀
replication의 개념과 docker-compose를 이용한 replica 생성 방법까지 간단히 정리해 보고자 합니다.
1. Replication의 정의
At the base of Redis replication (excluding the high availability features provided as an additional layer by Redis Cluster or Redis Sentinel) there is a leader follower (master-replica) replication that is simple to use and configure.
It allows replica Redis instances to be exact copies of master instances.
The replica will automatically reconnect to the master every time the link breaks, and will attempt to be an exact copy of it regardless of what happens to the master.
Redis 복제의 기본(Redis Cluster 또는 Redis Sentinel에서 추가 계층으로 제공하는 고가용성 기능 제외)에는 사용 및 구성이 간단한 리더 팔로워(마스터-복제본) 복제가 있습니다.
이를 통해 복제 Redis 인스턴스는 마스터 인스턴스의 정확한 복사본이 될 수 있습니다.
복제본은 링크가 끊어질 때마다 자동으로 마스터에 다시 연결되며, 마스터에 어떤 일이 발생하더라도 마스터의 정확한 복사본이 되려고 시도합니다.
2. 왜 Replication이 필요한가
안정성
Replication을 사용하면 마스터 서버에서 발생한 데이터 변경이 슬레이브 서버로 자동으로 복제됩니다. 이는 데이터 손실을 방지하고, 마스터 서버가 장애를 겪었을 때 슬레이브 서버를 통해 데이터가 유지될 수 있도록 합니다.
가용성
Redis의 Replication을 통해 여러 서버에 데이터를 복제함으로써, 마스터 서버가 다운되더라도 슬레이브 서버를 통해 읽기 작업을 처리할 수 있습니다.
읽기 부하 분산
마스터 서버에 대한 읽기 요청을 슬레이브 서버로 분산시킬 수 있습니다. 여러 개의 슬레이브 서버를 운영하여 읽기 부하를 분산시킴으로써 성능을 개선할 수 있습니다. 이를 통해 대규모 트래픽을 처리할 수도 있습니다.
3. Dokcer-Compose 파일 준비!
networks: #네트워크 설정으로, 서비스 간 통신을 가능하게 함
replica: #네트워크 이름
driver: bridge #네트워크 드라이버로 bridge를 사용, 같은 호스트 내에서 여러 컨테이너가 서로 통신할 수 있도록 설정
services: #services 아래에 실행할 컨테이너를 정의
redis: #service 이름
container_name: redis #container 이름
image: redis:6.2 #docker hub 내 이미지(repository:verson_tag)
ports: #port 매핑(호스트 6379 포트:컨테이너 6379 포트)
- 6379:6379
networks:
- replica
#연결할 네트워크
#docker-compose.yml에서 networks를 정의하고, 각 컨테이너가 이를 사용하도록 설정하면 같은 네트워크를 공유하는 컨테이너끼리 이름(container_name)을 통해 접근할 수 있음
#예: redis://redis:6379
restart: always #컨테이너 중단 시, 동작 설정
imreplica:
container_name: imreplica
image: redis:6.2
ports:
- 6378:6379
#동일한 호스트에서 여러 개의 Redis 인스턴스를 실행하려면 각 인스턴스가 사용하는 포트를 다르게 설정해야 함
networks:
- replica
volumes:
#호스트(내 컴퓨터)와 Docker 컨테이너의 특정 폴더를 연결하는 설정
#컨테이너 내부에서 생성된 파일이 호스트에 저장되거나, 호스트의 파일이 컨테이너에서 사용될 수 있게 됨
#데이터를 영구적으로 저장하거나 공유하기 위해 사용
#volumes를 통해 데이터를 외부(호스트)에 저장하면 컨테이너를 삭제해도 데이터가 보존
- ./conf:/usr/local/etc/redis/
command: redis-server /usr/local/etc/redis/redis.conf
#컨테이너가 실행될 때 수행할 명령어
#redis-server: Redis Server 실행
#Redis 서버는 기본적으로 설정 파일인 redis.conf를 통해 설정을 읽고 실행
restart: always
imduplica:
container_name: imduplica
image: redis:6.2
ports:
- 6377:6379
networks:
- replica
volumes:
- ./conf:/usr/local/etc/redis/
command: redis-server /usr/local/etc/redis/redis.conf
restart: always
언제 그 기술이 익숙해졌다는 생각이 드시나요,,☺️
전 강의와 다르게 이름을 지을 때 입니다,,☺️
imreplica,,🤖 imduplica,,🤖
❓순간 왜 로컬 포트를 도커에 연결하고 있나,,라는 생각이 들 때, 읽어보면 좋은 글
Docker 컨테이너에 호스트 포트를 연결하는 이유는 외부 시스템(클라이언트나 다른 서버 등)이 컨테이너 내부의 서비스에 접근할 수 있게 만들기 위함입니다.
Docker는 컨테이너화된 애플리케이션을 실행하는 환경으로, 기본적으로 컨테이너는 호스트 시스템과 격리된 네트워크를 사용합니다.
따라서 호스트 포트를 연결해야만 호스트 시스템 외부에서 컨테이너의 서비스를 이용할 수 있습니다.
4. Replication을 위한 conf 파일 준비!
replicaof redis 6379
#Redis의 복제(replication) 기능을 설정
#replicaof: 현재 Redis 인스턴스를 복제본(replica)으로 설정하는데 사용
#지정된 마스터 Redis 서버에서 데이터를 복제하도록 설정
#redis: 복제할 마스터 Redis 서버의 서비스 이름(호스트명 또는 IP 주소)
#6379: 마스터 Redis 서버가 사용하는 포트 번호
🚨 [대기열 시스템] Docker Compose로 Grafana와 Prometheus로 모니터링 시스템 구축하기
이 때는 분명됐는데, 이번부터는 docker-compose.yml 파일에 version을 추가하면 오류는 아니고, 경고가 발생합니다,,🚨
the attribute `version` is obsolete,
it will be ignored,
please remove it to avoid potential confusion
top-level에서 version을 지정하는 환경이 obsolete되었기에 이제는 쓰지 않길 원한다는 것입니다.
version을 제거하면 경고 문구 없이 잘 동작합니다.
➕ Deprecated와 Obsolete
Deprecated
- 여전히 작동하며 당분간 지원 대상이나 향후 지원이 중단될 예정
Obsolete
- 더 이상 지원되지 않거나 사용되지 않으며, 대체 기술이나 방법으로 완전히 전환된 상태
5. Replication 테스트!
# 원본(Master) 인스턴스
docker-compose exec redis redis-cli
info replication
# Replication
# role:master, 현재 Redis 인스턴스의 역할
# connected_slaves:2, 현재 이 마스터 Redis 인스턴스와 연결된 슬레이브(복제본) 인스턴스의 수
# slave0:ip=172.18.0.3,port=6379,state=online,offset=941,lag=0
# offset: 마스터와 슬레이브 간 동기화 상태를 나타내는 데이터의 위치
# 마스터와 슬레이브의 오프셋이 같으면 동기화가 완료된 상태
# lag: 슬레이브가 마스터와 동기화할 때의 지연 시간
# slave1:ip=172.18.0.2,port=6379,state=online,offset=941,lag=0
# master_failover_state:no-failover
# 마스터가 장애가 발생했을 때 슬레이브 중 하나를 새로운 마스터로 승격시키는 과정
set key1 1
# 복제본에서도 실시간으로 데이터 확인 가능
# 복제본(Slave, imreplica&imduplica) 인스턴스
docker-compose exec imreplica redis-cli
set key1 1
# READONLY You can't write against a read only replica.
💡 Master Redis 인스턴스 Stop 후, Start할 경우,
- 기존 마스터가 중단된 후, 슬레이브 중 하나가 failover로 인해 마스터로 승격
- 기존 마스터를 다시 시작해도, 기존 마스터는 슬레이브 역할로 동작하며 데이터 일관성을 유지
- Master를 대리했던 인스턴스가 새로운 정보를 Write 했을 가능성이 존재
# Stop 전
# Replication
role:master
connected_slaves:2
slave0:ip=172.18.0.3,port=6379,state=online,offset=1000,lag=0
slave1:ip=172.18.0.2,port=6379,state=online,offset=1000,lag=0
# Stop 후, Start 시
# Replication
role:slave
master_host:172.18.0.3
master_port:6379
master_link_status:up
slave_repl_offset:0
📑
참고 자료
Chat GPT
https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
https://teveloper.tistory.com/82
https://fastcampus.co.kr/dev_online_traffic_data
'MinimiProject > 아이돌 티켓팅 접속자 대기열 시스템' 카테고리의 다른 글
[대기열 시스템] MVC vs Webflux - JMeter를 이용한 부하테스트 (1) | 2025.02.02 |
---|---|
[대기열 시스템] R2DBC와 Custom Query (0) | 2025.01.31 |
[대기열 시스템] Docker Compose로 Grafana와 Prometheus로 모니터링 시스템 구축하기 (0) | 2025.01.26 |
[대기열 시스템] RedisTemplate, RedisHash, @Cacheable (1) | 2025.01.25 |
[대기열 시스템] HTTP load testing tool, Vegeta 설치(Window) (0) | 2025.01.21 |