Atlas 비용 절감 구성을 위한 권장 사항

사용률이 낮은 클러스터 축소

Performance Advisor 및 클러스터 지표 사용하여 크기가 큰 클러스터를 식별합니다. 완전히 활용되지 않은 지속적으로 낮은 System Max: User CPU utilization (45% 미만) 또는 초과 RAM 있는지 찾습니다. 그런 다음 실제 워크로드 패턴에 더 잘 맞는 계층 으로 규모를 축소합니다.

많은 팀이 더 큰 클러스터로 시작하여 실제 사용 패턴을 학습 하면서 조정하는 것을 잊습니다. Atlas 더 가벼운 워크로드를 위한 Low CPU 옵션과 유연한 크기 조정을 제공하여 리소스를 추측하는 대신 현실에 맞출 수 있습니다. 적절한 크기로 조정하는 것이 가장 큰 비용 부담이 되는 경우가 많습니다.

자세히 학습 반응형으로 클러스터 축소를 참조하세요.

• 클러스터 계층에서 자동 확장을 활성화하여 사용량에 맞추고 오버프로비저닝을 방지하세요.

  축소는 6시간마다 한 번씩 발생하며 특정 조건을 충족해야 합니다. 자세한 내용은 클러스터 계층 축소를 참조하세요.

  정상 사용 기간 동안 연속된 30일에 걸쳐 클러스터의 CPU, WiredTiger 캐시, 메모리, IOPS 등을 정기적으로 모니터링하여 수동으로 더 낮은 클러스터 티어로 이동할 수도 있습니다. 일반적으로 사용량이 할당된 리소스의 45% 이하로 지속적으로 유지되면 축소할 것을 권장합니다.

• 전용 클러스터의 경우, 더 낮은 계층으로 확장하거나 장기간 사용하지 않을 경우 클러스터 일시 중지 하는 것이 좋습니다.

  개발 및 테스트 환경에서는 M10 또는 M30 클러스터를 사용하는 것이 좋습니다. 자세한 내용은 Atlas 클러스터 크기 가이드를 참조하세요.

• 개발 및 테스트 환경의 경우 다음을 권장합니다.

  • 클러스터에서 활발한 개발 활동이 없는 야간에는 개발 및 테스트 클러스터를 일시 중지하도록 크론 작업을 활성화하세요. 다음 방법 중 하나를 사용할 때 paused 필드를 true로 설정하여 Atlas 관리 API로 클러스터를 일시 중지할 수 있습니다.

    • 단일 클러스터 수정 엔드포인트

    • Terraform 클러스터 리소스

  • 타사 지표 또는 경고 시스템에서 개발자 또는 테스트 클러스터 에 일주일 이상 활동이 없는 경우 트리거되는 경고 설정합니다.

  • 일정 시간이 경과하면 사용하지 않는 개발 및 테스트 클러스터를 종료하는 것이 좋습니다. 클러스터 소유자에게 이메일로 충분히 알립니다. 다음 방법을 사용하여 클러스터를 종료할 수 있습니다.

    • 하나의 클러스터 엔드포인트 제거 를 사용하여 Atlas 관리 API 실행합니다.

    • Terraform 클러스터 리소스에서 termination_protection_enabled 필드를 false로 설정

불균등한 샤드 배포 방지

샤딩된 클러스터의 경우 핫 샤드방지하기 위해 확장 전략을 검토 . 핫 샤드 클러스터 의 하나의 샤드 다른 샤드보다 불균형적으로 더 많은 트래픽이나 데이터를 수신하여 해당 단일 샤드 에만 더 많은 리소스가 필요한 경우 전체 클러스터 확장하다 해야 할 때 발생합니다.

컬렉션이 샤드에 어떻게 분산되어 있는지 확인하여 이러한 한쪽으로 치우친 상황을 파악하세요. 아직 샤딩된 되지 않은 사용량이 많은 컬렉션을 찾습니다. 전체 클러스터 크기를 확장하다 할 수 있도록 적절하게 배포합니다. 또한 각 컬렉션을 실제로 사용하는 방식에 따라 다양한 컬렉션에 대해 서로 다른 샤딩 접근 방식을 설정하다 수 있습니다. 먼저 트래픽을 리밸런싱하여 샤드 간에 균등하게 유지하되, 이것이 불가능한 경우 독립적인 샤드 기능 활용합니다.

독립적인 샤드 확장 사용하지 않는 경우, 전체 클러스터 에서 실제로 필요하지 않은 리소스를 확장하다 데 비용을 지불하게 되므로 핫 샤드 비용이 많이 듭니다. 스마트 샤딩 통해 부하를 보다 균등하게 분산하면 설정 조정하고 불필요한 비용을 방지할 수 있습니다. 절감액은 특정 워크로드 에 따라 다르지만, 이러한 접근 방식은 데이터 패턴이 변경됨에 따라 안정적이고 비용 효율적인 방식으로 성장하는 데 도움이 됩니다.

자세한 내용은 Atlas 확장성 지침을 참조하세요.

