유일한 ID를 만드는 일은 쉬워 보입니다. 데이터베이스에 auto_increment를 걸면 끝나는 문제 아닌가요? 서버가 한 대라면 맞습니다. 7장은 서버가 여러 대일 때를 다룹니다. 네 가지 접근을 비교하고 마지막 것을 고르는 구성인데요, 그 마지막 접근을 두고 재 본 것이 하나 있습니다. 생성기를 만들어 1초 동안 ID를 발급한 다음, 시계를 0.5초 뒤로 돌리고 다시 발급해 봤죠. 되돌아간 구간에서 발급한 15,000개가 한 개도 빠짐없이 전부 이전 ID와 중복이었습니다. 확률 문제가 아닙니다. 구조적으로 그렇게 됩니다. 그리고 가상의 상황도 아니죠. 시계를 맞추는 NTP 구현은 오차가 크면 시계를 점프시키는데, 그 점프가 뒤로도 갑니다. 이 글은 네 접근을 따라가면서 각각이 무엇을 내주고 무엇을 ..

키-값 저장소의 인터페이스는 두 개다. put(key, value)로 넣고 get(key)로 꺼낸다. 자료구조 수업 첫 주에 배우는 해시 테이블과 다를 게 없다. 그런데 6장은 이 두 개짜리 인터페이스로 한 장을 통째로 쓴다. API가 단순한 만큼 설계의 난이도가 전부 다른 데로 몰려 있기 때문이다. 여러 대에 나눠 담으면 무엇이 깨지는지, 복제하면 무엇이 새로 생기는지가 이 장의 내용이다. 시작하기 전에 하나 재 보고 갔다. 복제본을 세 개 두고 쓰기마다 셋 모두의 응답을 기다리도록 하면, 노드 하나의 가용률이 99%일 때 쓰기 성공률은 97.03%가 된다. 복제를 아예 하지 않은 단일 노드의 99%보다 나쁘다. 연간 실패 시간으로는 10.8일 대 3.7일이다. 내구성을 위해 복제본을 늘렸는데 실패할 ..

데이터를 여러 서버에 나눠 담을 때 가장 먼저 떠오르는 방법은 나머지 연산이다. 키를 해시하고 서버 수로 나눈 나머지를 쓴다. 서버가 네 대면 hash(key) % 4, 여덟 대면 % 8이다. 코드로는 한 줄이고 계산도 빠르다. 문제는 서버 수가 바뀔 때다. 나누는 수가 바뀌면 나머지도 바뀌니까 키가 다른 서버로 이동한다. 여기까지는 예상할 수 있는데, 실제로 얼마나 움직이는지를 재 보고 나서 생각이 달라졌다. 서버를 여덟 대에서 아홉 대로 늘리는 것만으로 89%가, 열여섯 대에서 열일곱 대로 늘릴 때는 94%가 자리를 옮겼다. 5장은 이 문제를 다룬다. 안정 해시(consistent hashing)는 노드 집합이 바뀔 때 재배치되는 키를 최소로 만드는 해시 방식이고, 1997년 Karger 등의 논문에..

앞 편에서 초당 몇 건이 들어오는지를 계산했다. 그 계산의 목적은 "그만큼 받을 수 있게 만들자"였다. 그런데 그 계산이 답하지 않은 질문이 하나 남는다. 계산한 상한을 넘는 요청이 실제로 도착하면 어떻게 되는가. 이 장의 답은 용량을 늘리는 쪽이 아니다. 넘는 요청을 거절하는 쪽이다. 처리율 제한 장치(rate limiter)는 정해진 시간 동안 허용할 요청 수를 정해 두고, 넘는 요청을 잘라 내는 구성 요소다. 거절이라고 하면 소극적인 조치처럼 들리는데, 실제로 읽어 보면 그렇지 않았다. 무엇을 언제 거절할지를 정하는 일에는 다섯 가지 알고리즘과, 그 알고리즘들이 각각 무엇을 포기했는지에 대한 판단이 들어간다. 그리고 그 판단이 그대로 시스템의 성격이 된다. 제한이 없으면 무슨 일이 벌어지는가책은 처..

