TIL

10장 클러스터

레디스 클러스터와 확장성

스케일업 vs 스케일 아웃

• 확장성(scalability)은 운영 중인 시스템에서 증가하는 트래픽에 유연하게 대응할 수 있는 능력을 뜻한다.
• 스케일 업
  • 서버의 하드웨어를 높은 사양으로 업그레이드하는 것
  • 수직 확장
• 스케일 아웃
  • 장비를 추가해 시스템을 확장하는 방식
  • 수평 확장
• 일반적으로 스케일 업이 간단하지만 하드웨어 범위 내에서만 가능하기에 한계가 있다.
• 스케일 아웃은 장비를 추가함에 따라 확장이 가능하지만 분산 처리에 대한 로직이 추가 개발 되어야 한다.

레디스에서의 확장성

• 레디스 처리량을 증가시킬 때 스케일 업만으로는 한계가 있다.
• 레디스는 단일 스레드로 동작하기에 CPU를 추가해도 코어를 동시에 활용할 수 없다.
• 데이터를 여러 서버로 분할해 관리하여 처리량을 선형적으로 확장시킬 수 있다.

레디스 클러스터의 기능

• 레디스의 클러스터 모드
  • 애플리케이션 아키텍처 변경 없이 레디스 인스턴스 간 수평 확장이 가능
  • 데이터 분산 처리, 복제, 자동 페일오버 기능 또한 사용 가능
• 데이터 샤딩
  • 마스터를 최대 1000개까지 확장시킬 수 있다.
  • 샤딩과 관련된 기능은 레디스 내부에서 자체적으로 관리되기에 프록시 서버 등의 추가 작업은 필요치 않다.
  • 데이터는 키를 이용해 샤딩되며 하나의 키는 하나의 마스터 노드에 매핑된다.
  • 클라이언트가 키가 없는 마스터 노드에 연결하면 키가 할당된 마스터 노드로 리다이렉션한다.
• 고가용성
  • 클러스터는 각각 최소 3대 마스터, 복제본 노드를 갖도록 하는 것이 일반적이다.
  • 하나의 클러스터 구성에 속한 각 노드는 서로를 모니터링한다.
  • 한 마스터 노드에 장애가 발생하면 자동 페일오버가 발생하기에 가용성이 높다.
  • 클러스터 내 노드들은 클러스터 버스라는 독립적 통신을 이용하여 다른 노드와 통신한다.
  • 풀 메쉬 토폴로지 형태
    • 모든 노드가 TCP 연결을 사용해 다른 모든 노드와 연결돼 있다.
    • 클러스터가 정상적인 상태에서는 노드 간 너무 많은 메시지 교환은 일어나지 않기에 오버헤드는 걱정하지 않아도 된다.

레디스 클러스터 동작 방법

해시슬롯을 이용한 데이터 샤딩

• 클러스터 구조에서 모든 데이터는 해시 슬롯에 저장된다.
  • 레디스는 총 16384개의 해시슬롯을 가지고 모든 마스터 노드는 이를 나눠 갖는다.
• 해시함수 - HASH_SLOT = CRC16(key) mod 16384
  • CRC16으로 암호화 후 나머지 값을 이용
• 해시슬롯은 마스터 노드 내에서 자유롭게 옮겨질 수 있다.
  • 옮겨지는 중에도 데이터에 정상 접근 가능
  • 덕분에 클러스터 내 마스터 노드의 추가, 삭제는 간단히 처리될 수 있다.

해시태그

• 클러스터를 사용할 땐 다중 키 커맨드를 사용할 수 없다.
  • ex) MEGET user1:name user2:name
  • 서로 다른 해시슬롯에 속한 키에 대해서 다중 키 커맨드를 사용할 수 없는 것
• 해시태그라는 기능을 사용하면 이런 문제를 해결할 수 있다.
  • { } 사이에 있는 문자열로 해싱하여 해시슬롯에 배치하는 방법
  • 아래 두 키는 괄호 사이에 동일한 값을 갖기에 같은 해시슬롯(마스터 노드)에 저장된다는 것이 보장된다.
  • 괄호가 없었다면 전체 키의 문자열로 해싱된다.
  • { }가 여러개 있다면 가장 처음의 { 부터 가장 처음의 } 사이 값들이 해싱된다.

