요구사항 정리와 재배치 비용

이동량을 첫 제약으로 세웁니다. 처리량이 아닙니다.

그다음 각 숫자가 무엇을 강제하는지 말합니다. 구성 변경 주당 3~4번 은 이동 비용을 구조로 낮추게 만들고, 조회 초당 50만 은 담당을 물어보지 않고 계산하게 만듭니다.

흔한 실수: 장애 감지까지 범위에 넣는 것. 감지는 별개의 문제이고 그것을 끌어오면 담당을 정하는 이야기가 흩어집니다. "어느 서버가 빠졌다는 사실은 주어진 것으로 본다" 고 먼저 잘라야 합니다.

바뀐 키는 새 서버에서 미스가 되고, 그 미스가 그대로 원본 부하가 됩니다.

평소: 조회 50만 x 미스 5퍼센트 = 원본 요청 2.5만
담당이 전부 바뀐 직후: 원본 요청 50만

20배입니다. 그리고 원본이 그 부하를 받지 못하면 캐시를 채우는 것도 실패하므로 회복이 더 늦어집니다. 캐시 계층이 있는 시스템에서 가장 위험한 순간이 이것입니다.

그래서 이 설계에서 먼저 재는 값은 처리량이 아니라 서버 하나가 늘거나 빠질 때 담당이 바뀌는 키의 비율입니다.

흔한 실수: 캐시니까 미스가 좀 늘어도 괜찮다고 답하는 것. 미스는 조금 늘지 않고 한꺼번에 늡니다. 평소 부하로 맞춰 둔 원본이 20배를 받는 순간이 생기는 것이 문제입니다.

예산을 넘깁니다. 담당 계산은 조회마다 실행되므로 초당 50만 번입니다.

왕복은 같은 구역에서도 0.2에서 1밀리초입니다. 예산 0.1ms 를 한 번에 넘기고, 그 조회 서비스가 새로운 병목이자 새로운 장애 지점이 됩니다.

그래서 담당은 물어보지 않고 계산으로 알아야 합니다. 필요한 것은 서버 목록뿐이고, 그것은 자주 바뀌지 않으므로 각자 들고 있을 수 있습니다.

흔한 실수: 매핑 표를 중앙에 두고 캐시해서 쓰겠다고 답하는 것. 키가 10억 개 이므로 표를 키 단위로 만들면 그 표 자체가 또 하나의 대규모 저장소가 됩니다. 키마다의 답을 저장하는 것과 계산하는 것은 규모가 다릅니다.

이동량의 대가가 달라집니다. 기법은 같습니다.

캐시는 값을 잃어도 되므로 담당만 바꾸면 끝입니다. 저장소는 데이터를 옮겨야 하고, 옮기는 중에는 새 담당과 옛 담당을 모두 확인해야 하며, 옮기다 실패하면 어디까지 옮겼는지 알아야 합니다.

그래서 저장소에서는 이동량이 이관 작업량으로 환산됩니다.

흔한 실수: 캐시와 저장소를 같은 무게로 다루는 것. 캐시에서는 "그냥 버린다" 가 정답인데 저장소에서 그렇게 하면 데이터가 사라집니다. 무엇을 잃어도 되는지가 설계를 가릅니다.