요청과 데이터가 서버에서 어떻게 처리되는지 — 백엔드 기본기.
2026년 9월 4일
안녕하세요. 자바파커입니다. 분산 캐시에 서버가 세 대 있다고 가정해 보겠습니다. 가장 단순한 배치식은 다음과 같습니다. 이 방식은 빠르고 이해하기 쉽습니다. 하지만 네 번째 서버를 추가하는 순간 식이 로 바뀝니다. 같은 키의 해시값은 그대로인데 나누는 수가 달라져 기존 키 대부분의 목적지가 달라질 수 있습니다. 일관된 해싱의 목적은 데이터를 완벽히 균등…
2026년 9월 3일
안녕하세요. 자바파커입니다. 데이터가 수억 건 있는 저장소에 어떤 키가 존재하는지 확인해야 한다고 생각해 보겠습니다. 매 요청마다 DB나 디스크를 읽으면 정확하지만 비쌉니다. 그렇다고 모든 키를 메모리에 보관하면 메모리가 커집니다. 블룸 필터(Bloom Filter)는 이 문제에 독특한 답을 냅니다. 없다고 판정하면 확실히 없습니다. 있다고 판정하면 실제…
2026년 8월 28일
안녕하세요. 자바파커입니다. 결제 서버 하나가 느려졌습니다. 주문 서버는 친절하게 세 번 재시도했습니다. 잠시 뒤 주문·재고·알림 서버까지 모두 느려졌습니다. 실패를 줄이려던 재시도가 왜 전체 장애를 만들었을까요? 서킷 브레이커는 실패를 없애는 장치가 아닙니다. 실패가 다른 서비스로 번지는 것을 막는 장치입니다. 요청이 쌓이다 차단기가 열리고, 시험 요청…
2026년 8월 27일
안녕하세요. 자바파커입니다. 캐시 적중률이 99%인데 DB가 갑자기 멈췄습니다. 캐시를 더 많이 쓰고 있었는데 왜 장애가 났을까요? 원인은 인기 키 하나의 만료 시각이었습니다. 캐시가 없어서가 아니라, 모두가 같은 순간 캐시가 없다는 사실을 발견해서 터집니다. TTL이 이 되는 순간 요청이 DB로 폭발하고, 락 하나로 다시 한 줄이 되는 과정은 52초 영…
2026년 8월 26일
안녕하세요. 자바파커입니다. 서버가 세 대라서 요청도 세 대에 똑같이 나눴습니다. 그런데 잠시 뒤 1번 서버의 연결은 8개, 2번과 3번 서버는 각각 1개가 됐습니다. 요청 개수는 공평했는데 왜 부하는 공평하지 않을까요? 로드 밸런싱의 목표는 요청 개수를 똑같이 만드는 것이 아니라, 사용 가능한 서버가 감당할 수 있도록 트래픽을 분배하는 것입니다. 요청이…
2026년 8월 25일
안녕하세요. 자바파커입니다. 초당 요청이 100건 들어오는데 서버는 20건밖에 처리하지 못한다고 해보겠습니다. 직접 호출이라면 20건은 처리되고 나머지는 타임아웃이나 오류가 됩니다. 그 사이에 메시지 큐를 넣으면 어떻게 될까요? 서버가 빨라지는 것은 아닙니다. 처리하지 못한 80건이 실패 대신 대기가 됩니다. 이것이 메시지 큐의 핵심입니다. 메시지 큐는 …