Docs Menu
Docs Home
/ /
Atlas 아키텍처 센터
/

Atlas 고가용성을 위한 지침

이 페이지를 참조하여 가용성 및 성능을 최적화하면서 기업의 비용 관리 및 및 액세스 요구사항에 맞는 적절한 클러스터 구성을 계획하세요.

Atlas 에서 새 클러스터 시작하면 Atlas 최소 3노드 복제본 세트 자동으로 구성하고 배포 리전 에 배포합니다. 프라이머리 멤버가 중단되면 MongoDB database 이 장애를 자동으로 감지하고 세컨더리 멤버를 교체 멤버로 선출하며, 이 세컨더리 멤버를 새 프라이머리 멤버로 승격합니다. 그런 다음 Atlas 장애가 발생한 멤버를 복원하거나 교체하여 클러스터 가능한 한 빨리 대상 구성으로 돌아갈 수 있도록 합니다. 또한 MongoDB 클라이언트 운전자 모든 클라이언트 연결을 자동으로 전환합니다. 전체 선택 및 페일오버 프로세스 수동 개입 없이 몇 초 내에 완료됩니다. MongoDB 장애를 감지하고 새로운 프라이머리 선택하는 데 사용되는 알고리즘을 최적화하여 페일오버 간격을 줄입니다.

단일 리전 내에 배포 클러스터는 해당 리전 내의 가용영역에 분산되어 있으므로 읽기 또는 쓰기 (write) 가용성의 중단 없이 부분적인 리전 중단을 견딜 수 있습니다.

선호하는 리전 에서 쓰기 (write) 작업을 항상 유지하는 것이 최우선 우선 순위 인 경우, MongoDB 선호하는 리전 내 최소 두 개의 가용영역에 최소 두 개의 투표 선택 가능 멤버가 있도록 클러스터 배포할 것을 권장합니다.

전 세계 배포서버에서 최상의 데이터베이스 성능을 위해 사용자는 위치 인식 샤딩을 사용하여 읽기 및 쓰기 지연 시간을 최소화하는 글로벌 클러스터 를 구성할 수 있습니다. 지리적 저장 요구 사항이 있는 경우 Atlas가 특정 지리적 영역에 데이터를 저장하도록 할 수도 있습니다.

3 노드가 있는 단일 리전 (프라이머리 1개와 보조 노드 2개)이 있는 토폴로지 .

이 토폴로지는 낮은 지연 시간이 필요하지만 고가용성 요구 사항이 단일 지역으로 제한되는 경우에 적합합니다. 토폴로지는 1개의 노드 장애를 허용할 수 있으며 지역 세컨더리 내에서 과반수 쓰기 고려를 쉽게 충족할 수 있습니다. 노드 장애 시 선호 지역에서 프라이머리를 유지하고 비용을 절감할 수 있으며 애플리케이션 아키텍처 관점에서 가장 간단합니다. 토폴로지의 세컨더리에서 읽기 및 쓰기 작업은 선호하는 지역에서 낮은 지연 시간을 경험합니다.

그러나 이 토폴로지는 지역 장애에 대응할 수 없습니다.

다음 권장 사항을 사용하여 고가용성 위해 Atlas 배포 및 백업을 구성하고 재해로부터 빠르게 복구할 수 있습니다.

재해 계획 및 대응에 대해 더 알아보려면 Atlas 재해 복구 지침을 참조하세요.

새로운 클러스터를 생성할 때, Dedicated, Flex, Free 배포 유형에 따라 제공되는 다양한 클러스터 계층 중에서 선택할 수 있습니다.

애플리케이션 크기에 권장되는 클러스터 계층 결정하려면 Atlas 클러스터 크기 가이드를 참조하세요.

프라이머리를 선출하려면 투표 가능한 복제본 세트 멤버의 과반수가 필요합니다. 투표 가능한 복제본 세트 멤버의 수를 홀수로 생성하는 것이 좋습니다. 투표 가능한 복제본 세트 멤버의 수가 짝수인 경우 이점이 없습니다. Atlas는 기본적으로 3, 5 또는 7개의 노드를 요구하므로 이 요구 사항을 충족합니다.

