[견고한 데이터 엔지니어링] CH6 2단계: 데이터 저장

 

1) 데이터 스토리지의 구성요소

1-1. 스토리지 “추상화” vs 스토리지 “시스템”

저장 이야기를 할 때 가장 먼저 구분해야 한다.

스토리지 추상화(Architecture/Layer)

• 데이터 레이크
• 데이터 레이크하우스
• 데이터 플랫폼
• 클라우드 데이터 웨어하우스

-> “사용 패턴(저장/쿼리/변환/거버넌스)”을 규정하는 큰 틀

스토리지 시스템(Implementation)

• HDFS(하둡 분산 파일 시스템)
• 캐시/메모리 기반 스토리지
• 관계형 DB
• 객체 스토리지(S3 등)
• 스트리밍 스토리지(카프카 등)

-> “실제로 데이터를 담고 전달하는 기술”

1-2. 스토리지의 기본 구성요소(물리/논리)

스토리지 성능은 결국 아래 구성요소의 조합으로 결정된다.

• HDD / SSD / RAM
• 네트워킹
• CPU
• 직렬화(Serialization)
• 압축(Compression)
• 캐싱(Caching)

1-3. HDD(자기 디스크 드라이브)

• 용량 증가 = 면적 밀도에 의해 확장
• 전송속도 증가 = 선형 밀도에 의해 확장 (용량과 비례하지 않음)
• 탐색시간(Seek) + 회전지연(Rotation latency)이 병목이 되기 쉬움

1-4. SSD

• 플래시 메모리 셀에 전하로 저장
• 여러 컨트롤러가 병렬로 동작하는 파티션 구조 → 전송속도/IOPS 향상
• OLTP 혁신의 핵심(상용 OLTP의 표준)
• OLAP에서도 SSD 캐싱으로 자주 접근 데이터 쿼리 성능에 기여

1-5. RAM(임의 접근 메모리)

• CPU 주소 공간에 매핑되어 코드/데이터를 저장
• 휘발성(volatile)
• SSD보다 훨씬 빠른 전송 속도와 낮은 탐색 시간
• 단점: 비용↑, 용량 제약↑ (규모 확장 시 복잡성↑)

1-6. 네트워킹과 CPU

• RAID 같은 표준은 단일 서버 내 병렬 디스크 구성을 지원
• 클라우드 객체 스토리지는 네트워크 기반 분산 + AZ(가용 영역) 단위 복제

AZ는 전력/물/자원 등이 독립된 표준 클러스터 환경으로, 다중 AZ는 가용성과 내구성을 높인다.

CPU는 단순 계산뿐 아니라

• 읽기 집계, 쓰기 분산
• API 처리, 백엔드 구성요소 운영
• 로드밸런싱 등
• 스토리지 시스템을 “웹앱”처럼 동작하게 만든다.

-> 결국 네트워크 장치 성능/토폴로지가 고성능의 핵심이다.

1-7. 직렬화(Serialization)

직렬화는 데이터를 평탄화하고 표준 포맷으로 패킹하는 과정이고, 읽는 쪽은 이를 디코딩한다.

• JSON/XML/CSV 같은 포맷은 범용 디코딩이 쉽지만 CPU 오버헤드가 커질 수 있음
• 직렬화 방식은 CPU 오버헤드/쿼리 지연시간에 직접 영향

대표 예시:

• 컬럼형 직렬화: Parquet
• 하이브리드 직렬화/테이블 관리: Hudi
• 인메모리 직렬화: Arrow
• 저수준 DB 내부 저장도 일종의 직렬화로 볼 수 있음

1-8. 압축(Compression)

고효율 압축의 장점:

1. 디스크 공간 절약
2. 디스크 당 체감 검색 속도 향상
3. 네트워크 전송량 감소

단점:

• 압축/해제에 CPU 시간과 자원이 추가로 든다.

1-9. 캐싱(Caching)

스토리지 분석에서 캐시 계층을 어디에 두는지는 매우 중요하다.

• 모든 유형의 스토리지를 캐시 계층 안에 배치하면 유용할 수 있음
• 반대로 “보관 스토리지”는 역캐시(비상시 접근) 성격
  • 백업/보존/컴플라이언스 목적
  • 접근 특성은 나쁘지만 비용이 낮음

