본문으로 이동
H/ACCH/ACC
컴퓨팅 인프라 ／ 기술 진전

OpenAI가 공유 스토리지의 속도와 자원 격리를 개선하다

H/ACC · AI 보조 편집자료 공개일 편집일 2026-10-23

이번 진전

OpenAI는 Habitat의 전 세계 읽기 요청 지연 시간 중앙값을 약 120밀리초에서 약 10밀리초로 줄였다고 밝혔다. 이번 엔지니어링 회고는 요청의 우선순위, 데이터 배치, 캐시를 함께 다루며 공유 자원이 제품팀의 용량 계획 부담을 어떻게 줄이는지도 보여준다.

핵심 판단AI 보조 분석

공유 플랫폼이 용량 배분과 캐시 관리를 맡으면 제품팀은 공통 엔지니어링 역량을 재사용할 수 있다. 읽기 성능은 데이터 배치, 캐시, 서비스 처리 부담을 함께 최적화해 개선하며, 작업 부하의 우선순위는 더 많은 서비스가 자원을 안정적으로 공유하도록 돕는다.

사실 분석

읽기 요청의 지연 시간 중앙값이 약 10밀리초로 줄었다

OpenAI가 10월 23일 공개한 두 번째 Habitat 엔지니어링 회고에 따르면, 올해 성능 최적화에 집중하기 시작한 뒤 전 세계 읽기 요청의 p50 지연 시간이 약 120밀리초에서 약 10밀리초로 줄었다. p50은 중앙값으로, 요청의 절반이 이 값 이하의 시간에 처리된다는 뜻이다.

자료는 데이터를 요청과 가까운 곳에 배치하고, 일부 핵심 데이터의 사본을 여러 지역에 추가하며, 캐시를 통합하고, 서비스를 Rust로 다시 작성한 것을 최적화 방법으로 제시한다. 이 수치는 내부 스토리지 읽기 요청을 측정한 결과다. 여러 개선이 함께 작용했으며, 글에는 각 개선의 기여도를 따로 비교할 수 있는 완전한 자료가 없다.

공유 자원과 전용 자원에는 각각 어떤 비용이 따르는가

Habitat은 처음에 여러 서비스가 기본 Azure Cosmos DB 컨테이너를 함께 사용하도록 했다. 공식 회고는 같은 물리적 파티션에 있는 서비스들이 처리 용량을 놓고 경쟁해, 특정 데이터에 몰리는 요청이 다른 서비스에 영향을 줄 수 있었다고 설명한다. 이후 팀은 핵심 서비스에 별도 컨테이너를 배정해 장애의 영향 범위를 줄였다. 다만 각 제품팀이 필요한 용량을 미리 추정하고 설정해야 했다.

이후 팀은 Azure와 협력해 요청이 집중되는 키의 처리량을 제한하고, 대량 데이터 입력과 추출 같은 백그라운드 요청의 우선순위를 낮추며, 부하에 따른 용량 확장 기능을 개선했다. 이런 조건을 갖춘 뒤 플랫폼은 다시 공유 컨테이너를 기본 방식으로 삼고, 용량 계획 업무를 공동으로 운영하는 인프라 계층에 더 많이 맡겼다.

캐시는 요청 가까이에 두고 데이터가 바뀌면 무효화한다

Habitat은 최근 접근한 데이터의 사본을 요청 처리 위치와 가까운 Valkey 캐시에 저장한다. 기반 데이터베이스에 변경이 생기면 변경 데이터 캡처 기능이 캐시 무효화 작업을 전 세계에 전파한다. 원문은 이 전파가 수초 단위로 이뤄진다고 설명한다. 이후 읽기 요청에서 캐시에 데이터가 없으면 스토리지 계층에서 최신 버전을 가져와 캐시를 다시 채운다.

여러 곳에 다수의 사본을 두는 방식은 인증 메타데이터처럼 크기가 작고 지연 시간에 특히 민감한 데이터에만 적용한다. 원문은 데이터를 요청 가까이에 배치하는 데도 지역별 스토리지, 전력, 냉각 용량의 제약이 있다고 설명한다. 가장 느린 요청 중 일부는 여전히 다른 지역에서 캐시되지 않은 데이터를 읽어 와야 한다.

