バックエンド

12. 데이터 시스템의 미래

gilbert9172 — Mon, 10 Nov 2025 19:46:35 +0900

❒ 개요

이번 장에서는 미래에는 어떻게 돼야 하는지에 대해서 설명함.
앞에서 배운 아이디어들을 함께 모아 그것을 기반으로 미래를 고찰하자.

❒ 1. 데이터 통합

가장 적절한 소프트웨어 도구를 선택하는 것은 상황에 따라 다름.
선택의 폭이 넓은 경우
1. 소프트웨어 제품과 그 제품고가 잘 어울리는 환경 사이의 대응 관계를 파악하는 것
2. 복잡한 환경에서는 데이터를 여러 가지 다른 방법으로 사용하기 때문에, 소프트웨어가 모든 상황에 대처할 가능성이 낮음.

1-1. 파생 데이터에 특화된 도구의 결합

개요

OLTP용 데이터베이스(트랜잭션 처리 DB)만으로는 임의 키워드 검색(full-text search) 같은 걸 잘 처리하기 어려움.
PostgreSQL 같은 DB도 풀텍스트 기능을 제공하지만
- 복잡하고 정교한 검색을 하려면 Elasticsearch, Solr 같은 전문 검색 도구가 더 적합
반대로, 검색 인덱스는 system of record로 쓰기엔 내구성/일관성 측면에서 좋지 않음.
- 따라서, 중요한 데이터는 여전히 RDB에 저장해야 함.
그래서 실무에서는 아래의 도구를 조합해서 요구사항을 만족 시킴
- “쓰기/정합성”은 DB
- “검색/질의”는 검색엔진
같은 비즈니스 데이터가 여러 시스템에 복제·변환돼 존재하기 때문에
- 각 시스템을 어떻게 통합하고 동기화할지가 점점 더 어려움.

데이터플로에 대한 추론 (Reasoning about dataflows)

모든 쓰기의 순서를 결정하는 단일 시스템으로 모든 사용자 입력을 밀어 넣을 수 있다면
- 쓰기를 같은 순서로 처리해 데이터를 다른 표현형으로 파생하기가 훨씬 쉬워짐

파생 데이터 vs 분산 트랜잭션

추상적인 수준에서 보면 파생 데이터와 분산 트랜잭션은 다른 방식으로 유사한 목표를 달성함.
1. 분산 트랜잭션
  - 상호 배타적인 잠금을 사용해 순서를 결정
  - 원자적 커밋을 사용해 변경 효과가 정확히 한 번 나타나도록 보장
2. 파생 데이터
  - 로그를 사용해서 순서를 결정
  - 결정적 재시도와 멱등성을 기반으로 함.
두 시스템의 가장 큰 차이점
1. 트랜잭션 시스템
  - 선형성을 지원함.
2. 파생 데이터 시스템
  - 비동기로 갱신되기 때문에 기본적으로 동시간 갱신 보장을 하지 않음.

전체 순서화의 제약 (The limits of total ordering)

모든 이벤트를 하나의 글로벌 순서로 정하는 것은 작고 단순한 시스템에서는 가능
하지만 파티셔닝, 다중 데이터센터, 마이크로서비스, 오프라인 클라이언트 등 현실적인 요구가 늘어나면
전역 total order를 유지하는 것이 근본적으로 어렵고, 현재 합의 알고리즘으로도 한계가 있다

인과성 획득을 위한 이벤트 순서화
➔ 모든 이벤트를 전역 순서로 정하지 못하더라도, 중요한 ‘인과관계(causality)’만큼은 어떻게 보존할 것인가?

이벤트 간 인과성이 없는 경우 전체 순서가 정해지지 않아도 큰 문제가 아님.
- 동시에 발생한 이벤트는 임의의 순서로 정할 수 있기 때문임.
예시 : 친구 끊고, 뒷담
- 친구 상태를 저장하는 곳과 메시지를 저장하는 곳이 다른 시스템의 경우
  - 친구 끊기 이벤트와 메시지 보내기 이벤트 사이의 순서 의존성이 없음.
  - 이 경우, 뒷담 깐거를 들길 수 있음.
이 문제를 해결할 수 있는 3가지 방법 제시
1. 논리적 타임스탬프(Logical timestamps)
2. “사용자가 본 상태”를 이벤트로 기록하기
3. 충돌 해소(Conflict resolution) 알고리즘

1-2. 일괄 처리와 스트림 처리

필자는...

데이터 통합의 목표는 데이터를 올바른 저장소에 올바른 형태로 두는 것이라고 생각함.
이렇게 하기 위해서는 아래의 과정을 거쳐야 함.
- 입력 ➔ 형 변환 ➔ 필터링 ➔ 집계 ➔ 모델 학습 ➔ 평가 ➔ 출력
일괄 처리자와 스트림 처리자는 이 목표를 달성하기 위한 도구임.

파생 상태 유지

입력과 출력을 잘 정의한 결정적 함수의 원리는
1. 내결함성에 도움이 됨.
2. 조직 내의 데이터플로 추론을 단순화 함.
이론상으로 파생 데이터 시스템은
- 관계형 DB가 색인할 테이블에 기록하는 트랜잭션 내에서 보조 색인을
  동기식으로 갱신하는 것처럼 동기식으로 운영할 수 있음.
- 하지만 비동기 방식을 사용하면 이벤트 로그 기반 시스템을 훨씬 견고하게 만들 수 있음.
분산 트랜잭션은
- 참여 장비 일부가 실패하면 어보트하기 때문에 나머지 시스템으로 실패가 확산되어 실패가 증폭되는 경향이 있음.

애플리케이션 발전을 위한 데이터 재처리

기존 데이터를 재처리하는 것은 시스템을 유지보수하기 위한 좋은 메커니즘으로
- 새로운 기능 추가와 요구사항에 대응할 수 있게 만듬.
재처리 없이 스키마를 변경하는 작업은
- 레코드에 새 선택적 필드를 추가하거나
- 새로운 타입의 레코드를 추가하는 것과 같은 간단한 것으로 제한됨.
이런 제약은 읽기 스키마와 쓰기 스키마 모두에 해당
파생뷰를 사용하면 점진적 발전이 가능함.
- 데이터셋을 재구축해야 할 경우 갑자기 뷰 이전을 수행할 필요가 없음.
- 신/구 버전의 독립적인 파생 뷰를 만들 수 있음.
- 즉, 뭔가 잘못됐을 때 쉽게 롤백할 수 있음.

람다 아키텍쳐

일괄 처리를 과거 데이터를 재처리하는데 사용하고, 최근 갱신 데이터를 처리하는데 스트림 처리르 사용
핵심 아이디어
- 람다 아키텍처를 쉽게 설명하면, 들어오는 모든 데이터를 삭제하거나 수정하지 않고 일단 저장해두고,
  필요할 때마다 저장된 데이터를 다양하게 분석하거나 복구하는 구조라고 이해하면 됨.
- 즉, 데이터를 바꾸거나 지우지 않고 계속 추가만 해서 "모든 기록을 남겨두는 방식"
- 실제로 잘못된 결과가 나오거나 새로운 분석 방법이 생겼을 때도 원본 데이터를 바탕으로 다시 계산하거나,
  원하는 정보로 바꿀 수 있음.
이 아키텍쳐에서 스트림 처리자는
- 이벤트를 소비해 근사 갱신을 뷰에 빠르게 반영함.
- 이후에 일괄 처리자가 같은 이벤트 집합을 소비해 정확한 버전의 파생 뷰에 반영함.
이 아키텍쳐의 설계 배경은
- 일괄 처리는 간단해서 버그가 생길 가능성이 적음.
- 반면에 스트림 처리자는 신뢰성이 떨어지고 내결함성을 확보하기 어렵다는 것.
근데 필자는 람다 아키텍쳐에 문제가 있다고 생각함
1. 배치 코드 + 스트림 코드를 두 벌 유지해야 함.
2. 전체 재처리는 비싸서, 결국 “증분 배치”가 필요해짐. (특정 시간의 데이터만 배치 처리하는 등..)

일괄 처리와 스트림 처리의 통합

최근에는 같은 시스템에서 일괄 처리 연산과 스트림 연산을 모두 구현함으로써
람다 아키텍처의 단점을 빼고 장점만 취할 수 있게 하는 작업이 진행되고 있음.
배치와 스트림을 한 시스템으로 통합하려면 다음 세 가지 기능이 필요함.
- 최근 이벤트 스트림을 다루는 처리 엔진에서 과거 이벤트를 재생하는 능력
- 스트림 처리에서도 Exactly-once semantics 보장
- 이벤트 시간(event time) 기준 윈도우링 지원
위 세 가지 기능을 가지고 있다면
- 람다 아키텍처처의 단점은 없앨 수 있고,
- 하나의 스트리밍/데이터플로우 엔진이
  - 실시간 처리, 과거 재처리, 파생 뷰 유지 를 모두 담당하는 통합 모델을 만들 수 있음.

❐ 2. 데이터베이스 언번들링 (데이터베이스의 분리)

저자는 운영체제(Unix) 와 데이터베이스(DB) 를 비교하면서
두 시스템이 같은 목적을 다른 철학으로 해결한 역사적 흐름을 설명하는 파트
Unix는 단순하지만 직접 해야 할 게 많음
DB는 강력하지만 내부가 감춰져 있음.
현대 시스템은 이 둘의 장점을 결합해 “유연하면서도 강력한 데이터 시스템”을 지향함.
- 이것이 바로 데이터베이스 언번들링의 출발점

2-1. 데이터 저장소 기술 구성하기

데이터베이스가 제공하는 다양한 기능에 대한 요약 설명

보조 색인은 필드 값을 기반으로 레코드를 효율적으로 검색할 수 있는 기능이다.
구체화 뷰는 질의 결과를 미리 연산한 캐시의 일종이다
복제 로그는 데이터의 복사본을 다른 노드에 최신 상태로 유지하는 기능이다.
Full-text 검색 색인은 텍스트에서 키워드 검색을 가능하게 하는 기능이다.

색인 생성하기

필자는 인덱스 생성이 단순한 DB 내부 작업이 아니라,
- 데이터 재처리(reprocessing) 와 파생 데이터(derived data) 의 일종임을 강조
CREATE INDEX 실행 시 일어나는 일
1. 일관된 스냅샷(consisent snapshot) 확보
  - 인덱스를 생성하려면, 특정 시점의 테이블 상태를 완전하게 읽어야 함.
  - DB는 트랜잭션 격리 수준을 활용해 일관된 시점의 데이터 복사본(snapshot) 을 확보.
2. 인덱싱할 필드 추출 및 정렬
  - 예: CREATE INDEX ON users(email)
  - 모든 users.email 값을 읽어서 정렬 후, B-Tree 혹은 다른 인덱스 구조로 저장.
3. 인덱스 파일 쓰기
  - 정렬된 데이터를 기반으로 새로운 인덱스 파일을 디스크에 기록.
4. 스냅샷 이후에 발생한 쓰기(write) 처리
  - 인덱스 생성 중에도 테이블은 계속 쓰기될 수 있음.
  - DB는 “스냅샷 이후 발생한 변경분(backlog)”을 추적하여 새 인덱스에 반영.
5. 지속적인 동기화
  - 인덱스 생성이 끝나면, 이후 트랜잭션이 테이블에 쓰기할 때마다 인덱스도 함께 갱신..
즉, 새 인덱스를 만든다는 것은
- 기존 데이터를 전부 복제해서 새로운 형태로 저장하는 것과 같음

모든 것의 메타데이터베이스 (The meta-database of everything)

일괄 처리와 스트림 처리로 유지하는 파생 데이터 시스템은 마치 다양한 색인 유형과 비슷함.
기존에는 하나의 DB 엔진 안에 모든 인덱스 기능 포함
- B-tree, Hash, Spatial 등
각 기능을 독립된 전문 시스템으로 분리(Unbundling) 하는 방향으로 진화
- 텍스트 검색 : Elasticsearch, OpenSearch
- 이벤트 스트림 저장 : Kafka
- ...
필자는 서로다른 저장소와 처리 도구를 사용하지만 하나의 응집된 시스템으로
구성할 수 있는 2가지 방법이 있다고 생각함.
1. 연합 데이터 베이스 : 읽기를 통합
  - 여러 종류의 저장 엔진과 처리 방식을 대상으로 하나의 통합 쿼리 인터페이스를 제공하는 접근.
  - 즉, 다양한 데이터 소스를 하나의 SQL처럼 읽을 수 있게 하는 방식.
  - 쓰기(write) 일관성 유지나 트랜잭션 처리에는 약함
  - PostgreSQL Foreign Data Wrapper (FDW)\
    - 외부의 다른 데이터 소스(MySQL, CSV, REST API 등)를 PostgreSQL 테이블처럼 읽을 수 있음.
2. 언번들링 데이터베이스 : 쓰기를 통합
  - 여러 저장소 간에 쓰기(write) 를 일관되게 동기화(synchronize) 하는 문제를 다룸.
  - 즉, “데이터 변경을 여러 시스템에 안정적으로 반영” 하는 방식.
  - Change Data Capture (CDC), Event Log, Outbox Pattern 등을 통한 데이터 동기화.
  - 예: 트랜잭션 로그를 Kafka로 보내고, 이를 검색 인덱스나 캐시 시스템이 구독함.

언번들링이 동작하게 만들기

Federation vs Unbundling — “같은 동전의 양면”
- Federation : 여러 데이터 소스를 하나의 인터페이스로 읽기(read) 통합
- Unbundling : 여러 데이터 시스템 간 쓰기(write) 를 일관되게 동기화(synchronize)
  → 둘 다 이질적인 시스템을 결합(composition) 한다는 점에서 동일한 목표를 가진다.
쓰기 동기화(Write Synchronization)는 훨씬 어려움
- 읽기 통합은 단지 “데이터 모델 간 매핑(mapping)” 문제라서 상대적으로 단순함.
- 하지만 쓰기 통합은 여러 시스템에 걸쳐 데이터를 정합성 있게 동시에 반영해야 함.
- 즉, “한쪽에 쓴 내용이 다른 쪽에도 반영되어야 한다”는 문제는 훨씬 복잡하다.
전통적 접근: 분산 트랜잭션(Distributed Transactions)
- 과거에는 여러 저장소에 걸친 쓰기를 2PC 등의 분산 트랜잭션으로 처리하려고 했다.
- 하지만 이 방식은 다음과 같은 문제가 있음:
  - 이기종 시스템 간에는 표준화된 트랜잭션 프로토콜이 없음.
  - 네트워크 지연, 장애 시 전체 시스템이 멈출 위험(결합도가 너무 높음).
  - 따라서 확장성과 견고성이 떨어지는 구조가 됨.
추천 접근: 이벤트 로그(Event Log) 기반의 비동기 통합
- 저자는 대신 다음 방식을 제안 ➔ “비동기 이벤트 로그 + 멱등(idempotent) 쓰기”
- 즉, 데이터를 쓸 때 즉시 여러 시스템에 쓰는 대신,
  - 하나의 이벤트 로그에 변경을 기록하고
  - 다른 시스템들은 이 로그를 구독(consume)하며 상태를 갱신
- 이 방식은 Derived Data System, Change Data Capture(CDC) 와 같은 형태로 구현된다.
왜 이벤트 로그 방식이 더 나은가
1. 시스템 수준의 이점 - 느슨한 결합
  - 각 구성 요소가 비동기적으로 통신하므로, 일부 시스템이 느리거나 장애가 나도 전체가 멈추지 않음.
  - 이벤트 로그가 버퍼 역할을 하며 데이터 손실을 방지.
  - 장애가 복구되면 소비자(consumer) 는 이벤트를 재처리(catch up) 가능.
  - 반대로 분산 트랜잭션은 동기적으로 묶여 있어서 부분 장애가 전체 장애로 확산(escalation) 되기 쉽다.
2. 조직 수준의 이점 — 독립 개발과 유지보수
  - 각 팀이 자신의 시스템에만 집중할 수 있다.
  - 팀 간 인터페이스(계약)가 명확해짐.
이벤트 로그의 핵심 속성 (아래 속성이 결합되어 분리된 시스템 간 강력한 일관성을 유지하는 기능하게 함)
- 내구성 (Durability)
- 순서 보장 (Ordering)
- 멱등성 (Idempotence)
결론
- Unbundling(분리된 데이터 시스템의 통합) 을 가능하게 만드는 핵심은
  분산 트랜잭션이 아니라 비동기 이벤트 로그(asynchronous log) 기반의 통합이다.
- 시스템적으로는 느슨한 결합과 복원력(resilience)을 확보하고,
- 조직적으로는 독립된 개발·운영을 가능하게 한다.
- 결국 “로그(Log)”는 데이터 통합의 중심 축이자,
  현대 분산 아키텍처에서 데이터 일관성을 유지하는 가장 현실적인 수단이다.

언번들링 vs 통합 시스템

저자는 “Unbundling이 미래의 방향”이라고 말하면서도,
통합형 데이터베이스의 역할이 여전히 필수적임을 강조
즉, “모든 걸 분리하라”가 아니라 “필요할 때만 분리하라”
Unbundling이 대체가 아니라 “보완”
- “Unbundling(분리형)” 접근이 데이터베이스를 완전히 대체하지는 않는다.
- 즉, 스트림/배치 시스템의 결과를 저장하고 서빙(Serving) 하는 역할은 여전히 DB가 맡는다.
필요없는 확장은 낭비

뭐가 빠졌지?

우리는 Kafka, DB, Search, Stream Processor 등 훌륭한 부품을 이미 갖고 있음
하지만 이들을 Unix 파이프처럼 단순하게 조합할 “언어(shell)” 가 아직 없다.

2-2. 데이터플로 주변 애플리케이션 설계

데이터 파생(derivation)은 모든 시스템의 핵심 동작이다.
하지만 단순 인덱스 생성 외의 복잡한 파생 로직은 애플리케이션 코드로 직접 구현해야 한다.
대부분의 데이터베이스는 이러한 “파생 로직(derivation function)”을 내장적으로 다루지 못한다.
➔ 이는 Unbundled Architecture 의 핵심 과제 중 하나다.

파생 함수로서의 애플리케이션 코드

모든 파생 데이터는 원본 데이터를 변환 함수(transformation function) 를 통해 얻어짐.
자동화된 파생 함수 vs 커스텀 파생 함수
- 자동화된 파생 함수
  - 보조 인덱스(secondary index) 생성은 너무 자주 쓰이기 때문에
    DB가 내부적으로 자동 처리 기능으로 내장 (CREATE INDEX).
  - 즉, derivation function이 DB 엔진에 내장되어 있음.
- 커스텀 파생 함수
  - 전문 검색, 머신러닝, 캐시 구축 등은 도메인 특화 로직이 필요함.
  - 따라서 표준화된 기능이 아니라 직접 코드로 구현해야 함.
  - 이 때 애플리케이션 코드가 derivation function 역할을 수행.

애플리케이션 코드와 상태의 분리

“DB는 데이터 저장에, 애플리케이션은 코드 실행에” → 역할 분리가 합리적
“상태(state)는 DB에, 로직(logic)은 코드에” → 이것이 오늘날의 기본적인 시스템 구조
DB는 “공유 가능한 가변 변수(shared mutable variable)” 처럼 작동
- 하지만 문제는 DB 변경을 실시간으로 감지(subscribe) 하기 어려움
- 대부분의 DB는 수동적(polling) 방식: “값이 바뀌었는지”를 주기적으로 쿼리해야 함.
- 최근의 CDC·Change Stream 기술은 이 간극을 메워, DB와 애플리케이션 간의 진정한 분리가 가능함

데이터플로 : 상태 변경과 애플리케이션 코드 간 상호작용
➔ Unbundled Database = Dataflow 시스템으로 재조립된 DB

기존의 관계 — “코드가 상태를 조작한다”
- 전통적으로 우리는 DB를 단순한 상태 저장소(state holder) 로 봄
- 애플리케이션이 DB를 읽고 → 로직 처리 후 → DB에 다시 쓴다.
- 즉, 애플리케이션은 명령어 중심(command-driven) 으로 동작하고,
- DB는 수동적(passive) 역할에 머문다.
새로운 관점 — “상태 변화와 코드의 상호작용(interplay)”
- 이제는 DB의 상태 변화 자체를 이벤트(event) 로 보고,
- 애플리케이션 코드가 그 변화를 구독(subscribe) 하여 반응하는 구조로 변화.
- 예:
  - 사용자가 주문 생성 → “OrderCreated” 이벤트 발생
  - 코드가 이 이벤트를 받아 → 결제 요청, 재고 차감 등의 후속 상태 변화(trigger)
- 즉, 하나의 상태 변화가 또 다른 상태 변화를 유도하는 체계적인 데이터 흐름.
역사적·구조적 맥락
- 이 개념은 “데이터베이스와 스트림은 동등하다” 는 책의 핵심 논의에서 이어진다.
  - DB의 트랜잭션 로그(log)는 곧 이벤트 스트림(event stream)이다.
  - 따라서 로그를 구독하면 DB의 상태 변화를 실시간으로 감지할 수 있다.
- 비슷한 아이디어가 이미 오래전부터 존재했음:
  - Actor 모델 (메시지 기반 동시성)
  - Tuple space 모델 (프로세스가 공유 상태의 변화에 반응)
  - Triggers & Secondary Indexes (DB 내부의 자동 반응 로직)
Unbundling 관점에서 본 Dataflow
- DB 내부에서만 일어나던 “상태 변화에 대한 반응(trigger)”을 외부 시스템으로 확장하는 것.
- 예:
  - DB → Kafka (Change Event)
  - Kafka → Elasticsearch (검색 인덱스 업데이트)
  - Kafka → ML Pipeline (모델 업데이트)
  - Kafka → Cache (UI 캐시 리빌드)
- 이 모든 과정이 데이터플로우(dataflow) 로 연결된다.
- 즉, “상태 변화 → 코드 반응 → 새로운 상태 생성”의 연쇄.
데이터플로우와 일반 메시징 시스템의 차이점
- 파생 데이터를 유지하기 위해선 아래 두 가지 조건이 매우 중요함.
  - 순서 보장
  - 내구성 & 내결함성
Stream Processor = 현대의 파생 함수 엔진
- 각 스트림 연산자(operator)는 “데이터 변화”를 입력으로 받아 새로운 상태를 산출하는 “함수” 로 동작.

스트림 처리자와 서비스

요즘 개발 스타일 트렌드는
- 각 기능을 동기 네트워크 요청을 통해 통신하는 서비스의 집합으로 나누는 것
- 느슨한 연결을 통한 조직적 확장성
새로운 패러다임: Stream-based Dataflow Systems
- 스트림 처리 시스템도 “작은 단위의 연산(operators)”을 연결하여 큰 시스템을 구성한다는 점에서 마이크로서비스와 유사함.
- 그러나 핵심 차이는 통신 방식에 있음:
  - Microservice → Request/Response (동기식)
  - Dataflow → Message Stream (비동기식)
- 즉, “함수 호출”이 아닌 “데이터 흐름(event flow)”으로 상호작용한다.
스트림 기반 접근의 본질: Stream Join
- 이 접근은 “RPC 호출”을 “스트림 조인(stream join)”으로 대체한 것.
- 두 이벤트 스트림:
  1. purchase events (구매 이벤트)
  2. exchange rate updates (환율 이벤트)
- 두 스트림을 시간 기준으로 조인하여 → “구매 시점의 환율”을 결합.
- 시간 의존성(time-dependence) 주의:
  - 나중에 재처리할 경우 환율이 달라질 수 있음.
  - 따라서 “구매 시점의 환율”을 복원하려면 과거 환율 이벤트를 함께 보관해야 함.
데이터플로우 접근은 “요청 기반(request-driven)” → “이벤트 기반(event-driven)” 으로의 진화다.

2-3. 파생 상태 관찰하기

Write Path는 즉시 처리(eager), Read Path는 요청 시 처리(lazy) 라는 관점에서 서로 보완 관계를 이룬다.

설계 방향	특징	예시
Write-heavy (사전 계산 중심)	- 쓰기 시점에 많은 계산 수행- 읽기 시 매우 빠름	검색 인덱스, Materialized View
Read-heavy (요청 시 계산 중심)	- 쓰기는 가볍지만- 읽기 시 많은 계산 필요	OLTP 쿼리, 실시간 집계
균형형	- 일부는 사전 계산, 일부는 실시간 계산	캐시 + 비동기 업데이트

파생 데이터(derived dataset)는 “미리 계산할지, 나중에 계산할지” 의 균형점이다.
시스템 설계는 “계산 시점”을 어디에 둘 것인가의 문제다.

구체화 뷰와 캐싱

인덱스는 “쓰기 시점에 미리 정리해두는 구조"이므로 읽기 속도를 빠르게 만들지만, 쓰기 오버헤드 존재
현실적 절충: Common Queries Cache
- 자주 등장하는 쿼리만 미리 계산(cache or materialized view) 해둠.
- 나머지 쿼리는 기존 인덱스를 이용해 실시간 검색.
- 이 구조를 “common query cache” 혹은 “materialized view” 라고 부른다.

오프라인 대응 가능한 상태 저장 클라이언트
➔ “만약 클라이언트가 자체적으로 상태(state)를 갖는다면, 서버-클라이언트 구조는 어떻게 달라질까?”

지난 20년간 웹 애플리케이션은 “서버 중심, 클라이언트 무상태" 모델을 기본으로 함.
PA(Single Page Application)와 모바일 앱의 등장으로 패러다임이 바뀜
클라이언트가 저장하는 데이터는 서버의 상태(state) 를 부분 복제(partial replica) 한 것.
- 서버 → 진리의 원본(Source of Truth)
- 클라이언트 → 구체화 뷰 혹은 캐시
- 서버의 상태 변경이 클라이언트에 반영될 때까지 동기화 지연(sync delay) 존재함

상태 변경을 클라이언트에게 푸시하기
➔ 로컬 상태를 어떻게 서버 상태와 동기화할 것인가

기존의 웹 패턴
- Polling 기반, Stale Cache
변화 (Push 기반 프로토콜의 등장)
- Server-Sent Events (SSE), WebSocket 같은 기술이 등장하면서
- 서버 → 클라이언트 방향의 푸시(push) 통신이 가능해짐.
- 클라의 로컬 상태는 더 이상 정적 캐시가 아니라,
  서버 이벤트 스트림과 실시간으로 동기화되는 복제 상태가 된다.
기존에는 Write Path가 서버 내부의 파생 데이터(인덱스, 뷰 등) 까지만 도달
- 하지만 Write Path가 클라이언트까지 확장됨.
- 즉, 서버의 변경 이벤트가 클라이언트로 스트림 형태로 전송.
오프라인 상태를 고려한 동기화 전략
- 클라이언트는 종종 오프라인 상태가 되므로, 서버의 이벤트를 받을 수 없는 시간 구간이 생김.
- 로그 기반 메시징 시스템(Kafka 등)의 offset 재연결 패턴으로 해결 가능

종단 간 이벤트 스트림

현대 데이터 시스템의 미래는 “end-to-end event streams”이다.
즉, 사용자의 입력부터 다른 사용자 화면의 변화까지 하나의 이벤트 스트림으로 연결되는 구조.
이를 위해서는 “stateless request/response” 패러다임을 넘어
“stateful, publish/subscribe dataflow” 로 전환해야 한다.
데이터를 질의하는 대신 변화를 구독(subscribe)해야 한다.\

읽기도 이벤트다

기존 구조: “읽기와 쓰기”의 분리
- 지금까지의 모델에서는 다음처럼 역할이 나뉨:
  - Write Path: 이벤트 로그를 기반으로 파생 데이터 생성.
  - Read Path: 저장소(DB, Cache, Index)를 쿼리하여 결과 반환.
