Intercom의 200만 QPS 달성을 위한 데이터베이스 스케일링 전략

도입

Intercom의 스태프 제품 엔지니어 유진은 2013년부터 현재까지 Intercom이 2백만 QPS(초당 쿼리 수)를 처리하기 위해 데이터베이스를 어떻게 확장해왔는지에 대한 여정을 공유합니다. 창립 초기부터 Rails를 사용해 온 Intercom은 방대한 코드베이스와 250명 이상의 엔지니어가 협업하며, 13개의 데이터베이스에 분산된 1,000개 이상의 테이블을 운영하고 있습니다. 이 발표는 Intercom이 직면했던 다양한 데이터베이스 스케일링 문제와 이를 해결하기 위해 적용한 기술적 접근 방식들을 연대기적으로 설명합니다.

Intercom은 2013년부터 2024년까지 급격한 성장에 맞춰 다양한 데이터베이스 스케일링 전략을 단계적으로 도입했습니다.

Intercom의 데이터베이스 스케일링 여정

2013: 수직 스케일링: AWS RDS를 통해 더 큰 인스턴스로 업그레이드하여 초기 데이터베이스 용량 문제를 해결하고 성장을 위한 여유를 확보했습니다.
2014: 기능별 수평 샤딩: 신규 기능의 대규모 데이터 생성을 예측하여 전용 데이터베이스를 생성, 데이터 분리 및 스케일링 유연성을 높였습니다. 초기 Rails의 다중 데이터베이스 지원은 미흡했습니다.
2015: 애플리케이션 계층 캐싱 (Identity Cache Gem): 피크 시간대 데이터베이스 CPU 100% 문제를 해결하고자 Identity Cache Gem을 도입, 고빈도 쿼리를 캐싱하여 서비스 가용성을 확보했습니다. 현재 1,000만 건의 쿼리를 캐시에서 처리합니다.
2017: 읽기 복제본 활용: 메인 데이터베이스의 부하를 분산하기 위해 Mara Gem을 이용해 읽기 쿼리를 복제본으로 라우팅하고 일관성을 보장했습니다. 이후 Rails 자체 지원으로 전환했습니다.
2019: 테이블별 수평 샤딩: 250억 개 행의 conversations 테이블 마이그레이션 어려움을 해결하고자 고객별로 테이블을 분할하여 스키마 변경 관리 용이성을 높였습니다.
2024: PlanetScale 마이그레이션: Amazon Aurora 2 EOL 및 다운타임 위험에 대응하여 PlanetScale(Vitess 기반)으로 전환했습니다. 이는 제로 다운타임 업그레이드와 통합 샤딩 관리를 제공하여 운영 효율성을 극대화했습니다.

결론

Intercom의 데이터베이스 스케일링 여정은 단일 데이터베이스에서 시작하여 13개 이상의 데이터베이스와 복잡한 샤딩, 캐싱 전략을 거쳐 PlanetScale과 같은 최신 관리형 서비스로 진화했음을 보여줍니다. 각 단계에서 Intercom은 특정 문제에 직면하여 해결책을 모색했으며, 때로는 단기적인 복잡성을 감수하고 장기적인 가용성과 확장성을 확보했습니다. 특히 Rails의 다중 데이터베이스 지원 발전과 같은 기술적 변화를 활용하고, Identity Cache Gem과 같은 오픈 소스 도구를 적극적으로 도입하며 2백만 QPS라는 엄청난 규모를 성공적으로 감당할 수 있었습니다. 이 경험은 성장하는 기업이 데이터베이스 스케일링에 접근하는 실용적이고 점진적인 방법을 제시합니다.

Intercom의 200만 QPS 달성을 위한 데이터베이스 스케일링 전략

Eugene Kenny, Scaling Rails to 2M MySQL requests per second. San Francisco Ruby Conference 2025.

핵심 요약

도입

Intercom의 데이터베이스 스케일링 여정

결론

관련 글들

대규모 Rails 애플리케이션의 스키마 마이그레이션 관리: Intercom 사례

Rails 애플리케이션 확장을 위한 모범 사례

Buildkite의 PostgreSQL 데이터베이스 샤딩 여정: 대규모 데이터베이스 문제 해결 및 시스템 개선

Heroku에서 단일 PostgreSQL을 사용하는 Rails 모놀리스의 스케일링 교훈

댓글 0

로그인이 필요합니다

아직 댓글이 없습니다