장애 허용성은 프라이머리 선출을 위해 충분한 멤버가 남아 있는 상태에서 사용 불가일 수 있는 복제본 세트 멤버의 수입니다. 네 멤버 복제 세트의 장애 허용성은 세 멤버 복제 세트와 동일합니다. 둘 다 단일 노드 중단을 견딜 수 있기 때문입니다.

애플리케이션이 복제본 세트 프라이머리의 장애를 처리할 수 있는지 테스트하려면 프라이머리 페일오버 테스트 요청을 제출하세요. Atlas가 페일오버 이벤트를 시뮬레이션할 때, Atlas는 현재 프라이머리를 종료하고 새로운 프라이머리를 선출하기 위한 투표를 실시합니다.

복제본 세트 멤버에 대해 더 알아보려면 복제본 세트 멤버를 참조하세요. 복제본 세트 선거와 투표에 대해 자세히 알아보려면 복제본 세트 선거 및 투표를 참조하세요.

MongoDB는 복제본 세트에 여러 데이터 사본을 저장하여 고가용성을 제공합니다. 동일한 복제본 세트의 노드가 동일한 리소스를 공유하지 않도록 하고, 데이터 센터를 사용할 수 없게 되었을 때 복제본 세트가 프라이머리를 선택할 수 있도록 하려면 최소 3 개의 데이터 센터에 노드를 분산해야 합니다. 최소 5개의 데이터 센터를 사용하는 것이 좋습니다.

여러 가용영역을 지원하는 리전에 클러스터를 배포하여 여러 데이터 센터에 데이터를 분산할 수 있습니다. 각 가용영역은 일반적으로 하나 이상의 개별 데이터 센터로 구성되어 있고, 각 데이터 센터는 중복 전원, 네트워킹 및 연결성을 갖추고 있으며, 종종 별도의 시설에 위치합니다. 가용영역을 지원하는 리전에 전용 클러스터를 배포하면 Atlas는 클러스터의 노드를 가용영역에 자동 분할합니다. 예를 들어, 세 개의 노드로 구성된 복제본 세트 클러스터가 세 개의 가용영역이 있는 리전에 배포된 경우, Atlas는 각 가용영역에 하나의 노드를 배포합니다. 이렇게 하면 동일한 복제본 세트의 노드가 리소스를 공유하지 않게 되어, 한 구역에 장애가 발생하더라도 데이터베이스를 계속 사용할 수 있습니다.

3개 미만의 데이터 센터를 사용하는 데 따른 위험을 이해하려면 두 개의 데이터 센터에 분산된 데이터를 보여주는 다음 다이어그램을 살펴보세요.

두 개의 데이터 센터를 보여주는 이미지: 데이터 센터 1에는 프라이머리 노드와 세컨더리 노드가 있고 데이터 센터 2에는 세컨더리 노드만 있습니다.

이전 다이어그램에서 데이터 센터 2를 사용할 수 없게 되면 복제본 세트 멤버의 과반수가 남아 있으며 Atlas는 프라이머리를 선출할 수 있습니다. 그러나 데이터 센터 1을 잃게 되면 세 개의 복제본 세트 멤버 중 하나만 사용할 수 있으며 과반수가 없고 시스템은 읽기 전용 모드로 전환됩니다.

가용 리전 이 3개인 리전에 배포된 5노드 복제본 세트 클러스터 보여주는 다음 다이어그램을 고려하세요.

세 개의 데이터 센터를 보여주는 이미지: 데이터 센터 1에는 프라이머리 노드와 세컨더리 노드가 있고, 데이터 센터 2에는 세컨더리 노드 2개가 있으며, 데이터 센터 3에는 세컨더리 노드 1개가 있습니다.
클릭하여 확대

이전 다이어그램의 2-2-1 토폴로지 여러 리전에서 고가용성, 성능 및 비용 균형을 맞추기 위해 권장되는 토폴로지 입니다. 이 토폴로지 에서는 하나의 데이터 센터 장애가 발생해도 대부분의 복제본 세트 멤버를 계속 사용할 수 있으며 Atlas 자동 페일오버를 수행할 수 있습니다. 3노드, 3리전 토폴로지 모든 1리전 장애를 허용할 수 있지만, 1-1-1 토폴로지 에서 페일오버 이벤트 발생하면 새로운 프라이머리 다른 리전 에서 강제로 선출되어야 합니다. 2-2-1 토폴로지 새 프라이머리 기본 리전 에 유지하면서 프라이머리 노드 장애를 허용할 수 있습니다.

