Incremental(증분) 방식과 문제점 | Lambda | Kappa Architecture

 

1. 문제 상황

트래픽 증가 문제

페이지 조회 이벤트가 발생할 때마다 DB에서 view_count를 즉시 갱신하면 다음과 같은 문제들이 발생한다:

1. DB 부하 증가:
   • 매 이벤트마다 DB에 view_count + 1 업데이트 쿼리를 실행.
   • 트래픽이 증가할수록 데이터베이스의 I/O 작업이 많아져 병목 발생.
2. 성능 병목:
   • 다수의 사용자가 동시에 조회 요청을 보낼 경우, 처리 속도가 느려짐.
   • DB 서버의 성능이 낮거나 트래픽이 급증하는 경우에는 웹 서버까지 응답 속도가 느려짐.
3. 데이터 손실 위험:
   • 트래픽 과부하로 인해 DB가 요청을 처리하지 못하거나, 타임아웃이 발생하면 이벤트 데이터가 손실.

---

2. Incremental(증분) 방식의 원리

Incremental 방식은 데이터베이스와의 상호작용 빈도를 줄이고, 성능을 최적화하기 위해 다음 단계를 사용한다:

2.1 이벤트 큐(Queue) 활용

• 이벤트 발생 시 바로 DB를 갱신하지 않고, 큐(Queue)에 이벤트 정보를 저장한다.
• 큐는 메시지 브로커 시스템(예: RabbitMQ, Apache Kafka, Redis Streams)을 사용하여 이벤트 데이터를 안전하게 저장.

2.2 일괄 처리

• 큐에 일정량의 이벤트가 쌓이면(예: 100개) 이를 한 번에 묶어서 DB를 갱신.
• 한 번의 업데이트로 여러 이벤트를 처리하여 DB 부하를 최소화.

2.3 처리 흐름

1. 사용자 요청:
   • 페이지 조회 이벤트 발생 시 웹 서버는 즉시 응답하고, 이벤트 정보를 큐에 추가.
2. 큐에서 소비:
   • 소비자(Consumer)는 큐에서 일정량의 이벤트 데이터를 읽어 모음.
3. 일괄 업데이트:
   • Consumer는 읽은 이벤트 데이터를 집계하여 한 번의 DB 쿼리로 처리.

---

3. Incremental 방식의 장점

1. 성능 최적화:
   • 단건 처리 대신 이벤트 데이터를 묶어서 처리하므로, DB에 대한 요청 횟수를 줄임.
2. 데이터 손실 방지:
   • 큐에 데이터를 저장하므로 DB 부하나 타임아웃 상황에서도 데이터가 유실되지 않음.
3. 확장성:
   • 트래픽이 증가하면 큐와 Consumer의 수를 조정하여 시스템을 확장 가능.

---

4. 트래픽 증가에 따른 문제점

큐의 병목 현상

• 트래픽이 급증할 경우, 큐에 너무 많은 이벤트가 쌓여 처리 지연이 발생.
• 큐의 처리 속도가 소비자(Consumer) 속도를 초과하면 이벤트가 계속 대기 상태로 남게 됨.

---

5. 해결 방안

5.1 큐 병렬화

• 여러 Consumer를 병렬 실행하여 큐 처리 속도를 높임.
• 메시지 브로커 시스템 예:
  • RabbitMQ: 다중 Consumer 지원으로 메시지 처리 속도 증가.
  • Apache Kafka: 파티션 단위로 데이터를 분산 처리하여 대량의 이벤트를 병렬로 소비.

5.2 캐싱 레이어 도입

• 자주 조회되거나 수정되는 데이터를 DB 대신 캐시(예: Redis)에 저장.
• 작동 방식:
  • 페이지 조회 시, 캐시에서 view_count를 증가.
  • 캐시 데이터를 일정 주기(예: 5분)마다 DB와 동기화.
• 장점:
  • DB에 직접 접근하는 빈도를 줄이고, 응답 속도를 개선.

