Racon

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 을 사용하면된다.

Pub/Sub이란? 메시징 모델 중의 하나로 발행(Publish)와 구독(Subscribe) 역할로 개념화 한 형태 발행자와 구독자는 서로에 대한 정보 없이 특정 주체(토픽 or 채널)을 매개로 송수 Messaging Middleware 사용의 장점 비동기 : 통신의 비동기 처리 낮은 결합도 : 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존 탄력성 : 수정원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화됨 Messaging Middleware 제품들 : Kafka, RabbitMQ, ActiveMQ Redis의 Pub/Sub 특징 Message Queue에 저장 되지 않음 온라인으로 떠있는 Subscriber에게만 메시지가 전송된다. Kafka의 컨슈머 그룹 같은 분산 처리..

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

캐싱(Caching) Cache : 성능 향상 을 위해 값을 복사해놓는 임시 기억 장치 Cache에 복사본을 저장해놓고 읽음으로서 속도가 느린 장치로의 접근 횟수를 줄임 Cache의 데이터는 원본이 아니며 언제든 사라질 수 있다 캐시의 적용 네트워크 지연 감소 서버 리소스 사용감소 병목현상 감소 원칙 : 더 빠르고 값사게 가져올 수 있다면 캐시를 사용한다. 캐싱 관련 개념들 캐시 적중 (Cache Hit) : 캐시에 접근해 데이터를 발견함 캐시 미스(Cache Miss) : 캐시에 접근했으나 데이터를 발견하지 못함 캐시 삭제 정책(Eviction Policy) : 캐시의 데이터 공간 확보를 위해 저장된 데이터를 삭제 캐시 전략 : 환경에 따라 적합한 캐시 운영 방식을 선택 할 수 있음(Cache-Asid..

세션관리를 위한 서버의 역할 세션 생성 : 요청이 들어 왔을때 세션이 없다면 만들어서 응답에 set-cookie로 넘겨줌 세션 이용 : 요청이 들어왔을때 세션이 있다면 해당 세션의 데이터를 가져옴 세션 삭제: 타임아웃이나 명시적인 로그아웃 API를 통해 세션을 무효화함 모든 요청에 대해서 Cookie를 파싱해 확인하고, 세션 생성 시에는 set-cookie 값가지 설정해야 위 동작을 쉽게 해주는 Spring Boot 도구 - HttpSession 세션을 손쉽게 생성하고 관리할 수 있게 해주는 인터페이스 UUID로 세션 ID를 생성 JSESSIONID라는 이름의 Cookie를 설정하여 내려줌 ex) @GetMapping("/hello") public String hello(HttpSession sessio..

Session 정의 네트워크 상에서 두 개 이상의 통신장치간에 유지되는 상호 연결 연결된 일정 시간 동안 유지되는 정보를 나타냄 적용 대상에 따라 다른 의미를 가짐 Web 로그인 세션 Web 상에서 특정 유저가 로그인했음을 나타내는 정보 브라우저는 Cookie를, 서버는 해당 Cookie에 연관된 세션 정보를 저장 유저가 로그아웃 하거나 세션이 만료될 때 까지 유지되어 유저에 특정한 서비스 가능 Web 로그인 과정 분산 환경에서의 세션 처리 Server는 세션 정보를 저장 해야 함 Server가 여러 대라면 최초 로그인한 Server가 아닌 Server는 세션 정보를 알지 못함 세션 정보를 Server간에 공유할 방법이 필요(Session Clustering) 분산 환경에서의 세션 처리 - RDB 사용시..