다음 리전은 최소 3개의 가용영역을 지원 복제본 세트를 배포 것이 좋습니다.

AWS 리전
위치
Atlas 리전

us-east-1

미국 북부 버지니아주

US_EAST_1

us-west-2

미국 오리건주

US_WEST_2

ca-central-1

캐나다 퀘벡주 몬트리올

CA_CENTRAL_1

ca-west-1

캘거리, 캐나다

CA_WEST_1

us-east-2

Ohio, USA

US_EAST_2

sa-east-1

브라질 상파울루

SA_EAST_1

AWS 리전
위치
Atlas 리전

ap-southeast-1

싱가포르

AP_SOUTHEAST_1

ap-southeast-2

호주 NSW주 시드니

AP_SOUTHEAST_2

ap-southeast-3

Jakarta, Indonesia

AP_SOUTHEAST_3

ap-south-1

인도 뭄바이

AP_SOUTH_1

ap-east-1

중국 홍콩

AP_EAST_1

ap-northeast-1

Tokyo, Japan

AP_NORTHEAST_1

ap-northeast-2

서울, 대한민국

AP_NORTHEAST_2

ap-northeast-3

일본 오사카

AP_NORTHEAST_3

ap-south-2

Hyderabad, India

AP_SOUTH_2

ap-southeast-4

호주 빅토리아주 멜버른

AP_SOUTHEAST_4

AWS 리전
위치
Atlas 리전

eu-west-1

아일랜드

EU_WEST_1

eu-central-1

독일 프랑크푸르트

EU_CENTRAL_1

eu-north-1

스톡홀름, 스웨덴

EU_NORTH_1

eu-west-2

영국 런던

EU_WEST_2

eu-west-3

(프랑스, 파리)

EU_WEST_3

eu-south-1

이탈리아, 밀라노

EU_SOUTH_1

eu-central-2

스위스, 취리히

EU_CENTRAL_2

eu-south-2

스페인

EU_SOUTH_2

AWS 리전
위치
Atlas 리전

me-south-1

바레인

ME_SOUTH_1

af-south-1

남아프리카 공화국, 케이프타운

AF_SOUTH_1

il-central-1

Tel Aviv, Israel

IL_CENTRAL_1

me-central-1

UAE

ME_CENTRAL_1

Azure 리전
위치
Atlas 리전

centralus

Iowa, USA

US_CENTRAL

eastus

버지니아주(미국 동부)

US_EAST

eastus2

Virginia, USA

US_EAST_2

northcentralus

Illinois, USA

US_NORTH_CENTRAL

westus

미국 캘리포니아주

US_WEST

westus2

미국 워싱턴주

US_WEST_2

westus3

Arizona, USA

US_WEST_3

southcentralus

Texas, USA

US_SOUTH_CENTRAL

brazilsouth

브라질 상파울루

BRAZIL_SOUTH

brazilsoutheast

Rio de Janeiro, Brazil

BRAZIL_SOUTHEAST

canadacentral

캐나다 온타리오주 토론토

CANADA_CENTRAL

Azure 리전
위치
Atlas 리전

northeurope

아일랜드

EUROPE_NORTH

westeurope

네덜란드

EUROPE_WEST

uksouth

영국 런던

UK_SOUTH

francecentral

(프랑스, 파리)

FRANCE_CENTRAL

italynorth

이탈리아, 밀라노

ITALY_NORTH

germanywestcentral

독일 프랑크푸르트

GERMANY_WEST_CENTRAL

polandcentral

(폴란드 바르샤바)

POLAND_CENTRAL

switzerlandnorth

스위스, 취리히

SWITZERLAND_NORTH

norwayeast

노르웨이 오슬로

NORWAY_EAST

swedencentral

(스웨덴 예블레)

SWEDEN_CENTRAL

Azure 리전
위치
Atlas 리전

eastasia

중국 홍콩

ASIA_EAST

southeastasia

싱가포르

ASIA_SOUTH_EAST

australiaeast

호주 뉴사우스웨일스주

AUSTRALIA_EAST

centralindia

푸네(인도 중부)

INDIA_CENTRAL

japaneast

Tokyo, Japan

JAPAN_EAST

koreacentral