5.3 백프레셔(Backpressure) 적용

• 백프레셔는 큐의 과부하를 방지하기 위해, 생산자(Producer)가 데이터를 큐에 추가하는 속도를 조절.
• 과부하 발생 시:
  • 큐의 크기를 제한하여 추가 요청을 대기 상태로 전환.
  • 우선순위가 낮은 요청을 일시적으로 차단.

5.4 비동기 처리 강화

• 웹 서버에서 요청을 비동기로 처리하여 실시간성과 안정성을 분리.
• 비동기 메시징 프레임워크(예: Celery, Apache Pulsar)를 도입.

---

6. 예시

6.1 큐에 이벤트 추가 (Python + Redis)

import redis

# Redis 연결
redis_conn = redis.StrictRedis(host='localhost', port=6379, db=0)

# 이벤트 추가 함수
def add_event_to_queue(event_data):
    redis_conn.rpush("event_queue", event_data)
    print(f"Event added to queue: {event_data}")

6.2 큐에서 이벤트 처리 (Consumer)

import redis

# Redis 연결
redis_conn = redis.StrictRedis(host='localhost', port=6379, db=0)

# 이벤트 처리 함수
def process_events():
    while True:
        events = redis_conn.lrange("event_queue", 0, 99)  # 100개 이벤트 읽기
        if not events:
            break

        # 이벤트 처리
        for event in events:
            print(f"Processing event: {event.decode()}")

        # 처리한 이벤트 삭제
        redis_conn.ltrim("event_queue", len(events), -1)

6.3 캐싱 + DB 동기화

from redis import Redis

# 캐시 업데이트
redis_conn = Redis()
redis_conn.incr("view_count")  # 캐시에 `view_count` 증가

# 일정 시간마다 DB 동기화
def sync_cache_to_db():
    view_count = redis_conn.get("view_count")
    update_db(view_count)  # DB 갱신 함수 호출
    redis_conn.set("view_count", 0)  # 캐시 초기화

---

7. 결론

Incremental 방식은 데이터베이스 부하와 성능 병목 문제를 해결하는 효과적인 방법이다. 큐를 활용한 이벤트 처리와 캐싱 레이어를 결합하여 대규모 트래픽 상황에서도 안정적으로 동작하는 시스템을 구현할 수 있다.

---

 

 

 

 

■  Incremental(증분) 방식 문제점

 

view_count 테이블의 row 수 증가 문제

문제 상황:

• 트래픽 증가와 함께 view_count 테이블의 row 수도 급격히 증가한다.
• 대규모 데이터가 저장된 상태에서 조회 쿼리(GROUP BY)를 실행하면, DB는 많은 row를 스캔해야 하므로 쿼리 성능 저하가 발생.

GROUP BY 연산의 한계:

• 데이터베이스에서 GROUP BY 쿼리는 전체 row를 스캔하고 정렬하거나 해시 작업을 수행해야 하므로 연산 비용이 높음.
• 특히 row 수가 많아질수록 응답 시간이 길어지며, DB 모니터링 시스템에서 지속적으로 경고 및 에러 알람이 발생할 가능성이 높아짐.

---

Incremental 방식 - 확장성 문제 해결 방안

1. 캐싱(Cache) 사용

설명:

• 조회 및 업데이트 요청을 데이터베이스 대신 캐시(예: Redis, Memcached)에서 처리하여 DB 부하를 줄임.
• 캐시 데이터는 일정 주기마다 DB와 비동기 동기화.

적용 방법:

1. 읽기 요청:
   • view_count 값을 DB에서 가져오지 않고 캐시에서 조회.
2. 쓰기 요청:
   • 캐시에 view_count 값을 업데이트하며, 일정 시간 간격으로 누적 데이터를 DB에 반영.

장점:

• DB 부하 감소: 캐시는 메모리 기반이므로 데이터 접근 속도가 빠름.
• 확장성 강화: 캐시 클러스터를 사용하면 대규모 트래픽도 분산 처리 가능.

