pile·
DB / 데이터·그린데이터그린데이터·

MongoDB 4.4에서 5.0으로 업그레이드 하기

한국그린데이터가 메인 DB 로 쓰는 MongoDB Atlas 를 4.4 에서 5.0 으로 올리고 NestJS 도 7.6 에서 8.2 로 함께 올린 기록이다. 정작 손이 많이 간 곳은 DB 자체가 아니라 mongoose 5 에서 6 으로 넘어가며 터진 옵션과 타입 에러 대응이었다.

핵심 포인트
  • Atlas 의 Shared cluster(M0/M2/M5) 는 강제 업그레이드 대상이었지만 이 팀은 Dedicated 라 영향이 없었고, 5.0 의 성능과 신기능을 쓰려고 자발적으로 올렸다.
  • 의존성은 @nestjs/core 8.2.6 을 기준으로 호환 버전을 맞췄고, mongoose 는 6.1.2 에서 버그를 만나 6.1.7 로 바꿨다.
  • mongoose 6 부터 useNewUrlParser, useCreateIndex, useUnifiedTopology, useFindAndModify 옵션이 사라져 MongoParseError 가 난다.
  • _id 를 ObjectId 가 아닌 string 으로 쓰는 구조라, Native Driver 를 쓰는 마이그레이션 코드에서 타입 에러가 발생했다.
  • Atlas 는 한 번 업그레이드하면 다운그레이드가 불가능하므로 여유를 두고 신중히 진행해야 한다.
상세 정리
  • mongoose 6.1.2 와 6.1.7 은 둘 다 MongoDB Node.js Driver 4.2.2 를 쓰므로 MongoDB 5.2 까지 호환된다.
  • 옵션 에러 대응: MongooseModule.forRoot 에 넘기던 deprecated 옵션 4종을 제거하면 된다. mongoose 6 은 그 동작을 기본값으로 내장한다.
  • bulkWrite 반환 타입이 BulkWriteOpResultObject 에서 BulkWriteResult 로 바뀌어, updateOne 과 조합해 만든 upsertBulk 구현부에서 타입 에러가 났다.
  • _id 를 string 으로 쓰는 이유는 API 로 넘어온 id 를 매번 ObjectId 로 변환해 조회하는 수고를 덜기 위해서다. 스키마에서 type String 에 default 로 ObjectId 를 문자열화해 넣는다.
  • 다만 migrate-mongodb 패키지는 mongoose 가 아닌 Native MongoDB Driver 를 쓰므로 seed 삽입 코드에서 collection 호출에 _id 가 string 인 제네릭을 명시해야 타입 에러가 사라진다.
  • mongoose 6.1.2 에서는 aggregate 의 $group 사용 시 Property '_id' is incompatible with index signature 에러가 났다. 스펙 변경이 아니라 버그였고 6.1.3 에서 고쳐져 6.1.7 로 올려 해결했다.
  • 개발 환경은 로컬 Docker 이미지를 mongo:5.0 으로 바꾸고, Dev 와 Prod 는 Atlas 클러스터의 Edit Configuration 에서 Additional Settings 의 버전을 5.0 으로 선택한다.
  • 진행 순서는 로컬 검증, Dev 배포 후 최종 테스트, Prod 배포다. 인스턴스 종류와 용량에 따라 완료 시간이 달라진다.
  • @nestjs/microservices 는 MQTT 5 Shared Subscription 을 쓰려고 수정한 버전을 파일 경로로 물려 쓰고 있다.
왜 읽나mongoose 5 에서 6 으로 넘어가며 옵션과 타입 에러를 만난 Node.js 백엔드 개발자에게 에러별 대응을 바로 대조해볼 수 있는 체크리스트.
그린데이터
그린데이터 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5