24/02/07 TIL __ 레플리케이션

 

 

 

소켓 서버는 부하가 많아 이 부하를 견딜수 있게 처리해주고 싶었다.

샤딩과 레플리케이션을 생각했고, 1차 저장소인 레디스에 적용을 하고 싶었다.

 

처음에는 mongodb, redis 2개를 사용해야 하기 때문에 2다 해야할까 싶엇지만,

일단은 레디스만 적용해보려 한다.

샤딩보다는 레플리케이션을 먼저 시도하는게 나을 듯 해서

레디스의 레플리케이션에 대해 공부해 보았다.

 

 

레디스 공식문서에 나와있기를

 

Redis의 기본 클라이언트 수는 최대 10,000개입니다. 

최대값에 도달한 후 Redis는 모든 새 연결에 오류로 응답합니다. 

연결(또는 애플리케이션 인스턴스)이 많으면 더 높은 수준으로 올라가야 할 수도 있습니다.

Redis 구성 파일에서 최대 동시 클라이언트 수를 설정할 수 있습니다.

 

maxclients 20000

이걸 redis.conf 파일에서 설정하면 된다 하는데, 
redis.conf파일이 없다... 만들어야 하나 싶지만 좀더 찾아봤다.

docker 컨테이너에서 redis.conf파일이 있는데 그걸 수정하면 된다고 하는데 우리 프로젝트에는 없었다..
없다면, 대부분 컨테이너가 기본 설정을 사용하고 있거나, 

사용자가 커스텀 구성파일을 제공하고, 마운트 하는 과정을 거치지 않았기 때문일 가능성 높다.

@_$

마운트? 이건또 뭐야 했는데,
새로 파일을 만드는 것이 아니라, 이미 존재하는 파일이나 디렉토리를 컨테이너에서 접근할 수 있도록 연결해주는 작업 이라고 한다. 

마운트 사용 목적
주로 컨테이너 내부에서 필요한 설정 파일, 데이터 파일, 또는 애플리케이션 로그 등을 관리하기 위해 사용. 

특히, 컨테이너의 휘발성 특성 때문에, 

중요한 데이터를 컨테이너 외부에 저장하고 필요할 때 컨테이너에 연결하여 사용하기 위해 마운트를 사용한다.🫠

 

자꾸 새로운게 나와서 자료를 한참 보다가, 일단 뭔가 쳐보자 싶어서 일단 vscode에 conf파일 만들어봤다.
그리고 maxmemory 설정을 메모리의 25프로 남겨놓고 하라는데 어떻게 해야할지 모르겟어서 찾아봤는데
우리는 도커환경이니까 도커에 우리가 얼마나 메모리를 할당했는지가 중요.

이걸 알아보는 명령어는
docker inspect 도커번호(아이디)


근데 메모리 할당된게 안보인다.
설정을 안한걸로 보여졌는데 문득
이 설정을 하는게 과연 좋은가에 대한 의문이 들었다. 
그래서 찾아본 결과

컨테이너에 메모리 제한을 설정하는 경우 장점은 자원을 효율적으로 관리하고 안정적이지만, 관리가 복잡해 질 수 있다는 단점이 있다.

메모리 제한을 설정하지 않으면 유연하고 간단하지만, 시스템 안정성이 저하되는  측면이 있다.

 

이부분은 내일 한번 물어봐야 겠다. 메모리 할당이 되었는지, 어떤 설정으로 되어 잇는지.

  

아래는 redis.conf 파일의 예시이다. 

#레디스 서버 포트 지정
port 6379

#어떤 인터페이스에서 listen 할껀지.
bind 0.0.0.0

# 지정된 인터페이스에 대한것만 연결할것인가요?
protected-mode yes

# 최대 클라이언트수 설정(동시 연결 가능한)
maxclients 20000

# 키 제거하기 전 사용할 최대 메모리 설정(너무 높아도, 낮아도 안되며, 도커의 메모리 할당량도 고려해야함)
maxmemory 3gb

# 어떤 정책으로 메모리가 용량이 찻을때 키를 제거할건지(allkeys-lru: 오래된 것부터 제거하겠다 나는) 
maxmemory-policy allkeys-lru

# TCP 백로그 구성 (아직 레디스 서버가 accept하지 않은 연결 요청의 큐를 얼마나 많이 유지할 수 있는지 설정.)(65536은 매우 높은 연결요청률을 처리 가능하게 함. 고성능, 동시연결 많이 예상될때 적합)
tcp-backlog 65536

# 레디스가 데이터 어떤 디렉토리에 저장할건지 설정
dir /var/lib/redis

# 레디스 데이터베이스 스냅샷 저장시 사용될 파일 이름 지정.(레디스의 데이터를 디스크에 지속적으로 저장하기 위한 rdb 포멧의 파일. dump.rdb는 기본 파일명.)
#이 파일은 레디스 서버가 재시작 될때 데이터를 빠르게 복원하는데 사용. 이걸 통해 데이터베이스의 특정 시점으로 되돌릴 수 있고, 백업목적으로 가능. 압축된 형식임.
dbfilename dump.rdb

# 복제 설정 설정. # replicaof는 현재 인스턴스를 지정된 마스터의 복제본으로 만듭니다. 
# replicaof <master ip> <master port> 

# AOF 지속성 모드 활성화. (appendonly)
모든 쓰기 작업(데이터 변경 명령)이 서버에 발생할 때마다 Append Only File에 기록됩니다. 이 파일은 Redis가 재시작될 때 재생되어 데이터를 복원할 수 있게 합니다. AOF는 데이터의 안전성을 강화하지만, 파일 크기가 커지고 디스크 쓰기 비용이 발생할 수 있으므로, 적절한 재작성(rewrite) 전략과 함께 사용해야 합니다.
appendonly yes

# 설정된 복제본 서버가 마스터 서버와 연결이 끊어져도 계속 데이터 제공할건지(yes는 장애상황시 가용성. no는 일관성 엄격유지.)
slave-serve-stale-data yes

# Make replicas read-only by default.
slave-read-only yes

# Disable RDB persistence.
save ""

 

 

추가로 알게된건데

레디스의 파이프 라이닝에 대한 내용이다.

 

데이터 패킷이 클라이언트에서 서버로 이동한 후 다시 돌아오는 데 걸리는 시간을 네트워크 왕복 시간 또는 RTT 라고 합니다 .

예를 들어 50개의 명령을 실행해야 한다면 요청을 보내고 50번 응답을 기다려야 하며 매번 RTT 비용을 지불해야 합니다.

이 문제를 해결하기 위해 Redis는 클라이언트가 이전 응답을 아직 읽지 않은 경우에도 새 요청을 처리할 수 있습니다.

이렇게 하면 응답을 전혀 기다리지 않고 서버에 여러 명령을 보낼 수 있습니다.

답변은 결국 한 단계로 읽혀집니다.

이 기술을 파이프라이닝이라고 하며 시스템 성능을 향상시키는 또 다른 좋은 방법입니다.

대부분의 Redis 라이브러리는 기본적으로 이 기술을 지원합니다.