user:{123}:profile
user:{123}:account

• 하지만 너무 많은 키가 같은 해시태그를 갖는다면 하나의 해시슬롯에 데이터가 몰리는 현상이 발생할 수 있다.
  • 키 분배에 대한 모니터링이 필요할 수도 있다.

자동 재구성

• 센티널과 마찬가지로 클러스터 구조에서도 복제와 자동 페일오버를 이용해 고가용성을 확보할 수 있다.
  • 클러스터 구조에선 데이터를 저장하는 일반 레디스 노드가 서로 감시한다는 점에서 센티널과 다르다.
  • 모든 노드는 클러스터 버스를 통해 통신하며 문제 발생 시 자동으로 클러스터 구조를 재구성한다.
• 레디스 클러스터에서 발생하는 재구성은 총 두 가지다.
  • 마스터 노드 장애 발생 시 복제본 노드를 마스터로 승격
  • 잉여 복제본 노드를 다른 마스터에 연결시키는 복제본 마이그레이션

자동 페일오버

• 페일오버 과정
  • 한 마스터에게 장애가 발생하면 그에 연결되었던 복제본은 다른 마스터들에게 페일오버 시도에 대한 투표를 요청한다.
  • 다른 마스터 노드가 장애 상태라고 판단하면 복제본에게 투표할 수 있다.
  • 과반수 이상의 투표를 받은 복제본은 마스터로 승격된다.
• cluster-require-full-coverage yes
  • 기본값 - yes
  • 클러스터에서 일부 노드만 다운된 경우라도 데이터 정합성을 위해 클러스터 전체 상태가 fail 처리되어 전체 해시슬롯에 대한 데이터 조작이 실패한다.
  • ex) 복제본이 1개만 있는 마스터가 다운되어 다음 복제본이 마스터로 승격됐는데 그 노드도 다운되어 클러스터의 마스터, 복제본 전체가 다운되는 경우
• 가용성이 중요할 때 클러스터 노드 다운타임을 줄이는 방법
  • 자동 복제본 마이그레이션이 가능하도록 아무 마스터 노드에 복제본을 하나 더 추가를 고려

자동 복제본 마이그레이션

• 레디스 클러스터는 각 마스터에 연결된 복제본 노드의 불균형을 파악해 복제본을 이동시키기도 한다.
  • ex) 특정 노드가 자동 페일오버 후 복제본이 사라졌을 때 다른 노드의 잉여 복제본 노드를 이동시킨다.
  • 가장 많은 수의 복제본이 연결된 마스터의 복제본 중 하나가 옮겨지게 된다.
• 자동 복제본 마이그레이션은 cluster-allow-repolica-migration 옵션이 yes일 때 동작
• cluster-migration-barrier
  • 복제본 마이그레이션하기 전 마스터가 가지고 있어야 할 최소 복제본 수를 의미
  • 만약 이 값이 2고 가장 많은 복제본을 가진 노드의 복제본 수도 2라면 복제본 마이그레이션은 발생하지 않는다.

레디스 클러스터 실행하기

• 레디스를 클러스터 모드로 사용하려면 최소 3개의 마스터 노드가 있어야 한다.
  • 보통 마스터에 각각 복제본을 추가해 총 6개 노드를 구성하는 것이 일반적

클러스터 초기화

• redis.conf에서 cluster-enabled 설정을 yes로 변경해 클러스터 모드로 변경할 수 있다.

cluster-enabled yes

• redis-cli를 이용해 클러스터를 생성할 수 있다.
  • —cluster create 옵션을 이용해 새로운 클러스터를 생성
  • 클러스터에 추가할 레디스의 ip:port 쌍을 나열
  • —cluster-replicas 1 옵션으로 각 마스터마다 1개 복제본을 추가

$ src/redis-cli --cluster create 192.168.0.11:6379 192.168.0.22:6379 ... --cluster replicas 1 -a nhncloud

• ip:port 쌍을 6개 입력했으면 입력한 순서대로 3개의 노드는 마스터, 나머지는 복제본이 되도록 구성될 것이다.
• 해시슬롯은 마스터에만 할당되며 복제본 노드에는 할당되지 않는다.

클러스터 상태 확인하기