- 즉, 읽기(Read)는 한 번의 네트워크 요청, 쓰기(Write)는 이벤트 스트림의 일부로만 다뤄짐.
- 그러나 저자는 읽기도 이벤트로 볼 수 있음.
새로운 관점: “읽기 요청도 이벤트다”
- 즉, 읽기 요청(read query)을 하나의 이벤트(read event) 로 표현하고,
- 이를 스트림 프로세서(stream processor) 가 처리할 수 있음.
- 새로운 데이터플로우 구조:
  - [Read Request Event Stream] → [Stream Processor] → [Read Result Event Stream]
    - 사용자는 “요청” 이벤트를 발행(publish)
    - 스트림 프로세서가 “결과” 이벤트를 발행(subscribe & process)
    - 이 구조는 요청/응답(request/response) 모델을 pub/sub 패러다임으로 대체함.
Stream-Table Join으로서의 “읽기”
- 쓰기와 읽기를 모두 이벤트로 표현하면,
  “읽기 요청 스트림”과 “데이터 스트림(또는 테이블)”을 조인(join) 하는 형태로 해석할 수 있음.
One-off Read vs Subscription Read
- 일회성 조회(one-off read):
  - 단일 요청을 조인에 통과시켜 결과를 반환하고 종료.
  - 일반적인 “쿼리 1회 실행” 형태.
- 구독형 조회(subscribe request):
  - 지속적으로 조인 상태를 유지.
  - 데이터가 바뀌면 새 결과를 푸시.
  - 즉, “Reactive Query / Live Query” 모델.
읽기 이벤트를 기록(Log)할 때의 부가 가치
- 읽기 이벤트를 로그에 남기면,
  데이터 혈통(data provenance) 과 인과관계(causality) 추적이 가능함
- 예시:
  - 사용자 A가 상품을 봄 → 재고 “있음” 상태 확인 → 구매 결정
  - 그 후 재고가 소진됨
  - 나중에 “왜 구매 버튼을 눌렀는가?”를 분석하려면
    - 사용자가 “당시 어떤 정보를 봤는지” 기록이 필요함 → 읽기 로그
- 읽기 이벤트를 남기면, 시스템 전체의 원인(Why) 을 재구성할 수 있음.
쓰기와 읽기를 모두 로그로 통합하면…
- 읽기 이벤트도 로그에 기록하면:
  - 장점: 완전한 인과 추적 가능 (cause & effect)
  - 단점: 저장 공간, I/O 부하 증가
- 하지만 이미 쓰기 로그를 운영 중이라면, 읽기 로그도 함께 남기는 것은 자연스러운 확장임.

다중 파티션 데이터 처리

트위터의 분산 RPC
- 다중 파티션에 분산된 데이터를 스트림 조합으로 통합
스트림 기반 다중 파티션 쿼리의 장점
- MPP (Massively Parallel Processing) 데이터베이스도 유사한 일을 함.
  - 쿼리를 DAG(Directed Acyclic Graph)로 분리
  - 각 노드가 병렬로 실행
  - 마지막에 결과를 결합
- 스트림 프로세서는 이 구조를 이미 기본적으로 내장하고 있음.
  - 따라서 동일한 처리를 실시간으로(streaming) 수행할 수 있음.
실용적 제안
- 만약 단순히 일회성 쿼리라면, MPP DB를 쓰는 게 더 간단할 수 있음.
- 하지만 지속적 스트림 기반 처리가 필요하다면, 스트림 프로세서 모델이 훨씬 더 적합함.

❐ 3. 정확성을 목표로

3-1.

데이터 시스템만 믿어서는 “완전하게 안전”하지 않다

트랜잭션 격리 수준이 높고, 직렬화 가능한 DB를 사용한다고 해도
애플리케이션 레벨의 버그로 인해 데이터 손실/손상은 발생할 수 있다.
예
- 애플리케이션 버그로 잘못된 값을 UPDATE
- 삭제하면 안 되는 데이터를 DELETE
  → DB의 직렬화 트랜잭션이 이런 문제를 해결해주지 않는다.
데이터 안전은 DB가 아니라 애플리케이션도 함께 책임져야 한다.

Exactly-once 처리의 어려움

메시지 처리 중 오류가 생기면 보통 2가지 선택이 있다.
- 포기한다 → 데이터 유실
- 재시도한다 → 실제로는 성공했는데 응답이 끊겨서 재시도하면 중복 처리
이 중 “재시도했을 때도 결과가 한 번만 처리되는 것”이 바로 Exactly-once semantics.
하지만 현실에서는 정말 구현하기 어렵다.

Idempotence(멱등성)으로 해결하는 방법

가장 효과적인 방식은 작업 자체를 멱등(idempotent) 하게 만드는 것.
멱등성을 지원하려면 다음 같은 추가 메타데이터가 필요할 수 있다.
- 요청 ID
- 실행된 작업 ID 로그
- fencing token(노드 장애 시 중복 실행 방지) 등

Duplicate suppression(중복 억제)가 필요한 이유

TCP 같은 네트워크 계층도 중복을 억제해주지만, 이는 단일 TCP 연결 안에서만 의미가 있다.
문제는:
- 요청이 DB에 전달되고 COMMIT 했는데
- 클라이언트가 응답을 못 받고 타임아웃 → 다시 요청
이 경우 DB 트랜잭션 레벨에서 duplicate suppression이 되지 않으면 중복 처리 위험이 있다.

“고급 트랜잭션 프로토콜”도 완벽하지 않다

2PC 같은 프로토콜은 TCP 연결과 트랜잭션을 분리해주지만,
여전히 애플리케이션이 중복 요청을 보낼 때까지 막지는 못한다.

애플리케이션 레벨에서 Operation ID 추가하기

중복 요청을 확실히 막으려면 애플리케이션에서 end-to-end로 중복을 억제해야 한다.
핵심 아이디어
- 클라이언트가 request_id(UUID) 를 생성
- 서버로 POST할 때 함께 보냄
- DB에서 request_id를 PK/UNIQUE로 사용하여 이미 처리된 요청이면 INSERT가 실패 → 중복 방지

End-to-End Argument란 무엇인가?

Saltzer, Reed, Clark이 정의한 개념
어떤 기능이 정말로 필요하다면, 시스템의 끝단(end-to-end) 에서 보장해야 한다.
낮은 레벨(TCP, 네트워크, 등)의 보장만으로는 부족하다.
예시
- Duplicate suppression
  - TCP는 패킷 중복을 해결해줘도 클라이언트 → 서버 → DB 전체에 걸친 중복은 막지 못함.
  - 그러므로 duplicate suppression은 DB까지 end-to-end로 관통해야 한다.
- 데이터 무결성 체크
  - TCP/Ethernet 체크섬은 전송 중 오류만 잡아낸다
  - 하지만 서버 버그, 디스크 손상은 감지 못함
    → 결국 end-to-end 체크가 필요 (예: 애플리케이션 레벨 체크섬)
- 암호화
  - WiFi 암호화는 집 안 공격자만 막음
  - 서버 공격자는 못 막음 → TLS처럼 end-to-end 암호화가 필요

결론 — 데이터 안전은 결국 애플리케이션 책임도 크다

DB가 강력한 트랜잭션을 제공해도 중복 억제, 멱등성, end-to-end 검증 없이는 데이터 손상 가능
트랜잭션은 많은 문제를 “commit or abort”로 추상화하지만 현실의 장애는 더 복잡하다
대규모 분산 환경에서는 애플리케이션 수준의 end-to-end 안전성이 필수

3-2. 제약 조건 강제하기

유니크 제약(uniqueness constraint)의 어려움

유저네임, 이메일, 계좌 ID처럼 “하나만 있어야 하는 값”을 보장하는 것은 쉬워 보이지만,
분산된 환경에서는 매우 어렵다.
예를 들어:
- 두 개의 노드가 동시에 같은 이메일로 회원가입
- 두 데이터센터에서 같은 좌석을 동시에 예약
  → 모두 “유일해야 하는 값”이기 때문에 충돌을 해결해야 한다.

왜 어려울까? → 유니크 보장은 합의(consensus)를 필요로 하기 때문

여러 노드가 동시에 같은 값을 삽입하려고 할 때,
시스템은 어느 요청이 승자이며, 나머지는 거절해야 하는지 결정해야 한다.
이는 결국 합의(consensus) 문제다.
가장 간단한 방식:
- 리더(leader)를 하나 두고, 모든 유니크 판단을 리더가 하게 한다.
문제점:
- 리더 노드 장애 → 다시 합의 필요
- 리더 한 개가 처리량 병목이 됨
- 클라이언트가 지구 반대편 → 높은 지연(latency)

파티셔닝 기반 유니크 보장

유니크 조건을 값 기반으로 파티션하면 확장성이 높아진다.\
예
- 요청 ID를 key로 파티션 → 같은 request_id는 항상 같은 파티션으로 감
- username을 hash(username) 기준으로 파티션 → 동일 username 충돌은 같은 파티션에서만 처리
즉, 동일 값을 유니크하게 만들려면 같은 파티션에서 처리되도록 라우팅하면 된다.
이 방식의 장점
- 파티션 별로 독립적 처리 가능 → 확장성 높음
- 각 파티션에서 순서가 보장되면(total order), 충돌 해결 가능
하지만 단점도 있다
- 비동기 멀티마스터 복제에서는 불가능(서로 다른 노드가 서로 모르게 같은 값을 허용할 수 있기 때문)\
- 유니크를 강하게 보장하려면 동기적 합의 또는 파티션 기반의 순차 처리가 필요함.

로그 기반 메시징에서 유니크 보장하기

Kafka처럼 로그 기반 메시징 시스템을 사용하면 유니크 제약을 비교적 쉽게 강하게 보장할 수 있다.
핵심 이유:
- 로그는 모든 메시지를 순서대로(total order) 기록
- 파티션 단위로는 한 스레드가 순서대로 처리
- 따라서 충돌 상황에서도 “누가 먼저 왔는지” 명확히 판단 가능

Multi-partition Request Processing (여러 파티션이 관여하면?)

문제는 여기서부터다. 금전 이체 같은 작업은 여러 파티션을 동시에 건드린다.
전통적인 DB 방식:
- 3개 파티션이 모두 참여 → 분산 트랜잭션(2PC) 필요
- 처리량 저하 + 높은 지연 → 문제가 많음

분산 트랜잭션 없이도 “동일한 정확성”을 달성하는 법

2단계 파이프라인 분리 + 로그 기반 처리 + 멱등성 조합이다.
단계 1 — 요청 ID를 기반으로 단일 메시지로 로깅
- 클라이언트가 송금 요청을 하나의 메시지로 보내고
- 로그에 append (request_id 파티션)
단계 2 — stream processor가 이 메시지를 읽고, 두 개의 별도 명령을 생성
- A 계좌 파티션: “A 계좌에서 10 빼세요”
- B 계좌 파티션: “B 계좌에 10 더하세요”
단계 3 — 두 계좌 파티션 소비자가 각각 명령 적용
- request_id를 기준으로 중복 제거
- 명령이 여러 번 와도 멱등 적용 가능
결과:
- A에서 빠지고 B에서 더하는 작업 모두 exactly once 적용됨
- 단 분산 트랜잭션 없이도 동일한 정확성 확보

장애 상황에서도 안전한 이유
➔ 만약 단계 2의 프로세서가 크래시 한다면?

체크포인트에서 재시작
로그에서 다시 읽고 같은 debit/credit 메시지 생성
하지만 단계 3에서 request_id로 dedupe → 중복 방지
즉,
- 로그는 append-only
- 처리 과정은 deterministic
- 결과는 멱등 → “한 번만 처리된 것처럼” 보장 가능

3-3. 적시성과 무결성

Transactions는 원래 “Timely”하다 (즉, Linearizable)

ACID 트랜잭션은 다음을 보장한다.
Commit이 끝난 직후, 모든 읽기는 그 결과를 본다.
즉, 쓰기(Write) → Commit → Read 가 즉시 반영된다.
이게 바로 선형성

하지만 Stream Processing에서는 이게 깨진다

Kafka처럼 로그 기반 비동기 파이프라인에서:
- 클라이언트는 메시지를 전송만 하고
- 실제 처리는 비동기 파이프라인에서 나중에 일어난다
- 그래서 “commit하자마자 읽으면 반영된다”는 보장이 없다
즉, 타임라인 상 지연이 생기는 게 기본이다.

Timeliness = “업데이트된 최신 상태를 얼마나 빨리 볼 수 있나?”

복제지연(replication lag) 때문에
내가 조금 전 업데이트한 데이터를 다른 노드에서는 잠시동안 못볼 수 있다.
하지만 몇 초 안에 eventually 반영됨.
Timeliness는 결국 “언젠가는 최신 상태가 되게 하는 속성”.

CAP의 “Consistency”도 사실 Timeliness 의미에 가깝다

Linearizability를 제공하는 시스템 = “강한 최신성 보장 시스템”.
그리고 더 약한 형태도 있다:
- Read-after-write consistency
- Monotonic reads 등

Integrity = “데이터 자체가 틀리지 않음”

Integrity는 timeliness보다 훨씬 더 중요하며 핵심적이다.
Integrity는 이런 것을 의미한다:
- 데이터가 손상되지 않았다 (no corruption)
- 데이터가 사라지지 않았다 (no data loss)
- 모순된 상태가 없다 (no contradictory state)
- 파생 데이터는 원본 데이터와 정확히 일치해야 한다

Integrity가 깨지면 “복구가 불가능하다”

Timeliness 문제는 시간이 지나면 해결되지만,
Integrity 문제는:
- 기다린다고 해결되지 않는다
- 복구 작업이 필요하다 (manual repair)
- 장애가 치명적이다

4. Event-driven 시스템은 Timeliness와 Integrity를 “분리”한다

ACID 세계에서는 동시에 제공되지만 이벤트 기반 스트림 시스템에서는 재밌는 특징이 있다:
Integrity를 보장하면서, Timeliness를 포기할 수 있다.
즉,
- 파이프라인은 비동기일 수 있고
- 최신 데이터가 바로 반영되지 않아도
- Integrity만 보장되면 된다
Integrity를 지키는 핵심 기법들
- Exactly-once / Effectively-once 처리
- 멱등(idempotent) 연산
- 중복 제거(deduplication)
- 요청 ID(request_id)를 end-to-end로 전달
- 불변 로그(immutable log)에 기반한 재처리
이 조합 덕분에 스트림 시스템은 오류가 나도 정합성을 유지할 수 있다.

5. 스트림 시스템에서 Integrity를 보장하는 패턴

모든 write를 단일 메시지로 표현 → 원자적으로 기록
모든 파생 상태는 deterministic function으로 유도
request_id를 end-to-end로 전달 → 중복 억제
모든 메시지를 immutable하게 관리

6. Loosely interpreted constraints (느슨한 제약 조건)

현실에서는 “유니크 제약”이 흔히 느슨하게 해도 된다
엄격하게 리니어라이저블하게 처리할 필요가 없는 상황 예:
- 동시에 두 사람이 같은 좌석을 예약 → 한쪽에게 사과하고 다른 좌석 제안
- 재고 5개인데 6개 주문됨 → 사과하고 환불/지연 안내
- 호텔 오버부킹(일반적 패턴) → 보상 제공
- 계정 overdraft → 나중에 수수료 부과
즉,
- 완벽한 정확성은 비싸다
- 실제 비즈니스는 사과/보상 프로세스로 수습 가능하다
- Integrity는 유지하되 Timeliness는 굳이 엄격할 필요가 없다

7. Coordination-avoiding Data Systems (조율을 피하는 시스템)

두 가지 관찰:
- 스트림 시스템은 분산 트랜잭션 없이도 integrity 보장 가능
- 많은 제약 조건은 임시 위반 가능(나중에 사과해서 해결할 수 있다)
즉, 동기적 조율(synchronous coordination) 없이도 정확성을 확보할 수 있는 시스템을 만들 수 있다.
협업이 필요 없는 대신:
- 로그 기반 비동기 처리
- request_id
- 멱등 처리
- 재생 가능한 파이프라인
- 느슨한 timeliness
이런 시스템의 장점
- 더 높은 가용성
- 더 높은 성능
- 지연이 적음
- 장애 복구에 강함
- 조율 비용이 거의 없음
AWS Dynamo, Cassandra, Kafka 기반 시스템 등이 이 철학을 따른다.

3-3. 믿어라 하지만 확인하라.

시스템은 항상 “잘못될 수 있다”

이런 일들은 드물지만 “언젠가는 반드시” 발생한다.
- 하드웨어 비트 플립
- 디스크 silent corruption
- 네트워크 데이터 손상
- DB 버그
- 애플리케이션 버그

가장 위험한 태도 = 기술을 맹신하는 것

“트랜잭션이니까 데이터는 틀리지 않겠지”
“DB가 알아서 무결성 지켜주겠지”

해결책 = Auditing & Verification

데이터가 손상됐는지 정기적으로 확인
백업 복원 테스트
해시 기반 데이터 검증
이벤트 로그 기반 재처리
end-to-end 검증
self-validating/self-auditing 시스템 구축

Event sourcing과 로그 기반 시스템은 Auditing에 매우 적합

event는 불변
deterministic derivation → 재현 가능
provenance(데이터의 기원) 추적 용이
hash 기반 무결성 검증 가능

앞으로의 데이터 시스템은 “Trust, but verify” 철학을 따른다

암호학적 무결성 검증(Merkle Tree 등)
자체 감사 기능(self-audit)
지속적 end-to-end 검증

11. 스트림 처리

gilbert9172 — Sat, 1 Nov 2025 17:33:36 +0900

❐ 0. 개요

현실 세계에서 데이터는 무한하고(unbounded) 시간이 지나면서 계속(gradually) 유입된다.
이번 장에서는 데이터 관리 메커니즘으로 이벤트 스트림을 설명한다.
이벤트 스트림은 일과 처리 데이터와는 반대로 한정되지 않고 점진적으로 처리된다.
일반적으로 "스트림"은 시간에 흐름에 따라 점진적으로 생산된 데이터를 일컫는다.

❐ 1. 이벤트 스트림 전송

Polling 방식의 한계

파일이나 데이터베이스만으로도 생산자와 소비자는 연결될 수 있다.
- 생산자는 자신이 생성한 모든 이벤트를 저장소에 기록
- 소비자는 주기적으로 저장소를 polling하여 마지막 실행 이후 새로 생긴 이벤트를 확인
- 이런 방식은 하루치 데이터를 하루가 끝날 때 처리하는 배치 처리와 유사
하지만 polling을 자주 할수록
- 새 이벤트를 실제로 얻는 요청 비율은 낮아짐.
- 즉, 시스템 오버헤드가 커지게 됨. (불필요한 요청을 많이하기 때문)
따라서 새 이벤트가 발생했을 때 소비자에게 알림이 전달되는(push) 방식이 더 효율적
데이터베이스에도 trigger 기능이 있긴 함.
- 근데 트리거는 기능이 제한적이고 데이터베이스를 설계한 이후에 도입된 개념

1-1. 메시징 시스템

메시징 시스템

새로운 이벤트에 대해 소비자에게 알려주려고 쓰이는 가장 일반적인 방법
메시징 시스템을 구축하는 가장 간단한 방법 ➔ 생산자와 소비자 사이에 직접 통신 채널을 사용하는 방식
메시징 시스템에서는 다수의 생산자 노드가 동일한 토픽으로 메시지를 전송할 수 있고,
소비자 노드가 토픽 하나에서 메시지를 받아 갈 수 있음.

시스템을 구별하는데 도움이 되는 2가지 질문

소비자가 메시지를 처리하는 속도보다, 생산자가 메시지를 전송하는 속도가 더 빠르면?
- 메시지 버리기 / 버퍼링 / 배압
노드가 죽거나 일시적으로 오프라인이 된다면 손실되는 메시지가 있을까?

생산자에서 소비자로 메시지를 직접 전달하기 - Direct messaging

많은 메시지 시스템은 생산자와 소비자를 네트워크로 직접 통신한다.
1. UDP 멀티-캐스트
2. ZeroMQ
3. ...
본래의 설계대로 동작하면 잘 동작함
- 생산자와 소비자가 항상 온라인 상태라고 가정함.
- TCP, UDP, WebSocket 같은 시스템은 이런 상황에서 문제 없이 동작
하지만 혀용 가능한 범위가 상당히 제한적이다.
- “네트워크 일시 장애” 정도는 커버하지만
- 생산자 또는 소비자가 오프라인이 되는 경우는 처리하지 못한다
네트워크 상에서 재전송을 지원하더라고, 애플리케이션 레벨에서는 모를 수 있음.
- 따라서 메시지가 유실될 수 있는 가능성을 고려해서 애플리케이션 코드를 작성해야 한다.

메시지 브로커 (메시지 큐)

Direct messaging의 대안으로 널리 사용되는 방법
근본적으로 메시지 스트림을 처리하는데 최적화된 데이터베이스의 일종
메시지 브로커는 서버로 구동되고 생산자와 소비자는 서버의 클라이언트로 접속함.
- 생산자 ➔ 브로커 ➔ 소비자
이 방식에서는 브로커에 데이터가 모이기 때문에 소비자 또는 생산자 노드가 오프라인이여도 쉽게 대처 가능
- 지속성 문제가 브로커로 옮겨갔기 때문
브로커가 장애로 중단됐을 때도 메시지를 잃어버리지 않기 위해 디스크 또는 메모리에 메시지를 기록함.
소비 속도가 느린 소비자가 있으면 배압을 사용하는 것과 반대로 큐가 제한 없이 늘어나게 함.
대기 큐를 사용하면 소비자는 일반적으로 비동기로 동작함.
- 생산자는 메시지 소비 유무를 신경 안 씀
- 물론 큐에 대기중이 메시지가 많으면 쫌 시간이 지나서 처리될 순 있긴 함.

메시지 브로커와 데이터베이스 비교

구분	데이터베이스	메시지 브로커
삭제	데이터를 명시적 삭제해야 함	메시지는 소비자에게 전달되면 자동 삭제
큐 크기	저장 공간이 커도 문제 없음	작업 집합이 작다고 가정 (작은 큐 크기)
데이터 선택/조회 방식	SQL, 인덱스, 조건 검색 등 쿼리 중심	Topic 기반 구독, 패턴 매칭 제공
질의와 변경 감지	- 쿼리 결과는 특정 시점(snapshot) 기준 - 이후 변경은 자동 반영되지 않음 (polling 필요) - 정적 질의 위주	- 데이터 변경 시 자동 알림(push) - 새 메시지가 생기면 구독자에게 전달 - 실시간 알림 중심

복수 소비자
➔ 같은 토피에서 메시지를 읽을 때 사용하는 주요 패턴

로드 벨런싱

각 메시지는 소비자 중 하나로 전달.
따라서 소비자들은 해당 메시지를 처리하는 작업을
공유한다.
브로커가 메시지를 전달할 소비자를 임의로 지정한다.
메시지 처리 비용이 비싸서, 처리를 병렬화 하기 위해
소비자를 추가 하고싶을 때 유용함.

팬 아웃

각 메시지는 모든 소비자에게 전달된다.
여러 독립적인 소비자가 브로드캐스팅된 동일한 메시지를
간섭 없이 청취(tune-in)할 수 있다.
이것은 같은 입력 파일을 읽어 여러 다른 일괄 처리
작업에서 사용하는 것과 동일

위 두가지 패턴은 함께 사용이 가능함.
- 소비가 그룹 A,B가 TopicA를 구독
- 각 그룹에서 모든 메시지 받음.
- 단, 각 메시지를 하나의 노드만 받게 함.

확인 응답과 재전송

메시지 브로커는 메시지를 잃어버리지 않기 위해서 확인 응답(acknowledgments)을 사용한다.
- 클라이언트는 메시지 처리가 끝났을 때 브로커에게 명지적으로 알려야 함.
브로커가 확인 응답을 받기 전에 클라에서 문제가 생기면 메시지가 처리되지 않았다고 가정
- 그리고 다른 소비자에게 재선송
메시지가 실제로 처리됐음에도 네트워크 상에서 확인 응답을 유실할 수 있음.
- 이런 경우를 처리하기 위해 원자적 커밋 프로토콜이 필요함.
- 현실의 분산 트랜잭션에서 ...

로드밸런싱과 결합하면 생기는 문제

로드벨런싱과 결합하면 위의 이미지와 같이 메시지 순서에 영향을 미친다.
이건 필연적으로 발생하는 문제 (로드벨런싱을 사용하지 않으면 문제를 피할 수 있음.)

1-2. 파티셔닝된 로그

개요

AMQP/JMS 형식의 메시징 처리는
- 브로커가 확인 응답을 받으면 브로커에서 메시지를 삭제하기 때문에 이미 받은 메시지는 복구할 수 없음.
- 그래서 소비자를 다시 실행해도 동일한 결과를 받지 못함.
그리고 기본적으로 메시징 시스템에서 새로운 소비자를 추가하면, 추가한 시점 이후의 메시지부터 받음.
데이터베이스의 지속성 있는 저장 방법과 메시징 시스템의 지연시간이 짧은 알림 기능을 조합할 수는 없을까?
➔ 로그 기반 메시지 브로커(log-based message broker)

로그를 사용한 메시지 저장소

생산자가 보낸 메시지는 로그 끝에 추가하고, 소비자는 로그를 순차적으로 읽어 메시지를 받음.
- 소비자가 로그 끝에 도달하면 새 메시지가 추가됐다는 알림을 기다림.
디스크 하나를 쓸 때보다 처리량을 높이기 위햇 확장하는 방법으로 로그를 파티셔닝
- 이렇게 하면 각 파티션은 다른 파티션과 독립적으로 읽고 쓰기가 가능한 로그가 됨.
- 토픽은 같은 형식의 메시지를 전달하는 파티션들의 그룹으로 정의한다.
각 메시지에는 오프셋(단조 증가하는 순번)이 붙음
- 파티션 안에서는 순서가 보장되지만, 파티션 간에는 순서 보장 없음.
대표 예시
- 아파치 카프카, 아마존 키네시스 스트림, 트위터의 분산 로그

로그 방식과 전통적인 메시징 방식의 비교

로그 기반 접근법은 소비자가 메시지를 읽어도 로그에서 삭제되지 않음.
개별 메시지를 소비자에게 할당하지 않고, 소비자 그룹의 노드들에게 전체 파티션을 할당
한 파티션은 순서가 보장되어야 하므로 한 스레드(single-thread)로 순차적으로 처리
이런 거친 방식의 로드벨런싱(Coarse-grained Load Balancing) 방법은 몇 가지 불리한 면이 있다.
1. 파티션 수 한계 : 소비자 수는 파티션 수보다 많을 수 없음.
2. Head-of-line-blocking : 앞에서 지연되면 뒤 파티션들도 모두 지연
언제 뭘 쓰면 되냐
1. JMS/AMQP 방식의 메시지 브로커
  - 메시지 순서는 중요하지 않은데, 처리 비용이 비싸고 병렬화 처리하고 싶은 경우
2. 로그 기반 접근법
  - 메시지 순서가 중요 + 메시지 처리 속도 빠름 + 처리량 많음

소비자 오프셋

소비자 오프셋을 사용하면 메시지 처리 현황을 알기 쉽다.
따라서 브로커는 모든 개별 메시지마다 보내는 확인 응답을 추적할 필요가 없다.
이 방법을 사용하면
1. 추적 오버헤드가 감소
2. 일괄 처리와 파이프라이닝을 수행할 수 있는 기회를 제공 ➔ 로그 기반 시스템의 처리량 향상
데이터베이스 복제에 사용되는 로그 순차 번호(log sequence number)와 상당히 유사함.
- 메시지 브로커는 데이터베이스의 리더처럼 동작하고 소비자는 팔로워처럼 동작함.
- 소비자 노드에 장애가 발생하면, 소비자 그룹 내 다른 노드에 장애가 난 소비자의 파티션을 할당
- 그리고 마지막 기록된 오프셋부터 메시지를 처리하기 시작.

디스크 공간 사용

로그를 추가하다보면 결국 디스크 용량을 다 쓰게 됨.
디스코 용량을 재사용하기 위해서 오래된 조각을 삭제하거나 보관 저장소로 이동
근데 소비자의 속도가 생산자 보다 느리면 메시지가 유실될 수 있음.
Kafka는 로그를 무한히 저장하지 않고, 시간이 지나면 오래된 로그(segment)는 자동으로 삭제
- 결과적으로 로그는 크기가 제한된 버퍼로 구현
- 이런 버퍼는 원형 버퍼 또는 링 버퍼라고 함.

