SW 전공

SW 전공 이론 학습

이론 목록으로 돌아가기

분산 저장·처리와 데이터 플랫폼

분할·복제·일관성·CAP와 분산 파일시스템·MapReduce·Spark·배치·스트림·데이터 파이프라인을 학습한다.

예상 읽기 8분

1. 분산시스템의 의미

분산시스템은 독립된 여러 컴퓨터가 네트워크로 협력해 하나의 서비스나 작업을 제공하는 시스템이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Client
  │
Coordinator
  ├─ Node A: 저장·처리
  ├─ Node B: 저장·처리
  └─ Node C: 저장·처리

장점:

  • 수평 확장
  • 병렬 처리
  • 장애 분산
  • 지역 분산

어려움:

  • 네트워크 지연·단절
  • 부분 실패
  • 시간·순서 불일치
  • 데이터 복제·일관성
  • 운영·관측 복잡성

한 노드가 정상이어도 다른 노드나 네트워크가 실패할 수 있다.

2. 데이터 분할

분할(Partitioning·Sharding)은 데이터를 여러 노드에 나누어 저장한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
사용자 ID 1~999   → Shard A
사용자 ID 1000~1999 → Shard B
사용자 ID 2000~2999 → Shard C

방식:

  • 범위 분할
  • 해시 분할
  • 목록·지역 분할
  • 라운드로빈
  • 복합 분할

고려사항:

  • 분할키의 균등성
  • 핫스팟
  • 범위 조회
  • 재분배
  • 여러 샤드에 걸친 조인·트랜잭션

3. 복제

복제는 같은 데이터를 여러 노드에 저장해 가용성과 읽기 성능을 높인다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Leader
  ├─ Replica B
  └─ Replica C
  • 동기 복제: 확인 후 완료, 손실 감소·지연 증가
  • 비동기 복제: 빠른 응답, 복제 지연·손실 가능
  • Leader-Follower
  • Multi-Leader
  • Leaderless 개념

읽기 복제본이 최신 변경을 아직 받지 못하면 오래된 값을 반환할 수 있다.

4. 일관성 모델

  • 강한 일관성: 완료된 쓰기 이후 모든 읽기가 최신값을 기대
  • 최종 일관성: 업데이트가 전파되면 결국 같은 값으로 수렴
  • 읽기 후 쓰기·세션 일관성 등 중간 모델
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
쓰기 완료
   ├─ Strong: 즉시 최신 읽기 기대
   └─ Eventual: 일부 복제본은 잠시 이전 값, 이후 수렴

일관성은 “데이터가 맞다/틀리다”의 단순 이분법이 아니라 시스템이 제공하는 보장 규칙이다.

5. CAP 개념

네트워크 분할이 발생한 상황에서 분산 데이터시스템은 일관성과 가용성을 동시에 완벽히 보장하기 어렵다는 트레이드오프를 설명한다.

  • C: 모든 노드에서 일관된 최신 응답
  • A: 모든 요청에 정상 응답
  • P: 네트워크 분할 속에서도 동작
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Node A  X  Node B
   네트워크 분할 발생

선택:
- 일관성 우선: 일부 요청 거부·대기
- 가용성 우선: 각 노드 응답, 값이 잠시 다를 수 있음

정상 상황에서 항상 둘 중 하나만 선택한다는 단순 암기가 아니라 분할 발생 시 보장과 업무 요구를 본다.

6. 쿼럼 기초

복제본 수 N, 읽기 수 R, 쓰기 확인 수 W를 조정한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
N=3, W=2, R=2
R + W > N

읽기·쓰기 집합이 겹칠 가능성을 높여 최신값 확인을 지원하지만, 네트워크·동시 쓰기·구현 규칙에 따라 추가 처리가 필요하다.

7. 분산 파일시스템

대용량 파일을 블록으로 나누어 여러 노드에 저장하고 복제한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
File X
├─ Block 1 → Node A, Node C
├─ Block 2 → Node B, Node C
└─ Block 3 → Node A, Node B

메타데이터 관리자는 파일 이름과 블록 위치를 관리하고, 데이터 노드는 실제 블록을 저장한다. 데이터가 있는 노드 근처에서 연산하는 데이터 지역성이 중요하다.

8. Hadoop 핵심 역할

Hadoop은 대용량 데이터를 여러 범용 서버에 분산 저장·처리하기 위한 오픈소스 생태계이다. 이름을 특정 영문 약어의 확장으로 설명하지 않는다.

대표 구성 개념:

  • HDFS: 분산 파일 저장
  • MapReduce: 배치 병렬 처리 모델
  • YARN: 자원·작업 관리 계층
  • 관련 수집·쿼리·처리 도구 생태계
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
HDFS 저장
   ↓
입력 분할
   ↓
Map: 각 분할 병렬 처리
   ↓
Shuffle·Sort: 키별 재분배
   ↓
Reduce: 키별 집계
   ↓
결과 저장

9. MapReduce 예시

단어 수 계산:

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
입력:
A: "cat dog cat"
B: "dog bird"

Map:
(cat,1) (dog,1) (cat,1)
(dog,1) (bird,1)

Shuffle:
cat → [1,1]
dog → [1,1]
bird → [1]

Reduce:
cat=2, dog=2, bird=1

대규모 배치에 적합하지만 반복적·대화형 분석에서는 디스크 I/O와 작업 지연이 클 수 있다.

