10P by GN⁺ 8일전 | ★ favorite | 댓글 2개

"Colossus 상태 기반 프로토콜"은 Rapid Storage의 고성능을 위한 비밀 재료임

  • Google Cloud Storage는 단순성과 확장성으로 널리 사용됨
  • 기존 REST 기반의 무상태 프로토콜은 사용이 간편하지만, AI 및 데이터 집약적 워크로드에는 지연 시간과 파일 중심 기능 부족이 문제가 됨
  • Rapid Storage는 상태 기반 gRPC 스트리밍 프로토콜을 도입해 이 문제를 해결하며, 객체 스토리지의 확장성과 처리량은 그대로 유지함

Colossus 기반 아키텍처의 강점

  • Colossus는 Google 내부의 클러스터 수준 파일 시스템으로, 고성능 제품을 위한 기반 기술임
  • 상태 기반 프로토콜을 사용해 초저지연 데이터 읽기/쓰기 지원
  • 클라이언트는 파일을 열어 핸들(handle) 을 받고, 이를 통해 직접 디스크와 통신 가능
  • RDMA 유사 프로토콜을 활용해 빠른 접근이 가능하며, SSD 최적화 및 병렬 쓰기 기술 적용
  • 내구성이 요구되는 로그 쓰기와 스트리밍 분석 워크로드에 적합함

Colossus 상태 기반 프로토콜의 작동 방식

  • 파일을 append 모드로 열면 Curator가 핸들을 생성해 클라이언트에 전달함
  • 애플리케이션은 로그 데이터를 클라이언트에 쓰고, 클라이언트는 핸들을 이용해 여러 디스크에 병렬로 쓰기 수행
  • 데이터를 내구성 있게 저장하기 위해 복수의 디스크에 복제, 쿼럼 기반 쓰기로 지연 최소화

Rapid Storage의 성능 및 활용 예

  • Cloud Storage 클라이언트는 gRPC 스트림 생성 시 인증 및 메타데이터 접근을 선처리함
  • 이후의 읽기/쓰기는 Colossus에 직접 연결되므로 초저지연 유지
  • 한 버킷당 초당 2천만 요청 처리 가능 — 대규모 AI/ML 워크로드에 적합
  • AI/ML 학습에 최적화된 설계

    • 수억~수십억 토큰이 포함된 대형 데이터 파일을 비순차적으로 읽는 데 이상적임
    • 학습 시작 시 스트림을 생성하고, 병렬 범위 읽기를 초저지연으로 수행 가능
    • 학습 중 스토리지 지연 없이 데이터 샘플을 빠르게 공급 가능
  • 안전하고 효율적인 Append 처리

    • 하나의 객체에 대해 무제한 append 가능 (객체 크기 제한 내)
    • 핸들을 통해 스트림이 중단되어도 재연결 후 계속 읽기/쓰기 가능
    • 한 번에 하나의 스트림만 객체에 쓰기 가능 — 새 스트림이 이전 스트림을 트랜잭션 방식으로 잠금 처리
    • 각 append는 쓰는 오프셋을 명시해 데이터 일관성 보장

Rapid Storage 통합 및 API

  • gRPC 기반 append 기능을 지원하도록 SDK 업데이트 중
  • Cloud Storage FUSE에 통합되어 파일 시스템처럼 Cloud Storage 버킷 접근 가능
  • Hierarchical Namespace와도 연계되어 성능 및 일관성 강화, 폴더 기반 API 지원

Rapid Storage의 결합적 장점

  • 블록 스토리지 수준의 초저지연
  • 병렬 파일 시스템 수준의 높은 처리량
  • 객체 스토리지의 확장성과 간편함까지 제공

Colossus가 참 좋다고 하는데, 실제로 내부에서 써보신 분들은 어떤지 궁금하네요.

Hacker News 의견
  • Google이 주요 클라우드 중 유일하게 저지연 단일 존 객체 저장소, 표준 지역 객체 저장소, 투명하게 복제된 이중 지역 객체 저장소를 동일한 API로 제공함
    • 인프라 시스템에서는 GCS API를 사용하여 코드 작성 후 사용자가 비용, 지연 시간, 내구성의 균형을 선택할 수 있음
  • 2025 Google Next 컨퍼런스에서 발표되었으며, Rapid Storage를 위한 gRPC 클라이언트를 공개함
    • 이는 Colossus 자체의 얇은 래퍼로 보이며, 단일 존 저장소임
  • 과학적 컴퓨팅 속도를 실제로 높일 수 있을 것 같음
    • 데이터 로컬화/비로컬화가 전체 인스턴스 실행 시간의 중요한 부분임
  • 고전적인 마이크로서비스 비디오를 다시 봐야 했음
    • Colossus를 사용했다고 확신했지만 실제로는 Galactus & Omega Star였음
  • 이 링크가 이전 링크보다 훨씬 더 이해가 잘 됨
  • SSD의 높은 랜덤 I/O 속도가 장점에 크게 기여함
    • 20m 초당 쓰기 속도는 드라이브 네트워크에 분산되어 가능할 것 같음
  • 단일 존 객체 저장소가 성공적으로 자리 잡는 것을 보니 기쁨
    • 엄청난 대역폭 속도가 데이터 분석을 재정의할 것임
    • 99%의 모든 쿼리가 단일 노드에서 분산 컴퓨팅보다 빠르게 실행 가능함
  • Chubby를 서비스로 제공받고 싶음
    • etcd와 zookeeper를 버릴 수 있음
  • S3 express one zone과 유사함
  • 개인 초대 전용 anywhere caches와 관련이 있는지 궁금함
    • 또는 이제 GA일 수도 있음