Firestore Deep Dive - Part 1: 역사, 구조, 그리고 Spanner

이 글에서 다루는 사내 사례와 데이터는 기밀 유지를 위해 일부 이름과 용어를 익명화했습니다.

들어가며

게임 런칭을 앞두고 Firestore를 미리 데우는(warm-up) 과제를 맡은 적이 있습니다.

시작은 단순한 질문이었습니다. 런칭 순간에 트래픽이 0에서 최대로 뛰는데, 그때 DB가 버틸까? 공식 문서를 찾아보니 답이 이렇게 적혀 있었습니다.

Firestore는 트래픽에 맞춰 자동으로 확장됩니다.

맞는 말인데, 이 문장만으로는 아무것도 할 수 없었습니다. 얼마나 빨리 확장되는지, 확장된 상태가 얼마나 유지되는지, 확장이 트래픽보다 느리면 무슨 일이 일어나는지가 없었기 때문입니다. 실제로 부하를 걸어 보니 429가 돌아왔고, 그 시점부터는 "Firestore가 알아서 한다"는 설명으로는 한 발짝도 나아갈 수 없었습니다.

그래서 Firestore가 실제로 무엇 위에 서 있는지부터 파고들었습니다. 이 글은 그 조사 기록입니다.

• 1부(이 글) — Firestore의 역사와 구조. 무엇 위에 서 있고, 데이터가 어떻게 배치되며, 읽기와 쓰기 한 건이 어디를 지나가는지.
• 2부 — 확장의 한계와 워밍업. 실제로 부하를 걸어 관측한 것과, 100K ops/s까지 데우면서 알게 된 것들.

1부는 실험 이야기가 없는 순수 구조 해설입니다. 그런데 2부에서 다루는 관측들이 전부 여기 나오는 구조에서 설명되기 때문에, 순서를 이렇게 잡았습니다.

근거 표기

분산 DB의 내부는 공식 문서가 다 말해 주지 않고, 검증되지 않은 추측이 인터넷에 많습니다. 그래서 문장마다 근거의 출처와 강도를 표시했습니다.

1. 역사 — Firestore는 Datastore의 후속이 아니다

Firestore를 이해하는 데 가장 도움이 됐던 사실은 이것이었습니다.

Firestore는 Datastore의 다음 버전이 아니라, 같은 데이터 모델을 다른 저장 엔진 위에 다시 구현한 것이다.

이 문장이 왜 중요한지는 조금 뒤에 드러납니다. 먼저 시간순으로 보겠습니다.

📄 2024년 VLDB에 Google 엔지니어들이 Datastore에서 Firestore로의 이관 과정을 다룬 논문을 발표했습니다. 이 글의 역사·저장구조 부분은 대부분 이 논문에 근거합니다.

📄 논문의 표현은 이렇습니다.

"Datastore launched in 2008 as the database for Google's early platform-as-a-service App Engine. Megastore was used as Datastore's storage layer. ... Firestore launched in 2019, combining a newer implementation of the Datastore API with a new mobile and web-friendly Firestore API, but used Spanner as its storage layer."

1-1. Megastore가 무엇이고 무엇이 문제였나

📄 Megastore는 entity group 단위로 Paxos를 돌려 데이터를 동기 복제했고, 각 복제본은 Bigtable에 저장됐습니다.

entity group은 키의 계층 구조로 정해집니다. Datastore의 키는 (kind, identifier) 쌍의 경로입니다.

/users/752                          ← entity group (users, 752)
/users/752/rooms/den                ← 같은 group
/users/752/rooms/kitchen            ← 같은 group
/users/752/backups/A/slice/23       ← 같은 group

첫 번째 (kind, identifier) 쌍을 공유하면 같은 entity group입니다. 그리고 여기에 Megastore의 두 가지 제약이 걸려 있었습니다.

📄 > "Megastore, and hence Datastore, provided full ACID semantics within each entity group but no consistency guarantees across them. Furthermore, each entity group had a limited maximum write rate (on the order of a few writes per second), forcing application developers to split their data across many entity groups, and then have to resort to eventually consistent queries to access this data."

이 제약이 만드는 악순환이 문제의 핵심입니다.

group 하나당 초당 몇 건밖에 못 쓴다
        ↓
데이터를 여러 entity group으로 잘게 쪼갠다
        ↓
