DocumentDB를 운영하던 중 특정 시간쯤에 입력 쿼리들에 대하여 대량의 지연이 발생한 후 해소되는 현상이 발생하였습니다.
이 글은 해당 이슈에 대한 원인을 파악하기 위해 확인하였던 내용들과 거기서 알게된 내용들에 대해 정리하고자 합니다.
1. 현상
서비스 오픈 이후 얼마 되지 않은 시점부터 특정 시간대에 평소 30MS 이하의 처리 속도를 보이던 입력과 유니크 인덱스를 바탕으로한 단일 업데이트 쿼리가 300~400MS 까지 증가한 후 감소하는 현상을 발견하였습니다.
해당 컬렉션은 _id 컬럼의 인덱스와 uuid 값을 가진 데이터의 유니크 인덱스를 가지고 있었고 데이터 사이즈는 수억건으로 꽤 큰 편이었습니다.
2. 확인 내용
여러 지표들에 대해 확인하였으며 해당 과정에서 알게된 내용입니다.
확인 지표
A. WriteLatency : 큰 변화는 보이지 않았습니다.
B. 데이터 입력량 : 실제 서비스에서 시도한 데이터 입력량은 여러 방면으로 검토하였을 때 변화가 없는 상태였습니다.
C. Connection : 커넥션은 이슈 시점에 급격히 증가한 후 설정한 커넥션풀 타임에 맞추어 감소하는 패턴을 보였습니다.
D. DocumentReturned : 이슈 시점에 맞추어 크게 증가한 후 감소하는 패턴을 보였습니다.
E. OpcountersQuery : 큰 변화는 보이지 않았습니다.
성능 개선 도우미
이슈 시점에 AAS 는 짧은 시간동안 수백개로 증가하였고 잡히는 WAIT TYPE은 주로 I/O, Latch 였으며 CPU도 확인할 수 있었습니다.
지표에 대하여 알게된 사항
OpcountersCommand : 해당 지표는 MongoDB와 다르게 DocDB에서는 FIND, UPDATE, ISNERT, DELETE를 제외한 명령어가 집계 됩니다.
OpcountersGetmore : Cursor를 사용하였을 때 외에도 세션 및 연결 관리에서 getMore 함수를 사용할 수 있습니다.
DocumentReturned : find 등의 데이터를 반환하는 때 외에도 세션 연결, 유지 등에서 추가적으로 증가할 수 있습니다.
지표들의 변화를 바탕으로 보았을 때 이슈 시점에 DocumentReturned 지표가 증가하는건 커넥션 증가로 인한 원인으로 확인할 수 있있었습니다.
PI의 Latch : 세션이 버퍼 풀의 페이징을 기다리고 있을 때 발생할 수 있는 이벤트 즉 메모리와 연관성이 있다.
이러한 지표들을 바탕으로 특정 시점에 DocDB가 입력을 받아주지 못하여 성능 이슈가 발생하고 서비스에서 여러 커넥션을 추가하고 해소되었을 때 커넥션들이 릴리스 되는 과정을 반복하고 있다는 판다을 하였고 지속적으로 AWS 서비스팀과 발생하는 클러스터들의 상태에 대하여 확인을 하였으나 엔진과 스토리지는 특이사항이 없다는 답변을 계속 받으며 개선이 어렵다 판단하고 PostgreSQL로 이전을 검토하던 상태였습니다.
그러던 중 Aurora PostgreSQL, ElastiCache Redis, MSK 등이 복합적으로 설계된 시스템에서 입력이 지연이 발생하는 현상을 파악하였고 좀 더 다양한 지표와 검토를 할 수 있는 PostgreSQL을 통하여 특정 컬럼의 데이터의 분포도로 인하여 인덱스를 메모리로 올리는 과정에서 지연이 발생하는 것을 확인하였습니다. (https://kominjae.tistory.com/292 글에서 정리 )이 상황이 해당 DocumentDB에도 동일하게 발생하고 있을 수 있다는 생각이 들었고 개발팀에서 해당 데이터를 uuid -> uuidV7으로 개선하는 작업 이후 모든 데이터 입력에 대한 이슈가 해소된 것을 확인하였습니다.
결국 B-TREE 구조로 인덱스가 생성되는 DocumentDB도 Aurora PostgreSQL과 같은 이슈를 겪고 있었던걸로 확인할 수 있었습니다.
DocumentDB를 운영하면서 알게된 소소한 내용
1. MongoDB는 인덱스 생성시 백그라운드 옵션을 별도로 지정하지 않고 버전에 따라 설정 자체가 별도로 없지만 AWS DocDB는 옵션을 지정해주지 않으면 백그라운드로 생성이 되지 않아 서비스 영향이 발생합니다.
-> db.collection.createIndex({name : names}. {background:true});
2. DocumentDB는 2시간의 쿼리 타임 아웃이 설정되어 있고 이는 별도 설정을 할 수 없습니다.
-> 테스트 대역에서 컬렉션 마이그레이션 등의 작업을 진행하고 있을 때 알 수 없는 ERROR를 뱉으면서 쿼리가 간헐적으로 실패하는 과정을 보았는데요 케이스 오픈을 통해 확인하였을 때 서비스 팀을 통해 DocDB는 2시간의 타임아웃이 있는 것을 확인할 수 있었습니다.
'공부 > DATABASE' 카테고리의 다른 글
| [Aurora MySQL] OOM과 Performance Schema (0) | 2026.04.05 |
|---|---|
| [Aurora PostgreSQL] VACUUM TRUNCATE (0) | 2026.03.07 |
| Jenkins 로 Terraform 호출하여 AWS RDS 생성하기 (0) | 2026.02.14 |
| [PostgreSQL, MySQL] DBMS에서 인데스 조회 중 I/O 줄이는 방식 (0) | 2026.02.01 |
| [Aurora PostgreSQL] 테이블 DROP (0) | 2026.02.01 |