소비자가 생산자를 따라갈 수 없을 때

앞에서 소비자가 느릴 때 대처할 수 있는 세 가지 방법을 이야기 했었음 (버리기 / 버퍼링 / 배압)
로그 기반 접근법은 고정 크기의 버퍼를 사용하는 버퍼링 형태.
소비자가 뒤쳐지면 필요한 메시지를 읽지 못 할 수 있음.
버퍼는 충분히 크다면,
- 운영자가 느린 소비자를 수정해서 메시지 손실이 발생하기 전까지 따라잡도록 할 수 있음.
- kafka는 버퍼는 메모리 기반 큐보다 훨씬 큼 (수GB ~ 수 TB)

오래된 메시지 생성

로그 기반 접근 법도 오래된 메시지를 읽을 수 있음.
- 메시지를 파일에 append하고, 소비자가 읽을 때 그 메시지를 삭제하지 않음.
- 오직 변하는건 소비자의 오프셋
여기서 오프셋은 소비자의 관리 아래 있기 때문에, 원하는대로 변경할 수 있음.
- 이런 특성 때문에 로그 기반 메시징은 이전 장의 배치 처리와 비슷
- 즉, 입력 데이터(로그)를 그대로 두고,
  소비자는 그걸 읽어 결과를 별도로 만들어내는 구조.(파생된 결과 데이터)
이런 구조 덕분에,
- 실험(코드 변경)을 자유롭게 할 수 있음.
- 에러나 버그 발생시 복구도 쉬움
- 조직 내 여러 데이터 흐름(dataflow)을 통합하는 데 매우 유용

근데 시간 지나면 삭제한다고 했는데?

Kafka는 보존(retention) 정책에 따라 오래된 로그(segment)를 자동으로 삭제
Kafka 자체는 “단기 버퍼”로 쓰고, 장기 보존은 데이터 레이크(HDFS/S3)에 저장하는 게 일반적

❐ 2. 데이터베이스와 스트림

2-1. 시스템 동기화 유지하기

데이터베이스와 스트림

데이터베이스는 “현재 상태”를 저장
스트림은 “시간의 흐름에 따라 일어난 사건(event)”을 저장

이중쓰기 문제

둘 중 하나만 성공하거나 실패할 수 있음
이런 경우 두 시스템의 데이터 불일치(inconsistency) 가 발생
이런 문제를 완벽히 해결하려면 원자적 커밋(atomic commit) 이나 2PC 같은 고비용 트랜잭션이 필요
단일 리더 복제 구조에서는 리더가 쓰기 순서를 정해 덜 복잡하지만,
리더가 여러 개이거나 없는 구조에서는 충돌이 자주 발생

2-2. 변경 데이터 캡처

변경 데이터 캡처(change data capture, CDC)

CDC는 데이터베이스에 기록하는 모든 데이터의 변화를 관찰해
다른 시스템으로 복제할 수 있는 형태로 추출하는 과정
데이터가 기록되자마자 변경 내용을 스트림으로 제공할 수 있으면 특히 유용함.

위의 예시에서 검색 색인 뿐만 아니라 데이터 웨어하우스도 "변경 스트림의 소비자"임.

변경 데이터 캡처의 구현

“검색 인덱스나 "데이터 웨어하우스" 같은 시스템은
원본 데이터베이스의 로그를 소비하여 만들어지는 파생(derived) 데이터 시스템
CDC는 레코드 시스템의 정확한 데이터 복제본을 가지게 하기 위해 레코드 시스템에 발생하는
모든 변경 사항을 파생 데이터 시스템에 반영하는 것을 보장하는 메커니즘
CDC는 본질적으로 변경 사항을 캡처할 DB 하나를 리더로 하고 나머지를 팔로워로 한다.
CDC를 구현하는데 DB trigger를 사용하기도 함.
- 하지만 이 방식은 전반적으로 취약하고, 성능 오버헤드가 상당함.
메시지 브로커와 동일하게 비동기 방식으로 동작
- 그렇기 때문에 어떠한 설계로 인해 느린 소비자가 추가되어도 레코드 시스템에 미치는 영향은 없음.
- 하지만 복제 진연의 문제가 발생하는 단점이 있음.

초기 스냅숏

모든 변경 사항을 영구적으로 보관하는 일은 디스크 공간이 많이 필요하고,
로그를 재생하는 작업도 너무 오래 걸림. 그래서 로그를 적당히 잘라야 함.
일부 CDC 도구는 스냅숏 기능을 내장하고 있으나, 수작업으로 해야하는 CDC 도구도 있음.

로그 컴팩션

앞에서 다룬 내용
로그 컴팩션 과정을 통해 중복을 제거하고, 각 키에 대해 가장 최근에 갱신된 내용만 유지
컴팩션과 병합 과정은 백그라운드로 진행
이 과정 덕분에
- 로그에 데이터베이스에 있는 모든 키의 최신 값이 존재하는 것이 보장됨.
- 따라서 검색 색인과 같은 파생 데이터 시스템을 재구축할 때마다 새 소비자는
  컴팩션된 로그 토픽의 오프셋 0부터 시작해서 모든 키를 스캔하면 됨.
아파치 카프카는 로그 컴팩션 기능을 제공함.
메시지 브로커는 일시적 메시징뿐만 아니라 지속성 있는 저장소로도 사용 가능함
- (후반부에 자세히 다룰 예정)

변경 스트림용 API 지원

최근 데이터베이슨는 리버스 엔지니어링을 통해 점진적으로 변경 스트림을 기본 인터페이스로 지원하기 시작
예) 리싱크DB는 질의 결과에 변경이 있을 때 알림을 받을 수 있게 구독이 가능한 질의를 지원하는 등...

2-3. 이벤트 소싱

이벤트 소싱

DDD 커뮤니티에서 개발한 기법
CDC와 유사하게 애플리케이션 상태 변화를 모두 변경 이벤트 로그로 저장한다.
차이점은 이 아이디어를 적용하는 추상화 레벨이 다르다는 점

CDC vs 이벤트 소싱

CDC : DB 내부의 변경 로그를 읽어서 데이터 변화를 외부로 전달하는 방식
1. 데이터베이스를 자유롭게 수정 가능한(mutable) 방식으로 사용
  ➔ INSERT / UPDATE / DELETE 를 마음대로 수행할 수 있다.
2. 데이터베이스의 변경 로그(replication log)를 읽어서 변경 내용을 추출
  ➔ DB에 실제로 기록된 순서를 그대로 반영할 수 있어서 경쟁 조건이 생기지 않는다.
3. 애플리케이션은 CDC가 동작 중이라는 사실을 몰라도 된다.
  ➔ 즉, DB는 평소처럼 사용하고, CDC는 백그라운드에서 로그를 감시
이벤트 소싱 : 애플리케이션에서 발생한 사건을 불변 이벤트로 기록하는 설계 방식
- 애플리케이션 로직 자체가 이벤트 기반으로 설계
  ➔ 이벤트들을 불변(immutable) 형태로 이벤트 로그에 기록한다.
- 이벤트 저장소는 “append-only” 구조이며, 수정/삭제 금지.
- 이벤트는 낮은 수준의 데이터 변경이 아니라, 비즈니스 수준에서 실제 일어난 일을 표현

이벤트 소싱의 특징

모든 상태 변화는 이벤트 로그로 남는다.
- "회원가입됨”, “주문됨”, “결제됨”, “배송완료됨” 같은 이벤트들이 시간순으로 기록됨.
데이터는 절대 수정하거나 삭제하지 않는다.
- 변경이 생기면 “이전 상태를 취소하는 새 이벤트”를 추가함.
- 즉, 로그를 Append 방식으로만 저장
현재 상태는 이벤트를 전부 재생(Replay)하여 도출함.
- 시스템 장애나 버그가 생겨도 이벤트를 다시 읽어 현재 상태를 재구성하기 용이함.
디버깅 및 변경 추적이 용이하다.

이벤트 로그에서 현재 상태 파생하기

이벤트 소싱을 사용하는 애플리케이션은
- 시스템에 기록한 데이터를 표현한 이벤트 로그를 가져와
  사용자에게 보여주기에 적당한 애플리케이션 상태로 변환해야 함.
- 이 변환 과정은 결정적(deterministic) 과정이어야 함. (다시 수행해도 똑같은 상태여야 하기 때문)
- 일반적으로 이벤트 로그에서 파생된 현재 상태의 스냅숏을 저장하는 메커니즘이 있음.
  - 따라서, 매번 전체 로그를 반복해서 재처리할 필요는 없음.

CDC와 이벤트 소싱의 로그 관리 방식 차이

CDC
- 데이터베이스의 상태 변경을 그대로 반영
- 즉, “기본키 기준으로 가장 최신 상태” 만 유지하면 된다.
- 이전 상태(이전 이벤트)는 로그 컴팩션을 통해 지워진다.
- 불필요한 옛 버전은 버려도 현재 상태 복원이 가능함.
이벤트 소싱
- 이벤트 소싱은 사용자의 의도나 행동 자체를 이벤트로 기록
- 각 이벤트는 과거 기록을 덮어쓰지 않으며, 시스템 상태를 복원하려면 모든 이벤트의 전체 히스토리가 필요
- 따라서 로그 컴팩션은 불가능하다. (이전 이벤트도 시스템의 의미 있는 일부이기 때문)

명령과 이벤트

이벤트 소싱의 철학은 이벤트와 명령(command)를 구분하는데 있다.
사용자 요청이 처음 왔을 때 ➔ 명령
- 이 시점에 명령이 실패할 수 있음.
- 명령에 대한 무결성이 검증되고 승인되면, 명령은 지속성 있는 불변 이벤트가 됨.
이벤트는 생성 시점에 사실(fact)가 된다.
이벤트 스트림의 소비자는 이벤트를 거절하지 못한다.
- 소비자가 이벤트를 받는 시점에는 이벤트는 이미 불변 로그의 일부
- 따라서 유효성 검증은 이벤트로 바뀌기 이전 단계(명령 단계)에서 동기적으로 수행해야 함.
비동기 처리로 유효성을 검사하기
- 좌석 예약처럼 여러 사용자가 동시에 같은 자원을 요청하는 경우를 예로 들었음.
- 먼저 “가예약”을 이벤트 발행
- 이후에 유효성 검증 후 문제가 없을 때 “확정 이벤트”를 발행

2-4. 상태와 스트림 그리고 불변성

불변성 원리 덕분에...

입력 파일에 손상을 주지 않고, 기존 입력 파일에 얼마든지 실험적 처리 작업을 수행할 수 있음.
이 원리가 이벤트 소싱과 CDC를 매우 강력하게 만들어줌.
그런데 데이터베이스는 수정/삭제를 지원하는데 어떻게 불변성과 어울림?

변경된 상태는 시간의 흐름에 따라 변한 이벤트의 마지막 결과

상태가 어떻게 바뀌었든 항상 이런 변화를 일으킨 일련의 이벤트가 있음.
변경 로그를 지속성 있게 저장한다면 상태를 간단히 재생성할 수 있는 효과가 있음.

불변 이벤트의 장점

회계 원장(ledger)처럼 신뢰 가능한 기록 유지
- 즉, “언제, 어떤 변화가 있었는가” 를 신뢰성 있게 남길 수 있음.
오류 복구 및 감사(audit)에 강함
- 잘못된 데이터가 생겨도 기존 기록을 수정하지 않고 “오류를 보정하는 새로운 이벤트”를 추가
- 코드 실수나 데이터 오염이 발생했을 때, 불변 로그를 통해 과거 상태를 재현하기가 훨씬 쉬워짐
데이터 손실 및 복구 위험 감소
- 잘못된 데이터가 저장되어도 이전 이벤트가 보존되어 있어 복구 가능
분석 및 추적에 유용한 풍부한 히스토리
- 불변 이벤트는 단순히 “현재 상태”뿐 아니라 사용자의 행동 패턴, 취소된 행동의 흔적까지 포함

동일한 이벤트 로그로 여러 가지 뷰 만들기

불변 이벤트 로그에서 가변 상태를 분리하면 동일한 이벤트 로그로 다른 여러 읽기 전용 뷰를 만들 수 있다.
- Druid는 카프카로부터 직접 데이터를 읽어 처리
- Pistachio는 분산 키-값 저장소로 카프카를 커밋 로그처럼 사용
- 카프카 커넥트 싱크는 카프카에서 여러 데이터베이스와 색인에 데이터를 내보낼 수 있음.
이벤트 로그를 기반으로 하면 시스템을 바꾸거나 확장하기 훨씬 쉽다.
- 새로운 기능이 필요하면?
  - 기존 DB는 변경하지 않고, 이벤트 로그를 읽어서 적절한 "읽기 전용 뷰" 만들면 됨
- 이벤트 로그는 원본 데이터의 근거(ground truth) 이기 때문에,
  - 새로운 시스템은 기존 시스템의 로그를 그대로 읽어 독립적으로 실행할 수 있음.
- 결국 신/구 버전이 같이 공존할 수 있고, 점진적으로 구 버전을 없앨 수 있음.
대표적인 응용의 예로 CQRS가 있음
- DB 스키마, 색인(index), 저장 방식이 “쓰기 성능”과 “읽기 편의성”을 동시에 만족시키기 어려움
- 따라서, 데이터를 읽기와 쓰기로 분리하면 시스템을 더 유연하고 효율적으로 설계할 수 있음.

동시성 제어

이벤트 소싱과 CDC의 가장 큰 단점은 이벤트 로그의 소비가 대게 비동기로 이뤄진다는 것.
해결책
1. 읽기 뷰의 갱신과 로그에 이벤트를 추가하는 작업을 동기식으로 수행하는 방법
2. 이벤트 로그로 현재 상태를 만드는 방법
3. 이벤트 로그와 애플리케이션 상태를 같은 파티션 단위로 설계하는 방법

불변성의 한계

많은 시스템은 불변 구조를 사용한다.
- Git, Mercurial, Fossil 같은 버전 관리 시스템
- 이들은 과거의 모든 변경 이력(history) 을 보존하기 위해 불변 데이터를 사용한다.
불변성은 데이터의 일관성, 감사 가능성, 복구 용이성 측면에서 매우 유용하다.
하지만 “모든 데이터를 영구적으로 불변”으로 두는 것은 현실적으로 어려움
- 저장소 용량과 성능 문제
  - 데이터가 계속 쌓이기만 하고 삭제되지 않으면,
    저장소가 점점 커져서 관리 비용과 성능 문제가 발생할 수 있다.
  - 특히 자주 갱신되는 데이터셋의 경우,
    불변 이력을 모두 유지하면 공간 낭비와 검색 성능 저하로 이어질 수 있다.
  - 압축이나 가비지 컬렉션을 해야 하지만, 이 또한 복잡하고 비용이 큼
- 법적 / 관리적 이유로 삭제가 필요한 경우
  - 이런 경우에는 “삭제 이벤트를 추가하는 것”으로 해결되지 않는다.
    왜냐하면 기존 데이터가 여전히 로그 안에 존재하기 때문.
  - 첨부터 기록하지 않았던 것 처럼 해야함.

❐ 3. 스트림 처리

스트림을 처리하는 3가지 선택지

이벤트에서 데이터를 꺼내서 저장소 시스템에 기록하고, 데이터를 질의
이벤트를 사용자에게 직접 전달
하나 이상의 입력 스트림을 처리해 하나 이상의 출력 스트림을 생산 (이번장에서 살펴볼 부분)

3-1. 스트림 처리의 사용 (Uses of Stream Processing)

모니터링

주로 특정 상황이 발생하면 조직에 경고를 해주는 모니터링 목적으로 오랜 기간 사용돼 왔음.
그러나 시간이 지나면서 다른 용도로 스트림 처리를 사용하는 사용자들이 나타나기 시작함.

복잡한 이벤트 처리 (complex event processing, CEP)

1990년대에 이벤트 스트림 분석용으로 개발된 방법
특정 이벤트 패턴을 검색해야 하는 애플리케이션에 특히 적합
실시간으로 발생하는 여러 이벤트 스트림을 분석하여,
특정한 패턴이나 조건이 충족될 때 새로운 "복합 이벤트"를 생성하는 시스템
감지한 이벤트 패턴을 묘사하기 위해 종종 SQL과 같은 고수준 선언형 질의 언어를 사용하기도 함.
이 시스템에서는 질의는 오랜 기간 저장되고, 입력 스트림으로 부터 들어오느 이벤트는 지속적으로
질의를 지나 흘러가면서 이벤트 패턴에 매칭되는 질의를 찾는다.
에스퍼, 아파마, SQL스크립트 등이 있음.

스트림 분석

연속한 특정 이벤트 패턴을 찾기보단, 대량의 이벤트를 집계하고 통계적 지표를 뽑는 것을 우선함.
- ex. 특정 유형의 이벤트 빈도 측정, 특정 기간에 걸치 값의 이동 평균 계산...
일반적으로 이런 통계는 고정된 시간 간격 기준으로 계산한다.
- 집계 시간 간격 = 윈도우(window)
최적화를 위해 "확률적 알고리즘"을 사용하기도 함.
아파치 스톰, 스파크 스트리밍, 카프카 스트림 등이 있음.

구체화 뷰 유지하기

이벤트 소싱에서 애플리케이션 상태는 이벤트 로그를 적용함으로써 유지함.
- 이때 애플리케이션의 상태로 "구체화 뷰"라고 할 수 있음.
구체화 뷰를 만들기 위해서는 잠재적으로 임의의 시간 범위에 발생한 모든 이벤트가 필요함.
- 따라서 모든 이벤트가 필요함. ➔ 시작 시점까지 늘려진 윈도우가 필요함.
스트림 처리 시스템이라면 이론적으로는 모두 구체화 뷰를 유지하는 데 쓸 수 있다.
- 하지만, materialized view 유지에는 이전 모든 이벤트의 상태를 계속 기억하고 갱신하는 능력이 필요하다.
- 반면 많은 분석 중심 스트림 처리 시스템은 “윈도우 기반(한정된 기간)” 데이터만 처리하도록
  설계되어 있기 때문에, 이런 영구 상태 유지 요구사항과는 설계 철학이 충돌한다.

스트림 상에서 검색하기

복잡한 기준을 기반으로 개별 이벤트를 검색해야 하는 경우도 있음.
전통적인 검색 엔진은 먼저 문서를 indexing하고 index를 통해 질의를 실행
반대로 스트림 검색은 처리 순서가 반대임.
질의를 먼저 저장함. 그리고 질의를 지나가면서 실행됨.
즉, “아직 저장되지 않은, 실시간으로 흘러들어오는 데이터”를 계속 감시하면서 조건이 충족되면 즉시 결과를 생성

메시지 전달과 RPC

앞에서 메시지 전달 시스템을 RPC 대안은로 사용할 수 있다고 했음. (139쪽)'
메시지 전달 시스템이 RPC처럼 사용될 수 있지만, 스트림 처리와는 다른 특성을 가짐.
액터 프레임워크는 메시지 기반 동시성 모델이지만, 데이터 영속성 측면에서는 제한적.
스트림 처리는 데이터 흐름 전체를 지속적으로 관리하는 반면,
RPC는 요청-응답(request-response) 중심으로, 일시적인 통신에 가깝다.
물론 액터 프레임워크를 이용한 스트림 처리도 가능하긴 함.
- 그러나 액터 프레임워크는 장애 상황에서 메시지 전달을 보장하지 않기 때문에
  추가적인 재시도 로직을 구현하지 않으면, 처리에 내결함성을 보장하지 못함.

3-2. 시간에 관한 추론 (Reasoning About Time)

➔ (특히 분석 목적으로 사용할 때) 스트림 처리자는 종종 시간을 다뤄야할 때가 있다.

이벤트 시간 대 처리 시간

처리가 지연되는 데는 많은 이유가 있음.(큐 크기, 네트워크 결함 등등)
메시지가 지연되면 메시지 순서를 예측하지 못할 수도 있다.
이벤트 시간과 처리 시간을 혼동하면 좋지 않은 데이터가 만들어짐.

준비 여부 인식

이벤트를 시간 단위로 윈도우(Window)로 묶어 처리할 때 생기는 문제
- 현재 윈도우에 속한 모든 이벤트가 도착했는지 확신할 수 없다는 점
윈도우를 이미 종료한 후에 도착한 낙오자(straggler) 이벤트를 처리할 방법이 필요함
1. 낙오자 이벤트를 무시하기
  - 정상적인 상황에서는 늦게 도착하는 이벤트의 비율이 매우 적기 때문.
  - 하지만 만약 낙오가 많아지면 경고를 보내거나 추적할 수 있다.
2. 수정 값을 발행하기
  - 늦게 도착한 이벤트를 포함해 다시 윈도우를 계산(갱신)
  - 그에 따라 이전 출력 결과를 취소하거나 보정
일부 이벤트는 네트워크 지연이나 장비 문제로 늦게 도착할 수 있음.
- 따라서 시스템은 “언제 윈도우가 완전히 끝났다고 선언할지”를 판단하기 위해
  타임아웃이나 특수 메시지(‘더 이상 이전 타임스탬프는 없다’는 신호) 를 사용할 수도 있음.
- 하지만 이 방식은 생산자가 이런 신호를 추가해야 하므로 복잡도가 높음.

어쨋든 어떤 시계를 사용할 것인가.

이벤트의 타임스탬프는 모바일 장치 로컬 시계를 따르는, 실제 사용자와 상호작용이
발생했던 실제 시각이어야 함.
하지만 우연히 잘못된 시간이 설정됐을 가능성이 있기 때문에 사용자가 제어하는 장비의
시계를 항상 신뢰하기는 어려움.
잘못된 장치 시계를 조정하는 한 가지 방법은 세 가지 타임스탬프를 로그로 남기는 것
1. 이벤트가 발생한 시간 (장치 시계를 따른다)
2. 이벤트를 서버로 보낸 시간 (장치 시계를 따른다)
3. 서버에서 이벤트를 받은 시간 (서버 시계를 따른다)
2번과 3번의 타임스탬프 차이를 구하면 장치 시계와 서버 시계 간의 오프셋을 추정할 수 있음.
- 이때 필요한 타임스탬프 정확도에 비해 네크워크 지연은 무시할 만하고,
  이벤트가 발생한 시간과 이벤트를 서버로 보낸 시간 사이에는 장치 시계 오프셋이
  변하지 않았다고 가정
- 그러면 계산한 오프셋을 이벤트 타임스탬프에 적용해 이벤트가 실제로 발생한 시간을 추정할 수 있음.

윈도우 유형
➔ 윈도우 기간을 어떻게 정의할지 결정해야 함

텀블링 윈도우
- 고정된 크기의 윈도우
- 모든 이벤트는 정확히 한 윈도우에 속함.
- ex. {10시03분00초, 10시03분59}
홉핑 윈도우
- 고정된 크기의 윈도우
- 결과를 매끄럽게 만들기 위해 윈도우를 중첩할 수 있음.
- 1분 크기의 홉을 이용하는 5분 윈도우 예시
  - A1윈도우 : "10시03분00초~10시07분59초"
  - A2윈도우 : "10시04분00초~10시08분59초"
슬라이딩 윈도우
- 각 시간 간격 사이에서 발생한 모든 이벤트를 포함
- 시간 기준으로 정렬한 이벤트를 버퍼에 유지하고 이벤트가 만료되면
  윈도우에서 제거하는 방식으로 구현할 수 있음.
세션 윈도우
- 고정된 기간이 없음
- 대신 같은 사용자가 짧은 시간 동안 발생시킨 모든 이벤트를 그룹화해서 세션 윈도우를 정의함.
- 그리고 일정 시간이 지나 사용자가 비활성되면 윈도우 종료
- 웹사이트 분석을 할 때 흔히 필요

3-3. 스트림 조인

3가지 조인 유형

스트림 상에는 새로운 이벤트가 언제든 나타날 수 있기 때문에,
- 스트림 상에서 수행하는 조인은 일괄 처리 작업에서 수행하는 조인보다 훨씬 어려움.
3가지 유형
1. 스트림-스트림 조인
2. 스트림 테이블 조인
3. 테이블-테이블 조인

스트림-스트림 조인 (윈도우 조인)

웹사이트의 검색 기능에서 사용자가 입력한 검색 이벤트와 그 결과를 클릭한 클릭 이벤트를
연결(조인)하여 사용자의 검색 ➔ 클릭 행동을 분석하는 방식.
적절한 윈도우 선택이 필요한 이유
- 클릭이 항상 발생하지 않음.
- 검색 이벤트와 클릭 이벤트는 시간 차이가 일정하지 않음.
- 네트워크 지연으로 이벤트 순서가 바뀔 수도 있음.
이런 유형의 조인을 구현하려면 스트림 처리가 상태(state)를 유지해야 함.
- 예를 들면, 모든 이벤트를 세션 ID로 색인

스트림 테이블 조인 (스트림 강화)

사용자 활동 이벤트 스트림과 사용자 프로필 데이터베이스(테이블)를 결합하는 방식
스트림의 각 이벤트에 테이블 정보를 추가해 이벤트를 “강화(enriching)” 하는 형태
수행 방법
1. 스트림 처리기는 들어오는 활동 이벤트(스트림)를 받는다.
2. 각 이벤트의 사용자 ID를 기준으로 데이터베이스를 조회한다.
3. 데이터베이스에서 프로필 정보를 가져와 이벤트에 추가한다.
4. 이렇게 강화된 이벤트를 출력한다.
또 다른 방법은 네트워크 왕복 없이 질의하도록 스트림 처리자 내부에 DB 사본을 적재하는 것
스트림은 시간이 흘러가면서 DB 내용이 변할 가능성이 높음.
- 따라서 DB 로컬 복사본을 최신 상태로 유지해야 함.
- 이 문제는 CDC를 사용하면 해결 가능함.
스트림-스트림 조인과 매우 비슷함.
가장 큰 차이점은 테이블 조인을 할 때, 테이블 변경 로그 스트림 쪽은
"시작 시간"까지 이어지는 윈도우를 사용하며 레코드의 새 버전으로 오래된 것을 덮어씌운다.

테이블 테이블 조인 (구체화 뷰 유지)

조인 결과를 지속적으로 유지하고 갱신해야 하는 스트림 기반 “구체화 뷰 유지”와 같다.
단순 조회가 아니라 변화가 발생할 때마다 조인 결과(타임라인 캐시)를 실시간으로 갱신하는 과정

조인의 시간 의존성

위에서 본 세 가지 조인 유형의 공통점 ➔ 특정 상태를 유지함
시간에 따라 변하는 상태를 조인해야 한다면 어느 시점을 조인에 사용해야 할까?
- 예시) 세율
복수 개의 스트림에 걸친 이벤트 순서가 결정되지 않으면 조인도 비결정적
- 이 문제를 데이터 웨어하우승는 천천히 변하는 차원(slowly changing dimension, SCS)라 함.
- 이 문제는 흔히 조인되는 레코드의 특정 버전을 가리키는데 유일한 식별자를 사용해 해결함.

3-4. 내결함성

내결함성

스트림 처리의 핵심 과제: 장애가 발생해도 결과가 중복되거나 누락되지 않게 하는 것.
일괄 처리(예: MapReduce)는 태스크 단위로 명확한 재처리 경계가 존재하기 때문에
실패 후 재시작해도 동일한 결과를 얻을 수 있다.
이러한 특성을 정확히 한 번 시맨틱스(Exactly-once semantics) 라고 하며,
실제 의미는 “결과적으로 한 번만 반영(effectively-once)”이다.
- 즉, 태스크가 여러 번 실행되더라도 출력 결과는 정확히 한 번만 나타나야 한다.

스트림 처리에서도 동일한 문제가 있지만,
- 실시간성 요구로 인해 태스크가 끝날 때까지 기다릴 수 없기 때문에
  다른 방식의 내결함성 설계가 필요함.

마이크로 일괄 처리와 체크포인트

