AI 시대 클라우드의 함정! Aurora RDS 경쟁 조건 버그, 그 원인과 교훈
AI와 실시간 데이터 분석 시대, 우리가 믿어온 클라우드 인프라에도 생각지 못한 ‘경쟁 조건(race condition)’ 버그가 숨어 있다는 사실, 알고 계셨나요? 오늘은 수많은 기업의 실시간 이벤트 시스템(대표적으로 Hightouch의 사례)을 뒤흔든 Aurora RDS의 장애를 따라가며, 실제로 어떤 일이 있었고 무엇을 배워야 하는지 쉽고 명확하게 정리했습니다.
경쟁 조건, 그리고 AI 기반 시스템의 도전
경쟁 조건(race condition)은 컴퓨터 시스템에서 여러 프로세스가 동시에 같은 자원에 접근할 때, 순서에 따라 결과가 뒤바뀔 수 있는 버그입니다. 특히 AI, 인공지능 기반의 실시간 이벤트 분석 서비스처럼 대량의 데이터를 빠르게 처리해야 하는 환경에서는 이런 버그가 한 번만 터져도 전체 시스템이 마비될 수 있습니다.
2025년 10월, AWS의 us-east-1(미국 동부 1) 리전에서는 DNS 관리 시스템의 경쟁 조건 버그로 대규모 장애가 발생했습니다. 이 장애로 인해 Hightouch 등 많은 서비스의 이벤트 처리 시스템에 엄청난 백로그가 쌓이고, 서비스 확장과 복구가 절실해졌죠.
Aurora RDS: 빠른 장애 복구의 양날의 검
Hightouch는 이벤트 데이터의 중앙 집중 및 실시간 개인화, AI 마케팅 분석을 위해 Aurora RDS(PostgreSQL 호환)를 사용합니다. Aurora의 큰 장점 중 하나는 컴퓨팅과 스토리지를 분리해 빠른 장애 복구와 읽기 확장이 가능하다는 점이지만, 이렇게 복잡해진 구조는 똑같이 복잡한 실패 모드도 동반됩니다.
이미지 출처: hightouch
이 구조에서 장애 복구(페일오버)는 리더(Reader) 인스턴스를 메인 라이터(Writer)로 승격시켜, 빠른 환경 복구와 확장성 증대를 실시간으로 처리하게 해줍니다. 하지만 정확한 페일오버 과정이 이뤄지지 않을 경우, 오히려 더 심각한 위험이 초래됩니다.
페일오버의 덫: 동시 쓰기, 그리고 경쟁 상태의 진짜 얼굴
Hightouch는 시스템 한계에 도달한 백로그를 해소하고자, 인스턴스의 업그레이드와 페일오버 절차를 시행했습니다. 절차는 다음과 같았습니다.
읽기 인스턴스 추가로 읽기 용량 확보
기존 리더 인스턴스를 특정 크기로 업그레이드
리더를 라이터로 승격(15초 미만 다운타임 예상)
기존 라이터(Writer) 인스턴스의 업그레이드 및 리더로 전환
문제는 페일오버가 정상적으로 끝나기도 전에 Cluster 내 두 개의 인스턴스가 ‘동시에 쓰기 작업’을 처리하는 현상, 즉 경쟁 상태가 발생했다는 점입니다! 그 결과, 저장소 레이어는 동시 쓰기를 거부했고 두 인스턴스 모두 크래시가 일어나 복구가 지연되었습니다.
이미지 출처: hightouch
직접 조사와 AI 기반 관측의 힘
장애 원인을 찾기 위해 Hightouch는 다음 방식을 활용했습니다.
DB 메트릭 분석(네트워크 트래픽∙커밋 수치 등)
앱 로그/오류 메시지(“cannot execute UPDATE in a read-only transaction”)
Aurora 인스턴스의 내부 로그 다운로드 및 비교
이 과정을 통해, 실제로 페일오버 중 ‘두 인스턴스가 동시에 라이터 역할을 하려 했다’는 결론에 도달합니다. Aurora 오케스트레이션이 라이터 강등과 승격 신호를 정확히 전달하지 못하면서, 스토리지 시스템 충돌→전체 장애가 촉발된 것이죠.
이미지 출처: hightouch
이미지 출처: hightouch
AWS의 공식 인정과 해결 조치
해당 장애와 로그를 AWS에 전달한 결과, AWS 역시 "내부 신호 전달 문제(Writer 강등 프로세스)"로 인해 벌어진 경쟁 조건임을 공식 확인했습니다. 해결법은 단순하지만 중요한데, 페일오버 시 반드시 ‘동시 쓰기 요청을 모두 중단’한 다음 진행하라는 것입니다. 즉, 장애 복구 전에 실시간 쓰기 서비스 일시 중지 시나리오를 플레이북에 필수로 추가하게 되었죠.
분산 시스템에서 경쟁 조건, 예측 불가능과 대비의 중요성
이 사례는 분산 시스템 관점에서 참 많은 것을 시사합니다. 오늘날 인공지능이 대량 데이터와 실시간 처리를 요구하고, Aurora RDS처럼 고도화된 아키텍처가 사용될수록, 다음 요소들을 반드시 명심해야 합니다.
준비된 비상 대응 절차: 장애 복구 시도는 예상대로만 진행되지 않습니다. “최악”의 경우를 반드시 준비하세요.
뛰어난 관측 능력의 필수성: 쿼리·로그·메트릭 기반 실시간 모니터링 없이는 미묘한 오류를 잡기 힘듭니다.
테스트와 상시 운영환경의 차이: 스테이징에서 완벽했던 프로세스라도 운영 환경에서는 예측 못한 상황(트래픽, 동시성 등)이 발생합니다.
확장과 분산의 한계: 컴퓨팅·스토리지 분리와 다중 인스턴스 구조가 빠른 복구와 대규모 확장에 유리하지만, 경쟁 상태와 신호 전달 같은 복잡한 오류도 내포합니다.
AI/분산시스템에서는 단일 컴포넌트가 전체 장애로 번질 수 있음: 설계상 서로 영향을 최소화해야 합니다.
결론: AI 기반 클라우드 운영에서 습득해야 할 교훈
Aurora RDS의 경쟁 조건 버그 사건은 AI와 인공지능 중심 시대에도 기존의 시스템 신뢰에만 의존할 수 없음을 보여줍니다. 장애는 예기치 못하게 발생할 수 있으며, ‘실패 시나리오 플레이북’, ‘실시간 모니터링 체계’, ‘운영환경 테스트의 반복’ 등이 기업의 시스템 운영의 필수가 됩니다.
마지막으로, 장애를 겪었다면 그 원인 분석과 교훈 도출에 집중하세요. 실전에서 얻은 마이그레이션•복구 전략은 여러분의 AI∙클라우드 인프라의 진짜 경쟁력이 될 것입니다.
참고
[1] How we Uncovered a Race Condition in Aurora RDS - Hightouch
[2] AWS Post-Event Summaries - AWS
[3] Challenges with distributed systems - AWS Builders Library
[4] Avoiding fallback in distributed systems - AWS Builders Library
[5] Guidance for Cross Region Failover & Graceful Failback on AWS - AWS Solutions Library