Auto Increment Gap 문제

Auto Increment Gap 문제는 RDBMS에서 자동 증가(primary key 등)를 사용하는 과정에서 발생할 수 있는 ID 누락(갭) 현상을 말합니다. 이 명칭은 공식적인 이름은 아니며, 실무적인 용어로 유사 용어로는 아래와 같은 것들도 있습니다.

• Sequence Gap
• ID Gap
• Non-contiguous Sequence
• Lost Sequence Number
• Skipped Sequence

 

---

✅ 1. Auto Increment Gap이란?

Auto Increment Gap은 자동 증가되는 ID 값들이 중간에 끊겨 누락된 상태로 보이는 현상입니다.

Auto Increment Gap 문제는 일반적인 다중 커넥션, 병렬 처리, 트랜잭션 롤백 등이 가능한 RDBMS (Oracle, MySQL 등) 환경에서 회피할 수 없는 동작 방식입니다.

 

예:

• ID 100, 101, (102 없음), 103
• 중간 ID(예: 102)는 발급되었지만 해당 트랜잭션이 롤백되거나 실패하면서 데이터는 존재하지 않고 ID만 건너뜀
• 또는 커밋이 완료되지 않은 시점에서 후순위 ID 가 보이지만, 잠시동안 중간 ID가 비어보임

---

✅ 2. 어떤 시스템에서 발생하나?

시스템	발생 여부	이유
MySQL (InnoDB)	✔ 발생	AUTO_INCREMENT는 트랜잭션과 무관하게 증가
Oracle	✔ 발생	SEQUENCE는 독립 객체로 미리 증가 가능
PostgreSQL	✔ 발생	SEQUENCE도 트랜잭션 롤백에 영향받지 않음
Redis (싱글스레드)	❌ 거의 없음	순차적이고 원자적으로 ID 할당 (INCR)
UUID, Snowflake 등	❌ 없음	고유값 생성 방식이므로 갭 개념 자체 없음

 

---

✅ 3. 발생 원인

RDBMS에서는:

1. 시퀀스/오토인크리먼트는 트랜잭션과 무관하게 동작합니다.
2. 병렬 커넥션이 많기 때문에 여러 트랜잭션이 동시에 ID를 요청하고, 일부는 롤백되어 ID가 소모만 된 채 사라집니다.
3. InnoDB의 경우, insert 전에 오토인크리먼트 값을 미리 할당하고 롤백되어도 그 값은 되돌리지 않습니다.

 

원인	설명
트랜잭션 롤백	INSERT로 ID를 발급했지만 이후 트랜잭션 롤백 시 데이터는 저장되지 않고 ID는 소모됨
동시성 (Concurrency)	여러 커넥션에서 동시에 ID를 발급받는 과정에서 충돌 회피를 위해 미리 ID를 할당함
캐싱 및 프리페치 (Preallocation)	성능 향상을 위해 시퀀스를 미리 여러 개 할당하거나 캐싱하면서 일부가 사용되지 않음
서버 크래시	ID는 증가되었지만 실제 데이터 INSERT 이전에 서버 다운 → ID만 건너뜀

 

 

---

✅ 4. 장단점 비교

구분	Auto Increment (RDB)	UUID/Snowflake	Redis (INCR) 기반
ID Gap 발생 가능성	높음	없음	매우 낮음
순차성	좋음	나쁨 (랜덤)	매우 좋음
성능	보통 (락/경합 있음)	보통~좋음	빠름 (싱글스레드)
확장성	낮음 (중앙집중형)	높음 (분산 가능)	낮음 (단일 노드 중심)
트랜잭션 Rollback 영향	있음 (ID만 소모)	없음	있음 (단, INCR 결과는 남음)

 

---

✅ 5. 문제 사례 및 영향

• 모니터링/추적 오류: ID 기준으로 시간 순서를 추적하려는 로직에서 누락이 생긴 것처럼 보임
• 운영 혼란: 운영자나 사용자 입장에서 "ID가 왜 중간에 빠졌는가?"라는 혼동 발생
• ID 재사용 요구: 금융, 행정 등 연속된 ID를 필요로 하는 시스템에서 요구사항 충족 어려움

---

✅ 6. Auto Increment Gap 문제 방지/완화 전략

전략	설명	장점	단점
1. Redis INCR 사용	Redis의 INCR 명령은 원자적이고 싱글스레드 기반이라 순차 ID 발급 가능	빠르고 간단, Gap 없음	단일 노드 장애에 취약, 확장성 제한
2. Kafka 단일 파티션 offset 활용	Kafka의 offset은 메시지 쓰기 시점에 순차적으로 증가 → Gap 없음	순차성 보장, 고성능 가능, Gap 없음	단일 파티션은 쓰레드 1개, TPS 확장성 한계
3. 전용 Sequence 서비스 (ID 서버)	전용 마이크로서비스에서 전역 ID 관리 (예: Snowflake 개량 버전)	비즈니스 로직과 분리, 유연한 커스터마이징	운영 복잡성 증가, 단일 장애지점 가능성
4. Redis Preallocation	Redis에서 ID 블록을 미리 할당해 애플리케이션 메모리에서 사용	DB 부하 감소, ID 재시도 가능	복잡도 증가, ID 일부 미사용 시 gap 발생 가능
5. UUID / Snowflake 사용	UUID 또는 시간 기반 분산 ID 생성	분산 시스템에서 충돌 없이 고유 ID 생성	순차성 없음 또는 약함, 가독성 낮음
6. 데이터 저장 직전에 ID 발급	INSERT 직전 시점에 ID 생성 → 롤백 시 ID 발급도 없음	Gap 방지 가능	로직이 복잡해짐, 트랜잭션 경계 관리 필요
7. Kafka + Redis Hybrid	Kafka offset을 기반으로 Redis에 ID 캐싱 또는 복제	순차성 + 속도 확보	동기화 관리 필요, 운영 난이도 ↑

 

---

✅ 7. 결론

내용

Auto Increment Gap은 전통적인 RDBMS 환경에서는 본질적으로 피할 수 없음

Redis는 싱글스레드 기반이라 Gap 없이 빠르고 순차적인 ID 발급 가능, 단 단일 장애지점 대비 필요

Kafka 단일 파티션 offset은 절대 순차 ID로 활용 가능하며, Gap 없음, 수만 TPS까지 실현 가능 (튜닝 필요)

Kafka는 순차성과 성능을 동시에 만족시키는 좋은 대안, 특히 ID 발급 전용 토픽으로 사용할 경우 유용

대규모 시스템에선 전용 ID 발급 서비스 또는 Hybrid 전략(Redis + Kafka) 조합이 현실적