스트림을 짧은 구간(예: 1초 단위)으로 잘라 일괄 처리하듯 다루는 방법.
- 마이크로 일괄 처리(microbatching)
특징
- 일반 배치보다 빠르지만, 완전 실시간은 아님 (지연 시간 약 1초).
- 배치 단위로 상태를 저장하고, 장애 시 체크포인트에서 재시작.
- 대표적으로 Spark Streaming이 사용.
단점
- 실시간성이 떨어지고, 체크포인트 접근만으로는 외부 시스템(DB, 브로커 등)에 중복된 출력이 발생할 수 있음.
- 즉, 마이크로 배치 단위 내에서는 “정확히 한 번” 보장이 어렵다.

원자적 커밋 재검토

장애 시에도 “모든 출력을 한 번만 발생”시키려면
- 스트림 처리기와 외부 시스템 간의 원자적 커밋(atomic commit) 이 필요
하지만 스트림 프레임워크는 여러 노드와 메시지 시스템 간 동기화가 어려워
- 2PC는 현실적으로 비효율적
- 대신, 내부 트랜잭션처럼 동작하는 상태 관리 기반 커밋 방식이 사용

멱등성

정확히 한 번 시맨틱스를 달성하기 위한 실용적 접근법.
같은 연산이 여러 번 수행되더라도 결과가 동일해야 한다.
외부 시스템(예: Kafka, DB)에 쓰기 시 메시지 오프셋이나 마지막 처리 상태를
함께 기록하여 중복 실행 시 동일 결과를 유지하도록 만든다.
Trident (Storm 기반 프레임워크) 등은 이러한 멱등성을 전제로 작업 순서를 보장하며
“정확히 한 번 처리”를 실질적으로 구현한다.

실패 후 상태 재구축

스트림 처리에서는 조인, 윈도우, 집계 등 상태를 가진 연산이 많기 때문에 장애 시 상태 복구가 매우 중요
복구 방식
1. 원본 데이터 재질의
  - 모든 입력 이벤트를 재처리하여 동일한 결과 재생성
  - 느리지만 단순하고 확실함
2. 상태 스냅샷 복원 (Checkpoint Restore)
  - 주기적으로 상태를 저장소(HDFS, Kafka 등)에 백업
  - 장애 발생 시 해당 시점의 스냅샷을 불러와 빠르게 복구
일부 DB(예: VoltDB)는 노드 간 상태 복제를 통해 장애 시 즉시 복구한다.
상태 복제가 불필요한 경우도 있음
- 예: 작은 윈도우라면 입력 스트림을 재처리해도 충분히 빠르게 복구 가능.

트레이드 오프

복구 방식 선택은 인프라 성능 특성에 달려 있다.
- 디스크 접근이 느리고 네트워크가 빠른 시스템
- 혹은 그 반대의 시스템 등
따라서 “로컬 상태 vs 원격 상태” 중 어떤 쪽을 더 자주 백업할지,
혹은 실시간 복제를 유지할지 등의 트레이드오프 설계가 필요함.

10장. 일괄 처리(Batch Processing)

gilbert9172 — Sun, 26 Oct 2025 17:18:06 +0900

❐ 0. 개요

시스템 구축 방법의 세 가지 유형
➔ 온라인 시스템이 유일한 시스템 구축 방법은 아니다.

서비스 (온라인 시스템)
- 응답 시간은 서비스 성능 측정의 중요한 지표
일괄 처리 시스템 (오프라인 시스템)
- 매우 큰 입력 데이터를 받아 데이터를 처리하는 작업을 수행
- 그리고 결과 데이터를 생산
스트림 처리 시스템 (준 실시간 시스템)
- 온라인 서비스와 일관 처리 시스템 사이의 어딘가..
- 입력 이벤트가 발생한 직후 바로 작동

❐ 1. 유닉스 도구로 일괄 처리하기

1-1. 단순 로그분석

# 웹 사이트에서 가장 인기 높은 체이지 5개
cat /var/log/nginx/access.log |
  awk '{print$7}' |
  sort            |
  uniq -c         |
  sort -r -n      |
  head -n 5

unix 기반 방식은 상당히 강력함(incredibly powerful).
수 기가 바이트의 로그 파일을 수 초 내로 처리할 수 있고, 필요에 따라 분석방법을 수정하기도 쉬움.

연쇄 명령 vs 맞춤형 프로그램(custom program)

counts = Hash.new(0)

File.open('...') do |file|
    file.each do |line|
        url = line.split[6]
        counts[url] += 1
    end
end

top5 = counts.map(|url, count| [count, url] }.sort.reverse[0...5]
top5.each(|count, url| puts "#{count} #{url}" }

unix 연쇄 명령 대신 위와 같이 작성할 수도 있음.
하지만 두 가지 방법은 실행 흐름이 크게 다름. (특히 대용량 파일을 분석해 보면 차이가 확 드러남)

정렬 vs 인메모리 집계

인메모리
- 작업 세트가 충분히 작다면 임메모리 해시 테이블도 잘 동작함
- 여기서 작업 세트는 단순히 고유 URL 수로 결정 (ex. [url: ~~, count: 10])
정렬
- "허용 메모리 < 작업 세트"의 경우 좋음
- 접근법은 SS 테이블과 LSM 트리에서 설명한 원리와 다르지 않음.

1-2. Unix 철학

아이디어

"다른 방법으로 데이터 처리가 필요할 때 정원 호스와 같이 여러 다른 프로그램을 연결하는 방법이 필요하다"
이 방식을 배관 공사와 비슷한 점에서 착안함.

철학

SRP
작은 프로그램들을 조합해서 더 큰 일을 하게 만들라
소프트웨어를 빠르게 써볼 수 있게 설계 & 구축
프로그래밍 작업을 줄이려면 도구를 써라

동일(uniform) 인터페이스

특정 프로그램이 다른 어떤 프로그램과도 연결 가능하려면 동일한 인터페이스를 사용해야 함.
unix에서 인터페이스는 파일(파일 디스크립터)
- 파일은 단지 순서대로 정렬된 바이트의 연속
- unix 입장에서 읽고 쓸 수 있으면 다 파일임.(소켓, 드라이버 등등)

[ 파일 디스크립터 ]

➔ 커널이 관리하는 파일/소켓/파이프 등에 대한 식별자 번호

번호(fd)	이름	의미	방향
0	stdin	표준 입력	입력
1	stdout	표준 출력	출력
2	stderr	표준 에러 출력	출력

echo "hello" > out.txt   # stdout(1)을 out.txt로 연결
cat < input.txt          # stdin(0)을 input.txt로 연결

➔ 리다이렉션(>, <)이 바로 파일 디스크립터 번호를 재연결하는 행위

데이터의 발칸화(Balkanization)

인터넷이 고립된 여러 개의 섬처럼 나뉘어 있는 현상이나,
프로그램 언어나 데이터 파일 포맷 등이 분화발전하는 것을 의미하기도 함.

로직과 연결의 분리

그니깐 unix는 stdin, stdout을 통해서 파일을 읽고 쓰는 역할에만 집중
- (Default) stdin은 키보드로부터, stout은 화면으로 출력
- `cat < input.txt > output.txt` 이렇게 하면 파일에서 입력 가져와서, 파일로 출력
Pipe의 역할
- 한 프로세스의 stdout을 다른 프로세스의 stdin과 연결함.
- `grep "ERROR" < input.txt | sort |uniq -c > output.txt`
  1. 파일 내용을 stdin으로 리다이렉트함
  2. stdin으로 받은 데이터에서 필터링 수행
  3. sort, uniq 작업하고 output에 쓰기(리다이렉트) 수행
- 이때 데이터는 디스크에 쓰지 않고, 인메모리 버퍼에 저장
sort
- 오로지 입력 스트림을 받아서 정렬하는 역할만 함.
stdin과 stdout을 사용할 때의 제약
- 여러 개의 입출력의 경우 불가능하지 않지만 까다로움
- 프로그램의 출력을 파이프를 이용해 네트워크와 연결하지는 못함.

투명성과 실험 (유닉스 도구가 성공적인 이유)

유닉스 명령에 들어가는 입력 파일은 일반적으로 불변으로 처리한다.
원하는 형태의 출력이 나오는지 언제든 확인 가능하다.
특정 파이프라인 단계의 출력을 파일에 쓰고, 다음에 입력으로 사용할 수 있음.

❐ 2. 맵리듀스와 분산 파일 시스템

맵리듀스

맵리듀스 작업은 분산 파일 시스템 상의 파일을 입력과 출력으로 사용하고,
대용량 데이터셋을 처리하는 코드를 작성하는 프로그래밍 프레임워크
병렬로 수행하는 코드를 직접 작성하지 않고도 여러 장비에서 병렬로 처리가 가능함.
매우 불친절하고 brute-force 방식이지만, 엄청 효율적인 도구임
입력을 수정하지 않기 때문에 출력을 생성하는 것 외에 다른 부수 효과는 없음.

HDFS(Hadoop Distributed File System)

분산 파일 시스템 중 하나.
비공유 원칙을 기반으로 함(NAS, SAN과 반대)
- 일반적인 데이터센터 네트워크에 연결된 네트워크면 충분함.
TODO

2-1. 맵리듀스 작업 실행하기

데이터 처리 패턴

입력형식 파서를 사용해서 입력 파일 읽은 후, 레코드로 쪼갠다.
[사용자가 작성한 코드] 각 입력 레코드마다 매퍼 함수를 호출해 키와 값을 추출한다.
키를 기준으로 key-value 쌍을 모두 정렬한다.
[사용자가 작성한 코드] 정렬된 key-value 쌍을 대상으로 reduce 함수를 호출한다.

콜백함수(mapper, reducer)
➔ 맵리듀스 작업을 생성하려면 구현해야 함.

매퍼
- 입력 레코드로부터 키와 값을 추출하는 작업
- 모든 입력 레코드마다 한 번씩만 호출됨.
- 상태를 유지하지 않기 때문에 각 레코드를 독립적으로 처리
리듀서
- 맵리듀스 프레임워크는, 같은 키를 가진 레코드를 모으고 해당 값의 집합을 반복해 리듀서 함수를 호출함.
- 리듀서는 출력 레코드를 생성한다.

맵리듀스의 분산 실행

맵리듀스 프레임워크가 장비 간 데이터 이동하는 부분을 처리하기 때문에
mapper와 reducer는 한 번에 하나의 레코드만 처리하는 것에 집중하면 됨.
맵리듀스 작업의 병렬 실행은 파티셔닝을 기반으로 한다.

하둡 맵리듀스 작업에서의 데이터 플로우

그림10-1. 매퍼3개와 리듀서 3개로 구성된 맵리듀스 작업

작업 입력으로 HDFS 상의 디렉터리를 사용하는 것이 일반적임.
"입력 디렉터리 내 각 파일 or 파일 블록"을 독립된 `맵 태스크`에서 처리할 독립 파티션으로 간주
- 맵 태스크 수는 입력 파일의 블록수로 결정된다.
각 입력 파일은 보통 그 크기가 엄청 큼
맵리듀서의 스케줄러는 '복제본을 가지고 있는 노드'에 메모리와 CPU 자원의 여유가 있다면
➔ 데이터를 네트워크로 옮기기보다, 데이터가 이미 저장된 서버에서 바로 연산을 실행하려고 한다.
➔ 데이터 가까이에서 연산하기 원리 적용

1. 매퍼

입력 파일을 읽어서 (key, value) 쌍으로 변환

2. 파티셔닝

매퍼가 생성한 (key, value) 쌍은
- 여러 리듀서 중 어느 리듀서로 갈지를 키의 해시값(hash) 으로 결정
- 예: hash(key) % 리듀서 수
즉, 같은 키를 가진 모든 데이터는 반드시 같은 리듀서로 이동하게 됨.

3. 셔플 & 정렬

같은 키 끼리 모으는 과정
1. 각 매퍼의 출력(key-value 쌍) 을 키 기준으로 정렬 (Sort)
2. 같은 키끼리 묶음(Group)
3. 리듀서로 전송
즉, m1, m2, m3 ...의 결과를 리듀서별로 분배하는 과정

4. 리듀서

같은 키를 가진 값들을 합침

데이터 가까이에서 연산하기 (putting the computation near the data)

이 원리를 적용하면
1. 네트워크를 통해 입력 파일을 복사하는 부담 감소
2. 네트워크 부하 감소
3. 지역성 증가

맵 리듀스 워크플로

단일 맵리듀스 작업으로 해결할 수 있는 문제의 범위는 제한적임.
일반적으로 n개의 맵리듀스 작업을 연결해 workflow로 구성해서 사용함.
하둡 맵리듀스 프레임워크의 경우
- 워크플로를 제공해주지 않기 때문에 작업은 디렉터리 이름을 통해 암묵적으로 연결됨.
연결된 맵리듀스 작업은 유닉스의 명령 파이프라인과 유사하진 않음.
- 얘는 각 명령의 출력을 임시파일에 쓰고, 다음 명령이 그 임시 파일의 입력을 읽는 방식에 가까움.
- 유닉스는 직접 전달되는 방식을 가지고 있음.

스케쥴러

일괄 처리 작업의 출력은 작업이 성공적으로 끝났을 때만 유효함.
따라서 워크플로 상에서 선행 작업의 입력 디렉터리를 생성하는 작업이 끝나야 다음 작업을 할 수 있음.
하둡 맵리듀스 작업 간 수행 의존성을 관리하기 위해 다양한 스케쥴러가 개발됨.
스케쥴러가 있어서 유지보수할 때 유용함

2-2. 리듀스 사이드 조인과 그룹화

➔ 맵리듀스에는 일반적으로 이야기하는 색인 개념이 없다.

사용자 활동 이벤트 분석 예제

그림 10-2. 사용자 활동 이벤트 로그와 사용자 데이터베이스 간 조인

이 분석 작업은
- 사용자 활동과 사용자 프로필 정보를 연관시켜야 한다.
- 활동 이벤트에 사용자 프로필 데이터베이스를 조인해야 한다.
- 하나하나 다 훑는 방식 ➔ 성능이 떨어짐.
위에서 학습했든, 일괄 처리에서 처리량을 높이기 위해서는 같은 장비에서 연산을 해야 한다.
그래서 이 경우
- '사용자 데이터베이스'의 사본을 가져와 '사용자 활동 이벤트 로그'가 저장된
  분산 파일 시스템에 넣는 방법을 고려해 볼 수 있음.

정렬 병합 조인

한 매퍼는 활동 이벤트를 훑어 사용자 ID를 키로, 활동 이벤트를 값으로 추출
- [사용자 ID : 활동 이벤트]
다른 매퍼는 사용자 데이터베이스를 훑어 사용자 ID를 키도 사용자 생일을 값으로 추출
- [사용자 ID : 생일]
그리고 key로 매퍼의 출력을 파티셔닝해 k-v 쌍으로 정렬하면
- 같은 사용자의 활동 이벤트와 사용자 레코드는 리듀서의 입력으로 서로 인접해서 들어감.
- 매퍼가 생성한 키는 값을 보낼 목적지의 주소 역할을 함.
보조 정렬
- 맵리듀스에서 작업 레코드를 재배열하는 것
보조 정렬 이후 실제 조인 수행
- 보조 정렬했기 때문에, 첫 번째 값은 항상 생년월일 레코드
- 리듀서는 지역 변수에 생년월일 저장하고, {url : 연령} 쌍을 출력함
이렇게 하면
- 리듀서는 특정 사용자 ID의 모든 레코드를 한 번에 처리할 수 있음.
- 결과적으로 데이터를 주고받는 네트워크 송수신 과정이 없어도 됨.

같은 곳으로 연관된 데이터 가져오기

병합 정렬 조인 과정 덕분에 단일 스레드로 모든 작업을 처리할 수 있게 됐음.
결과적으로 처리량은 높게 유지하면서, 메모리 부담은 줄일 수 있게 됐음.

아키텍처 이해하기

맵리듀스 프로그래밍 모델은
- 올바른 장비로 데이터를 모으는 연산의 물리적 네트워크 통신 측면과
- 받은 데이터를 처리하는 애플리케이션 로직을 분리한다.
맵리듀스는 모든 네트워크 통신을 직접 관리한다.
- 때문에 부분적으로 실패가 발생하더라도, 스스로 실패한 태스크는 확실하게 재시도한다.

그룹화

맵리듀스의 간단한 그룹화 방법은, 매퍼가 k-v 쌍을 생성할 때 그룹화할 대상을 키로 지정
맵리듀스 위에서 그룹화와 조인의 구현은 상당히 유사함.

쏠림 다루기 (Handling Skew)

키 하나에 너무 많은 데이터가 연관된다면
- 같은 키를 가지는 모든 레코드를 같은 장소로 모으는 패턴은 제대로 동작하지 않음.
모든 매퍼와 리듀서가 완전히 끝나야지만 맵리듀스 작업이 끝나기 때문에
느린 리듀서가 완료할 때까지 후속 작업 들은 기다려야 함.

조인 최적화 방법

Pig: Skewed Join
- 먼저 샘플링으로 어떤 키가 핫 키인지 찾음.
- 실제 조인 시, 핫 키에 해당하는 레코드는 해시 기반이 아닌 무작위로 여러 리듀서에 분산.
- 조인의 다른 입력(상대 테이블)은 핫 키 관련 레코드를 해당 리듀서들에 복제해 전달.
- 효과: 핫 키 작업을 병렬화.
- 비용: 복제 오버헤드
Crunch: Sharded Join
- 핫 키를 명시적으로 지정해야 함(샘플링 없음).
- 아이디어는 Pig와 유사하게 랜덤 분산으로 핫 스팟 완화.
Hive: Skewed Join 최적화
- 테이블 메타데이터에 핫 키를 명시, 해당 키 레코드를 별도 파일에 저장.
- 조인 시 핫 키에 대해 맵 사이드 조인을 사용해 리듀서 병목을 피함.

집계 최적화

2단계 그룹핑
- 1단계: 핫 키 레코드를 랜덤 리듀서로 보내 각 리듀서가 부분 집계(키별 압축 값) 수행.
- 2단계: 모든 부분 집계를 한 번 더 합쳐 키당 최종 값 생성.
- 효과: 한 리듀서에 과부하가 걸리지 않게 부분 집계로 부하 분산.

2-3. 맵 사이드 조인

지금 까지는 리듀스 사이드 조인

장점 : 입력 데이터에 대한 특정 가정이 필요 없음.
단점 : 리듀서 입력을 병합하는 모든 과정에 드는 비용이 상당함.

맵 사이드 조인

입력 데이터에 대해 특정 가정이 가능한 경우, 이 방법을 사용하면 조인을 더 빠르게 수행할 수 있음.
이 접근법은 축소된 맵리듀스 작업으로, 리듀서는 물론 정렬 작업 없이 없음.

브로드캐스트 해시 조인

큰 데이터셋과 작은 데이터셋을 조인할 때 사용하는 가장 단순하고 효율적인 map-side join 방식.
작은 데이터셋을 모든 매퍼에 브로드캐스트(복제)하여,
각 매퍼가 메모리에 로드한 후 해시 테이블(작은 데이터 셋) 기반으로 조인을 수행
인메모리 해시 테이블로 적재하는 대신 로컬 디스크에 읽기 전용 색인으로 저장하기도 함.

파티션 해시 조인

양쪽 입력 데이터(예: 사용자 DB, 활동 로그)가 같은 기준(key)과 같은 해시 함수로
같은 개수의 파티션으로 나뉘어 있을 경우, 각 파티션별로 독립적으로 해시 조인(Hash Join)을 수행할 수 있다.
예
- 사용자 ID가 3으로 끝나는 사용자 데이터를 메모리에 로드(해시 테이블 생성)
- 사용자ID가 3으로 끝나는 활동 로그를 스캔
- 제대로 파티션 됐다면, 조인할 레코드가 모두 같은 번호의 파티션에 위치
이 방법은 각 매퍼의 해시 테이블에 적재해야 할 데이터의 양을 줄일 수 있다는 장점이 있음.
하이브에서는 '버킷 맵 조인'이라고 부름

맵 사이드 병합 조인

파티셔닝뿐만 아니라, 같은 키를 기준으로 정렬됐다면 변형된 맵 사이드 조인을 적용할 수 있음.
매퍼는 리듀서에서 일반적으로 수행하는 것과 동일한 병합 연산을 수행할 수 있기 때문에
입력 크기가 메모리에 적재 가능한지 고려할 필요가 없음.
이 방식이 가능하다면 선행 맵리듀스 작업이 이미 파티셔닝 & 정렬을 해놨다는 뜻.

맵 사이드 조인을 사용하는 맵리듀스 워크플로

맵 사이드 조인을 수행하기 위해서는 제약 사항(크기, 정렬, 입력 데이터의 파티셔닝)이 따름.
맵 태스크 수는 큰 입력의 파일 블록 수에 따라 결정된다.
작은 데이터셋은 브로드캐스트(join)하거나, 동일한 파티션으로 분할되어야 한다.
하둡 생태계에서는 데이터셋 파티셔닝 관련 메타데이터를 관리하는 H카탈로그나 하이브 메타스토어를 사용하기도 함.

2-4. 일괄 처리 워크플로의 출력

➔ 일괄 처리는 입력 데이터셋 부분을 스캔하는 것이 일반적이라 분석에 더 가까움.

검색 색인 구축

구글에서 검색 엔진에 사용할 색인을 구축하기 위해서 맵리듀스를 사용했었음.
정해진 문서 집합을 대상으로 full-text 검색이 필요하다면 일괄 처리가 효율적임
1. 매퍼는 필요에 따라 문서 집합을 파티셔닝 하고 각 리듀서가 해당 파티션에 대한 색인을 구축한다.
2. 그리고 색인은 분산 파일 시스템에 저장됨.
색인된 문서 집합이 변하면 주기적으로 전체 색인 워크플로를 재수행해야함.

일괄 처리의 출력으로 키-값 저장

배치 프로세스의 출력을 웹 애플리케이션이 질의하는 DB로 보내는 방법이 있을까?
가장 심플한 방법 : 직접 매퍼/리듀서 내에서 선호하는 DB로 요청 보내는 것
근데 좋은 방법은 아님. 왜?
1. 일단 일괄 처리 태스크는 데이터양이 많아서 레코드마다 네트워크 요청을 하면 성능 떨어짐
2. 외부에 출력을 생성하게 되면, 맵리듀스 작업의 실패&재시도 과정이 노출됨.
그럼 더 좋은 방법은?
- 일괄 처리 작업 내부에 완전히 새로운 DB를 구축해 분산 파일 시스템의 작업 출력 디렉터리에 저장
- 이때 데이터 파일은 한 번 기록되면 불변이고 서버에 bulk로 적재해 읽기 전용 질의를 처리할 수 있음.
데이터베이스 파일을 생성하는 작업은 굉장히 좋은 맵리듀스 활용법
- 매퍼로 키를 추출한 다음, 키로 정렬하는 과정은 색인을 만들 때도 꼭 필요한 작업임.

일괄 처리 출력에 관한 철학
➔ 일괄 처리의 철학은 “입력은 불변, 출력은 완전히 새로 생성”이라는 유닉스 철학에서 비롯됨.

재실행이 용이함
- 코드 오류나 실패 시 입력 데이터만 유지하면 재실행으로 복구 가능.
- 잘못된 데이터가 DB에 기록되지 않아 “사람의 실수(human fault)”에도 안전.
되돌릴 수 있는 구조
- 결과를 쉽게 되돌릴 수 있게 설계하여 “비가역성 최소화(minimizing irreversibility)” 실현.
- 애자일 개발 및 실험적 개발에 적합.
맵리듀스의 내결함성(fault tolerance)
- 실패한 태스크는 동일 입력으로 자동 재시도.
- 여러 번 실패 시 프레임워크가 해당 출력 폐기 후 작업 실패로 처리.
입력-출력의 명확한 분리
- 코드 수정, 모니터링, 디버깅 시 외부 부수 효과가 없으므로 단순함 유지.
- 출력의 품질은 입력과 코드만으로 결정됨.

2-5. 하둡과 분산 데이터베이스의 비교

하둡은 유닉스의 분산 버전과 비슷함
HDFS는 파일 시스템이고 맵리듀스는 특별한 방식으로 구현된 유닉스 프로세스다.

저장소의 다양성

전통적인 DB는 특정 모델(관계형, 문서형 등)에 맞게 데이터를 구조화해야 한다.
반면 HDFS는 훨씬 유연해서, 어떤 형태의 데이터든 그대로 저장 가능함.
- 텍스트, 이미지, 비디오, 센서 데이터, 시퀀스 등 다양한 형태를 지원.
하둡은 데이터를 먼저 저장하고 나중에 해석하는(dump first, process later) 방식
MPP DB는 데이터를 저장하기 전에 이미 정해진 스키마에 맞게 가공해야 함.
하둡은 데이터를 저장할 때 스키마를 강제하지 않음. 대신 데이터를 읽을 때 스키마를 적용
- schema-on-read
- 데이터 해석의 책임은 소비자에게 있다.
- 이는 초밥 원리(sushi principle)로 부름 - 데이터는 원시(raw) 상태가 더 좋다

하둡은 ETL의 중간 저장소 역할로 자주 사용된다.
- 트랜잭션 처리 시스템 → 원시 데이터 덤프 (하둡 저장)
- 이후 맵리듀스 작업은 관계형 형태로 데이터를 정제하고, 분석을 위해 MPP 데이터웨어하우스로 이동
- 즉, 수집 단계(하둡) 와 분석 단계(MPP DB) 를 명확히 분리하는 구조.

처리 모델의 다양성

MPP(Massively Parallel Processing) 데이터베이스에 대해서
- MPP DB는 일체형 구조로 디스크 저장소, 쿼리 최적화, 스케줄링, 실행 엔진이 긴밀하게 통합되어 있음.
- 데이터베이스의 특성과 쿼리 유형에 맞게 튜닝이 최적화되어 있어 매우 좋은 성능을 낼 수 있다.
- SQL 언어를 통해 복잡한 처리를 코드 작성 없이 수행할 수 있음.
- Tableau 같은 BI(비즈니스 인텔리전스) 도구로 시각화하기 쉬움.
- 즉, 분석용 쿼리와 정형 데이터 처리에는 매우 효율적.
SQL 기반 처리의 한계
- SQL은 모든 종류의 처리에는 적합하지 않다.
- 머신러닝, 추천 시스템, 자연어 처리 등은 '통계적/비정형 처리'가 필요하여 SQL로 표현하기 어려움.
- 이러한 비정형 처리에는 전용 애플리케이션 모델이나 코드 기반 접근이 필요함.
맵리듀스를 이용하면...
- 엔지니어가 직접 작성한 코드를 대규모 데이터셋에 대해 실행할 수 있다.
- 하이브처럼 HDFS 위에 SQL 실행 엔진을 추가할 수도 있음.
- 즉, SQL과 코드 기반 처리를 혼합 활용할 수 있다.
시간이 지나면서...
- 하나의 처리 모델로는 모든 작업을 해결하기 어렵다는 점이 드러났다.
- 하둡은 이를 해결하기 위해 여러 형태의 처리 모델을 동시에 지원할 수 있도록 발전
  - 맵리듀스, SQL, 스트리밍 등이 있다고 함. (맵 리듀스를 너머에서 자세히 다룰 예정)
- 하둡의 플랫폼 개방성 덕분에 기존 MPP 데이터베이스보다 훨씬 다양한 처리 방식을 수용 가능하게 되었다.
하둡 생태계의 확장
- 하둡 생태계에는 두 가지 대표적 데이터베이스가 존재
  - HBase → OLTP
  - Impala → MPP 스타일
- 두 시스템 모두 맵리듀스를 사용하진 않지만, HDFS를 저장소로 사용한다.
- 둘이 통합해서 쓸 수도 있음.
  - HBase는 빠른 쓰기/조회 중심, Impala는 복잡한 쿼리 중심으로 쓴다고 함.

빈번하게 발생하는 결함을 줄이는 설계

맵리듀스와 MPP 비교 시 가장 두드러지는 차이점
1. 결함을 다루는 방식
2. 메모리 및 디스크를 사용하는 방식

