- 클라우드 데이터 서비스의 미래는 "대규모, 다중 테넌트" 구조
- S3와 같은 최상위 SaaS 서비스들이 단순성, 신뢰성, 내구성, 확장성, 저렴한 가격을 제공하는 이유는 이 서비스의 기술들이 이러한 것들을 제공하기 위해 구조적으로 설계되었기 때문
- 대규모 자원 풀을 통해 고객에게 서비스를 제공하는 것은 규모에 따른 효율성과 신뢰성을 보장함
[서버리스 멀티 테넌트 (Serverless Multi Tenant) 시스템 정의]
"Multi-Tenancy"의 정의
- 다중 테넌트는 공유 하드웨어에서 작업 부하를 공동으로 배치시켜서 자원을 공유하는 것에 관한 것
- 클라우드에서 시스템을 구축하는 것은 여러 테넌트가 공유된 컴퓨팅 인스턴스(예: Amazon EC2 또는 Google Compute) 또는 공유된 PaaS 서비스(예: 클라우드 오브젝트 스토리지)에서 서비스를 받는 것을 의미
- 다중 테넌트를 "공유된 자원(가상화된 서버, 드라이브 및 PaaS 빌딩 블록 서비스 등)에서 여러 테넌트에게 서비스를 제공하는 것"으로 정의함
- 여러 리소스 공유 모델을 사용할 수 있으며, 일부 시스템은 컴포넌트 전체에 걸쳐서 여러 공유 모델을 결합
- 공유 프로세스: 동일한 소프트웨어 프로세스가 여러 테넌트에 서비스를 제공. 데이터 및 보안 격리는 논리적임
- 컨테이너: 단일 테넌트 노드를 실행하고 호스트당 여러 컨테이너를 패키징. 일반적으로 특정 K8s 노드가 수많은 테넌트의 포드를 호스팅하는 Kubernetes를 통해 이루어짐
- 가상화: VM(예: QEMU) 또는 microVM(예: Firecracker)에서 단일 테넌트 노드를 실행하고 호스트당 여러 VM을 패키징합. Kubernetes는 Kata 컨테이너를 통해 VM과 함께 사용할 수도 있음
- 테넌트가 동일한 V8 프로세스를 공유하면서 별도의 경량 컨텍스트에서 사용할 수 있는 V8 격리 방법도 있지만, 아직 데이터 시스템에서 이를 본 적은 없음
서버리스 정의
- 고객은 서버 유형을 선택하거나 하드웨어를 명시적으로 선택하지 않음
- 이러한 시스템들은 고객이 하드웨어의 크기를 명시적으로 조정할 필요 없이 모든 워크로드의 수요를 처리할 수 있도록 일정 수준의 탄력성과 이동성에 의존
- 탄력성: 워크로드의 필요에 따라 서비스를 확장/축소하고 축소/증설할 수 있는 기능
- 이동성: 성능 및 안정성 요구 사항을 충족하기 위해 내부적으로 워크로드를 이동하고 균형을 맞출 수 있는 서비스 기능
- 서버리스 모델은 고객에게 점점 더 중요해지고 있는 사용량 기반 요금제를 사용
- 많은 고객이 미리 큰 규모의 약정을 맺는 것을 원하지 않고 단순히 사용한 만큼만 요금이 청구되는 것을 선호
- 사용량 기반 요금제에는 워크로드 및 기본 시스템 구현에 따라 크게 달라지는 다양한 변형이 있음
- (백만) 오퍼레이션당 지불
- 워크로드의 CPU 및 메모리 사용량에 대한 비용 지불
- 스토리지 GB당 지불
- 리소스 및 작업 속도와 관련된 가상 성능/용량 단위(예: DynamoDB의 RCU/WCU)에 대해 비용을 지불
- 고객이 일부 기본 용량에 대해 비용을 지불하고 그 이상의 사용량에 대해 비용을 지불하는 하이브리드 모델("기본 비용 내고, 피크는 지불")
[공통된 도전 과제]
워크로드에 의해 부과된 제약 조건 내에서 작업
- 주어진 데이터 시스템의 작업 부하에 의해 부과된 많은 제약 조건들이 기본 아키텍처의 중요한 동인임.
- 지연 시간/가용성 요구 사항
- 일관성 요구 사항
- 요청과 데이터 간의 상관관계/종속성
- 순차적 액세스 패턴과 무작위 액세스 패턴
- 요청당 수행되는 작업의 다양성
- 데이터 크기
- 세션 대 요청 지향 프로토콜, 푸시 대 풀 메커니즘
- 작업의 컴퓨팅 강도
- 느슨한 지연 시간과 일관성 요구 사항은 엔지니어에게 더 많은 자유도를 제공함
- 지연 시간이 짧은 시스템에서는 지연 시간이 긴 구성 요소를 도입하는 데 제약이 있기 때문에 클라우드 오브젝트 스토리지의 저비용 및 높은 내구성 이점을 활용하는 것이 좋은 예
- Eventually Consistent한 시스템은 데이터를 동기식 데이터 핫 경로에 포함하지 않고 오브젝트 스토리지에 비동기식으로 기록함으로써 이러한 딜레마를 피할 수 있음
- 지연 시간이 짧고 일관성이 강한 시스템에는 이러한 면죄부 카드가 없음
- 짧은 지연 시간 같은 제약 조건이 결합하면 워크로드의 공간적, 시간적 로컬리티가 아키텍처 선택에 영향을 미칠 수 있음
- 예를 들어, 순차적 스캔이 특징인 워크로드는 디스크에서 빠르고 효율적인 스캔을 위해 연속적인 데이터 범위를 함께 유지하는 것이 좋음
- 이러한 범위를 더 작은 하위 범위로 세분화하면 핫스팟 관리에 도움이 되지만, 이 두 가지는 서로 상충되는 문제이므로 둘 사이의 균형을 찾아야 함
- 개별 요청 간의 상관관계가 거의 없는 무작위 액세스 패턴은 여러 서버에 균일하고 얇게 분산할 수 있는 플랫 주소 공간의 이점을 활용할 수 있음
- 영구 연결을 설정하는 세션 지향 프로토콜은 일반적으로 각 요청이 마지막 요청과 독립적인 요청 지향 프로토콜에 비해 더 어려움
- 영구 연결에는 연결 풀링이 필요할 수 있으며 롤링 노드 및 데이터 밸런싱과 같은 교란이 발생하면 클라이언트에 외부적으로 눈에 띄는 영향을 미칠 수 있음
- 객체 스토리지나 Kafka API와 같이 단순한 스토리지 API인 시스템도 있고, SQL 데이터베이스와 같이 컴퓨팅 집약적인 시스템도 있음
- 이는 각 요청을 처리하는 데 필요한 작업량의 예측 가능성과 가변성이라는 주제로 이어짐
- 극단적인 예로, 연속된 레코드 블록을 단순히 검색해야 하는 Kafka와 같은 데이터 스트리밍 API가 있고, 다른 쪽 끝에는 쿼리마다 작업량에 큰 차이를 초래할 수 있는 SQL이 있음
테넌트 격리
- 자원 공유는 하드웨어 활용도를 높이지만, 한 테넌트의 작업 부하가 다른 테넌트에게 영향을 미치는 자원 경합을 초래할 수 있음
- 다중 테넌트 시스템에서는 공유된 하드웨어 자원에서 서비스를 받는 테넌트가 자신만의 전용 서비스에서 서비스를 받는 것처럼 보장해야 함
스토리지와 컴퓨트의 분리
- 스토리지와 컴퓨트의 분리는 지금까지 조사된 모든 시스템이 어느 정도 구현한 핵심 설계 원칙임
- 하드웨어 트렌드로 인해 스토리지와 컴퓨팅의 분리는 점점 더 현실화되고 있으며, 이는 부분적으로는 네트워크가 더 이상 예전과 같은 병목 현상을 일으키지 않기 때문
- 네트워크 처리량은 증가하고 있지만, 클라우드 오브젝트 스토리지가 우선순위를 차지하면서 이러한 분리에 따른 새로운 과제가 여전히 존재
- 클라우드 오브젝트 스토리지는 여전히 상대적으로 지연 시간이 길고 내구성이 뛰어나며 비용이 저렴
- 하지만 OLTP 데이터베이스와 같이 일반적으로 지연 시간이 짧은 워크로드에 도입하기는 어려울 수 있음
- 또한 클라우드 오브젝트 스토리지의 경제적인 모델은 많은 작은 오브젝트에 의존하는 설계에 불리하게 작용하며, 더 적은 요청으로 더 큰 오브젝트에 데이터를 축적해야 하므로 저지연 시스템의 수명을 더욱 복잡하게 만듦
- 엔지니어는 지연 시간이 짧은 시스템에 오브젝트 스토리지를 포함시키되, 느린 오브젝트 스토리지 앞에 내구성 있고 내결함성 있는 쓰기 캐시 및 예측 읽기 캐시를 배치하여 오브젝트 스토리지의 지연 시간 문제에 대응할 수 있음
- 이 내구성 있는 쓰기 캐시는 기본적으로 복제 프로토콜을 구현하고 블록 스토리지에 데이터를 쓰는 서버 클러스터임
- 백그라운드에서 클러스터는 더 적은 수의 대용량 파일을 쓰는 경제적인 패턴에 따라 데이터를 오브젝트 스토리지에 비동기식으로 업로드
- fault-tolerant 쓰기 캐시는 짧은 레이턴시의 쓰기를 잘 지원함
- 이 아키텍처에서 문제가 될 수 있는 것은 읽기 캐시
- 이벤트 스트리밍과 같은 순차적 워크로드는 간단하고 매우 효과적
- Aggregate Prefetching(집계 프리페팅)이 수요를 따라잡는 한, 읽기는 항상 로컬 읽기 캐시에 도달해야 함
- 데이터베이스는 예측하기 어려운 랜덤 액세스 패턴으로 인해 이보다 더 어려운 문제를 겪지만, 테이블 스캔은 여전히 읽기 선행 작업의 이점을 누릴 수 있음
- 복제 프로토콜로 분산형 내결함성 쓰기 캐시를 구현하는 것은 그리 간단한 일이 아니며, 다중 AZ 환경에서는 교차 AZ 요금과 같은 다른 비용이 발생할 수 있음
- 하지만 현재로서는 저렴하고 내구성이 뛰어난 오브젝트 스토리지를 기본 데이터 저장소로 사용하고자 하는 저지연 시스템을 위한 대안이 없음
- 지연 시간이 짧은 다른 시스템은 클라우드 오브젝트 스토리지 사용을 아예 피해야 하며, 무엇보다도 예측 가능한 짧은 지연 시간을 선호
- 클라우드 스토리지는 널리 사용되고 있지만 지연 시간 상충 관계로 인해 보편적이지 않습니다.
열 관리
- 열 관리는 지연 시간 급증이나 초당 작업 수 감소와 같이 외부에서 눈에 보이는 성능 문제를 일으킬 수 있는 핫스팟을 피하기 위해 여러 스토리지 노드에 걸쳐 가능한 한 균등하게 부하를 분산하는 것
- 이를 로드 밸런싱이라고도 할 수 있지만, 보통 상태 비저장 노드에 대한 로드 밸런서라는 용어를 사용
- 스테이트풀 시스템에서는 특정 스토리지 노드에 수요가 많은 오브젝트가 그룹화되지 않아 경합이 발생할 수 있는 핫스팟이 발생할 수 있음
- 로드 밸런서는 무작위, 최소 연결 또는 일부 FIFO 변형과 같은 간단한 전략으로 상태 비저장 노드 집합에 부하를 고르게 분산시킬 수 있지만, 상태 저장 시스템은 데이터가 있는 위치에 따라 요청을 노드로 라우팅해야 함
- 부하를 재분배하기 위해 데이터를 이동하는 것을 흔히 리밸런싱이라고 함
- 더욱 복잡한 문제는 시간이 지남에 따라 부하 분산이 변경될 수 있다는 점
- 데이터 분산은 작은 데이터 하위 집합에 영향을 미치는 단기적인 피크부터 여러 테넌트에 걸쳐 나타나는 일별 패턴이나 계절적 이벤트로 인한 더 큰 부하 변화까지 모든 것을 처리해야 하는 동적인 프로세스가 됨
- 대규모 데이터베이스나 처리량이 많은 이벤트 스트림과 같은 대규모 데이터 세트는 부하를 효과적으로 분산하기 위해 샤딩해야 함
- 리밸런싱은 샤드의 리밸런싱이 되며, 시스템은 로드 분배가 변경됨에 따라 샤드를 분할하고 병합할 수도 있음
- 그러나 샤드 수와 크기와 관련하여 데이터 로컬리티와 같은 상충되는 문제가 존재할 수 있음
- 한편으로는 데이터의 공동 위치가 많을수록 검색이 더 효율적
- 반면에, 너무 많은 샤드에서 가져와야 하는 컴퓨팅 작업의 비용이 더 많은 서버에 부하를 분산시킴으로써 얻을 수 있는 이점을 능가할 수도 있음
- 열 관리는 단일 테넌트 시스템에서도 필요할 수 있으므로 멀티 테넌트만의 문제는 아님
- 그러나 MT 데이터 시스템에서는 테넌트가 서비스 품질 변동을 경험하지 않도록 하기 위해 열 관리가 더욱 중요해짐
높은 자원 활용도 달성
- 서버리스 멀티테넌트 아키텍처를 구현하는 주요 동기 중 하나는 기본 하드웨어 리소스를 보다 효율적으로 사용하여 더 나은 경제적 성능을 제공하기 위한 것
- 리소스 풀링을 통해 리소스 활용도를 높이는 것이 가장 중요하지만, 테넌트 격리 및 예측 가능한 성능으로 이를 달성하는 것은 어려운 과제
콜드 스타트
- 테넌트 단위로 자원을 제로로 축소하는 서버리스 시스템은 테넌트가 작업 부하를 재개할 때 콜드 스타트의 문제에 직면할 수 있음
- 콜드 스타트는 처음부터 서버리스 기능의 초점이었으며, 일부 서버리스 데이터 시스템에도 영향을 미칠 수 있음
- 일부 시스템에서는 콜드 스타트가 전혀 발생하지 않는 반면, 다른 시스템에서는 콜드 스타트가 아키텍처와 스케일 투 제로 제품 제공으로 인해 피할 수 없는 일종의 피할 수 없는 것이기도 함
- 내가 본 모든 사례에서 콜드 스타트 문제는 제품 결정 사항이며, 요금제 및 가격 책정 방식에 따라 리소스 축소 수준이 다를 수 있음
- 궁극적으로 고객과 공급업체는 각자의 필요에 맞게 절충안을 선택할 수 있음
조사한 시스템들
- Group 1 - Storage APIs (compute-light)
- Amazon DynamoDB (chapter 1)
- Kora - Serverless Kafka engine inside Confluent Cloud (chapter 2)
- Backblaze B2 (planned)
- Group 2 - SQL OLTP databases (compute-heavy)
- Neon - serverless PostgreSQL (chapter 3)
- CockroachDB’s serverless multi-tenant architecture. (in progress)
- Planetscale (planned)
- Group 3 - SQL OLAP databases and data warehouses (compute-heavy)
- Google BigQuery (planned)
- ClickHouse Cloud (in progress).
- 이 작업은 계속 진행되겠지만, 2024년 1월/2월에 일종의 '결론' 포스팅 예정