<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://choyoungseo20.github.io/</id><title>Young's Tech Blog</title><subtitle>A tech blog by YoungSeo Cho, a backend developer writing about servers, databases, and lessons learned along the way.</subtitle> <updated>2026-09-19T00:08:19+09:00</updated> <author> <name>YoungSeo Cho</name> <uri>https://choyoungseo20.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://choyoungseo20.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://choyoungseo20.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 YoungSeo Cho </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Redis 클러스터 (Cluster)</title><link href="https://choyoungseo20.github.io/posts/redis-cluster/" rel="alternate" type="text/html" title="Redis 클러스터 (Cluster)" /><published>2026-09-13T21:30:00+09:00</published> <updated>2026-09-18T23:18:23+09:00</updated> <id>https://choyoungseo20.github.io/posts/redis-cluster/</id> <content type="text/html" src="https://choyoungseo20.github.io/posts/redis-cluster/" /> <author> <name>YoungSeo Cho</name> </author> <category term="Backend" /> <category term="Redis" /> <summary>클러스터 구성 데이터를 여러 Master에 나눠서 저장하고, 별도 감시자 없이 노드끼리 장애를 판정하는 구성 센티널까지로 failover는 자동화됐지만, write와 메모리는 여전히 Master 한 대의 한계에 갇혀 있다. 그래서 데이터 자체를 나눈다. 센티널과 달리 감시 전용 프로세스가 없고, 노드 간 gossip으로 서로 감시한다. 고가용성(HA)은 클러스터에 내장되어 있어, 센티널을 따로 두지 않는다. 데이터는 16384개의 슬롯으로 나뉘어 Master들에 분배된다. Master는 3대 이상이어야 한다. FAIL 판정과 승격 승인 모두 Master 과반이 하므로, 2대면 한 대 장애 시 과반이 성립하지 않는다. (센티널을 3대 이상 두는 것과 같은 논리) 클러스터 시...</summary> </entry> <entry><title>Redis 센티널 (Sentinel)</title><link href="https://choyoungseo20.github.io/posts/redis-sentinel/" rel="alternate" type="text/html" title="Redis 센티널 (Sentinel)" /><published>2026-09-13T21:00:00+09:00</published> <updated>2026-09-18T23:18:23+09:00</updated> <id>https://choyoungseo20.github.io/posts/redis-sentinel/</id> <content type="text/html" src="https://choyoungseo20.github.io/posts/redis-sentinel/" /> <author> <name>YoungSeo Cho</name> </author> <category term="Backend" /> <category term="Redis" /> <summary>센티널 구성 레플리카 구성에 감시 프로세스(센티널)를 더해, Master가 죽으면 자동으로 failover 하는 구성 고가용성(HA, High Availability)은 장애가 나도 서비스가 계속되는 성질이다. 레플리카가 넘겨받을 대상(이중화)을 만들었다면, 센티널은 넘기는 일(failover)을 자동화해서 HA를 완성한다. 센티널도 여러 대를 두고, 서로 감시와 합의를 통해 장애를 판정한다. 3대 이상, 홀수로 둔다. 과반이 성립해야 failover가 실행되므로, 2대면 한 대만 죽어도 과반이 불가능하다. 서로 다른 호스트에 배치한다. 한 호스트에 몰아두면 그 호스트 장애로 Master와 센티널 과반이 함께 사라진다. 감시자 스스로가 SPOF(단일 장애점)가 되지 않게 하기...</summary> </entry> <entry><title>Redis 레플리카 (Replication)</title><link href="https://choyoungseo20.github.io/posts/redis-replication/" rel="alternate" type="text/html" title="Redis 레플리카 (Replication)" /><published>2026-09-12T21:30:00+09:00</published> <updated>2026-09-18T23:29:09+09:00</updated> <id>https://choyoungseo20.github.io/posts/redis-replication/</id> <content type="text/html" src="https://choyoungseo20.github.io/posts/redis-replication/" /> <author> <name>YoungSeo Cho</name> </author> <category term="Backend" /> <category term="Redis" /> <summary>레플리카 구성 Master의 데이터를 다른 호스트의 Replica에 복제해두는 구성 Master의 디스크를 잃어도 Replica에 데이터가 남아 있다. 복제 시작 과정 Replica의 redis.conf에 Master 정보를 설정하면 복제 시작 replicaof [Master IP] [Master Port] Replica가 Master에 TCP connect PING → AUTH → REPLCONF listening-port [포트] 순서로 자신을 Master에 등록한다. (Master의 INFO replication에 slave로 표시된다) PSYNC ? -1 을 보내면 Master가 +FULLRESYNC로 응답하고, fork로 RDB를 생성해 전송한다. 그...</summary> </entry> <entry><title>Redis 싱글 구성과 영속성 (RDB, AOF)</title><link href="https://choyoungseo20.github.io/posts/redis-single-persistence/" rel="alternate" type="text/html" title="Redis 싱글 구성과 영속성 (RDB, AOF)" /><published>2026-09-12T21:00:00+09:00</published> <updated>2026-09-18T23:18:23+09:00</updated> <id>https://choyoungseo20.github.io/posts/redis-single-persistence/</id> <content type="text/html" src="https://choyoungseo20.github.io/posts/redis-single-persistence/" /> <author> <name>YoungSeo Cho</name> </author> <category term="Backend" /> <category term="Redis" /> <summary>싱글 구성 Redis 프로세스 하나로 운영하는 가장 단순한 구성 영속성이 필요한 이유 Redis는 모든 저장과 조회를 메모리에서 처리 Redis는 데이터를 메모리에만 두기 때문에, 프로세스가 죽으면 데이터가 사라진다. 디스크에 데이터를 남겨두면 재시작할 때 다시 로드할 수 있다. 그래서 영속성(RDB, AOF)이 필요하다. RDB (Redis Database) 특정 시점의 메모리 전체를 스냅샷으로 디스크에 기록하는 방식 save [초] [변경 횟수] 예를 들어 save 900 1 은 마지막 스냅샷 이후 900초가 지났고, 그동안 변경이 1번 이상 있었으면 스냅샷을 기록한다. 자식 프로세스를 fork 해서 기록하므로, 기록 중에도 요청을 계속 처리할 수 있다...</summary> </entry> <entry><title>캐시 경계 측정 (워킹셋 임계점)</title><link href="https://choyoungseo20.github.io/posts/measuring-the-cache-boundary/" rel="alternate" type="text/html" title="캐시 경계 측정 (워킹셋 임계점)" /><published>2026-08-17T05:40:00+09:00</published> <updated>2026-09-18T23:29:09+09:00</updated> <id>https://choyoungseo20.github.io/posts/measuring-the-cache-boundary/</id> <content type="text/html" src="https://choyoungseo20.github.io/posts/measuring-the-cache-boundary/" /> <author> <name>YoungSeo Cho</name> </author> <category term="Backend" /> <category term="Architecture" /> <summary>워킹셋 수백 종으로 남겨둔 재검토 조건을 직접 측정했다. L1 적중률은 798~800종에서 무너지기 시작했고, 접근 분포를 바꾸자 경계도 움직였다.</summary> </entry> </feed>