2) 데이터 스토리지 시스템

2-1. 단일 머신 vs 분산 스토리지

• 단일 머신: 단순하지만 규모/장애 한계가 뚜렷
• 분산 스토리지: 여러 서버에 분산 저장/검색/처리 + 중복성(복원성) 확보

2-2. 최종 일관성 vs 강력한 일관성

BASE

• 기본적으로 가용성을 보장
• 일관성을 강하게 보장하지 않음
• “최선의 노력” 기반 읽기/쓰기

여기서 발생하는 상태:

• 소프트 상태(soft state): 트랜잭션이 커밋되었는지 불명확할 수 있음

최종 일관성(Eventual Consistency)

어떤 시점 이후에는 읽을 때 일관된 값이 반환됨

강력한 일관성(Strong Consistency)

항상 정확한 값을 보장하려 하지만

• 쿼리 시간 증가
• 리소스 사용 증가

일관성은 보통 3가지 레벨에서 결정된다.

1. DB 기술 자체의 일관성 모델
2. DB 설정 매개변수
3. 개별 쿼리 수준의 일관성 옵션

(예: DynamoDB는 최종 일관/강력한 일관 읽기 모두 지원)

2-3. 파일 스토리지

파일은 유한 길이의 바이트 스트림이며

• 추가(append)
• 임의 접근(random access)
• 이 가능하다.

디렉터리 탐색은 각 계층의 메타데이터를 따라 포인터를 추적해 내려간다.

로컬 디스크 스토리지

• OS가 파일 시스템 관리
• 저널링, 스냅숏, 중복성, 디스크 암호화/압축 등 지원
• 일반적으로 “쓰기 후 읽기(read-after-write) 일관성”을 제공

NAS(네트워크 결합 스토리지)

• 네트워크를 통해 파일 시스템 제공

클라우드 파일 시스템

• 여러 클라우드/VM/애플리케이션/외부 클라이언트까지 지원하는 관리형 파일 시스템
• 예: AWS EFS
  • 사전 예약 없이 자동 확장
  • 사용량 기반 과금
  • 로컬 쓰기 후 읽기 일관성, 닫기 후 열기(close-to-open) 일관성 제공

2-4. 블록 스토리지

HDD/SSD가 제공하는 원시 스토리지 단위

클라우드에서 VM의 표준 스토리지 형태로 쓰인다.

블록 스토리지 애플리케이션

트랜잭션 DB는 블록 단위 접근으로 성능 최적화를 수행한다.

RAID

• 여러 디스크 동시 제어
• 내구성 향상 + 성능 개선 + 용량 결합

SAN(스토리지 영역 네트워크)

스토리지 풀에서 네트워크 기반으로 가상 블록 장치 제공

클라우드 가상화 블록 스토리지

SAN처럼 동작하지만, 운영/네트워킹 복잡성을 엔지니어가 직접 다루지 않음

예: AWS EBS

• EC2 기본 스토리지
• 볼륨 사용 중 특정 시점 스냅숏 가능

로컬 인스턴스 스토리지

• 저렴, 낮은 지연시간, 높은 IOPS
• 복제되지 않음(내구성 약함)
• 고급 기능 제한
• 캐시 영역으로 활용 가능

2-5. 객체 스토리지(Object Storage)

S3, Azure Blob, GCS 같은 객체 스토리지는

TXT/CSV/JSON부터 이미지/비디오/오디오까지 모두 저장 가능하다.

특징:

• 관리/사용이 단순 (서버리스 성격)
• 키-값 형태
• 한 번 쓰고 나면 객체는 변경되지 않음(불변성)
• 병렬 읽기/쓰기 성능이 뛰어나 대규모 분석 엔진에 적합
• 가용성/내구성에 강함 → 빅데이터에 이상적

데이터 엔지니어링에서의 객체 스토리지

• 대규모 배치 읽기/쓰기
• OLAP 사용 사례에 적합
• 데이터 레이크의 사실상 표준
• 비정형 데이터 저장에 최적

객체 조회 방식

실제 디렉터리는 없고, 디렉터리처럼 보이는 키(prefix)로 “디렉터리 시맨틱”을 흉내 낸다.