서울, 대한민국

KOREA_CENTRAL

Azure 리전
위치
Atlas 리전

southafricanorth

남아프리카 공화국 요하네스버그

SOUTH_AFRICA_NORTH

Azure 리전
위치
Atlas 리전

uaenorth

Dubai, UAE

UAE_NORTH

qatarcentral

Qatar

QATAR_CENTRAL

israelcentral

이스라엘

ISRAEL_CENTRAL

GCP 리전
위치
Atlas 리전

us-central1

Iowa, USA

CENTRAL_US

us-east4

미국 버지니아주 북부

US_EAST_4

us-east5

미국 오하이오주 콜럼버스

US_EAST_5

northamerica-northeast1

캐나다 몬트리올

NORTH_AMERICA_NORTHEAST_1

northamerica-northeast2

캐나다 토론토

NORTH_AMERICA_NORTHEAST_2

southamerica-east1

브라질 상파울루

SOUTH_AMERICA_EAST_1

southamerica-west1

칠레 산티아고

SOUTH_AMERICA_WEST_1

us-west1

미국 오리건주

WESTERN_US

us-west2

Los Angeles, CA, USA

US_WEST_2

us-west3

미국 유타주 솔트레이크시티

US_WEST_3

us-west4

Las Vegas, NV, USA

US_WEST_4

us-south1

Dallas, TX, USA

US_SOUTH_1

GCP 리전
위치
Atlas 리전

asia-east1

대만

EASTERN_ASIA_PACIFIC

asia-east2

중국 홍콩

ASIA_EAST_2

asia-northeast1

Tokyo, Japan

NORTHEASTERN_ASIA_PACIFIC

asia-northeast2

일본 오사카

ASIA_NORTHEAST_2

asia-northeast3

Seoul, Korea

ASIA_NORTHEAST_3

asia-southeast1

싱가포르

SOUTHEASTERN_ASIA_PACIFIC

asia-south1

인도 뭄바이

ASIA_SOUTH_1

asia-south2

인도 델리

ASIA_SOUTH_2

australia-southeast1

호주 시드니

AUSTRALIA_SOUTHEAST_1

australia-southeast2

호주 멜버른

AUSTRALIA_SOUTHEAST_2

asia-southeast2

Jakarta, Indonesia

ASIA_SOUTHEAST_2

GCP 리전
위치
Atlas 리전

europe-west1

벨기에

WESTERN_EUROPE

europe-north1

핀란드

EUROPE_NORTH_1

europe-west2

London, UK

EUROPE_WEST_2

europe-west3

독일 프랑크푸르트

EUROPE_WEST_3

europe-west4

네덜란드

EUROPE_WEST_4

europe-west6

스위스, 취리히

EUROPE_WEST_6

europe-west10

(독일 베를린)

EUROPE_WEST_10

europe-central2

(폴란드 바르샤바)

EUROPE_CENTRAL_2

europe-west8

이탈리아, 밀라노

EUROPE_WEST_8

europe-west9

(프랑스, 파리)

EUROPE_WEST_9

europe-west12

(이탈리아 토리노)

EUROPE_WEST_12

europe-southwest1

스페인 마드리드

EUROPE_SOUTHWEST_1

GCP 리전
위치
Atlas 리전

me-west1

Tel Aviv, Israel

MIDDLE_EAST_WEST_1

me-central1

Doha, Qatar

MIDDLE_EAST_CENTRAL_1

me-central2

Dammam, 사우디 아라비아

MIDDLE_EAST_CENTRAL_2

클라이언트가 샤딩된 클러스터에 연결할 때 연결 URI에 쉼표로 구분된 여러 mongos 프로세스를 포함하는 것을 권장합니다. 자세한 내용은 MongoDB 연결 문자열 예시를 참조하세요. 이 설정은 로드 밸런싱을 위해 작업을 다른 mongos 인스턴스로 라우팅할 수 있게 하지만 재해 복구에도 중요합니다.

세 개의 데이터 센터에 분산된 샤딩된 클러스터 보여주는 다음 다이어그램을 고려하세요. 애플리케이션 이 원격 위치 에서 클러스터 에 연결됩니다. 데이터 센터 3 을(를) 사용할 수 없게 되더라도 애플리케이션 다른 데이터 센터의 mongos 프로세스에 계속 연결할 수 있습니다.

