고지연 문제 해결: MongoDB 연결 문제 진단

MongoDB의 높은 지연 시간이 항상 느린 쿼리 문제인 것은 아닙니다. 때로는 쿼리 자체는 서버에 도달하면 빠르게 실행되지만, 요청이 연결을 기다리거나, DNS에서 지연되거나, 느린 네트워크 경로를 통과하거나, 일시적인 오류 후 재시도하거나, 대량의 결과 집합을 애플리케이션으로 다시 전송하는 데 너무 오래 걸리는 경우가 있습니다.

첫 번째 작업은 종단 간 지연 시간을 여러 부분으로 나누는 것입니다. 서버 측 쿼리 시간, 연결 체크아웃 시간, 네트워크 왕복 시간, 결과 전송 시간, 애플리케이션 처리 시간은 각각 다른 문제이며 다른 해결 방법이 필요합니다.

1. 네트워크 구성 및 연결성

네트워크 문제는 예상치 못한 지연 시간의 빈번한 원인입니다. 애플리케이션 서버와 MongoDB 인스턴스 간의 사소한 패킷 손실이나 왕복 시간(RTT) 증가라도 성능에 큰 영향을 미칠 수 있습니다.

1.1. 애플리케이션과 MongoDB 서버 간 지연 시간

Ping 및 Traceroute: 표준 네트워크 진단 도구를 사용하여 RTT를 측정하고 네트워크 경로의 잠재적 병목 지점을 식별합니다.
```
ping <mongodb_host>
traceroute <mongodb_host>  # 또는 Windows의 경우 tracert
```
- 팁: 지속적으로 높은 핑 시간이나 큰 변동은 네트워크 불안정을 나타낼 수 있습니다.
방화벽 규칙 및 네트워크 혼잡: 방화벽이 지연을 유발하지 않는지(예: 심층 패킷 검사) 또는 네트워크 링크가 포화 상태가 아닌지 확인합니다. 애플리케이션과 데이터베이스 계층 간의 네트워크 트래픽을 모니터링합니다.

1.2. DNS 확인 지연

호스트 이름 대신 IP 주소를 사용하는 경우 느린 DNS 조회는 모든 연결 시도에 지연 시간을 추가할 수 있습니다. DNS 서버가 응답 가능하고 올바르게 구성되었는지 확인합니다.

2. 연결 풀링 문제

연결 풀링은 성능에 필수적이지만, 잘못된 구성이나 과도한 사용은 심각한 지연 시간을 초래할 수 있습니다.

2.1. 연결 풀링 이해

연결 풀링은 애플리케이션이 재사용할 수 있는 열린 데이터베이스 연결 집합을 유지 관리하여 모든 요청에 대해 새 연결을 설정하는 오버헤드를 방지합니다. 이는 연결 설정 시간을 획기적으로 줄여줍니다.

2.2. 최대 연결 수 부족

애플리케이션의 최대 연결 풀 크기가 너무 낮게 설정되면 애플리케이션 스레드가 사용 가능한 연결을 기다려야 할 수 있으며, 이는 요청 대기열과 높은 지연 시간으로 이어집니다. 반대로, 지나치게 큰 풀은 MongoDB 서버에 과부하를 줄 수 있습니다.

모니터링: 대부분의 MongoDB 드라이버는 연결 풀 사용량에 대한 통계를 제공합니다. 다음과 같은 메트릭을 확인합니다.
- pool.size: 풀의 현재 연결 수.
- pool.in_use: 현재 사용 중인 연결 수.
- pool.waiters: 연결을 기다리는 스레드 수.
pool.waiters가 지속적으로 높다면 maxPoolSize가 너무 작을 수 있습니다.
구성 (예시 - Python/PyMongo):
```
from pymongo import MongoClient

client = MongoClient(
    'mongodb://localhost:27017/',
    maxPoolSize=20,  # 필요에 따라 이 값을 조정하세요
    minPoolSize=5
)
```
- 팁: 최적의 maxPoolSize는 애플리케이션의 동시성, MongoDB 서버 코어 수, 네트워크 지연 시간에 따라 달라집니다. 적당한 값으로 시작하여 모니터링 결과에 따라 조정합니다.

2.3. 연결 설정 지연 시간

풀링을 사용하더라도 초기 연결 설정은 시간이 걸릴 수 있으며, 특히 지연 시간이 긴 네트워크나 TLS/SSL 협상이 포함된 경우 더욱 그렇습니다. 이 지연 시간은 기존 연결이 모두 사용 중이거나 시간 초과되어 풀이 새 연결을 생성해야 할 때 발생합니다.

TLS/SSL 오버헤드: 보안에 필수적이지만 TLS/SSL 핸드셰이크는 오버헤드를 추가합니다. 하드웨어가 암호화/복호화 부하를 처리할 수 있는지 확인합니다.