그런데 group 사이에는 일관성 보장이 없다
        ↓
group을 걸치는 조회는 eventually consistent 쿼리로 해야 한다
        ↓
데이터 모델이 저장 엔진의 제약에 맞춰 뒤틀린다

📄 완화책으로 최대 25개 entity group을 걸치는 트랜잭션을 지원했지만, 근본 해결은 아니었습니다.

🔴 시제에 주의하세요. "entity group당 초당 몇 건"은 Megastore 시절 Datastore의 제약입니다. 지금의 Firestore에는 해당하지 않습니다. 인터넷에 남아 있는 오래된 Datastore 튜닝 글들이 이 제약을 전제로 쓰여 있어서, 지금 읽으면 오히려 잘못된 데이터 모델을 유도합니다.

1-2. 왜 Spanner였나

📄 논문은 Spanner를 고른 이유를 이렇게 적습니다.

"Spanner was chosen as the storage engine of Firestore in particular for technical reasons — it provides unrestricted transaction capabilities, strong consistency guarantees, and other improvements over Megastore."

그래서 Datastore API를 Spanner 위에 다시 구현했을 때 얻은 것이 두 가지입니다. 📄 모든 쿼리의 강한 일관성, 그리고 제약 없는 트랜잭션. 위 악순환이 통째로 사라진 셈입니다.

📄 그리고 두 API는 같은 데이터 모델을 쓰고, 같은 데이터에 접근하며, 가격도 동일합니다. Datastore API와 Firestore API는 같은 저장소를 보는 두 개의 문(門)입니다.

1-3. 100만 개의 DB를 무중단으로 옮긴 이야기

📄 이관은 2021년에 시작해 약 3년이 걸렸고, 100만 개가 넘는 모든 데이터베이스가 옮겨졌습니다. 이 글의 주제는 아니지만 원칙 하나는 인용할 만합니다.

"Migration causes no downtime or disruption to customer traffic during and after migration ... The migration is automatic; the customer does not need to take any action."

우리가 지금 쓰는 Firestore가 이 이관의 결과물이고, 뒤에 나올 저장 레이아웃이 Megastore 시절의 키 순서를 그대로 보존하도록 설계된 이유도 여기에 있습니다. 📄 "to preserve Datastore's performance profile after migration, both implementations must keep essentially the same storage layout and key order."

2. 레이아웃 — 요청 하나가 지나가는 길

Firestore에 문서 하나를 읽는 요청을 보내면, 그 요청은 일곱 개의 층을 지나갑니다.

🔴 출처를 분명히 해야 하는 지점입니다. Firestore 공식 문서(📘 Understand reads and writes at scale)는 ①~⑤층까지만 설명하고 Spanner와 Colossus를 이름으로 언급하지 않습니다. ⑥⑦층과 Firestore를 잇는 근거는 📄 VLDB 논문입니다. "Firestore는 Spanner 위에서 돈다"는 문장을 공식 문서에서 찾으려 하면 못 찾습니다.

2-1. 🔴 우리가 직접 볼 수 있는 층은 하나도 없다

이 글 전체에서 가장 실무적으로 중요한 사실이 이것입니다.

Spanner를 직접 쓰면 노드 수를 정하고, CPU 사용률을 보고, split 목록을 조회할 수 있습니다. Firestore 사용자에게는 그 어느 것도 노출되지 않습니다. Firestore는 프로비저닝하는 인스턴스가 아니기 때문에 노드 수라는 값 자체가 없습니다.

그래서 2부의 실험은 전부 "안을 못 보는 상태에서 행동만으로 내부 상태를 추론하는" 형태가 됩니다. 이 제약이 실험 설계 전체를 지배합니다.

3. 에디션과 모드 — 헷갈리는 두 개의 축

Firestore를 만들 때 고르는 선택지가 두 축으로 나뉘는데, 이름이 비슷해서 자주 섞입니다.

📘 editions overview 기준으로 정리하면 이렇습니다.

모드는 어떤 API로 이 저장소를 열 것인가입니다.

