무부하를 기대했던 메타데이터 작업과 리더 노드의 이상 현상
일반적인 데이터베이스 관리 환경에서 테이블의 인덱스 가시성을 조정하는 'ALTER INDEX ... INVISIBLE' 명령은 가벼운 메타데이터 수정 작업으로 취급됩니다. 테이블스페이스를 새로 구축하거나 대량의 데이터를 복사하지 않는 인플레이스(INPLACE) 방식의 메타데이터 작업이므로 운영 중인 데이터베이스에 부하를 주지 않는다는 것이 데이터베이스 관리자들의 일반적인 상식이었습니다.
당근 DB팀은 20개가 넘는 인덱스로 인해 쿼리 최적화 비용과 쓰기 부하가 가중되던 특정 테이블의 미사용 인덱스 6개를 정리하는 작업에 착수했습니다. 인덱스를 즉각 삭제하지 않고 가시성만 감추어 서비스 영향을 관찰하려는 안전한 접근법이었습니다. 그러나 Aurora MySQL 3.10.x 클러스터(Writer 1대, Reader 3대)에서 작업을 수행하자 예상과 정반대의 결과가 나타났습니다. Writer 인스턴스는 평소와 같은 상태를 유지했으나, 3대의 Reader 인스턴스에서 일제히 CPU 점유율이 30%에서 50~60%로 치솟고 ReadIOPS가 평소 수백 건에서 3,100건(3.1K)으로 폭증하는 병목이 발생했습니다.
버퍼풀 수치는 유지되나 캐시는 무효화된 모순 추적
문제 발생 당시 리더 노드들의 버퍼 캐시 히트율은 급격히 하락했습니다. 이는 메모리 상주 데이터가 사라져 물리 스토리지에 재접근하는 전형적인 지표 패턴이었습니다. 하지만 'information_schema.INNODB_BUFFER_PAGE' 시스템 뷰를 통해 점검한 결과, 리더 노드의 버퍼풀에 적재되어 있던 해당 테이블의 인덱스 및 데이터 페이지 총수(약 51만 개)에는 작업 전후 아무런 수치적 변화가 없었습니다.
원인은 버퍼풀 내부의 'IS_STALE' 상태에 있었습니다. 메모리에서 페이지가 물리적으로 제거되지는 않았지만, 해당 페이지들이 모두 더 이상 유효하지 않은 'STALE' 상태로 플래그 처리되어 버린 것입니다. 캐시 히트율이 붕괴된 채 유효성을 잃은 페이지 대신 분산 스토리지 계층으로부터 데이터를 다시 읽어 들이면서 리더 노드의 ReadIOPS와 CPU 연산 부하가 동시다발적으로 치솟았던 것입니다.
MySQL 상류의 지연 무효화 설계와 Aurora 아키텍처의 충돌
이러한 현상의 기저에는 MySQL 8.0 커뮤니티 엔진에서 도입된 테이블스페이스 정리 메커니즘이 자리 잡고 있습니다. MySQL 8.0.23(WL#14100) 버전에서는 대용량 버퍼풀 환경에서 테이블을 삭제하거나 비울 때 버퍼풀 전체를 전수 스캔하여 페이지를 즉각 퇴출하는 부하를 줄이고자, 테이블스페이스 버전을 비교해 페이지를 수동적으로 걷어내는 지연 무효화(lazy eviction) 방식이 도입되었습니다. 이어 8.0.24 버전에서는 이 무효화 상태를 추적할 수 있도록 'IS_STALE' 컬럼이 정보 스키마에 정식으로 추가되었습니다.
커뮤니티 버전에서 이는 삭제된 테이블스페이스의 페이지만 선별적으로 걷어내기 위한 최적화 장치였습니다. 그러나 공유 스토리지 기반 분리 아키텍처를 채택하고 있는 Aurora 엔진 내부에서는, 테이블스페이스가 파기되지 않은 단순 인덱스 메타데이터 변경 redo 로그를 처리하는 과정에서 리더 노드가 전체 캐시 페이지를 무효화(stale) 처리하도록 잘못 판단하는 결함이 발생한 것으로 해석됩니다.
AWS의 엔진 결함 인정과 향후 3.14 릴리즈 패치 예고
당근 DB팀은 DDL 종류별로 현상을 면밀히 재현하고 분석한 결과를 바탕으로 AWS 지원팀에 공식 리포트를 제출했습니다. AWS 엔지니어링 팀은 심층 조사를 거쳐 해당 현상이 Aurora MySQL 엔진 자체의 고유 결함임을 공식 인정했습니다.
이에 따라 리더 노드의 버퍼풀 페이지가 부당하게 무효화되는 버그를 수정한 공식 패치가 차기 배포 버전인 Aurora MySQL 3.14 릴리즈에 포함되는 것으로 확정되었습니다. 다만 2026년 10월 조사 시점 기준으로 공식 문서에는 3.10부터 3.12 버전 내역만 등재되어 있어, 3.14 버전의 일반 배포 일정과 상세 적용 내역은 향후 공식 릴리즈 노트를 통해 최종 확인될 예정입니다.
운영 환경 인덱스 관리 및 모니터링을 위한 실무적 제안
이번 사례는 '메타데이터만 변경하는 DDL은 안전하다'는 데이터베이스 운영의 표준적 가정이 클라우드 전용 엔진의 아키텍처적 변형 속에서 깨질 수 있음을 명확히 보여줍니다. 따라서 패치가 실린 버전으로 업그레이드하기 전까지는, 메타데이터 DDL이라 할지라도 대규모 트래픽이 유입되는 리더 인스턴스를 운영하는 환경에서는 트래픽 피크 타임을 피해 점진적으로 적용하는 운영 원칙이 권장됩니다.
아울러 미사용 인덱스를 판정할 때는 Writer 노드뿐 아니라 모든 Reader 노드의 I/O 통계를 교차 검증해야 합니다. 또한 버퍼풀 이상 징후를 진단할 때 'INNODB_BUFFER_PAGE'와 같은 전수 조사 뷰는 그 자체로 상당한 인스턴스 부하를 유발할 수 있으므로, 운영 환경에서는 시스템 영향을 고려하여 신중하게 제한적으로 활용하는 분석 체계가 필요합니다.
출처
당근 기술 블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Aurora MySQL 인덱스 DDL이 Reader 버퍼풀을 비운다? (새 창)