맵리듀스는...
1. 대용량 데이터 처리에 적합
2. 오랜 시간 수행되는 작업에서도 일부 실패 시 재시작이 용이하다.
3. 작업은 태스크 단위로 나뉘어 병렬 실행되며, 태스크 하나가 실패해도 전체 작업을 다시 실행하지 않아도 된다.
4. 대신 모든 중간 결과를 디스크에 저장하기 때문에 복구는 빠르지만, 메모리 효율성은 낮음.
5. 태스크 종료가 예상치 못하게 자주 발생하더라도 견딜 수 있게 설계되어 있음.
근데 현실 세계에서는 이런 장애가 자주 일어나진 않음.
- 내결함성을 확보하기 위해 상당한 오버헤드를 감당하는게 가치가 있을까..?

❐ 3. 맵리듀스를 넘어

...

맵리듀스는 학습하기가 매우 유용한 도구. 분산 파일 시스템 상에서 상당히 단순 명로하게 추상화된 모델이기 때문
여기서 단순함이란? 무엇을 하고 있는지 이해하기 쉽다는 뜻.
반면에 맵리듀스 원시 API를 사용해서 복잡한 연산을 구현하는 일은 실제로 매우 어렵고 수고스러움.
이번 장의 나머지 부분에서는 일괄 처리 방법의 대안을 살펴보는데 할애할 것임.

3-1. 중간상태 구체화 (Materialization of Intermediate State)

중간 상태 & 구체화

모든 맵리듀스 작업은 다른 작업과 독립적이며, 주요 접점은 분산파일 시스템 상의 입력과 출력 디렉터리
보통 한 작업은 같은 팀 내의 다른 특정 작업의 입력으로만 사용됨.
이 경우에 분산 파일 시스템 상에 있는 파일들을 중간 상태(Intermediate state)라고 함.
그리고 중간 상태를 파일로 기록하는 작업을 구체화(materialization)라고 함.
- unix의 파이프는 중간 상태를 구체화하진 않고, 인메모리 버퍼에 스트리밍(streaming)함.

중간 상태를 구체화하는 맵리듀스 접근 방식의 단점

맵리듀스는 선행작업이 완료되어야만 후행작업을 할 수 있음. → 워크플로 전체 수행 시간이 느려짐
종종 중복되기도 함.
임시데이터를 대상으로 구체화는 과잉조치임

데이터플로 엔진

위에서 본 문제를 해결하기 위해 여러 엔진들이 개발됨.
이 엔진들의 공통점은, 전체 워크플로를 독립된 하위 작업으로 나누지 않고 하나로 다룸.
그리고 이 엔진들은 여러 처리 단계를 통해 데이터 흐름을 명시적으로 모델링하기 때문에
데이터플로 엔진이라고 부름
데이터플로 엔진은
- 입력을 파티셔닝해 병렬화 함.
- 한 함수의 출력을 다른 함수의 입력으로 사용하기 위해 네트워크를 통해 복사함.
- 연산자의 출력과 다른 연산자의 입력을 연결하는 여러 가지 선택지를 제공함.
  - 연산자 : 맵과 리듀스를 번갈아 수행하는 규칙을 지키지 않아도 되는 함수
- 맵리듀스 워크플로와 동일한 연산을 구현할 수 있다.
- 최적화로 인해 수행 속도가 훨씬 빠르다.

내결함성

분산 시스템에서 중간 상태를 모두 구체화할 때 챙길 수 있는 이점 ➔ 내구성
아무래도 모든 중간상태를 다 가지고 있으니깐 쉽게 내결함성을 보장함.
중간 상태를 사용하지 않는 애들 ➔ 스파크, 플링크, 테즈
- 그럼 어떻게 내결함성을 보장할까?
  ➔ 유효한 데이터로부터 계산을 다시 해서 복구함 (항상 정답은 아님!)
  ➔  근데 이렇게 하려면 데이터가 어떻게 연산됐는지 추적을 해야 함.
     ➔  스파크의 경우에는 RDD(Resilient distributed dataset) 추상화를 사용함.
     ➔  플링크는 연산자 상태를 체크포인트로 남김.
- 데이터를 재연산할 때 중요한 점은? ➔ 연산의 결정적(deterministic) 여부 == 멱등성
- 물론 비결정적 연산도 있기 때문에, 원인을 제거해야 함.

3-2. 그래프와 반복 처리

페이지랭크

웹 페이지를 링크하는 다른 웹 페이지를 기반으로 인기도를 측정하는 알고리즘
웹 검색 엔진에서 검색 결과를 나타낼 때 사용하는 순서를 결정하는 방법 중 하나

알고리즘 : 이형적 폐쇄(transitive closure)

그림2.6 - 데이터베이스에 포함된 북미 지역의 모든 위치 목록을 만드는 예제

특정 정보를 전파하기 위해 정점 하나와 인접한 정점을 조인하면서 특정 조건에 도달할 때까지 반복

반복적인 스타일로 구현하는 이유

맵리듀스에는 "완료할 때 까지 반복"이라는 개념이 없음.
왜냐면 맵리듀스는 데이터를 일회성으로만 처리하기 때문임.
접근법
1. 외부 스케줄러가 이 알고리즘의 한 단계를 연산하기 위해 일괄 처리를 수행함.
2. 해당 일괄 처리가 완료되면, 스케줄러는 종료 조건을 기반으로 완료됐는지 확인함.
3. 아직 끝나지 않았다면 스케줄러는 1단계로 돌아가서 다음 일괄 처리를 수행한다.
위 접근법으로 맵리듀스를 구현해도 동작하지만 상당히 비효율적임

프리글 처리 모델

벌크 동기식 병렬(Bulk synchronous parallel, BSP) 연산 모델
- 일괄 처리 그래프를 최적화하는 방법 중 하나.
- 구현체 : 아파치 지라프, 스파크 그래프 X API, 플링크 젤리 등.
- 프리글 모델로도 불림

내결함성

정점이 서로 직접 질의하는 방식이 아니라 메시지 전달로 통신한다는 점은 프리글 작업 성능 향상에 도움이 됨
메시지는 일괄 처리가 가능해 통신 중 대기 시간이 발생하지 않기 때문임
프리글 구현상 다음 반복에서 메시지는 목적지 정점에 정확히 한 번만 처리됨.
프리글 차원의 내결함성은 반복이 끝나는 시점에 모든 정점의 상태를 주기적으로 체크포인트로 저장해서 보장.

병렬 실행

정점의 실행 위치와 메시지 전달
- 정점은 특정 장비에서 실행될 필요가 없으므로, 메시지를 보낼 때 정점 ID를 사용해 다른 정점으로 전달함.
- 그래프를 어떤 장비에 분할(파티셔닝)하고, 메시지를 어떻게 라우팅 할지를 프리글(Pre-gel) 프레임워크가 담당.
그래프 파티셔닝 방식
- 일반적으로 통신이 자주 발생하는 정점끼리 같은 장비에 위치시키는 것이 이상적이지만,
- 실제로는 복잡하므로 단순히 임의로 부여된 정점 ID 기준으로 나누는 경우가 많다.
- 즉, 관련성이 높은 정점끼리 묶이지 않을 수 있음.
통신 오버헤드 문제
- 분산 환경에서는 장비 간 통신(메시지 전달) 오버헤드가 큼.
- 특히 중간 상태의 메시지가 많아지면 원본 그래프보다 통신 비용이 훨씬 커질 수 있음.
- 네트워크 메시지 전송으로 인해 분산 그래프 알고리즘의 성능 저하가 발생할 수 있다.
단일 장비 처리의 이점
- 그래프가 단일 컴퓨터 메모리에 들어갈 만큼 작다면, 분산보다 단일 장비에서 처리하는 게 훨씬 효율적.
- 심지어 단일 스레드로 실행하더라도 성능이 더 좋을 수 있음.
- 단일 장비에서 처리할 수 없는 큰 그래프의 경우에는 GraphChi 같은 단일 장비용 그래프 프레임워크 사용도 가능.
결론
- 그래프가 너무 커서 단일 장비 메모리에 담을 수 없다면, 프리글(Pre-gel) 같은 분산 접근법을 써야 함.
- 병렬 그래프 알고리즘의 효율적인 실행은 여전히 연구가 진행 중인 분야.

3-3. 고수준 API와 언어

배경

MapReduce가 대규모 데이터를 처리할 수 있게 되면서 분산 일괄 처리 기술이 성숙함.
물리적인 인프라 문제는 해결되었지만, 프로그래밍 모델은 여전히 복잡했음
- 더 효율적인 프로그래밍 모델의 필요성이 커짐.

고수준 API의 등장

하이브, 피그, 캐스캐이딩, 크런치 등의 고수준 언어·API가 등장함.
이들은 개발자가 직접 맵리듀스 코드를 작성하지 않고도 데이터플로우 방식으로 일괄 처리 수행할 수 있게 함.
스파크, 플링크도 이 계보에 속하며 고수준 데이터플로우 API를 제공함.
이 API들은 관계형 스타일의 빌딩 블록을 통해 데이터 조인, 필터링, 그룹화 등의 작업을 표현할 수 있게 함.

선언형 언어로의 전환

기존에는 코드를 명시적으로 작성해 조인을 수행했지만,
선언형 접근법(declarative approach)은 시스템이 어떤 조인 방식을 쓸지 자동으로 결정함.
하이브, 스파크, 플링크는 비용 기반 최적화(Cost-based optimization)를 수행해
조인 순서나 실행 계획을 스스로 변경하기도 함.
개발자는 모든 알고리즘을 직접 이해할 필요 없이 "무엇을 할지(what)”만 정의하면 됨.

함수형 모델과 코드 실행

MapReduce와 그 후속 프레임워크는 SQL과 달리 함수형 프로그래밍 모델을 따름.
- 함수 호출(map, reduce)을 이용해 코드를 작성하고 병렬 실행함.
- 파싱, 자연어 처리, 이미지 분석 등에서도 이러한 함수형 패턴이 활용됨.
이미 다양한 통계/수치 계산용 라이브러리가 존재하며 이를 그대로 활용 가능.

임의 코드 실행과 MPP DB의 비교

MPP(Massively Parallel Processing) 데이터베이스는 일반적으로 SQL 기반이고,
일괄 처리 시스템(MapReduce, Spark 등)은 임의 코드 실행 가능성을 강조함.
하지만 최근에는 경계가 점점 모호해져서, MPP DB + 일괄 처리 프레임워크가 기능적으로 수렴하는 추세.

고수준 API의 장점

생산성과 유지보수성이 높아짐.
장비 수준에서도 효율적인 실행 가능.
조인 최적화, 코드 벡터화(Vectorization), 내부 루프 최적화 등으로 CPU 캐시 낭비를 줄이고 실행 속도를 향상.

다양한 분야로의 확장

일괄 처리 프레임워크는 점차 다양한 분야로 확장됨:
- 통계·수치 알고리즘
- 추천 시스템 / 머신러닝 (예: Mahout)
- 공간 검색(k-최근접 이웃, KNN)
Mahout은 MapReduce, Spark, Flink 위에서 실행되는 머신러닝 알고리즘 모음.
MADlib은 관계형 MPP DB 내부에서 실행되는 유사한 라이브러리임.

Part3. 파생 데이터 (Derived Data)

gilbert9172 — Sun, 26 Oct 2025 16:03:46 +0900

❐ 정리

1부와 2부에서는
- 분산 데이터베이스로 가기 위해 고려해야 할 모든 주요 사항을 밑바닥 부터 다뤘음.
- 하지만 1,2부에서는 애플리케이션이 단일 데이터베이스를 사용한다고 가정했음.
3부에서는
- 다양한 특징을 가지는 여러 데이터 시스템을 일관성 있는 하나의 애플리케이션 아키텍처로
  통합하는 문제에 대해서 검토한다.

❐ 레코드 시스템과 파생 데이터 시스템

➔ 데이터를 저장하고 처리하는 시스템은 크게 두 분류로 나눌수 있음.

레코드 시스템

믿을 수 있는 데이터 버전을 저장한다.
진실의 근원(source of truth)라고도 한다.
- 각 사실은 일반적으로 정규화를 거쳐 정확하게 한 번 표현된다.

파생 데이터 시스템

다른 시스템에 존재하는 데이터를 가져와 특정 방식으로 변환하고 처리한 결과
파생 데이터를 잃게 되더라도, 원천 데이터로부터 다시 생성할 수 있음.
대표적인 예로 캐시를 들 수 있음.
엄밀히 말하자면, 파생 데이터는 중복(rerdundant)라고 할 수 있음.
읽기 질의 성능을 높이는 데 종종 필수적 요소임.
대개 비정규화 과정을 통해 생성됨 (스테이킹 개발할 때 grossRewardAmount 같은거)

❐ 3부 개요

10장에서는
- (mapReduce와 같은) 일괄 처리 방식(batch-oriented) 데이터플로 시스템을 살펴볼 예정
- 대규모 데이터 시스템을 구축하기 위한 원리가 무엇인지 알아볼 예정
11장에서는
- 10장과 동일한 아이디어를 데이터 스트림에 적용해볼 예정
12장에서는
- 이 책의 마지막 장
- 미래에 신뢰할 수 있고 확장 가능하면 유지보수하기 쉬운 애플리케이션을 구축하기 위해서
  앞서 언급한 도구들을 어떻게 사용해야 하는지에 대한 아이디어를 모색할 예정

9장. 일관성과 합의 (Consistency and Consensus)

gilbert9172 — Fri, 17 Oct 2025 20:12:58 +0900

❐ 0. Description

이번장 에서는..

내결함성을 지닌 분산 시스템을 구축하는데 쓰이는 알고리즘과 프로토콜의 몇 가지 예를 얘기한다.
그리고 8장에서 설명한 모든 문제가 발생할 수 있다고 가정한다.
시간은 최선을 다하더라도 근사치 밖에 쓸 수 없다.
노드는 멈출 수 있고, 언제라도 죽을 수 있다.

내결함성을 지닌 시스템을 구축하는 가장 좋은 방법은?

유용한 보장을 해주는 범용 추상화를 찾아 이를 구현하고 애플리케이션에서 이 보장에 의존하는 것.
그니깐 모든 애플리케이션에서 각자 장애 복구 로직을 구현하는 건 비효율 적임
대신 신뢰성 있는 공통 추상화 계층을 만들어서, 그 위에 애플리케이션을 올리면
각 앱은 그 보장(트랜잭션, exactly-once)에 의존해 더 안전하게 동작할 수 있음.

합의 (Consensus)

분산 시스템에서 가장 중요한 추상화 중 하나
어떤 것을 할 수 있고 어떤 것을 할 수 없는지에 대한 범위를 이해해야 함.

❐ 1. 일관성 보장 (Consistency Guarantees)

복제 데이터베이스

대부분 최소한 최종적 일관성을 제공
쓰기를 멈추고 불특정 시간 동안 기다리면 결국 모든 읽기 요청이 같은 값을 반환(수렴)
하지만 이것은 매우 약한 보장(weak guarantee)
- 왜냐면 언제 복제본이 수렴될지에 대한 정보가 하나도 없기 때문
이러한 최종적 일관성의 엣지 케이스는 시스템에 결함이 있거나 동시성이 높을 때만 드러남.

강한 일관성 모델

앞으로 데이터 시스템이 제공할 수 있는 더 강한 일관성 모델에 대해서 살펴 볼 예정
1. 선형성(linearlizability)
2. 이벤트 순서화 문제 (인과성과 전체 순서화와 관련된 문제 검토)
3. 분산 트랜잭션을 원자적으로 커밋하는 방법
강한 보장을 제공하는 시스템은
1. 성능이 나쁘거나
2. 약한 보장이 제공하는 시스템보다 내결함성이 약할 수도

❐ 2. 선형성 (Linearizability)

아이디어

데이터 복사본이 하나만 있는 것처럼 보여주자!
읽힌 값이 최근에 갱신된 값임을 보장해줌 ➔ 최신성 보장(recency guarantee)
단점은 모든 복제본에 값이 write 될 때 까지 기다여야 하기 때문에 느림

선형성 위반 예시

복제 지연으로 인해 밥은 앨리스보다 우승자 확인을 늦게하는 상황
밥의 질의가 오래된 결과를 반환했다는 사실이 선형성 위반

2-1. 시스템에 선형성을 부여하는 것은 무엇인가?(What Makes a System Linearizable?)

➔ "복사본이 하나 뿐인 것처럼 보이게 하자"를 이해하기 위해 예제를 살펴보자.

동시에 같은 키(x)를 읽고 쓰는 예시

읽기와 쓰기 요청이 동시에 실행되면 과거의 값을 반환할 수도, 새로운 값을 반환할 수도 있음.
결과적으로 A,B는 서로 다른 값을 받을 수도 있다.
즉, "데이터의 단일 복사본"을 모방하는 시스템에 기대하는 바가 아님!

선형 시스템에서는 값이 원자적으로 바뀌는 시점이 있어야 한다고 가정함.
예시의 경우에는, A가 x를 1로 읽었으면 B도 1로 읽어야 함.

두 번째 타이밍 다이어그램을 개선한 버전. (원자적으로 영향을 주는 개별 연산을 시각화)
선형성의 요구사항은 연산 표시를 모은 선들이 항상 시간순으로 진행돼야 함.
참고로 위 예시에서 클라이언트B의 마지막 읽기는 선형적이지 않음.
- 이 연산은 x를 2에서 4로 갱신하는 C의 cas쓰기와 동시적
- 다른 요청이 없으면 2가 맞는데 A가 읽기를 했고, 그 결과가 4
- 그렇다면 B도 4를 읽어야 함.

선형성 vs 직렬성

직렬성
- 모든 트랜잭션이 여러 객체를 읽고 쓸 수 있는 상황에서의 트랜잭션의 격릴 속성
- 트랜잭션이 어떤 순서에 따라 실행되는 것 처럼 동작하도록 보장해줌.
- 이때 순서가 트랜잭션이 실제로 실행되는 순서와 달라도 상관이 없음.
- ex. 직렬성 스냅숏 격리 ➔ 미리 떠놓은 스냅샷을 읽기 때문에 비선형적
선형성
- 레지스터(개별 객체)에 실행되는 읽기와 쓰기에 대한 최신성 보장
- 선형성 연산은 트랜잭션으로 묶지 않음 ➔ "write skew" 같은 문제를 막지 못함.
- ex. 2PL, 실제적인 직렬 실행을 기반으로 한 직렬성 구현

선형성 + 직렬성

선형성과 직렬성의 조합을 '엄격한 직렬성' 또는 '강한 단일 복사본 직렬성' 이라고 함.

2-2. 선형에 기대기 (Relying on Linearizability)

➔ 어떤 환경에서 선형성이 유용한지 알아보자.

잠금과 리더 선출

단일 리더 복제 시스템은 스플릿 브레인을 방지하기 위해 하나의 리더만 선출해야 한다.
이를 보장하기 위해서 잠금을 사용하는 것인데, 이 잠금의 구현은 무조건 선형적이여야 함.
분산 잠금과 리더 선출을 구현하기 위해 코디네이션 서비스가 사용되는데
이들은 합의 알고리즘을 사용해 선형성 연산을 내결함성이 있는 방식으로 구현함.

제약 조건과 유일성 보장

데이터를 기록할 때 유일성 조건을 강제하고 싶다면 선형성이 필요함.
예를 들면 서비스 가입할 때, 닉네임이 점유되어 있지 않다면 사용 가능

채널 간 타이밍 의존성

파일 저장 서비스가 비선형적이라면? (선형적이라면 위 플로우는 문제 없음.)
- 현재 '이미지 크기 변경 모듈'은 두개의 채널과 통신함. ➔ 메시지 큐 & 파일 저장소
- 이때, 메시지 큐가 저장소 내부의 복제보다 빠를 수도 있음.
- 모듈이 과거 버전 이미지를 처리하게 될 수도 있음.
- 이렇게 되면, 원래 크기의 이미지와 변경된 이미지가 영구적으로 불일치하게 됨.
즉, 선형성의 최신성 보장이 없으면 이 두 채널 사이에 경쟁 조건이 발생할 수 있음.

예상 시나리오

사용자가 "ABC.png" 업로드. 그리고 큐에 메시지 "ABC-1" 전달
모종의 이유로 큐에서 딜레이 발생
그 사이에 사용자가 이미지로 교체함(이때 이미지 명 같음). 그리고 큐에 메시지 "ABC-2" 전달
큐 내부 사정이나 네트워크 지연 때문에 "ABC-2"를 먼저 모듈에 전달.
모듈에서 "ABC-2"의 정보를 바탕으로 리사이즈
그리고 큐에서 "ABC-1"를 모듈에 전달.
과거의 정보를 바탕으로 리사이즈된 이미지가 최종적으로 저장됨.

해결 방법

이벤트 순서 제어
- 메세지에 타임스탬프 또는 버전 정보를 추가해서 가장 최신 이벤트만 처리하도록 하기
payload 정보 변경 + 재시도 메커니즘(retry, outbox 등등)
- payload에 메시지의 UUID를 넘기고, UUID를 기반으로 리사이즈하기
- 만약 DB에 저장되기 전에 메시지가 소비 될 경우를 대비해서 재시도 메커니즘 구현

2-3. 선형성 시스템 구현하기

➔ 정말 심플하게 진짜 복사본을 하나만 사용하기. 그러나 이 방법으로 결함을 견뎌낼 수 없다.

5장에서 봤던 내용을 선형적으로 만들 수 있을까?

단일 리더 복제 (선형적이 될 가능성이 있음)
합의 알고리즘 (선형적)
다중 리더 복제 (비선형적)
리더 없는 복제 (아마도 비선형적)
- '일 기준 시계'를 기반으로 LWW 충돌 해서 방법은 거의 확실히 비선형적
- 시계 타임스탬ㅁ프는 clock skew 때문에 이벤트의 실제 순서와 일치함을 보장할 수 없기 때문

선형성과 정족수

n	3
w	3
r	2
w + r > n	5 > 3 (true)

엄격한 정족수를 사용하지만 비선형적인 실행 케이스
A의 요청이 완료된 후, B가 요청함.
- 선형적이라면 B는 1을 읽어야 하는데, 0을 읽음.
- 결과적으로 비선형적
다이나모 스타일 정족수를 선형적으로 만드는게 가능함(성능은 당연히 저하됨)
- 읽기 복구를 동기식으로 처리해서 가능하게 함.

2-4. 선형성의 비용

단일 리더 설정은 비선형적

단일 리더 설정에서 데이터센터 사이의 네트워크가 끊기면 팔로워 데이터센터로 접속한
클라이언트들은 리더로 연결할 수 없으므로 데이터베이스에 아무것도 쓸 수 없고,
선형성 읽기도 전혀 할 수 없음.
팔로워로부터 읽을 수는 있지만 데이터가 최신이 아닐수 있음.(비선형적)

CAP(Consistency / Availability / Partition tolerance) 정리

일관성, 가용성, 분할 허용성 사이의 trade-off를 설명하는 정리
원래는 데이터베이스에서 trade-off에 대한 논의를 시작하려는 목적
정확한 정의 없이 경험 법칙으로 제안됐음.
공식적으로 정의된 CAP 정리는 매우 범위가 좁음.
➔ 오직 하나의 일관성 모델과 한 종류의 결함만 고려함.
결론 : 역사적 영향력은 있는데 시스템을 설계할 때는 실용적 가치 없음.

도움이 안되는 CAP 정리
- CAP은 때때로 '일관성', '가용성', '분할 허용성' 중 2개를 고르라는 것으로 표현됨.
- 근데 이런 식으로 생각하면 오해의 소지가 있음.
- 왜? 네트워크가 올바르게 동작할 때는 시스템이 일관성(선형성)과 가용성 모두를 제공하기 때문임.

➔ CAP의 올바른 정의 : "네트워크 분단(Partition)이 생겼을 때" 일관성과 가용성 중 하나를 선택하라

선형성과 네트워크 지연

선형성은 (네트워크가 정상이든, 아니든) 항상 느리다.
따라서 선형성을 보장하면, 성능이 떨어진다.

❐ 3. 순서화 보장 (Ordering Guarantees)

3-1. 순서화와 인과성

순서화는 인과성을 보존하는데 도움을 준다.

인과성은 이벤트에 순서를 부과한다.
- 결과가 나타나기 전에 원인이 발생한다.
- 메시지를 받기 전에 메시지를 보낸다.
- 답변하기 전에 질문한다.
시스템이 인과성에 부과된 순서를 지키면
➔ 그 시스템은 인과적으로 일관적(causally consistent)이라고 한다.
- 스냅숏 격리가 인과적 일관성을 제공하는 예시
- 어떤 데이터를 읽었어. 그럼 이 데이터보다 인과적으로 먼저 발생한 데이터도 볼 수 있어야 함.

수학적 집합은 부분적으로 순서가 정해짐(partially ordererd)

{a, b, c} / {a, b} / {b, c} ➔ 이런 경우라면 포함관계를 설명할 수 있기 때문에 비교할 수 있음.
{a, b} / {b, c} ➔ 이 경우에 각 요소는 어떤 집합과의 포함관계를 설명할 수 없기 때문에 비교할 수 없음.

인과적 순서가 전체 순서는 아니다. (선형성 ≠ 인과성)

선형성
- 연산의 전체 순서를 정할 수 있다.
- 복사본이 하나만 있는 것처럼 동작하고 모든 연산이 원자적이면
  어떤 두 연산에 대해 항상 둘 중 하나가 먼저 실행됐다고 할 수 있다는 뜻
- 선형성 데이터스토어에는 동시적 연산이 없다.
- 하나의 타임라인이 있고, 모든 연산은 그 타임라인을 따라서 전체 순서가 정해져야 한다.
인과성
- 동시에 실행되면 비교할 수가 없다.
- 인과성이 전체 순서가 아니라 부분 순서를 정의한다는 뜻
- 동시성은 타임라인이 갈라졌다가 다시 합쳐지는 것을 의미한다.
- 이 경우 다른 branch에 있는 연산은 비교 불가(즉, 동시적)하다.

선형성은 인과적 일관성보다 강하다.

선형성은 인과성을 내포한다.
- = 어떤 시스템이든지 선형적이라면 인과성도 올바르게 유지한다.
근데 앞서 말했듯이 시스템을 선형적으로 만들면, 성능과 가용성이 떨어진다.
하지만, 선형성이 인과성을 보존하는 유일한 방법은 아니다.
선형성이 필요해 보이는 경우, 진짜 필요한건 일관적 일관성

인과적 의존성 담기 (Capturing causal dependencies)

인과성을 유지하기 위해서는 어떤 연산이 다른 연산보다 먼저 실행 됐는지 알아야 한다.
이를 알기 위해서 단일 키 뿐만 아니라 전체 데이터베이스에 걸친 인과적 의존성을 추적해야 한다.
인과적 순서를 결정하기 위해 데이터베이스는 애플리케이션이 데이터의 어떤 버전을 읽었는지 알아야 한다.

3-2. 일련번호 순서화(Sequence Number Ordering)

일련번호나 타임스탬프를 써서 이벤트 순서를 정하기

모든 인과적 의존성을 실제로 추적하는 것은 오버헤드가 큼.
더 좋은 방법으로는 '일련번호' 나 '타임스탬프' 를 써서 이벤트 순서를 정하는 것
- 앞에서 학습했듯, 타임스탬프는 논리적 시계에서 얻어도 됨.
- 논리적 시계는 연산을 식별하는 시퀀스를 생성하는 알고리즘임.
- 보통 모든 연산마다 증가하는 카운터를 사용함.

일련번호 or 타임스탬프

크기가 작고, 전체 순서를 제공함.
- 즉, 모든 연산은 고유 시퀀스를 갖고 항상 두 개의 시퀀스를 비교하면 됨.
인과성에 일관적인 전체 순서대로 일련번호를 생성할 수 있음.
- 연산 A가 B보다 인과적으로 먼저 실행됐다면, A는 전체 순서에서도 B보다 먼저임.
- 근데 연산 C, D가 동시에 일어났다면?
  - 동시적인 연산은 서로 인과관계가 없기 때문에 둘 중 뭐가 먼저와도 노상관
  - A > B > C > D or A > B > D > C
