계층형 저장소

계층형 저장소 (Tiered Storage)

Pulsar의 토픽 백로그는 사실상 무한정 커질 수 있는데, 그만큼 시간이 지나면 비용 부담이 생기기 마련이에요. 계층형 저장소(Tiered Storage)는 오래된 메시지를 BookKeeper에서 더 저렴한 저장소로 옮겨 비용을 낮추면서도, 클라이언트는 아무 변화 없이 백로그를 그대로 사용하게 해주는 기능이에요. 이 글에서는 동작 원리와 지원하는 저장소, 그리고 실제로 설정하고 운영하는 방법을 정리해 드릴게요.

출처: 문서

본문

Pulsar의 세그먼트 기반 아키텍처 덕분에 토픽 백로그는 사실상 제한 없이 아주 크게 자랄 수 있어요. 하지만 그만큼 시간이 지나면 비용이 비싸질 수 있죠.

이 비용을 줄이는 방법 중 하나가 계층형 저장소를 사용하는 거예요. 계층형 저장소를 쓰면 백로그의 오래된 메시지를 BookKeeper에서 더 저렴한 저장 메커니즘으로 옮기면서도, 클라이언트는 아무것도 바뀌지 않은 것처럼 백로그에 계속 접근할 수 있어요.

계층형 저장소 동작 원리

계층형 저장소는 Pulsar의 세그먼트 기반 아키텍처를 활용해요. 데이터는 BookKeeper에서 불변(immutable) 세그먼트(ledger)로 저장되죠. 세그먼트가 봉인(seal)되어 읽기 전용이 되면 외부 저장 시스템으로 안전하게 오프로드할 수 있어요.

오프로딩 과정

  1. 세그먼트 봉인: BookKeeper ledger가 닫히면(크기 제한, 시간 제한, 또는 수동 트리거 때문에) 불변이 돼요.
  2. 자격 확인: 브로커가 설정된 정책에 따라 어떤 세그먼트가 오프로딩 대상인지 판단해요.
  3. 데이터 전송: 자격이 있는 세그먼트를 설정된 장기 저장 백엔드로 복사해요.
  4. 메타데이터 갱신: BookKeeper 메타데이터가 외부 저장 위치를 가리키도록 갱신돼요.
  5. 로컬 삭제: 설정 가능한 지연 시간(기본값: 4시간)이 지난 뒤, 원본 데이터를 BookKeeper에서 삭제해요.

투명한 접근

소비자는 오프로드된 데이터에 투명하게 접근할 수 있어요. 소비자가 오프로드된 데이터를 요청하면:

  • 브로커가 BookKeeper 메타데이터를 확인해 저장 위치를 판단해요.
  • 데이터가 외부 저장소에 있으면 브로커가 매끄럽게 그 데이터를 가져와요.
  • 소비자는 데이터가 여전히 BookKeeper에 있는 것처럼 그 데이터를 받아요.

지원되는 저장 백엔드

Pulsar는 계층형 저장소를 위해 여러 저장 백엔드를 지원해요:

클라우드 저장 공급자

  • Amazon S3: 여러 스토리지 클래스를 지원하는 업계 표준 객체 저장소
  • Google Cloud Storage (GCS): 라이프사이클 관리 기능을 갖춘 Google의 객체 저장소
  • Microsoft Azure Blob Storage: Azure의 객체 저장소 솔루션
  • Alibaba Cloud OSS: Alibaba의 객체 저장소 서비스

온프레미스 솔루션

  • 파일시스템: 온프레미스 배포를 위한 로컬 또는 네트워크 연결 저장소
  • S3 호환 저장소: MinIO, Ceph 및 기타 S3 호환 솔루션

스토리지 클래스와 비용 최적화

저장 백엔드마다 다양한 스토리지 클래스를 제공해요:

  • 핫(hot) 저장소: 즉시 접근 가능, 비용이 높음 (S3 Standard, GCS Standard)
  • 쿨(cool) 저장소: 자주 접근하지 않음, 비용이 낮음 (S3 IA, GCS Nearline)
  • 콜드(cold) 저장소: 아카이브 저장, 비용이 가장 낮음 (S3 Glacier, GCS Coldline)

