멀티 리전 Atlas 배포를 사용하면 지연 시간 줄여 성능을 향상할 수 있습니다. 다음 섹션에는 지연 시간 줄이기 위해 선택할 수 있는 요소와 구성 선택 사항이 나열되어 있습니다.
물리적 거리
물리적 거리는 지연 시간 의 프라이머리 원인입니다. 사용자와 애플리케이션 간의 거리, 애플리케이션 과 데이터 간의 거리, 클러스터 노드 간의 거리가 모두 시스템 지연 시간 과 애플리케이션 성능에 영향 .
읽기 작업의 지연 시간 줄이려면 애플리케이션 과 데이터를 모두 지리적으로 사용자에게 더 가깝게 배치하는 것이 중요합니다.
복제 구성
복제는 프라이머리 노드 에서 세컨더리 노드로 데이터를 복사하는 것입니다. 복제 구성 방법이 지연 시간 에 영향을 미칩니다. 다음 요소를 고려하세요.
쓰기 고려 수준: 쓰기 (write) 내구성과 쓰기 (write) 지연 시간 사이에는 장단점이 있습니다. 구성하는 쓰기 고려 (write concern) 수준(
w: "majority"예시:)에 따라 여러 데이터 센터에 걸친 복제 정의되므로 지속형 작업의 지연 시간 길어질 수 있습니다. 그러나 이렇게 하면 모든 데이터가 세컨더리에 커밋되고 페일오버 이벤트 시 쓰기가 롤백되지 않도록 보호할 수 있습니다.리전 우선 순위: 구성의 리전 순서는 프라이머리 노드 위치 의 우선 순위 결정할 수 있으며, 이는 사용자의 위치에 따라 쓰기 (write) 지연 시간 영향 수 있습니다. 예시 를 들어 대부분의 사용자가 아시아에 있는 경우 아시아 리전 에 가장 높은 우선 순위 설정하다 프라이머리 으로 선택해야 합니다.
미러링된 읽기 : 미러링된 읽기는 세컨더리 노드의 캐시를 미리 워밍하여 운영 중단 후 프라이머리 투표의 영향 줄입니다. 자세한 내용은 미러링된 읽기 참조하세요.
읽기 설정: 기본값 으로 애플리케이션은 읽기 작업을 프라이머리 노드 로 보냅니다. 그러나 읽기 작업을 세컨더리 노드로 전송하도록 읽기 설정 (read preference) 구성할 수 있습니다. 이렇게 하면 읽기가 지리적으로 가장 가까운 클러스터 로 이동합니다. 요구 사항에 가장 적합한 구성을 구현하는 방법에 대한 지침 MongoDB의 MongoDB 전문 서비스 팀 문의 .
중요
복제 지연 으로 인해 세컨더리 노드 오래된 데이터를 반환할 가능성이 있다는 점에 유의하세요. 읽기 일관성 및 격리 구성에 대한 자세한 내용은 읽기 고려를 참조하세요.
데이터 분산: 복제본 세트 또는 샤딩된 클러스터를 사용하여 리전 간에 데이터를 분산하는 것은 데이터가 지리적인 경우에 효과적인 접근 방식입니다. 예시 들어 EU에서만 읽을 수 있는 데이터와 북미에서만 읽을 수 있는 데이터가 있는 경우 해당 데이터를 적절하게 배포하는 클러스터를 만들 수 있습니다.
네트워크 구성
비공개 엔드포인트 사용하여 보안을 강화하고 잠재적으로 지연 시간 줄일 수 있습니다. 비공개 엔드포인트는 애플리케이션의 가상 네트워크와 Atlas cluster 간에 직접적이고 안전한 연결을 설정하여 잠재적으로 네트워크 홉을 줄이고 지연 시간 개선합니다.
지연 시간 모니터링 및 테스트
Atlas 다양한 리전의 지연 시간 지표 관찰할 수 있는 실시간 성능 패널 (RTPP)을 제공합니다. 애플리케이션 수준 모니터링 구현 애플리케이션 과 주고받는 엔드 투 엔드 지연 시간 추적 수도 있습니다. 최종 프로덕션 배포서버 전에 지연 시간 병목 현상을 식별하고 주소 위해 다양한 멀티 리전 시나리오에서 성능테스트를 수행하는 것이 좋습니다.
연결 구성 옵션
가능하면 애플리케이션의 프로그래밍 언어에 맞는 최신 운전자 버전 을 기반으로 구축된 연결 방법을 사용하는 것이 좋습니다. Atlas 제공하는 기본값 연결 문자열 도 좋은 출발점이지만, 특정 애플리케이션 및 배포서버 아키텍처의 컨텍스트에서 성능을 위해 이 문자열을 조정할 수도 있습니다.
엔터프라이즈 수준 애플리케이션 배포의 경우 추가 운영 지연 시간 발생시키지 않고 사용자 요구를 충족할 수 있도록 애플리케이션 에 대한 연결 풀 설정을 조정하는 것이 특히 중요합니다. 데이터베이스 클라이언트 연결을 열면 상당한 네트워크 오버헤드 발생하므로 대부분의 데이터베이스 클라이언트 연결을 언제, 어떻게 열어야 하는지 고려하고 기본 설정에 맞게 연결 풀 설정을 구성하는 것이 중요합니다. minPoolSize 연결 풀 옵션을 사용하여 애플리케이션 스타트업 시 열리는 데이터베이스 클라이언트 maxPoolSize 연결 수를 지정할 수 있습니다. 이러한 초기 연결 후 연결 풀은 연결 수에 도달할 때까지 MongoDB 에 대한 동시 요청을 지원 위해 필요에 따라 소켓을 엽니다.
minPoolSize 값과 maxPoolSize 값이 비슷하면 대부분의 데이터베이스 클라이언트 연결은 애플리케이션 스타트업 시 열립니다. 예시 들어 minPoolSize 가 10 로 설정하다 되어 있고 maxPoolSize 가 12로 설정하다 경우, 애플리케이션 스타트업 시 10 클라이언트 연결이 열리고 애플리케이션 런타임 중에 2 연결만 더 열 수 있습니다. . 이렇게 하면 애플리케이션 런타임 중에 필요에 따라 동적으로 동적으로 발생하는 것이 아니라 애플리케이션 스타트업 시 네트워크 비용 의 대부분이 발생합니다. 한 번에 많은 수의 추가 연결을 열어야 하는 요청이 갑자기 급증하는 경우 애플리케이션 런타임 중에 새 데이터베이스 연결 풀을 열면 최종 사용자의 운영 지연 시간 에 잠재적으로 영향 수 있습니다.
애플리케이션의 아키텍처는 이러한 고려 사항의 핵심입니다. 예시 , 애플리케이션 마이크로서비스로 배포 경우, 연결 풀 의 동적 확장 과 축소를 제어하는 수단으로 어떤 서비스가 Atlas 직접 호출해야 하는지 고려하세요. 또는 애플리케이션 배포서버 Amazon Web Services Lambda 와 같은 단일 스레드 리소스를 활용하는 경우 애플리케이션 하나의 클라이언트 연결만 열고 사용할 수 있으므로 minPoolSize 및 maxPoolSize 를 모두 로 설정하다 해야 합니다. 1.
연결 풀 만들고 사용하는 방법과 위치, 연결 풀 설정을 지정하는 위치에 대한 자세한 학습 은 연결 풀 개요를 참조하세요.
쿼리 지연 시간 옵션
배포서버 에 글로벌 및 작업 수준 기본값 쿼리 시간 제한을 설정하다 애플리케이션 시간이 초과되기 전에 응답을 기다리는 시간을 줄일 수 있습니다.
샤드 워크로드 분산
샤딩 을 사용하면 클러스터 를 수평으로 확장하다 할 수 있습니다. MongoDB 를 사용하면 일부 컬렉션을 샤드 하면서 동일한 클러스터 의 다른 컬렉션은 샤딩되지 않은 상태로 유지할 수 있습니다. 새 데이터베이스 를 생성하면 기본값 클러스터 에서 데이터 양이 가장 적은 샤드 가 해당 데이터베이스의 프라이머리 샤드 로 선택됩니다. 해당 데이터베이스 의 샤딩되지 않은 모든 컬렉션은 기본값 해당 프라이머리 샤드 에 있습니다. 이로 인해 워크로드가 증가함에 따라 프라이머리 샤드 에 대한 트래픽이 증가할 수 있으며, 특히 워크로드 워크로드 가 프라이머리 샤드 의 샤딩되지 않은 컬렉션에 집중되는 경우 더욱 그렇습니다.
이 워크로드 를 더 잘 분산하기 위해 MongoDB 8.0 에서는 moveCollection 명령을 사용하여 샤딩되지 않은 컬렉션 을 프라이머리 샤드 에서 다른 샤드로 이동할 수 있습니다. 이를 통해 예상 리소스 사용량이 적은 샤드에 활성이고 사용량이 많은 컬렉션을 배치할 수 있습니다. 이를 통해 다음을 수행할 수 있습니다.
더 크고 복잡한 워크로드에서 성능을 최적화합니다.
리소스 활용도를 높일 수 있습니다.
샤드 전체에 날짜를 더 균등하게 배포합니다.
다음과 같은 상황에서는 컬렉션 을 격리하는 것이 좋습니다.
처리량이 많은 여러 개의 비샤드형 컬렉션으로 인해 프라이머리 샤드 에 상당한 워크로드 가 발생하는 경우.
샤딩되지 않은 컬렉션 이 다른 컬렉션의 병목 현상이 될 수 있는 향후 성장을 경험할 수 있을 것으로 예상합니다.
클러스터당 하나의 컬렉션 배포서버 설계를 실행 우선 순위 또는 워크로드를 기준으로 해당 고객을 격리하려고 합니다.
샤드에는 샤드되지 않은 컬렉션의 수로 인해 비례하는 양 이상의 데이터가 있습니다.
mongosh 를 사용하여 샤딩되지 않은 컬렉션 을 이동하는 방법을 학습 보려면 컬렉션 이동을 참조하세요 .