대용량 데이터 처리 시 고려사항

대량 데이터 처리 시 고려사항은 단순히 빠르게 처리해야한다가 아니다.

 아래의 5가지로 나눠볼수 있다.
성능(Performance), 안정성(Stability), 정합성(Consistency), 확장성(Scalability), 데이터 품질(Data Quality)

성능(Performance)

대용량을 처리하는 프로세스는 아래 참고!

2025.08.21 - [역량 UP!/Architecture] - 용어정리) OLTP, OLAP란?

2016.09.28 - [OS/Linux&Unix] - BATCH, OLTP,OLAP,DW 정의

• Data의 특성에 맞게 처리를 해주면 됩니다.
• 3가지 영역으로 보면
  • Infra : Server를 늘려주거나(Scale-out), 네트워크(LB), CDN, Cache 

• DB : 데이터 저장 구조라고 볼수 있는데
  • 인덱스, 파티셔닝, 샤딩, 캐시, CQRS

• Application : 데이터 특성에 맞게 Batch, OLTP 등 
  • Batch, Stream, 비동기, 큐, 병렬처리 등 

성능 최적화 관점 정리

Q. 내가 해왔던 프로젝트 중에 성능을 높여주기 위해 

확장성(Scalability)

트래픽이 미친 듯이 늘어날때 시스템이 어떻게 버티느냐에 대한 이야기!
다시 말해 사용자가 늘어나거나 데이터가 폭증해도 서비스 성능을 유지할 수 있는 능력!
: 시스템이 더 많은 요청을 더 많은 자원으로 처리 할 수 있어야 한다.

확장방식은 2가지가 있습니다.
Scale-UP(수직 확장)과 Scale-Out(수평확장)

1) Scale-UP : 한 서버의 스펙을 올림(CPU, RAM 증설)
2) Scale-Out : 여러 서버로 부하를 나눔
Kafka나 HBase같은 친구들은 수평확장이 기본으로 설계된 시스템 입니다.

Scale-Out 구조로 부하를 분산 시킵니다.
tip. 확장을 하려면 상태가 없어야 합니다.(Stateless 설계) 그래서 보통 상태 등은 따로 외부 메타 데이터 저장소에서 관리가 됩니다.

정합성(Consistency)

정합성은 분산환경(MSA)에서 데이터의 시점이 다를 수 있어서 나타나는 문제(각 모듈별로 DB를 가짐)
대용량 트래픽 환경에서 그 빈도와 영향은 당연히 커짐!

Saga, Outbox, 멱등처리가 요구 됨.

2025.10.24 - [역량 UP!/Architecture] - MSA에서 분산 트랜잭션 처리는?(Saga+outbox)

2025.10.24 - [역량 UP!/Architecture] - Saga Pattern(outbox pattern) 좀 더 보기!

안정성(Reliability)

대용량 트래픽이면 장애를 피할수가 없으니 장애시에 다운이 아닌 버티고 복구할 수 있게 설계를 해야한다는게 핵심!

1) Retry+Backoff(재시도+ 점진적 대기)

• API, Kafka consumer, DB connection 모두에서 적용 가능
• 무한 루프 방지 위해 최대 재시도 횟수 지정
• Spring Retry, Resilience4j, Kafka Connect Retry 등으로 쉽게 구현 가능

2) DLQ(Dead Letter Queue)

• ex) Kafka Consumer에서 메시지를 소비하다가 에러 발생! -> 재시도 해도 도저히 안되는 메시지는 어떻게 해야하나?
  계속 실패하면 consumer는 멈춰버림!!
• 메시지 유실 방지 (안 사라지고 DLQ에 남음)
• 운영 시, DLQ는 “이상 징후 탐지용”으로도 사용됨
• AWS SQS, Kafka Connect, RabbitMQ 등 모두 DLQ 지원함

참고 : 2025.08.21 - [역량 UP!/Architecture] - 비동기 아키텍처(=Asynchronous Architecture)

3) Replication(복제)

여러 시스템들이 Replica를 제공 함.

4) 모니터링&알림(Observability)
대용량 트래픽 환경에서 장애보다 더 무서운건? 바로 장애를 모르는것!! ㄷㄷ 
문제가 생길 확률이 높으니 그걸 빨리 알아야 대응이 가능!!

모니터링+로깅+알림 시스템 필수

모니터링 지표

• Kafka Lag (메시지 적체량)
• API Error Rate
• Redis Latency
• DB Connection Pool 사용률
• CPU / Memory / Network
• 응답지연(latency)과 타임아웃 발생률