H/ACC의 관점

기다리는 순서를 공유 자원의 규칙으로 정한다

H/ACC 편집 해석: 이번 개선의 의미는 공유 용량을 더 명확한 규칙에 따라 배분하는 데 있다. 사용자와 상호작용하는 요청과 대규모 백그라운드 작업은 처리 속도에 대한 요구가 다르다. 먼저 요청이 몰리는 지점을 제한하고 어떤 작업이 기다려도 되는지 정하면, 남는 용량을 함께 사용하면서도 한 작업의 부하가 갑자기 커져 다른 서비스를 지연시킬 가능성을 줄일 수 있다.

따라서 작업 부하 사이의 자원 격리는 요청을 어떤 순서로 처리하느냐에도 달려 있다. 서비스마다 별도 자원을 준비하는 것만이 방법은 아니다. 이를 위해서는 시스템이 부하를 식별하고 우선순위를 적용하며 이상을 감시해야 한다. 용량 활용률과 핵심 요청의 안정성은 같은 부하 시험 조건에서 함께 평가할 필요가 있다.

제품팀이 공통 시스템의 역량을 활용하게 한다

데이터 배치, 캐시 갱신, 용량 관리를 공유 플랫폼에 모으면 제품팀은 축적된 엔지니어링 역량을 재사용할 기회를 얻는다. 새 기능을 연결할 때 반복해서 풀어야 하는 문제는 줄어들고, 데이터베이스팀과 클라우드 플랫폼팀은 용량 확장, 요청 집중, 장애 복구를 전담할 수 있다. 이는 인프라가 제품 개발의 효율을 높이는 구체적인 경로다.

다음으로 살펴볼 것은 빠른 요청 이외의 경험이다. 캐시에 데이터가 없거나 다른 지역에 접근하거나 백그라운드 작업과 자원을 두고 경쟁할 때도 대기 시간을 예측할 수 있는지가 중요하다. 중앙값은 일반적인 요청의 개선을 보여준다. 반면 느린 요청의 지연 시간과 데이터의 최신성은 그 개선이 어떤 사용 상황까지 이어지는지를 결정한다.

판단의 한계

  • 성능 수치와 운영 경험은 OpenAI가 직접 공개한 내용이며, 이 글에서 실험을 독립적으로 재현하지 않았다. 10월 23일은 회고 자료의 공개일이며 모든 개선이 그날 완료됐다는 뜻은 아니다.
  • 약 120밀리초에서 약 10밀리초로 줄었다는 수치는 Habitat 스토리지 읽기 요청의 전 세계 p50이다. 이를 모델의 생성 속도나 ChatGPT 전체 응답 시간이 같은 비율로 개선됐다는 뜻으로 환산할 수 없다.
  • 수초 단위의 캐시 무효화 전파는 읽기 시점에 항상 최신 데이터가 보장된다는 뜻이 아니다. 다른 지역의 캐시에 데이터가 없는 경우와 지역별 물리적 용량 제약은 별도로 평가해야 한다.

다음에 살펴볼 것AI 보조 분석

  1. 앞으로 공개할 데이터가 캐시 적중 여부와 같은 지역·다른 지역 접근을 구분해 읽기 요청의 p95와 p99를 보여줄 것인가? 이를 통해 중앙값 개선이 느린 요청에도 이어졌는지 확인할 수 있을까?
  2. 특정 키에 요청이 몰리는 상황과 대량 쓰기가 동시에 발생하는 부하 시험에서도 사용자와 상호작용하는 요청의 오류율과 느린 요청의 지연 시간이 안정적으로 유지되는가? 백그라운드 작업은 얼마나 기다려야 하는가?

참고 자료

이 콘텐츠에서 참고한 보도와 연구 자료입니다.

  1. Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)OpenAI · Jon Lee, Hrachya Hakobyan, Chaomin Yu · 자료 공개일 2026-10-23

주제 계속 보기

이어서 읽기

OpenAI가 오프라인 학습과 상시 레드팀 검증을 격리 체계에 반영하다OpenAI, 반복되는 작은 판단을 전용 API로 제공
피드로 돌아가기