• CLUSTER NODES 커맨드로 현재 클러스터 상태를 확인할 수 있다.
  • 랜덤으로 클러스터 내 노드를 순서 없이 출력

<id> <ip:port@cport> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>

• 각 라인의 의미는 다음과 같다.
  • id - 노드가 생성될 때 만들어지는 클러스터 ID 값
  • ip:port@cport - 노드가 실행되는 ip, port 그리고 클러스터 버스 포트 값이다.
  • flags - 노드의 상태를 나타낸다.
  • master - 복제본 노드일 경우 마스터 노드의 ID, 마스터일 경우 - 문자가 표시된다.
  • ping-sent - 보류 중인 PING이 없다면 0, 마지막 PING이 전송된 유닉스 타임을 표시한다.
  • pong-sent - 마지막 PONG이 수신된 유닉스 타임을 표시한다.
  • config-epoch - 현재 노드의 구성 에포크. (페일오버가 발생할 때마다 증가)
  • link-state - 클러스터 버스에 사용되는 링크의 상태를 의미 (connected/disconnected)
  • slot - 노드가 갖고 있는 해시슬롯의 범위를 표시

redis-cli를 이용해 클러스터 접근하기와 리디렉션

• 레디스 클러스터에 접속하려면 클러스터 모드를 지원하는 레디스 클라이언트가 필요하다.
  • 클러스터 모드가 지원되지 않는 클라이언트라면 특정 키에 대해선 정해신 해시슬롯이 있는 노드에서만 커맨드를 수행할 수 있다.
• 클러스터 모드를 지원하는 클라이언트
  • Jedis
  • Redisson
  • redis-cli (-c 옵션을 추가해 클러스터 모드 사용 가능, 리디렉션 기능이 제공된다)

페일오버 테스트

• 클러스터 구성이 완료되면 페일오버가 잘 동작하는지 확인하자
  • 클러스터 내부 노드 간 통신이 정상적인지
  • 일부 노드 간 네트워크 단절은 없는지
• 커맨드를 이용햔 페일오버 발생 (수동 페일오버)
  • 수동 페일오버를 하려면 페일오버시키고자 하는 마스터에게 1개 이상 복제본이 있어야 한다.
  • cluster failover 커맨드로 페일오버를 발생시킬 수 있다.
  • 수동 페일오버 중에는 기존 마스터에 연결된 클라이언트는 잠시 블락된다.
  • 페일오버가 완료되면 클러스터 정보를 변경하고 클라이언트는 새로운 마스터로 리디렉션된다.
• 마스터 동작을 중지시켜 페일오버 발생 (자동 페일오버)
  • 직접 마스터 노드에 장애를 발생시키는 방법
  • redis-cli -h <master-host> -p <master-port> shutdown
  • 클러스터 구조에서 복제본은 마스터가 정상적이지 않다고 판단하면 페일오버를 트리거한다.

레디스 클러스터 운영하기

클러스터 리샤딩

• 마스터 노드의 해시슬롯 중 일부를 다른 마스터로 옮기는 것을 리샤딩이라 한다.
  • 리샤딩 작업은 중단 없이 진행될 수 있다.
• redis-cli --cluster reshard <host>:<port>
  • redis-cli로 리샤딩을 시작할 수 있다.
  • 이동시킬 슬롯의 개수, 해시 슬롯을 받을 노드 ID 등을 차례로 입력하여 진행한다.

클러스터 리샤딩 - 간단 버전

• 만약 운영상 슬롯을 자주 이동시켜야 한다면 자동화를 할 수도 있다.
• 커맨드를 이용해 바로 슬롯을 이동시키는 방법이 존지한다.
  • 중간에 취소와 확인이 어려운 단점이 있다.

redis-cli --cluster reshard <host>:<port> --cluster-from <node-id> 
--cluster-to <node-id> --cluster-slots <number of slots> --cluster-yes

클러스터 리샤딩 - 신규 노드 추가

• 클러스터를 확장히야할 때 신규 노드 추가가 가능하다.
  • 추가하고자 하는 레디스에는 데이터가 하나도 없어야 한다.
  • 마찬가지로 설정 파일에 cluster-enabled yes를 추가한 클러스터 모드 상태여야 한다.
