▲

GN⁺: MongoDB에서 PostgreSQL로 대규모 이전한 후기

 (infisical.com)
11P by neo 1달전 | favorite | 댓글 1개
  • Infisical은 하루에 5천만 개 이상의 Secret을 처리하는 플랫폼으로 급성장
  • 사용량 증가에 따라 스택을 지속적으로 업그레이드해야 했으며, 최근에는 MongoDB에서 PostgreSQL로 전체 데이터베이스 마이그레이션을 진행
  • 이 마이그레이션은 신기술 채택, 데이터베이스 스키마 생성, 로직 재구성, 쿼리 재작성, 수백만(또는 수십억) 데이터 레코드를 PostgreSQL로 이전하는 복잡한 과정을 포함

시작 단계

  • Infisical을 처음 구축할 때, 팀에 가장 익숙한 스택을 사용하여 MongoDB + Mongoose ORM을 선택
  • 초기에는 Infisical Cloud, 관리형 SaaS 제공에 더 집중했으며, 사용자가 제품을 자체 호스팅하는 경우를 많이 예상하지 않았음

MongoDB가 아닌 이유?

  • MongoDB는 초기에는 잘 작동했지만, 제품 사용 사례가 관리형 서비스를 넘어서면서 단점이 드러나기 시작
  • 많은 조직들이 Infisical Cloud 대신 Infisical을 자체 호스팅하는 것을 선호했으며, 일부는 온프레미스 요구 사항을 충족해야 했음
  • MongoDB의 제약 사항과 사용성 문제로 인해 PostgreSQL로 전환하기로 결정

PostgreSQL을 선택한 이유?

  • 새로운 데이터베이스를 찾으면서 관리 용이성, 트랜잭션 지원, 관계형 기능 등이 중요한 요소로 고려됨
  • 내부 저장소와 외부 저장소 솔루션 사이에서 고민했으나, PostgreSQL을 선택
  • PostgreSQL은 활발한 커뮤니티, 풍부한 문서, 다양한 솔루션 및 확장 기능을 제공하며, 대부분의 클라우드 제공업체에서 관리형 서비스를 제공

ORM에 대하여

  • PostgreSQL을 선택한 후, 애플리케이션이 데이터베이스와 상호작용하는 방식을 결정해야 했음
  • Mongoose ORM과 유사한 경험을 제공하는 도구를 찾았으며, Knex.js 쿼리 빌더를 사용하기로 결정함
  • Knex.js는 씨딩 및 마이그레이션 도구를 제공하며, TypeScript 지원을 위한 맞춤형 Zod 통합 작업을 통해 만족스러운 수준에 도달

마이그레이션 계획

  • 코드 재작성이 끝나갈 무렵, MongoDB 데이터를 PostgreSQL로 최소한의 중단으로 매핑하는 마이그레이션 작업을 어떻게 수행할지 고민
  • 중요한 인프라에서 역할을 하는 Infisical의 경우 절대 다운타임을 허용할 수 없었으며, 마이그레이션 기간 동안 쓰기 작업을 금지하는 타협을 함

대이동

  • 마이그레이션 준비를 위해 자세한 체크리스트와 예상 시간표를 작성
  • 마이그레이션은 6시간 동안 읽기 작업만 허용하면서 수행되었으며, 데이터 이동 후 DNS를 새 인스턴스로 전환

결과

  • 마이그레이션은 데이터 손실 없이 순조롭게 진행되었으며, 고객에게 미치는 영향이 최소한인 몇 가지 기능 오류를 36시간 이내에 수정
  • 플랫폼은 조인을 통한 쿼리 최적화로 인해 성능 향상을 경험했으며, 데이터베이스 비용도 50% 절감
  • PostgreSQL 도입으로 데이터 유효성 검사가 개선되었으며, 이제 Infisical은 자체 호스팅이 훨씬 쉬워짐

결론

  • MongoDB에서 PostgreSQL로의 이동 결정은 쉽지 않았으며, 신중한 계획과 논의를 거쳐 3-4개월이 걸렸음
  • 이러한 큰 프로젝트를 시도하기 전에 사용 사례와 구현을 심도 있게 생각할 것을 권장