---

2. 메시지 큐(Message Queue) 기반 비동기 처리

설명:

• 트래픽 증가 시 즉시 DB를 갱신하지 않고, 이벤트를 메시지 큐(예: Kafka, RabbitMQ)에 저장한 후 비동기적으로 처리.

적용 방법:

1. 이벤트 프로듀서(Producer):
   • 웹 서버는 페이지 조회 이벤트를 메시지 큐에 전송.
2. 이벤트 소비자(Consumer):
   • 메시지 큐에 저장된 이벤트 데이터를 읽어 집계 처리 후 DB에 업데이트.

장점:

• 실시간 DB 업데이트 감소: 이벤트를 모아 일괄 처리.
• 확장성 강화: 트래픽 증가에 따라 Consumer 인스턴스를 추가.

---

3. OLAP(Online Analytical Processing)과 OLTP(Online Transaction Processing) 분리

설명:

• OLTP(DB의 실시간 데이터 처리)와 OLAP(통계 및 분석)를 분리하여 조회 쿼리의 성능 문제를 해결.

적용 방법:

1. OLTP DB:
   • 실시간 view_count 업데이트를 처리.
2. OLAP DB 또는 데이터 웨어하우스:
   • 정기적으로 OLTP 데이터를 ETL(추출, 변환, 적재)하여 조회 쿼리 수행.

장점:

• 조회 쿼리 성능 개선: OLAP DB는 대량 데이터를 효율적으로 처리.
• DB 부하 분산: OLTP와 OLAP 간 역할을 분리하여 각 작업의 효율성을 최적화.

---

4. Sharding(샤딩) 도입

설명:

• 테이블을 여러 개의 샤드(Shard)로 분리하여 데이터 저장소를 수평 확장.

적용 방법:

1. view_count 테이블을 특정 기준(예: 페이지 ID, 사용자 ID)으로 나누어 저장.
2. 트래픽 및 row 수를 각 샤드로 분산.

장점:

• 수평 확장 가능: 샤드 개수를 증가시켜 트래픽과 데이터 증가에 대응.
• 쿼리 성능 개선: 각 샤드에서 병렬로 작업 처리.

---

5. 데이터 아키텍처 모니터링 및 최적화

백프레셔(Backpressure):

• 트래픽 폭증 시 요청 속도를 제한하거나, 우선순위 처리로 안정성 확보.

인덱스 최적화:

• view_count 테이블에 적절한 인덱스를 추가하여 쿼리 성능 향상.

자동 스케일링:

• DB와 캐시 서버에 오토스케일링을 적용하여 트래픽 증가에 실시간으로 대응.

---

 

 

○ Row 수 증가 문제와 RDBMS 확장

Row 수가 증가하면 기존 RDBMS의 성능이 저하되므로 확장이 필요하다.

---

1. 수직 확장 (Vertical Scaling)

설명:

• 더 강력한 하드웨어 자원(CPU, 메모리, SSD)을 사용하여 성능 향상을 도모.

한계:

• 하드웨어 성능에는 물리적인 한계가 있으며, 비용이 기하급수적으로 증가.

---

2. 수평 확장 (Horizontal Scaling, Sharding)

설명:

• Sharding을 통해 데이터를 여러 DB 서버로 분산하여 처리 부하를 분산.

장점:

• 데이터와 트래픽 증가를 효과적으로 처리.

단점:

• 데이터 분산 방식과 샤드 식별 로직을 관리하는 복잡성이 증가.

---

Sharding의 데이터 분산 방식과 샤드 선택

Q1. 어떤 방식으로 데이터를 분산?

샤딩에서는 데이터를 특정 기준에 따라 분산한다. 아래는 주요 데이터 분산 방식이다:

1. 키 기반 분산 (Key-based Sharding)