객체 일관성과 버전 관리

• 제자리 갱신(append/update) 불가
• 같은 키로 새 객체를 다시 써야 함
• 버전 관리는 복구/롤백에 큰 도움

스토리지 클래스(계층)

접근 빈도에 따라 계층화:

• Standard / Standard-IA(검색 비용↑ 대신 저장 비용↓)
• One Zone-IA(단일 AZ 복제)
• Glacier / Glacier Deep Archive(아카이브 계층)

객체 저장소를 파일시스템처럼 쓰기

s3fs, S3 파일 게이트웨이 같은 방식이 존재

2-6. 캐시/메모리 기반 스토리지

• Memcached: 쿼리 결과, API 응답 캐싱(키-값)
• Redis: 지속성 옵션 포함(목록/집합/스냅숏/저널링 등)

2-7. HDFS(하둡 분산 파일 시스템)

• 구글 파일 시스템(GFS) 기반
• 데이터는 블록 단위로 분할
• 블록 위치 카탈로그를 네임노드가 관리
• 맵리듀스 모델과 결합해 처리

2-8. 스트리밍 스토리지

예: Apache Kafka

특징:

• 확장 가능한 스트리밍 프레임워크
• 과거 데이터 범위를 반환하는 리플레이(replay) 지원 → 표준 검색 메커니즘

2-9. 인덱스, 파티셔닝, 클러스터링

• 인덱스가 있으면 RDBMS는 초당 수천 행 조회/갱신 가능
• 컬럼형 저장은 필요한 열만 스캔 → 읽는 데이터 양 감소

행 기반 vs 열 기반

• 열 기반: 대규모 스캔, 집계, 통계, 복잡 조건 평가에 강함
• 단점: 개별 행을 다수 비동기로 조회할 땐 비효율적일 수 있음
• 열 기반 DB는 조인 성능도 크게 개선됨

파티션/클러스터링

• 파티션: 큰 덩어리로 분할
• 클러스터링: 파티션 내부를 더 세밀하게 정렬(유사 값 군집)

예: Snowflake의 마이크로 파티셔닝

• 유사 행을 묶으려는 시도
• 메타데이터 DB가 조건절에 따라 스캔 범위를 줄여줌

3) 데이터 엔지니어링 스토리지 “추상화” 개요

3-1. 데이터 웨어하우스

• 표준 OLAP 아키텍처
• 기술 플랫폼(예: BigQuery, Teradata)
• 데이터 중앙 집중화를 위한 조직 패턴

3-2. 데이터 레이크

• 원래는 “원시 데이터의 대규모 저장소”
• 현재는 컴퓨팅/스토리지 분리와 함께 발전
• MPP 계열 기능을 흡수하는 방향으로 변화

3-3. 데이터 레이크하우스

• 레이크 + 웨어하우스 결합
• 메타데이터/파일 관리 계층 포함
• Delta Lake(데이터브릭스), Apache Hudi, Apache Iceberg 등
• 테이블 이력, 갱신/삭제, 메타데이터 관리 제공
• 상호 운용성 이점이 있으나 “항상 테이블 구조가 강제되진 않을 수 있음”

3-4. 데이터 플랫폼

• 비정형 사용 사례에 강한 객체 스토리지와의 긴밀한 통합이 특징

3-5. Stream-to-Batch 스토리지 아키텍처

람다 아키텍처와 유사:

• 스트리밍 토픽을 통과하는 데이터
• 배치 스토리지에 장기 보존 + 배치 쿼리

예:

• Kinesis Firehose가 트리거 기반으로 S3 객체 생성
• BigQuery는 스트리밍 버퍼로 수집

4) 스토리지의 주요 동향(아이디어)

4-1. 데이터 카탈로그

중앙 집중식 메타데이터 저장소로 다양한 시스템/추상화와 통합된다.

구성요소:

• 카탈로그 애플리케이션 통합(API 기반 메타데이터 갱신)
• 자동화된 스캔(레이크/웨어하우스/운영DB에서 메타데이터 수집)
• 데이터 포털/소셜 계층(검색/관계 시각화/설명 편집)

사용 사례:

• 조직적 활용(검색/공유/책임)
• 기술적 활용(테이블 탐색/계보 추적)