3. MongoDB 서버 리소스 경합

MongoDB 서버 자체에 부하가 가해지면 단순한 작업에서도 지연 시간이 증가할 수 있습니다.

3.1. CPU 사용량

MongoDB 서버의 높은 CPU 사용률은 연결 처리 및 쿼리 처리를 포함한 모든 작업을 느리게 할 수 있습니다. 이는 다음과 같은 원인으로 발생할 수 있습니다.

비효율적인 쿼리: 전체 컬렉션 스캔 또는 복잡한 집계를 수행하는 쿼리.
높은 동시성: 너무 많은 동시 요청이 서버의 처리 능력을 압도합니다.
백그라운드 작업: 유지 관리 작업, 선거 또는 데이터 동기화.
모니터링: mongostat 또는 클라우드 제공업체 모니터링 도구를 사용하여 CPU 사용률을 확인합니다.
```
mongostat --host <mongodb_host> --port 27017
```
높은 qr(쿼리 대기열 길이) 및 qw(쓰기 대기열 길이) 값을 확인합니다.

3.2. 메모리 사용량 및 스와핑

MongoDB는 작업 세트(활발히 사용되는 데이터 및 인덱스)가 RAM에 맞을 때 최상의 성능을 발휘합니다. RAM 부족으로 서버가 디스크로 스와핑을 시작하면 성능이 급격히 저하됩니다.

모니터링: MongoDB 서버의 RAM 사용량 및 스왑 활동을 모니터링합니다.
```
# Linux에서는 top 또는 htop 사용
top
```
상당한 스왑 사용량(top의 Swap)이 보이면 메모리 부족의 강력한 신호입니다.
해결 방법: 서버 RAM을 늘리거나 인덱스가 쿼리를 포괄하도록 하는 등 MongoDB 배포를 최적화하여 메모리 사용량을 줄입니다.

3.3. 디스크 I/O 병목 현상

느린 디스크 I/O는 특히 데이터나 인덱스가 메모리에 완전히 캐시되지 않은 경우 일반적인 병목 현상입니다.

모니터링: Linux 시스템에서 iostat를 사용하여 디스크 사용률을 확인합니다.
```
iostat -xz 5
```
높은 %util, await 또는 svctm 값은 디스크 포화를 나타냅니다.
해결 방법: 더 빠른 스토리지(SSD)를 사용하고, 캐싱을 위한 충분한 RAM을 확보하며, 디스크 읽기를 줄이기 위해 쿼리를 최적화합니다.

3.4. 서버의 네트워크 처리량

네트워크 경로가 양호하더라도 MongoDB 서버가 엄청난 양의 요청을 처리하는 경우 네트워크 인터페이스가 포화 상태가 될 수 있습니다.

모니터링: MongoDB 서버 자체의 네트워크 트래픽을 모니터링합니다.

4. 애플리케이션 수준 고려 사항

때로는 문제가 MongoDB나 네트워크에 직접 있는 것이 아니라 애플리케이션이 데이터베이스와 상호 작용하는 방식에 있을 수 있습니다.

4.1. 과도한 드라이버 호출

애플리케이션이 작업을 일괄 처리하지 않고 매우 많은 수의 작은 독립적인 데이터베이스 호출을 수행하면 연결 오버헤드와 지연 시간이 증가할 수 있습니다.

예시: insert_many를 사용하는 대신 루프에서 개별 insert_one 작업을 수행합니다.

4.2. 애플리케이션 내 장기 실행 작업

애플리케이션이 MongoDB에서 데이터를 검색한 후 응답을 반환하기 전에 상당한 계산이나 I/O를 수행하면 종단 간 지연 시간이 길어집니다.

해결 방법: 애플리케이션 코드를 프로파일링하여 느린 부분을 식별하고 최적화합니다.

단계별 지연 시간 분류

요청을 여러 부분으로 나누어 측정하는 것부터 시작합니다. "API가 900ms가 걸린다"와 같은 하나의 숫자로는 충분하지 않습니다. 연결을 기다리는 데 얼마나 많은 시간이 소요되는지, 명령을 보내는 데, MongoDB에서 실행하는 데, 결과를 수신하는 데, 응답을 직렬화하는 데 각각 얼마나 걸리는지 알아야 합니다.

대부분의 MongoDB 드라이버는 명령 모니터링 후크를 노출합니다. 명령 시작 및 명령 성공 또는 실패 주변에 임시 로깅을 추가합니다. 명령 이름, 기간, 데이터베이스, 컬렉션 및 요청 ID를 포함합니다. 민감한 데이터가 포함될 수 있는 경우 전체 쿼리 값을 기록하지 마십시오.