세 개의 데이터 센터를 보여주는 이미지: 데이터 센터 1에는 프라이머리 샤드와 두 개의 mongos가 있고 데이터 센터 2에는 세컨더리 샤드와 두 개의 mongos가 있으며 데이터 센터 3에는 세컨더리 샤드와 두 개의 mongos가 있습니다. 애플리케이션은 모든 6개의 mongos 인스턴스에 연결됩니다.
클릭하여 확대

mongos 구성에 필요한 오류 처리를 단순화하기 위해 재시도 가능한 읽기재시도 가능한 쓰기를 사용할 수 있습니다.

MongoDB에서는 쓰기 고려를 사용하여 쓰기 작업에 대해 요청되는 확인 수준을 지정할 수 있습니다. 예를 들어, majority의 쓰기 고려를 가진 3개 노드로 구성된 복제본 세트가 있는 경우, 모든 쓰기 작업은 해당 쓰기 작업을 실행한 드라이버로 완료 확인이 전송되기 전에 두 노드에 지속되어야 합니다. 지역 노드 장애로부터 최상의 보호를 위해 쓰기 고려를 majority로 설정하는 것이 좋습니다.

majority 쓰기 고려 (write concern) 사용하면 쓰기 고려 (write concern) 1에 비해 쓰기 (write) 지연 시간 늘어나지만, 복제본 세트 프라이머리 잃더라도 데이터 센터에서 쓰기 (write) 작업을 계속 수행할 수 있으므로 majority 쓰기 고려 (write concern) 사용하는 것이 좋습니다.

숫자 쓰기 고려 (write concern) 보다 majority 쓰기 고려 (write concern) 사용할 때의 이점을 이해하려면 2-2-1 토폴로지 가 있는 3개 리전, 5노드 복제본 세트 가정하고 숫자 쓰기 고려 (write concern) 를 4. 2노드 리전 중 하나를 사용할 수 없게 되면 4개 노드에 데이터를 유지할 수 없기 때문에 쓰기 (write) 작업을 완료할 수 없습니다. majority 를 사용하면 쓰기 (write) 작업이 두 개 이상의 노드에 데이터를 유지할 때 계속해서 데이터 중복성과 쓰기 (write) 연속성을 유지할 수 있습니다.

빈번한 데이터 백업은 비즈니스 연속성과 재해 복구에 중요합니다. 자주 백업을 수행하면 재해나 사이버 공격으로 정상적인 운영이 중단되더라도 데이터 손실과 다운타임을 최소화할 수 있습니다.

다음을 수행하는 것이 좋습니다.

  • 원하는 비즈니스 연속성 목표를 충족하도록 백업 빈도를 설정하세요. 일부 시스템에서는 연속 백업이 필요할 수 있지만 다른 시스템에서는 덜 빈번한 스냅샷이 선호될 수 있습니다.

  • 백업을 원본 데이터와 다른 물리적 위치에 저장하세요.

  • 백업 복구 프로세스 테스트하여 반복 가능하고 시기적절한 방식으로 백업을 복원 할 수 있는지 확인합니다.

  • 복원 시 호환성을 위해 클러스터가 동일한 MongoDB 버전을 실행하고 있는지 확인하세요.

  • 백업 컴플라이언스 정책 을 구성하여 백업 스냅샷 삭제를 방지하고 스냅샷 보존 시간이 단축되는 것을 방지하는 등의 작업을 수행합니다.

추가 백업 권장 사항은 Atlas 백업 지침을 참조하세요.

리소스 용량 문제를 방지하려면 리소스 사용률을 모니터 하고 정기적으로 용량 계획 세션을 진행하는 것이 좋습니다. MongoDB Professional Services에서 이러한 세션을 제공합니다.

과도하게 사용되는 클러스터는 실패하여 재해를 일으킬 수 있습니다. 시스템 CPU 및 시스템 메모리 사용률이 60%+ 이상인 등 안정된 상태 에서 사용률이 정기적으로 경고를 보내는 경우 클러스터를 상위 계층으로 확장합니다.

리소스 사용률을 보려면 실시간 성능 모니터링을 참조하세요. Atlas 관리 API 사용하여 지표 보려면 모니터링 및 로그를 참조하세요.

