전사 장애를 데이터로 잠재운 인프라팀의 8개월
Summary
대형 아키텍처 전환 미루고 '기본기'로 전사 장애 90% 감소시킨 아임웹 인프라팀의 8개월 비결
Redis에서 Valkey 9 무중단 대형 마이그레이션부터 쿼리 최적화까지, 데이터로 증명한 인프라 안정화 전략
단일 DB 병목으로 인한 만성 전사 장애를 극복하고자 아임웹 인프라팀이 실행한 현실적이고 효과적인 엔지니어링 기록입니다. 대규모 분산 DB 도입 대신 캐싱과 쿼리 최적화, 대담한 캐시 엔진 업그레이드로 즉각적인 성능 개선을 이끌어냈습니다. 메트릭 일원화와 포스트모템 프로세스 정착을 통해 장애 관리 체계를 고도화한 실전 노하우를 제공합니다.
- 01분산 DB 전면 교체 대신 성능 체감이 빠른 캐싱, 쿼리 최적화, 부하 분산 작업을 우선순위로 진행
- 02Redis 6에서 오픈소스 Valkey 9 메이저 버전으로 무중단에 준하는 과감한 업그레이드 성공
- 03Aurora Writer 연결 피크 최대 75% 감소 및 위젯 쿼리 90% 급감으로 DB 부하 근본적 감소
- 04모든 시스템 로그, APM, 메트릭을 Datadog으로 일원화하여 관측성 확보 및 선제적 장애 대응 체계 구축
- 05장애 발생 시 템플릿화된 포스트모템 절차를 거쳐 매번 다른 유형의 장애만 남도록 기술적 재발 방지
RECOMMENDATION
시스템 병목 현상이 발생했을 때 리소스가 큰 아키텍처 전면 개편을 즉시 시도하기보다, 캐싱 레이어 도입 및 비효율적 쿼리 제거 등 점진적인 최적화로 성능 마진을 먼저 확보하는 접근법을 적극 권장합니다.
The Problem
13년 된 모놀리식 아키텍처에서 모든 서비스 사이트가 하나의 단일 DB Writer를 공유하여 특정 고객의 트래픽 급증이 전사 장애로 쉽게 이어졌습니다. 또한 로그 수집 체계 미비로 인해 시스템이 아닌 고객 제보를 통해서만 장애 발생을 조기 인지하는 등 관측성(Observability)이 매우 부족한 상황이었습니다.
The Solution
새로운 DB 분산 이관 작업을 일시 유예하고, 캐싱, 쿼리 최적화, DB 부하 분산이라는 기본기에 집중했습니다. 구체적으로는 Aurora MySQL Reader 재배치, Valkey 9 무중단 업그레이드, 위젯 read-through 캐싱 도입, N+1 쿼리 제거, Datadog 일원화를 수행했습니다.
The Result
적용 직후 Aurora Writer 연결 피크가 65~75% 감소하고 위젯 쿼리가 약 90% 급감했으며, TTFB 평균 응답 시간이 22.16% 개선되었습니다. 연간 위험급 장애 빈도가 기존 분기 평균 6건에서 2건 수준으로 낮아졌고, MTTR도 1시간 이상에서 23~35분으로 크게 줄었습니다.
Trade-off
근본적 해결책인 DB 전면 분산 및 이관을 뒤로 미루어 단일 Writer 공유 구조의 잠재적 리스크는 아직 일정 부분 남아 있습니다. 또한 패치 직후의 커넥션 단절이나 새벽 배치 스크립트 장애 시 수동 조치가 개입하기 전까지 복구가 다소 지연되는 새벽 시간대의 무인 자동화 대응 지연이 발생했습니다.
