Lambda Architecture
Lambda Architecture 는 빅데이터 환경에서 실시간성과 정확성을 동시에 달성하기 위해 고안된 데이터 처리 아키텍처이다. 배치 레이어와 스피드 (실시간) 레이어, 그리고 서빙 레이어로 구성되며, 배치 레이어는 대규모 데이터를 정확하게 처리하고, 스피드 레이어는 최신 데이터를 빠르게 반영한다. 이 구조는 데이터 일관성, 확장성, 장애 복원력을 제공하며, IoT, 로그 분석, 실시간 이벤트 분석 등 다양한 분야에서 활용된다.
배경
Lambda Architecture 는 기존 배치 처리 시스템의 높은 지연시간과 스트림 처리 시스템의 낮은 정확성 문제를 해결하기 위해 개발되었다. 빅데이터 시대의 도래와 함께 실시간 분석에 대한 요구가 증가하면서, 대용량 데이터를 정확하고 빠르게 처리할 수 있는 아키텍처의 필요성이 대두되었다.
목적 및 필요성
주요 목적:
- 대용량 데이터의 실시간 및 배치 처리 통합
- 높은 처리량과 낮은 지연시간의 균형
- 시스템 장애에 대한 높은 복원력 제공
- 데이터 정확성과 일관성 보장
필요성:
- 기존 배치 처리만으로는 실시간 의사결정 지원 한계
- 스트림 처리만으로는 데이터 정확성과 완전성 보장 어려움
- 비즈니스 민첩성 (Business Agility) 요구 증가
- 다양한 데이터 소스와 처리 요구사항 대응
핵심 개념
Lambda Architecture 는 대규모 데이터 시스템에서 정확성과 실시간성을 동시에 확보하기 위해 고안된 아키텍처로, Nathan Marz가 처음 제안했다.
기본 개념
불변성 (Immutability)
- 데이터는 한번 저장되면 수정되지 않고 새로운 데이터만 추가됨
- 데이터 일관성과 신뢰성 보장
- 실무에서는 추가 전용 로그 (Append-only Log) 구조로 구현
3 계층 구조 (Three-Layer Architecture)
- 배치 레이어, 스피드 레이어, 서빙 레이어의 분리된 역할
- 각 계층의 독립적 확장성과 장애 격리
- 실무에서는 마이크로서비스 아키텍처와 유사한 설계 원칙 적용
뷰 (View) 기반 처리
- 원시 데이터로부터 미리 계산된 뷰 생성
- 배치 뷰와 실시간 뷰의 결합
- 실무에서는 구체화된 뷰 (Materialized View) 패턴으로 구현
하이브리드 처리 (Hybrid Processing)
- 배치와 스트림 처리의 장점 결합
- 높은 처리량과 낮은 지연시간의 균형
- 실무에서는 Apache Spark 의 배치/스트리밍 통합 API 활용
실무 구현을 위한 연관성
데이터 파이프라인 설계 측면
- ETL/ELT 프로세스와 긴밀한 연관성
- 데이터 레이크 (Data Lake) 와 데이터 웨어하우스 (Data Warehouse) 통합
- 실시간 데이터 수집 아키텍처와의 연계
분산 시스템 설계 측면
- 분산 컴퓨팅 프레임워크 활용 (Apache Spark, Apache Flink)
- 메시지 큐 시스템 통합 (Apache Kafka, Amazon Kinesis)
- NoSQL 데이터베이스와의 연동 (Apache Cassandra, MongoDB)
장애 허용성 측면
- 체크포인팅 (Checkpointing) 메커니즘
- 정확히 한 번 처리 (Exactly-once Processing) 보장
- 분산 시스템의 부분 장애 처리
주요 기능 및 역할
실시간 분석 (Real-time Analytics)
- 스트리밍 데이터의 즉시 처리
- 밀리초 단위의 낮은 지연시간 제공
- 실시간 대시보드와 알림 시스템 지원
배치 분석 (Batch Analytics)
- 과거 데이터의 포괄적 분석
- 높은 정확성과 완전성 보장
- 복잡한 집계와 머신러닝 모델 학습
통합 질의 처리 (Unified Query Processing)
- 배치와 실시간 결과의 일관된 뷰 제공
- 애드혹 질의 (Ad-hoc Query) 지원
- 다양한 비즈니스 인텔리전스 도구와 연동
특징
확장성 (Scalability)
- 수평적 확장 지원
- 각 계층의 독립적 확장
- 클라우드 환경에서의 탄력적 자원 관리
내결함성 (Fault Tolerance)
- 개별 계층의 장애 격리
- 자동 복구 메커니즘
- 데이터 복제를 통한 가용성 보장
유연성 (Flexibility)
- 다양한 데이터 소스 지원
- 다중 처리 엔진 통합
- 비즈니스 요구사항 변화에 대한 적응성
핵심 원칙
불변성 원칙 (Immutability Principle)
- 한번 저장된 데이터는 수정하지 않음
- 새로운 데이터만 추가 (Append-only)
- 데이터 무결성과 감사 추적 보장
재계산 원칙 (Recomputation Principle)
- 오류 발생 시 전체 데이터셋에서 재계산 가능
- 휴먼 에러 (Human Error) 에 대한 복구 능력
- 알고리즘 개선 시 과거 데이터 재처리 가능
읽기 전용 계산 원칙 (Read-only Computation)
- 원본 데이터는 변경하지 않고 뷰만 생성
- 부작용 (Side Effect) 없는 함수형 처리
- 동시성 문제 해결
주요 원리
- 이중 처리 (Double Processing): 동일 데이터를 batch 와 stream 에서 각각 처리함
- Event Sourcing 원칙 적용: 데이터는 Append-only log 로 기록됨
- 불변 데이터: 데이터는 변경 불가능, 오직 추가만 가능
- 지연 보상 보정 (Latency Compensation): 실시간 결과는 추정값이며, 이후 batch 결과로 정정
작동 원리 및 방식
graph TD A[데이터 소스] --> B[메시지 큐<br/>Apache Kafka] B --> C[배치 레이어<br/>Apache Spark/Hadoop] B --> D[스피드 레이어<br/>Apache Storm/Flink] C --> E[배치 뷰<br/>HDFS/Data Lake] D --> F[실시간 뷰<br/>NoSQL/In-Memory] E --> G[서빙 레이어<br/>Query Engine] F --> G G --> H[통합 결과<br/>대시보드/API]
설명:
- 모든 원시 데이터는 Batch 와 Speed Layer 로 동시에 전달됨
- Batch Layer 는 일정 시간 주기로 전체 데이터를 분석하여 결과에 대한 배치 뷰를 생성
- Speed Layer 는 최근 데이터를 빠르게 처리하여 응답 속도를 높임
- Serving Layer 는 두 계층의 결과를 병합해 사용자의 쿼리에 응답
구조 및 아키텍처
graph TB subgraph "데이터 소스" DS1[IoT 센서] DS2[웹 로그] DS3[트랜잭션 DB] DS4[소셜 미디어] end subgraph "수집 계층" MQ[메시지 큐<br/>Apache Kafka/Kinesis] end subgraph "Lambda Architecture" subgraph "배치 레이어" BP[배치 처리<br/>Apache Spark/Hadoop] BDS[배치 데이터 저장<br/>HDFS/S3] BV[배치 뷰<br/>Hive/Parquet] end subgraph "스피드 레이어" SP[스트림 처리<br/>Apache Storm/Flink] RDS[실시간 데이터 저장<br/>Redis/Cassandra] RV[실시간 뷰<br/>In-Memory DB] end subgraph "서빙 레이어" QE[질의 엔진<br/>Apache Druid/Pinot] API[API 게이트웨이] end end subgraph "응용 계층" DASH[대시보드] APP[애플리케이션] BI[BI 도구] end DS1 --> MQ DS2 --> MQ DS3 --> MQ DS4 --> MQ MQ --> BP MQ --> SP BP --> BDS BDS --> BV SP --> RDS RDS --> RV BV --> QE RV --> QE QE --> API API --> DASH API --> APP API --> BI
구성요소
구분 | 레이어 / 구성요소 | 기능 | 역할 | 특징 | 기술 스택 예시 |
---|---|---|---|---|---|
필수 | 배치 레이어 (Batch Layer) | 전체 데이터셋의 정확하고 완전한 처리 | 마스터 데이터셋 저장 및 배치 뷰 생성 | 높은 처리량, 높은 정확성, 높은 지연시간 | Apache Hadoop, Apache Spark, HDFS, Amazon S3 |
스피드 레이어 (Speed Layer) | 실시간 스트림 데이터의 즉시 처리 | 배치 지연을 보완하는 근사 뷰 생성 | 낮은 지연시간, 근사 정확성, 제한된 처리량 | Apache Storm, Apache Flink, Apache Kafka Streams | |
서빙 레이어 (Serving Layer) | 배치와 실시간 결과의 통합 및 질의 제공 | 사용자에게 통합된 최신 데이터 뷰 제공 | 낮은 질의 지연시간, 높은 동시성 지원 | Apache Cassandra, Apache HBase, Apache Druid | |
선택 | 메시지 큐 시스템 | 데이터 스트림 수집 및 중개 | 배치 및 스피드 레이어 간 데이터 전파 및 디커플링 | 높은 처리량, 내결함성, 메시지 순서 보장 | Apache Kafka, Amazon Kinesis, Apache Pulsar |
모니터링 및 관리 도구 | 시스템 성능 및 상태 실시간 모니터링 및 분석 | 장애 감지, 성능 최적화, 이상 탐지 | 실시간 메트릭, 로그 분석, 경고/알림 기능 | Grafana, Apache Zeppelin, ELK Stack (Elasticsearch 등) |
구현 기법
카테고리 | 구현 기법 | 정의 및 구성요소 | 주요 목적 / 역할 | 기술 스택 / 예시 |
---|---|---|---|---|
1. 배치 처리 | Batch Processing Framework | 대용량 데이터의 정기적 처리 (시간 단위/일 단위) | 전역 분석, 정밀 통계, 마스터 데이터셋 생성 | Apache Spark, Hadoop, Airflow, HDFS, Amazon S3 |
Batch View Materialization | 배치 결과를 쿼리 가능한 형태로 저장 | 정합성 높은 전처리 결과 제공 | Spark Aggregation → Parquet/Hive Table/Redis | |
2. 스트림 처리 | Stream Processing Engine | 실시간 이벤트를 지속적으로 처리 | 낮은 지연시간, 실시간 반응, Near Real-time ETL | Apache Kafka Streams, Flink, Storm, Redis |
Immutable Event Log | 변경 불가능한 이벤트 로그 저장소 (로그 기반 처리 모델) | 이벤트 재처리, 감사 추적, 장애 복구 기반 | Apache Kafka, Amazon Kinesis | |
Backpressure Control | 소비자 속도 제어 메커니즘 (과부하 방지) | 안정성 보장, 시스템 보호 | Reactive Streams, Akka Streams, Flink Watermarks | |
3. 통합 및 병합 | Lambda Merge Logic | 배치와 스트림 결과를 통합 (Timestamp, ID 기반 병합) | 실시간 데이터와 정제 데이터의 정합성 유지 | Serving Layer 병합 처리, 시간 우선 병합 로직 |
Serving Index / Data Store | 질의 성능을 위한 데이터 인덱싱 및 저장소 | 빠른 조회 응답, 사용자 API 대응 | Apache Druid, Presto, Cassandra, Elasticsearch | |
4. 메시지 처리 | Messaging / Buffering Layer | 데이터 생산자 ↔ 처리 계층 간 비동기 버퍼링 | 시스템 디커플링, 내결함성, 재시도 처리 | Apache Kafka, RabbitMQ, Pulsar |
5. API 및 질의 | Unified Query API | 배치 + 실시간 뷰를 API 수준에서 통합 질의 처리 | 사용자 요청에 최신 통합 결과 제공 | Flask + Redis + Spark SQL, GraphQL Gateway |
API Gateway / Result Cache | 통합 결과 제공 및 캐싱 계층 | 지연시간 감소, 캐시 효율성 | NGINX, FastAPI, Redis Cache | |
6. 운영 및 모니터링 | Monitoring & Alerting Tools | 상태 감시, 지표 수집, 이상 탐지 | SLA 보장, 운영 효율성 확보 | Prometheus, Grafana, ELK Stack, Jaeger |
Orchestration & Scheduling | 작업 스케줄링 및 의존성 관리 | 정기 실행, 장애 복구, 병렬 처리 | Apache Airflow, Oozie | |
7. 보안 및 안정성 | Secure Messaging & Data Access | 메시지/API 수준의 보안 및 인증 | 데이터 보호, 비인가 접근 방지 | TLS, mTLS, JWT, RBAC, Zero Trust Messaging |
배치 처리 구현 기법
정의: 대용량 데이터를 일정 주기로 모아서 처리하는 기법
구성:
- 스케줄러 (Apache Airflow, Oozie)
- 분산 컴퓨팅 엔진 (Apache Spark, Hadoop MapReduce)
- 분산 저장소 (HDFS, Amazon S3)
목적: 높은 처리량과 정확성을 통한 포괄적 데이터 분석
실제 예시:
|
|
스트림 처리 구현 기법
정의: 연속적으로 들어오는 데이터를 실시간으로 처리하는 기법
구성:
- 스트림 처리 엔진 (Apache Flink, Apache Storm)
- 메시지 큐 (Apache Kafka)
- 인메모리 저장소 (Redis, Apache Ignite)
목적: 낮은 지연시간으로 실시간 인사이트 제공
실제 예시:
|
|
통합 질의 구현 기법
정의: 배치 뷰와 실시간 뷰를 결합하여 통합된 결과를 제공하는 기법
구성:
- 질의 엔진 (Apache Druid, Presto)
- API 게이트웨이
- 결과 캐싱 레이어
목적: 사용자에게 일관되고 완전한 데이터 뷰 제공
실제 예시:
|
|
장점
카테고리 | 항목 | 설명 |
---|---|---|
1. 데이터 품질 및 정확성 | 정확성 보장 | 배치 계층에서 전체 데이터셋 기반의 정합성 높은 결과 제공 |
불변성 기반 복원 가능 | 데이터가 변경되지 않으므로 오류 시 재처리로 정확성 회복 가능 | |
휴먼 에러 대응력 | 잘못된 처리도 전체 재계산으로 정정 가능 | |
2. 실시간성과 신속성 | 실시간성과 지연 최소화 | Speed Layer 를 통해 지연 없이 빠른 응답 제공 |
최신 데이터 반영 | 스트림 기반 데이터가 즉시 조회 계층에 반영됨 | |
높은 처리량 균형 | 배치 처리와 실시간 처리의 장점을 동시에 활용 | |
3. 확장성 및 유연성 | 계층별 독립 확장 가능 | Batch/Speed/Serving Layer 를 개별적으로 확장 가능 |
다양한 기술 스택 적용 | 각 계층에 최적화된 기술 선택 가능 (예: Hadoop + Kafka + Cassandra) | |
유연한 처리 구조 | 다양한 데이터 처리 요구사항에 대응 가능 (실시간, 지연 허용 분석 등) | |
4. 장애 복원력 및 안정성 | 강력한 내결함성 (Fault Tolerance) | 계층 간 독립성으로 인해 한 계층의 장애가 전체에 영향을 미치지 않음 |
재처리 기반 복구 가능 | 오류나 장애 발생 시 불변 데이터셋 재처리로 복구 가능 | |
5. 운영 효율성 | 데이터 일관성 보장 | 실시간 + 배치를 조합하여 최신성과 정합성을 모두 확보 |
시스템 구성 단순화 가능성 | 각 계층의 역할이 분리되어 관리 및 유지보수 용이 |
6.10 단점과 문제점 그리고 해결방안
설계상 단점 (Structural Drawbacks)
카테고리 | 항목 | 설명 | 원인 또는 배경 | 해결 방안 |
---|---|---|---|---|
아키텍처 복잡성 | 계층 분리로 인한 복잡성 증가 | Batch, Speed, Serving 레이어의 독립 운영으로 전체 아키텍처가 복잡해짐 | 다중 처리 경로 및 연계 구성의 복잡성 | 자동화 도구 도입 (Airflow, Beam), 구조 간소화 및 명확한 책임 구분 |
코드 관리 | 배치/실시간 처리 코드 중복 | 동일한 비즈니스 로직이 두 번 구현되어 유지보수와 테스트 부담 증가 | 분리된 처리 방식, API 불일치 등 | Apache Beam, Spark Structured Streaming 등 공통 API 활용, 모듈화 구조 개발 |
비용 측면 | 인프라 및 운영 비용 상승 | 3 계층 분리로 리소스 소비가 중복되고 관리 비용 증가 | 이중 처리 및 고가용성 요구 | 클라우드 네이티브 서비스 활용 (Glue, Kinesis), 서버리스 기반 처리, 리소스 스케일 최적화 |
데이터 정합성 | 일관성 보장 지연 | 배치와 스트림 결과가 즉시 반영되지 않아 일시적으로 결과 불일치 발생 | 비동기 수집과 지연 처리의 차이 | 시간 기준 병합 전략, 데이터 버전 관리 및 배치 주기 최적화 |
유지보수성 | 장애 진단 및 운영 난이도 | 각 계층에 대한 모니터링과 복구 전략이 상이하여 통합 운영 난이도 증가 | 복잡한 계층 구조 및 로그 파편화 | 통합 로그 관리 시스템 구축, 장애 시나리오 자동화, 문서화 강화 |
운영상 문제점 (Runtime Issues)
카테고리 | 문제점 | 설명 | 원인 | 탐지 / 예방 / 해결 방안 |
---|---|---|---|---|
성능 병목 | 데이터 스큐 (Data Skew) | 일부 키에 데이터 집중 시 처리 병목 발생 | 파티셔닝 키 불균형, 데이터 쏠림 | 사전 분포 분석 → 솔트 키 (Salt Key) 적용, 동적 파티셔닝 |
처리 안정성 | 백프레셔 (Backpressure) | 소비 속도보다 빠른 데이터 유입으로 인한 메모리 고갈, 처리 실패 | 큐 과부하, 스트림 처리 속도 부족 | 큐 크기 모니터링, 버퍼 조절, 오토스케일링, Reactive Streams 적용 |
상태 관리 | 상태 관리 복잡성 | 스트림 처리 중 상태 유지, 복구, 파티셔닝의 어려움 | Checkpoint 지연, 상태 백업 미흡 | 분산 상태 저장소 (Flink RocksDB), 주기적 체크포인트, 상태 파티셔닝 |
결과 정합성 | Batch vs Speed 결과 불일치 | 사용자에게 시간대별로 다른 결과 노출 가능성 발생 | 배치/실시간 처리 시점 불일치 | Timestamp 기반 병합, 동일 기준 시점 적용, Serving Layer 에서의 보정 로직 적용 |
데이터 회복력 | 재처리 비용/부하 | 장애 또는 버그 발생 시 전체 재처리가 필요하여 성능과 비용에 큰 영향 | 이력 기반 처리 구조 부재 | 증분 처리 구조 도입 (Change Data Capture), Checkpoint 기반 증분 배치 처리 |
가용성 | 장애 시 전체 서비스 영향 | 하나의 계층 실패가 전체 응답 시스템에 영향을 미침 | 단일 지점 장애 (Single Point of Failure) 존재 | 계층 이중화 구성, 장애 탐지 → 자동 복구 스크립트 및 리트라이 로직 적용 |
최신성 | 데이터 지연 반영 | 배치 주기 지연 시 최신 데이터 미반영으로 사용자 경험 저하 | 긴 배치 간격, 느린 ETL 파이프라인 | 실시간 비율 확대, 배치 주기 단축, Stream-First 설계로 리디자인 |
일관성 검사 | 데이터 정합성 검증 미흡 | 배치/스트림 결과가 다를 경우 오류 감지가 늦음 | 검증 로직 미흡, 테스트 자동화 부족 | 데이터 검증 로직 추가 (hash match, 기준값 비교), 로그 기반 이상 탐지 |
도전 과제
카테고리 | 항목 | 문제 원인 / 특성 | 영향 및 문제점 | 해결 방향 |
---|---|---|---|---|
1. 설계 복잡도 | 코드 및 로직 중복 | Batch 와 Speed Layer 에서 유사한 데이터 처리 로직이 중복 구현됨 | 유지보수 난이도 상승, 로직 일관성 저하, 개발 생산성 저하 | 공통 유틸리티 추출, 코드 리팩토링, 스트림·배치 공용 DSL 도입 |
데이터 일관성 문제 | 두 계층이 다른 타이밍/경로로 동일 데이터를 처리함 | 최종 결과 불일치, 분석 결과 신뢰도 저하 | 통합 검증 도구 도입, Serving Layer 에서 보정 처리 적용 | |
2. 운영 복잡성 | 장애 격리 및 복구 어려움 | 계층이 분리되어 있어 장애 발생 시 연동 지점 복구가 복잡함 | 파이프라인 실패 복구 시간 증가, 장애 원인 추적 어려움 | Retry·DLQ 정책, 워크플로우 기반 복구 자동화 도입 |
운영 자동화 어려움 | 서로 다른 실행/스케줄 방식의 계층 운영이 병렬로 존재함 | 운영 비용 증가, 사람 의존도 상승 | 통합 오케스트레이션 툴 (Airflow, Dagster 등) 활용 | |
멀티 테넌시 | 여러 팀이 하나의 파이프라인을 공유하며 사용 | 리소스 경합, 데이터 충돌, 관리 비용 증가 | Namespace 분리, 우선순위 기반 리소스 관리 | |
3. 비용 효율성 | 중복 처리로 인한 자원 낭비 | 동일 데이터를 배치·스트림에서 각각 처리 | CPU, I/O, 저장소 비용 증가 | 처리 구조 단순화, 중복 작업 제거 |
복잡한 유지보수 및 인력 요구 | 파이프라인 수 증가 및 구성 복잡화로 인한 인력 투입 필요 | 운영 인력 과부하, 관리 실패 시 장애 확산 | 플랫폼화, 파이프라인 표준화 | |
4. 기술적 제약 | Exactly-Once 처리 보장 어려움 | 스트리밍과 배치의 일관된 트랜잭션 처리 어려움 | 중복 데이터 발생 또는 일부 누락으로 인한 데이터 오류 | Idempotency 설계, Transactional Producer 활용 |
스키마 진화 대응 | 메시지 구조 또는 테이블 스키마의 점진적 변경 | 소비자 측 처리 오류, 호환성 문제 | Avro, Protobuf 등 스키마 진화 지원 포맷 사용 | |
아키텍처 전환의 어려움 | 기존 구성과 워크플로우 의존성이 높음 | Kappa 등 대체 구조 도입에 진입 장벽 존재 | 추상화 레이어 도입 → 점진적 마이그레이션 | |
5. 데이터 품질 및 거버넌스 | 데이터 거버넌스 | 계층마다 보안, 품질, 추적 수준이 상이함 | 규정 준수 어려움, 데이터 오류 추적 어려움 | 린리지 추적 도구, IAM, 암호화 정책 도입 |
데이터 신뢰성과 품질 관리 | 중간 상태 데이터를 빠르게 소비하지만 품질 보장이 어려움 | 사용자 신뢰 하락, 오류 누적 | 품질 모니터링 도구 (Monte Carlo 등), 자동 테스트 도입 |
분류 기준에 따른 종류 및 유형
카테고리 | 분류 기준 | 유형 | 설명 |
---|---|---|---|
1. 처리 패러다임 | 처리 모델 | Lambda Architecture | Batch + Stream 을 분리하여 병렬로 처리하는 기본 모델 |
Kappa Architecture | 순수 Stream 기반 처리, 배치 제거로 구조 단순화 | ||
Hybrid Lambda | 일부 공통 로직 공유 및 처리 계층에 따라 병합 전략 적용 | ||
2. 처리 구성 방식 | 아키텍처 계층 구성 | 3-Tier Lambda | Batch, Speed, Serving 3 계층 분리 구성 |
처리 파이프라인 구성 | Dual Pipeline | Batch 와 Stream 이 각각 독립된 파이프라인으로 구현됨 | |
Unified Pipeline | 공통 처리 로직 또는 추상화를 통해 배치/스트림 간 재사용 가능 구조 | ||
3. 구현 방식 | 기술 적용 전략 | Native Lambda | Spark, Kafka 등을 직접 구성하여 구현 |
Managed Lambda | AWS Glue, Kinesis 등 클라우드 플랫폼을 활용한 관리형 구조 | ||
배포 환경 | 클라우드 네이티브 | 완전한 클라우드 기반 (AWS Lambda, Azure Functions 등) | |
온프레미스 | 자체 서버 인프라에서 운영 (Hadoop, Spark 등) | ||
하이브리드 클라우드 | 클라우드와 온프레미스 인프라를 조합하여 유연성 확보 | ||
4. 데이터 특성 | 데이터 입력 방식 | 이벤트 기반 | Kafka 등 이벤트 스트림 중심의 실시간 데이터 처리 |
시계열 기반 | 시간순 정렬된 데이터 (로그, 센서 데이터 등) 의 주기적 분석에 특화 | ||
5. 데이터 저장 구조 | 저장 방식 | 분산 저장 기반 | HDFS, S3, Parquet 등 확장성 높은 분산 파일 시스템 사용 |
뷰 구성 방식 | 머티리얼라이즈드 뷰 | 배치 또는 스트림 결과를 주기적으로 저장하여 빠른 질의 제공 | |
6. 운영 전략 | 운영 복잡도 관리 | 자동화 기반 | Orchestration (Airflow), 스케줄링, 상태 체크 등을 통한 운영 자동화 |
수동 통합 관리 | 수작업 중심 배치/스트림 관리, 운영 복잡도 증가 가능 |
Lambda Architecture vs. Kappa Architecture 비교
비교 항목 | Lambda Architecture | Kappa Architecture |
---|---|---|
핵심 개념 | Batch + Speed Layer 조합으로 실시간성과 정확성을 모두 확보 | 단일 스트림 처리 계층으로 실시간 데이터만 처리하며, 배치를 대체함 |
구성 계층 | Batch Layer, Speed Layer, Serving Layer | Stream Layer, Serving Layer (단순화됨) |
데이터 소스 | 실시간 스트림 + 배치 파일 모두 처리 | 실시간 스트림 중심 처리 (배치 파일도 스트림으로 리플레이) |
처리 방식 | 동일 데이터를 배치와 실시간 경로로 각각 처리 (이중 처리) | 하나의 스트림 파이프라인으로 처리 (단일 처리 경로) |
재처리 | 배치 계층으로 전체 데이터 재처리 | 스트림 리플레이 (replay) 기반 |
코드 및 로직 | 배치/실시간 로직 분리, 코드 중복 존재 가능 | 처리 로직 단일화로 중복 최소화 |
복잡도 | 계층 구성 및 파이프라인 복잡, 운영·모니터링 복잡도 높음 | 아키텍처 단순화, 유지보수 효율적 |
정확성 보장 | 배치 처리 기반으로 강한 정합성 및 재처리 용이 | 스트림 처리 기반으로 정합성 확보가 상대적으로 복잡 (Idempotency, Transaction 필요) |
장애 복구 | 불변 데이터로 인해 장애 시 재처리 기반 복구 가능 | 스트림 재처리는 가능하나 설계 및 저장소 구성에 따라 복잡 |
성능 특성 | 배치는 대량 처리에 유리, 실시간 처리는 지연 감소 목적 | 모든 처리 스트림 기반 → 실시간 처리에 최적화 |
기술 적합도 | Kafka + Hadoop + Spark/Flink (계층별 상이) | Kafka + Flink/KSQLDB (일관된 기술 스택) |
스키마 관리 | 계층 간 포맷 다름 → 스키마 호환성 고려 필요 | 단일 파이프라인으로 스키마 관리 일원화 가능 |
장점 요약 | - 정확성 보장 - 장애 복구 용이 - 유연한 계층 확장 | - 단순성 - 운영 효율 - 로직 일관성 유지 |
단점 요약 | - 복잡한 구성 및 운영 - 코드 중복 가능성 - 비용 증가 | - 정합성 보장 어려움 - 재처리 기반 복원 한계 |
적합한 경우 | 정확성과 실시간성을 모두 요구하는 복합 환경 | 실시간성과 개발 단순성이 중요한 환경 |
추천 사용 사례 | 대규모 정산, 비즈니스 크리티컬 분석, 정합성/정확성 우선 영역 | 실시간 피드, IoT 센서 분석, 사용자 행동 추적 등 빠른 반응 요구 영역 |
🔍 정리: Lambda Architecture 는 정밀성과 내결함성을 강조하는 반면, Kappa Architecture 는 실시간성과 단순성을 추구한다. 최근에는 Kappa 방식이 데이터 플랫폼에서 더 많이 채택되는 추세이다.
실무 사용 예시
도메인 | 사용 목적 | 기술 조합 | 기대 효과 |
---|---|---|---|
1. 로그 분석 | 실시간 이상 탐지 + 정확한 이력 분석 | Hadoop (Batch) + Storm/Flink (Stream) + Cassandra | 신속한 이벤트 대응, 보안 감사 기반 확보 |
2. 광고 분석 | 클릭/노출 로그의 실시간 분석 및 성과 정산 | Spark (Batch) + Kafka (Stream) + Cassandra/Redis | 타겟팅 최적화, 반응 속도 향상, 정확한 정산 |
3. 금융 서비스 | 실시간 사기 탐지 및 트랜잭션 정산 | Kafka + Flink (Speed) + Cassandra/HBase (Serving) | 리스크 감지 향상, 회계 일치, 응답 시간 단축 |
4. IoT 플랫폼 | 센서 이벤트 실시간 분석 및 이력 기반 이상 예측 | Spark/Storm + Kafka + InfluxDB/Grafana | 예지 정비, 유지보수 자동화, 장애 예방 |
5. 전자상거래 | 사용자 행동 기반 추천 및 개인화 모델 적용 | Spark + Kafka + Redis + Druid | 추천 정확도 향상, 매출 증대 |
6. 통신 네트워크 | 실시간 트래픽 감시 및 네트워크 이상 탐지 | Kafka + Samza + HBase | 네트워크 장애 예방, 복구 시간 단축 |
7. 미디어/OTT | 사용자 시청 패턴 실시간 수집 및 분석 | Pulsar + Druid + Elasticsearch | 콘텐츠 개인화, 시청률 향상, 이탈률 감소 |
8. 제조/산업 설비 | 생산 공정 및 품질 지표 실시간 모니터링 | Kafka + Flink + Time-series DB (e.g. InfluxDB) | 생산성 향상, 품질 이상 사전 감지 |
유형 분류 요약
카테고리 | 정의 | 대표 사례 |
---|---|---|
분석 중심형 | 실시간 이벤트 분석 + 배치 기반 통계 집계 결합 | 로그 분석, 시청 패턴 분석 |
정산/회계형 | 실시간 응답 + 정확한 정산을 위한 배치 보정 처리 구조 | 광고 분석, 금융 거래 |
예측/모니터링형 | 실시간 수집 → 상태 예측 및 이상 탐지 | IoT, 제조 설비, 네트워크 |
개인화/추천형 | 사용자 행동 실시간 추적 + 모델 학습/갱신 기반 추천 시스템 구현 | 이커머스, 미디어 |
플랫폼 통합형 | 다양한 이벤트 및 이력 정보를 통합 분석하여 거버넌스 및 통찰 확보 | 통신사, 대규모 IoT 플랫폼 |
활용 사례
사례 1: 광고 실시간 분석 시스템 (Real-time Ad Analytics)
시스템 구성:
- Batch Layer: 사용자 클릭 로그를 Spark 로 하루 단위 집계
- Speed Layer: Kafka + Flink 로 실시간 클릭 수 카운팅
- Serving Layer: Elasticsearch 에 batch + stream 결과 병합 저장
Workflow:
sequenceDiagram participant User as 광고 사용자 participant Kafka as Kafka (Ingestion) participant Flink as Speed Layer participant Spark as Batch Layer participant ES as Elasticsearch (Serving Layer) User->>Kafka: 클릭 로그 발생 Kafka->>Flink: 실시간 처리 Kafka->>Spark: 배치 입력 대기 Spark->>ES: 배치 결과 저장 Flink->>ES: 실시간 결과 저장 ES-->>User: 광고 성과 응답
Lambda Architecture 의 역할:
- 실시간으로 광고 클릭 성과를 대시보드에 표시 (Flink)
- 배치로 누적 성과 집계 및 이상 징후 검출 (Spark)
- Serving Layer 가 두 결과를 병합하여 제공
유무에 따른 차이점:
비교 항목 | Lambda 사용 | 미사용 (단일 처리) |
---|---|---|
실시간성 | 우수 | 낮음 |
정합성 | 보장 | 실시간 처리에 의존하여 낮음 |
장애 대응 | 재처리 가능 | 실시간 처리 실패 시 손실 위험 |
사례 2: 실시간 로그 분석 시스템
시스템 구성:
- 웹 서버 로그 → Kafka(메시지 큐) → Hadoop(배치 처리) + Storm(실시간 처리) → HBase(서빙) → 대시보드
Workflow:
- 로그 데이터가 Kafka 로 유입
- Hadoop 이 전체 로그를 배치로 분석
- Storm 이 최신 로그를 실시간 분석
- HBase 에 두 결과를 저장, 대시보드에서 결합 결과 조회
Lambda Architecture 의 역할:
- 실시간 이벤트 탐지, 정확한 집계, 장애 복원력
Lambda Architecture 유무에 따른 차이:
- 도입 전:
실시간성과 정확성 중 하나만 선택 가능, 장애 복원력 약함 - 도입 후:
실시간성과 정확성 동시 확보, 장애 복원력 및 확장성 강화
사례 3: 전자상거래 실시간 추천 시스템
시스템 구성:
- 데이터 소스: 웹 클릭스트림, 구매 이력, 상품 카탈로그, 사용자 프로필
- 수집 계층: Apache Kafka 를 통한 실시간 이벤트 수집
- 배치 레이어: Apache Spark 를 사용한 일일 협업 필터링 모델 학습
- 스피드 레이어: Apache Flink 를 통한 실시간 클릭스트림 분석
- 서빙 레이어: Redis 기반 실시간 추천 캐시, Apache Cassandra 기반 배치 추천 저장
graph TD subgraph "데이터 소스" WEB[웹 클릭스트림] ORDER[주문 데이터] PRODUCT[상품 카탈로그] USER[사용자 프로필] end subgraph "수집 계층" KAFKA[Apache Kafka<br/>실시간 이벤트 수집] end subgraph "배치 레이어" SPARK[Apache Spark<br/>협업 필터링 모델] HDFS[HDFS<br/>과거 데이터 저장] MODEL[추천 모델<br/>MLlib] end subgraph "스피드 레이어" FLINK[Apache Flink<br/>실시간 행동 분석] REDIS[Redis<br/>실시간 세션 추적] end subgraph "서빙 레이어" CASSANDRA[Apache Cassandra<br/>배치 추천 저장] CACHE[Redis Cache<br/>실시간 추천 캐시] API[추천 API<br/>Gateway] end subgraph "응용 계층" WEBSITE[전자상거래 웹사이트] MOBILE[모바일 앱] EMAIL[이메일 마케팅] end WEB --> KAFKA ORDER --> KAFKA PRODUCT --> KAFKA USER --> KAFKA KAFKA --> SPARK KAFKA --> FLINK SPARK --> HDFS HDFS --> MODEL MODEL --> CASSANDRA FLINK --> REDIS REDIS --> CACHE CASSANDRA --> API CACHE --> API API --> WEBSITE API --> MOBILE API --> EMAIL
Workflow:
- 데이터 수집: 사용자의 웹 브라우징, 구매, 검색 활동이 실시간으로 Kafka 에 수집
- 배치 처리: 매일 밤 Spark 를 통해 전체 사용자 행동 데이터 기반 협업 필터링 모델 학습
- 실시간 처리: Flink 를 통해 현재 세션의 사용자 행동을 실시간 분석하여 즉시 추천 업데이트
- 결과 통합: 배치 추천 (장기 선호도) 과 실시간 추천 (즉시 관심사) 을 결합하여 개인화된 추천 제공
Lambda Architecture 의 역할:
- 배치 레이어: 정확한 장기 사용자 선호도 모델링 및 상품 간 유사도 계산
- 스피드 레이어: 현재 세션의 즉시 관심사 반영 및 실시간 개인화
- 서빙 레이어: 두 레이어의 결과를 결합하여 최적의 추천 목록 생성
Lambda Architecture 유무에 따른 차이점:
구분 | Lambda Architecture 적용 | 기존 배치 처리만 적용 |
---|---|---|
추천 정확도 | 장기 선호도 + 실시간 관심사 반영으로 90% 정확도 | 과거 데이터 기반으로만 75% 정확도 |
응답 시간 | 실시간 추천으로 50ms 이내 응답 | 배치 처리로 24 시간 지연 |
사용자 경험 | 즉시 행동 변화 반영으로 높은 참여도 | 과거 선호도만 반영으로 낮은 적합성 |
비즈니스 효과 | 클릭률 25% 향상, 매출 15% 증가 | 기존 대비 개선 효과 제한적 |
구현 예시
Python: 전자상거래 추천 시스템의 핵심 구성요소
|
|
Python 기반, Kafka + Spark 구조
|
|
이 예시는 Speed Layer 의 실시간 분석 부분에 해당하며, Serving Layer 로는 Elasticsearch 또는 Redis 와 연동하여 실시간 UI 업데이트가 가능하다.
Python, Spark Streaming + Hadoop 기반
|
|
- 설명:
Kafka 에서 로그 데이터를 받아 Spark Streaming 으로 실시간 에러 로그를 탐지한다. 전체 로그 집계는 Hadoop 에서 별도로 수행한다.
실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점
카테고리 | 고려사항 | 설명 | 권장사항 |
---|---|---|---|
1. 아키텍처 설계 | 데이터 파티셔닝 전략 | 병렬 처리 및 확장성을 위한 파티셔닝 키 전략 수립 | 시간/사용자/지역 기반 등 도메인 맞춤 파티셔닝 적용 |
스키마 설계 | 처리 계층 간 스키마 호환성 확보 및 진화 대응 | Avro, Protobuf, Schema Registry 사용 | |
계층별 기술 스택 분리 | Batch / Speed / Serving 계층별 최적화 기술 선택 | Spark, Kafka, Cassandra, Redis 등 분리 조합 | |
2. 운영 및 모니터링 | 통합 모니터링 체계 구축 | 계층별 지표 수집, 장애 탐지, 알람 대응 시스템 구축 | Prometheus, Grafana, AlertManager 도입 |
코드/로직 중복 최소화 | 배치와 스트리밍에 동일 로직 반복 방지 | 공통 로직 추출 및 모듈화, 재사용 구조 설계 | |
Serving Layer 검증 | 실시간 결과와 배치 결과 간의 일관성 확보 | 정기 검증 Job, 결과 비교 로직 운영 | |
3. 성능 최적화 | 리소스 사용량 관리 | CPU, 메모리, I/O 등의 낭비 방지를 위한 관리 정책 수립 | 우선순위 기반 스케줄링, 리소스 격리, 동적 스케일링 |
캐싱 전략 | 반복 접근되는 Hot Data 에 대한 응답 속도 개선 | TTL 기반 다층 캐시, Redis, Memcached 활용 | |
백프레셔 대응 | 처리 지연 발생 시 스트림 흐름 제어 | Kafka Consumer Lag 모니터링, 처리율 제어 | |
4. 배포 및 운영 전략 | 무중단 배포 및 롤백 전략 | 실시간 계층 변경 시 다운타임 방지와 오류 회복 전략 | Blue-Green 배포, 카나리 롤아웃 적용 |
마이크로서비스화 | 계층 간 의존성 축소, 독립 배포 및 장애 격리 가능 | Docker + Kubernetes 기반 MSA 구성 | |
테스트 자동화 | 계층별 통합 테스트 및 재처리 시 검증 자동화 | Testcontainers, E2E Pipeline Test 구성 | |
5. 데이터 품질 및 관리 | 데이터 일관성 검증 | 배치/스트림 결과의 불일치 방지를 위한 자동화된 검증 메커니즘 | 결과 비교 자동화 스크립트, 해시/해당일 기준 검증 |
불변 데이터 보존 | 오류 복구와 재처리를 위한 원본 로그/이벤트의 불변성 확보 | Kafka log 보존 기간 설정, S3 Raw 저장소 구축 | |
스키마 검증 및 이상치 탐지 | 입력 데이터의 품질 확보 및 스키마 일탈 방지 | Schema Validator, 데이터 프로파일링 도구 활용 | |
백업 및 복구 | 시스템 장애 시 데이터 손실 최소화를 위한 정책 | 주기적 백업, 오브젝트 스토리지 이중화, DR 시나리오 구축 | |
6. 보안 및 거버넌스 | 멀티테넌시 자원 격리 | 다양한 팀/도메인 사용 시 리소스 충돌 최소화 | 네임스페이스, RBAC, 쿼터 기반 격리 정책 적용 |
민감 데이터 보호 | 데이터 전송 및 저장 중 보안 확보 | TLS, 데이터 마스킹, 필드 암호화 적용 | |
접근 제어 및 감사 로그 관리 | 운영 인프라에 대한 무단 접근 방지 및 변경 추적 | IAM 정책, API 접근 로그 저장, 감사 트레일 구축 |
최적화하기 위한 고려사항 및 주의할 점
카테고리 | 최적화 요소 | 설명 | 권장 사항 |
---|---|---|---|
1. 처리 성능 | 배치 크기 조정 | 마이크로 배치 단위 조절을 통해 처리량과 지연 시간 간 균형 확보 | Spark 의 trigger.batch 조정, adaptive batch 사용 등 |
병렬도 최적화 | 파티션 수와 실행 병렬도 조절로 처리 속도 향상 | CPU, 메모리, 네트워크 대역폭 기반 병렬도 설정, Kafka 파티션 조정 | |
데이터 병합 전략 | Serving Layer 에서 배치·스트림 중복 제거 및 정합성 보장 | 시간 우선 병합 (Timestamp Priority Merge), ID 기반 Deduplication 적용 | |
Speed Layer 튜닝 | 스트림 지연 최소화를 위한 Kafka 및 처리엔진 설정 최적화 | Kafka 의 Topic 파티션 분산, 소비자 그룹 병렬 구성, low-latency 모드 활성화 | |
2. 자원 관리 | 배치 작업 최적화 | 리소스 과다 사용 방지를 위한 증분 처리 및 필터링 적용 | Delta 방식 증분 배치, 데이터 전처리 필터, predicate pushdown |
상태 저장소 최적화 | 스트림 처리 시 상태 저장 성능 향상 및 메모리 사용 최소화 | RocksDB 튜닝, 상태 압축 사용, 증분 체크포인팅 | |
JVM 메모리 튜닝 | GC 튜닝을 통한 처리 안정성 및 지연 최소화 | G1GC 사용, 힙 메모리 설정, GC 로그 기반 모니터링 | |
3. 네트워크 효율 | 데이터 압축 | 전송량 감소 및 I/O 병목 완화를 위한 압축 기법 적용 | Snappy, LZ4, ZSTD 등 알고리즘 선택, Producer 압축 설정 |
배치 전송 전략 | 네트워크 오버헤드 최소화를 위한 메시지 묶음 처리 | Async I/O, Batching, Connection Pool 활용 | |
4. 저장소 최적화 | 데이터 레이아웃 구성 | 질의 최적화를 위한 파티셔닝, 컬럼형 저장 구조 설계 | Parquet 포맷, 날짜/키 기반 파티셔닝, Z-Ordering |
압축 및 인코딩 | 저장 공간 절약과 처리 성능 향상 | Dictionary Encoding, RLE, Delta Encoding | |
5. 장애 복원성 | 장애 대응 전략 | 각 계층 장애 시 자동 복구 및 리트라이 체계 확보 | Airflow 재시도 설정, Kafka consumer 리트라이, Serving Layer fallback 처리 |
상태 복구 및 재처리 | 중단 시 지연 최소화를 위한 상태 기반 재처리 구조 설계 | Checkpoint 주기 설정, offset 저장, 증분 로그 기반 복구 | |
6. 비용 최적화 | 오토스케일링 | 사용량에 따라 동적 리소스 할당 및 클러스터 크기 조절 | Kubernetes HPA, AWS Auto Scaling Group, Spark Dynamic Allocation |
서버리스 활용 | 관리형 인프라를 통한 비용 절감 및 운영 단순화 | AWS Glue, Kinesis Data Analytics, Azure Stream Analytics | |
7. 운영 신뢰성 | 테스트 자동화 | 파이프라인 변경 시 회귀 방지 및 신뢰성 확보 | 데이터 컨트랙트 테스트 (dbt), 통합 테스트 (Testcontainers), Smoke Test 구성 |
모니터링 및 알림 | 성능 저하 및 장애 조기 감지를 위한 상태 감시 체계 구축 | Prometheus + Grafana, Kafka Metrics, 로그 기반 Alert 설정 |
주제와 관련하여 주목할 내용
카테고리 | 주제 | 항목 | 설명 |
---|---|---|---|
1. 아키텍처 특성 | Lambda Architecture | 이중 처리 구조 (Batch + Speed) | 정확성과 실시간성 동시 확보, 일관성 보장 |
Serving Layer | 빠른 조회 계층 | 처리된 결과를 사용자 요청에 빠르게 서빙 | |
2. 핵심 기술 스택 | 메시징/전송 | Apache Kafka | 배치/스트림 데이터의 분기와 전달을 담당 |
스트림 처리 | Apache Storm, Flink, Spark SS | 실시간 이벤트 흐름 처리에 특화된 엔진 | |
배치 처리 | Hadoop, Apache Spark | 대규모 데이터셋의 일괄 처리 담당 | |
서빙 스토리지 | Elasticsearch, Cassandra | 결과 데이터를 위한 빠른 질의 지원 | |
워크플로 엔진 | Apache Airflow, Prefect | 배치 작업 스케줄링 및 관리 | |
3. 대안 아키텍처 | Kappa Architecture | 스트림 중심 단일 처리 모델 | 배치 제거, 실시간 처리 일원화로 복잡도 감소 |
Delta Architecture | 통합 스토리지 계층 | Delta Lake 기반 배치/스트림 통합 처리 | |
4. 진화된 프로그래밍 모델 | Apache Beam | Unified API | 배치 + 스트림 처리를 단일 API 로 구성 가능 |
Structured Streaming | SQL 기반 실시간 스트리밍 처리 | Spark 의 구조적 스트리밍 기능 | |
5. 클라우드 서비스 | AWS Lambda + Kinesis | 서버리스 Lambda 아키텍처 구현 | 배치 및 스트림 처리를 클라우드 기반으로 단순화 |
Azure Stream Analytics | 관리형 실시간 분석 서비스 | 실시간 SQL 쿼리 기반 분석 | |
6. 운영 및 배포 환경 | Kubernetes | 컨테이너 기반 오케스트레이션 | 각 계층의 독립 배포와 자원 격리 실현 |
Terraform/Ansible | IaC 기반 인프라 자동화 | 환경 구성의 일관성 및 확장성 확보 | |
Prometheus + Grafana | 통합 모니터링 및 알림 | 계층별 지표 수집과 실시간 상태 추적 | |
7. 활용 및 적용 사례 | 로그/보안 분석 | Lambda + Elastic Stack | 실시간 탐지 + 정밀 분석 병행 |
IoT + 센서 데이터 | Kafka + Spark/Flink | 이벤트 중심 이상 탐지 및 트렌드 분석 | |
실시간 광고/추천 시스템 | Lambda + Redis | 실시간 반응형 피드백 제공 |
- 아키텍처 관점: 이중 처리 구조를 통한 정확성과 실시간성 트레이드오프 해결
- 기술 구성: Kafka + Spark/Flink + Elasticsearch 조합이 전형적
- 비교 아키텍처: Kappa(단순화), Delta(통합성), Beam(프로그래밍 통일성)
- 클라우드 전략: Lambda + Kinesis 또는 Azure SA 로 서버리스 대체 가능
- 운영 환경: Kubernetes 와 IaC, 통합 모니터링 툴로 안정적 운영 필수
반드시 학습해야할 내용
카테고리 | 주제 | 항목/개념 | 설명 / 학습 필요성 |
---|---|---|---|
1. 분산 시스템 기초 | CAP 정리 | Consistency, Availability, Partition Tolerance | 분산 시스템에서의 핵심 트레이드오프 원칙 이해 |
분산 합의 알고리즘 | Raft, PBFT | 일관성 보장을 위한 리더 선출 및 상태 동기화 알고리즘 학습 | |
Immutable Data | 불변 데이터 구조 | 재처리 가능성과 데이터 정합성 확보에 필요한 기반 설계 원칙 | |
2. 데이터 처리 모델 | Lambda vs Kappa Architecture | 아키텍처 비교 | Batch+Stream 분리 vs 단일 스트림 모델, 설계 선택 시의 기준 이해 |
Batch ETL | Hadoop, Spark | 대용량 데이터 집계 및 변환 처리에 필요한 프레임워크와 처리 모델 학습 | |
Stream Processing | Kafka, Flink, Storm | 실시간 데이터 처리 아키텍처와 스트림 처리 엔진 비교 분석 | |
이벤트 시간 vs 처리 시간 | Watermarking | 지연 이벤트를 정확하게 처리하기 위한 타임 윈도우 개념 및 처리 시간 기준 차이 이해 | |
정확히 한 번 처리 | Exactly-once Semantics | 메시지 중복 방지 및 데이터 손실 방지를 위한 스트림 신뢰성 처리 기법 | |
3. 데이터 모델링 및 아키텍처 | 이벤트 소싱 (Event Sourcing) | Event Store | 상태 대신 이벤트 저장을 통한 변경 이력 보존 및 재구성 구조 학습 |
CQRS 패턴 | Command / Query 분리 | 읽기와 쓰기의 책임 분리로 인해 확장성과 유연성이 향상되는 설계 패턴 이해 | |
Kappa Architecture | 단일 스트림 기반 처리 아키텍처 | Lambda 아키텍처의 대안 구조로, 유지보수성과 실시간성 중심 환경에 적합 | |
4. 성능 최적화 기법 | 백프레셔 관리 | Flow Control | 스트림 과부하 방지를 위한 처리 속도 조절 및 시스템 안정성 확보 기법 |
로드 밸런싱 | 부하 분산 전략 | Hotspot 제거 및 트래픽 분산을 통한 처리 효율 향상 | |
Serving Layer 병합 전략 | 실시간/배치 뷰 통합 처리 방식 | 시간 우선 병합, 중복 제거 전략 등 최종 사용자 응답 일관성 확보 | |
5. 저장 및 서빙 기술 | 서빙 데이터베이스 | HBase, Cassandra | 대용량 데이터의 빠른 조회와 쓰기를 지원하는 NoSQL 기반 서빙 레이어 이해 |
데이터 저장 최적화 | 컬럼형 저장, 파티셔닝 | 분석 효율성과 비용 절감을 위한 저장 구조 설계 전략 | |
6. 운영 및 모니터링 | 시스템 모니터링 및 알림 | Prometheus, Grafana | 지표 수집, 대시보드 시각화, 알림 설정을 통한 시스템 상태의 실시간 관리 |
로그 및 상태 추적 | ELK Stack, Checkpointing | 장애 분석, 상태 복구, 운영 이력 파악을 위한 필수 도구 및 기법 | |
테스트 자동화 | dbt test, Testcontainers | 전체 파이프라인에 대한 신뢰성 확보와 변경 안정성 확보를 위한 자동화 테스트 전략 |
- 이론/설계/구현/운영의 4 단계 흐름을 반영하여 실무 적용까지 고려한 분류
- 각 항목은 실제 Lambda 구현 시 꼭 필요한 기초 및 고급 요소를 포함
- 중복 항목 제거, 의미 중복은 통합 (예: 이벤트 소싱 + CQRS → 모델링 카테고리로 통합)
용어 정리
카테고리 | 용어 | 설명 |
---|---|---|
데이터 처리 방식 | 배치 처리 (Batch Processing) | 일정량의 데이터를 모아 정해진 시점에 일괄 처리하는 방식 |
스트림 처리 (Stream Processing) | 데이터가 생성되는 즉시 처리하는 방식으로, 실시간 반응 가능 | |
아키텍처 구성 요소 | Batch Layer | 전체 데이터셋 기반으로 정확한 결과를 생성하는 계층 (정확성 중시) |
Speed Layer | 최신 데이터를 빠르게 처리하는 실시간 계층 (신속성 중시) | |
Serving Layer | 배치와 스트림 처리 결과를 병합하여 사용자 요청에 응답하는 계층 | |
데이터 저장 방식 | 분산 저장소 (Distributed Storage) | 데이터를 여러 서버에 분산 저장하여 확장성과 가용성 확보 |
핵심 개념 | 불변성 (Immutability) | 데이터는 수정되지 않으며, 추가만 가능하도록 보존됨 |
재계산 (Recomputation) | 장애 발생 시 전체 데이터를 기반으로 결과를 다시 생성하는 방식 | |
뷰 (View) | 처리된 데이터 결과를 미리 계산한 집계 또는 변환된 형태 | |
기술 메커니즘 | 백프레셔 (Backpressure) | 처리 속도보다 빠른 입력으로 인해 발생하는 시스템 부하 현상 |
워터마킹 (Watermarking) | 지연 데이터를 정확히 처리하기 위한 기준 시간값 설정 방식 | |
체크포인팅 (Checkpointing) | 스트림 처리 중 상태를 저장하여 장애 복구 시 복원 가능하도록 지원 | |
메시징 시스템 | Apache Kafka | 스트리밍 데이터의 발행과 소비를 담당하는 고성능 메시지 브로커 |
아키텍처 유형 | Lambda Architecture | 배치와 스트림 처리를 결합한 하이브리드 아키텍처 |
Kappa Architecture | 스트림 기반 단일 파이프라인 아키텍처로, Lambda 의 단순화 모델 | |
Delta Architecture | 배치와 스트림을 동일한 테이블/스토리지에서 처리하는 통합 모델 | |
성능 지표 | 처리량 (Throughput) | 단위 시간당 처리 가능한 데이터의 양 |
지연시간 (Latency) | 데이터가 입력되어 결과가 나올 때까지 걸리는 시간 | |
가용성 (Availability) | 시스템이 오류 없이 사용 가능한 시간 비율 |
참고 및 출처
- Lambda Architecture 기본 개념 – Databricks
- Build a big data Lambda architecture for batch and real‑time analytics – AWS Blog
- Lambda Architecture – Wikipedia
- Apache Spark Structured Streaming Programming Guide
- Apache Hadoop 공식 문서
- Lambda Architecture 글 – Martin Fowler Bliki
- Serverless 아키텍처 – Martin Fowler
- Spark Streaming Programming Guide