명령 기간은 짧지만 API가 느린 경우 MongoDB가 주요 병목 현상이 아닐 가능성이 높습니다. 애플리케이션 CPU, 다운스트림 HTTP 호출, JSON 직렬화, 템플릿 렌더링 또는 대기열 대기를 확인합니다. 명령 기간은 길지만 MongoDB 프로파일러가 빠른 실행을 보여주는 경우 지연은 연결 체크아웃, 네트워크 전송, DNS, TLS 협상 또는 결과 디코딩에 있을 수 있습니다.

연결 체크아웃 시간은 특히 놓치기 쉽습니다. 풀은 시작 시에는 정상이지만 트래픽 급증 시 포화 상태가 될 수 있습니다. 요청이 소켓을 기다리는 경우 MongoDB가 각 명령을 빠르게 실행하더라도 애플리케이션 관점에서는 모든 쿼리가 느리게 보입니다. 드라이버에서 노출하는 경우 풀 대기 시간을 추적합니다. 그렇지 않은 경우 데이터베이스 호출 전후 시간을 측정하고 서버 측 프로파일러 시간과 비교합니다.

간단한 로컬 테스트로 문제를 좁힐 수 있습니다.

mongosh "mongodb://mongo1.internal:27017/app" --eval 'db.runCommand({ ping: 1 })'

노트북, 애플리케이션 호스트, 가능하면 동일한 서브넷의 다른 호스트에서 실행합니다. 애플리케이션 호스트만 느린 경우 로컬 DNS, 방화벽 규칙, 라우팅, 과부하된 노드 또는 컨테이너 네트워킹을 의심합니다. 모든 호스트가 느린 경우 데이터베이스 계층 또는 계층 간 네트워크 경로를 확인합니다.

DNS의 경우 반복 조회를 테스트합니다.

time nslookup mongo1.internal

새 연결 생성 중 느린 조회는 클라이언트를 재사용하지 않고 자주 생성하는 서비스에 해를 끼칠 수 있습니다. 대부분의 애플리케이션에서는 프로세스당 하나의 MongoClient를 생성하고 재사용합니다. 요청당 새 클라이언트를 생성하는 것은 지연 시간을 만드는 가장 빠른 방법 중 하나입니다.

TLS도 특히 연결 생성 중에 비용을 추가할 수 있습니다. TLS를 비활성화해야 한다는 의미는 아닙니다. 풀링된 연결을 재사용하고, 불필요한 클라이언트 변경을 피하며, 핸드셰이크 중 CPU가 포화되지 않도록 해야 한다는 의미입니다.

서버에서 MongoDB 메트릭을 운영 체제 메트릭과 비교합니다. mongostat에 대기열이 증가하고 호스트에 높은 CPU가 표시되면 쿼리 또는 동시성 압력이 있을 수 있습니다. CPU는 적당하지만 iostat에 높은 대기 시간이 표시되면 스토리지가 문제의 일부일 가능성이 높습니다. 메모리 압력으로 인해 스와핑이 발생하면 먼저 해결하십시오. 스와핑하는 데이터베이스 호스트는 모든 것을 무작위적이고 느리게 만듭니다.

대량의 결과 집합은 연결 지연 시간처럼 보일 수 있습니다. 50,000개의 문서를 반환하는 쿼리는 빠르게 실행될 수 있지만 네트워크를 통해 데이터를 전송하고 드라이버에서 디코딩하는 데 시간이 걸립니다. 프로젝션, 페이지 매김 및 서버 측 제한을 사용합니다. API의 경우 화면에 실제로 필요한 필드만 반환하고 개발 중에 편리하다고 전체 문서를 반환하지 마십시오.

마지막으로 토폴로지 동작을 확인합니다. 복제본 세트 선거 중에는 새 기본 노드가 선출될 때까지 쓰기가 일시 중지됩니다. 드라이버도 토폴로지 변경을 감지해야 합니다. 지연 시간 급증이 선거, 노드 재시작, 유지 관리 기간 또는 네트워크 장애와 일치하는 경우 해결 방법은 쿼리 튜닝보다는 안정성 및 장애 조치 동작일 수 있습니다. 연결 문자열에 복제본 세트 멤버 또는 적절한 SRV 레코드가 포함되어 있는지 확인하고, 애플리케이션이 너무 오래 중단되지 않고 예측 가능하게 실패하도록 시간 제한을 의도적으로 설정합니다.

유용한 인시던트 노트는 증거(풀 대기 시간, 명령 기간, 프로파일러 기간, 네트워크 RTT, CPU, 메모리, 디스크 I/O 및 비밀번호가 제거된 정확한 연결 문자열 형태)로 끝납니다. 이를 통해 추측이 아닌 실제 진단을 얻을 수 있습니다.

시간 제한 설정은 진단의 일부입니다