설정과 정책

오프로딩 트리거

계층형 저장소는 다음 조건에 따라 트리거될 수 있어요:

  1. 크기 기반 정책: 토픽 백로그가 특정 크기를 초과하면 오프로드
  2. 시간 기반 정책: 지정된 기간보다 오래된 데이터를 오프로드
  3. 수동 트리거: REST API 또는 CLI를 통한 관리 명령
  4. 네임스페이스 수준 정책: 네임스페이스 설정에 따른 자동 오프로딩

주요 설정 파라미터

  • 오프로드 임계값: 오프로딩이 시작되기 전의 최소 백로그 크기
  • 오프로드 삭제 지연: 오프로딩 후 BookKeeper에서 데이터를 삭제하기까지의 지연
  • 최대 블록 크기: 외부 저장소에 업로드되는 데이터 블록의 최대 크기
  • 읽기 버퍼 크기: 오프로드된 데이터를 읽을 때 사용하는 버퍼 크기
  • 오프로드 드라이버: 백엔드 저장 드라이버 설정

성능 고려 사항

읽기 성능

  • 첫 접근: 네트워크 지연 때문에 오프로드된 데이터를 읽는 것은 BookKeeper보다 느려요.
  • 캐싱: 일부 구현은 자주 접근하는 오프로드 데이터를 캐시해요.
  • 프리페치: 브로커는 접근 패턴에 따라 데이터를 미리 가져올 수 있어요.

쓰기 성능

  • 비동기 오프로딩: 오프로딩은 백그라운드에서 일어나므로 쓰기 성능에 영향을 주지 않아요.
  • 병렬 전송: 여러 세그먼트를 동시에 오프로드할 수 있어요.
  • 대역폭 관리: 오프로딩이 네트워크 자원을 압도하지 않도록 제한을 설정할 수 있어요.

비용 이점

BookKeeper에 기록된 데이터는 기본적으로 3개의 물리 머신에 복제돼요. 하지만 일단 세그먼트가 BookKeeper에서 봉인되면 불변이 되어 장기 저장소로 복사될 수 있어요. 장기 저장소는 Reed-Solomon 오류 정정 같은 메커니즘을 사용해 더 적은 물리 복사본만으로도 비용을 절감할 수 있어요.

비용 절감은 다음에서 비롯돼요:

  • 복제 감소: 외부 저장소는 일반적으로 더 적은 복제본을 요구해요.
  • 스토리지 클래스 최적화: 오래된 데이터에 더 저렴한 스토리지 클래스를 사용해요.
  • 운영 효율: BookKeeper 클러스터 저장 요구량이 줄어들어요.

사용 사례와 이점

장기 데이터 보존

  • 규정 준수: 데이터 보존에 대한 규제 요건을 충족해요.
  • 이력 분석: 분석을 위해 과거 데이터에 접근할 수 있게 유지해요.
  • 감사 추적: 규정 준수와 감사를 위해 메시지 이력을 보존해요.

비용 최적화

  • 저장 비용 절감: 콜드 데이터를 더 저렴한 저장 계층으로 옮겨요.
  • 운영 효율: BookKeeper 저장 요구량을 줄여요.
  • 탄력적 확장: 과잉 프로비저닝 없이 다양한 데이터 볼륨을 처리해요.

관리와 운영

모니터링

  • 오프로딩 지표: 오프로딩 진행 상황과 성능을 추적해요.
  • 저장 사용량: 계층별 저장 소비량을 모니터링해요.
  • 접근 패턴: 최적화를 위해 데이터 접근 패턴을 분석해요.

자동화

  • 정책 기반 관리: 사전 정의된 정책에 따른 자동 오프로딩
  • 라이프사이클 관리: 클라우드 공급자의 라이프사이클 정책과 연동
  • 알림: 오프로딩 실패 또는 임계값 초과에 대한 알림

자세한 설정 절차와 구성 예시는 계층형 저장소 쿡북을 보세요.

더 알아보기 (Learn more)