고가용성(High Availability, HA)은 시스템이 장애 상황에서도 지속적으로 운영될 수 있도록 설계하는 개념이다.
특히 분산 환경이나 클라우드 기반 데이터 인프라에서는 서비스 중단과 데이터 유실을 최소화하는 것이 핵심 목표가 된다.
이때 시스템 복구 전략을 정의하는 핵심 지표로 RPO(Recovery Point Objective)와 RTO(Recovery Time Objective)가 사용된다.
1. RPO (Recovery Point Objective)
RPO는 장애가 발생했을 때 복구 가능한 데이터의 최신 시점을 의미한다.
즉, 데이터 유실을 허용할 수 있는 최대 시간을 나타낸다.
예를 들어 RPO가 10분이라면, 장애가 발생하더라도 최대 10분 전까지의 데이터만 복구되면 된다.
이는 백업 주기나 로그 복제 주기와 직결된다.
| 시스템 | RPO 목표 | 의미 |
|---|---|---|
| 금융 트랜잭션 DB | 0분 | 실시간 복제 필요 |
| 로그 분석 시스템 | 30분 | 배치 기반 복제 가능 |
| 정적 웹 서비스 | 1일 | 일일 백업으로 충분 |
관련 기술 예시
- Hadoop HDFS: NameNode와 Secondary NameNode 복제 설정을 통해 데이터 복구 포인트 보장
- Amazon EMR: S3 버킷을 지속형 스토리지로 설정하면, 클러스터 장애 시에도 데이터를 복구 가능
- Kafka: 토픽 복제(replication factor)를 통해 메시지 손실 없이 장애 시 재처리 가능
- Snowflake: Time Travel 기능으로 지정된 시점의 데이터 상태로 복원 가능
2. RTO (Recovery Time Objective)
RTO는 장애가 발생한 후, 서비스가 정상 복구되기까지 허용 가능한 최대 시간을 의미한다.
즉, 다운타임에 대한 목표값이다.
예를 들어 RTO가 5분이라면, 장애 발생 후 5분 내에 시스템이 정상 상태로 돌아와야 한다.
| 시스템 | RTO 목표 | 복구 전략 |
|---|---|---|
| 실시간 결제 서버 | 0~1분 | 장애 자동 감지 및 Failover |
| 분석 파이프라인 (Airflow) | 10분 | DAG 재시작 및 작업 재시도 |
| 로그 시각화 대시보드 (ELK) | 1시간 | 인덱스 재빌드 및 캐시 복구 |
관련 기술 예시
- Zookeeper: 분산 시스템의 리더 선출과 상태 감시를 통해 빠른 장애 전환(Failover) 지원
- Airflow: 태스크 재시도(retry), SLA 미준수 알림 기능으로 복구 시간 단축
- Kubernetes + Spark: Pod 재시작 정책 및 Executor 자동 재배치를 통해 RTO 최소화
- AWS Auto Scaling: 인스턴스 장애 발생 시 자동으로 대체 리소스 실행
3. RPO와 RTO의 상관관계
RPO와 RTO는 서로 독립적이지만, 함께 고려해야 한다.
두 지표는 비용과 안정성 사이의 균형을 결정한다.
- RPO ↓, RTO ↓ → 비용 ↑ (실시간 복제 및 즉각 복구 인프라 필요)
- RPO ↑, RTO ↑ → 비용 ↓ (비정기 백업 및 수동 복구 가능)
따라서 각 서비스의 비즈니스 중요도에 따라 우선순위를 정하고,
데이터 복제, 백업, 장애 전환(Failover) 전략을 구체적으로 설계해야 한다.
4. 시스템 유형별 복구 전략 예시
| 시스템 유형 | RPO 목표 | RTO 목표 | 권장 기술 및 방법 |
|---|---|---|---|
| 트랜잭션 DB | 0분 | 0분 | Active-Active 구조 (MySQL Group Replication, Aurora Multi-AZ) |
| 배치 처리 시스템 | 30분 | 10분 | Airflow DAG 재시작, S3 staging zone 활용 |
| 로그 수집 파이프라인 | 10분 | 5분 | Kafka replication + ELK snapshot 복구 |
| 데이터 웨어하우스 | 1시간 | 1시간 | Snowflake Time Travel, Delta Lake versioning |
5. 실무 아키텍처 적용 예시
(1) EMR 기반 분석 시스템
- RPO: S3에 로그를 지속 저장하여 0 데이터 유실 보장
- RTO: 클러스터 자동 재생성 스크립트로 10분 이내 복구
- 추가 고려: Step 실패 시 CloudWatch 이벤트 기반 자동 재시작
(2) Spark + Kafka 실시간 스트리밍
- RPO: Kafka replication factor=3 설정
- RTO: Spark Streaming checkpointing으로 상태 복원
- 추가 고려: Zookeeper 장애 시 리더 자동 전환으로 시스템 일관성 유지
(3) Airflow 기반 ETL 파이프라인
- RPO: S3 intermediate 저장소를 통한 task-level checkpoint
- RTO: DAG retry 정책 및 SLA 모니터링을 통한 자동 재수행
- 추가 고려: XCom 및 metadata DB 백업으로 복구 안정성 확보
6. Spark와 Kafka 기반 실무 RPO / RTO 설계 예시
1. 실시간 로그 스트리밍 파이프라인 (Kafka + Spark Structured Streaming)
1) 구성
- Kafka: 웹/앱 로그를 수집하는 메시지 큐
- Spark Structured Streaming: 실시간 데이터 처리 및 적재
- HDFS / S3: 영구 저장소
- Zookeeper: Kafka 브로커 메타데이터 관리
- Checkpoint 디렉터리: Spark 상태 저장소 (S3, HDFS 등)
2) RPO 관점 - 데이터 유실 방지
| 위험 요소 | 대응 전략 | 설명 |
|---|---|---|
| Kafka 브로커 장애 | replication.factor=3 설정 | 하나의 브로커가 다운돼도 메시지 복제본 유지 |
| Spark 장애 | Structured Streaming의 checkpointing + WAL (Write Ahead Log) 활성화 | Spark executor가 재시작되면 마지막 커밋된 오프셋 이후부터 재처리 |
| Consumer lag 누적 | auto.offset.reset=latest 대신 commitSync() 관리 | 커밋 단위를 명확히 제어하여 중복/유실 최소화 |
RPO 목표: 0~5초 수준 — Spark의 마이크로배치 주기와 Kafka 오프셋 커밋 타이밍에 의해 결정됨.
3) RTO 관점 - 복구 속도
| 장애 유형 | 복구 메커니즘 | 예상 복구 시간 |
|---|---|---|
| Spark Worker 장애 | Kubernetes 자동 재시작, executor 재할당 | 수십 초 내 |
| Kafka 브로커 장애 | Zookeeper 리더 재선출 + ISR 복구 | 약 1~2분 |
| 전체 클러스터 장애 | S3 checkpoint 기반 스트림 재시작 | 5분 내 재가동 가능 |
RTO 목표: 5분 내 전체 파이프라인 재가동
4) 알아둬야 할 포인트
- Kafka 오프셋 커밋 주기를 Spark batch interval과 일치시켜야 유실 없는 복원 가능
- Spark checkpoint를 S3 versioning과 함께 사용하면 장애 시점을 정확히 되돌릴 수 있음
- Kafka topic을 "hot/cold topic"으로 분리하면 중요 스트림만 우선 복구 가능 (비용 대비 효과적)
2. 배치 ETL 시스템 (Airflow + Spark + S3)
1) 구성
- Airflow DAG: ETL 파이프라인 오케스트레이션
- Spark on EMR: 대규모 변환 작업 수행
- S3 Staging Layer: 중간 결과 저장소
- Glue Data Catalog: 메타데이터 관리
2) RPO 전략
-
각 DAG 단계(Task)마다 S3에 intermediate checkpoint 생성
- 특정 태스크 실패 시 이전 단계부터 재시작 가능
-
Spark의 saveMode("append") + transaction ID 기반 덮어쓰기 관리
- 중복 쓰기나 손실 없는 재실행 보장
RPO 목표: 30분~1시간 수준 (배치 주기 기반)
3) RTO 전략
-
Airflow 태스크에 retries=3, retry_delay=5m 설정
- 임시 장애 시 자동 복구
-
Spark 클러스터는 EMR Step API를 이용해 자동 재시작
- 장애 탐지 후 재실행까지 약 10분 내 완료
RTO 목표: 10~15분
3. Kafka + Spark + ELK 로그 분석 시스템
1) 구성
- Kafka → Spark Streaming → Elasticsearch → Kibana
- 장애 시, 로그 데이터 복구와 시각화 재빌드가 핵심
2) RPO
- Kafka 복제(3x) + Elasticsearch snapshot(매 15분) → 15분 이내 데이터 손실 방지
- Spark checkpoint로 처리 중인 스트림 상태 복원 가능
3) RTO
- Elasticsearch cluster는 snapshot 복구로 약 5~10분 내 인덱스 복원
- Spark Streaming은 checkpoint offset부터 자동 재시작 → 실시간 복구
전체 파이프라인 RTO 목표: 약 10분
4. 정리
| 시스템 유형 | 주요 장애 대비 전략 | RPO | RTO |
|---|---|---|---|
| Spark Streaming + Kafka | 오프셋 관리, checkpoint, replication | 0~5초 | 5분 |
| Airflow + Spark Batch | Task-level checkpoint, DAG retry | 30분 | 10분 |
| Kafka + ELK | snapshot, replication, checkpoint | 15분 | 10분 |
7. 결론
RPO와 RTO는 단순한 백업 지표가 아니라, 데이터 인프라 전체의 복원력(Resilience)을 정의하는 핵심 메트릭이다.
이 두 지표를 기준으로 장애 대응 전략을 수립하면, 단순한 "복구"가 아닌 연속적 서비스 운영(Continuous Operation)을 실현할 수 있다.
특히 분산 데이터 환경에서 RPO와 RTO의 기준을 명확히 세워두면,
시스템 설계, 예산, 백업 주기, 모니터링 아키텍처 등 모든 의사결정의 기준점이 된다.
