이번 포스트에는 프로듀서, 브로커, 컨슈머를 제외한 나머지들 이상 데이터를 탐지할 때, 백업 방법, 모니터링 과 분석용 툴들을 정리해보고 최종 파이프라인을 그려보고 운영 단계에서 효율적이라고 생각하는 최종 파이프라인을 구성해보겠습니다.
1편(broker 비교, kafka vs kinesis)
https://spidyweb.tistory.com/599
2편(consumer 비교, flink, spark streaming, kafka streaming, logstash, kinesis firehose)
https://spidyweb.tistory.com/600
3편(이상 데이터 탐지, 백업, 모니터링, 분석, 파이프라인 및 최종)
https://spidyweb.tistory.com/601
1. 이상 데이터 탐지
굳이 파이프라인상에서의 앞단과 뒷단의 이상탐지로 나누게 된다면 다음과 같습니다.
- schema registry
- elasticsearch와
1) (Glue) Schema registry
데이터가 produce되고 consume 되는 과정에서 구조 상으로 깨진 데이터가 들어온 것을 미리 감지할 수 있는 실시간 처리 파이프라인 상에서 비교적 앞단에 존재하며, 데이터 스키마(구조) 관리 관점에서 중요한 역할을 함
Glue Schema Registry vs Confluent Kafka Schema Registry
| 항목 | Kafka Schema Registry (Confluent) | AWS Glue Schema Registry |
| 소속 | Confluent (Kafka 전용 도구) | AWS Glue (AWS 생태계 전용) |
| 지원 포맷 | Avro, JSON Schema, Protobuf | Avro, JSON, Protobuf |
| 통합 | Kafka 중심 (Kafka Producer/Consumer에서 tightly coupled) | AWS Kinesis, Kafka, Lambda, MSK, Spark, Flink 등과 통합 |
| Schema Evolution | 지원 (백워드/포워드 호환성 설정 가능) | 지원 (Schema compatibility validation 제공) |
| 보안 | RBAC, 인증 등 강력한 보안 | IAM 기반 권한 제어 |
| 운영방식 | 사용자 직접 운영 또는 Confluent Cloud | Fully managed (Glue 내 서비스로 제공) |
| Schema 조회 및 관리 | REST API, UI 제공 | AWS Console, CLI, SDK 제공 |
| 비용 | Confluent: 유료 / 오픈소스는 직접 운영 | Glue Schema Registry 자체는 무료 |
Producer가 Kafka에 데이터를 보낼 때
- 직렬화 전에 Schema Registry에 요청
- 기존 스키마인지 확인 (스키마 ID 조회)
- 없으면 새 스키마 등록 → 새로운 스키마 ID 발급
- Kafka에 [magic byte + schema ID + 직렬화된 데이터] 형식으로 전송
- 이때 Schema Registry는 스키마 ID 제공자 역할
Consumer가 Kafka에서 데이터를 읽을 때
- 메시지를 보면 schema ID만 있음
- Schema Registry에서 해당 ID에 해당하는 스키마를 조회
- 스키마 기반으로 역직렬화(deserialize) 수행
- 이때 Schema Registry는 스키마 정보 제공자 역할
2) ElasticSearch
- 데이터 파이프라인상에서 비교적 뒷단에서 consume된 데이터를 이용하여 실시간 탐지 및 시각화 기반의 로그/이벤트 이상 탐지 및 알림에 적합
- 정형화되지 않은 로그 데이터나 이벤트 스트림에서 실시간 패턴 이상을 탐지하기 위한 강력한 기능을 제공
데이터 인덱싱
- Kafka → Logstash / Fluentd / Kafka Connect → Elasticsearch
- 데이터는 JSON 형태로 인덱싱되며 timestamp 필드 포함
이상 탐지 방식
| 탐지 방법 | 설명 |
| Threshold 기반 | 특정 필드의 값이 임계치를 넘으면 경고 (e.g. 응답시간 > 1s) |
| Anomaly Detection (ML 기능) | Elasticsearch의 Machine Learning 모듈 사용해 과거 데이터로 이상 패턴 학습 |
| Watchers (Alert) | 조건 설정하여 실시간으로 슬랙/메일 알림 |
| Kibana Dashboard 시각화 | 특정 로그 분포 이상, 요청 수 급증/급감 등을 실시간 시각화 |
| Histogram/Moving Average | 시간에 따른 평균 대비 이상치 판단 가능 |
2. 백업 저장소
consume하여 S3에 저장 된 데이터는 곧장 활용됩니다. 하지만 데이터 복구를 위한 백업의 방법도 필요한데, S3에 기능들을 활용하여 백업 정책을 만들어 두면 될 것 같습니다.
- lifecyle을 걸어두어 일정 기간이 지난 데이터는 glacier로 tiering하는 정책 생성
- data 유실 방지를 위한 multi region replication
3. 모니터링
Kafka Exporter + Prometheus + Grafana
모니터링으로는 kafka cluster에서 metric을 수집하여 prometheus로 보낼 수 있는 kafka exporter를 사용합니다.
prometheus로 보내진 metric을 Grafana에서 원하는 대시보드를 생성하여 시각화하고, 특정 기준치에 대한 알람도 발송을 할 수 있습니다.
4. 실시간 분석 및 시각화
ElasticSearch + Kibana
S3에 데이터를 전송함과 동시에 ElasticSearch에도 데이터를 전송합니다. 해당 데이터는 앞에서 언급한 것과 마찬가지로 데이터 이상 패턴 감지에도 활용되며, 데이터 실시간 분석 및 검색과 Kibana를 통한 시각화에 사용됩니다.
5. 최종 파이프라인
최종적으로 운영에서 실행 될 수 있는 효율적인 실시간 처리 데이터 파이프라인은 다음과 같이 구성되는게 맞지 않을까 싶습니다.
- Producer 역할을 하는 Ingestiopn 서버를 클러스터로 구성하여 MSK로 전송
- MSK로 procude, 로부터 consume되기 전에 Kafka Schema Registry와 같은 역할을 하는 AWS Glue Schema Registry를 통해 이상 데이터 탐지
- MSK를 통한 운영 및 관리 포인트 최소화, 카프카 브로커 역할 수행
- 따로 EC2 혹은 k8s에 kafka exporter를 두어 관련 메트릭을 Prometheus로 전송 및 Grafana로 시각화
- flink cluster(혹은 managed flink)를 통해 MSK로부터 데이터를 Consume
- 데이터 저장소로 S3 및 Avro파일 형태로 데이터를 저장 및 lifecycle을 걸어 두어 Glacier로 내려가게 끔 백업용 데이터로 보관 및 recplication
- ElasticSearch(Opensearch)로 데이터를 동시에 보내어 실시간 분석 및 검색, 이상 탐지, kibana와 연동한 시각화
댓글