Instagram ID 샤딩 전략을 쉽게 이해해보자.

📸 Instagram ID 샤딩 전략

Instagram이 대규모 분산 시스템에서 고유한 ID를 생성하는 방법

🔢 64비트 ID 구조

Timestamp

41 bits

밀리초 타임스탬프

Shard ID

13 bits

샤드 식별자

Sequence

10 bits

자동 증가 시퀀스

부분	비트 수	최대 값	설명
타임스탬프	41 bits	2^41 ≈ 69년	커스텀 epoch 이후의 밀리초. 시간 순 정렬 가능
샤드 ID	13 bits	2^13 = 8,192	논리적 샤드 식별. 데이터 위치 결정
시퀀스	10 bits	2^10 = 1,024	샤드당 밀리초당 1,024개 ID 생성 가능

🏗️ 샤딩 아키텍처

논리적 샤드

Shard 1

Shard 2

Shard 3

...

Shard 2000

수천 개의 논리적 샤드

⟹

물리적 서버

PostgreSQL 서버 1
Schema 1, 2, 3...

PostgreSQL 서버 2
Schema 500, 501...

PostgreSQL 서버 3
Schema 1000, 1001...

적은 수의 물리적 서버

핵심 아이디어: 논리적 샤드를 코드에서 물리적 서버로 매핑. 데이터 재구성 없이 샤드를 다른 서버로 쉽게 이동 가능!

📝 ID 생성 예제

시나리오

• 날짜: 2011년 9월 9일 오후 5시
• Epoch: 2011년 1월 1일
• 사용자 ID: 31,341
• 논리적 샤드 개수: 2,000개

1 타임스탬프 계산

Epoch 이후 경과 시간: 1,387,263,000 밀리초 왼쪽 23비트 시프트: 1387263000 << 23 결과: 최상위 41비트 채우기

2 샤드 ID 계산

사용자 ID로 샤딩: 31341 % 2000 = 1341 왼쪽 10비트 시프트: 1341 << 10 결과: 다음 13비트 채우기

3 시퀀스 번호 추가

PostgreSQL nextval() 호출 시퀀스 값 % 1024 결과: 마지막 10비트 채우기

4 최종 ID 조합

ID = (timestamp << 23) | (shard_id << 10) | (sequence % 1024) 결과: 64비트 고유 ID 생성 완료!

💻 PostgreSQL 구현

CREATE OR REPLACE FUNCTION insta5.next_id(OUT result bigint) AS $$ DECLARE our_epoch bigint := 1314220021721; -- 커스텀 epoch seq_id bigint; now_millis bigint; shard_id int := 5; -- 현재 샤드 ID BEGIN -- 1. 시퀀스 번호 가져오기 (1024로 나눈 나머지) SELECT nextval('insta5.table_id_seq') % 1024 INTO seq_id; -- 2. 현재 밀리초 타임스탬프 SELECT FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 1000) INTO now_millis; -- 3. ID 조합 result := (now_millis - our_epoch) << 23; -- 타임스탬프 result := result | (shard_id << 10); -- 샤드 ID result := result | (seq_id); -- 시퀀스 END; $$ LANGUAGE PLPGSQL;

✨ 주요 장점

⏰ 시간 순 정렬

ID에 타임스탬프가 포함되어 있어 추가 쿼리 없이 시간순 정렬 가능

🎯 샤드 식별

ID에서 샤드 정보를 추출하여 어느 DB를 쿼리할지 즉시 파악

🚀 단순성

별도의 ID 생성 서비스 불필요. PostgreSQL 내부에서 모두 처리

📈 확장성

데이터 재구성 없이 논리적 샤드를 새 서버로 이동 가능

⚡ 높은 처리량

샤드당 밀리초당 1,024개 ID 생성. 병렬 처리로 전체 처리량 극대화

💾 효율적 저장

64비트로 컴팩트. Redis 등에서 효율적으로 저장 가능

🔍 다른 솔루션과의 비교

솔루션	크기	시간순 정렬	복잡도	Instagram 선택 여부
UUID	128 bits	❌	낮음	❌ 너무 큼
Flickr (홀수/짝수)	64 bits	❌	중간	❌ 시간순 정렬 불가
Twitter Snowflake	64 bits	✅	높음	⚠️ 별도 서비스 필요
Instagram 방식	64 bits	✅	낮음	✅ 선택!

📊 성능 지표

처리량 계산

• 샤드당 처리량: 1,024 IDs/밀리초 = 1,024,000 IDs/초
• 2,000개 논리적 샤드: 2,048,000,000 IDs/초 (이론적 최대)
• 실제 Instagram 부하: 초당 사진 25개 + 좋아요 90개 = 115개/초
• 여유: 이론적 최대치의 0.000006% 사용 중 (충분한 확장 여력)

🎓 핵심 교훈

1. 단순함이 최고: 복잡한 외부 서비스 대신 기존 DB 기능 활용
2. 현명한 차용: Twitter Snowflake 아이디어를 차용하되 상황에 맞게 변형
3. 논리적 추상화: 논리적 샤드와 물리적 샤드 분리로 확장성 확보
4. 스케일링 전략: 적은 엔지니어로 1,400만+ 사용자 지원 가능

📚 참고 자료

• 원문: Sharding & IDs at Instagram
• Twitter Snowflake: 분산 ID 생성 시스템의 영감
• PostgreSQL Schemas: 논리적 그룹화 기능
• PL/PGSQL: PostgreSQL의 내장 프로그래밍 언어