- 순서화를 더 부과한다? ➔ 인과성이 없는 연산도 순서를 매겨 버림.
  - 결과적으로 이 방식은 인과 관계를 잘 반영해서, 전체 순서를 잘 만들어줌. (A,B)
  - 근데 동시적에 발생한 연산의 경우에도 강제로 순서를 매겨버림. (C, D)

UUID로 만든 전체 순서의 문제점.

랜덤 UUID는 서로 비교할 수 있기 때문에, 전체 순서를 만들 수 있음.
실제로 A가 먼저 발생하고 B가 발생한 상황에서 UUID를 비교했는데,
B가 먼저 발생한 상황이라고 결정하는 문제가 있을 수 있음.
결과적으로 UUID를 사용한 전체 순서는 인과성이 깨지게 됨

단일 리더 환경이 아닌 경우 일련번호를 생성하는 방법

각 노드가 자신만의 독립적인 일련번호 집합을 생성
- 예를 들어 노드 두 대가 있으면 한 노드는 홀수만, 다른 한 노드는 짝수만
각 연산에 '일 기준 시계'에서 얻은 타임스탬프를 사용하기
- 이 타임스탬프가 순차적이진 않지만, 해상도가 높다면(자리수가 크다면) 충분함
일련 번호 블록을 미리 할당
- A노드는 1 ~ 1000, B노드는 1001 ~ 2000

➔ 위 세가지는 확장성이 좋지만, 생성한 일련번호가 인과성에 일관적이지 않게 된다.

위 세가지 방법의 문제점

각 노드는 초당 연산수가 다를 수 있음.
- 짝수용 카운터가 홀수용 카운터보다 뒤처지거나 하는 상황이 발생할 수 있음.
- 즉, 홀수 연산과 짝수 연산 중 어떤 것이 인과적으로 먼저 실행됐는지 알 수 없음.
물리적 시계에서 얻은 타임스탬프는 시계 스큐에 종속적이러서 인과성에 일관적이지 않을 수 있음.
- 인과적으로 나중에 실행된 연산(B)이 실제로 더 낮은 타임스탬프를 배정 받음.
1003 번이 199번보다 먼저 실행되는 상황이 발생할 수 있음.

램포트 타임 스탬프

핵심 개념
- 인과 관계를 만족시키는 논리적 시계(Logical Clock)
- 실제 물리적 시간이 아니라, “어떤 이벤트가 다른 이벤트보다 앞섰다”는 관계만을 보장하는 시계
메커니즘
- 각 노드는 고유 식별자를 갖고, 각 노드는 처리한 연산 개수를 카운터로 유지
- 램포트 타임스탬프는 그냥 [카운터, 노드ID] 의 쌍
- 때로 같은 카운터 값이 같을 수 있지만, 타임스탬프에 노드 ID를 포함시켜서 유일성을 보장
핵심 아이디어
- 모든 노드와 모든 클라가 지금까지 본 카운터 값 중 최대값을 추적하고 모든 요청에 그 값을 포함시킨다.
- 노드가 자신의 카운터 값보다 큰 카운터를 가진 요청/응답을 받으면 바로 그 값으로 최대값을 증가
이 방법은 램포트 타임스탬프로부터 얻은 순서가 인과성에 일관적이도록 보장해줌.
버전 벡터와의 차이점
- 버전 벡터는 두 연산이 동시적인지 인과적인지 구분할 수 있음. (부분 순서만 표현)
- 램포트 타임스탬프는 항상 전체 순서화를 강제함.

타임스탬프 순서화로는 충분하지 않다.
➔ 유일한 사용자 계정을 생성하는 시나리오

람포트 타임스탬프로 해결할 수 있을 것 같지만 그렇지 않음.
사용자 생성 요청을 당장 결정해야 하는 경우를 생각해봐야 함.
- 노드A가 `username = gilbert`요청을 받음.
- 이 요청을 지금 바로 처리해도 되는지 여부를 판단해야 함.
- 이 시점에 노드A는 다른 노드들이 무슨 일을 하고 있는지 모름.
- 결국 “지금 시점”에서는 안전하게 결정할 근거가 없음.
즉, 모든 노드의 정보(연산)를 받아야만 전체 순서를 알 수 있는 거임.
- 램포트 타임스탬프가 딱 이런 케이스임.

3-3. 전체 브로드 캐스트

전체 순서 브로드 캐스트(= 원자적 브로드캐스트)

단일 리더 복제는 한 노드를 리더로 선택하고 리더의 단일 CPU 코어에서 모든 연사을
차례대로 배열함으로써 연산의 전체 순서를 정함
여기서 어려운 문제는 처리량이 단일 리더가 처리할 수 있는 수준을 넘었을 때임.
분산 시스템 분야에서는 위 문제를 이 방법으로 해결하는 것으로 알려져 있음.
- 전체 순서 브로드캐스트(total order broadcast) = 원자적 브로드캐스트(atomic broadcast)

전체 순서 브로드캐스트란?

분산 시스템에서 모든 노드가 같은 순서로 같은 메시지를 받도록 보장하는 통신 방식
두 가지 안전성 속성을 항상 만족해야 한다.
1. 신뢰성 있는 전달 (Reliable delivery)
2. 전체 순서가 정해진 전달 (Totally ordered delivery)
물론 네트워크가 끊긴 경우에는 메시지 전달을 못하지만, 복구되면 원래대로 동작해야 한다.
Zookeeper나 etcd 같은 합의 서비스는 전체 순서 브로드캐스트를 실제로 구현한다.

전체 순서 브로드캐스트 사용하기

데이터베이스 복제
- 상태 기계 복제(state machine replication)
  - 모든 메시지가 데이터베이스에 쓰기를 나타내고 모든 복제 서버가 같은 쓰기 연산을
    같은 순서로 처리하면 복제 서버들은 서로 일관성 있는 상태를 유지하는 원리
직렬성 트랜잭션 구현
- 모든 복제 서버가 쓰기 연산을 같은 순서로 처리하면, 서로 일관성 있는 상태를 유지
- 상태 기계 복제(state machine replication)
로그를 만드는 방법 중 하나
- 메시지 전달은 모든 노드의 로그에 그 메시지를 추가하는 것과 비슷하다.
- 이렇게 하면 모든 노드가 같은 순서로 로그를 쌓기 때문에 동일한 메시지를 볼 수 있음.
펜싱토큰을 제공하는 서비스 구현하는데 유용
- 잠금을 획득하는 모든 요청은 메시지로 로그에 추가
- 모든 메시지들은 로그에 나타난 순서대로 일련번호가 붙음.
- 그러면 일련번호는 단조 증가하므로 펜싱 토큰의 역할을 수행할 수 있음.

TOB 특징

메시지가 전달되는 시점에 그 순서가 고정됨.
중간에 소급적용이 불가능 (즉, 끼워 넣기 X)
이러한 이유로 타임스탬프 순서화보다 강하다고 함.

TOB를 사용해 선형성 저장소 구현하기

선형성과 TOB가 같다고 할 순 없지만, 어느정도 링크되어 있음.
1. 전체 순서 브로드캐스트
  - 비동기
  - 고정된 순서는 보장하지만, 언제 전달될지는 보장되지 않음.
2. 선형성
  - 최신성 보장
`TOB(추가 전용 로그로 사용) + CAS 연산`
1. 클라이언트 A(나), B가 동시에 "gilbert" 생성 시도.
2. 로그 순서는 TOB가 [Create(A), Create(B)]로 확정. ➔ 모든 노드가 동일하게 가지고 있게됨.
3. "gilbert"라는 이름에 대해 처음 등장한 메시지가
  - 나의 메시지라면? 내가 닉 먹는거임
  - 내 메시지가 아니라면? 나의 요청은 abort
4. 만약 동일한 메시지가 처리된다면?
  - 멱등성 보장을 통해 동일한 결과를 반환
근데 이 방법은 선형성 읽기는 보장하지 않음.
- 로그로부터 비동기로 갱신되는 저장소를 읽으면 오래된 값이 읽힐 수 있음.
읽기를 선형적으로 만들기 위한 몇 가지 선택지가 있음.
1. 로그 순서에 따라 읽기
2. 로그의 최신 위치를 동기화한 후 읽기
3. 최신 복제본에서만 읽기

선형성 저장소를 사용해 TOB 구현하기
➔ 선형성이 보장되면 TOB 구현할 수 있다.

구현 아이디어
1. 전역 카운터
  - 선형성을 보장하는 저장소에 정수를 저장한다.
  - 이 정수는 전역적으로 하나뿐인 “메시지 번호” 역할을 한다.
  - 원자적 `increment-and-get` 연산을 지원한다고 가정한다.
2. 메시지를 보낼 때
  - 브로드캐스트하고 싶은 메시지를 만들 때, 먼저 increment-and-get을 실행해서
    ➔ 그 결과값을 메시지의 “일련번호(sequence number)” 로 붙인다.
    » increment-and-get() 연산이 전역에서 단 하나의 순서로 실행됨
  - 모든 노드로 전송
    - 메시지와 함께 부여된 일련번호를 다른 노드들에게 보낸다.
    - 모든 노드가 동일한 순서로 메시지를 전달받게 된다.
    - 메시지가 유실되면 재전송 가능.(일련번호가 있으므로 중복 판별 가능)
램포트 타임스탬프와의 차이점
- 선형성 레지스터를 증가시켜 순열을 형성함.
- 즉, 순열(sequence)이 실제 순서와 100프로 동일함.

선형성, TOB == 합의

단일 노드에서 레지스터를 구현하는건 간단하지 않은 문제임.
- 노드가 죽거나, 네트워크가 끊기는 경우엔?
- 즉, "전역적으로 레지스터”를 만들려면 노드 간 의견이 완전히 일치해야 함.
  ➔ 이건 바로 합의(Consensus) 문제의 본질
선형성과 TOB가 합의 문제로 귀결되는 이유
- 결국엔 모든 노드가 다음에 어떤 값이 되어야 하는지 동의해야 하기 때문

❐ 4. 분산 트랜잭션 합의

합의

분산 컴퓨팅에서 가장 중요하고 근본적인 문제 중 하나.
쉽게 말하면(Informally), 합의의 목적은 단지 여러 노드들이 뭔가에 동의하게 만드는 것임
- 노드가 동의하는 것이 중요한 케이스
  1. 리더 선출
  2. 원자적 커밋

합의 불가능성

FLP 정리
- 어떤 노드가 죽을 위험이 있다면 항상 합의에 이를 수 있는 알고리즘은 없다를 증명한 것
- 아주 제한적인 조건(이상적인 가정) 아래에서만 “불가능”을 증명함.
분산 시스템에서는 노드가 죽을 수 있다고 가정하기에, 신뢰성 있는 합의는 불가능함.
- 하지만 현실 세계에서는 가능함. (타임아웃, 노드가 죽었음을 판단하는 다른 방법 등.. 으로)

4-1. 원자적 커밋관 2단계 커밋

단일 노드에서 분산 원자적 커밋으로 (From single-node to distributed atomic commit)

단일 노드에서 트랜잭션 커밋은
- 데이터가 디스크에 지속성 있게 쓰여지는 순서에 결정적으로 의존한다.
만약 트랜잭션에 여러 노드가 관련한다면? (ex. 다중 객체 트랜잭션, 용어 파티셔닝된 보조 색인)
- 이 경우, 원자성을 보장할 수 없기 때문에 각 노드에서 독립적으로 트랜잭션을 커밋하는 것은 충분하지 않음.
트랜잭션 커밋을 되돌릴 수 없음.
- 물론 보상 트랜잭션 (compensating transaction)으로 비슷해 보이게 할 순 있는데
  데이터베이스의 관점에서 이는 엄연히 분리된 트랜잭션.
  ➔ 트랜잭션 사이에 걸친 정확성 요구사항은 application의 몫

2단계 커밋 소개 (Introduction to two-phase commit)

여러 노드에 걸친 원자적 트랜잭션 커밋을 달성하는 것을 보장하는 알고리즘
단일 노드 트랜잭션에서는 보통 존재하지 않는, 코디네이터(coordinator)를 사용함.
- 코디네이터는 주로 애플리케이션 프로세스 내에서 라이브러리로 구현됨.
- 분리된 프로세스나 서비스가 될 수도 있음.

2단계 커밋 메커니즘
➔ 2PC의 commit/abort 과정은 두 단계로 나뉨 (그래서 이름이 이럼)

평소처럼 애플리케이션이 여러 DB 노드에서 데이터를 읽고 쓰면서 시작
- 여러 DB노드를 참여자(participant)라고 부름
애플리케이션이 커밋할 준비가 되면 코디네이터가 1단계를 시작함.
- 각 노드에 준비 요청을 보내서 커밋할 수 있는지 물어봄
그 후 코디네이터는 참여자들의 응답을 추적함.
참여자 중,
- 모두 "Yes"로 응답하면 코디네이터는 2단계에서 commit 요청 & commit됨.
- 하나라도 "No"로 응답하면 abort 요청을 보냄

약속에 관한 시스템 (A system of promises)

애플리케이션 분산 트랜잭션 희망
- 애플리케이션은 코디네잍어에게 트랜잭션 ID를 요청한다.
- ID는 전역으로 유일함.
애플리케이션은 각 참여자(DB 노드)에서 단일 노드 트랜잭션 시작
- 단일 노드 트랜잭션에 전역적으로 유일한 트랜잭션 ID를 붙임
  ➔ 이렇게 하면 문제가 생겨도 코디네이터나 참여자중 누군가가 abort 시킬 수 있음.
애플리케이션 커밋 준비 상태
- 코디네이터는 모든 참여자에게 전역 트랜잭션 ID로 태깅된 준비 요청을 보냄.
- 보낸 요청 중 하나라도 실패 or 타임아웃 터지면 그 트랜잭션 ID로 abort 요청 보냄
참여자가 준비 요청 받으면 모든 상황에서 트랜잭션을 커밋할 수 있는지 확인
- 이때 참여자는 제약 조건 위반이나 충돌이 없는지도 미리 검사해야 한다.
코디네이터의 최종 결정
- 모든 준비 요청에 대해 응답을 받았을 때 커밋할 것인지 abort할 것인지 결정
- 코디네이터는 추후 죽는 경우에 어떻게 결정했는지 알 수 있도록 그 결정을 디스크에 있는
  트랜잭션 로그에 기록해야 함. 이를 커밋 포인트라고 함.
모든 참여자에게 결과(commit or abort) 요청 전송
- 만약 요청 전송에 문제가 생기면, 성공할 때 까지 무한 재시도

2PC가 원자성을 보장하는 근거

참여자가 "Yes"에 투표할 때, 나중에 무조건 커밋할 수 있음을 약속함.
코디네이터도 한 번 결정하면 그 결정을 변경할 수 없음(위에서 본 무한 재시도)

코디네이터 장애

준비 요청을 보내기 전에는 트랜잭션을 abort 할 수 있음.
참여자가 준비 요청을 받고 "Yes"에 투표했다면 트랜잭션을 일방적으로 abort 할 수 없음.
- 일단 코디네이터로부터 커밋/어보트 여부를 회신 받을 때까지 대기 해야함.
- 이런 상태에서 참여자의 트랜잭션을 의심스럽다(in doubt), 불확실하다(uncertain)고 함.
코디네이터에 장애가 생기면 복구되기를 기다려야 함
- 코디네이터는 2PC를 완료할 수 있는 유일한 방법이기 때문.
- 코디네이터가 복구되면 트랜잭션 로그를 읽어서 의심스러운 트랜잭션의 상태를 결정

3단계 커밋

2PC는 코디네이터가 복구하시를 기다리는 경우가 있어, 블로킹 원자적 커밋 프로토콜이라고 불림.
이론상으로 논블로킹하게 만들 수 있긴 함. 근데 간단하진 않음.
3PC
- 3PC는 지연에 제한이 있는 네트워크와 응답 시간에 제한이 있는 노드를 가정함.
- 기약 없는 네트워크 지연 or 프로세스 중단이 있는 경우, 3PC는 원자성 보장 못함.
일반적으로 논블로킹 원자적 커밋은
- 완벽한 장애 감지기 (perfect failure detector) 메커니즘이 필요
암튼, 이런 이유로 2PC가 계속 쓰임

4-2. 현실의 분산 트랜잭션

엇갈린 평판

긍정 : 달성하기 어려운 중요한 안전성 보장을 제공하는 것으로 봄
부정 : 운영상의 문제를 일으키고 성능을 떨어뜨린다고 봄
- ex. MySQL의 분산 트랜잭션은 단일 노드 트랜잭션 보다 10배 이상 느림
  ➔ 디스크 강제 쓰기 & 네트워크 왕복 시간

두 가지 종류의 분산 트랜잭션

데이터베이스 내부 분산 트랜잭션
- 하나의 분산 데이터베이스 시스템 내부에서 발생하는 트랜잭션
- 같은 DB 소프트웨어 안에서 여러 노드가 하나의 트랜잭션에 참여하는 형태
- ex. MySQL NDB Cluster, VoltDB, CockroachDB
이종 분산 트랜잭션 (Heterogeneous Distributed Transaction)
- 서로 다른 기술이 섞인 트랜잭션이에요.
- 트랜잭션에 참여하는 시스템이 DB만 있는 게 아니라 메시지 브로커, 다른 벤더의 DB일 수도 있음.
- ex. Oracle DB + Kafka 메시지 큐 + MySQL DB

정확히 한 번 메시지 처리 (Exactly-once message processing)

큐에서 나온 메시지는 그 메시지를 처리하는 DB 트랜잭션이 커밋에 성공했을 때만 처리된 것 간주할 수 있음.
(메시지 확인 + 데이터베이스 쓰기)를 단일 트랜잭션에서 원자적 단위로 묶으면,
중간에 장애가 나도 재시도를 통해 effectively-once processing 보장할 수 있음.
그러나 이런 분산 트랜잭션은,
- 트랜잭션에 영향을 받는 모든 시스템이 동일한 원자적 커밋 프로토콜을 사용할 수 있을 때만 가능

XA(eXtended Architecture) 트랜잭션

X/Open XA는 이종 기술에 걸친 2PC을 구현하는 표준이다.
XA는 postgresql, mysql, db2, sql서버, 오라클을 포함한 여러 관계정 데이터베이스와
엑티브MQ, 호닛MQ를 포함한 메시지 브로커에서 지원됨.
XA는 네트워크 프로토콜이 아니고 트랜잭션 코디네이터와 연결되는 인터페이스틑 제공하는 API
XA는 애플리케이션이 네트워크 드라이버나 클라이언트 라이브러리를 사용해
참여자 DB나 메시징 서비스와 통신한다고 가정함.
코디네이터가 죽었다 깨어나면 XA 콜백을 사용해서 디스크에 저장한 상태를 공유함.

의심스러운(in doubt) 상태에 있는 동안 잠금을 유지하는 문제

트랜잭션은 커밋/어보트 될 때까지 잠금을 가지고 있어야 하는데,
2PC를 사용하면 의심스러운 트랜잭션은 상태가 변경되기 전까지 계속 잠금을 잡아야 함.

코디네이터 장애에서 복구하기

앞에서는 코디네이터가 부활하면 의심스러운 트랜잭션을 해소한다고 학습했음.
그러나 현실에서는 고아+의심 트랜잭션(orphaned in-doubt transactions)이 생길 수 있음.
- 트랜잭션 로그 손실, 소프트웨어 오염 등의 이유로
이런 트랜잭션은 영원히 잠금을 유지한테로 남아있게 됨.
DB 서버 재부팅하면? 그래도 안됨.
- 2PC의 메커니즘은 재시작하더라도 in-doubt 트랜잭션의 잠금을 유지해야 함.
- 그렇지 않으면 원자성을 위반할 위험이 있음.
이걸 해결하려면, 관리자가 개입해야 함(수동 작업 필요)
여러 XA 구현체는 참여자가 독단적으로 의심서르오누 트랜잭션을 커밋/어보트할지 결정할 수 있는
경험적 결정(heuristic decision)이라고 부르는 대책이 있긴함.
- 근데 경험적은 2PC의 약속 체계를 위반하는 거임.
- 아마도 원자성을 깰 수 있다를 완곡하게 표현하는 것.

분산 트랜잭션의 제약
➔ 11장, 12장에서 대안적인 방법 학습할 예정

단일 장애점(Single Point of Failure) 문제
- 트랜잭션 코디네이터가 단일 노드에서 실행되면, 장애가 발생 시 전체 시스템이 멈출 수 있음.
- 코디네이터 장애 시 트랜잭션이 잠금 상태로 남거나 다른 애플리케이션 서버까지 영향을 받음.
- 대부분의 코디네이터 구현체는 고가용성(HA) 을 지원하지 않거나 제한적인 복제만 제공함.
애플리케이션 서버 비정상 종료 문제
- 트랜잭션 참여자 중 하나라도 비정상 종료되면, 코디네이터가 그 상태를 알 수 없음.
- 재시작 시 트랜잭션의 일관성 복구를 위해 데이터베이스 로그나 별도의 저장소가 필요하지만,
  대부분의 애플리케이션 서버는 이에 적합하지 않음.
