QA가 서버를 죽여본 이유 – Host Level 카오스 엔지니어링 테스트
Summary
QA가 직접 서버를 죽여봤다! 올리브영의 Host Level 장애 실험기
서버는 살아났는데 데이터는 꼬였다? 인프라 장애 뒤에 숨겨진 '진짜 문제'를 찾는 카오스 엔지니어링
단순한 코드 테스트를 넘어 인프라 붕괴 상황에 대비하는 실전형 카오스 엔지니어링 사례를 다룹니다. QA 조직이 주도하여 DB와 메시지 큐를 직접 중단시키며, 시스템 로그가 포착하지 못하는 사용자 경험의 결함과 데이터 정합성 오류를 발굴하고 해결하는 과정을 생생하게 담았습니다. 장애 복구의 정의를 '서버 재시작'에서 '데이터 무결성 확보'로 확장한 것이 핵심입니다.
- 01DB 장애 시 주문은 성공하지만 증정품이 누락되는 '조용한 장애' 패턴 식별
- 02캐시 TTL(5분)이 장애를 일시적으로 은폐하는 현상을 파악하여 복구 골든타임 수립
- 03복구 후 재고 수량이 거꾸로 증가하는 등 정합성 오류를 포착하여 데이터 유실 방지
- 04장애 기간 누락된 상품 정보를 일괄 동기화하는 '정합성 전용 API' 도입으로 운영 자동화
- 05장애 영향도를 4단계(L1~L4)로 표준화하여 팀 간 장애 대응 커뮤니케이션 속도 개선
RECOMMENDATION
분산 시스템에서 인프라 장애가 비즈니스 로직에 미치는 부작용을 사전에 차단하고 싶은 SRE와 QA 엔지니어에게 필독을 권합니다. 특히 DB나 MQ 장애 시 데이터 정합성을 검증하는 구체적인 시나리오와 영향도 평가 기준이 필요한 팀에게 실무적인 가이드를 제공합니다.
The Problem
애플리케이션 레벨의 취약점 검증을 넘어, DB나 메시지 큐 등 핵심 인프라 자체의 장애 발생 시 시스템이 실제로 어떻게 반응하고 복구되는지 확인해야 할 필요성이 대두되었습니다. 단순히 서버가 다시 켜지는 기술적 복구뿐만 아니라, 장애 상황에서 고객이 겪는 경험 훼손과 복구 후의 데이터 정합성 문제를 사전에 식별하고자 했습니다.
The Solution
운영 환경과 동일하게 구성된 QA 환경에서 관계형 DB, 검색 엔진, 캐시 서버 등 핵심 인프라를 대상으로 AWS 콘솔에서 노드를 직접 중단시키는 Host Level 카오스 엔지니어링 테스트를 수행했습니다. QA 팀이 주도하여 고객 및 관리자 시나리오 기반의 기능 검증을 진행했으며, 인프라 차단부터 복구 후 정합성 체크까지 포함된 6단계 실험 프로세스를 적용했습니다.
The Result
총 9개의 주요 버그를 발견하여 4개를 즉시 개선하고 5개를 중장기 로드맵에 반영했으며, 장애 영향도 평가 기준(L1~L4)과 실시간 알림 체계를 구축했습니다. 특히 복구 후 수동 데이터 동기화 문제를 해결하기 위해 '정합성 작업 전용 API'를 개발하여 운영 효율을 높였으며, 서비스별 복구 기준 시간(5분)을 설정하는 성과를 거두었습니다.
Trade-off
본문에 구체적인 수치는 명시되지 않았으나, 운영 환경과 동일한 QA 환경을 유지하고 반기 동안 장기 테스트를 수행하는 과정에서 상당한 인프라 비용과 인적 리소스가 투입되었을 것으로 추론됩니다. 또한 모든 장애 케이스를 자동화하기보다는 QA의 수동 검증 비중이 높아 테스트 반복 주기 단축에 한계가 있을 수 있습니다.
Key Concepts
More from 올리브영
View all posts from 올리브영
옴니채널 재고 정합성 한계에 대응하는 인벤토리 데이터 파이프라인 구축기
KafkaSpring BatchEDA1주 전
에러로그 하나에 깨던 새벽에서 벗어나기까지 — 상품 모니터링 진화기
DatadogCDCAutomation1주 전
150개국 K-뷰티 플랫폼 뒤의 팀, 올리브영 글로벌엔지니어링센터의 첫 번째 워크숍 이야기
GenAIVibe CodingVertex AI2개월 전
45분 배치에서 준실시간으로! 다수 도메인 데이터를 Kafka로 통합한 전환기
KafkaEvent-Driven ArchitectureRedis Pub/Sub2개월 전
AI와 협업하는 새로운 개발 프로세스, 올리브영은 어떻게 시작했을까 (feat. AI-DLC)
AI-DLCSDLCAWS2개월 전