Racon

클러스터를 사용할 때의 성능 클라이언트가 MOVED 에러에 대해 재요청을 해야하는 문제 클라이언트(라이브러리)는 key-node 맵을 캐싱하므로 대부분의 경우 발생하지 않음 클라이언트는 단일 인스턴스의 REdis를 이용할때 와 같은 성능으로 이용 가능 분산 시스템에서 성능은 데이터 일관성(Consistency)과 trade-off가 있음 Redis Cluster는 고성능의 확장성을 제공하면서 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계 클러스터의 데이터 일관성 Redis Cluster는 Strong consistency를 제공하지 않음 높은 성능을 위해 비동기 복제를 하기 때문 클러스터의 가용성 - auto failover 일부 노드(master)가 실패(또는 네트워크 단절) 하더라..

클러스터를 사용할 때의 성능 클라이언트가 MOVED에러에 대해 재요청을 해야 하는 문제 클라이언트(라이브러리)는 Key-Node 맵을 캐싱하므로 대부분의 경우 발생하지 않음 클라이언트는 단일 인스턴스의 Redis를 이용할 때와 같은 성능으로 이용가능 분산 시스템에서 성능은 데이터 일관성(Consistency)과 trade-off가 있음 Redis Cluster는 고성능의 확장성을 제공하면서 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계 클러스터의 데이터 일관성 Redis Cluster는 Strong Consistency를 제공하지 않음 높은 성능을 위해 비동기 복제를 하기 때문 클러스터의 가용성 - auto failover 일부 노드(Master)가 실패(또는 네트워크 단절) 하더라도..

데이터를 분산하는 기준 특정 key의 데이터가 어느 노드(shard)에 속할 것인지 결정하는 메커니즘이 있어야 함 보통 분산 시스템에서 해싱이 사용됨 단순 해싱으로는 노드의 개수가 변할 때 모든 매핑이 새로 계산 되어야 하는 문제가 있음 Hash Slot을 이용한 데이터 분산 Redis는 16384개의 Hash Slot으로 key 공간을 나누어 관리 각 키는 CRC16해싱 후 16384로 modulo연산을 해 각 hash slot에 매핑 hash slot은 각 노드들에게 나누어 분배됨 클라이언트의 데이터 접근 클러스터 노드는 요청이 온 key에 해당하는 노드로 자동 redirect를 해주지 않음 클라이언트는 MOVED 에러를 받으면 해당 노드로 다시 요청해야 함

확장성이란? 소프트웨어나 서비스의 요구사항 수준이 증가할 때 대응할 수 있는 능력 주로 규모에 대한 확장성을 뜻함(데이터 크기, 요청 트래픽 등) 수직 확장(Scale-up)과 수평 확장(Scale-out)이 사용됨 수평 확장(Scale-Out) 처리 요소(ex: 서버)를 여러개 두어서 작업을 분산 무중단 확장이 가능 이론적으로는 무한대로 확장이 가능 분산 시스템에 따라오는 문제 부분 장애 네트워크 실패 데이터 동기화 로드밸런싱(또는 Discovery) 개발 및 관리의 복잡성 분산 시스템의 적용 분산 시스템으로 인한 trade-off 를 판단해서 적합하다면 사용 서비스 복잡도와 규모의 증가로 분산은 피할수 없는 선택 분산 시스템의 구현체들은 세부적인 부분에서 튜닝이 가능하게 옵션이 제공됨 즉. 분산 시스..

Redis Sentinel 이란? Redis에서 HA(High Availability)를 제공하기 위한 장치 master-replica 구조에서 master가 다운시 replica를 master로 승격 시키는 auto-failover를 수행 Sentinel 기능 모니터링 알림 자동 장애 복구 환경 설정 제공 Redis Sentinel 실제 구성도 설명 Sentinel 노드는 3개 이상으로 구성 Quorum 때문 : Quorum은 Redis에서 페일오버(장애 복구)를 결정할 때 필요한 최소한의 참여 수를 나타냅니다. 여러 Sentinel이 마스터 상태를 투표하고, 이 투표 수가 Quorum보다 많아야 페일오버가 발생한다. Sentinel들은 서로 연결되어 있음 Sentinel들은 Redis master와 ..