▲
neo 1달전  [-]
Hacker News 의견

  • Postgres와 MongoDB를 대규모로 운영한 경험이 있는 한 사용자는 두 데이터베이스 모두 좋아하지만, Postgres의 고가용성(HA)과 수평 확장 지원 부재에 대해 이해할 수 없다고 언급함. Postgres 설치가 매번 독특하며, 여러 확장 기능과 스크립트를 사용해 이를 보완해야 한다고 지적함. 이러한 확장 기능들은 종종 버그가 많고 문서화가 부족하다고 덧붙임. Postgres의 주요 버전 파일 형식 변경으로 인해 업그레이드가 매우 힘들다고 언급함. MySQL이 HA/샤딩에서 Postgres보다 훨씬 나은 점에 대해 놀라워함.

  • MongoDB에서 PostgreSQL로의 마이그레이션 경험을 기술적인 관점에서 설명한 블로그 포스트를 공유함. 이 포스트는 예제와 그래프를 포함하여 더 기술적이고 비즈니스적인 내용이 적다고 언급함.

  • PostgreSQL이 데이터베이스 세계를 점령하고 있다고 언급하는 사용자는, 저자들이 처음에 데이터 모델에 적합하지 않은 아키텍처를 선택했다고 지적함. 관계형 데이터를 비관계형 저장소에 넣는 것은 항상 문제를 일으킬 것이라고 언급함.

  • MongoDB와 Mongoose ORM을 선택한 이유가 기능 개발 속도를 높이는 데 최적화된 선택이었다고 주장하는 문장과, Tony Hoare의 "시기상조된 최적화는 모든 악의 근원이다"라는 인용문을 사용하여 이 선택을 정당화하는 문장 사이의 모순을 지적함.

  • 문서형 데이터베이스가 새로운 프로젝트에는 적합하지 않다고 생각하는 사용자는, MongoDB의 라이선스 비용과 호스팅 비용이 증가하고 기능 개발이 정체될 것으로 예상함.

  • MongoDB로 인한 문제로 인해 Postgres로 전환한 경험이 있는 사용자는 그 결정에 매우 만족한다고 언급함. MongoDB가 SQL 대신 JavaScript를 사용하는 것이 불편했다고 덧붙임.

  • 실제 리라이트 과정에서 발생한 문제들에 대해 논의하는 것이 누락되었다고 지적하는 사용자는, 쿼리가 동등하게 이루어졌는지, 양쪽 데이터베이스에서 읽고 쓸 수 있도록 제품을 어떻게 구성했는지, 마이그레이션 중 버그가 발견되었는지, 쿼리를 1:1로 이전할 수 있었는지에 대한 질문을 함.

  • MongoDB를 사용해본 사용자는 문서형 데이터베이스가 일부 사용 사례에는 적합하지만, Mongoose를 사용해야 한다는 것을 깨달았을 때 관계형 데이터베이스로 전환을 고려해야 한다고 언급함. 대부분의 경우 Mongoose는 기존 프로젝트에 추가해야 하며, 처음부터 필요하다면 관계형 데이터베이스를 사용해야 한다고 조언함.

  • MongoDB를 사용하는 프로젝트를 물려받은 사용자는 BSON 형식이 좋지 않지만, JSON API부터 데이터베이스까지 동일한 스키마를 사용할 수 있다는 점을 좋아한다고 언급함. Go와 Rust에서 데이터 지향 프로그래밍에 적합하다고 덧붙임. MongoDB는 읽기 위주의 작업에만 적합하다고 결론짓고, 쓰기 작업이 많은 경우에는 MongoDB가 큰 도움이 되지 않는다고 언급함.

  • 기술적인 이유보다는 라이선스 문제로 인해 PostgreSQL로 전환한 것이 주된 이유라고 언급하는 사용자는, 조인을 사용한 쿼리 최적화로 인해 성능 향상을 경험했다고 공유함. 데이터가 키-값 저장소에 적합하게 모델링되지 않았기 때문에, 적절한 유형의 저장소로 전환하는 것이 결정적인 이유가 되었다고 언급함.

답변달기