• Native mode — 📘 실시간 동기화와 오프라인 캐시를 포함한 최신 기능 전부. 새로 시작한다면 기본 선택지입니다.
• Datastore mode — 📘 Datastore와 App Engine Datastore 앱을 위한 모드. §1의 이관 서사가 그대로 이어지는 자리입니다. 옛 Datastore 앱이 코드를 그대로 두고도 Spanner 위 저장 엔진을 쓸 수 있게 한 것이 이 모드입니다.
• MongoDB 호환 — 📘 기존 MongoDB 드라이버·툴·오픈소스 생태계를 그대로 재사용. Enterprise edition에서만 가능합니다. 📘 2025년 4월 Google Cloud Next에서 프리뷰로 발표됐고 2025년 8월 GA됐습니다.

🔴 모드는 DB 생성 시점에 정해지고 나중에 바꿀 수 없습니다. 리전도 마찬가지입니다. 이 두 값은 되돌릴 수 없으니 생성 전에 확인해야 합니다.

이 글의 나머지와 2부는 전부 Standard edition · Native mode 기준입니다. 실무에서 가장 흔한 조합이고, 무엇보다 "모든 필드에 자동으로 인덱스가 생긴다"는 성질이 뒤에 나올 쓰기 비용 이야기의 전제이기 때문입니다.

4. 특성 — 문서 DB로서의 Firestore

4-1. 데이터 모델

Firestore는 컬렉션 → 문서 → (서브컬렉션 → 문서) 의 트리입니다.

users (컬렉션)
 └── user_8f3a... (문서)
      ├── name: "Isaac"
      ├── level: 42
      └── inventory (서브컬렉션)
           └── item_001 (문서)

• 문서는 스키마가 없습니다. 같은 컬렉션 안의 두 문서가 완전히 다른 필드를 가져도 됩니다.
• 문서 하나의 크기 상한은 📘 1 MiB입니다.
• 서브컬렉션은 부모 문서를 지워도 같이 지워지지 않습니다. 경로가 남아 고아 문서가 됩니다. 실무에서 자주 밟는 지뢰입니다.

4-2. 쿼리 — "느린 쿼리"가 아니라 "불가능한 쿼리"

RDBMS를 쓰다 오면 가장 크게 걸리는 지점입니다.

📘 Standard edition에서는 모든 쿼리가 인덱스를 요구합니다. 인덱스가 없으면 쿼리가 느려지는 게 아니라 실패합니다. 대신 에러 메시지에 그 인덱스를 만드는 콘솔 링크가 같이 옵니다.

FAILED_PRECONDITION: The query requires an index.
You can create it here: https://console.firebase.google.com/...

이 설계의 결과가 재미있습니다.

Firestore에는 "풀 스캔이 걸려서 느려지는" 상황이 존재하지 않습니다. 쿼리 성능은 스캔한 데이터가 아니라 반환한 결과의 크기에 비례합니다.

RDBMS에서는 인덱스를 안 타면 느려지기라도 하지만, Firestore는 아예 거부합니다. 성능 예측 가능성을 얻고 표현력을 내준 거래입니다. 그래서 JOIN이 없고, 정렬·범위 조건의 조합에도 제약이 있습니다.

4-3. PostgreSQL과의 빠른 비교

마지막 두 줄이 2부 전체의 주제입니다. 용량을 내가 정할 수 없다는 성질은 운영을 편하게 만들어 주지만, 런칭처럼 부하가 계단으로 뛰는 순간에는 정확히 반대로 작용합니다.

5. 키 공간 — 문서 ID가 곧 물리적 위치다

이제 저장 층으로 내려갑니다. 여기서부터가 2부의 실제 근거입니다.

5-1. 테이블은 두 개다

📄 논문이 보여 주는 저장 레이아웃입니다. 예제는 /users/752/rooms/den 같은 문서들이 homes라는 DB에 들어 있는 상황입니다.

TABLE Entities
  db_id | entity_group | path                     | kind  | ...
  ------+--------------+--------------------------+-------+----
  homes | (users, 752) | /users/752               | users | ...
  homes | (users, 752) | /users/752/rooms/den     | rooms | ...
  homes | (users, 752) | /users/752/rooms/kitchen | rooms | ...

TABLE Indexes
  db_id | index           | value | key → Entities
  ------+-----------------+-------+---------------------------
  homes | "size" on rooms | 100   | /users/752/rooms/den
  homes | "size" on rooms | 200   | /users/752/rooms/kitchen

키 순서가 핵심입니다. 📄

