Architectures
Lambda Architecture(람다 아키텍처) 는 대용량 데이터의 정확한 분석을 위해 배치 처리와 실시간 스트림 처리를 결합한 구조로, 데이터의 신속한 처리와 정확한 결과를 동시에 제공한다. 반면 Kappa Architecture(카파 아키텍처) 는 모든 처리를 스트림 기반으로 단순화하여, 데이터 재처리와 시스템 유지보수를 용이하게 한다. 두 아키텍처는 빅데이터 환경에서 데이터 신뢰성, 확장성, 실시간성 확보를 위한 대표적인 설계 방식으로, 각각의 특징과 적용 환경에 따라 선택적으로 활용된다.
핵심 개념
Lambda Architecture 핵심 개념:
- 배치 계층 (Batch Layer): 대용량 히스토리컬 데이터를 정확하게 처리하는 불변 데이터 저장소
- 스피드 계층 (Speed Layer): 실시간 데이터 스트림을 낮은 지연시간으로 처리
- 서빙 계층 (Serving Layer): 배치와 스피드 계층의 결과를 통합하여 쿼리 서비스 제공
- 휴먼 내결함성 (Human Fault Tolerance): 코드 오류나 알고리즘 변경 시 히스토리컬 데이터 재처리 지원
Kappa Architecture 핵심 개념:
- 단일 스트림 처리: 모든 데이터를 연속적인 이벤트 스트림으로 처리
- 이벤트 소싱 (Event Sourcing): 모든 변경사항을 이벤트로 기록하는 불변 로그 패턴
- 리플레이 (Replay) 메커니즘: 과거 이벤트를 재처리하여 상태 복구 및 재계산 지원
- 통합 데이터 처리: 실시간과 배치 처리 로직을 동일한 코드베이스로 구현
공통점:
- 대규모 데이터 처리, 확장성, 실시간 분석 지원, 데이터 플로우 (Flow) 기반 설계.
차이점:
- Lambda 는 배치 + 실시간의 이중 경로, Kappa 는 단일 스트림 경로.
실무 구현을 위한 연관성 분석
기술 스택 연관성:
- 메시지 브로커: Apache Kafka 가 두 아키텍처 모두에서 핵심 역할을 담당하며, 데이터 수집과 분산을 지원
- 스트림 처리 엔진: Apache Flink, Apache Storm, Kafka Streams 가 실시간 처리 구현의 기반
- 저장소 시스템: NoSQL 데이터베이스 (Cassandra, HBase) 와 분산 파일 시스템 (HDFS, S3) 이 데이터 영속성 보장
- 배치 처리 프레임워크: Apache Spark, Hadoop 이 Lambda 의 배치 계층 구현에 필수적
운영 측면 연관성:
- 모니터링과 관찰성: 분산 시스템의 성능 추적과 장애 감지를 위한 메트릭 수집 체계
- 확장성 설계: 수평적 확장을 위한 파티셔닝과 샤딩 전략
- 데이터 거버넌스: 데이터 품질, 일관성, 보안을 위한 정책과 절차
실무 연계 관점 정리
| 항목 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 주요 목적 | 정확성과 실시간성의 절충 | 단순성과 재처리 용이성 |
| 활용 분야 | 금융, 보안, 정확한 데이터 일관성 필요 영역 | 로그 분석, 사용자 행동 분석, IoT 데이터 처리 등 |
| 사용 기술 | Hadoop, Spark, Storm, HBase | Kafka, Flink, Pulsar, ksqlDB 등 |
| 요구 조건 | 배치 + 스트림 구성과 이중 코드 관리 필요 | 이벤트 로그 재처리 가능한 저장소 필수 (예: Kafka log retention) |
Lambda Architecture vs. Kappa Architecture 비교
Lambda 와 Kappa 아키텍처는 대용량 데이터 처리에 대한 서로 다른 철학을 반영한다. Lambda 는 정확성과 내결함성에 중점을 두어 복잡한 계층 구조를 통해 안정성을 확보하고, Kappa 는 단순성과 실시간성에 집중하여 스트림 중심의 통합된 접근법을 제시한다.
| 구분 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 핵심 철학 | 배치와 실시간 처리의 분리를 통한 정확성 확보 | 모든 데이터를 스트림으로 통합 처리 |
| 계층 구조 | 3 계층 (배치, 스피드, 서빙) | 단일 스트림 처리 계층 |
| 데이터 처리 방식 | 배치 + 실시간 이중 처리 | 스트림 기반 단일 처리 |
| 복잡성 | 높음 (두 개의 처리 경로 관리) | 낮음 (단일 처리 경로) |
| 개발 및 유지보수 | 두 개의 코드베이스 관리 필요 | 단일 코드베이스로 간소화 |
| 지연시간 | 스피드 계층은 낮음, 배치는 높음 | 일관되게 낮은 지연시간 |
| 정확성 | 배치 계층에서 높은 정확성 보장 | 스트림 처리 정확성에 의존 |
| 내결함성 | 매우 높음 (이중 처리로 백업) | 높음 (리플레이 메커니즘) |
| 확장성 | 배치와 스트림 각각 독립적 확장 | 스트림 처리 엔진 성능에 의존 |
| 비용 | 이중 인프라로 높은 비용 | 단일 인프라로 상대적 저비용 |
구조 및 아키텍처
Lambda Architecture
flowchart LR
A[데이터 소스] --> B["배치 레이어 (Batch Layer)"]
A --> C["실시간 레이어 (Speed Layer)"]
B --> D["서빙 레이어 (Serving Layer)"]
C --> D
D --> E[클라이언트/분석]
- 배치 레이어: 전체 데이터 집합을 주기적으로 처리하여 정확한 결과 생성
- 실시간 레이어: 최신 데이터만 빠르게 처리하여 신속한 결과 제공
- 서빙 레이어: 두 결과를 통합하여 사용자에게 제공
Kappa Architecture
flowchart LR
A[데이터 소스] --> B["스트림 처리 레이어 (Stream Processing Layer)"]
B --> C["서빙 레이어 (Serving Layer)"]
C --> D[클라이언트/분석]
- 스트림 처리 레이어: 모든 데이터 처리 (실시간/재처리 포함) 를 단일 파이프라인에서 수행
- 서빙 레이어: 처리 결과를 저장 및 제공
구성 요소 비교
| 구성 요소 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 데이터 소스 | 이벤트, 로그, 외부 시스템 등 | Kafka 등 append-only 로그 기반 시스템 |
| Batch Layer | Spark, Hadoop 기반으로 주기적 배치 처리 | ❌ 없음 (전체 스트림으로 재처리) |
| Speed Layer | Storm, Spark Streaming, Flink 등 실시간 처리 엔진 사용 | 스트림 처리 엔진 단일 사용 |
| Serving Layer | Cassandra, HBase, Druid | Cassandra, Druid, Elasticsearch 등 유사 |
| 상태 저장소 | 배치와 스트림 모두 각자 상태 저장 | 스트림 처리 내부 상태 or 외부 저장소 (RocksDB 등) |
주요 원리 및 설계 철학
| 항목 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 처리 철학 | " 정확한 결과는 배치에서, 빠른 응답은 스트림에서 " | " 스트림 하나로 모두 처리하고, 필요하면 재처리 " |
| 데이터 처리 | 배치 + 실시간 분리 (Dual Path) | 단일 스트림 경로 (Single Path) |
| 재처리 방식 | Batch Layer 에서 전체 재처리 | Kafka 로그에서 다시 consume |
| 코드베이스 | Speed / Batch 각각 구현 | 하나의 스트림 처리 코드 |
작동 원리 및 흐름
Lambda Architecture 작동 흐름
sequenceDiagram
participant Source
participant BatchLayer
participant SpeedLayer
participant Serving
participant Client
Source->>BatchLayer: Historical Data Input
Source->>SpeedLayer: Real-time Data Input
BatchLayer-->>Serving: Batch View Results
SpeedLayer-->>Serving: Real-time View Results
Client->>Serving: Query
Serving-->>Client: Unified Response
Kappa Architecture 작동 흐름
sequenceDiagram
participant Kafka
participant StreamProcessor
participant Serving
participant Client
Kafka->>StreamProcessor: Events
StreamProcessor-->>Serving: Processed Output
Client->>Serving: Query
Serving-->>Client: Response
구현 기법 비교
| 항목 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 처리 모델 | Batch + Stream 이원 구조 | Stream 단일 경로 |
| 재처리 방식 | 전체 배치 재처리 (HDFS 재스캔) | Kafka 로그 재처리 (Offset reset) |
| 코드베이스 | 이중 구현 필요 (Batch/Stream 따로) | 단일 스트림 처리 코드 |
| 배포 모델 | 이중 처리 플로우 관리 필요 | 단일 파이프라인 유지 |
| 기술 조합 | Spark + Storm + Cassandra | Kafka + Flink + RocksDB / Elastic |
| 지연 시간 | 실시간 + 배치 병합으로 약간 느림 | 스트림 기반이라 낮음 (ms~sec 단위) |
| 상태 처리 | 외부 DB (Cassandra, Redis 등) | 내장 상태 DB (e.g., Flink 의 RocksDB) |
Lambda Architecture 구현
| 구분 | 항목 | 설명 | 구성 요소 | 실제 예시 |
|---|---|---|---|---|
| 이중 처리 경로 | 동일 데이터 분기 처리 | 하나의 데이터를 배치와 스트림 경로로 동시에 전송하여 각자의 특성에 맞게 병렬 처리 | - Kafka: 분산 로그 시스템 - Spark (Batch): 정확성 중심 처리 - Storm (Stream): 실시간 처리 - HBase: 공통 결과 저장소 | - 전자상거래 추천 시스템 - 사용자 행동 로그 분석 - 실시간 추천 + 정확한 통계 병행 |
| 뷰 통합 | 배치 결과 + 스트림 결과 통합 | 배치 계층과 실시간 계층의 결과를 서빙 계층에서 병합하여 통합된 응답을 제공 | - Query Router: 요청 분기 - Result Merger: 결과 병합 - Cache Layer: 응답 속도 향상 | - 소셜 미디어 타임라인 - 금융 거래 대시보드 - T-24h 집계 + 1h 실시간 결과 합산 |
Kappa Architecture 구현 기법
| 항목 | 이벤트 소싱 (Event Sourcing) | 스트림 재처리 (Stream Reprocessing) |
|---|---|---|
| 정의 | 모든 상태 변화를 불변 이벤트로 저장 | 과거 이벤트를 새로운 로직으로 재처리 |
| 구성 요소 | Event Store, Event Handlers, Snapshots | Offset Reset, Parallel Processing, State Management |
| 목적 | 시스템 상태의 완전한 추적성과 재현성 확보 | 비즈니스 로직 변경 시 히스토리컬 데이터 재계산 |
| 실제 예시 - 시스템 구성 | Kafka Event Log → Flink Event Processor → Cassandra State Store | Kafka Topics → Flink Job Reset → New Logic Processing |
| 실제 예시 - 시나리오 | 금융 거래 시스템의 계좌 잔액 관리 | 머신러닝 모델 업데이트 후 전체 예측 결과 재계산 |
강점과 약점 비교
| 구분 | Lambda Architecture | Kappa Architecture |
|---|---|---|
| 강점 | • 높은 정확성과 일관성 • 강력한 내결함성 • 대용량 배치 처리 최적화 • 히스토리컬 데이터 재처리 안정성 | • 단순한 아키텍처 • 빠른 개발 및 배포 • 단일 코드베이스 • 일관된 낮은 지연시간 |
| 약점 | • 높은 복잡성 • 이중 인프라 비용 • 두 개의 코드베이스 유지 • 개발 및 운영 복잡도 증가 | • 스트림 처리 엔진 성능 의존 • 복잡한 배치 분석 제한 • 대용량 히스토리컬 처리 성능 • 스토리지 요구사항 증가 |
단점과 문제점 및 해결방안
Lambda Architecture
단점
| 항목 | 설명 | 해결책 |
|---|---|---|
| 높은 복잡성 | 배치와 스피드 계층 간 동기화, 두 개의 서로 다른 처리 로직 관리 | 표준화된 개발 프레임워크 도입, 자동화된 배포 파이프라인 구축 |
| 개발 비용 | 이중 코드베이스 개발 및 유지보수로 인한 개발 리소스 증가 | 공통 라이브러리 개발, 코드 생성 도구 활용 |
| 운영 복잡도 | 다중 시스템 모니터링, 장애 대응 절차 복잡화 | 통합 모니터링 플랫폼, SRE 조직 구성 |
| 지연시간 | 배치 계층의 처리 지연으로 인한 최신 데이터 반영 지연 | 마이크로 배치 기법, 증분 처리 도입 |
문제점
| 항목 | 원인 | 영향 | 탐지 및 진단 | 예방 방법 | 해결 방법 및 기법 |
|---|---|---|---|---|---|
| 데이터 일관성 | 배치와 스트림 계층 간 처리 시점 차이 | 클라이언트 쿼리 결과 불일치 | 데이터 검증 대시보드, 일관성 체크 | 타임스탬프 기반 동기화 | Eventually Consistent 패턴 적용 |
| 리소스 중복 | 동일 데이터의 이중 처리 | 인프라 비용 증가, 성능 저하 | 리소스 사용량 모니터링 | 효율적 파티셔닝 전략 | 리소스 풀링, 컨테이너 오케스트레이션 |
| 스키마 진화 | 배치/스트림 계층 스키마 불일치 | 데이터 파이프라인 장애 | 스키마 호환성 테스트 | 스키마 레지스트리 도입 | 하위 호환성 있는 스키마 설계 |
Kappa Architecture
단점
| 항목 | 설명 | 해결책 |
|---|---|---|
| 스트림 엔진 의존성 | 단일 스트림 처리 엔진 성능과 안정성에 전체 시스템이 의존 | 멀티 클러스터 구성, Active-Standby 패턴 도입 |
| 배치 분석 제약 | 복잡한 알고리즘이나 대용량 조인 연산의 성능 한계 | 하이브리드 접근법, 오프라인 분석 파이프라인 분리 |
| 상태 관리 | 대용량 상태 데이터 관리와 체크포인트 오버헤드 | 상태 파티셔닝, 점진적 체크포인트 |
| 디버깅 복잡도 | 스트림 처리 로직의 디버깅과 테스트 어려움 | 이벤트 소싱 기반 리플레이, 로컬 테스트 환경 |
문제점
| 항목 | 원인 | 영향 | 탐지 및 진단 | 예방 방법 | 해결 방법 및 기법 |
|---|---|---|---|---|---|
| 백프레셰 (Backpressure) | 스트림 처리 속도 < 데이터 유입 속도 | 처리 지연, 메모리 부족 | 처리량 메트릭 모니터링 | 동적 스케일링 정책 | 적응형 배치 크기, 로드 밸런싱 |
| 이벤트 순서 | 네트워크 지연으로 인한 이벤트 순서 변경 | 잘못된 상태 계산 | 이벤트 타임스탬프 추적 | 이벤트 타임 워터마크 | 늦은 이벤트 처리 윈도우 |
| 중복 처리 | 네트워크 재전송으로 인한 이벤트 중복 | 부정확한 집계 결과 | 이벤트 ID 추적 | 멱등성 키 설계 | 정확히 한 번 처리 보장 |
실무에서 효과적으로 적용하기 위한 고려사항
| 항목 | Lambda Architecture | Kappa Architecture | 권장사항 |
|---|---|---|---|
| 데이터 볼륨 | 페타바이트급 대용량 처리에 적합 | 테라바이트급 중간 규모에 최적화 | 데이터 규모에 따른 아키텍처 선택 |
| 실시간 요구사항 | 정확성 우선, 약간의 지연 허용 | 일관된 낮은 지연시간 필요 | SLA 요구사항 분석 후 결정 |
| 팀 역량 | 분산 시스템 전문 지식 필요 | 스트림 처리 전문 지식 필요 | 팀의 기술 스택 숙련도 고려 |
| 운영 복잡도 | 높은 운영 오버헤드 수용 가능 | 단순한 운영 환경 선호 | DevOps 성숙도 평가 |
| 비용 제약 | 이중 인프라 비용 감수 가능 | 비용 최적화 우선 | ROI 분석을 통한 의사결정 |
최적화하기 위한 고려사항
| 항목 | Lambda Architecture | Kappa Architecture | 권장사항 |
|---|---|---|---|
| 성능 최적화 | 배치/스트림 각각 독립 튜닝 파티셔닝 전략 수립 | 스트림 처리 엔진 성능 집중 백프레셔 관리 | 워크로드 특성에 맞는 튜닝 |
| 확장성 | 계층별 독립적 스케일링 리소스 분리 관리 | 스트림 처리 중심 스케일링 상태 관리 최적화 | 확장 패턴 설계 시 고려 |
| 모니터링 | 다중 계층 메트릭 수집 통합 대시보드 구성 | 단일 파이프라인 모니터링 이벤트 추적 강화 | 관찰성 플랫폼 구축 |
| 장애 복구 | 계층별 백업 전략 독립적 복구 절차 | 이벤트 리플레이 기반 복구 체크포인트 관리 | DR 시나리오별 복구 절차 |
| 데이터 거버넌스 | 계층별 데이터 품질 관리 일관성 검증 절차 | 이벤트 스키마 진화 관리 상태 일관성 보장 | 데이터 품질 프레임워크 |
주목할 내용들
| 주제 | 항목 | 설명 |
|---|---|---|
| 기술 트렌드 | Event Mesh | 분산된 이벤트 브로커들을 연결하는 네트워크로 확장성과 유연성 향상 |
| Serverless Streaming | 서버리스 컴퓨팅과 스트림 처리 결합으로 운영 부담 감소 | |
| AI/ML 통합 | 실시간 머신러닝 추론과 온라인 학습을 스트림 처리에 직접 통합 | |
| 운영 혁신 | GitOps for Data | 데이터 파이프라인의 버전 관리, 배포, 롤백을 Git 워크플로우로 관리 |
| DataOps | 데이터 팀의 협업과 자동화를 위한 DevOps 방법론 적용 | |
| Observability 3.0 | 메트릭, 로그, 트레이스를 넘어선 비즈니스 컨텍스트 기반 관찰성 | |
| 아키텍처 진화 | Data Mesh | 도메인 중심의 분산 데이터 아키텍처로 확장성과 자율성 향상 |
| Event-Driven Microservices | 이벤트 스트리밍을 중심으로 한 마이크로서비스 아키텍처 | |
| Polyglot Persistence | 워크로드별 최적화된 다양한 데이터 저장소 조합 사용 | |
| 보안 및 거버넌스 | Zero Trust Data | 모든 데이터 접근에 대한 지속적 검증과 최소 권한 원칙 |
| Privacy-Preserving Analytics | 개인정보 보호와 분석 효용성의 균형을 위한 기술 (차분 프라이버시, 동형암호) | |
| Data Lineage Automation | 데이터 흐름과 변환 과정의 자동 추적 및 문서화 |
반드시 학습해야할 내용들
| 카테고리 | 주제 | 항목 | 설명 |
|---|---|---|---|
| 스트림 처리 기술 | Apache Kafka | 메시지 브로커 운영 | 토픽 설계, 파티셔닝 전략, 컨슈머 그룹 관리 |
| Apache Flink | 상태 관리 | 체크포인트, 세이브포인트, 상태 백엔드 최적화 | |
| Event Time Processing | 워터마크와 윈도우 | 늦은 이벤트 처리, 시간 기반 집계 연산 | |
| 데이터 모델링 | Event Sourcing | 이벤트 설계 | 이벤트 스키마, 버전 관리, 이벤트 스토어 설계 |
| CQRS | 명령과 쿼리 분리 | 읽기/쓰기 모델 분리, 최종 일관성 관리 | |
| Stream Schema Design | 스키마 진화 | 하위 호환성, 스키마 레지스트리 활용 | |
| 분산 시스템 | Consensus Algorithms | 합의 알고리즘 | Raft, PBFT, 분산 상태 관리 |
| Circuit Breaker | 장애 격리 | 장애 전파 방지, 자동 복구 메커니즘 | |
| Distributed Tracing | 분산 추적 | 요청 흐름 추적, 성능 병목 식별 | |
| 운영 및 모니터링 | SRE Practices | 신뢰성 엔지니어링 | SLI/SLO 설정, 에러 버짓 관리 |
| Chaos Engineering | 장애 주입 테스트 | 시스템 복원력 검증, 장애 시나리오 테스트 | |
| Cost Optimization | 비용 최적화 | 리소스 사용량 분석, 자동 스케일링 정책 | |
| 보안 | Stream Encryption | 스트림 암호화 | End-to-end 암호화, 키 관리, 접근 제어 |
| Zero Trust Architecture | 제로 트러스트 | 마이크로 세그먼테이션, 동적 접근 제어 | |
| Privacy Engineering | 프라이버시 엔지니어링 | 차분 프라이버시, 데이터 익명화 기법 |
용어 정리
| 카테고리 | 용어 | 설명 |
|---|---|---|
| 아키텍처 | Lambda Architecture | 배치와 실시간 경로를 결합한 대규모 데이터 처리 구조 |
| 아키텍처 | Kappa Architecture | 모든 처리를 단일 스트림 파이프라인에서 수행하는 구조 |
| 구성요소 | 배치 레이어 | Lambda 에서 대용량 데이터 일괄 처리 담당 |
| 구성요소 | 실시간 레이어 | Lambda 에서 최신 데이터 실시간 처리 담당 |
| 구성요소 | 서빙 레이어 | 처리 결과를 통합, 저장, 제공하는 계층 |
| 구성요소 | 스트림 처리 레이어 | Kappa 에서 데이터 실시간 처리 담당 |
| 기술 | Kafka | 분산 메시지 큐, 스트림 데이터 처리 플랫폼 |
| 기술 | Flink | 실시간 데이터 스트림 처리 프레임워크 |
| 기술 | Spark | 대규모 데이터 배치 및 스트림 처리 프레임워크 |
📘 용어 정리
| 카테고리 | 용어 | 설명 |
|---|---|---|
| 아키텍처 | Lambda Architecture | 배치와 실시간 처리를 병행하는 데이터 아키텍처 |
| 아키텍처 | Kappa Architecture | 단일 스트림 처리 경로만 사용하는 간단한 아키텍처 |
| 스트리밍 엔진 | Flink | 고급 상태 기반 스트림 처리 엔진 |
| 데이터 버스 | Kafka | 고신뢰 이벤트 스트림 브로커 |
| 처리 계층 | Serving Layer | 외부에서 쿼리 가능한 상태 저장 계층 |
| 상태 관리 | RocksDB | Flink 내부에서 사용하는 로컬 상태 DB |
| 재처리 | Offset Reset | Kafka topic 에서 소비 지점을 다시 지정해 재처리 수행 |
| 장애 복구 | Checkpointing | Flink 등의 시스템에서 상태를 저장하여 복구 |
용어 정리
| 카테고리 | 용어 | 설명 |
|---|---|---|
| 아키텍처 | Event Sourcing | 시스템의 모든 상태 변화를 이벤트로 저장하는 패턴 |
| CQRS | Command Query Responsibility Segregation - 명령과 쿼리 책임 분리 | |
| Materialized View | 쿼리 성능 향상을 위해 미리 계산된 집계 결과를 저장하는 뷰 | |
| CAP Theorem | 분산 시스템에서 일관성, 가용성, 분할 허용성 중 최대 2 개만 보장 가능 | |
| 스트림 처리 | Watermark | 이벤트 시간 처리에서 늦은 데이터 도착을 처리하기 위한 시간 임계값 |
| Backpressure | 처리 속도보다 빠른 데이터 유입으로 인한 시스템 압박 상황 | |
| Windowing | 무한한 스트림을 시간 또는 개수 기준으로 분할하여 집계 연산 수행 | |
| Exactly-Once | 각 메시지가 정확히 한 번만 처리되도록 보장하는 의미론 | |
| 데이터 관리 | Schema Registry | 데이터 스키마의 중앙 집중식 관리 및 호환성 검증 시스템 |
| Data Lineage | 데이터의 출처, 이동 경로, 변환 과정을 추적하는 메타데이터 | |
| Event Store | 이벤트 소싱에서 이벤트를 영구 저장하는 특수한 데이터베이스 | |
| Partitioning | 데이터를 여러 노드에 분산 저장하여 확장성과 성능 향상 | |
| 운영 | Circuit Breaker | 장애 서비스 호출을 차단하여 연쇄 장애 방지하는 패턴 |
| Blue-Green Deployment | 두 개의 동일한 환경을 사용하여 무중단 배포하는 전략 | |
| Canary Release | 소수 사용자에게 먼저 배포하여 점진적으로 확산하는 배포 방식 | |
| Idempotency | 동일한 연산을 여러 번 수행해도 결과가 같도록 보장하는 성질 |
참고 및 출처
- Lambda Architecture 개요 및 세 계층 설명 - Wikipedia
- Data processing architectures — Lambda vs Kappa for Big Data - Medium
- Kappa Architecture – 시스템 설계 가이드 - GeeksforGeeks
- Lambda vs Kappa Architecture: Choosing the Best Data Framework - HashStudioz
- Kappa Architecture – 개념 및 장단점 - Hazelcast
- Lambda vs Kappa Architectures, Pros and Cons – Data Engineering Reddit