공통 분모(Shared Protocol) 부재
- 서로 다른 데이터베이스/시스템이 함께 XA 트랜잭션을 수행하려면 최소한의 공통 프로토콜이 필요.
- 하지만 각 DB나 시스템이 표준화된 방식(예: SSI)을 따르지 않으면 일관성을 유지하기 어려움.
XA가 아닌 시스템 간의 제한
- XA를 지원하지 않는 데이터베이스나 내부 DB에서는 분산 트랜잭션이 불가능함.
- 일부 2PC(성공 사례도 있지만, 시스템 일부가 응답하지 않으면 실패함.
- 따라서 장애에 취약하고 복구가 어려움.

4-3. 내결함성을 지닌 합의

합의 문제

합의 문제는 일반적으로 다음과 같은 방식으로 정리해서 설명할 수 있음.
- 하나 이상의 노드가 값을 제안하고 합의 알고리즘이 그 제안들 중 하나를 최종 값으로 결정
위 정의에 따르면, 합의는 아래의 속성을 만족해야 함.
- 안전성 속성 (내결함성 상관없으면 이 세개 속성 만족시키는 건 쉬움)
  1. 균일한 동의 : 어떤 두 노드도 다르게 결정하지 않는다.
  2. 무결성 : 어떤 노드도 두 번 결정하지 않는다.
  3. 유효성 : 한 노드가 값v를 결정하면, 어떤 노드에서 제안된 것이다.
- 활성성 속성
  - 종료 : 죽지 않는 모든 노드는 결국 어떤 값을 결정한다.
(균일한 동의 + 무결성)은 합의의 핵심 아이디어

'종료 속성' 자세히 알아보기

종료 속성은
- 내결함성의 아이디어를 형식화(정의)한다.
- 본질적으로 합의 알고리즘은 걍 계속 진행해야 한다고 규정한다.
- 어떤 노드들에 장애가 생겨도, 나머지 멀쩡한 노드들은 결정을 내려야함.
- 죽거나 연결할 수 없는 노드 대수가 절반 미만이라는 가정에 종속적
대부분의 합의 구현은 과반수의 노드에 장애가 나거나 심각한 네트워크 문제가 있더라도
- 안정성 속성(동의, 무결성, 유효성)을 항상 만족함.
- 그러므로 서버는 죽더라도, 유효하지 않은 결정을 내려서 합의 시스템을 오염시키진 않음.

대부분의 합의 알고리즘은 비잔틴 결함이 없다고 가정

노드가 프로토콜을 올바르게 따르지 않으면 프로토콜의 안전성 속성이 깨지게 됨.

'합의 알고리즘'과 '전체 순서 브로드캐스트(TOB)'

널리 알려진 내결함성을 지닌 합의 알고리즘 (유사하지만 같지는 않음)
- 뷰스탬프 복제 (Viewstamped Replication)
- 팍소스(Paxos) ➔ Leaderless
- 멀티 팍소스(Multi-Paxos) ➔ Leader-based
- 라프트(Raft) ➔ Leader-based
- 잽 (Zab)
위 알고리즘에서 '형식적 모델'을 직접 사용하진 않고, 값의 순차열을 결정해서 TOB 알고리즘을 만듬
TOB는 “모든 노드가 같은 순서로 메시지를 받게 하기 위해” 각 메시지 순서마다 합의를 반복해서 실행하는 과정
뷰스탬프 복제, 라프트, 잽은 전체 순서 브로드캐스트를 직접 구현함
- 이렇게 하는게 매번 합의를 하는 것보다 효율적이기 때문

단일 리더 복제와 합의

합의를 하려면 리더가 필요하고, 리더를 정하려면 합의가 필요 (닭이 먼저냐 달걀이 먼저냐)

에포크 번호 붙이기와 정족수
➔ 지금까지 설명한 합의 프로토콜은 단일 리더를 보장하지 않음.

앞서 설명한 프로토콜들은 에포크 번호를 정의하고 각 에포크 내에서는 리더가 유일하다고 보장
- 팍소스 - 투표 번호(ballot number)
- 뷰스탬프 복제 - 뷰 번호(view number)
- 라포트 - 텀 번호(term number)
에포크 번호는 전체 순서가 있고 단조 증가함. 따라서 번호가 큰 놈이 리더가 됨.
- 물론, 정족수로부터 투표를 받음.
노드들은 총 두 번의 투표를 함. (이 때 투표를 하는 정족수는 겹쳐야 함.)
1. 리더 선출하기 위해서
2. 리더의 제안에 투표하기 위해서
이 투표는 2PC와 비슷해 보이긴 함.
- 정리하자면, 모든 노드가 응답해야 하지만, 합의 알고리즘은 과반수만 응답해도 됨.

합의의 제약

합의 시스템은 항상 엄격한 과반수가 동작하기를 요구함.
대부분 합의 알고리즘은 투표에 참여하는 노드 집합이 고정돼 있다고 가정
- 이는 클러스터에 노드를 그냥 추가하거나 제거할 수 없다는 뜻
합의 알고리즘의 동적 멤버십(dynamic membership) 확장은 클러스터에 있는 노드 집합이
시간이 지남에 따라 바뀌는 것을 허용하지만, 이들은 정적 멤버십 알고리즘보다 이해하기 어려움.
합의 시스템은 장애 노드를 감지하기 위해 일반적으로 타임아웃에 의존함.
- 잦은 리더 선출은, 리더를 선택하는데 시간을 더 많이 쓰기 때문에 성능을 떨어뜨림.

멤버십과 코디네이션 서비스

Zookeeper나 etcd 같은 프로젝트는
- "분산 키-값 저장소"나 "코디네이션 설정 서비스"라고 설명됨.
- 작은 양의 데이터를 보관하도록 설계됐고, 이 소량의 데이터는 내결함성을 지닌 TOB 알고리즘을 사용해
  모든 노드에 걸쳐 복제됨.
- 데이터베이스 처럼 보이지만 목적이 다름. 주 목적은 분산 시스템 간의 일관성과 합의를 보장하는 것
- 이렇기 때문에 HBase, Hadoop YARN, OpenStack Nova, Kafka는 모두 Zookeeper에 의존함.
ZooKeeper가 재공하는 흥미로운 기능들
- 선형성 원자적 연산
- 연산의 전체 순서화
- 장애 감지
- 변경 알림

작업을 노드에 할당하기

Zookeeper는 아래의 경우에 유용함
- 리더 선출 필요한 경우
- 파티셔닝된 자원이 있고, 어떤 파티션을 어떤 노드에 할당할지를 결정해야 하는 경우
(원자적 연산 + 단명 노드 + 알림)을 잘 사용하면
➔ 사람의 개입 없이 애플리케이션이 결함으로부터 자동으로 복구될 수 있다.
주키퍼는(보통 3~5개) 고정된 수의 노드에서 합의를 수행하고, 수천 대의 클라이언트가 이를 이용
그래서 zookeeper 왜 씀? ➔ 합의 알고리즘 구현하기 엄청 빡셈(성공한 기록이 없음)

서비스 찾기

특정 서비스에 연결하려면 어떤 IP 주소로 접속해야 하는지 알아내는 용도로도 자주 사용됨.
서비스 찾기는 합의는 필요 없지만, 리더 선출은 합의가 필요함.
- 따라서 합의 시스템이 누가 리더인지 안다면, 다른 서비스가 리더를 찾을 때 그 정보를 써도됨.
- 이런 목적으로 어떤 합의 시스템은 읽기 전용 캐시 복제 서버를 지원함.

멤버십 서비스

현재 클러스터에 속한 노드가 누구인지(살아 있는지 죽었는지)를 합의 기반으로 관리하는 서비스
장애 감지를 합의와 연결하면 노드들은 어떤 노드가 살아 있는 것으로 여겨져야 하는지
혹은 죽은 것으로 여겨져야 하는지에 동의할 수 있다.

8장. 분산 시스템의 골칫거리(The Trouble with Distributed Systems)

gilbert9172 — Mon, 13 Oct 2025 21:49:30 +0900

분산 시스템을 다루는 것은 단일 컴퓨터에서 소프트웨어를 작성하는 것과 근본적으로 다르다.
결국 엔지니어로서 우리의 과제는 모든 것이 잘못되는 와중에도 시스템이 자신의 일을 하도록 만드는 것
9장에서 우리는 분산 시스템에서 그러한 보장을 제공할 수 있는 알고리즘의 예를 살펴보겠습니다.

❐ 1. 결함과 부분 장애(Faults and Partial Failures)

부분장애란?

분산 시스템에서는 시스템의 어떤 부분은 정상 동작하지만, 어떤 부분은 아닐 수도 있다는 것
부분장애는 비결정적(nondeterministic) ➔ 같은 조건에서도 결과가 매번 달라질 수 있음.
이런 비결정성과 부분 장애 가능성이 분산 시스템을 어렵게 만듬.

1-1. Cloud Computing and Supercomputing

대규모 컴퓨팅 구축 방법(철학)

고성능 컴퓨터
클라우드 컴퓨팅
위 두 철학의 중간

철학에 따라 결함 처리 방법이 다름

슈퍼 컴퓨터 (단일 노드에 가까움)
- 노드 하나에 장애가 나면, 모든 작업을 중단한다.
- 장애가 복구되면 중단 시점부터 다시 계산을 한다.
- 결론 : 부분 장애를 전체 장애로 확대해서 해결

분산 시스템이 동작하게 하려면...

부분 장애 가능성을 받아들이고, 소프트웨어에 내결함서 메커니즘을 넣어야 한다.
신뢰성 없는 구성 요소를 사용해 신뢰성 있는 시스템을 구축해야 함.

신뢰성 없는 구성 요소를 사용해 신뢰성 있는 시스템을 구축하기

개별 구성 요소가 가끔 오류를 내더라도, 상위 계층에서 보정·재전송·검증 같은 메커니즘을
추가하면 전체 시스템의 신뢰성을 끌어올릴 수 있다.

예를 들어, 무선 통신처럼 잡음으로 오류가 생길 수 있어도, 오류정정코드가 있으면 잘못된 비트를
감지·수정해 올바른 데이터로 복구할 수 있다. 또 IP는 패킷을 유실·지연·중복·순서 뒤바꿈할 수 있는
“신뢰할 수 없는” 프로토콜이지만, 그 위의 TCP가 유실된 패킷을 재전송시키고, 순서를 맞춰 재조립해
“더 신뢰성 있는” 연결처럼 보이게 한다.

하지만 한계는 있다. 오류정정코드가 처리할 수 있는 오류량에는 상한이 있고, TCP가 손실·중복은 해결해도
네트워크 지연 자체를 없애진 못한다. 그럼에도 이런 상위 계층의 설계 덕분에 낮은 수준의 잡다한 장애를 단순화해
다루기 쉬워지고, 남은 문제에 집중할 수 있게 된다.

❐ 2. 신뢰성 없는 네트워크 (Unreliable Networks)

인터넷과 데이터센터 내부 네트워크 대부분은 비동기 패킷 네트워크
이런 종류의 네트워크에서 노드끼리 메시지(패킷)을 보낼 수 있음.
하지만 네트워크는 메시지가 언제 도착할지 혹은 메시지 도착 여부를 보장하진 않음.
요청을 보내고 응답을 기다리는 동안 여러가지 문제가 발생할 수 있음.
1. 요청 손실
2. 요청이 큐에서 늦게 전송
3. 원격 노드에 장애 발생
4. 원격 노드의 응답이 늦음
5. 네트워크가 손실
다른 노드로 요청을 보내서 응답을 받지 못했다면 그 이유를 아는 것은 불가능함.
- 이런 문제를 다루는 흔한 방법은 타임아웃
- 근데 이것도 원격노드가 응답을 받았는지 여부는 알 수 없음.

2-1. 현실의 네트워크 결함 (Network Faults in Practice)

어떤 연구에서..
- 네트워크 장비를 중복 추가하는 것은 기대만큼 결함을 줄여주지 못한다는 것을 발견
- 즉, 하드웨어 중복만으로는 운영·설정 실수를 예방할 수 없어서 전체 장애율 개선에 한계가 있다.
암튼 다양한 이유로 네트워크 결함이 생김
- 소프트웨 어 업그레이드
- 상어 이슈 등등
결국 네트워크 결함은 일어날 수 있음! 피할 방법이 없다.
그렇다고 반드시 네트워크 결함을 견더내도록(tolerating) 처리할 필요는 없음.
- 그냥 네트워크에 문제가 있다고 사용자에게 보여주는 것도 타당한 방법
- 그러나 시스템이 복구될 수 있도록 보장해야 함

2-2. 결함 감지(Detecting Faults)

시스템은 결함 있는 노드를 자동으로 감지할 수 있어야 함.

예를 들면
- 로드 벨런서는 죽은 노드로 요청을 그만 보내야 한다.
- 단일 리더 복제를 사용하는 분산DB에서 리더에 장애가 나면 팔로워 중 하나가 리더로 승격돼야 한다.
근데 네트워크의 불확실성 때문에 노드가 동작 중인지 아닌지 구별하기 어려움.
- 원격 노드가 다운되고 있다는 피드백은 유용하지만 여기에 의존 할 수 없음.
- 일반적으로 아무 응답도 받지 못할 것이라 가정해야 함.
결국 몇번이고 다시 요청보내서 타임아웃 내에 응답받지 못하면, 마침내 노드가 죽었다고 선언할 수 있음.

2-3. 타임아웃과 기약 없는 지연 (Timeouts and Unbounded Delays)

타임 아웃은 얼마나 길어야 될까?

답이 없음.
노드가 일시적으로 느려졌을 뿐인데, 죽었다고 잘못 선언할 위험이 있음.
- 노드가 죽었다고 선언되면, 다른 노드가 죽은 노드의 일도 해야 됨.
- 근데 너무 성급하게 죽었다고 선언하면
- 다른 노드가 과부하고 응답이 느려질 수 있음.(최악의 경우 죽음)
타임 아웃이 낮으면
- rtt(round-trip time)가 순간적으로 급증하기만 해도 시스템 균형이 깨짐

패킷의 최대 지연 시간이 보장된 네트워크를 사용하는 경우

모든 패킷은 전송 시간이 d 보다 더 걸리지 않음.
장애가 나지 않은 노드는 항상 요청을 r 시간 내에 처리한다고 가정
그렇다면 2d+r을 타임아웃으로 사용하는게 합리적

유감스럽게도 대부분의 시스템은 위와 같은 상황을 보장하지 않음!

비동기 네트워크는 기약 없는 지연(unbounded delay)가 있고, 요청을 특정 시간 내에 처리한다고 보장 못함.

네트워크 혼잡과 큐대기

네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많음.
1. 네트워크 혼잡 (network congestion)
2. CPU 코어가 바쁜 경우 큐에서 댇기
3. 가상 환경에서 실행되는 운영체제
4. TCP의 흐름 제어(flow control)
TCP는 타임아웃 내에 확인 응답을 받지 못하면 패킷이 손실됐다고 간주
- 그리고 손실된 패킷은 자동으로 재전송 ➔ 지연에 한 몫함

타임아웃 대안책 : 파이 증가 장애 감지기 (Phi Accrual failure detector)

고정된 타임아웃을 설정하는 대신
- 시스템이 지속적으로 응답 시간과 변동성(jitter)을 측정하고
- 관찰된 응답 시간 분포에 따라 타임아웃을 자동으로 조절하게 하는 방안

2-4. 동기 vs 비동기 네트워크 (Synchronous Versus Asynchronous Networks)

하드웨어에서는 왜 네트워크를 신뢰성 있게 만들 수 없을까?

고정 회선 전화 네트워크와 데이터센터 네트워크를 비교해보자.
전화 네트워크 (동기식)
- 극단적인 신뢰성 (음성 프레임이 지연되거나 통화가 유실되는 일은 매우 드뭄)
- 회선(circuit)이 만들어짐 ➔ 통화가 끝날때 까지 유지
- 두 명 사이에 있는 전체 경로를 따라서 그 통화에 대해 고정되고 보장된 양의 대역폭이 할당
- 데이터가 라우터를 거치더라도, 큐 대기 문제를 겪지 않음. (동기식)
  - 네트워크 종단 지연 시간의 최대치가 고정돼 있음
  - 이를 제한 있는 지연(bounded delay)라고 함.

그냥 네트워크 지연을 예측 가능하게 만들 수는 없을까?

전화 네트워크	데이터센터 네트워크
그 누구도 사용할 수 없는 회선을 사용함	가용 네트워크 대역폭을 기회주의 적으로 사용
회선이 구성됐을 때 왕복 시간의 최대치를 보장	큐 대기의 영향을 받는 패킷 교화 프로토콜(기약 없는 지연)
초당 비트 개수가 상당히 고정되어 있음.	순간적으로 몰리는 트래픽(bursty traffic)에 최적화

지연 시간과 자원 사용률

자원이 정적으로 분할된다면 어떤 환경에서는 지연 시간을 보장할 수 있지만, 사용률이 떨어짐.
반대로 동적으로 자원을 분할하면 사용률을 높여 비용은 줄이지만 자원 변동이 큼.

❐ 3. 신뢰성 없는 시계 (Unreliable Clocks)

두 가지 관점
1. 지속 시간 (Durations)
2. 시점 (Points in time)
분산환경에서 통신은 즉각적이지 않기 때문에 다루기 까다로움.

3-1. 단조 시계 vs 일 기준 시계 (Monotonic Versus Time-of-Day Clocks)

일 기준 시계 (Time-of-Day Clocks)

특정 달력에 따라 현재 날짜와 시간을 반환
- ex. 2025-10-13 21:34:12.123 KST
벽시계 시간(wall-clock time)이라고도 함.
NTP(Network time protocol)로 동기화
- 한 장비의 timestamp는 다른 장비의 timestamp와 동일한 의미를 지닌다는 뜻

'일 기준 시계'는 이상한 점

시계 점프 (clock jump)
- NTP 보정 시 시계가 과거로 되돌아가거나 순간적으로 뛰는 현상 발생 → 경과 시간 측정에 부적합
윤초(leap second)
- 지구 자전의 불규칙성으로 인해 발생하는 시간 차이를 보정하기 위해
  협정 세계시(UTC)에 1초를 더하거나 빼서 시간을 조정하는 것
- 윤초 반영이 불완전해 시계가 실제 시간과 미묘하게 어긋날 수 있음
낮은 해상도(coarse-grained)
- 과거 시스템은 10ms 단위로만 시간 갱신 → 세밀한 타이밍 측정 불가

단조 시계 (Monotonic)

지속 시간(시간 구간)을 재는데 접합한 시계
- ex. 32500523123ns, 523.411s
해상도가 상당히 좋음
- 시간 구간을 마이크로초나 그 이하 단위로 측정할 수 있음.
분산 시스템에서 단조 시계는 나름 good
1. 다른 노드의 시계 사이에 동기화가 돼야 한다는 가정이 없고,
2. 측정이 약간 부정확해도 민감하지 않기 때문
한 시점에서 단조 시계 값을 기록하고, 일정 일을 한 후 나중에 다시 값을 확인하면
➔ 두 값의 차이로 경과 시간을 구할 수 있음.
단조 시계의 절대적인 값 자체는 의미 없음. 단지 두 시점 사이의 차이가 의미를 가짐.
따라서 “이 값이 실제 시간 몇 시인가?” 같은 질문에는 사용할 수 없다.

다중 CPU 환경에서 단조 시계

여러 CPU 소켓이 있는 서버의 각 CPU는 독립된 타이머를 가질 수 있음.
운영체제는 여러 CPU에서 실행되는 스레드 간의 시간 차이를 줄이기 위해 단조적으로 보이게 하려고 노력
하지만 완벽한 단조성 보장은 불가능

NTP와 단조 시계

NTP는 단조 시계가 진행하는 진도수를 조정할 수 있음 - 시계를 돌린다(slewing)라고 함
- 컴퓨터의 로컬 시계가 NTP 서버 보다 빠르거나 느리다는 것을 발견했을 때
NTP가 조절할 수 있는 범위는 0.05%
- 단, 단조 시계가 앞이나 뒤로 뛰게 할 순 없음. (시간 점프 X)

3-2. 시계 동기화와 정확도 (Clock Synchronization and Accuracy)

시계 동기화

단조 시계는 동기화가 필요 없음.
일 기준 시계는 NTP 서버나 다른 외부 시간에 맞춰 설정돼야 유용함.

시계가 정확한 시간을 알려주게 하는 방법은 신뢰성이 높지 않음.

컴퓨터의 quartz(석영) 시계는 아주 정확하지 않음.
- 드리프트(drift) 현상이 생김 : 더 빠르거나 느리게 실행되는 현상
- 드리프트는 장비의 온도에 영향을 받음.
컴퓨터 시계가 NTP 서버와 차이가 많이 나면, 동기화 거부 또는 로컬 시계 강제 리셋 가능성 있음.
윤초가 발생하는 경우
가상화 된 하드웨어
완전히 제어할 수 없는 장치에서 소프트웨서 실행하는 경우
등등...

3-3. 동기화된 시계에 의존하기 (Relying on Synchronized Clocks)

시계도 완벽하지 않다!

네트워크와 마찬가지로 시계도 결함이 생길 수 있다는 가정하에 설계되어야 하며, 대비되어야 함
동기화된 시계가 필요한 소프트웨어는 필수적으로 시계를 모니터링 해야 함.
- 이렇게 함으로써 시계에 문제가 있음을 알아차려야 함.

이벤트 순서화용 타임스탬프 (Timestamps for ordering events)

여러 노드에 걸친 이벤트들의 순서를 정하는 경우
- LWW(Last Write Win)라고 배웠음.
- 이때 "최근"의 정의는 '로컬-일 기준 시계'에 의존하면 틀릴 수도 있음!!
그래서 순서가 보장되도록 NTP 동기화를 정확히 할 수 있나? 불가능
하지만 대안책은 있음.
- 카운터를 기반으로하는 논리적 시계(Logical clock)
- 논리적 시계는 오직 이벤트의 상대적인 순서만 측정.

시계 읽기는 신뢰 구간이 있다. (Clock readings have a confidence interval)

불확실성 경계는 시간 출처(time source)를 기반으로 계산할 수 있음.
- 불확실성 = 동기화 후 드리프트 오차 + NTP 서버의 오차 + RTT
아쉽게도 대부분 시스템은 불확실성을 노출하지 않음.
- `clock_gettime()`은 해당 타임스탬프의 예상 오차 범위를 말해주지 않음.
구글의 트루타임(TrueTime) API는 로컬 시계의 신뢰 구간을 명시적으로 보고함.
- 반환 값 : [earliest, latest]

전역 스냅숏용 동기화된 시계 (Synchronized clocks for global snapshots)

스패너(Spanner)
- 트루타임 API가 보고한 시계 신뢰 구간을 사용하여 스냅숏 구현한다.
- 두 개의 신뢰 구간이 있는데, 두 구간이 겹치지 않는다면 B는 분명히 A보다 나중에 실행 된 거임
- 읽기 쓰기 트랜잭션을 커밋하기 전에 의도적으로 신뢰 구간 길이만큼 기다린다.
  ➔ 트랜잭션 타임스탬프가 인과성을 반영하는 것을 보장하기 위함임.
  ➔ 이렇게 하면, "데이터를 읽을 지도 모를 트랜잭션"이 충분히 나중에 실행되는게 보장됨
  ➔ 대기 시간을 가능하면 짧게 유지하기 위해, 스패너는 시계 불확실성을 가능하면 작게 유지해야 함.

3-4. 프로세스 중단 (Process Pauses)

임차권 (lease)

다른 노드들에게 리더가 죽었다고 알 수 있게 해주는 방법 중 하나
타임아웃이 있는 잠금과 비슷함.
임차권을 획득한 노드는 임차권이 만료될 때까지 본인이 리더임을 알 수 있음.

// 아래 코드의 문제점은?
while (true) {
    val request = getIncomingRequest()

    // 항상 임차권이 적어도 10초는 남아 있게 보장한다
    if (lease.expiryTimeMillis - System.currentTimeMillis() < 10_000) {
        lease = lease.renew()
    }

    if (lease.isValid()) {
        process(request)
    }
}

동기화된 시계에 의존
- 임차권 만료 시간(lease.expiryTimeMillis)가 다른 장비에서 설정됐는데 로컬 시계랑 비교함.
- 동기화가 깨지게 되면, 이 코드는 더 이상 기대했던대로 동작안함.
프로그램 실행 중에 예상치 못한 중단이 있는 경우
- `lease.isValid()` 줄 근처에서 15초 동안 멈춘다면?
- 요청이 처리되는 시점에 임차권이 만료됐을 수 있음. (하지만 만료 됐음을 알 수 있는 방법이 없음...)
쓰레드가 아주 오랫동안 멈출 경우도 가정할 수 있음.
- 아래와 같은 문제가 생기면, 선점 된 쓰레드는 자신이 잠시 멈췄던 사실을 모름.
  - "stop-the-world" GC가 동작하는 경우
  - 가상 장비가 "suspend" 됐다가 다시 "resume" 되는 경우
  - 운영체제가 다른 스레드로 컨텍스트 스위치하는 경우
  - 하이퍼바이저가 다른 가상 장비로 스위치되는 경우
  - 느린 디스크 I/O 작업이 있는 경우 (ex. 페이지 폴트, 스와핑 등등)

응답 시간 보장

노력하면 위에서 말했던 기약 없는 시간동안의 중단의 원인을 제거할 수 있음.
어떻게? 데드라인 설정
- 데드라인을 만족시키지 못하면 전체 시스템 장애를 유발할 수 있음.
- 이를 이른바 엄격한 실시간 시스템(hard real-time systems)이라고 함.

실시간 시스템

웹에서 실시간이란?
- 서버가 클라이언트에게 데이터를 푸시하고 엄격한 응답 시간 제약 없이
  스트림 처리하는 것을 나타냄
실시간을 보장하려면?
- "실시간 운영체제(RTOS)"가 필요함
대부분 서버측 데이터 처리 시스템에서 실시간 보장은 경제적이지도 적절하지도 않음.
- 결과적으로 고통 받을 수 밖에 없음.

가비지 컬렉션의 영향을 제한하기 (Limiting the impact of garbage collection)

GC로 인한 중단을 노드가 중단되는 것으로 간주하고,
노드가 GC를 하는 동안, 다른 노드가 클라의 요청을 처리
- 이 방법은 GC로 인한 중단을 클라한테 감추고 응답 시간을 줄여줌.
- 지연 시간에 민감한 금융 거래 시스템에서 이 방법을 쓰는 곳도 있음.
(방법1의 변형)
- 수명이 짧은 객체만 가비지 컬렉터를 사용하고, 수명이 긴 객체는 GC가 돌기전에 프로세스 재시작

➔ 이 방법들이 GC로 인한 중단을 완전히 막을 순 없지만, 애플리케이션에 유의미한 영향을 미칠 수 있음.

❐ 4. 지식, 진실 그리고 거짓말 (Knowledge, Truth, and Lies)

4-1. 진실은 다수결로 결정된다.

분산 시스템은 한 노드에만 의존할 수 없음.
대신 여러 분산 알고리즘은 정족수(quorum), 즉 노드들 사이의 투표에 의존한다.
정족수를 이룬 노드들이 다른 노드를 죽었다고 선언하면, 그 노드는 (살아있더라도) 진짜 죽은거
노드의 과반수 이상을 정족수로 삼는게 가장 흔함.
과반수 정족수를 사용하면 개별 노드들에 장애가 나더라도 시스템은 계속 동작

리더와 잠금

오직 하나만 필요한 상황의 예시
- 리더 선출
- 자원 잠금
- 유일한 사용자 등록
분산 시스템에서 이런 상황을 구현하려면 중의해야 함.
- A 노드가 스스로를 유일한 노드라고 믿어도, 네트워크 끊겼거나 GC 중단의 이유로
  다른 노드들이 동의하지 않을 수 있음.
- 즉, 다른 노드들이 A가 죽었다고 생각해서, 그들끼리 리더를 선출했을 수 있음.

HBase 사례: 잠금을 잘못 구현해서 생긴 데이터 오염 버그
- 원인 : 잠금을 잘못 구현해서, GC 중단으로 인해서 클라1이 임차권이 유효하다고 판단
- 결과 : 쓰기 충돌, 데이터 오염

팬싱 토큰

HBase 같은 사례의 해결 방법 : 펜싱(fencing)
잠금 서버가 잠금이나 임차권을 승인할 때마다 펜싱 토큰도 반환한다고 가정
- 펜싱토큰 : 잠금이 승인될 때마다 증가하는 숫자
메커니즘 : 자원 자체가 이미 처리된 것보다 오래된 토큰을 사용해서 쓰는 것을 거부함
잠금 서비스로 주키퍼를 사용하면 트랜잭션id나 노드 버전을 펜싱 토큰으로 사용할 수 있음.

4-2. 비잔틴 결함(Byzantine fault)

비잔틴 결함 & 비잔틴 장군 문제

비잔틴 결함 ➔ 노드가 실제로 받지 않은 특정 메시지를 받았다고 주장하는 것
비잔틴 장군 문제 ➔ 신뢰할 수 없는 환경에서 합의해 도달하는 문제
- 두 장군 문제를 일반화 한 것
- 거짓 메시지나 악의적 행위가 존재할 때 신뢰를 유지할 수 있는가?

비잔틴 내결함성을 지난다.

일부 노드에 문제가 있더라도, 시스템이 올바르게 동작하는 시스템을 일컫는 말
이런 환경(비행 제어 시스템, 비트코인, 피어투피어 네트워크)에서 유의미함.

웹 애플리케이션에서는 클라이언트의 행동이 임의적이고 악의적이라고 예상해야 함.

SQL injection, cross site scripting 막아야 함.
근데 이걸 하기위해서 비잔틴 내결함성 프로토콜을 쓰진 않음. 그냥 서버에서 처리

약한 형태의 거짓말

"거짓말"로 부터 보호해주는 메커니즘을 소프트웨어에 추가하는게 가치가 있을 수 있음.
근데 이런 보호 메커니즘이 비잔틴 내결함성을 지니진 않음. 그래도 할 가치는 있음.
1. 네트워크 오염 문제
  - 애플리케이션 레벨에서 별도의 체크섬 검증을 추가
2. 애플리케이션 입력 검증
  - 입력한 값 검증하기
3. NTP
  - 여러 서버를 비교하여 이상치 제거

4-3. 시스템 모델과 현실

알고리즘 작성 방법

그들이 실행되는 하드웨어와 소프트웨어 설정의 세부 사항에 너무 심하게 의존하지 않는 방식으로 작성해야 함.
이렇게 하기 위해서는 시스템엣어 발생할 것으로 예상되는 결함의 종류를 정형화 해야 함.

타이밍 가정에 대해서 흔히 사용되는 시스템 모델

동기식 모델
- 네트워크 지연, 프로세스 중단, 시계 오차가 모두 제한되어 있음
- 거의 비현실적
- 이상적인 환경 가정. 현실 시스템에는 존재하지 않음
부분 동기식 보델
- 대부분의 시간에는 정상(동기식처럼 작동)하지만, 가끔 지연이나 중단이 발생할 수 있음
- 현실적
- 현실 분산 시스템이 가장 근사한 모델
비동기식 모델
- 시간의 개념이 없거나 예측 불가능 (시계가 없을 수도 있음)
- 이론적
- 설계가 가능하지만 매우 제한적

가장 널리 쓰이는 세 가지 노드용 시스템 모델

죽으면 중단(crash-stop)
- 노드가 한 번 죽으면 다시는 복구되지 않음
- 단순 시뮬레이션 환경, 임베디드 시스템
죽으면 복구(crash-recovery)
- 노드가 죽었다가 나중에 다시 살아남 (디스크 등 비휘발성 저장소는 유지)
- 대부분의 현실 시스템
비잔틴(임의적) 장애(Byzantine Fault)
- 노드가 거짓 정보, 오류 메시지, 잘못된 결과를 반환할 수 있음
- 악의적 공격, 하드웨어 결함, 버그 등

알고리즘의 정확성

알고리즘이 정확하다(correct)는 게 어떤 의미인지 정의하기 위해 알고리즘의 속성을 기술할 수 있다.
예를 들어 펜싱 토큰을 생성한다면...
- 유일성
- 단조 일련번호
- 가용성
그런데 노드가 다 죽거나, 무한 네트워크 지연이면 알고리즘도 아무것도 못함.

안전성과 활동성

➔ 안전성과 활동성 속성을 구별하면 어려운 시스템 모델을 다루는데 도움이 됨.

안전성
- 유일성, 단조 일련번호
- 나쁜 일이 일어나지 않는다.
- 안전성 속성이 위반되면, 그 속성이 깨진 특정 시점을 가리킬 수 있다.
- 안전성 속성이 위반된 후에는 그 위반을 취소할 수 없다. (이미 손상됨)
- 분산 알고리즘은 시스템 모델의 모든 상황에서 안전성 속성이 항상 만족되기를 기대
활동성
- 가용성
- 그 정의에 "결국에(eventually)" 이라는 단어를 포함하는 것
- 좋은 일은 결국 일어난다
- 안전성과 반대로 동작(특정 시점 못찾지만, 미래에는 만족시킬 수 있음)
- 분산 알고리즘은 시스템 모델의 모든 상황에서 활동성 속성에 대해서는 경고를 하는게 허용됨.

시스템 모델을 현실 세계에 대응시키기

이론은 단순하지만, 현실에서는 복잡함.
- 이론적 모델만으로는 불완전하며, 예상치 못한 상황을 처리하는 “실제 코드”가 필수.
- 즉, “불가능한 일이 실제로 일어나면 어떻게 대응할지까지 설계해야 한다” 는 의미.
알고리즘이 올바르다고 증명됐더라도 반드시 현실 시스템에서의 구현도
언제나 올바르게 동작한다고 단정 지을 수 없음.

구분	이론적 가정	현실에서의 문제
Crash-Recovery 모델	노드가 죽더라도 디스크의 데이터는 안전하게 남아 있음	디스크 오염, 펌웨어 버그, 하드웨어 인식 실패 등으로 데이터 손실 가능
정족수(Quorum) 알고리즘	“기억하고 있다”는 노드의 선언을 신뢰	노드가 이전 데이터 잊어버릴 수 있음 → 정확성 깨짐
비잔틴이 아닌(non-Byzantine) 가정	노드가 악의적 행동은 하지 않음	실제로는 버그, 하드웨어 결함 등으로 예상치 못한 행동 가능

Common Batch Patterns

gilbert9172 — Fri, 10 Oct 2025 18:51:41 +0900

일부 배치 작업은 Spring Batch에서 제공하는 기성(ready-made) 컴포넌트만으로도 구성할 수 있다.
예를 들어, ItemReader와 ItemWriter 구현체들은 매우 다양한 시나리오를 커버할 수 있다.
하지만 실무에서는 완벽히 일치하지 않는 요구사항이 많기 때문에, 일부 구간(특히 쓰기/처리)은
직접 구현해야 할 수도 있다.

이 장에서는 커스텀 비즈니스 로직에서 자주 사용되는 몇 가지 공통 패턴의 예시를 제공한다.
이러한 예시들은 주로 Listener 인터페이스를 활용한 것들이다.
또한, 필요하다면 ItemReader나 ItemWriter도 Listener 인터페이스를 직접 구현해야 할 수도 있다.

❐ 1. Logging Item Processing and Failures

Step 내에서 아이템별로(error item-by-item) 에러를 특별히 처리해야 하는 경우

(StepFactoryBean으로 생성되는) chunk-oriented Step은 이러한 요구를 간단히 처리할 수 있도록
ItemReadListener(읽기 에러 처리용)와 ItemWriteListener(쓰기 에러 처리용)를 제공한다.

@Bean
fun job(): Job {
    return JobBuilder("sampleStep", jobRepository)
        ...
        .listener(ItemFailureLoggerListener())
        .build()
}

class ItemFailureLoggerListener : ItemListenerSupport<Any, Any>() {

    companion object {
        private val logger: Log = LogFactory.getLog("item.error")
    }

    override fun onReadError(ex: Exception) {
        logger.error("Encountered error on read", ex)
    }

    override fun onWriteError(ex: Exception, items: MutableList<out Any>?) {
        logger.error("Encountered error on write", ex)
    }
}

에러 로깅/보정 처리는 메인 트랜잭션과 분리해서 커밋하자!

Chunk 기반 Step에서는 처리/쓰기 단계에서 예외가 나면 현재 트랜잭션이 롤백됨.
이때 리스너(onWriteError, onProcessError 등)에서 DB에 에러 로그를 남기면?
➔ 그 로그도 같이 롤백되어 사라질 수 있음!
따라서, 트랜잭션 전파 수준을 REQUIRES_NEW로 지정하는 방법을 추천!

❐ 2. Stopping a Job Manually for Business Reasons

2-1. Exception 던지기

class PoisonPillItemProcessor<T> : ItemProcessor<T, T> {

    override fun process(item: T): T? {
        if (isPoisonPill(item)) {
            throw PoisonPillException("Poison pill detected: $item")
        }
        return item
    }

    private fun isPoisonPill(item: T): Boolean {
        // 예: "STOP" 문자열을 만나면 종료
        return item == "STOP"
    }
}

class PoisonPillException(message: String) : RuntimeException(message)

exception을 던저서 배치 종료

2-2. NULL 반환하기

class EarlyCompletionItemReader<T>(
    private val delegate: ItemReader<T>
) : ItemReader<T> {

    override fun read(): T? {
        val item = delegate.read() ?: return null
        return if (isEndItem(item)) null else item
    }

    private fun isEndItem(item: T): Boolean {
        // 예: 특정 값이 나오면 종료
        return item == "STOP_SIGNAL"
    }
}

ItemReader가 null을 반환하면 batch 완료로 간주

2-3. Custom CompletionPolicy 구현하기

CompletionPolicy

public class StepBuilder extends StepBuilderHelper<StepBuilder> {

    public <I, O> SimpleStepBuilder<I, O> chunk(
        int chunkSize, 
        PlatformTransactionManager transactionManager
    ) {
        return new SimpleStepBuilder<I, O>(this).transactionManager(transactionManager).chunk(chunkSize);
    }
    
    public <I, O> SimpleStepBuilder<I, O> chunk(
        CompletionPolicy completionPolicy,
        PlatformTransactionManager transactionManager
    ) {
        return new SimpleStepBuilder<I, O>(this).transactionManager(transactionManager).chunk(completionPolicy);
    }
    
    //...
}

CompletionPolicy는 청크(chunk)가 언제 끝날지를 판단하는 전략
위 소스는 StepBuilder의 chunk 메소드
이 중 두 번째 메소드를 보면 알겠지만, completionPolicy를 파라미터로 입력 받음

예제 코드

@Bean
fun stepWithTimeLimitPolicy(): Step {
    return StepBuilder("timeLimitedStep", jobRepository)
        .chunk<String, String>(SpecialCompletionPolicy(limit = 5, maxDurationSeconds = 10), platformTransactionManager)
        .reader(reader())
        .writer(writer())
        .build()
}

/**
 * SpecialCompletionPolicy
 * - 5개 아이템을 처리하거나
 * - 특정 아이템("STOP")을 만나거나
 * - 10초가 경과하면 청크를 종료
 */
class SpecialCompletionPolicy(
    private val limit: Int = 5,
    private val maxDurationSeconds: Long = 10
) : CompletionPolicy {

    private var counter = 0
    private var complete = false
    private var startTime: Instant? = null

    override fun start(context: RepeatContext): RepeatContext {
        counter = 0
        complete = false
        startTime = Instant.now()
        return context
    }

    override fun update(context: RepeatContext) {
        counter++
    }

    override fun isComplete(context: RepeatContext): Boolean {
        val elapsedSeconds = Duration.between(startTime, Instant.now()).seconds
        return counter >= limit || complete || elapsedSeconds >= maxDurationSeconds
    }

    override fun isComplete(
        context: RepeatContext,
        result: RepeatStatus
    ): Boolean {
        return isComplete(context)
    }

    fun markComplete() {
        complete = true
    }
}

2-4. StepExecution에 flag 설정하기

@Component
class TerminateOnPoisonReadListener : ItemReadListener<Any>, StepExecutionListener {

    private lateinit var stepExecution: StepExecution

    override fun beforeStep(stepExecution: StepExecution) {
        this.stepExecution = stepExecution
    }

    override fun afterRead(item: Any) {
        if (isPoisonPill(item)) {
            // Step 중단 플래그 설정 → 이후 프레임워크가 JobInterruptedException 발생
            stepExecution.setTerminateOnly()
        }
    }

    override fun afterStep(stepExecution: StepExecution) = stepExecution.exitStatus

    private fun isPoisonPill(item: Any): Boolean =
        item == "STOP" // 예: 포이즌 신호
}

@Bean
fun stepWithTerminateFlag(): Step = StepBuilder("terminateFlagStep", jobRepository)
    .chunk<String, String>(10, transactionManager)
    .reader(reader())
    .writer(writer())
    .listener(TerminateOnPoisonReadListener())
    .build()

특정 신호(포이즌)나 외부 조건을 만나면 즉시 중단해야 할 때 사용 (결과는 비정상 종료)
정상적으로 끝내고 싶으면 CompletionPolicy를 구현

❐ 3. Adding a Footer Record

Footer 달기

파일 쓰기 작업 후에 Footer(하단에 고정으로 나와야 하는 그런거)가 필요한 경우
Spring Batch에서는 FlatFileFooterCallback 인터페이스를 제공해줌.

@Bean
fun itemWriter(outputResource: Resource): FlatFileItemWriter<String> =
    FlatFileItemWriterBuilder<String>()
        .name("itemWriter")
        .resource(outputResource)
        .lineAggregator(lineAggregator())   // LineAggregator<String>
        .headerCallback(headerCallback())   // FlatFileHeaderCallback
        .footerCallback(footerCallback())   // FlatFileFooterCallback
        .build()

인터페이스 정의

public interface FlatFileFooterCallback {
    void writeFooter(Writer writer) throws IOException;
}

3-1. Writing a Summary Footer

출력 과정에서 정보를 집계(aggregate)해 파일 끝에 붙이는 Footer 레코드가 필요한 경우가 흔함.
이 footer는 보통 파일의 요약 정보를 제공하거나 체크섬(checksum)을 제공하는 용도로 사용됨.

@Bean
public TradeItemWriter tradeItemWriter() {
	TradeItemWriter itemWriter = new TradeItemWriter();

	itemWriter.setDelegate(flatFileItemWriter(null));

	return itemWriter;
}

@Bean
public FlatFileItemWriter<String> flatFileItemWriter(Resource outputResource) {
	return new FlatFileItemWriterBuilder<String>()
			.name("itemWriter")
			.resource(outputResource)
			.lineAggregator(lineAggregator())
			.footerCallback(tradeItemWriter())
			.build();
}

class TradeItemWriter(
    private val delegate: ItemWriter<Trade>
) : ItemWriter<Trade>, FlatFileFooterCallback {

    private var totalAmount: BigDecimal = BigDecimal.ZERO

    override fun write(items: Chunk<out Trade>) {
        // 1) 이번 청크의 합계를 먼저 산출
        var chunkTotal = BigDecimal.ZERO
        for (trade in items) {
            chunkTotal = chunkTotal.add(trade.amount)
        }

        // 2) 실제 쓰기 시도 (여기서 예외나 skip이 나면 totalAmount는 아직 증가하지 않음)
        delegate.write(items)

        // 3) 예외 없이 성공한 경우에만 누적 합계 갱신
        totalAmount = totalAmount.add(chunkTotal)
    }

    override fun writeFooter(writer: Writer) {
        writer.write(System.lineSeparator())
        writer.write("Total Amount Processed: $totalAmount")
    }
}

재시작 가능하게 ItemStream 으로 상태 저장

TradeItemWriter는 totalAmount를 내부 상태로 들고 있으므로 Step이 재시작 불가
재시작 가능하게 하려면 아래의 과정을 거쳐야함.
- ItemStream을 구현
- open에서 과거 값을 복원
- update에서 최신 값을 ExecutionContext에 저장
이렇게 하면 재시작 시 이전 지점부터 이어서 합계를 계속 누적할 수 있음.

@Bean
fun tradeWriter(fileWriter: FlatFileItemWriter<Trade>): StreamSafeTradeItemWriter {
    val writer = StreamSafeTradeItemWriter(fileWriter)
    fileWriter.setFooterCallback(writer) // footer 연결
    return writer
}

// reader,writer가 ItemStream이면 Step이 자동으로 open/update/close 호출
@Bean
fun step(): Step = StepBuilder("tradeExport", jobRepository)
    .chunk<Trade, Trade>(100, transactionManager)
    .reader(reader())
    .writer(writer())
    .build()

class StreamSafeTradeItemWriter(
    private val delegate: ItemWriter<Trade>
) : ItemWriter<Trade>, FlatFileFooterCallback, ItemStream {

    companion object {
        private const val KEY_TOTAL = "total.amount"
    }

    private var totalAmount: BigDecimal = BigDecimal.ZERO

    override fun write(items: Chunk<out Trade>) {
        // 이번 청크 합계를 먼저 계산
        var chunkTotal = BigDecimal.ZERO
        for (t in items) chunkTotal = chunkTotal.add(t.amount)

        // 실제 쓰기(예외 발생 시 totalAmount는 아직 안 늘림)
        delegate.write(items)

        // 성공 시에만 누적 합계 반영
        totalAmount = totalAmount.add(chunkTotal)
    }

    // ===== FlatFileFooterCallback =====
    override fun writeFooter(writer: Writer) {
        writer.write(System.lineSeparator())
        writer.write("Total Amount Processed: $totalAmount")
    }

    // ===== ItemStream (재시작 상태 저장/복원) =====
    override fun open(executionContext: ExecutionContext) {
        if (executionContext.containsKey(KEY_TOTAL)) {
            totalAmount = executionContext[KEY_TOTAL] as BigDecimal
        }
    }

    override fun update(executionContext: ExecutionContext) {
        executionContext.put(KEY_TOTAL, totalAmount)
    }

    override fun close() { /* no-op */ }
}

❐ 4. Driving Query Based ItemReaders

왜 Driving Query 접근법을 사용할까?

비관적 락의 문제
대규모 데이터셋의 cursor 문제

➔ 이러한 문제로 인해 키(주로 ID)를 기준으로 페이지 단위로 잘라서 반복 조회하는 Driving Query 방법 사용

Driving Query Job example

전체 행(row)을 가져오는 대신, ID 컬럼만 선택
이후 단계(Processor나 Writer 등)에서 이 ID를 이용해 필요한 데이터를 다시 조회하거나 처리함.

❐ 5. Multi-Line Records

docs 읽어보기

❐ 6. Executing System Commands

많은 배치 작업은 배치 내부에서 외부 명령(command)을 실행해야 하는 경우가 있음.
보통 이런 작업은 스케쥴러(cron 등)에서 따로 실행할 수 있지만...
- 이렇게 하면 Spring Batch의 실행 메타데이터(JobExecution, StepExecution)와 분리됨.
- 따라서, 일관된 관리가 어려워지는 단점이 발생함.
그래서 Spring Batch는 이를 쉽게 관리하기 위해 아래의 구현체를 제공해줌.
- Tasklet 구현체 중 하나인 SystemCommandTasklet

@Bean
public SystemCommandTasklet tasklet() {
    SystemCommandTasklet tasklet = new SystemCommandTasklet();

    // 실행할 명령어 (OS 명령)
    tasklet.setCommand("echo hello");

    // 명령어 실행 제한 시간 (밀리초 단위)
    tasklet.setTimeout(5000);

    return tasklet;
}

❐ 7. Handling Step Completion When No Input is Found

SpringBatch의 기본 동작

읽을 데이터가 없더라도, 예외를 터트리지 않음.
- "할 일이 없다"로 판단하고, 정상 종료(COMPLETED) 처리함.
기본 제공되는 모든 ItemReader 구현체도 이 방식을 따름

문제 상황

입력 데이터가 실제로 존재해야 하는데, 파일 이름이 잘못되는 등의 이유로 아무것도 읽히지 않는다면?
- 이런 경우에도 Step이 "정상 종료"로 기록됨.
- 근데 이렇게 되면 문제가 발생한 걸 인지하지 못하고 넘어갈 수 있음.

해결 방안: NoWorkFoundStepExecutionListener

SpringBatch는 이런 경우를 대비해, 입력이 없을 때 Step을 실패로 처리하도록 도와주는 구현체 제공
그것이 바로 NoWorkFoundStepExecutionListener

❐ 8. Passing Data to Future Steps

ExecutionContext의 역할

Step 간에 데이터를 전달해야 할 때는 ExecutionContext를 사용
ExecutionContext는 두 가지가 있으며,
- StepExecutionContext : Step 실행 중에만 유지되고, chunk 커밋마다 갱신
- JobExecutionContext : Job 전체 실행 동안 유지되며, 각 Step이 끝날 때 한 번씩 갱신
따라서, Step이 실행 중일 때는 모든 데이터를 StepExecutionContext에 저장해야 함.
- 그렇지 않고 JobExecutionContext에 저장하면?
  ➔ Step이 실패할 경우 해당 데이터는 영구 저장되지 않아 손실될 수 있음.

그래서 다른 Step으로 데이터 전달은 어떻게 할 수 있을까?

Step이 종료 후, StepExecutionContext에 있던 데이터를 JobExecutionContext로 승격(promote)
SpringBatch는 이걸 할 수 있게끔, ExecutionContextPromotionListener를 제공함

ExecutionContextPromotionListener 구현하기

ExecutionContext에 있는 데이터중에서 승격해야 하는 항목들의 key를 리스너에 설정해야 함.
또한 프로모션이 발생해야 하는 종료 코드(Exit Code) 패턴 목록을 선택적으로 설정할 수 있음.
- 기본적으로는 Step이 COMPLETED 되었을 때만 데이터가 승격
- 필요하다면, 추가적인 종료 코드 패턴(NO_WORK_FOUND, WARNING 등)을 설정해 둘 수도 있음.
- 기본값은 COMPLETED이며, 다른 모든 리스너와 마찬가지로 해당 Step에 등록해야 함.

Sample Code

@Configuration
class PromoteContextJobConfig(
    private val jobRepository: JobRepository,
    private val platformTransactionManager: PlatformTransactionManager,
    private val savingItemWriter: SavingItemWriter,
    private val retrievingItemWriter: RetrievingItemWriter,
    private val promotionListener: PromotionListener
) {

    // ====== Job ======
    @Bean
    fun job1(): Job =
        JobBuilder("job1", jobRepository)
            .start(step1())
            .next(step2())
            .build()

    // ====== Step1: 값 저장 + 승격 ======
    @Bean
    fun step1(): Step =
        StepBuilder("step1", jobRepository)
            .chunk<String, String>(3, platformTransactionManager)
            .reader(ListItemReader(listOf("A", "B", "C", "D", "E")))
            .writer(savingItemWriter)          // 처리 개수를 StepContext에 저장
            .listener(promotionListener.get()) // someKey 승격(JobContext로)
            .build()

    // ====== Step2: 승격된 값 사용 ======
    @Bean
    fun step2(): Step =
        StepBuilder("step2", jobRepository)
            .chunk<String, String>(1, platformTransactionManager)
            .reader(ListItemReader(listOf("F")))
            .writer(retrievingItemWriter)
            .build()
}

@Component
class SavingItemWriter : ItemWriter<String> {

    private lateinit var stepExecution: StepExecution

    @BeforeStep
    fun captureStepExecution(stepExecution: StepExecution) {
        this.stepExecution = stepExecution
    }

    override fun write(items: Chunk<out String>) {
        val stepCtx: ExecutionContext = stepExecution.executionContext
        var processed = stepCtx.getInt("someKey", 0)
        processed += items.size()                 // 이번 chunk에서 처리한 개수 누적
        stepCtx.putInt("someKey", processed)      // StepContext에 저장(→ Step 끝나면 승격)
        println("[step1] processed so far = $processed")
    }
}

@Component
class RetrievingItemWriter : ItemWriter<Any> {

    private var someObject: Any? = null

    @BeforeStep
    fun retrieveInterstepData(stepExecution: StepExecution) {
        val jobExecution: JobExecution = stepExecution.jobExecution
        val jobCtx: ExecutionContext = jobExecution.executionContext
        someObject = jobCtx.get("someKey")
        println("[step2] promoted value = $someObject")
    }

    override fun write(items: Chunk<out Any>) {
        // 실제 비즈니스 로직에서 someObject를 활용
    }
}

Retry

gilbert9172 — Fri, 10 Oct 2025 18:50:22 +0900

❐ Retry

Retry

Batch 처리에서 일시적인 오류(transient error) 때문에 전체 작업이 실패하는 걸 방지하기 위해,
자동 재시도(retry) 메커니즘을 제공한다.
예를 들어 이런 경우에 유용하다.
- 네트워크 일시 장애로 API 호출 실패
- DB Deadlock 발생 (DeadlockLoserDataAccessException)
- 외부 시스템 응답 지연
실패 시 바로 중단하지 않고 일정 횟수까지 재시도 하는 방식으로 안정성을 높인다.

Retry 기능의 분리

Spring Batch 2.2.0 이후, Retry 기능은 별도의 라이브러리로 분리됐다.
- 예전엔 RepeatTemplate 내부에서 Retry 로직을 직접 포함했지만
- 지금은 Spring Retry가 RetryTemplate, BackOff, Policy 등을 담당하고,
- Spring Batch는 단지 이를 통합해서 사용하는 구조예요.
즉, Spring Batch의 내부 Retry 동작은 실제로 Spring Retry의 API를 기반으로 동작한다.

소스코드

// RetryOperations.java
public interface RetryOperations {...}
  
// BatchRetryTemplate.java
public class BatchRetryTemplate implements RetryOperations {...}

// FaultTolerantStepBuilder.java
public class FaultTolerantStepBuilder<I, O> extends SimpleStepBuilder<I, O> {...}

Scaling and Parallel Processing

gilbert9172 — Fri, 10 Oct 2025 18:16:41 +0900

❐ 1. Multi-thread Step

앞에서 봄

❐ 2. Parallel Steps

앞에서 봄

❐ 3. Remote Chunk

Remote Chunk란?

Reader/Processor와 Writer를 서로 다른 프로세스(노드)로 분리해서 실행하는 구조
- 마스터 노드: 데이터를 읽고 나누어(Chunk 단위로) 전송
- 워커 노드: 전달받은 Chunk를 실제로 Write (DB 저장 등)

언제 효과적일까?

Manager 컴포넌트는 하나의 프로세스로 동작하고, worker는 여러 개의 원격 프로세스로 동작함
이 패턴은 Manager가 병목(bottleneck)이 되지 않을 때 가장 효율적
따라서, 아이템을 읽는 작업보다 처리 작업이 더 비싼 경우에 특히 효과적

Manager

Manager는 Spring Batch의 Step 구현체
청크(chunk) 단위의 아이템을 메시지 형태로 미들웨어(MQ 등)에 전송하는 일반화된 ItemWriter를 사용

➔ 즉, Manager는 일반적인 Step과 동일하게 동작하지만,

ItemReader → 데이터를 읽고
ItemProcessor → 데이터를 가공한 뒤
ItemWriter → 직접 DB에 쓰지 않고 메시지로 전송

@Bean
fun masterStep(): Step {
    return StepBuilder("masterStep", jobRepository)
        .chunk<String, String>(10, txManager)
        .reader(itemReader)
        .processor(itemProcessor)
        .writer(chunkMessageWriter) // DB X → MQ 전송
        .build()
}

Worker

Worker는 사용 중인 미들웨어(Message Broker) 에 맞는 표준 리스너(listener) 로 구현
- 예를 들어 JMS를 사용한다면, Worker는 MessageListener 구현체가 된다.
이들의 역할은
- 수신한 청크 데이터를 처리하는 것
- ChunkProcessor 인터페이스를 통해 표준 ItemProcessor 또는 ItemWriter를 사용하여 데이터를 처리

➔ 즉, Worker는 MQ로부터 메시지를 수신하고 그 내용을 “청크 단위로” 처리

Manager → MQ로 Chunk 전송
Worker → 메시지 수신 (MessageListener 역할)
Worker 내부에서는 → ItemProcessor, ItemWriter를 사용해 데이터를 처리 (예: DB 저장)

@Component
class WorkerMessageListener(
    itemWriter: ItemWriter<String>
) : MessageListener {

    private val chunkProcessor: ChunkProcessor<String> =
        SimpleChunkProcessor(null, itemWriter)

    override fun onMessage(message: Message) {
        val items: List<String> = extractItems(message)
        chunkProcessor.process(items)
    }
}

언제 효과적일까?

Manager 컴포넌트는 하나의 프로세스로 동작하고, worker는 여러 개의 원격 프로세스로 동작함
이 패턴은 Manager가 병목(bottleneck)이 되지 않을 때 가장 효율적
따라서, 아이템을 읽는 작업보다 처리 작업이 더 비싼 경우에 특히 효과적

부하 분산

아이템들은 동적으로 분할(dynamically divided)되어 미들웨어(Message Broker) 를 통해 분산
따라서 모든 리스너(Worker)가 적극적으로 메시지를 소비하는(eager consumer) 방식이라면,
- 자동으로 부하 분산(load balancing)이 이루어짐

❐ 4. Partitioning

Partitioning

Spring Batch는 Step execution을 분할해서 원격으로 실행할 수 있는 SPI도 제공
- 쉽게 말하면, Step 자체를 여러 개로 쪼개서 각각 다른 프로세스(또는 서버) 에서 실행
- SPI : Service Provider Interface
Worker들은 별도의 Step 인스턴스로 동작

Manager가 Worker에게 보내는 메시지는 내구성(durability), 전달 보장(guaranteed delivery)이 필요하지 않음.

메시지를 MQ에 반드시 영구 저장할 필요가 없다는 뜻
왜냐하면 Worker 실행은 Spring Batch의 JobRepository 메타데이터에 의해 관리되기 때문

이해하기 쉬운 예시
➔ 회원 테이블을 ID 기준으로 4개 구간으로 나누고, 각 구간을 다른 서버가 동시에 처리하고 싶다면?

Master
1. StepPartitioner가 4개의 Partition(1~2500, 2501~5000, …) 생성
2. PartitionHandler가 각 Partition을 원격 Worker로 전송
Workers
1. 각 서버에서 동일한 Step 실행 (SELECT * FROM members WHERE id BETWEEN ...)
2. 각각 결과 저장

Partitioning의 핵심 SPI 구조를 구성하는 3요소 이해하기

Spring Batch의 SPI의 구성
1. PartitionStep이라는 특별한 Step 구현체
2. 환경에 맞게 구현해야 하는 두 개의 전략 인터페이스
  - StepExecutionSplitter : Step을 여러 Partition으로 나누는 전략
  - PartitionHandler : 각 Partition을 분배하고 Worker에서 실행되게 하는 전략

4-1. PartitionHandler

Manager가 만든 각 StepExecution(파티션 단위 작업)을 실제로 Worker에게 전달하는 역할
- 멀티 스레드 방식으로 Step을 병렬 실행해주는 기본 PartitionHandler를 제공함
- 데이터를 어떻게 분할(Split) 할지, 또는 여러 Step 실행 결과를 어떻게 합칠(Aggregate) 지 알 필요 없음.
일반적으로 PartitionHandler는 복구(resilience) 나 장애조치(failover) 를 다룰 필요도 없음.
- 왜냐하면 이런 기능들은 대부분 사용 중인 메시징 시스템이나 그리드 플랫폼이 담당하기 때문
메시징이나 Worker 실패와 상관없이, 부분 재실행 가능
- JobRepository에 저장된 메타데이터를 기준으로 “어떤 파티션이 완료됐는지” 를 알고 있으므로
PartitionHandler 인터페이스는 다양한 환경에 맞게 구현할 수 있음.

4-2. Partitioner

Partitioner란?

새로운 StepExecution을 실행하기 위한 ExecutionContext를 생성하는 것
- 즉, "작업을 어떻게 나눌지”만 정의

인터페이스 정의

public interface Partitioner {
    Map<String, ExecutionContext> partition(int gridSize);
}

// "partition1" -> { startId=1, endId=1000 }
// "partition2" -> { startId=1001, endId=2000 }

gridSize
- 나눌 파티션 개수 (예: 4개라면 4개의 StepExecution 생성)
return Map
- key: 파티션 이름
- value: ExecutionContext (해당 파티션에서 사용할 변수들)

4-3. Binding Input Data to Steps

Partitioner가 생성한 ExecutionContext 데이터를 Step에 바인딩하는 방법

Spring Batch에서 Partitioning을 사용할 때, 각 파티션은 서로 다른 데이터를 처리해야 함.
예를 들어,
1. 파티션마다 다른 파일을 읽거나
2. 서로 다른 ID 구간을 처리하거나
3. 날짜별로 분리된 데이터를 다루거나
이때 핵심은 바로
- Partitioner가 생성한 ExecutionContext를 실제 Step의 Reader나 Writer에 동적으로 바인딩하는 것
Partitioner가 만든 ExecutionContext 데이터를 @StepScope Bean과 SpEL로 런타임에 바인딩하면
하나의 Step으로 여러 파티션 데이터를 유연하게 처리할 수 있다.

Item processing

gilbert9172 — Thu, 9 Oct 2025 00:48:20 +0900

❐ 1. Chaining itemProcessor

ItemProcessor로 부가적인 로직을 짤 수 있음.
근데 ItemProcessor를 체이닝을 걸어서 쓰고 싶다면?

@Configuration
class BatchConfig {

    @Bean
    fun ioSampleJob(jobRepository: JobRepository, step1: Step): Job =
        JobBuilder("ioSampleJob", jobRepository)
            .start(step1)
            .build()

    @Bean
    fun step1(
        jobRepository: JobRepository,
        transactionManager: PlatformTransactionManager
    ): Step =
        StepBuilder("step1", jobRepository)
            .chunk<Any, Any>(2, transactionManager)
            .reader(fooReader())
            .processor(compositeProcessor())
            .writer(foobarWriter())
            .build()

    @Bean
    fun compositeProcessor(): CompositeItemProcessor<Any, Any> =
        CompositeItemProcessor<Any, Any>().apply {
            setDelegates(listOf(FooProcessor(), BarProcessor()))
        }

    // 아래 메서드/클래스들은 실제 구현에 맞게 정의되어 있어야 합니다.
    fun fooReader() = /* ItemReader<Any> */ TODO()
    fun foobarWriter() = /* ItemWriter<Any> */ TODO()

    class FooProcessor : ItemProcessor<Any, Any> {
        override fun process(item: Any): Any? = /* transform */ item
    }

    class BarProcessor : ItemProcessor<Any, Any> {
        override fun process(item: Any): Any? = /* transform */ item
    }
}

나머지는 읽어보면 될듯.