• Entities는 (db_id, 엔티티 키) 순으로 정렬됩니다 → "all entities for a particular Datastore database are contiguous"
• Indexes는 (db_id, 인덱스 식별자, 인덱싱된 값, 엔티티 키) 순으로 정렬됩니다 → "Within a particular index, entries are ordered by indexed values, as required for the index table scans which support query execution"

그래서 SELECT * FROM rooms WHERE size > 90 같은 쿼리는 이렇게 실행됩니다.

인덱스를 스캔해서 키를 얻고, 그 키로 본문을 가져온다. 이 2단계가 §4-2에서 말한 "인덱스 없으면 쿼리가 아예 안 되는" 이유이고, 동시에 "비용이 반환 결과에 비례하는" 이유이기도 합니다. 인덱스가 이미 정렬돼 있으니 조건에 맞는 구간만 연속으로 읽으면 되고, 그 구간의 길이가 곧 결과의 크기니까요.

5-2. 그래서 문서 ID를 어떻게 짓느냐가 물리 배치를 정한다

📄 저장 층은 행들을 tablet으로 쪼개 서버에 나눠 주고, 각 tablet은 연속된 키 범위를 담습니다.

"Both Megastore (via Bigtable) and Spanner use sharding to split or merge an instance's rows into tablets which are then assigned to individual servers, for sharing and balancing load. Each tablet contains consecutive ranges of the instance's keyed rows; consequently, key ordering is important for locality and overall performance."

즉 이렇습니다.

키 공간 (문서 ID 사전순)
├─────────────┬─────────────┬─────────────┤
   구간 A         구간 B         구간 C
   서버 1         서버 2         서버 3

문서 ID는 단순한 식별자가 아니라 그 문서가 어느 서버에 놓일지를 정하는 좌표입니다.

여기서 두 가지가 따라 나옵니다. 하나는 좋은 소식이고 하나는 나쁜 소식입니다.

• 🙂 ID를 고르게 흩뿌리면(예: 랜덤 해시) 부하가 여러 서버로 자연스럽게 나뉩니다.
• 🙁 ID가 단조증가하면(타임스탬프, 순번) 모든 쓰기가 키 공간의 끝 한 곳으로 몰립니다. 서버를 아무리 늘려도 그 한 대만 일합니다.

그리고 두 번째 문제는 Entities뿐 아니라 Indexes에도 똑같이 일어납니다. 문서 ID를 랜덤으로 잘 지었더라도 created_at 같은 필드에 인덱스가 걸려 있으면, 그 인덱스의 키 공간에서는 새 값이 항상 맨 끝에 붙습니다. 📘 Standard edition은 모든 필드에 자동으로 인덱스를 만들기 때문에(§3), 이건 의도하지 않아도 생깁니다.

📄 Google은 이 패턴에 index lasering이라는 이름을 붙였고, 논문에 이렇게 적었습니다.

"Index lasering is a traffic pattern in which monotonically increasing or decreasing values are written at a high rate to an index. ... Because the hotspot moves sequentially through a previously empty index key space, the load cannot be effectively split across multiple servers in a range-sharded system."

마지막 문장이 2부에서 반복해서 돌아옵니다. 핫스팟에는 서버를 더 나눠 줘서 풀리는 종류와, 아무리 나눠도 안 풀리는 종류가 있습니다. 단조증가 키는 후자입니다. 꼬리를 쪼개 봐야 새 꼬리가 생기니까요.

6. Spanner 구조 — 논리와 물리의 관계

여기서부터는 Firestore 문서에 없는 이야기입니다. 근거는 📄 Spanner: Google's Globally-Distributed Database (OSDI 2012) 논문과 📘 Cloud 문서입니다.

⚠️ OSDI 논문은 2012년 시점의 스냅샷입니다. 이후 구현이 바뀐 부분이 있을 수 있으므로, 구체적인 수치(특히 §7의 시계 오차)는 "당시 값"으로 읽어 주세요. 반면 구조와 용어는 지금 Cloud 문서와도 일관됩니다.

용어가 여럿 나오는데 논리 단위와 물리 단위가 섞여 있어서 헷갈립니다. 먼저 갈라 놓겠습니다.

6-1. spanserver 안쪽

📄 spanserver 하나는 tablet을 100~1000개 들고 있고, tablet마다 Paxos state machine이 하나씩 얹혀 있습니다.

