AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

네트워크 피어링

참고

이 페이지는 Atlas Infinite와 Atlas Core 모두에 적용됩니다.

Atlas 네트워크 피어링을 사용하면 애플리케이션 네트워크와 Atlas 네트워크 간에 전용 클러스터용 전용 연결을 생성할 수 있습니다. 이 연결은 공용 인터넷 대신 사설 IP 주소를 통해 트래픽을 라우팅하며, 이를 통해 애플리케이션-데이터베이스 트래픽을 격리할 수 있습니다. Atlas는 Amazon Web Services, Azure, GCP의 전용 클러스터에 대한 피어링을 지원하며, 여러 클라우드 공급자에 걸쳐 있는 샤딩된 클러스터에 대한 피어링도 지원합니다. 비공개 엔드포인트와 비교하여 피어링은 Atlas와 클라우드 네트워크 간의 비공개 네트워크 연결을 허용하는 반면, 비공개 엔드포인트는 네트워크 신뢰 경계의 확장을 줄여주면서 보다 족은 범위의 비공개 액세스를 제공합니다.

정확한 설정 요구 사항과 제한 사항은 클라우드 공급자마다 다릅니다. 따라서 연결을 구성하기 전에 공급자 특정 지침을 검토해야 합니다.

네트워크 피어링 구성의 핵심 요소는 미리 CIDR 범위를 정의하는 것입니다. 사용자의 Atlas CIDR는 피어링할 계획인 VPC와 중복되지 않아야 합니다. 그리고 CIDR 크기는 Atlas가 해당 프로젝트 또는 리전에서 지원할 수 있는 노드 및 복제본 세트 수에 영향을 미칩니다. Atlas에서 피어링 연결을 만들 때 네트워크 컨테이너가 자동으로 생성됩니다. 경우에 따라 연결과 분리하여 컨테이너를 생성하거나 관리하고 싶을 수도 있습니다. 이를 위해, 네트워크 컨테이너 관리 가이드를 따르세요.

참고

The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see Shared Responsibility Model.

  • Atlas는 다른 클라우드 공급자의 단일 리전에 배포된 클러스터 간 네트워크 피어링을 지원하지 않습니다. 예를 들어 Amazon Web Services의 단일 리전에서 호스팅되는 Atlas 클러스터와 Google Cloud Platform의 단일 리전에서 호스팅되는 애플리케이션 간에는 네트워크 피어링을 설정할 수 없습니다.

  • 무료 클러스터(이전에는 M0라고 함) 및 Flex 클러스터는 VPC 피어링을 지원하지 않습니다. 프라이빗 네트워킹을 사용하려면 전용 클러스터를 사용해야 합니다.

  • CIDR 범위를 미리 계획하십시오. 이상적으로는 리전 내 첫 번째 전용 클러스터를 배포하기 전에 계획하는 것이 좋습니다. 사용자의 Atlas CIDR은 피어링할 계획인 VPC와 중복되지 않아야 합니다. 그리고 CIDR 크기는 Atlas가 해당 프로젝트 또는 리전에서 지원할 수 있는 노드 및 복제본 세트 수에 영향을 미칩니다.

  • 피어링 네트워크에는 RFC 1918 사용자 전용 주소만 사용하세요.

  • Atlas 프로젝트는 총 최대 50 개의 피어링 연결을 가질 수 있으며, 이 중 최대 25 개는 보류 중일 수 있습니다.

  • Atlas에 대한 비공개 네트워크 경로가 필요한 경우 VPC 또는 VNet 피어링을 사용하지만, 피어링은 비공개 엔드포인트보다 네트워크 신뢰 경계를 더 넓히는 점을 기억하세요. 신뢰 경계 확장 최소화가 최우선 순위인 경우 비공개 엔드포인트가 일반적으로 더 적합합니다.

  • 피어링을 최소 권한 네트워크 설계 연습으로 간주하세요. 보안 그룹과 네트워크 ACL을 잠과 Atlas가 애플리케이션 네트워크에 대한 불필요한 인바운 액세스를 확보하지 않도록 하고, Atlas 액세스가 필요한 컴포넌트만 노출되도록 중간 VPC를 사용하는 것을 고려해 보세요.

  • 피어 CIDR을 Atlas IP 액세스 목록 에 추가하고 제공자 특정 피어링 절차에 설명된 대로 클라우드 측 네트워크 라우팅이 구성되어 있는지 확인합니다.

  • 연결 문자열 선택을 명시적으로 지정하세요. AWS에서, 표준 연결 문자열은 일반적으로 피어링을 통해 작동하며, 사용자 지정 DNS를 사용하지 않는 한 -pri string은 선택 사항입니다. Azure와 Google Cloud Platform에서는 Private IP for Peering 연결 문자열을 사용합니다.

  • 멀티 리전 배포의 경우, 클라우드 동작에 따라 피어링을 계획합니다. Amazon WebServices 및 Azure</ub294 관련된 각 Atlas 리전에 대해 피어링이 필요합니다. 반면 Google Cloud Platform은 전역 VPC를 사용하므로 피어링 연결이 하나만 필요합니다.

스킬 배지 획득

"Networking Security: Atlas"를 무료로 마스터하세요!

자세한 내용을 알아보세요.

이 페이지 평가하기