심층 해설 · 약 5분 읽기
OpenAI의 Habitat 재설계: 공유 용량, 지역 캐시와 조건이 붙는 읽기 12배 개선
Cosmos DB 테넌시, CDC 무효화와 Rust를 설명한 OpenAI. 읽기 중앙값 개선은 여러 변경을 합친 결과다.
- 사이트 게시일
- 원문 게시일
- 출처 확인일
OpenAI는 10월 23일 기술 글에서 Habitat의 Azure Cosmos DB 저장소와 읽기 경로를 어떻게 바꿨는지 설명했다. 운영상의 선택과 회사가 보고한 측정치에 관한 글이며, 새 모델이나 공개 저장소 상품 출시는 아니다.
뉴스 듣기
이 기사를 읽어 드리거나 뉴스를 계속 재생합니다.
읽기를 준비하는 중…
기기 음성
읽기는 브라우저나 기기에서 처리합니다. AISubHub는 내용을 오디오 API로 보내지 않습니다. 사용 가능한 음성과 잠금 화면 재생은 기기에 따라 다릅니다.
계속 재생할 때 짧은 구절이 반복될 수 있습니다.
핵심 요약
- OpenAI는 전 세계 읽기 p50이 약 120ms에서 10ms로 줄어든 원인을 데이터 배치, 지역 캐시, Rust 재작성의 조합으로 설명한다. 느린 캐시 미스는 여전히 먼 저장소에 접근한다.
- Habitat는 공유 컨테이너에서 격리로 전환한 뒤 Azure 공동 개발을 거쳐 공유를 기본값으로 되돌렸다. 별도의 엑사바이트 규모 시스템은 개발 중이다.
공유 저장소가 무관한 기능을 제한한 이유
OpenAI는 Habitat가 500PB가 넘는 데이터를 관리하며 40개 지역에서 10억 명 넘는 사용자에게 서비스를 제공하는 제품을 지원한다고 설명한다. 저자가 제시한 규모이며 독립 사용자 통계나 이번에 늘어난 사용자 수가 아니다. 핵심 문제는 용량을 합치면서 한 기능이 다른 기능에 피해를 주지 않게 하는 것이다. 처음에는 Cosmos DB 계정마다 기본 컨테이너 하나를 쓰고 클라이언트가 논리 파티션 키를 골랐다. 흔한 식별자가 겹치면 서로 다른 용도가 같은 키의 한도를 나눠 쓰게 됐다.
RU/s는 초당 요청 단위로, 일정한 쿼리 횟수가 아니다. 초기 설계는 논리 키의 명시된 10,000RU/s 한도로 역압력을 기대했지만 실제 제한은 공유 물리 파티션에서 적용된다. 같은 물리 파티션의 무관한 키도 경쟁한다. 저장량 증가로 파티션이 나뉠 때 컨테이너 전체 처리량이 그대로라면 자식 파티션의 몫은 줄어든다. 큰 객체 위주 작업은 요청률이 일정해도 제한될 수 있다. 글의 도식은 이 메커니즘을 설명하며 도형 비율은 운영 측정값이 아니다.
격리는 피해를 줄이고 용량 계획 부담을 늘렸다
전용 컨테이너는 중요한 서비스에 독립 물리 파티션을 제공해 시끄러운 이웃의 영향 범위를 줄였다. 팀은 약한 파티션에 대응하려고 물리 파티션 수에 맞춰 프로비저닝 처리량도 조절했다. 대신 서비스마다 용량 계획을 해야 했다. 내부 시험에서 대규모 공개 트래픽으로 뛰면 작은 전용 컨테이너는 포화될 수 있지만 같은 증가가 큰 공유 풀에는 미미할 수 있다. 격리는 장애 경계를 바꿨을 뿐 출시 수요를 예상할 필요를 없애지 못했다.
Habitat는 핫키 제한, 대량 작업의 낮은 우선순위, Azure와 만든 serverless 변형을 갖추고 기본 공유로 돌아갔다. 글은 기존 물리 파티션당 5,000RU/s 상한과 맞춤 방식의 최대 10,000RU/s를 비교하며, 저장량 외에 RU 사용량으로도 분할한다고 설명한다. 특정 협업 결과이지 모든 Azure 고객이 켤 수 있다는 증거는 아니다. 본지 분석으로는 대화형 작업을 보호하는 제어와 수요에 반응하는 용량 조절이 있어야 공유 여유가 신뢰할 만한 이점이 된다.
관리형 서비스에도 공동 장애 시험이 필요했던 이유
OpenAI에 따르면 최대 Cosmos DB 계정은 수십 PB를 저장하며 초당 2,000만 회 이상의 쿼리를 처리한다. 2024년 말 정전과 약 한 달 뒤 원복 사고가 검증되지 않은 규모 가정을 드러냈다. 정전 뒤 최대 계정을 보조 지역으로 전환하는 데 수 시간이 필요하다는 점이 밝혀졌고, 약 한 달 뒤 원래 지역으로 복귀할 때 연결 폭주가 게이트웨이를 압도했다. 관련 물리 파티션이 다 돌아오기 전에 클라이언트가 연결한 것이다. 서로 다른 복구 단계의 두 사고이며 한 번의 연속 장애가 아니다.
대응은 용량 구매를 넘어섰다. Habitat와 Azure는 각 계층을 공동 감시하고 운영 크기의 비운영 계정에서 시험하며 SDK를 함께 개선하고 엔지니어 간 직접 상향 대응 경로를 운영한다. 게이트웨이 메타데이터 캐시, 부하 보호, 연결 재사용, 중요 작업과 오프라인 작업 분리도 설명한다. 본지는 다른 팀도 대표적인 규모에서 장애 전환과 원복을 모두 시험해야 한다고 추론한다. 공급자가 DB를 관리해도 고객 연결 동작, 복구 시간, 허용 피해 범위가 자동으로 검증되지는 않는다.
읽기 12배 개선에 실제 포함된 변경
OpenAI는 Habitat 요청의 90% 이상이 읽기라고 한다. 용량이 허용되면 데이터를 사용자 가까이 놓고, 작고 지연에 민감한 일부 데이터만 넓게 복제하며, 나머지 자주 쓰는 객체와 관계는 가까운 Valkey에 캐시한다. 일부 중요 계정은 서비스하는 Azure 40개 지역 모두에 복제하지만 모든 데이터가 모든 지역에 있다는 뜻은 아니다. 저장소와 연산은 전력, 냉각, 공간을 놓고 경쟁한다. 배치는 제품과 용량의 절충이며 무제한 근접성 보증이 아니다.
캐시 무효화에는 Cosmos DB 변경 피드를 쓴다. CDC 소비자가 업데이트 후 로컬 사본을 무효화하고 다음 읽기에서 다시 채운다. OpenAI는 전 세계 전파가 수 초 내에 이뤄진다고 보고해 TTL 만료에만 의존하지 않는 최신성 관리를 설명하지만 즉시 일관성을 뜻하지 않는다. Rust 재작성도 서비스 오버헤드를 낮췄다. 이 변경들을 합쳐 전 세계 읽기 p50이 약 120ms에서 10ms가 됐다. 차트는 근거리 복제, 지역 캐시, Rust를 구분한다. 12배를 Rust만의 효과나 쓰기 지연, 각 사용자의 ChatGPT 전체 응답 시간으로 확대하면 안 된다.
CDC 확장과 운영 중·개발 중 시스템의 경계
CDC는 보조 인덱스, 데이터 이동, 분석에도 쓰인다. OpenAI는 수천 컨테이너와 수백만 컨테이너 파티션에서 초당 수백만 변경이 백 개 넘는 Kafka 토픽을 거친다고 보고한다. 제어 평면이 지역과 워커를 배정하고 복제본 읽기와 낮은 우선순위로 대화형 트래픽을 보호한다. 스트림 격리, 리스 처리, 데드레터 큐, 지역 장애 시 읽는 위치 변경은 서로 다른 실패를 다룬다. 영구 실패 전달을 분리해 스트림 막힘을 방지해도 모든 하위 소비자가 최신이라는 증명은 아니다.
적용 한계도 남는다. 느린 캐시 미스는 원격 저장소에 도달하고 글에는 각 최적화를 분리한 통제 비교나 보편적인 꼬리 지연 보증이 없다. OpenAI는 Rockset의 RocksDB Cloud 코어, Raft 복제, Cosmos 호환 문서 모델을 쓰는 엑사바이트 시스템을 개발 중이다. 분리형 저장소와 물리 복제로 플래시 요구량을 줄이는 대신 최대 QPS는 낮추는 설계다. 아직 Cosmos 교체가 끝난 것이 아니다. 본지는 이 2부와 읽기 차트를 읽었으나 연결된 1부, SDK 소스나 서비스 보증을 독립적으로 검증하지 않았다.
중요한 이유
인프라 팀은 격리, 전체 용량 여유와 운영 책임의 비용을 비교할 수 있다. 캐시 최신성, 장애 복구, 꼬리 지연은 각각 별도 기준으로 검증해야 한다.
제한 및 이용 가능성
OpenAI의 주장으로, AISubHub의 재현 결과나 Azure 보증이 아니다. 맞춤 serverless의 일반 제공, 새 구독 혜택 또는 앱 전체 지연 개선을 입증하지 않는다.
출처와 근거
원문 게시일: · 출처 확인일:
AI 보조 편집 기사를 명시한 일차 출처와 대조합니다. 업체 주장은 출처를 밝히며 게재는 추천을 뜻하지 않습니다.