몇 가지 중요한 성질이 여기서 나옵니다.

• 📄 쓰기는 반드시 리더에서 Paxos를 시작해야 하지만, 읽기는 충분히 최신인 아무 replica의 tablet에서나 직접 읽습니다. 읽기와 쓰기의 확장성이 갈리는 근본 원인이 이 한 줄입니다.
• 📄 lock table은 리더에만 있습니다. 2단계 잠금(2PL) 상태를 키 범위 → 잠금 상태로 들고 있습니다.
• 📄 트랜잭션이 Paxos group 하나 안에서 끝나면 transaction manager를 우회합니다. 여러 group에 걸칠 때만 2PC가 붙습니다. 이게 §9의 비용 구조를 정합니다.
• 📄 Paxos 리더는 장수명 리더 리스를 쓰고 기본값이 10초입니다.

6-2. split 하나가 zone들에 퍼지는 모습

이제 전체 관계도입니다. split 3개가 zone 3개에 복제된 상황을 그리면 이렇습니다.

읽는 법입니다.

• 가로 줄이 zone입니다. 물리적으로 떨어진 장애 격리 단위입니다.
• 세로 줄이 하나의 split이고, 그 replica들의 집합이 Paxos group입니다.
• 각 Paxos group은 리더를 하나씩 뽑습니다. 📘 "as long as a majority of the voting replicas for the split are up, one of those replicas can be elected leader."
• 🔴 리더들이 같은 zone에 몰려 있지 않습니다. 📘 "The distribution of splits among the nodes may be different in each zone, and the Paxos leaders do not all reside in the same zone."

마지막 항목이 실무적으로 중요합니다. "이 DB의 리더 서버"라는 것은 존재하지 않습니다. split마다 리더가 따로 있고 서로 다른 zone에 흩어져 있습니다. 그래서 쓰기가 여러 split에 걸치면 여러 zone을 가로지르는 조율이 필요해집니다(§9).

6-3. nam5는 실제로 어떻게 생겼나

📘 Firestore의 멀티리전 로케이션은 문서에 구성이 공개돼 있습니다.

📘 "Each replica is either a read-write replica which contains all of the data in the database or a witness replica which does not maintain a full set of data but participates in replication."

witness replica는 데이터 전부를 들고 있지 않지만 복제(=합의 투표)에는 참여합니다. 과반을 만드는 데는 기여하되 스토리지 비용은 덜 드는 구성입니다. 리전 하나가 통째로 사라져도 서비스가 계속되는 근거가 이것입니다.

🧩 문서가 말하지 않는 것: 총 replica 개수와, 리더십이 어느 리전에 주로 놓이는지는 공식 문서에 명시돼 있지 않습니다. 인터넷에 "리더는 주 리전에 유지된다"는 설명이 돌아다니지만 저는 출처를 확인하지 못했습니다.

7. TrueTime — 시계에 돈을 쓰는 이유

분산 트랜잭션에서 가장 어려운 문제는 "어느 쪽이 먼저 일어났는가" 입니다. 서버마다 시계가 조금씩 다르기 때문에, 보통은 시계를 믿지 않는 방향으로 설계합니다.

Spanner는 반대로 갔습니다. 시계를 믿을 수 있게 만들어 버렸습니다.

📄 TrueTime API는 시각을 하나의 값이 아니라 구간으로 돌려줍니다.

TT.now()  →  TTinterval [earliest, latest]
              ← 실제 시각은 이 구간 안에 반드시 있다

📄 "TrueTime explicitly represents time as a TTinterval, which is an interval with bounded time uncertainty (unlike standard time interfaces that give clients no notion of uncertainty)."

이 구간의 폭 절반을 ε(엡실론)이라 부릅니다. 논문 시점의 값은 이랬습니다. 📄

• 시간 기준은 GPS 수신기와 원자시계 두 종류 — 고장 양상이 서로 달라야 상관된 실패를 피할 수 있기 때문입니다
• 데몬 폴 주기 30초, 적용 드리프트 200μs/s
• ε는 폴 주기마다 1~7ms를 오가는 톱니 모양이고, 대부분의 시간에는 약 4ms

7-1. commit wait — 쓰기에 고정으로 붙는 비용

