클러스터 구성 데이터를 여러 Master에 나눠서 저장하고, 별도 감시자 없이 노드끼리 장애를 판정하는 구성 센티널까지로 failover는 자동화됐지만, write와 메모리는 여전히 Master 한 대의 한계에 갇혀 있다. 그래서 데이터 자체를 나눈다. 센티널과 달리 감시 전용 프로세스가 없고, 노드 간 gossip으로 서로 감시한다....

센티널 구성 레플리카 구성에 감시 프로세스(센티널)를 더해, Master가 죽으면 자동으로 failover 하는 구성 고가용성(HA, High Availability)은 장애가 나도 서비스가 계속되는 성질이다. 레플리카가 넘겨받을 대상(이중화)을 만들었다면, 센티널은 넘기는 일(failover)을 자동화해서 HA를 완성한다. 센티널도 ...

레플리카 구성 Master의 데이터를 다른 호스트의 Replica에 복제해두는 구성 Master의 디스크를 잃어도 Replica에 데이터가 남아 있다. 복제 시작 과정 Replica의 redis.conf에 Master 정보를 설정하면 복제 시작 replicaof [Master IP] [Master Port] Replic...

싱글 구성 Redis 프로세스 하나로 운영하는 가장 단순한 구성 영속성이 필요한 이유 Redis는 모든 저장과 조회를 메모리에서 처리 Redis는 데이터를 메모리에만 두기 때문에, 프로세스가 죽으면 데이터가 사라진다. 디스크에 데이터를 남겨두면 재시작할 때 다시 로드할 수 있다. 그래서 영속성(RDB, AOF)이 필요하다. ...

워킹셋 수백 종으로 남겨둔 재검토 조건을 직접 측정했다. L1 적중률은 798~800종에서 무너지기 시작했고, 접근 분포를 바꾸자 경계도 움직였다.

API를 4대로 늘리기 전에 Redis를 비교했고, 실측을 근거로 Caffeine을 유지했다. 판단 근거와 재검토 조건을 기록한다.

네 가지 캐시 구성을 75회 부하 실험으로 비교했다. 응답 지연보다 DB 로딩과 콜드 스타트에서 차이가 났고, 현재 조건에서 Redis 도입을 기각했다.

API를 4대로 늘린다고 Redis가 바로 필요한 것은 아니었다. 성능, 정합성, 중복 로딩을 나눠 보고 다음 부하 실험에서 확인할 지표를 정리했다.

로그상 정상으로 보였던 이중 과금의 25초 레이스를 찾아, 조건부 UPDATE로 결제 선점을 원자화한 기록

갤러리 업로드 파이프라인을 고쳐 월 S3 증가량을 30GB에서 3GB로, 사진 1장 업로드 시간을 3초에서 1초로 줄인 과정