• 설명:
  • 해시 함수(ex. MD5, SHA-256)를 사용하여 데이터 키(예: user_id)를 특정 샤드로 매핑.
• 장점:
  • 샤드 간 데이터 균형이 잘 맞음.
• 단점:
  • 샤드 수를 변경( 추가/삭제)할 경우 데이터 리밸런싱이 필요.

2. 범위 기반 분산 (Range-based Sharding)

• 설명:
  • 특정 값의 범위(예: user_id가 1~10,000)로 샤드를 분할.
• 장점:
  • 데이터 조회 및 관리가 단순.
• 단점:
  • 데이터가 고르지 않게 분포될 수 있으며, 특정 샤드로 요청이 집중되는 문제 발생.

3. 지리적 분산 (Geographic-based Sharding)

• 설명:
  • 사용자 위치(예: 국가, 지역)에 따라 데이터를 분산.
• 장점:
  • 지역 트래픽 분리로 네트워크 레이턴시 감소.
• 단점:
  • 사용자의 이동 또는 글로벌 서비스에서 데이터 일관성 문제가 발생할 수 있음.

4. 유사도 기반 분산 (Entity-based Sharding)

• 설명:
  • 관련 데이터를 동일한 샤드에 저장하여 JOIN 작업 최적화.
• 장점:
  • 샤드 간 통신을 최소화.
• 단점:
  • 데이터 간 관계를 사전에 정의해야 하며, 관리 복잡성이 증가.

---

Q2. 애플리케이션에서 어떤 샤드를 읽어야 하는지?

애플리케이션이 적절한 샤드를 선택하는 방법은 다음과 같습니다:

1. 샤드 매핑 테이블 사용

• 설명:
  • 별도의 매핑 테이블(DB 또는 캐시)에 key와 shard 정보를 저장.
• 장점:
  • 동적 샤드 관리 가능.
• 단점:
  • 매핑 테이블이 추가적인 조회 오버헤드를 유발.

2. 샤드 선택 알고리즘 사용

• 설명:
  • 데이터를 분산할 때 사용한 해시 함수나 범위 기준을 동일하게 적용하여 샤드를 선택.
• 장점:
  • 추가적인 매핑 테이블이 필요 없음.
• 단점:
  • 샤드 추가/삭제 시 전체 데이터 리밸런싱 필요.

3. 애플리케이션 로직에서 결정

• 설명:
  • 애플리케이션 코드에서 데이터를 저장할 샤드와 읽을 샤드를 결정하는 로직 포함.
• 장점:
  • 단순하고 샤드 선택 속도가 빠름.
• 단점:
  • 애플리케이션 로직의 복잡성이 증가하며, 유지보수가 어려움.

---

Sharding으로 인한 복잡성 증가와 해결 방안

문제:

• 데이터 일관성:
  • 샤드 간 데이터가 분산되므로 트랜잭션 처리 및 데이터 동기화가 어려움.
• 운영 복잡성:
  • 샤드 추가/삭제 시 데이터 리밸런싱 필요.

해결 방안:

1. 분산 트랜잭션 관리:
   • 2PC(2-Phase Commit) 또는 SAGA 패턴을 사용.
2. 자동화 도구 사용:
   • 샤드 관리 및 데이터 리밸런싱을 자동화하는 오픈소스(예: Vitess, Citus) 활용.
3. 샤드 모니터링:
   • 샤드 간 부하를 실시간으로 분석하고, 필요 시 재분배.
4. 샤드 수 확장 계획:
   • 초기 설계 단계에서 충분한 샤드 여유 공간 확보.

---

 

○ Sharding 도입 후 발생한 문제와 해결 방안

Sharding을 통해 트래픽 증가 및 view_count_table의 row 수 증가 문제를 해결하는 것은 효과적이지만, 그에 따른 내결함성 (Fault tolerance)과 human error 에 대한 문제도 함께 해결해야 한다.

---

1. 내결함성 (Fault tolerance) 보장