TrueTime이 있으면 트랜잭션에 "실제 시각" 타임스탬프를 붙일 수 있습니다. 그런데 구간에는 폭이 있으므로, 커밋 타임스탬프가 정말로 과거가 될 때까지 기다려야 합니다.

📘 "the leader waits until it can be sure that the transaction's timestamp has passed in real time; this typically requires a few milliseconds ... This is what ensures strong consistency."

이것이 commit wait입니다. 📄 논문의 1-replica 실험에서 commit wait은 약 5ms, Paxos 지연은 약 9ms였습니다.

🔴 여기서 얻는 것과 잃는 것 얻는 것 — external consistency. 트랜잭션 A가 끝난 뒤 시작한 트랜잭션 B는 반드시 더 큰 타임스탬프를 받습니다. 두 트랜잭션이 지구 반대편 서버에서 실행돼도 그렇습니다. 잃는 것 — 모든 쓰기에 수 ms의 고정 비용이 붙습니다. 부하를 줄여도 사라지지 않습니다.

2부에서 "쓰기 지연이 왜 읽기보다 구조적으로 비싼가"를 이야기할 때, 그 바닥에 이 commit wait이 깔려 있습니다.

8. 읽기 경로 — 잠금이 없다

읽기 한 건이 지나가는 길입니다.

핵심은 두 문장입니다. 📘

"reads do not acquire any locks in read-only transactions. And because reads can potentially be served by any up-to-date replica of a given split, the read throughput of the system is potentially very high."

• 잠금을 잡지 않습니다. 쓰기와 경합하지 않고, 읽기끼리도 경합하지 않습니다.
• 아무 replica나 응답할 수 있습니다. 리더 하나에 몰리지 않으므로 읽기 처리량은 replica 수만큼 늘어납니다.

8-1. 낡은 읽기가 더 빠른 이유

📘 강한 읽기에서도 replica는 보통 리더에게 RPC를 한 번 날려 "내가 어디까지 적용해야 하느냐"를 묻습니다. 그런데 이 왕복을 없앨 수 있습니다.

"If the client is able to tolerate reads that are at least ten seconds stale, read throughput can be even higher. Because the leader typically updates the replicas with the latest safe timestamp every ten seconds, reads at a stale timestamp may avoid an extra RPC to the leader."

리더가 10초 주기로 안전 타임스탬프를 뿌려 주기 때문에, 10초보다 낡은 시점을 읽겠다고 하면 리더에게 물어볼 필요가 없습니다. 최신성을 조금 포기하는 대가로 왕복 하나를 통째로 아끼는 거래입니다.

랭킹 보드나 목록 화면처럼 몇 초 낡아도 되는 조회라면 검토할 가치가 있습니다.

9. 쓰기 경로 — participant 수가 지연을 정한다

읽기와 달리 쓰기는 리더를 거쳐야 하고, 합의를 해야 하고, 잠금을 잡아야 합니다.

9-1. split 하나 안에서 끝나는 쓰기

📘 리더가 부여하는 타임스탬프는 "guaranteed to be greater than that of any previously committed transaction" 입니다.

9-2. 여러 split에 걸치는 쓰기 — 2PC

문제는 쓰기 한 건이 여러 split을 건드릴 때입니다. 📘

"All of the splits involved in a transaction become participants in the transaction."

이때는 2단계 커밋이 붙습니다. participant마다 잠금을 잡고, 📘 "each participant split records its set of locks by replicating them to (at least) a majority of split replicas" — 즉 잠금 자체를 과반 복제합니다. 그다음 coordinator가 결과를 모든 participant에 알리고, 그제서야 변경이 적용됩니다.

📘 "typically a few more than in the single split case because of the extra cross-split coordination."

그래서 공식 문서가 이렇게 못 박습니다. 📘

"Write/transaction latency increases as the number of splits/participants increases."

9-3. 🔴 그런데 문서 하나를 쓰면 participant가 몇 개가 되는가

여기가 Firestore 특유의 지점입니다. §3에서 본 것처럼 Standard edition은 모든 필드에 자동으로 인덱스를 만듭니다. 그리고 📄 인덱스 엔트리는 같은 트랜잭션 안에서 동기적으로 갱신됩니다.

📄 "in the case of a write to Spanner, all entities and index entries are updated synchronously, and therefore the latency of a write is at least as high as the latency of the slowest index update"

