샤딩

복제로는 못 고치는 병

앞 강의에서 사본을 여러 권 만들어 읽기 부하를 나눴습니다. 그런데 이번엔 기록이 초당 5,000건씩 들어옵니다. 원본 장부는 초당 1,000건이 한계입니다.

사본을 100권 만들면 될까요? 안 됩니다. 기록은 원본에만 할 수 있으니까요. 사본을 늘리면 원본은 오히려 100권에 변경 사항을 알려주느라 더 바빠집니다.

약이 병에 안 맞는 겁니다. 복제는 읽기 병의 약이고, 지금 앓는 건 쓰기 병입니다.

그러면 장부를 쪼개자

유일한 방법은 원본 자체를 여러 개로 나누는 것입니다.

고객 성씨 ㄱ~ㅁ  →  1번 장부
고객 성씨 ㅂ~ㅅ  →  2번 장부
고객 성씨 ㅇ~ㅈ  →  3번 장부
고객 성씨 ㅊ~ㅎ  →  4번 장부

각 장부는 자기 몫에 대해서는 완전한 원본입니다. 사본이 아닙니다. 1번 장부에 기록하는 동안 2번 장부에도 동시에 기록할 수 있습니다. 장부가 4개면 기록 능력도 4배입니다. 이걸 샤딩이라고 하고, 각 조각을 샤드라고 부릅니다.

이제 장부를 늘리는 만큼 쓰기가 늘어납니다. 복제로는 절대 얻을 수 없던 것입니다.

그런데 누가 어느 장부인지 어떻게 아나

요청이 들어오면 어느 샤드로 갈지 정해주는 존재가 필요합니다. "김철수의 정보를 줘"라는 요청이 오면, 이름을 보고 "1번 장부"라고 판단합니다.

중요한 것은 이 판단이 매번 같아야 한다는 점입니다. 김철수를 저장할 때 1번에 넣었는데 꺼낼 때 3번을 뒤지면 영영 못 찾습니다. 그래서 이 판단은 키를 계산해서 나온 항상 같은 답이어야 합니다. 이 계산 방식이 다음 강의의 주제인 일관된 해시입니다.

이 강의의 캔버스에서는 샤드를 여러 개의 데이터베이스로 두고, 그 앞의 로드밸런서에 '일관된 해시' 방식을 지정해서 샤드 라우터 역할을 시킵니다. 실제 시스템에서는 이 역할을 전용 프록시나 애플리케이션 코드가 맡습니다.

무엇을 기준으로 나눌 것인가 — 여기가 전부다

샤딩에서 유일하게 중요한 결정은 "무엇을 기준으로 나눌 것인가"입니다. 이걸 샤드 키라고 합니다. 그리고 한 번 정하면 바꾸기가 매우 어렵습니다.

나쁜 예를 봅시다. 가입 연도로 나눴다고 합시다.

신규 가입자는 전부 4번으로 갑니다. 샤드를 4개로 늘렸는데 일하는 건 하나뿐입니다. 이걸 핫스팟이라고 합니다. 나머지 3대는 돈만 쓰고 놀고 있습니다.

좋은 샤드 키의 조건은 두 가지입니다.

1. 고르게 퍼진다 — 어느 샤드에도 몰리지 않는다 (고객 ID처럼 값이 다양한 것)
2. 대부분의 질의에 그 키가 들어 있다 — 안 그러면 모든 샤드를 다 뒤져야 한다

샤딩의 대가

공짜가 아닙니다. 데이터가 흩어진 순간 여러 샤드에 걸친 질문이 어려워집니다.

• "김철수의 주문 내역" → 쉽습니다. 김철수의 샤드 하나만 봅니다.
• "지난달 전체 매출" → 4개 샤드를 전부 조회해서 합산해야 합니다.
• "A의 잔액을 B에게 이체" → 두 사람이 다른 샤드에 있으면 매우 어렵습니다.

한쪽만 성공하고 다른 쪽이 실패하면 돈이 사라집니다.

마지막 항목이 특히 중요합니다. 하나의 데이터베이스 안이라면 이 문제는 트랜잭션이 해결해 줍니다. 그게 다음다음 강의의 주제입니다. 그런데 샤드가 갈리는 순간 그 안전장치가 사라집니다.

그래서 순서가 중요합니다. 샤딩은 마지막 카드입니다. 인덱스로 안 되고, 캐시로 안 되고, 복제로도 안 될 때 꺼내는 것입니다. 처음부터 샤딩하는 설계는 대부분 필요 없는 고통을 자초하는 일입니다.