10. Spark 개념

Spark는 분산 데이터 처리 엔진으로 메모리 활용과 DAG 기반 작업 최적화를 통해 반복·대화형·스트림 처리 등을 지원한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Source
  ↓
Transform A
  ↓
Transform B
  ├─ Action 1
  └─ Action 2

지연 평가를 이용해 실제 결과가 필요한 시점에 실행계획을 구성할 수 있다. 메모리 기반이라는 표현이 모든 데이터가 항상 메모리에만 존재한다는 뜻은 아니다.

11. 배치와 스트림

구분배치스트림
입력일정량 누적계속 도착
결과주기적실시간·근실시간
예일 마감 집계이상거래 탐지
핵심처리량·재처리지연·순서·상태

스트림 처리 고려사항:

  • 이벤트 시간과 처리 시간
  • 늦게 도착한 이벤트
  • 윈도
  • 중복과 순서
  • 체크포인트
  • 상태 저장
  • 재처리

12. ETL·ELT와 데이터 파이프라인

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
ETL:
원천 → 추출 → 변환 → 목적 저장

ELT:
원천 → 추출 → 목적 저장 → 내부 변환

데이터 파이프라인에는 다음이 필요하다.

  • 수집
  • 스키마 검증
  • 품질 검사
  • 변환
  • 저장
  • 메타데이터·계보
  • 오류 격리
  • 재처리
  • 모니터링
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Source → Ingestion → Raw Zone → Transform → Curated Zone → BI·ML
                         │          │
                       품질·계보·감사

13. DW·Data Lake·Lakehouse

구조목적
Data Warehouse정제·통합된 구조화 데이터와 분석
Data Mart부서·주제별 작은 분석 저장소
Data Lake원시·다양한 형식의 대규모 데이터 저장
Lakehouse레이크의 유연성과 웨어하우스의 관리·질의 특성 결합 지향

저장소 이름보다 데이터 품질, 메타데이터, 권한, 비용, 사용 패턴을 봐야 한다.

14. 장애와 재처리

  • 작업 ID·입력 버전 기록
  • 체크포인트
  • 멱등 출력
  • 중간 결과 격리
  • 원자적 파일 교체
  • 오류 레코드 별도 보관
  • 처리건수·합계 대사
  • 스키마 변경 호환성
  • 데이터 계보

분산 처리에서 일부 노드만 성공할 수 있으므로 전체 성공 조건과 재시작 위치를 명확히 한다.

15. 파티셔닝·일관성·쿼럼 계산

N개 replica에서 read quorum R, write quorum W가 R+W>N이면 읽기·쓰기 집합이 적어도 하나 겹친다. W가 과거 쓰기와 겹치려면 2W>N 조건도 고려한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
N=3, R=2, W=2 → R+W=4>3, 2W=4>3

이 조건만으로 모든 장애·동시쓰기에서 선형화 가능성이 자동 보장되는 것은 아니며 버전·충돌 해결과 coordinator 동작이 필요하다.

16. CAP와 PACELC

네트워크 분할(P)이 발생하면 일관성(C)과 가용성(A)을 동시에 완전히 보장할 수 없다는 것이 CAP의 핵심이다. 정상 상황에도 PACELC는 Else에서 지연시간(L)과 일관성(C)의 선택이 있음을 강조한다.

17. HDFS 상태와 블록 배치

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Client ↔ NameNode: namespace·block metadata
Client ↔ DataNodes: 실제 block 스트리밍
DataNode → NameNode: heartbeat·block report

NameNode는 일반적으로 사용자 파일 데이터를 직접 전달하지 않는다. DataNode 장애가 감지되면 부족한 replication factor를 복구하도록 다른 노드에 복제를 지시한다. 작은 파일이 지나치게 많으면 namespace metadata 부담이 커진다.

18. MapReduce·Spark 장애 복구

MapReduce의 shuffle은 mapper 중간 결과를 key별 partition으로 정렬·전송해 reducer에 모은다. Spark RDD는 lineage를 이용해 잃은 partition을 재계산할 수 있지만, 긴 lineage는 checkpoint로 끊을 수 있다. cache는 성능 최적화이지 영구 저장 보장이 아니다.

19. 스트림 처리 상태

  • event time: 사건 발생 시각
  • processing time: 시스템 처리 시각
  • watermark: 늦은 이벤트를 어느 정도까지 기다릴지 나타내는 진행 기준
  • backpressure: downstream 처리보다 입력이 빠를 때 upstream을 늦추는 제어

윈도 결과를 너무 일찍 확정하면 late event를 놓치고, 지나치게 오래 기다리면 지연·상태 크기가 증가한다. exactly-once state와 외부 sink의 부수효과 보장 범위를 구분한다.

20. 데이터 플랫폼 선택

DW는 관리된 구조·BI에, lake는 원시·다양한 데이터 저장에, lakehouse는 객체 저장의 개방성과 테이블 트랜잭션·스키마 관리를 결합하려는 구조다. 명칭보다 ACID 범위, metadata, governance, 성능·비용을 비교한다.

확인 문제

  1. N=3, R=2, W=2에서 R+W 조건은?
  2. CAP가 적용되는 핵심 상황은?
  3. HDFS에서 실제 block 데이터를 저장하는 것은?
  4. Spark RDD lineage의 장애 복구 역할은?
  5. watermark의 목적은?