Kappa Architecture카파 아키텍처

람다의 문제:
  배치 코드 + 스트리밍 코드 = 2배 유지보수

카파의 해결:
  Kafka에 모든 데이터를 무기한 보존
  → 재처리 필요 시 처음부터 스트리밍으로 재생

단일 처리 엔진 (Flink, Kafka Streams)으로
배치와 실시간 모두 처리

     이벤트 스트림
          │
          ▼
    Kafka (원시 데이터 보존, 무기한)
          │
     ┌────┴────┐
     ▼         ▼
  실시간      재처리
  처리        (오류 수정/모델 변경 시)
  (Flink)    처음부터 재생
     │
     ▼
  서빙 레이어
  (Cassandra, Redis)

StreamsBuilder builder = new StreamsBuilder();

// 실시간 처리 (배치도 같은 코드)
KStream<String, ClickEvent> clicks =
    builder.stream("click-events");

KTable<Windowed<String>, Long> hourlyCounts = clicks
    .groupBy((key, event) -> event.getPageId())
    .windowedBy(TimeWindows.of(Duration.ofHours(1)))
    .count();

hourlyCounts.toStream()
    .to("hourly-page-counts");

// 재처리: 오프셋을 0으로 설정해 처음부터 재실행
// consumer.seekToBeginning(partitions);

1. 새 토픽/테이블에 재처리 결과 저장
2. 검증 완료 후 서빙 레이어에 교체
3. 이전 결과 삭제

오프셋 보존 기간:
  Kafka: log.retention.hours=forever (무기한)
  재처리 가능한 기간 = 보존 기간

카파 선택:
  ✅ 스트리밍 처리로 충분한 정확도
  ✅ 단순한 코드베이스 선호
  ✅ 배치 처리 없이 재처리 가능

람다 유지:
  ✅ ML 학습 등 대용량 배치 필수
  ✅ 스트리밍 재처리가 너무 느림
  ✅ 정확성이 최우선