Sharding을 사용하면 여러 DB 서버로 데이터를 분산시키기 때문에 특정 DB 서버가 다운되더라도 전체 시스템이 정상적으로 작동하도록 하는 것이 중요하다. 이를 위해 다음과 같은 방법을 사용할 수 있다:

해결 방법:

• 샤드 복제 (Sharded Replication):
  • 각 샤드를 미리 복제하여 복제본을 유지한다. 이 방법은 특정 샤드 서버가 다운되었을 때, 복제본을 사용하여 서비스 중단 없이 운영할 수 있게 한다.
  • 복제본이 여러 개 있을 경우, 한 샤드가 다운되더라도 다른 샤드에서 데이터를 복구하고 자동 장애 복구가 가능해진다.
• 데이터 중복 처리:
  • 데이터를 분산하여 저장할 때, 중요한 데이터는 두 개 이상의 서버에 중복 저장해 두고, 한 서버가 다운되었을 때 자동으로 다른 서버에서 데이터를 가져올 수 있도록 한다.
• 장애 감지 및 자동화:
  • 모니터링 시스템을 통해 특정 서버의 장애를 감지하고 자동으로 복구 프로세스를 실행하도록 한다. 예를 들어, 장애가 발생한 서버의 복제본을 활성화시키고, 기존 데이터를 최신 상태로 동기화한다.

---

2. 실수에 의한 데이터 오염

작업자가 실수로 조회수를 잘못 수정하는 경우, 예를 들어 조회수를 +1이 아니라 +2로 잘못 증가시키는 상황이 발생하면 데이터가 오염되어 시스템에 심각한 영향을 미칠 수 있다.

해결 방법:

• 트랜잭션 관리:
  • ACID(Atomicity, Consistency, Isolation, Durability) 원칙을 준수하는 트랜잭션 처리를 통해 데이터를 안전하게 업데이트한다. 조회수와 같은 중요한 값은 트랜잭션 단위로 처리하여 중간에 오류가 발생해도 데이터 오염을 방지한다.
• 버전 관리 및 롤백:
  • 버전 관리 시스템을 도입하여 데이터 변경 시 버전 정보를 기록하고, 잘못된 변경 사항이 감지되면 롤백할 수 있도록 한다. 예를 들어, 조회수 증가 작업을 +1로 제한하고, 실수로 잘못된 값이 증가했다면 이를 롤백하여 원래 값을 복구한다.
• 이중 확인 및 알림 시스템:
  • 중요한 작업에 대해서는 이중 확인 절차를 추가하여 실수를 줄일 수 있다. 예를 들어, 조회수를 수정할 때 관리자에게 확인 메시지를 보내거나, 실수로 큰 값을 수정하려 할 때 경고 메시지를 띄웁니다.
• 백업 및 데이터 복구:
  • 정기적인 백업을 통해 데이터를 주기적으로 저장하고, 실수나 데이터 오염이 발생한 후에는 백업 데이터를 통해 복구할 수 있도록 한다. 실수로 발생한 데이터 오염은 백업을 통해 신속하게 원래 상태로 복구할 수 있다.
• 로그 시스템:
  • 모든 작업에 대한 변경 로그를 기록하고, 이 로그를 통해 작업자가 수행한 변경 사항을 추적할 수 있도록 한다. 문제가 발생한 후, 로그를 통해 변경된 정확한 시점과 원인을 확인하여 복구 작업을 진행한다.

---

3. 데이터 읽고 쓰는 문제

초기 요구사항이 단순히 "각 URL별 누적 조회수 계산"이었다면, 데이터를 읽고 쓰는 문제에 너무 많은 시간이 소비되기 시작하는 것은 샤딩과 데이터 분산 처리의 복잡성 때문이다. 이를 해결하기 위한 방법은 다음과 같습니다:

해결 방법:

• 캐싱:
  • 조회수를 자주 읽는 데이터는 캐시를 활용하여 성능을 향상시킵니다. 예를 들어, 조회수 데이터를 Redis와 같은 인메모리 캐시 시스템에 저장하여 빠르게 조회하고, 변경 사항이 발생할 때만 DB에 반영하도록 한다.
• 비동기 처리:
  • 조회수를 즉시 DB에 반영하는 대신, 비동기 방식으로 처리하여, 데이터베이스에 실시간으로 반영하지 않고 큐(queue)를 사용하여 일정 주기로 배치 처리를 할 수 있다.
• 분산 트랜잭션 및 최적화:
  • 여러 샤드에 걸쳐 데이터를 처리할 때, 분산 트랜잭션 관리 시스템을 적용하여 트랜잭션의 일관성을 보장하고, 조회수 계산의 성능을 최적화한다.
• 데이터 마이그레이션:
  • 초기 설계 시 데이터가 커질 것을 대비하여 샤드의 구조를 미리 설계하고, 데이터 마이그레이션이 용이하도록 시스템을 구축한다.

---

 

 

 

Lambda Architecture 개요

Lambda Architecture는 대규모 데이터 처리 시스템에서 실시간 데이터와 배치 데이터 처리의 장점을 결합한 아키텍처이다. 이 아키텍처는 빅데이터 파이프라인에서 널리 사용되며, Batch Layer, Speed Layer, Serving Layer의 세 가지 주요 계층으로 구성된다.

---

1. Batch Layer

• 역할: Batch Layer는 전체 데이터를 주기적으로 처리하여 데이터의 완전한 상태를 보장한다. 이 계층에서 데이터를 미리 계산하여 Batch View를 생성한다.
• 데이터 처리: 주기적으로 (예: 하루에 한 번, 두 번) 대량의 데이터를 처리하여 새로운 데이터를 반영한 배치 뷰를 생성한다. Master Dataset을 관리하고, 배치 처리로 데이터를 처리하기 때문에 정확성과 완전성을 보장할 수 있다.
• 특징: 전체 데이터에 대한 집계 및 분석을 수행하고, 대규모 데이터를 일괄 처리하는 데 적합한다. 이 계층은 실시간 처리에는 느리지만, 데이터의 일관성과 정확성을 보장한다.

---

2. Speed Layer (Real-time Layer)

• 역할: Speed Layer는 Batch Layer에서 처리할 수 없는 실시간 데이터를 처리한다. 주로 실시간 뷰(Realtime View)를 생성하여 빠르게 데이터를 반영한다.
• 데이터 처리: 실시간으로 들어오는 데이터를 빠르게 처리하고, 실시간 뷰를 업데이트하여 최신 데이터를 제공할 수 있다. 이 계층은 데이터의 속도와 시의성에 중점을 두며, 빠른 처리 속도를 요구한다.
• 특징: 실시간 데이터 흐름을 처리하며, Batch Layer가 처리되지 않은 가장 최근의 데이터에 대한 결과를 제공한다.

---

3. Serving Layer

• 역할: Serving Layer는 Batch View와 Real-time View를 결합하여, 클라이언트에서 쿼리할 수 있는 최종 결과를 제공한다. 이 계층은 쿼리 요청에 대해 빠르게 데이터를 반환한다.
• 데이터 처리: Batch View와 Real-time View를 결합하여 하이브리드 쿼리를 제공한다. 이 계층은 최신 데이터를 사용자에게 제공하는 역할을 한다.
• 특징: 클라이언트에서 쿼리 요청을 처리하고, Batch Layer와 Speed Layer에서 생성된 뷰를 결합하여 응답을 생성한다.

---

Lambda Architecture의 흐름

1. Batch Layer에서 대규모 데이터 집합에 대한 계산을 주기적으로 수행하고, 결과를 Batch View로 생성한다.
2. Speed Layer에서 실시간 데이터를 처리하여 Real-time View를 생성하고, 빠르게 최신 데이터를 반영한다.
3. Serving Layer는 이 두 가지 뷰를 결합하여 클라이언트에서 쿼리 가능한 형식으로 제공

 

 

 

 