숫자 없이는 설계도 없다 — 개략적 규모 추정 1편에서는 서버 한 대에서 시작해 로드밸런서, 캐시, CDN, 복제, 샤딩을 차례로 붙였다. 그 글을 쓰면서 끝까지 답하지 못한 질문이 하나 있었다. 그래서 지금 내가 만드는 서비스는 저 중 어디까지 필요한가. 캐시를 넣을 때인가, 아직 이른가. 샤딩을 고민해야 하나, 앞으로 3년쯤은 안 해도 되나. 2장은 그 질문에 답하는 도구를 다룬다. 개략적 규모 추정(back-of-the-envelope estimation)이다. 이름 그대로 봉투 뒷면에 적을 수 있는 수준의 계산이고, 정확한 값을 구하는 게 목적이 아니다. 자릿수가 맞는지, 그리고 그 자릿수가 어떤 구조를 요구하는지를 아는 게 목적이다. 솔직히 처음에는 이 장이 시험 대비용 계산 요령처럼 보였다...

대규모 시스템 설계 1편 - 사용자 규모에 따른 확장성『가상 면접 사례로 배우는 대규모 시스템 설계 기초』를 읽기 시작했다. 1장은 사용자가 한 명뿐인 서버 한 대에서 출발해, 사용자가 늘어날 때마다 구성 요소를 하나씩 더해 가며 백만 명 규모까지 끌고 간다. 로드밸런서, 캐시, CDN, 복제, 샤딩 같은 말들이 순서대로 등장하는데, 이 순서가 이 장의 전부라고 해도 된다. 읽으면서 계속 걸린 게 하나 있었다. 각 단계가 "이런 것도 있다"는 소개처럼 읽힌다는 점이다. 로드밸런서를 놓으면 트래픽이 분산된다, 캐시를 두면 빨라진다, 샤딩을 하면 데이터를 나눌 수 있다. 다 맞는 말이지만 이렇게만 기억하면 순서가 남지 않는다. 실제로 중요한 건 그 반대 방향이다. 어떤 병목이 먼저 터졌기에 이 장치가 필요해..

캐시는 잘 동작할 때가 아니라 무너질 때가 문제다1편에서 캐시가 무엇이고 왜 Redis로 가는지를, 2편에서 같은 Redis로 쓰기 경합을 다스리는 법을 정리했다. 두 편을 거치고 나면 Look-aside 캐시 한 벌을 붙이는 것 자체는 어렵지 않다. 캐시를 먼저 보고, 없으면 DB에서 읽어 채우고, 데이터가 바뀌면 지운다. 히트율 그래프가 95%를 찍으면 일이 끝난 것처럼 보인다. 문제는 그 95%가 아니라 나머지 순간에 있다. 인기 상품의 캐시가 만료되는 바로 그 1초, 누군가 존재하지도 않는 상품 번호를 초당 수천 번 조회하는 순간, 배포 직후 모든 키가 한꺼번에 만료되는 시점, 혹은 Redis 자체가 잠깐 죽는 동안. 이런 순간에 캐시는 부하를 덜어 주기는커녕, 평소 막아 주던 트래픽을 한꺼번에 ..

지난 1편에서는 캐시가 무엇이고 왜 Redis로 가는지, 캐시를 읽고 쓰는 패턴들을 정리했다. 그때 Redis는 주로 "원본 앞에 둔 읽기 가속 계층"이었다. 이번 2편에서는 Redis를 한 걸음 더 밀어붙여, 읽기가 아니라 쓰기 경합을 다스리는 도구로 쓴다. 여러 요청이 같은 데이터를 동시에 바꾸려 할 때 생기는 동시성 문제를, DB의 락에서 시작해 Redis 분산락과 원자 연산으로 옮겨 가며 풀어 본다. 문제 상황은 선착순이다. 선착순 쿠폰이나 한정 수량 상품을 만들어 본 적이 있다면, 코드를 처음 짤 때는 대개 이렇게 쓴다. 재고를 읽고, 0보다 크면 1 빼서 다시 저장하고, 발급 기록을 남긴다. 혼자 테스트할 때는 멀쩡히 돌아간다. 그런데 실제로 100개 한정 상품에 200명이 같은 순간 몰리면,..