-> 레이크하우스의 핵심 구성요소로 “쿼리를 위한 테이블 검색”과 연결된다.

4-2. 데이터 공유

정의된 권한과 함께 특정 데이터셋을 특정 엔티티와 공유하는 능력 자체가 중요한 기능이 됨.

4-3. 스키마: 쓰기 스키마 vs 읽기 스키마

• 쓰기 스키마: 쓰기 시점에 스키마 준수 강제(전통 DW)
• 읽기 스키마: 데이터 저장 후 읽을 때 해석(Parquet/JSON 등 내장 스키마 활용)

CSV는 스키마 불일치 문제가 쉽게 발생한다.

4-4. 컴퓨팅과 스토리지의 분리

코로케이션(공동 배치)

• 낮은 지연시간, 높은 대역폭
• HDFS+MapReduce에서 “데이터가 있는 곳으로 작업을 보냄”

분리의 장점

• 임시성과 확장성: 큰 클러스터를 필요할 때만 띄우고 삭제 가능
• 내구성과 가용성: 데이터 손실 위험↓, 가동시간↑

하이브리드(분리 + 코로케이션)

• 멀티티어 캐싱
• 장기 보관은 객체 스토리지, 처리 단계는 로컬/HDFS/메모리 스토리지 활용

예:

• EMR에서 S3 + 임시 HDFS
• Spark의 인메모리 의존(고비용 가능)
• Druid의 SSD 의존
• S3 Select 같은 하이브리드 객체 스토리지 접근

무복사 복제(Zero-copy replication)

물리 복사 없이 객체에 대한 “새 포인터(가상 복사본)”를 생성

4-5. 데이터 스토리지 수명주기(온도/보존/컴플라이언스/비용)

• 핫: 즉각/빈번 접근, 가장 비쌈(캐시)
• 웜: 월 1회 수준 접근
• 콜드: 거의 접근 없음(아카이브)

권장:

• 자동 수명주기 정책으로 핫→콜드 스필오버 설계
• “데이터는 무조건 쌓아야 한다”는 오류를 경계

고려 요소:

• 가치(즉시 사용/조직 전체 가치)
• 시간(보유 기간에 따라 가치 변동, TTL)
• 컴플라이언스(보관 의무)
• 비용(ROI 관점)

4-6. 싱글 테넌트 vs 멀티 테넌트 스토리지

• 싱글 테넌트: 테넌트별 격리(리소스 분리)
• 멀티 테넌트: 단일 DB/스토리지에 여러 테넌트 저장 → 보안/성능/격리 설계가 핵심

5) 함께 작업할 대상

스토리지는 데이터 엔지니어링 인프라의 핵심이기 때문에 데이터 팀만으로 결정하기 어렵다.

• 보안/거버넌스 조직
• 플랫폼/인프라 팀
• 운영 DB/애플리케이션 팀
• 비용/FinOps 관점의 이해관계자

6) 드러나지 않는 요소(Hidden Layers)

보안

• 미사용/이동 중 데이터 암호화
• 세분화된 접근 제어
• 최소 권한 원칙 실천

데이터 관리

• 데이터 카탈로그/메타데이터 투자
• 계보 추적으로 문제 원인 추적 시간 단축
• 객체 저장소의 데이터 버전 관리(복구/롤백)
• GDPR 등 개인정보보호 규정이 설계에 직접 영향

데이터 옵스

• 스토리지 컴포넌트 감시(서버리스 포함)
• 데이터 통계/엔트로피 모니터링, 이상 탐지
• 논리적 불일치 테스트(규칙 기반 검증)

데이터 아키텍처

• 신뢰성/내구성 고려 설계
• 업스트림 수집 이후 저장·접근 방식 정렬
• 다운스트림 쿼리/모델 유형 이해
• FinOps 적극 적용

오케스트레이션

• 파이프라인 흐름과 스토리지가 복잡하게 얽힘
• 저장 계층의 트리거/배치 생성/카탈로그 갱신 등과 연결됨

소프트웨어 엔지니어링

1. 코드가 스토리지 특성(일관성/성능/비용)과 맞게 동작해야 함
2. 스토리지 인프라를 코드로 정의(IaC), 임시 컴퓨팅 리소스와 함께 운영