• 마스터로 추가하기
  • redis-cli —cluster add-node <추가할 노드 IP:PORT> <기존 노드 IP:PORT>
  • 두 번째 인수는 기존 클러스터 노드 중 1개를 지정하면 된다.
  • 노드 추가만 해서는 할당된 해시슬롯이 없기 때문에 리샤딩을 통해 해시슬롯을 할당해야 한다.
• 복제본으로 추가하기
  • redis-cli —cluster add-node <추가할 노드 IP:PORT> <기존 노드 IP:PORT> —cluster-slave [—cluster-master-id <기존 마스터 ID> ]

노드 제거하기

• 클러스터에서 노드를 제거하려면 del-node 커맨드를 사용한다.
  • redis-cli —cluster del-node <기존 노드 IP:PORT> <삭제할 노드 ID>
  • 마스터, 복제본 모두 이 커맨드로 삭제할 수 있지만 마스터의 경우 데이터가 없는 상태여야 한다.
  • 이 때 CLUSTER FORGET, CLUSTER RESET SOFT를 수행했다는 로그가 남는다.
• CLUSTER FORGET
  • 클러스터를 제거하려면 클러스터 내 다른 노드들에게 해당 노드를 지우라는 커맨드를 보내야 한다.
  • CLUSTER FORGET <node-id>를 수신한 노드는 노드 테이블에서 해당 노드 정보를 지운다.
  • 60초 동안 제거된 노드 ID를 가지는 노드와 신규로 연결되지 않도록 설정한다.
    • 클러스터 구성 내 노드들은 가십 프로토콜로 통신한다.
    • 제거된 노드 ID 차단을 하지 않으면 신규 클러스터 노드로 간주해 자동으로 추가할 수도 있다.
• CLUSTER RESET
  • 제거될 노드에서 수행하는 커맨드
  • SOFT와 HARD 옵션이 있으며 기본은 SOFT
  • HARD 리셋은 아래 과정 모드를 수행하지만 SOFT에선 1~3번까지만 수행한다.
    • 제거될 노드가 복제본이었다면 마스터로 전환되고 모든 데이터셋이 삭제되고, 마스터였다면 리셋 작업이 중단된다.
    • 노드가 해시슬롯을 가지고 있었다면 모든 슬롯이 해제되며 페일오버 중이었다면 페일오버도 초기화된다.
    • 클러스터 구성내 다른 노드 데이터가 초기화되어 클러스터 버스를 통해 연결됐던 노드를 인식할 수 없게 된다.
    • currentEpoch, configEpoch, lastVoteEpoch 값이 0으로 초기화된다.
    • 노드 ID가 새로운 임의 ID로 변환된다.

레디스 클러스터로의 데이터 마이그레이션

• 기존 싱글 혹은 센티널 구성이었던 레디스를 클러스터로 마이그레이션하고 싶을 때가 있다.
• 레디스 커맨드 라인 클라이언트를 통해 손쉽게 마이그레이션이 가능하다.
  • 기존 애플리케이션에서 다중 키 커맨드를 사용하고 있었다면 해시태그를 사용하도록 로직을 일부 수정할 필요는 있다.
• 클러스터 구성을 만든 뒤 기존 싱글 레디스 인스턴스에 데이터 import 요청을 한다.
  • 데이터가 저장될 클러스터 노드엔 해시스롯 16384개가 정상 할당된 상태여야 한다.
  • 클러스터 내 마스터 노드가 모두 접근 가능 상태여야 한다.

redis-cli --cluster import 192.168.0.11:6379 --cluster-from 192.168.0.88:6379 --cluster-copy

• 마이그레이션 도중에 변경되거나 수정된 데이터는 마이그레이션되는 클러스터에는 반영되지 않는다.
  • 때문에 소스 레디스에 연결된 클라이언트 연결을 중단하는 것이 좋다.

복제본을 이용한 읽기 성능 향상

• 레디스 클라이언트는 기본적으로 마스터 노드로 연결을 리디렉션한다.
  • 복제본에선 데이터를 읽을 수 없다.
• 마스터에 데이터 조회 부하가 집중되는 경우 읽기 트래픽은 복제본으로 분배시켜 읽기 성능을 향상시킬 수 있다.
  • READONLY 모드로 변경

$ redis-cli -h 192.168.0.55 -c
192.168.0.55:6379> readonly
OK

레디스 클러스터 동작 방법

