Realm Mobile Sync 프로덕션 체크리스트
Atlas Device Sync, Atlas Edge Server, Data API 및 HTTPS endpoints 는 더 이상 사용되지 않습니다. 자세한 내용은 지원 중단 페이지를 참조하세요.
최적의 성능과 원활한 사용자 환경을 보장하려면 다음 권장사항을 따르는 것이 좋습니다.
서비스 제한 사항에 대한 관련 정보는 서비스 제한 사항을 참조하세요 .
Atlas cluster 구성
- 전용 Atlas 클러스터 사용
프로덕션 앱은 최소한
M10전용 cluster를 사용해야 합니다. 사용 사례에 따라 최적의 성능을 위해 상위 계층으로 업그레이드해야 할 수도 있습니다.M0,M2또는M5와 같은 공유 클러스터를 사용하는 경우 제한된 리소스 및 다른 사용자와의 경합으로 인해 성능 문제가 발생할 수 있습니다. 프로덕션 환경으로 전환한 후 공유 계층에서 전용 계층으로 업그레이드하는 경우, Device Sync를 종료 하고 모든 클라이언트 애플리케이션을 재설정하거나 다시 설치해야 합니다.- Atlas oplog
- Device Sync 에는 동기화된 클러스터 에 대한 시간 기반 oplog 에 대한 액세스 가 필요합니다. 모든 새 Atlas 클러스터는 기본값 이 기능을 제공합니다. 최상의 결과를 얻으려면 Device Sync 를 사용하여 클러스터 에 대해 48 시간의 oplog 를 유지하세요.
- MongoDB 버전
- 가능하면 최신 버전의 MongoDB를 사용하세요. 일부 Realm Mobile Sync 최적화에서는 새로운 MongoDB 버전 기능 및 개선 사항을 사용합니다.
- NVMe 최소 MongoDB 버전
- 클러스터 가 NVMe 스토리지 를 사용하는 hardware 에서 실행되는 경우 Device Sync 프로덕션 애플리케이션에 MongoDB 버전 6.0 이상을 사용해야 합니다.
- 기본 제공 스키마 유효성 검사 비활성화 또는 managed
App Services 의 스키마 는 MongoDB의 내장 스키마 유효성 검사 와 동일하지 않습니다 . Device Sync 는 내장 스키마 와 호환되지 않는 방식으로 클러스터 와 상호 작용 수 있습니다.
클러스터에서 스키마 유효성 검사를 사용하는 경우 App Services 스키마를 위해 비활성화하거나 두 스키마 유효성 검사 계층이 호환되도록 관리해야 합니다. 자세한 내용은 App Services 스키마와 내장 스키마 유효성 검사를 참조하세요.
App Services 구성
- 배포 모델 및 지리적 리전
- Realm Mobile Sync 애플리케이션을 구축할 때는 로컬 배포 모델 을 사용하세요. 동일한 리전 및 cloud 공급자 내에서 실행되도록 앱과 MongoDB 데이터 소스를 구성합니다.
- 클라이언트 최대 오프라인 시간 정의
- App Services 백엔드는 기본 데이터의 변경 기록을 사용하여 클라이언트를 동기화합니다. 클라이언트 최대 오프라인 시간 을 구성하여 앱에 저장된 기록의 일수를 제어합니다. 해당 일 수 이상 동기화되지 않은 클라이언트는 다음에 백엔드에 연결할 때 클라이언트 재설정을 수행해야 합니다.
클라이언트 애플리케이션 코드
- 클라이언트 재설정 처리기 정의
- 클라이언트와 서버 기록이 서로 다른 심각한 오류 상태를 복구하려면 SDK로 동기화된 각 영역을 열 때 클라이언트 재설정 핸들러를 정의해야 합니다.
데이터 모델 및 스키마
- 호환성이 손상되는 변경 방지
- 동기화를 활성화한 후에는 Realm 데이터 모델을 수정하는 방법에 제한이 있습니다. 특히, Sync는 지정된 속성의 유형 변경과 같은 Realm 객체 유형에 대한 호환성이 손상되는 변경 을 지원하지 않습니다. 호환성이 손상되는 변경을 적용하려면 업데이트된 데이터 모델과의 동기화를 종료했다가 다시 허용해야 합니다.
- App Services 스키마 데이터 일관성
- 또는 Device Sync 와 같은 다른 도구를 사용하여 문서를 만들거나 mongosh shell 수정하는 MongoDB Compass 경우 컬렉션 의 App Services 스키마 에 대해 문서의 유효성을 검사해야 합니다. 자세한 내용은 동기화되지 않은 문서를 참조하세요.
성능 모범 사례
- 프로덕션 부하 테스트
- 동기화 프로덕션 로드 테스트를 통해 확장된 프로덕션 배포에서 성능을 측정하고 문제를 식별합니다.
- 쓰기 트랜잭션(write transaction) 크기
- 대량의 데이터를 쓸 때는 하나의 대규모 트랜잭션 대신 여러 개의 작은 쓰기 트랜잭션(write transaction)을 사용하는 것이 좋습니다. Atlas cluster 버전 및 구성에 따라 16MB를 초과하는 쓰기 트랜잭션 (write transaction)은 MongoDB에서 거부되어 동기화 작업이 실패할 수 있습니다.