ex 면접용) 내 생각 ㅋㅋ 
저는 Latency를 가장 중요하게 봅니다.
특히 분산 환경에서는 한 서비스의 응답 지연이 다른 서비스의 타임아웃으로 번지기 때문입니다.
Error Rate는 그 결과고, Throughput은 원인이 될 수 있지만
실시간 감지 및 빠른 대응을 위해서는 Latency가 제일 빠른 신호라고 생각합니다.

데이터 품질(Data Quality)

대용량 트래픽 환경에서 정합성이 시점차이 문제라면 데이터품질은 내용 자체가 잘못된 문제입니다.

"트래픽이 많아질 수록 데이터가 더러워진다!"
누락, 중복, 오류가 조금만 생겨도 대규모 시스템에서는 눈덩이처럼 번짐!
정확한 데이터를 유지하기 위한 품질 관리가 핵심!

해결방향

1) Validation Layer(입력 검증 계층)
잘못된 데이터를 들어올 때 막자!

• API나 Kafka Consumer(소비)가 데이터를 받자마자 형식과 필드 유효성 검증!
  ex) user_id null 여부, price 음수 여부, timestamp 누락 등
• Json Schema / @Valid 등으로 구현 

public class OrderRequest {
    @NotNull private String orderId;
    @Min(1) private int quantity;
    @Positive private BigDecimal price;
}

2) Schema Registy(스키마 관리)
이벤트 버전이 달라져도 깨지지 않게 하자!

Kafka를 쓰면 서비스들끼리 이벤트(Json, Avro, Protobuf)를 주고 받는데
이때 스키마(필드 구조)가 바뀌면 Consumer가 깨질수 있음
->  Kafka Schema Registry가 나옴!

• 이벤트 구조를 중앙에 등록하고 버전을 관리
• 필드 추가는 되지만 삭제는 안됨!(Forward Compatible)
• Schema ID를 메시지에 포함 -> Consumer는 버전별 파싱 가능

{
  "schemaVersion": 3,
  "type": "OrderCreated",
  "fields": {
    "orderId": "O123",
    "price": 10000,
    "currency": "KRW"
  }
}

결론적으로 Kafka Schema Registry가 이걸 관리해서 다른 팀이 이벤트 필드를 변경해도 Consumer 장애 없이 호환하게 해줍니다.

3) Audit Log & Checksum(무결성 검증)
데이터가 어디서 어떻게 바뀌었는지 추적이 가능해야 합니다.

• Audit Log
  • DB나 이벤트 로그에 누가, 언제, 무엇을, 어떻게 변경했는지 기록.
    • 장애 시 원인 추적 가능!
• Checksum
  • 데이터 무결성 검증을 위해 Hash(MD5, CRC32 등) 값 저장.
    • CDC(Change Data Capture) 파이프라인에서 데이터 손실 감지 가능.

CREATE TABLE order_audit_log (
  id BIGINT AUTO_INCREMENT,
  order_id VARCHAR(50),
  action VARCHAR(20),      -- "CREATE", "UPDATE"
  old_value JSON,
  new_value JSON,
  updated_by VARCHAR(50),
  updated_at DATETIME
);

장애나 보정 시 무엇이 언제 왜 달라졌는지 쉽게 확인 가능.

4) 보정(Recovery)과 검증(배치 Job)
모든 시스템은 언젠가 어긋난다. 결국 보정 로직이 필요하다.

• 배치 Job이나 Airflw DAG로 정합성 검증 작업 주기적 수행
• 주문↔결제, 결제↔정산 간 데이터 비교
• 누락/불일치 발견 시 알림 또는 자동 복구

ex) 매 1시간 마다

 → order, payment 테이블 비교
 → 상태 불일치 시 Kafka ‘ReconcileNeeded’ 이벤트 발행
 → 수동/자동 복구 처리

대용량 트래픽에서는 데이터가 많아지는 만큼 정확성(Data Quality) 이 깨지기 쉽습니다.

Validation Layer로 잘못된 데이터 유입을 차단하고
Kafka Schema Registry로 이벤트 구조의 버전 호환성을 유지하며
Audit Log와 Checksum으로 데이터 변경 이력을 추적합니다.
또한, 주기적으로 정합성 검증 배치로 시스템 간 누락과 불일치 데이터를 보정 합니다.

실시간성보다 더 중요한 건 신뢰할 수 있는 데이터 입니다.
대규모 트래픽 환경에서는 속도보다 정확성을 유지하는 구조가 장기적으로 시스템을 살립니다