리소스 사용률에 대한 경고 및 모니터링 모범 사례는 Atlas 모니터링 및 경고 지침을 참조하세요.

리소스 용량 문제가 발생하면 리소스 용량 문제를 참조하세요.

최신 MongoDB 버전을 실행하는 것이 좋습니다. 이는 새로운 기능을 활용할 수 있게 해주며 이전 버전에 비해 향상된 보안 보장을 제공합니다.

현재 버전의 수명이 다하기 훨씬 전에 MongoDB 메이저 버전 업그레이드를 수행해야 합니다.

Atlas UI 사용하여 MongoDB 버전을 다운그레이드할 수 없습니다. 따라서 주요 버전 업그레이드 계획하고 실행할 때 업그레이드 프로세스 중에 발생할 수 있는 문제를 방지할 수 있도록 MongoDB 전문가 또는 기술 서비스팀과 직접 협력하는 것이 좋습니다.

MongoDB를 사용하여 클러스터의 유지 관리 기간을 구성할 수 있으며, 이를 통해 Atlas가 클러스터에서 주간 유지 관리를 시작할 시간을 설정할 수 있습니다. 사용자 지정 유지 관리 기간을 설정하면 업무에 중요한 시간 외에 복제본 세트당 최소 한 번의 투표가 필요한 유지 관리를 예약할 수 있습니다.

프로젝트에 보호 시간을 설정하면, 표준 업데이트가 시작되지 않는 일일 시간 구간을 정의할 수 있습니다. 표준 업데이트는 클러스터 재시작이나 재동기화를 포함하지 않습니다.

다음 예제에서는 자동화3 위한 Atlas 도구를 사용하여 단일 리전, 노드 복제본 세트/샤드 배포서버 토폴로지 구성합니다.

이러한 예시는 다음을 포함한 다른 권장 구성에도 적용됩니다.

  • 개발/테스트 환경을 위해 클러스터 계층을 M10으로 설정합니다. 애플리케이션 크기에 맞는 권장 클러스터 계층을 알아보려면 클러스터 크기 가이드를 참조하세요.

  • 단일 리전, 3-노드 복제본 세트/샤드 배포 토폴로지

당사의 예시는 AWS, Azure 및 Google Cloud를 상호 교체하여 사용합니다. 세 곳의 클라우드 공급자 중 어느 곳이든 사용할 수 있지만 클라우드 공급자에 맞게 지역 이름을 변경해야 합니다. 클라우드 공급자와 그 지역에 대해 알아보려면 클라우드 공급자를 참조하세요.

  • 중간 규모 애플리케이션을 위해 클러스터 계층을 M30으로 설정합니다. 애플리케이션 크기에 맞는 권장 클러스터 계층을 알아보려면 클러스터 크기 가이드를 참조하세요.

  • 단일 리전, 3-노드 복제본 세트/샤드 배포 토폴로지

당사의 예시는 AWS, Azure 및 Google Cloud를 상호 교체하여 사용합니다. 세 곳의 클라우드 공급자 중 어느 곳이든 사용할 수 있지만 클라우드 공급자에 맞게 지역 이름을 변경해야 합니다. 클라우드 공급자와 그 지역에 대해 알아보려면 클라우드 공급자를 참조하세요.

참고

Atlas CLI로 리소스를 생성하기 전에 다음을 수행해야 합니다.

개발 및 테스트 환경의 경우 각 프로젝트 에 대해 다음 명령을 실행 . 값을 사용하도록 ID와 이름을 변경합니다.

atlas clusters create CustomerPortalDev \
--projectId 56fd11f25f23b33ef4c2a331 \
--region EASTERN_US \
--members 3 \
--tier M10 \
--provider GCP \
--mdbVersion 8.0 \
--diskSizeGB 30 \
--tag bu=ConsumerProducts \
--tag teamName=TeamA \
--tag appName=ProductManagementApp \
--tag env=Production \
--tag version=8.0 \
--tag email=marissa@acme.com \
--watch

스테이징 및 프로덕션 환경의 경우 각 프로젝트에 대해 다음 cluster.json 파일을 생성합니다. ID와 이름을 사용자의 값으로 변경하세요.

