서비스가 커지면 무조건 NoSQL로 이전해야 한다는 오해가 흔합니다. 글로벌 사진 공유 플랫폼인 인스타그램은 핵심 데이터 저장소로 PostgreSQL을 사용해 20억 사용자 규모를 달성했습니다. 기술 스택을 성급히 바꾸기 전에 기존 시스템의 병목을 하나씩 해결한 과정에서 실무적인 힌트를 얻을 수 있습니다.

병목의 원인과 연결 관리

초기 성장의 첫 장벽은 데이터 크기보다 데이터베이스 커넥션 수의 폭발이 더 큰 문제였습니다. 인스턴스 급증으로 DB 연결이 늘어나 메모리가 바닥나자 연결 풀링 도구인 PgBouncer 를 도입해 수많은 애플리케이션 커넥션을 소수의 실제 연결로 제한했고 시스템은 빠르게 안정을 찾았습니다.

대다수 팀은 트래픽이 몰리면 데이터베이스 자체를 교체하려는 유혹에 빠집니다. 대개 진짜 문제는 도구 자체가 아니라 주변 설계에서 발생합니다. 인스타그램은 단 한 대의 장비로 모든 메타데이터를 처리하며 버텼습니다. 값비싼 시스템 교체 대신 병목을 정밀하게 추적하는 실용적인 방식을 택한 결과입니다.

논리 샤딩과 전역 ID 설계

물리 장비와 논리 샤드를 완전히 분리하는 구조가 시스템 유연성을 확보하는 열쇠입니다. 사용자 ID를 기준으로 데이터를 쪼개되 실제 장비 주소와 매핑하는 테이블을 별도로 관리했습니다. 장비 용량이 부족해지면 논리 샤드만 새 장비로 이전하면 되므로 구조가 깔끔합니다.

샤딩을 조기 도입하면 복잡도가 올라가므로 샤드 키 설정부터 신중해야 합니다. 인스타그램은 사용자 데이터를 한 샤드에 몰아넣어 개별 조회 속도를 보장했습니다. 다중 샤드 조회 시 발생하는 네트워크 비용은 캐시 계층을 두어 효율적으로 보완했습니다.

여러 장비로 쪼개진 환경에서는 중복되지 않는 고유 키 발급이 아주 까다롭습니다. 인스타그램은 시간 정보와 샤드 번호, 순번을 조합한 64비트 Snowflake 방식을 내부 함수로 구현했습니다. 이 방식은 정렬이 쉽고 중앙 발급 장비가 멈춰 전체 시스템이 마비되는 단일 장애점을 안정적으로 피했습니다.

내장 기능 활용 극대화

새로운 기술을 도입하는 비용보다 데이터베이스 내장 기능을 활용하는 편이 훨씬 저렴합니다. 최근 30일 데이터만 인덱싱하는 partial index 로 색인 크기를 대폭 줄여 확실한 효과를 보았습니다. 가공 값을 색인하는 functional index 와 실시간 데이터 전송을 돕는 logical replication 도 유용하게 쓰입니다.

새로운 NoSQL 엔진을 도입하면 팀이 감당해야 할 기술 부채와 운영 비용이 배로 늘어납니다. 운영 도구 구축과 인력 채용 등 모든 과정이 비용이므로 기존 도구를 깊이 이해하고 활용하는 편이 낫습니다. 특수 목적이 아니라면 이미 검증된 데이터베이스의 최적화만으로도 대규모 트래픽을 견딥니다.

유행하는 기술을 쫓기보다 현재 시스템의 진짜 문제를 파악하는 태도가 훌륭한 엔지니어링을 만듭니다. 중요한 것은 기술 자체가 아니라 문제를 해결하는 방식입니다.

요약

  • 성급한 NoSQL 전환보다 현재 데이터베이스의 커넥션 풀링(PgBouncer) 등 병목 지점을 먼저 해결하는 것이 효율적입니다.
  • 물리 장비와 논리 샤드를 분리하여 매핑 테이블로 관리하면 데이터 재분배와 서버 확장이 매우 유연해집니다.
  • UUID나 중앙 발급 방식 대신 시간과 샤드 ID를 조합한 Snowflake 방식의 고유 ID를 설계하여 분산 환경의 정렬과 성능을 모두 잡을 수 있습니다.