하트비트 패킷

• 하트비트 패킷
  • 클러스터 내 노드들은 주기적으로 PING, PONG 패킷을 주고 받는다.
  • 일반적으로 클러스터가 주고받는 유형의 패킷에 가십 섹션이 추가된 형태
• 일반적으로 패킷 헤더는 다음 정보를 포함한다.
  • 노드 ID
  • 현재 에포크/구성 에포크: 분산 환경에서 일관성을 유지하기 위한 정보
  • 노드 플래그: 노드가 마스터인지 복제본인지 등 노드 정보
  • 비트맵: 마스터의 해시슬롯 비트맵 정보 (복제본인 경우 마스터의 정보)
  • TCP 포트: 발신 노드의 TCP 포트
  • 클러스터 포트: 발신 노드의 노드 간 커뮤니케이션을 위한 포트
  • 클러스터 상태: 발신 노드 관점에서 봤을 때 클러스터 상태 (down/ok)
  • 마스터 노드 ID: 복제본 노드인 경우 마스터의 노드 ID
• 하트비트 패킷은 위 헤더에 가십 섹션을 추가로 포함한다.
  • 발신 노드가 알고 있는 다른 노드 정보를 나타냄
  • 자신이 아는 노드 중 랜덤한 몇 개의 노드만 가십 섹션에 포함
  • 이를 이용해 다른 노드 정보를 받으며 장애도 감지할 수 있게 함
• 에포크
  • 노드 간 구성 정합성을 유지하기 위한 개념으로 클러스터에서 여러 이벤트의 순서를 나타내는 값이다.
  • 에포크 값이 클수록 최신 구성의 노드라는 것을 의미
  • 모든 노드는 끊임없이 하트비트 패킷을 주고 받기에 모든 노드는 가장 큰 구성 에포크 값으로 통일된다.
  • 에포크 값은 클러스터 상태를 변경할 때, 페일오버가 발생할 때 동의를 구하기 위해 사용된다.

해시슬롯 구성이 전파되는 방법

• 레디스 클러스터의 중요 기능 중 하나가 특정 키의 해시슬롯이 어디 있는지 파악해 위치를 알려주는 것이다.
• 클러스터에서 해시슬롯 구성은 두 가지 방법으로 전파된다.
  • 하트비트 패킷: PING/PONG 패킷과 함께 자신의 해시슬롯을 보냄
  • 업데이트 메시지: 하트비트 패킷을 받았을 때 거기에 포함된 에포크 값이 오래됐다면 신규 에포크 구성 정보를 포함한 업데이트 메시지를 하트비트 패킷을 보낸 노드에게 보내 그 노드의 해시슬롯 구성을 업데이트

노드 핸드셰이크

• CLUSTER MEET
  • 한 노드가 클러스터에 합류하기 위해 다른 노드에게 보내는 커맨드
  • 이 커맨드를 수신한 노드는 다른 노드에게 정보를 전파한다.
  • 이 정보를 받은 노드가 신규 노드를 모르는 상태라면 해당 노드와 CLUSTER MEET를 통해 신규 연결을 맺게 된다.
• 위 과정을 통해 노드끼리 완전히 연결된다.
• 이미 알고 있는 노드끼리만 통신을 주고 받기에 외부 클러스터와 우연히 연결되는 일은 없다.

클러스터 라이브 재구성

• 클러스터 운영 중 새로운 마스터를 추가하거나 기존 마스터를 제거할 수 있다.
  • 클러스터에서 노드의 추가/삭제 작업은 동일한 작업으로 여겨질 수 있다.
  • 두 작업 모두 결국 한 노드내의 해시슬롯을 다른 노드로 옮기는 작업이 동반된다.
• A가 갖고 있던 해시슬롯 8을 B로 옮기고 싶다면 각 노드에서 다음 커맨드가 수행된다.
  • A에게: CLUSTER SETSLOT 8 MIGRATING B
  • B에게: CLUSTER SETSLOT 8 IMPORTING A
  • 만약 마이그레이션 수행 도중 A가 해시슬롯 8에 대한 쿼리를 받았을 때
    • 조회 작업이면 A에서 수행
    • 쓰기 작업이면 B 노드로 리디렉션