{
"clusterType": "REPLICASET",
"links": [],
"name": "CustomerPortalProd",
"mongoDBMajorVersion": "8.0",
"replicationSpecs": [
{
"numShards": 1,
"regionConfigs": [
{
"electableSpecs": {
"instanceSize": "M30",
"nodeCount": 3
},
"priority": 7,
"providerName": "GCP",
"regionName": "EASTERN_US",
"analyticsSpecs": {
"nodeCount": 0,
"instanceSize": "M30"
},
"autoScaling": {
"compute": {
"enabled": false,
"scaleDownEnabled": false
},
"diskGB": {
"enabled": false
}
},
"readOnlySpecs": {
"nodeCount": 0,
"instanceSize": "M30"
}
}
],
"zoneName": "Zone 1"
}
],
"tag" : [{
"bu": "ConsumerProducts",
"teamName": "TeamA",
"appName": "ProductManagementApp",
"env": "Production",
"version": "8.0",
"email": "marissa@acme.com"
}]
}

cluster.json 파일을 생성한 후 각 프로젝트에 대해 다음 명령을 실행합니다. 이 명령은 cluster.json 파일을 사용하여 클러스터를 생성합니다.

atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json

이 예시에 대한 추가 구성 옵션과 정보는 Atlas 클러스터 생성을 참조하세요.

참고

Terraform으로 리소스를 생성하기 전에 다음을 수행해야 합니다.

개발 및 테스트 환경의 경우 각 애플리케이션 및 환경 쌍에 대해 다음 파일을 생성합니다. 각 애플리케이션 및 환경 쌍에 대한 파일을 자체 디렉토리 에 배치합니다. 값을 사용하도록 ID와 이름을 변경합니다.

# Create a Project
resource "mongodbatlas_project" "atlas-project" {
org_id = var.atlas_org_id
name = var.atlas_project_name
}
# Create an Atlas Advanced Cluster
resource "mongodbatlas_advanced_cluster" "atlas-cluster" {
project_id = mongodbatlas_project.atlas-project.id
name = "ClusterPortalDev"
cluster_type = "REPLICASET"
mongo_db_major_version = var.mongodb_version
replication_specs {
region_configs {
electable_specs {
instance_size = var.cluster_instance_size_name
node_count = 3
}
priority = 7
provider_name = var.cloud_provider
region_name = var.atlas_region
}
}
tags {
key = "BU"
value = "ConsumerProducts"
}
tags {
key = "TeamName"
value = "TeamA"
}
tags {
key = "AppName"
value = "ProductManagementApp"
}
tags {
key = "Env"
value = "Test"
}
tags {
key = "Version"
value = "8.0"
}
tags {
key = "Email"
value = "marissa@acme.com"
}
}
# Outputs to Display
output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv }
output "project_name" { value = mongodbatlas_project.atlas-project.name }
# Atlas Organization ID
variable "atlas_org_id" {
type = string
description = "Atlas Organization ID"
}
# Atlas Project Name
variable "atlas_project_name" {
type = string
description = "Atlas Project Name"
}
# Atlas Project Environment
variable "environment" {
type = string
description = "The environment to be built"
}
# Cluster Instance Size Name
variable "cluster_instance_size_name" {
type = string
description = "Cluster instance size name"
}
# Cloud Provider to Host Atlas Cluster
variable "cloud_provider" {
type = string
description = "AWS or GCP or Azure"
}
# Atlas Region
variable "atlas_region" {
type = string
description = "Atlas region where resources will be created"
}
# MongoDB Version
variable "mongodb_version" {
type = string
description = "MongoDB Version"
}
# Atlas Group Name
variable "atlas_group_name" {
type = string
description = "Atlas Group Name"
}
atlas_org_id = "32b6e34b3d91647abb20e7b8"
atlas_project_name = "Customer Portal - Dev"
environment = "dev"
cluster_instance_size_name = "M10"
cloud_provider = "AWS"
atlas_region = "US_WEST_2"
mongodb_version = "8.0"
# Define the MongoDB Atlas Provider
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
required_version = ">= 0.13"
}

파일을 생성한 후 각 애플리케이션과 환경 쌍의 디렉토리로 이동하여 다음 명령을 실행하여 Terraform을 초기화합니다.

terraform init

Terraform 계획을 보려면 다음 명령을 실행합니다.

terraform plan

