☰

MongoDB on AWS(EBS): 복제본 3개 vs. 복제본 2개 + Arbiter

tag-icon • tag-icon replication mongodb
MongoDB on AWS(EBS): 복제본 3개 vs. 복제본 2개 + Arbiter

우리는 AWS에서 실행되는 상당히 큰 Mongo DB를 보유하고 있습니다. 현재 우리는 3개의 인스턴스로 구성된 복제본 세트를 실행하고 있습니다. 각 인스턴스에는 5TB의 EBS 스토리지가 연결되어 있습니다. 이는 인스턴스당 월 $1000 이상입니다. 게다가 우리는 프로덕션 환경과 스테이징 환경을 모두 갖추고 있습니다(세 번째 "개발" 환경은 곧 출시될 예정입니다). 또한, 이러한 비용은 미래에 샤딩된 환경으로 이동할 때 폭발적으로 증가할 것입니다.

문제는 AWS 환경에서 3개의 복제본이 얼마나 필요한가입니다.

알았어 알았어, 대답은 "상황에 따라 다르다"는 것을 이미 알고 있습니다. 내가 찾고 있는 것은 장단점을 가장 잘 평가하는 방법에 대한 조언입니다. 예를 들어...

  1. 각 EBS 볼륨에는 이미 3중 중복이 내장되어 있고 백업에서 복원하는 것이 매우 간단하다는 점을 고려할 때 2개 대 3개 복제본의 추가된 내결함성을 어떻게 측정합니까?

  2. 장단점을 고려할 때 중복성 외에 추가 고려 사항이 있습니까?

  3. 2개의 복제본과 Arbiter만 실행한 경험(좋은지 나쁜지)이 있는 사람이 있습니까?

답변1

  1. 각 EBS 볼륨에는 이미 3중 중복이 내장되어 있고 백업에서 복원하는 것이 매우 간단하다는 점을 고려할 때 2개 대 3개 복제본의 추가된 내결함성을 어떻게 측정합니까?

MongoDB에 관한 한, 3개 노드 복제본 세트에 2개의 데이터 보유 멤버만 있는 주요 고려 사항은 해당 데이터 보유 멤버 중 하나가 어떤 이유로든(계획된 유지 관리 또는 계획되지 않은 오류) 사용할 수 없는 경우입니다.

  • 더 이상 활성 복제가 없습니다(데이터 보유 멤버가 하나만 남아 있음).
  • 배포에서는 더 이상 다음보다 높은 쓰기 문제를 확인할 수 없습니다 w:1(예: w:majority또는 w:2).

이 구성은 단일 멤버 실패 시 기본 멤버 유지/선택 측면에서 고가용성을 제공하지만, 데이터 보유 멤버 중 하나를 사용할 수 없는 경우 중재자는 데이터 중복성을 손상시킵니다. EBS 백업에서 복원할 수 있는 합리적인 시간이 있고 EBS 중복성에 대한 신뢰가 있다고 가정하면 이는 사용 사례에 허용되는 절충안일 수 있습니다.

  1. 장단점을 고려할 때 중복성 외에 추가 고려 사항이 있습니까?

코드가 MongoDB를 사용하는 경우우려 사항 쓰기기본값( w:1)보다 높은 값을 추가하고 싶을 것입니다.wtimeout값. 옵션을 지정하지 않고 wtimeout쓰기 문제 수준을 달성할 수 없는 경우 쓰기 작업이 무기한 차단됩니다.

중복 인프라에 대한 AWS 보장은 일반적으로 여러 가용 영역에 걸친 장애까지만 확장되므로 가용성을 최대화하려면 복제본 세트 멤버를 다른 가용 영역에 배포해야 합니다.

  1. 2개의 복제본과 Arbiter만 실행한 경험(좋은지 나쁜지)이 있는 사람이 있습니까?

나는 사용자가 위 사항을 고려하지 못한(특히 쓰기 문제 및 시간 초과를 고려한 경우) 나쁜 결과를 본 적이 있습니다. 이러한 주의 사항을 염두에 두고 계획하고 테스트한다면 좋은 경험을 얻을 수 있을 것입니다.

게다가 우리는 프로덕션 환경과 스테이징 환경을 모두 갖추고 있습니다(세 번째 "개발" 환경은 곧 출시될 예정입니다).

프로덕션과 유사한 스테이징 및 개발 환경을 보유해야 한다는 주장이 분명 있지만, 일반적인 비용 절감은 프로덕션보다 장애 조치가 적은 개발용 저사양 환경을 배포하는 것입니다. 스테이징의 경우 더 낮은 사양의 환경을 배포하고 싶지만 유사한 구성을 사용하여 현실적인 장애 조치 시나리오를 테스트할 수 있습니다. 스테이징 환경에서 성능 또는 로드 테스트를 수행하는 경우 프로덕션과 동일한 사양으로 프로비저닝해야 합니다.

관련 정보