시간 제한이 지연 시간을 해결하지는 않지만 사용자에게 지연 시간이 얼마나 나쁘게 느껴질지 결정합니다. 서버 선택 시간 제한이 너무 높으면 애플리케이션이 제어된 오류를 반환할 수 있었음에도 오랫동안 중단될 수 있습니다. 소켓 시간 제한이 너무 낮으면 데이터베이스가 정상이더라도 일반적인 장기 실행 보고서가 실패할 수 있습니다. 워크로드에 맞게 의도적으로 설정합니다.

요청-응답 API의 경우 사용자가 기다리고 있으므로 더 짧은 서버 선택 시간 제한이 적합한 경우가 많습니다. 배치 작업의 경우 더 긴 시간 제한이 허용될 수 있습니다. 동일한 서비스가 둘 다 수행하는 경우 해당 클라이언트를 분리합니다. 대시보드 쿼리와 야간 내보내기가 항상 동일한 시간 제한 및 풀 동작을 공유해서는 안 됩니다.

또한 재시도 동작을 확인합니다. 재시도 가능 쓰기 및 드라이버 재시도는 일시적인 네트워크 오류를 완화할 수 있지만 모든 시도가 시간 제한 근처에서 대기하는 경우 단일 사용자 요청이 예상보다 오래 걸릴 수 있습니다. 가능하면 재시도 횟수를 기록합니다. 모든 요청이 조용히 백그라운드에서 재시도되는 경우 재시도 후 성공하는 서비스도 비정상일 수 있습니다.

연결 풀 크기 조정 간단 설명

더 큰 풀이 자동으로 더 빠른 것은 아닙니다. 데이터베이스가 100개의 동시 작업을 편안하게 처리할 수 있고 애플리케이션이 1,000개의 사용 중인 연결을 열면 컨텍스트 전환, 메모리 사용량 및 대기열이 증가할 수 있습니다. 풀이 너무 작으면 MongoDB에 용량이 있는 동안에도 애플리케이션 스레드가 기다립니다. 올바른 풀 크기는 동시성, 작업 기간 및 서버 용량에서 비롯됩니다.

하나의 애플리케이션 인스턴스에서 동시에 데이터베이스에 도달할 수 있는 요청 수를 확인하는 것부터 시작합니다. 그런 다음 앱 인스턴스 수를 곱합니다. 한 프로세스에서 적당해 보이는 maxPoolSize도 여러 프로세스에 걸쳐 커질 수 있습니다. 풀이 100인 10개의 애플리케이션 파드는 관리 도구, 작업 및 기타 서비스를 계산하기 전에 최대 1,000개의 연결을 생성할 수 있습니다.

연결 변동을 주시합니다. 연결이 지속적으로 열리고 닫히면 이유를 찾으십시오. 유휴 시간 제한, 로드 밸런서, NAT 게이트웨이, 서버리스 실행 환경 및 요청별 클라이언트 생성이 모두 변동을 유발할 수 있습니다. 안정적인 풀링된 연결은 일반적으로 더 일정한 지연 시간을 생성합니다.

간단한 현장 체크리스트

지연 시간이 급증하면 모든 것을 재시작하기 전에 증거를 수집합니다.

애플리케이션:
- 요청 기간 백분위수
- 데이터베이스 명령 기간
- 연결 체크아웃 대기 시간
- 재시도 횟수
- 결과 크기

MongoDB:
- 느린 명령에 대한 프로파일러 항목
- 급증 중 현재 작업
- 복제 지연
- 연결 및 대기 중인 읽기/쓰기

호스트 및 네트워크:
- CPU 포화
- 메모리 압력 및 스왑
- 디스크 대기/사용률
- 패킷 손실 및 RTT
- DNS 조회 시간

이 체크리스트는 일반적으로 세 가지 시나리오 중 하나를 가리킵니다. 앱이 연결을 기다리고 있거나, MongoDB가 명령 실행 속도가 느리거나, 빠른 명령 주변의 네트워크/결과 전송이 느린 경우입니다. 각 시나리오에는 다른 해결 방법이 있습니다.

실용적인 마무리

MongoDB 애플리케이션의 높은 지연 시간 문제를 해결하려면 체계적인 접근 방식이 필요합니다. 네트워크 연결, 연결 풀 구성 및 서버 리소스 사용률을 검토하여 지연의 근본 원인을 정확히 찾아낼 수 있습니다. 지연 시간은 증상이며, 최적의 성능을 달성하려면 애플리케이션 및 데이터베이스 인프라에 대한 전체적인 관점이 중요합니다.

가장 일반적인 원인인 네트워크 RTT, 연결 풀 waiters 및 서버 CPU/메모리/디스크 I/O를 모니터링하는 것부터 시작합니다. 필요에 따라 점차 더 구체적인 영역을 살펴봅니다. 이러한 메트릭과 구성을 정기적으로 검토하면 지연 문제가 사용자에게 영향을 미치는 것을 방지하는 데 도움이 됩니다.