# 서버리스 데이터 시스템의 아키텍처

> Clean Markdown view of GeekNews topic #12053. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=12053](https://news.hada.io/topic?id=12053)
- GeekNews Markdown: [https://news.hada.io/topic/12053.md](https://news.hada.io/topic/12053.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2023-11-27T11:03:02+09:00
- Updated: 2023-11-27T11:03:02+09:00
- Original source: [jack-vanlightly.com](https://jack-vanlightly.com/blog/2023/11/14/the-architecture-of-serverless-data-systems)
- Points: 26
- Comments: 0

## Topic Body

- 클라우드 데이터 서비스의 미래는 "대규모, 다중 테넌트" 구조  
  - 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월에 일종의 '결론' 포스팅 예정

## Comments



_No public comments on this page._