- 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개월이 걸렸음
- 이러한 큰 프로젝트를 시도하기 전에 사용 사례와 구현을 심도 있게 생각할 것을 권장