55. 스토리지와 컴퓨팅의 분리 (Separation of Compute and Storage)

⚠️ 이 문서는 과거 하둡(Hadoop) 서버들처럼 하나의 기계통 안에 데이터를 저장하는 하드디스크(스토리지)와 데이터를 연산하는 CPU(컴퓨팅)가 묶여있던 낡은 일체형 아키텍처를 폐기하고, 데이터는 싼 창고(S3)에 영원히 방치해 두고 계산이 필요할 때만 비싼 CPU 서버(EC2)를 잠깐 빌려와 파이프만 꽂아서 분석한 뒤 버리는 '클라우드 네이티브 데이터 웨어하우스(Snowflake 등)'의 핵심 철학을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 데이터가 쌓이는 속도(스토리지 팽창)와 데이터를 분석하는 횟수(컴퓨팅 부하)는 서로 완벽하게 독립적인 사건이다. 따라서 두 자원의 서버를 한 몸통으로 묶어두면 필연적으로 어느 한쪽의 막대한 낭비가 발생하므로 이를 완전히 가위로 잘라 분리해 버린 것이다.
  2. 가치: 10페타바이트의 데이터를 싼값에 저장해 두다가, 연말 정산 쿼리를 돌릴 때 딱 1시간 동안만 초거대 CPU 클러스터 1,000대를 무한정 빌려서(Scale-out) 빛의 속도로 계산한 뒤 반납해 버림으로써, 기업의 인프라 비용을 극적으로 구원한다.
  3. 기술 체계: 아마존 S3나 구글 GCS 같은 사실상 무한대 용량의 '객체 스토리지(Object Storage)'에 데이터 파일을 쌓고, 그 위에 Snowflake, AWS Athena, BigQuery 같은 '가상 웨어하우스 연산 엔진'을 네트워크로 연결하는 분산형 쿼리 아키텍처를 기반으로 작동한다.

Ⅰ. 일체형 아키텍처(Hadoop/RDBMS)의 뼈아픈 비효율

하드디스크와 CPU를 한 상자에 가두면 끔찍한 가성비가 나온다.

  1. 결합형 아키텍처 (Coupled Architecture):
    • 과거 온프레미스의 하둡(HDFS)이나 오라클 DB 장비는 1대의 랙 서버 안에 10TB의 디스크와 16코어 CPU가 한 몸으로 묶여 있었다.
  2. 스케일링(확장)의 딜레마:
    • 회사의 데이터가 폭증해서 100TB가 더 필요해졌다. 하지만 연산(CPU) 부하는 그대로다.
    • 디스크만 늘리고 싶은데 기계가 일체형이라서, 어쩔 수 없이 쓰지도 않을 비싼 CPU가 통째로 박혀있는 새 랙 서버 10대를 통째로 수억 원어치 추가 구매해야 한다. 반대의 경우(계산량만 폭증할 때)도 마찬가지다.
  3. 노드 간의 데이터 셔플링 병목:
    • 일체형 구조에서는 데이터를 연산할 때, 1번 서버의 디스크에 있는 데이터를 2번 서버의 CPU가 쓰려면 네트워크로 복사해 와야(Data Shuffling) 해서 병목 현상이 심했다.

📢 섹션 요약 비유: 호텔방(서버)을 빌릴 때, 방의 넓이(스토리지)와 침대의 개수(컴퓨팅)가 항상 패키지로 묶여있는 상황입니다. 나는 혼자 잘 건데 짐이 너무 많아서 엄청 넓은 방을 원할 뿐인데, 그 방에는 무조건 비싼 침대 10개가 꽉 차 있어서 억울하게 침대 10개 값을 다 내야만 하는 바가지요금 시스템과 같습니다.

Ⅱ. 분리 아키텍처: 컴퓨팅과 스토리지의 해방 (Snowflake의 등장)