Redis replication(복제) 백업만으로는 장애 대비에 부족함(백업 실패 가능성, 복구에 소요되는 시간) Redis도 복제를 통해 가용성을 확보하고 빠른 장애조치가 가능 master가 죽었을 경우 replica 중 하나를 master로 전환해 즉시 서비스 정상화 가능 복제본(replica)은 read-only 노드로 사용가능 하므로 traffic 분산도 가능 Redis 복제 사용 Replica노드에서만 설정을 적용해 master-replica 복제 구성 # Replica로 동작 하도록 설정 replicaof 127.0.0.1 6379 # Replica는 read-only로 설정 replica-read-only Master 노드에는 RDB나 AOF를 이용한 백업 기능 활성화가 필수! (재시작 후에..

AOF(Append Only File)을 사용한 백업 모든 쓰기 요청에 대한 로그를 저장 재시작 시 AOF에 기록된 모든 동작을 재수행해서 데이터를 복구 장점 모든 변경사항이 기록되므로 RDB방식 대비 안정적으로 데이터 백업 가능 AOF 파일은 append-only(명령어가 저장된) 방식이므로 백업 파일이 손상될 위험이 적음 실제 수행된 명령어가 저장되어 있으므로 사람이 보고 이해할 수 있고 수정도 가능 마지막에 flushAll을 사용하여 데이터가 손실되었다면 flushAll을 제거후 실행해야 한다. 단점 RDB 방식보다 파일 사이즈가 커짐 RDB 방식 대비 백업&복구 속도가 느림(백업 성능은 fsync정책에 따라 조절가) AOF 설정 # AOF 사용(Default NO) appendonly yes # ..

RDB (Redis Database)를 사용한 백업 특정 시점의 스냅샷으로 데이터 저장 재시작 시 RDB 파일이 있으면 읽어서 복구 장점 작은 파일 사이즈로 백업 파일 관리가 용이(원격지 백업, 버전 관리 등) fork를 이용해 백업하므로 서비스 중인 프로세스는 성능에 영향 없음 데이터 스냅샷 방식이므로 빠른 복구가 가능 단점 스냅샷을 저장하는 시점 사이의 데이터를 변경사항은 유실될 수 있음 데이터 저장 이후 다시 데이터를 저장하기 전에 오류 fork를 이용하기 때문에 시간이 오래 걸릴 수 있고, CPU와 메모리 자원을 많이 소모 데이터 무결성이나 정합성에 대한 요구가 크지 않은 경우 사용 가능 (마지막 백업 시 에러 발생 등의 문제) RDB 설정 설정파일이 없어도 기본값으로 RDB를 활성화 되어 있음 ..

채팅방 기능의 요구사항 채팅 클라이언트와 채팅 서버가 존재하고 통신방식을 정해야함. (프로토콜) 채팅 서버는 채팅방 관리 로직을 작성해야 함 Client 채팅방 입장 메시지 전송 메시지 수신 Chat Server 채팅방 생성 채팅방 접속자 관리 채팅방 메시지 수선/전송 Redis Pub/Sub을 이용한 채팅방 구현 채팅방 기능을 publish/subscribe 구조를 이용해 쉽게 구현 Chat Server 대신에 Redis Pub/Sub 을 사용하면된다.

리더보드(Leaderboard) 게임이나 경쟁에서 상위 참가자의 랭킹과 점수를 보여주는 기능 순위로 나타낼 수 있는 다양한 대상에 응용(최다 구매 상품, 리뷰 순위 등) 그룹 상위 랭킹 또는 특정 대상의 순위를 보여준다. 리더보드의 동작(API 관점) 점수 생성/업데이트 => ex: SetScore(userId, score) 상위 랭크 조회(범위 기반 조회) => ex: getRange(1~10) 특정 대상 순위 조회 (값 기반 조회) => ex: getRank(userId) 빠른 업데이트/ 빠른 조회가 필 관계형 DB 에서 데이터 구조와 성능 문제 관계형 DB등의 레코드 구조를 사용했을때 User Score A 1500 B 1350 C 1200 ... ... 업데이트 한 행에만 접근 하므로 비교적 빠름..