백업 구성 최적화

• 연속 백업 은 비용이 많이 들지만 재해 또는 코드 로직 오류가 발생한 경우 백업 창 내의 어느 점 에서든 데이터를 복구할 수 있는 가장 안전한 방법을 제공합니다. 가장 중요한 데이터 계층 프로덕션 애플리케이션에 대해서만 연속 백업을 활성화 좋습니다.

• 덜 중요한 데이터를 저장 클러스터의 백업 빈도를 낮춥니다. 개발 환경에서는 이러한 클러스터를 완전히 종료하는 것이 좋습니다.

데이터 전송 패턴 최적화

가능하면 동일한 제공자, 동일한 리전 데이터 전송 선택하여 비용을 최소화하세요. 다른 리전 에서 애플리케이션 복원 해야 하는 재해 복구 시나리오와 같이 필요한 경우에만 리전 간 또는 인터넷 전송을 사용합니다. 대부분의 리전 (일반적으로 애플리케이션 호스팅하다 리전)에 클러스터 배치하면 데이터 전송 비용을 크게 줄일 수 있습니다.

네트워크 트래픽 압축

클라이언트 드라이버에서 네트워크 압축을 활성화하여 클라이언트와 서버 간의 데이터를 압축합니다. 예를 들어 Node.js 드라이버에 대해 네트워크 압축 옵션을 구성할 수 있습니다. Atlas는 항상 클러스터 내 통신을 압축합니다.

자세한 내용은 데이터 전송 비용 절감 방법을 참조하세요.

연결 풀링 최적화

애플리케이션의 연결 풀 설정을 검토하고 실제 동시 사용 패턴에 맞게 크기를 적절하게 조정합니다. 대부분의 애플리케이션은 적절한 연결 시간 초과 및 재시도 로직을 추가하면서 기본값 설정에서 최대 풀 크기를 안전하게 줄일 수 있습니다.

각 데이터베이스 연결은 애플리케이션 과 클러스터 측 모두에서 리소스를 소비합니다. 과도하게 프로비저닝된 연결 풀은 불필요한 오버헤드 생성하고 실제로 연결 스래싱을 통해 성능을 저하시킬 수 있습니다.

자세한 학습 은 MongoDB Atlas 연결 제한 및 클러스터 계층을 참조하세요.

비효율적인 쿼리 방지

데이터에 액세스하는 모든 애플리케이션과 프로세스에서 비효율적인 부분이 없는지 확인합니다. 쿼리가 다음을 수행하지 않도록 확인합니다.

• 클라이언트에 이미 존재하는 데이터를 다시 읽습니다.

• 클러스터에 기존 데이터를 다시 작성합니다.

자세한 내용은 데이터 전송 비용 절감 방법을 참조하세요.

쿼리 최적화

실행 시간이 오래 걸리는 쿼리는 리소스 사용량이 증가하여 더 높은 계층의 클러스터가 필요할 수 있습니다. 이러한 쿼리를 최적화 하여 리소스 소비를 줄이고 결과적으로 비용을 절감하세요.

팀 과 함께 분기별로 쿼리 조정을 예약하여 가장 느린 쿼리를 검토 하고 인덱스 공간을 감사 . Performance Advisor 사용하여 누락된 인덱스를 식별하고 쿼리 프로파일러 사용하여 비용이 많이 드는 작업을 찾아보세요. 가장 10 비용이 많이 드는 상위 개 쿼리와 해당 최적화 상태를 추적 할 수 있는 간단한 스프레드시트를 만듭니다.

데이터가 증가하면 쿼리 성능이 저하됩니다. 1GB 에서 성능이 좋은 쿼리 100GB 의 예산을 쉽게 초과할 수 있습니다. 한편, 사용하지 않는 인덱스는 저장 소모하고 가치를 제공하지 못한 채 쓰기 속도를 저하시킵니다. 정기적인 검토를 통해 성능 드리프트를 조기에 포착하여 인덱싱 전략을 간결하고 목적에 맞게 유지할 수 있습니다.

자세한 학습 은 느린 쿼리 분석을 참조하세요.

일시 중지된 Atlas Search 인덱스

다음과 같은 이유로 Atlas Search 인덱스 오래되었을 수 있습니다.

• 디스크 사용률이 높아 복제가 중지되었습니다.

  전용 Atlas Search 노드의 경우, 클러스터 의 모든 쓰기에 대해 복제 일시 중지 임계값은 90%이고 복제 복제 임계값은 85% 디스크 사용률입니다. 전용 Atlas Search 노드가 없는 경우, 클러스터 의 모든 쓰기에 대해 복제 일시 중지 임계값은 96%이고 복제 복제 임계값은 94% 디스크 사용률입니다.

• 복제 oplog window 보다 긴 기간 동안 중지되면 Atlas Search mongot 프로세스 oplog 에서 중단된 다음 다시 동기화해야 합니다.

  이 상태 일반적으로 oplog 에서 현재 복제 점 더 이상 사용할 수 없을 때 mongod 발생합니다. 프로세스 oplog 에서 떨어지면 Atlas 인덱스 다시 작성하는 mongot 데, 이 작업은 리소스 많이 사용하고 상당한 시간이 걸릴 수 있습니다.