구름 위(Cloud)로 올라가면서 드디어 가위로 자를 수 있게 되었다.

  1. 스토리지의 영구적 추방 (S3):
    • 클라우드 제공자는 용량이 꽉 찰 걱정이 없는, 1GB당 몇십 원 수준의 극도로 저렴한 무제한 객체 스토리지(S3, Blob)를 제공한다. 회사 데이터는 이제 비싼 서버를 떠나 이 무제한의 싼 창고에 차곡차곡 쌓인다 (스토리지만 독립적으로 무한 스케일 아웃).
  2. 온디맨드 (On-Demand) 컴퓨팅의 독립:
    • 데이터 분석가가 SQL 쿼리를 날린다. 이때 클라우드는 빈 깡통 CPU 서버(가상 웨어하우스)를 수십 대 순식간에 켜서, 창고(S3)에 긴 빨대를 꽂아 필요한 데이터만 쫙 빨아들여 메모리에서 계산을 때린다.
    • ┌────────────────────────────────────────────────────────┐ │ [가상 웨어하우스 A (영업팀용 CPU 10대)] \ │ │ [가상 웨어하우스 B (마케팅팀용 CPU 2대)] --> [단일 무제한 저장소 S3 (Data)] │ └────────────────────────────────────────────────────────┘
  3. 작업 완료 후 전원 차단 (Zero-Compute Cost):
    • 쿼리가 1분 만에 끝나면, 빨대를 뽑고 깡통 CPU 서버들은 즉시 삭제(반납)해버린다. 회사는 딱 1분 치의 CPU 렌탈 비용만 내면 끝이다.

📢 섹션 요약 비유: 거대한 컨테이너 창고(스토리지)에 짐을 가득 쌓아두고 매달 싼 보관료만 냅니다. 연말정산처럼 짐을 다 까서 엄청나게 계산해야 할 일이 생기면, 일용직 알바생(컴퓨팅) 1,000명을 딱 하루만 고용해서 창고에 투입해 일을 끝내고, 저녁에 일당을 주고 쿨하게 해고해 버리는 극한의 인력 운영 효율화입니다.

Ⅲ. 멀티 테넌트 간섭 방지와 동시성의 기적

분리하면 요금만 싸지는 게 아니라, 부서 간의 싸움도 없어진다.

  1. 자원 경합(Resource Contention)의 종말:
    • 일체형 DB 시절에는 재무팀이 무거운 연말 통계 쿼리를 날리면 DB 전체의 CPU가 100%를 찍어, 영업팀이 고객 정보를 조회하는 쿼리마저 멈춰버리는 현상(Noisy Neighbor)이 일상이었다.
  2. 독립적인 컴퓨팅 클러스터 부착:
    • 분리 아키텍처(예: Snowflake)에서는 재무팀 전용 거대 CPU 클러스터(빨대 A)와 영업팀 전용 소형 CPU 클러스터(빨대 B)를 각각 따로 띄워서 동일한 S3 저장소에 동시에 꽂을 수 있다.
    • 재무팀 CPU가 폭발하든 말든, 영업팀 CPU는 전혀 간섭받지 않고 독립적으로 쾌적하게 S3 데이터를 읽어간다. 하나의 진실의 원천(Single Source of Truth) 데이터를 복사본 없이 수천 개 부서가 각자의 CPU로 동시에 씹고 뜯고 맛보는 기적이 열린 것이다.

📢 섹션 요약 비유: 하나의 거대한 뷔페 음식상(S3 스토리지)에, 코끼리(재무팀 CPU)와 토끼(영업팀 CPU)가 각자 자기 포크를 들고 달려와서 밥을 먹는 구조입니다. 코끼리가 음식을 미친 듯이 퍼먹느라 숨을 헐떡이든 말든(CPU 100%), 음식은 무한히 쌓여있으니 토끼는 옆에서 아무 방해 없이 평화롭게 자기 몫의 당근을 집어먹을 수 있는 완벽한 자원 격리 식당입니다.