애플리케이션 및 환경 쌍에 대해 하나의 프로젝트와 하나의 배포를 생성하려면 다음 명령을 실행합니다. 명령은 파일과 MongoDB & HashiCorp Terraform을 사용하여 프로젝트와 클러스터를 생성합니다.

terraform apply

메시지가 표시되면 yes를 입력하고 Enter 키를 눌러 구성을 적용합니다.

스테이징 및 프로덕션 환경의 경우 각 애플리케이션과 환경 쌍에 대해 다음 파일을 생성하세요. 각 애플리케이션과 환경 쌍의 파일은 별도의 디렉토리에 배치하세요. ID와 이름을 사용자의 값으로 변경하세요.

# Create a Group to Assign to Project
resource "mongodbatlas_team" "project_group" {
org_id = var.atlas_org_id
name = var.atlas_group_name
usernames = [
"user1@example.com",
"user2@example.com"
]
}
# Create a Project
resource "mongodbatlas_project" "atlas-project" {
org_id = var.atlas_org_id
name = var.atlas_project_name
# Assign the Project the Group with Specific Roles
team_id = mongodbatlas_team.project_group.team_id
role_names = ["GROUP_READ_ONLY", "GROUP_CLUSTER_MANAGER"]
}
# Create an Atlas Advanced Cluster
resource "mongodbatlas_advanced_cluster" "atlas-cluster" {
project_id = mongodbatlas_project.atlas-project.id
name = "ClusterPortalProd"
cluster_type = "REPLICASET"
mongo_db_major_version = var.mongodb_version
replication_specs {
region_configs {
electable_specs {
instance_size = var.cluster_instance_size_name
node_count = 3
}
priority = 7
provider_name = var.cloud_provider
region_name = var.atlas_region
}
}
tags {
key = "BU"
value = "ConsumerProducts"
}
tags {
key = "TeamName"
value = "TeamA"
}
tags {
key = "AppName"
value = "ProductManagementApp"
}
tags {
key = "Env"
value = "Production"
}
tags {
key = "Version"
value = "8.0"
}
tags {
key = "Email"
value = "marissa@acme.com"
}
}
# Outputs to Display
output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv }
output "project_name" { value = mongodbatlas_project.atlas-project.name }
# Atlas Organization ID
variable "atlas_org_id" {
type = string
description = "Atlas Organization ID"
}
# Atlas Project Name
variable "atlas_project_name" {
type = string
description = "Atlas Project Name"
}
# Atlas Project Environment
variable "environment" {
type = string
description = "The environment to be built"
}
# Cluster Instance Size Name
variable "cluster_instance_size_name" {
type = string
description = "Cluster instance size name"
}
# Cloud Provider to Host Atlas Cluster
variable "cloud_provider" {
type = string
description = "AWS or GCP or Azure"
}
# Atlas Region
variable "atlas_region" {
type = string
description = "Atlas region where resources will be created"
}
# MongoDB Version
variable "mongodb_version" {
type = string
description = "MongoDB Version"
}
# Atlas Group Name
variable "atlas_group_name" {
type = string
description = "Atlas Group Name"
}
atlas_org_id = "32b6e34b3d91647abb20e7b8"
atlas_project_name = "Customer Portal - Prod"
environment = "prod"
cluster_instance_size_name = "M30"
cloud_provider = "AWS"
atlas_region = "US_WEST_2"
mongodb_version = "8.0"
atlas_group_name = "Atlas Group"
# Define the MongoDB Atlas Provider
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
required_version = ">= 0.13"
}

파일을 생성한 후 각 애플리케이션과 환경 쌍의 디렉토리로 이동하여 다음 명령을 실행하여 Terraform을 초기화합니다.

terraform init

Terraform 계획을 보려면 다음 명령을 실행합니다.

terraform plan

애플리케이션 및 환경 쌍에 대해 하나의 프로젝트와 하나의 배포를 생성하려면 다음 명령을 실행합니다. 명령은 파일과 MongoDB & HashiCorp Terraform을 사용하여 프로젝트와 클러스터를 생성합니다.

terraform apply

메시지가 표시되면 yes를 입력하고 Enter 키를 눌러 구성을 적용합니다.

이 예제에 대한 추가 구성 옵션과 정보는 MongoDB & HashiCorp TerraformMongoDB Terraform 블로그 게시물을 참조하세요.

돌아가기

신뢰성

이 페이지의 내용