• 인덱스가 20억 개의 문서 제한에 도달했습니다.

• 오류로 인해 복제가 실패했습니다.

기존 인덱스 계속 쿼리 할 수 있습니다. 그러나 오래된 인덱스 에 대한 쿼리 결과에는 오래된 데이터가 포함될 수 있습니다. 검색 노드를 업스케일링하여 더 많은 디스크 공간을 확보하고, 현재 차단 임계값을 초과하지 않은 경우 기존 인덱스를 삭제 디스크 공간을 출시하다 수 있습니다. 또는 View status details 모달 창 오류를 사용하여 문제를 해결합니다.

자세한 학습 은 MongoDB 검색 문제 해결을 참조하세요.

스키마 패턴 최적화

Atlas 팀 과 함께 컬렉션을 검토 하여 문서 크기가 큰 문서, 무제한 배열 또는 비용이 많이 드는 작업을 강제하는 스키마와 같이 비용이 많이 드는 패턴이 있는지 검토하세요. 개별 문서를 합리적인 크기로 유지하면서 함께 액세스하는 관련 데이터를 포함할 수 있는 기회를 찾으세요. 더 간단한 문서 구조가 효과적일 수 있다면 복잡한 애그리게이션이나 컬렉션 간 조회가 필요한 패턴을 제거하는 데 집중하세요.

잘못된 스키마 설계 비효율적인 쿼리와 저장 확장을 통해 조용히 비용을 증가시킵니다. Atlas 문서 모델 올바르게 설계하면 비용이 많이 드는 관계형 작업이 자연스럽게 필요하지 않습니다. 잘 설계된 컬렉션은 컴퓨팅 오버헤드 줄이고, 인덱스 요구 사항을 최소화하고, 쿼리 성능을 개선하며, 이 모든 것이 월 청구서에 직접적인 영향 .

자세한 학습 은 스키마 설계를 참조하세요.

스토리지 최적화

온라인 보관 또는 TTL 인덱스와 같은 기능을 사용하여 오래된 데이터를 비용이 더 발생하는 핫 스토리지에서 비용이 덜 발생하는 콜드 스토리지로 이동하거나 더 이상 필요하지 않은 데이터를 삭제하세요. 데이터를 보관한 후 Atlas Data Federation을 통해 데이터에 접근할 수 있습니다.

비용 탐색기 사용

Cost Explorer 도구를 정기적으로 사용하여 조직, 프로젝트, 클러스터 및 서비스 수준에서 지출 패턴을 모니터 . 필요에 맞는 빈도를 설정합니다.

경고 설정

월별 비용이 일정 금액을 초과하는 경우와 같은 주요 임계값에 대한 청구 알림을 구성합니다. 예시 들어, 비용이 $100를 초과하면 경고 설정하다 . 이러한 사전 예방적 접근 방식은 예기치 않은 상황을 방지하는 데 도움이 됩니다.

청구서 검토

매월 청구서를 검토 하여 이전 청구 최적화 제안을 사용하여 가장 비용이 많이 드는 서비스를 평가합니다. 이는 비용 절감 기회를 식별하는 데 권장되는 모범 사례입니다.

청구서에 예기치 않은 변경 사항이 있는 경우 청구서의 가장 큰 부분을 차지하는 클라우드 컴퓨팅 비용을 확인하세요. Atlas Billing 섹션에 있는 모든 청구서의 Summary By Service 카드에서 클라우드 컴퓨팅 비용을 검토 할 수 있습니다. Summary By Service 보기에는 모든 클러스터의 제공자, 계층 및 리전 별 비용이 표시됩니다.

적절한 배포서버 패러다임과 토폴로지 선택

선택하는 배포서버 패러다임과 토폴로지에 따라 Atlas 비용이 달라질 수 있습니다.

다양한 토폴로지의 비용 절감에 대한 자세한 내용은 Atlas 고가용성 지침을 참조하세요.

리소스 태그 지정 설정

팀, 환경 또는 비용 센터별로 Atlas 프로젝트 및 클러스터에 일관적인 태그를 적용하세요. '팀 마케팅', '환경 프로덕션' 또는 '프로젝트 모바일 앱'과 같은 설명 태그를 사용하여 조직 전체에 걸쳐 명확한 소유권과 지출 가시성을 제공합니다.

적절한 태그 지정이 없으면 비용을 유발하는 팀이나 프로젝트를 추적 할 수 없는 Atlas 청구서가 난독화됩니다. 리소스 태깅을 사용하면 Cost Explorer를 강력한 책임 도구로 변환하여 비용 추세를 파악하고, 비용을 정확하게 할당하고, 부서 또는 워크로드 유형별로 최적화 기회를 쉽게 파악할 수 있습니다.

자세히 학습 리소스 태그를 참조하세요.