전체 글287

• 

  광고 클릭 집계 시스템 설계, 스트림 처리 파이프라인, 이벤트 시간 윈도우, Exactly-Once 개요광고를 한 번 클릭하면 어떤 일이 벌어지는가. 사용자에겐 0.3초짜리 페이지 이동이지만 시스템 뒤에서는 그 한 번의 클릭이 수십 개의 서비스를 지나고, 수십억 건의 다른 클릭과 합쳐져 실시간 집계된다. 광고주는 "오늘 우리 광고가 몇 번 클릭됐는지"를 5분 안에 알고 싶어 한다. 너무 늦으면 예산을 재조정할 타이밍을 놓친다. 그런데 이 한 번의 클릭을 중복 없이, 누락 없이, 초 단위로 집계하는 일은 생각보다 까다롭다. 한 이벤트가 Kafka로 들어가기 직전에 네트워크가 끊기면 어떻게 되는가. Flink가 집계하다가 죽으면 어디까지가 유효한가. Pinot이 응답하기 전에 새 클릭이 들어오면 어떻게 합치는가.Vol 2 Ch6(Ad Click Event Aggregation)는 스트림 처리의 정확도(En.. CS/시스템 설계 2026. 10. 15.

• 

  지표 모니터링 및 경보 시스템 설계 : Prometheus · Datadog, 시계열 데이터와 Gorilla 압축 가상면접 시스템 설계 시리즈 5편 (Vol 2 Ch5)개요서비스가 한 대였을 때는 SSH로 들어가 uptime을 치는 것만으로도 충분했다. 사용자가 몰리는 시간에 CPU가 얼마나 쓰이는지, 응답이 얼마나 걸리는지, 한눈에 보였다. 그런데 웹 서버가 10대, DB 복제본이 5대, 캐시 노드가 12대로 늘어나는 순간, "지금 뭐가 어떻게 돌고 있는지"를 묻는 질문 자체가 달라진다. 더 이상 단일 머신을 보는 게 아니라 수십 대에서 쏟아지는 숫자를 한 그래프에 합쳐야 한다. 그리고 그 숫자의 모양새가 일반 데이터와 다르다는 사실을 깨닫는다. 시간에 묶인 수치, 시계열(Time Series) 이다.19편은 운영 3요소인 로그·메트릭·자동화를 큰 그림에서 훑었다. 이번 글은 그중 메트릭 한 축만 깊게 파고든다. .. CS/시스템 설계 2026. 10. 14.

• 

  아파치 카프카와 주키퍼: 분산 시스템의 코디네이터에서 KRaft(내재화)로의 진화 가상면접 시스템 설계 시리즈 4.5편 (Vol 2 Ch4 보강편)0. 들어가며 — 분산 시스템의 까다로운 두 문제분산 시스템을 설계할 때 가장 마주하기 까다로운 문제는 "여러 노드가 정확히 동일한 상태를 바라보게 만드는 것(Consistency)"과 "네트워크 분할이나 장애 상황 속에서도 누가 리더인지 합의하는 것(Consensus)"입니다.아파치 카프카(Apache Kafka)는 초기 버전부터 클러스터의 메타데이터 관리, 브로커 상태 감지(Service Discovery), 컨트롤러 선출 등의 코디네이션(Coordination) 역할을 아파치 주키퍼(Apache ZooKeeper)에 전적으로 위임해 왔습니다. 하지만 최근 카프카는 주키퍼를 완전히 걷어내고 자체 메타데이터 관리 방식인 KRaft(Kafk.. CS/분산시스템 2026. 10. 14.

• 

  Distributed Message Queue 설계 : Kafka · RabbitMQ · RocketMQ 가상면접 시스템 설계 시리즈 4편 (Vol 2)개요알림 시스템에서 배운 교훈을 떠올려 보자. 푸시 서버가 APNs·FCM에 동기적으로 요청을 보내면 응답 지연이 우리 서버의 스레드와 DB 커넥션까지 잠식해 결제·로그인까지 무너진다(13편). 해법은 메시지 큐를 사이에 두고 비동기로 분리하는 것이었다. 알림 서버는 큐에 이벤트를 던져놓고 돌아서고, 워커가 큐에서 꺼내 서드 파티로 보낸다. 이 한 번의 분리가 시스템 전체를 캐스케이딩 실패에서 구한다.Vol 1 Ch10(알림)에서 "왜 메시지 큐로 비동기 분리하는가"의 원칙을 배웠다. Vol 2 Ch4는 그 다음 질문인 "어떤 메시지 큐를 쓰는가" 의 깊이로 들어간다. Apache Kafka, RabbitMQ, RocketMQ, 그리고 클라우드 관리형인 AW.. CS/시스템 설계 2026. 10. 14.

• 

  채팅 시스템 설계, 수백만 개의 열린 연결을 버티는 법 가상면접 사례로 배우는 시스템 설계 시리즈 15편개요REST API 설계에 자신감이 붙은 백엔드 3~5년 차 엔지니어라면 이런 순간을 만난다. 면접관이 말한다. "카카오톡 같은 채팅 시스템을 설계해 보세요. 동시 접속 수백만 명." 평소에는 무상태(Stateless) 세계에서 살던 엔지니어는 여기서 당황한다. 무상태를 버리는 게 미덕이던 환경에서, 갑자기 수백만 개의 TCP 커넥션을 메모리에 꽉 쥐고 절대 놓지 않는 상태 유지의 늪으로 들어가야 하기 때문이다.채팅의 본질을 한 문장으로 말하면 이렇다. 상대방이 메시지를 보냈을 때, 그 메시지는 서버가 먼저 말을 걸어서 내 화면에 떠야 한다. 그런데 HTTP는 태생적으로 클라이언트가 먼저 입을 열어야만 응답할 수 있는 단방향 프로토콜이다. 이 모순을 어떻게.. CS/시스템 설계 2026. 10. 14.

• 

  뉴스피드 시스템 설계, 0.1초의 화면 뒤에 숨은 팬아웃 전쟁 가상면접 사례로 배우는 시스템 설계 시리즈 14편개요출근길 지하철에서 피드를 새로 고침한다. 로딩 아이콘이 휙 돌더니, 정확히 0.1초 만에 친구들의 글이 쏟아진다. 우리는 이 0.1초를 전등 스위치처럼 당연하게 여긴다. 하지만 그 짧은 찰나에 서버 몇 만 대가 움직이고, 수백만 건의 데이터 조각이 해체됐다가 다시 조립된다. 그리고 무엇보다, "지금 이 순간 친구 5,000명 중 누가 무슨 글을 썼는지"를 알아내는 탐색이 일어난다.뉴스피드는 겉보기엔 "최신 글을 시간순으로 보여주는 목록"이다. 그런데 그 단순한 기능 뒤에 이런 질문이 숨어 있다. 한 명이 글을 쓰면 그 글이 어떻게 수천 명의 화면에 동시에 닿는가? 이 문제가 바로 이 장의 주인공, 팬아웃(Fan-out)이다. 이 글은 읽기/쓰기 비대칭에.. CS/시스템 설계 2026. 10. 14.

• 

  한 서버의 메모리로는 부족하다, 분산 키-값 저장소(Key-Value Store) 설계 가상면접 사례로 배우는 시스템 설계 시리즈 09편개요키-값 저장소(Key-Value Store)는 단순해 보인다. 사전 하나면 되는 것을 왜 수십 대의 서버로 쪼개서 만들까. 답은 물리적 한계에 있다. 단일 서버의 메모리, 디스크, 네트워크 대역폭은 전부 유한하다. 사용자 수가 늘면 메모리에 전부 올리던 것도 디스크로 흘러내리고, 디스크도 차면 이제 진짜 문제가 시작된다.이 글은 Amazon Dynamo 스타일의 분산 키-값 저장소를 설계한다. CAP 이론에서 출발해 쿼럼(Quorum)과 벡터 클락(Vector Clock)으로 일관성을 타협하고, 안정 해시로 데이터를 분산·다중화하고, 가십 프로토콜과 머클 트리(Merkle Tree)로 장애를 감지·복구하고, LSM-Tree와 B-Tree 사이에서 저장 .. CS/시스템 설계 2026. 10. 14.

• 

  서버 한 대를 추가했더니 캐시가 통째로 사라졌다, 안정 해시(Consistent Hashing) 설계 가상면접 사례로 배우는 시스템 설계 시리즈 08편개요캐시 서버가 4대로 운영 중이라고 상상해 보자. 어느 날 트래픽이 늘어 서버를 1대 추가했다. 그런데 갑자기 캐시 적중률이 바닥으로 떨어지고, DB에 읽기 요청이 수십 배로 몰리기 시작한다. 서버를 늘렸는데 왜 시스템은 더 느려지는 걸까.원인은 hash(key) % N 이다. 이 글은 왜 나머지 연산(Modulo)이 서버 증감 앞에서 붕괴하는지, 그리고 이를 해결하는 안정 해시(Consistent Hashing)가 어떤 원리로 "재배치를 최소화"하는지를 설계 관점에서 설명한다.1. hash(key) % N의 함정 — 재배치 폭풍캐시 서버가 4대 있다고 하자. 특정 키가 어느 서버에 저장될지는 보통 이렇게 결정한다.server_index = hash(ke.. CS/시스템 설계 2026. 10. 14.

• 

  CAP을 넘어 PACELC로: 평상시 트레이드오프와 합의 알고리즘 CAP을 넘어 PACELC로: 평상시 트레이드오프와 합의 알고리즘이전 1편: 피터 도이치의 8가지 오류에서 분산 환경의 물리적 한계, 2편: CAP 이론에서 P 상황의 트레이드오프, 3편: 주문/결제 시스템에서 CP와 AP 선택하기에서 1·2차 방어선으로 풀어내는 실무 전략을 다뤘습니다.3편 §5의 도메인 매트릭스에서 우리는 "정합성이 절대적인 도메인에는 CP 기반 분산 락(ZooKeeper/etcd)"이라고 정리했습니다. 그 CP 락 안에서는 무슨 일이 일어나고 있을까요? 그리고 CAP 이론이 다루지 못한 "평상시 트레이드오프"는 어떻게 설명할까요? 이번 4편은 이 두 질문에 답합니다.Hook: 네트워크 장애가 안 나면 CAP은 끝인가요? — 평상시에도 시스템은 트레이드오프에 직면합니다. PACELC .. CS/분산시스템 2026. 10. 9.

• 

  주문/결제 시스템에서 CP와 AP 선택하기 (feat. 블랙프라이데이) 주문/결제 시스템에서 CP와 AP 선택하기 (feat. 블랙프라이데이)이전 1편: 피터 도이치의 8가지 오류에서 분산 환경의 모든 고통이 물리적 한계에서 시작된다는 사실을 확인했습니다. 2편: CAP 이론에서는 "P는 선택이 아니라 전제, C와 A 중 하나를 포기해야 한다"는 트레이드오프의 수학적 정의를 짚었습니다.이번 3편에서는 이 트레이드오프를 실제 이커머스 주문 시스템에 대입합니다. "완벽한 정합성(CP)만 고집하면 왜 서비스가 터지는가"부터, "어떻게 AP로 가되 사가 패턴과 멱등성으로 방어하는가"까지, 결제 도메인의 생존 전략을 짚습니다.Hook: 결제창이 3초 멈추면 매출이 증발한다 — 그래서 우리는 정합성을 한 박자 늦추기로 했다.1. 실무의 고민 — 왜 CP만 고집하면 서비스가 터질까?2편.. CS/분산시스템 2026. 10. 9.

• 

  빛과 전파의 한계에서 시작하는 분산 시스템: 피터 도이치의 8가지 오류와 현실 분산 시스템의 진짜 출발점: 피터 도이치의 8가지 오류단일 서버(Monolith) 환경에서 개발을 할 때는 모든 것이 평화롭습니다. 함수를 호출하면 결과가 즉시 돌아오고, 메모리에 올린 데이터는 안전하며, 디스크나 네트워크 I/O는 대개 순조롭게 흘러갑니다.하지만 서비스를 확장해 마이크로서비스 아키텍처(MSA)나 대규모 분산 시스템을 구축하는 순간, 이 '당연함'들은 전부 거대한 착각이었음을 깨닫게 됩니다. 도대체 왜 분산 환경은 우리를 괴롭히는 걸까요? 답을 찾으려면 추상화된 코드를 걷어내고, 데이터가 움직이는 물리적 세계로 내려가야 합니다.이 글은 분산 시스템 시리즈 1편입니다. 1편에서는 물리적 한계 → 개발자들이 무의식적으로 빠지는 8가지 착각 → 이 한계 위에서 살아남는 회복 탄력성 전략까지 다.. CS/분산시스템 2026. 10. 9.

• 

  CAP 이론, "P를 보장한다"는 것의 진짜 의미 서론분산 시스템을 배우기 시작하면 거의 100% 마주치는 공식이 있습니다. CAP."C, A, P 셋 중 두 개만 가질 수 있다."이 한 줄이 모든 것을 잘못 가르쳤습니다. 이 글에서는 그 잘못을 바로잡고, "P는 선택이 아니라 전제"라는 Brewer의 2012년 재해석까지 도달해 보겠습니다.1. 왜 다시 CAP인가? — 모든 것의 시작2000년 7월, 포르투갈에서 열린 ACM PODC 학회 키노트 무대에 UC 버클리의 에릭 브루어(Eric Brewer)가 섰습니다. 그는 Google과 Inktomi 같은 대규모 분산 검색 시스템을 직접 구축하면서 겪은 직관을 정리해 발표했는데, 그것이 후에 "CAP 이론"으로 불리게 되는 추측이었습니다.당시만 해도 분산 데이터베이스는 무조건 ACID(원자성·일관성·격리.. CS/분산시스템 2026. 10. 8.