• 옮기는 해시슬롯에 속한 키 또한 A에서 B로 마이그레이션 한다.
• 마이그레이션 중엔 락이 걸리며 이로 인한 경쟁 상황은 발생하지 않는다.

리디렉션

• 레디스 클러스터의 리디렉션에는 두 가지 종류가 있다.
  • MOVED: 요청하는 해시슬롯이 다른 노드에 있음을 클라이언트에 알림
  • ASK: 지금 요청 쿼리는 다른 노드에서 수행하되, 다음 노드는 다시 자신한테 보내도록 함
• MOVED 리디렉션
  • 커맨드를 받은 노드가 그 해시슬롯을 가지고 있지 않는다면 어떤 노드가 해시슬롯을 가지는지 확인 후 MOVED 에러로 클라이언트에 응답
  • 클라이언트는 반환받은 노드로 다시 커맨드를 수행해 데이터를 조회한다.
  • 이후에는 클라이언트가 이 키를 다시 조회할 때 올바른 마스터 노드를 기억했다 조회하기에 리디렉션 비용을 줄일 수 있다.
  • 클러스터가 안정적일 때 모든 클라이언트는 해시슬롯, 노드의 맵을 가지고 있어 SPOF 없는 효율적인 서비스가 된다.
• ASK 리디렉션
  • 해시슬롯이 이동되는 과정에서만 발생
  • 이 리디렉션을 받은 클라이언트는 전달 받은 노드 정보로 쿼리를 재전송하지만 이후 같은 키에 대해선 기존 전송한 노드에 다시 보낸다.
  • 클라이언트는 리디렉션을 받은 값으로 해시슬롯 맵을 업데이트하지 않는다.

장애 감지와 페일오버

• 장애 감지에 사용되는 플래그는 두 가지가 있다.
  • PFAIL: 일부 노드에서는 해당 노드에 접근할 수 없지만 아직 확실하지 않은 실패
  • FAIL 대다수의 노드에서 해당 노드에 장애가 발생했음을 동의한 상태
• PFAIL 플래그
  • 특정 노드에 NODE_TIMEOUT 시간 이상 도달할 수 없는 경우
  • 마스터, 복제본에 관계 없이 PFAIL로 플래그할 수 있다.
  • 하트비트 패킷으로 타임아웃을 판단하기에 노드 간 왕복 시간보다 NOTE_TIMEOUT 값은 항상 커야 한다.
• FAIL 플래그
  • 페일오버를 트리거시키려면 노드가 PFAIL이 아닌 FAIL이어야 한다.
  • FAIL 플래깅 시나리오
    • A 노드가 B 노드를 PFAIL로 플래깅
    • B 노드 상태가 하트비트 패킷을 통해 클러스터 내 전파
    • 일정 시간 내에 다른 노드에서도 B에 대한 PFAIL 또는 FAIL 응답을 받으면 이 노드를 FAIL로 처리

복제본 선출

• 아래 조건에서 복제본은 페일오버를 직접 시도한다.
  • 마스터가 FAIL 상태
  • 마스터는 1개 이상의 해시슬롯을 갖고 있다.
  • 마스터와의 복제가 끊어진 지 오래다.
• 위 조건 만족 시 복제본은 자신의 에포크 값을 1 증가시키고 마스터 인스턴스에 투표를 요청한다.
  • 복제본은 모든 마스터 노드에 FAILOVER_AUTH_REQUEST 패킷으로 투표 요청
  • 요청 받은 마스터는 FAILOVER_AUTH_ACK 패킷으로 긍정 응답을 보내 투표에 동의
    • 동시에 다른 복제본을 승격시키는 것을 막고자 NODE_TIMEOUT * 2 시간 동안엔 또 투표할 수 없다.
    • 에포크 값이 작은 응답이 오면 무시하기 때문에 이전 버전의 투표는 거를 수 있다.
  • 다수의 마스터로부터 ACK를 받은 복제본이 마스터 호부로 선출된다.
    • NODE_TIMEOUT * 2 동안 과반수 이상의 동의를 얻지 못하면 페일오버는 중단된다.
    • 이후 NODE_TIMEOUT * 4만큼의 지연 후 새로운 투표가 시작된다.
• 랜덤한 지연 시간을 이용해 같은 마스터의 여러 복제본이 동시에 투표를 시작하는 것을 방지할 수 있다.