인덱스 엔트리는 §5에서 봤듯 Indexes 테이블의 전혀 다른 키 위치에 놓입니다. 인덱싱된 필드가 많을수록 건드리는 키 범위가 넓어지고, 넓어질수록 걸치는 split이 늘어납니다.

문서 1건 쓰기
   → 인덱싱된 필드 N개의 엔트리를 전부 갱신
   → 그 엔트리들이 흩어진 키 범위가 넓다
   → participant split이 많아진다
   → 2PC 참가자가 늘어난다
   → 지연이 오른다

📘 공식 문서의 표현은 이렇습니다.

"High index fanout for a document write increases the number of database rows to be mutated, which increases the number of participants."

⚠️ 인터넷에는 "인덱스 팬아웃이 쓰기 지연의 가장 큰 기여자"라는 표현이 자주 보이는데, 저는 그 문장을 공식 문서에서 확인하지 못했습니다. 확인되는 것은 "participant 수를 늘린다" 까지입니다. 방향은 같지만 강도가 다르므로 여기서는 확인된 데까지만 적습니다.

9-4. 읽기와 쓰기의 비용 구조 정리

🧩 읽기는 replica 수만큼 늘어나고 쓰기는 리더 하나로 직렬화됩니다. 이 비대칭이 2부에서 실측으로 그대로 드러납니다.

10. split은 부하를 보고 생긴다

이제 §5의 키 공간과 §6의 구조를 합칩니다.

📘 Spanner는 split 경계를 두 가지 계기로 만듭니다.

📘 "Splitting and merging are dynamic, based on traffic. As a split receives more traffic, Spanner subdivides it into smaller ranges and redistributes the resulting splits over other available resources in the instance."

즉 처리량은 split 수에 비례하고, split 수는 지금까지 받아 본 부하에 비례합니다. 부하를 받은 적이 없는 DB는 split이 적고, split이 적으면 서버도 적게 씁니다.

📘 그리고 확장이 트래픽을 못 따라가면 이렇게 됩니다.

"Splitting is not instantaneous. If the splitting and rebalancing can't keep up with the traffic, a split can potentially use up its available compute and memory resources."

이 한 문장이 2부의 출발점입니다. 런칭은 트래픽이 0에서 최대로 뛰는 사건인데, split은 즉시 생기지 않습니다.

10-1. split으로 풀리는 핫스팟과 안 풀리는 핫스팟

📘 load-based splitting은 "자주 접근되는 행들 사이에 경계를 추가해 서로 다른 서버가 담당하게" 만듭니다. 그런데 이 방식이 통하려면 경계를 그을 만한 자리가 있어야 합니다.

두 번째 줄이 §5에서 예고한 index lasering입니다. 📄 논문의 문장을 다시 인용합니다.

"Because the hotspot moves sequentially through a previously empty index key space, the load cannot be effectively split across multiple servers in a range-sharded system."

핫스팟이 가만히 있지 않고 이동하기 때문에, 경계를 그어도 부하는 이미 다음 자리로 옮겨가 있습니다.

10-2. 🔴 Spanner에는 있고 Firestore에는 없는 것

여기서 2부로 이어지는 결정적인 비대칭이 나옵니다.

📘 Spanner에는 pre-splitting이 있습니다. 런칭 전에 split 경계를 미리 만들어 달라고 요청하는 API입니다.

"By pre-splitting the database, Spanner can be ready for a predictable increased traffic." 언제 쓰는가 — "You're expecting a traffic load increase in an existing Spanner database in the near future. For example, you might need to support a large traffic event like a product launch or a sales campaign."

pre-split 지점은 기본 10일(최대 30일) 유지됩니다.

그런데 Firestore에는 이 API가 없습니다. §2-1에서 본 대로 Firestore는 split을 노출하지도, 조작하게 하지도 않습니다.

Spanner    : "여기에 경계를 만들어 줘"  라고 말할 수 있다   → 선언적
Firestore  : 실제로 부하를 걸어서 만들게 하는 수밖에 없다  → 경험적

🧩 Firestore에서 워밍업이 "데이터를 미리 넣는 일"이 아니라 "목표 부하를 실제로 통과시키는 일"이 되는 이유가 이것입니다. 경계를 요청할 수단이 없으니, 경계가 생길 만한 상황을 만들어 주는 것 외에 방법이 없습니다.