Kappa Architecture 개요

Kappa Architecture는 Lambda Architecture의 복잡성을 줄이기 위해 등장한 데이터 처리 아키텍처이다. Lambda Architecture는 Batch Layer와 Speed Layer를 분리하여 데이터를 처리하지만, Kappa Architecture는 이를 통합해 실시간 데이터 처리를 단일 계층에서 수행한다. 이 아키텍처는 주로 스트리밍 데이터 처리를 중점으로 설계되었으며, 확장성과 간소화를 목표로 한다.

---

Kappa Architecture의 주요 특징

1. Batch Layer 제거

• Lambda Architecture와 달리 Kappa Architecture에서는 Batch Layer를 제거하여 단일 스트리밍 계층에서 데이터를 처리.
• 데이터는 실시간으로 수집되고, 처리된 결과는 바로 저장소에 저장.
• 실시간 스트리밍 처리를 통해 배치 연산 없이 동일한 결과를 얻음.

2. Stream Processing Layer

• 데이터를 실시간 스트리밍 처리하며, 데이터가 들어오는 즉시 처리 및 업데이트.
• Apache Kafka, Apache Flink, Apache Spark Streaming과 같은 스트리밍 엔진을 주로 사용.
• 스트리밍 엔진은 이벤트 데이터를 처리하고 필요한 경우 이전 데이터를 업데이트.

3. Serving Layer

• 저장소(Storage)와 연결하여 클라이언트가 데이터를 쿼리 가능하도록 제공.
• 실시간 처리 결과를 기반으로 최신 데이터를 클라이언트에 전달.
• 클라이언트는 즉시 쿼리를 통해 최신 데이터와 히스토리 데이터를 결합해 사용할 수 있음.

---

Kappa Architecture의 장점

1. 아키텍처 단순화
   • Batch Layer 제거로 Lambda Architecture보다 구조가 간단.
   • 코드 중복이 사라지고 유지보수가 쉬워짐.
2. 실시간 데이터 처리 최적화
   • 스트리밍 데이터 처리 기술의 발전으로 실시간 처리 속도가 배치 처리와 비슷하거나 더 나아짐.
3. 유연한 확장성
   • 스트리밍 엔진이 중심이 되어, 확장성과 데이터 처리량 증가에 효과적으로 대응 가능.
4. 데이터 재처리 가능
   • 이벤트 로그 저장소에서 데이터를 다시 읽고 처리하여 데이터 복구 및 재처리가 가능.
   • 예를 들어, Apache Kafka의 로그 기반 스토리지를 활용.

---

Kappa Architecture의 단점

1. 복잡한 데이터 처리 논리
   • 배치 처리가 사라지면서 모든 데이터를 스트리밍 방식으로 처리해야 하므로 처리 논리가 더 복잡해질 수 있음.
2. 대규모 데이터 처리 제약
   • 배치 처리가 제공하는 대규모 데이터 분석 및 집계 작업이 상대적으로 비효율적.
3. 히스토리 데이터 보존의 부담
   • 모든 데이터를 스트리밍 방식으로 처리하므로, 히스토리 데이터를 효율적으로 관리하기 위한 스토리지 비용 증가.

---

Kappa Architecture의 구성요소와 데이터 흐름

1. Stream Processing Layer

• 실시간으로 데이터 스트리밍 처리.
• 데이터 변환, 집계, 필터링 작업 수행.

2. Storage Layer (Historical Data)

• 모든 데이터를 로그 기반 저장소(예: Kafka, HDFS)에 저장하여 히스토리 데이터 관리.
• 데이터 재처리 및 복구 가능.

3. Serving Layer

• 클라이언트가 데이터를 쿼리하고 사용할 수 있도록 결과 제공.
• 최신 데이터를 빠르게 제공하며, 이전 데이터와의 결합 가능.

---