Google Bigquery -2 (아키텍처)

https://nani-log.tistory.com/167

Google Bigquery -1 (설계적 특성 - OLAP, Columnar, MPP, Serverless)

 

앞서 Bigquery의 설계적 특성에 대해 살펴봤다. 이번 포스트에서는 Bigquery의 아키텍처를 뜯어보고자 한다

 

Bigquery는 크게 스토리지 레이어(colussus file system), 컴퓨팅 레이어(dremel), 네트워크(Jupiter)로 나뉜다

 

Storage Layer - Colussus File System

Bigquery의 스토리지는 크게 사용자가 조작 가능한 영역과 구글이 관리해주는 영역으로 나뉜다

 

1. 사용자 관리 영역
   • 데이터셋 및 테이블 관리
   • IAM 설정
   • 쿼리 작성 및 실행
   • 데이터 로드 및 내보내기
2. 구글 관리 영역
   • 물리적 데이터 저장 및 최적화
   • 메타데이터 관리
   • 데이터 내구성 및 가용성 유지
   • 쿼리 실행 최적화
   • 자동 확장 및 리소스 관리
   • 하드웨어 복잡성 추상화

 

각 역할을 요약하자면 사용자가 데이터셋과 테이블, IAM 설정 등을 조작하면 구글은 데이터에 대한 물리적인 저장 및 최적화, 쿼리 실행 최적화 등을 관리해준다. 사용자는 복잡한 하드웨어를 직접 관리하지 않고 데이터셋과 테이블, 그에 대한 접근 제한과 쿼리 튜닝 등만 신경쓰면 되기 때문에 아주 편리하다

 

분산 파일 시스템인 Colussus의 작동 방식을 좀 더 자세히 봐보자

클라이언트가 쿼리를 실행하면, Colussus client library는 클라이언트의 요청을 분석해 curators에게 필요한 데이터의 위치 정보를 요청한다. curators는 metadata database에서 해당 데이터의 위치 정보를 조회하고 반환해준다

 

필요한 데이터 위치 정보를 알게 되었으니, "D" managed disk storage에서 데이터를 읽어올 차례다. 이 데이터는 쿼리 처리를 위해 컴퓨팅 레이어의 각 리프 노드 메모리로 분산되고 메모리에 로드된 데이터를 바탕으로 각 서버에서 쿼리 연산을 수행한다

 

 

Compute Layer - Dremel

Compute Layer은 Dremel 구조로, 쿼리를 트리 구조로 변환하고 분할된 쿼리 연산을 리프 노드에서 병렬로 실행할 수 있게 설계한 분산 쿼리 엔진 구조를 뜻한다. 루트, 중간(믹서), 리프 서버로 이루어져 있고 리프 서버에서 각자 필요한 데이터를 스토리지에서 불러와 병렬로 처리한다

 

루트, 중간, 리프 서버는 각자 담당하고 있는 부분은

• 루트 서버
  • 쿼리를 접수하고 실행 계획을 수립한뒤, 쿼리 디스패처를 통해 우선 순위를 정해 스케줄링과 로드 밸런싱을 수행한다
  • 특정 서버에서 처리 속도가 느리면, 다른 서버에 작업을 분산시킨다
  • 쿼리 결과를 클라이언트에게 전달한다
• 중간 서버
  • 리프 서버의 결과를 수집하고 필요시 집계 및 처리한다
  • 루트 서버로 결과를 전달한다
• 리프 서버
  • 전달받은 쿼리를 각자 처리하고 결과를 반환한다
  • 여기서 슬롯의 개념이 등장하는데, 슬롯은 리프 서버에서 쿼리를 실행하는 단일 스레드를 의미한다

 

이러한 구조로 컴퓨팅 레이어를 설계하면 다음의 장단점이 있다

• 장점
  • 전체 데이터가 아닌 컬럼 단위로 데이터를 읽어 디스크 I/O가 최소화된다
  • 트리 아키텍처로 병렬 처리가 극대화된다
  • 중첩 데이터를 평평한 구조로 변환해 처리하기 때문에, 복잡한 데이터 구조도 효율적으로 처리할 수 있다
• 단점
  • 데이터 삽입/갱신/삭제시, 흩어져 있는 여러 컬럼에 걸쳐 작업해야 하므로 상대적으로 느리다

 

Network Layer - Jupiter

Bigquery 아키텍처에서 정말 중요한 역할을 수행하는건 Jupiter다. 하나의 컴퓨터 노드 내에서 스토리지와 컴퓨팅을 모두 수행하는 Redshift와 달리 스토리지와 컴퓨팅을 분리해 수행하기 때문에 빠른 네트워크가 아주 중요한 역할을 한다

 

Jupiter는 초당 1페타비트(약 131,072GB)의 데이터를 주고받을 수 있다. 이는 100,000대의 머신이 각각 10Gbps로 통신할 수 있는 대역폭으로 어마어마한 속도를 자랑한다. 또한 모든 머신이 빠른 속도로 데이터를 주고 받을 수 있기 때문에 랙의 물리적 위치(우리가 관리하는 것은 아니지만...)가 중요하지 않다

 

 

정리

Bigquery는 Jupiter 덕분에 스토리지와 컴퓨팅 레이어가 분리되어 있음에도 아주 빠른 속도로 데이터를 주고 받을 수 있고, 독립적으로 확장할 수 있다는 장점이 크다. 또한 서버리스로 제공되기 때문에 인프라를 직접 구성하지 않고도 필요한대로 스토리지와 컴퓨팅을 요청하면 그만큼 제공해준다. 따라서 우리는 쿼리 비용(슬롯 사용량)과 스토리지 비용만 신경써주면 된다

 

다음 포스트에서는 쿼리 비용과 스토리지 비용을 줄이기 위해 어떤 노력을 할 수 있는지 알아보자