2부는 정확히 이 지점에서 시작합니다.

11. 다른 합의 기반 DB와 비교하면

Spanner만 이렇게 생긴 것은 아닙니다. 같은 계열의 분산 DB들과 나란히 놓으면 Firestore의 성질이 이 제품의 결함인지, 아니면 이 구조를 택하면 따라오는 것인지가 분명해집니다.

가장 흥미로운 축은 시계입니다. 셋 다 같은 문제를 푸는데 답이 다릅니다.

• Spanner — 하드웨어에 돈을 써서 시계 오차의 상한을 보장하고, 그 상한만큼 기다립니다(commit wait).
• CockroachDB — 특수 하드웨어 없이 HLC를 쓰고, 대신 최대 시계 오차를 가정합니다. 그 불확실 구간에 걸린 읽기는 재시작될 수 있습니다.
• TiDB — 아예 중앙 타임스탬프 발급자(PD) 를 둡니다. 시계 문제는 사라지지만 그 발급자가 단일 지점이 됩니다.

11-1. 단조증가 키 문제는 Firestore만의 것이 아니다

그리고 §10-1의 핫스팟 이야기가 여기서 확인됩니다. CockroachDB 문서도 똑같은 한계를 적고 있습니다.

"in the case of a sequential workload hitting one of the range boundaries, there is no suitable split point, which leads to a single range hotspot."

부하 기반 분할이 있는 시스템에서도, 순차 워크로드에는 그을 자리가 없습니다.

단조증가 키 핫스팟은 Firestore의 버그가 아니라 range-sharded 시스템 공통의 구조적 한계입니다.

키를 사전순으로 정렬해 연속 범위로 쪼개는 설계를 택하는 순간 따라오는 대가이고, 그래서 해법도 공통입니다 — 키를 흩뜨리는 것(해시 프리픽스, 샤딩된 인덱스)뿐입니다. 📄 실제로 Google도 이관 과정에서 lasering을 겪는 고객 DB를 위해 투명한 인덱스 샤딩 시스템을 만들었습니다.

12. 정리

1부에서 확인한 것을 압축하면 이렇습니다.

• Firestore는 Datastore의 후속이 아니라 같은 데이터 모델을 Spanner 위에 다시 구현한 것이다. Datastore mode가 존재하는 이유가 여기 있다.
• 저장 층은 Entities와 Indexes 두 테이블이고, 둘 다 키 사전순으로 정렬된다. 쿼리는 인덱스를 range scan해 키를 얻고 본문을 point lookup하는 2단계다.
• 그래서 문서 ID는 식별자가 아니라 물리 배치를 정하는 좌표다.
• 키 공간은 split 단위로 쪼개져 서버에 분배되고, split의 replica 집합이 Paxos group을 이룬다. 리더는 split마다 따로 있고 zone에 흩어져 있다.
• 읽기는 잠금이 없고 아무 replica나 응답할 수 있어 replica 수만큼 확장된다. 쓰기는 리더를 거쳐 Paxos를 돌고 commit wait을 치르며, 여러 split에 걸치면 2PC까지 붙는다.
• split은 부하를 보고 생기지만 즉시 생기지 않는다. 그리고 Firestore에는 Spanner의 pre-splitting 같은 미리 만들어 달라고 말할 수단이 없다.

마지막 두 줄이 2부의 문제의식입니다. 확장은 부하를 따라오는 것인데, 런칭은 부하가 먼저 도착하는 사건입니다. 그 사이의 간격에서 무슨 일이 일어나는지, 그리고 그 간격을 미리 메울 수 있는지를 실제로 부하를 걸어 확인한 기록이 2부입니다.

거기서는 이런 것들을 다룹니다.

• 용량을 미리 잡아 둘 수 없는 DB에서 429가 의미하는 것 — 포화가 아니라 정책이라는 판별식
• split이 생기는 순간을 바깥에서 관측할 수 있는가 — p95 지연의 혹(hump)과 그 해석
• 100K ops/s까지 데운 실측과, 그 과정에서 드러난 워밍업의 유효기간
• 🔴 그리고 가장 반직관적이었던 것 — 읽기 확장과 쓰기 허용량은 수명이 다르다

→ Firestore Deep Dive - Part 2: 확장 한계와 워밍업

참고 문헌