<aside> 🌐 🔗 참조 기사 읽기
</aside>
1. 핵심 요약
- OpenAI는 8억 명의 사용자를 처리하면서도 분산 데이터베이스나 샤딩 클러스터가 아닌 단일 PostgreSQL 인스턴스를 활용하고 있습니다.
- 핵심은 워크로드 패턴과 운영 제약 조건을 기반으로 아키텍처 결정을 내리고, 불필요한 재구축 대신 기존 시스템을 적극적으로 최적화하는 데 있습니다.
- 캐시 잠금, 커넥션 풀링, ORM 쿼리 검토, 엄격한 운영 규율 등 다층적인 운영 방어 체계를 구축하여 안정적인 서비스를 유지하고 있습니다.
2. 기사 상세 번역
PostgreSQL의 재조명
벡터 데이터베이스가 여전히 유효한 사용 사례를 가지고 있지만, OpenAI를 포함한 많은 조직들이 실제 업무 처리를 위해 PostgreSQL에 의존하고 있습니다.
8억 명 사용자를 위한 단일 PostgreSQL 인스턴스
OpenAI는 ChatGPT와 API 플랫폼의 8억 명 사용자를 단일 프라이머리 PostgreSQL 인스턴스에서 운영하고 있습니다. 분산 데이터베이스도, 샤딩 클러스터도 아닌 단일 Azure PostgreSQL Flexible Server가 모든 쓰기 작업을 처리하며, 거의 50개의 읽기 복제본이 여러 지역에 분산되어 읽기 요청을 처리합니다. 이 시스템은 초당 수백만 건의 쿼리를 처리하면서도 낮은 두 자릿수의 99번째 백분위수(p99) 지연 시간과 5개의 9(five-nines) 수준의 가용성을 유지합니다.
기존 시스템 최적화의 중요성
이러한 설정은 기존의 확장성 지혜에 도전하며, 대규모 환경에서 실제로 효과적인 아키텍처에 대한 통찰력을 제공합니다. 중요한 교훈은 OpenAI의 스택을 그대로 복사하는 것이 아니라, 아키텍처 결정이 규모에 대한 공포나 유행하는 인프라 선택이 아닌 워크로드 패턴과 운영 제약 조건에 의해 주도되어야 한다는 것입니다. OpenAI의 PostgreSQL 설정은 팀이 성급하게 재구축하는 대신 의도적으로 최적화할 때 검증된 시스템이 얼마나 확장될 수 있는지를 보여줍니다.
PostgreSQL의 역할 확대
OpenAI 엔지니어 Bohan Zhang는 기술 공개 자료에서 “수년간 PostgreSQL은 ChatGPT 및 OpenAI API와 같은 핵심 제품을 지원하는 가장 중요하면서도 눈에 띄지 않는 데이터 시스템 중 하나였다”라고 밝혔습니다. 또한 “지난 한 해 동안 PostgreSQL의 부하는 10배 이상 증가했으며, 계속해서 빠르게 증가하고 있다”고 덧붙였습니다.
핵심 최적화 전략
OpenAI는 커넥션 시간을 50밀리초에서 5밀리초로 단축하는 커넥션 풀링과 캐시 미스가 데이터베이스 과부하를 유발하는 ‘썬더링 허드(thundering herd)’ 문제를 방지하기 위한 캐시 잠금 등 타겟팅된 최적화를 통해 이러한 규모를 달성했습니다.
기업을 위한 PostgreSQL의 중요성
PostgreSQL은 ChatGPT와 OpenAI API 플랫폼의 운영 데이터를 처리합니다. 워크로드가 읽기 중심적이기 때문에 PostgreSQL이 적합합니다. 그러나 PostgreSQL의 멀티버전 동시 제어(MVCC)는 과도한 쓰기 부하 하에서 문제를 야기합니다.
데이터를 업데이트할 때 PostgreSQL은 전체 행을 복사하여 새 버전을 생성하므로 쓰기 증폭이 발생하고 쿼리가 현재 데이터를 찾기 위해 여러 버전을 스캔해야 합니다.
OpenAI는 이러한 제한 사항에 맞서 싸우기보다는 이를 기반으로 전략을 구축했습니다. OpenAI의 규모에서는 이러한 트레이드오프가 이론적인 문제가 아니라 PostgreSQL에 유지할 워크로드와 다른 곳으로 이동해야 할 워크로드를 결정합니다.
PostgreSQL 최적화 방안
일반적인 데이터베이스 지혜는 대규모 환경에서 PostgreSQL을 여러 프라이머리 인스턴스로 샤딩하여 쓰기를 분산하거나, 대규모 확장을 위해 설계된 CockroachDB 또는 YugabyteDB와 같은 분산 SQL 데이터베이스로 마이그레이션하는 두 가지 경로를 제시합니다. 대부분의 조직은 8억 명의 사용자에 도달하기 훨씬 전인 수년 전에 이러한 경로 중 하나를 선택했을 것입니다.
샤딩 또는 분산 SQL 데이터베이스로의 마이그레이션은 단일 쓰기 병목 현상을 제거합니다. 분산 SQL 데이터베이스는 이러한 조정을 자동으로 처리하지만, 두 가지 접근 방식 모두 상당한 복잡성을 초래합니다. 애플리케이션 코드는 올바른 샤드로 쿼리를 라우팅해야 하고, 분산 트랜잭션을 관리하기가 더 어려워지며, 운영 오버헤드가 크게 증가합니다.
OpenAI는 PostgreSQL을 샤딩하는 대신 하이브리드 전략을 채택했습니다. 즉, PostgreSQL에 새로운 테이블을 추가하지 않고, 새로운 워크로드는 Azure Cosmos DB와 같은 샤딩 시스템을 기본적으로 사용하며, 수평 분할이 가능한 기존 쓰기 중심 워크로드는 마이그레이션합니다. 나머지는 공격적인 최적화를 통해 PostgreSQL에 유지합니다.
이러한 접근 방식은 기업이 전체 재구축에 대한 실용적인 대안을 제공합니다. 수백 개의 엔드포인트를 몇 년 동안 다시 작성하는 대신, 팀은 특정 병목 현상을 식별하고 해당 워크로드만 목적에 맞는 시스템으로 이동할 수 있습니다.
시사점
OpenAI의 PostgreSQL 확장 경험은 기업이 규모에 관계없이 채택할 수 있는 몇 가지 실천 방안을 제시합니다.
- 다층적인 운영 방어 체계 구축: OpenAI는 캐시 잠금, 커넥션 풀링(커넥션 시간 50ms에서 5ms로 단축), 애플리케이션, 프록시, 쿼리 수준에서 속도 제한 등 다층적인 접근 방식을 결합합니다. 워크로드 격리는 우선순위가 낮은 트래픽과 높은 트래픽을 별도의 인스턴스로 라우팅하여 최적화되지 않은 새 기능이 핵심 서비스 성능을 저하시키지 않도록 합니다.
- 프로덕션 환경에서 ORM 생성 SQL 검토: Django, SQLAlchemy, Hibernate와 같은 객체 관계 매핑(ORM) 프레임워크는 애플리케이션 코드에서 데이터베이스 쿼리를 자동으로 생성하여 개발자에게 편리함을 제공합니다. 그러나 OpenAI는 트래픽이 급증했을 때 여러 심각한 사고를 유발한 12개의 테이블을 조인하는 ORM 생성 쿼리를 발견했습니다. 프레임워크가 SQL을 생성하도록 허용하는 편리함은 프로덕션 부하 하에서만 나타나는 숨겨진 확장성 위험을 초래합니다. 이러한 쿼리를 검토하는 것을 표준 관행으로 삼아야 합니다.
- 엄격한 운영 규율 시행: OpenAI는 경량 스키마 변경만 허용하며, 전체 테이블 재작성을 유발하는 변경은 금지합니다. 스키마 변경에는 5초의 제한 시간이 적용됩니다. 장시간 실행되는 쿼리는 데이터베이스 유지 관리 작업을 차단하지 않도록 자동으로 종료됩니다. 데이터를 백필할 때 공격적인 속도 제한을 적용하여 작업이 일주일 이상 걸릴 수 있습니다.
읽기 중심 워크로드와 버스트 쓰기가 있는 경우 단일 프라이머리 PostgreSQL에서 예상보다 오래 실행할 수 있습니다. 샤딩 결정을 내릴 때는 사용자 수보다 워크로드 패턴에 따라 결정해야 합니다.
이러한 접근 방식은 특히 워크로드가 읽기 중심적이고 예측할 수 없는 트래픽 급증이 발생하는 AI 애플리케이션에 적합합니다. 이러한 특성은 단일 프라이머리 PostgreSQL이 효과적으로 확장되는 패턴과 일치합니다.
결론은 간단합니다. 실제 병목 현상을 식별하고, 가능한 경우 검증된 인프라를 최적화하고, 필요한 경우 선택적으로 마이그레이션합니다. 전체 재구축은 항상 확장 문제에 대한 답이 아닙니다.
3. 기술 용어 해설
- PostgreSQL: 오픈 소스 관계형 데이터베이스 관리 시스템(RDBMS)으로, 안정성과 확장성이 뛰어나 다양한 산업 분야에서 널리 사용됩니다.
- Vector Database: 벡터 임베딩을 저장하고 검색하는 데 최적화된 데이터베이스로, AI 및 머신러닝 애플리케이션에서 유사성 검색에 주로 사용됩니다.
- 샤딩(Sharding): 대규모 데이터베이스를 여러 개의 작은 데이터베이스(샤드)로 분할하여 분산 저장하고 관리하는 기술입니다.
- MVCC (Multiversion Concurrency Control): 다중 버전 동시성 제어. 데이터베이스에서 동시성을 관리하는 방법 중 하나로, 각 트랜잭션이 데이터의 특정 버전을 보게 하여 충돌을 방지합니다.
- ORM (Object-Relational Mapping): 객체 관계 매핑. 프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블 간의 데이터 변환을 자동화하는 기술입니다.
- p99 (99th Percentile): 99번째 백분위수. 전체 요청 중 99%가 이 값 이하의 응답 시간을 갖는다는 의미입니다. 성능 측정 지표로 사용됩니다.
- 5개의 9 (five-nines): 99.999%의 가용성을 의미합니다. 연간 다운타임이 약 5분 15초 이하임을 나타냅니다.
4. 수석 분석가의 Insight
OpenAI의 사례는 대규모 서비스 확장 시 무조건 최신 기술을 도입하거나 분산 시스템으로 전환하는 것이 아니라, 기존 시스템의 잠재력을 최대한 활용하는 것이 더 효율적일 수 있음을 보여줍니다. 국내 IT 업계는 이 사례를 통해 불필요한 기술 스택 복잡성을 줄이고, 핵심 워크로드에 집중하여 성능 최적화를 추진하는 전략적 접근 방식을 고려해야 할 것입니다. 특히 AI 서비스 개발 시에는 읽기 중심적인 워크로드 특성을 고려하여 PostgreSQL과 같은 검증된 RDBMS를 적극적으로 활용하는 방안을 모색할 필요가 있습니다.
AI검색 기반 자료입니다. 중요한 정보인 경우 다시 확인해주세요.
댓글, 공감 버튼 한 번씩 누르고 가주시면 큰 힘이 됩니다