[번역] 프리즈마 쓰지 마세요

데이터베이스, 운영체제, 커널과 시스템·2023년 10월 25일

https://www.youtube.com/watch?v=jqhHXe746Ns&t=345s&ab_channel=ThePrimeTime

Node.js 프로젝트의 ORM을 뭘 쓸까 고민하던 중에, Primeagen이 리뷰한 재밌는 아티클이 있어서 번역해봤습니다.

원본 링크: https://codedamn.com/news/product/dont-use-prisma

프리즈마 쓰지 마세요

원제: We migrated to SQL. Our biggest learning? Don’t use Prisma

지난 주에 우리는 기본 데이터베이스를 MongoDB에서 Postgres로 전환하는 마이그레이션을 완료했습니다. 이 과정에서 많은 도전 과제들이 있었으며, 그 중 가장 큰 도전은 코드베이스를 두 번이나 재작성한 것입니다.

프리즈마를 프로덕션에서 사용하려고 고민 중인 개발자들을 위해 이 글을 씁니다. 쓰지 마세요.

처음엔 백엔드를 Prisma로 작성

Prisma의 마케팅과 아름다운 홈페이지에 넘어가 맹목적으로 신뢰하고 말았습니다.

Prisma의 장점 중 하나는 관계, 기본값, 데이터 타입을 모두 포함하는 스키마를 생성하는 능력입니다. 문법도 매우 명확합니다.

그러나 그게 전부입니다. Mongoose ORM에서 Prisma로 전체 코드베이스를 전환했는데, 처음에는 좋아 보였습니다.

배포 문제

codedamn에서는 AWS 람다를 사용하여 GraphQL 기반 백엔드를 호스팅합니다. Prisma와 관련하여 처음 발견한 문제는, Prisma가 여러 개의 10-20MB 크기의 "엔진"을 배포한다는 것이었습니다.

프리즈마가 자기만의 독자적인 "db" 엔진 레이어를 필요로 한다는 사실이 매우 충격적이었습니다.

https://www.prisma.io/docs/concepts/components/prisma-engines

우리의 AWS 람다 배포는 50MB 크기 제한을 초과하여 실패했습니다. 백엔드 타입스크립트를 구축하기 위해 ESBuild를 사용했습니다. 우리는 불필요한 엔진과 Prisma 파일 및 node_modules를 제거하고 배포 크기를 50MB 미만으로 줄이기 위해 빌드 파이프라인에 여러 패치를 작성해야 했습니다.

그러나 결국, Prisma가 꼭 필요로 하는 12-13MB 크기의 쿼리 엔진을 배송해야 했습니다.

낮은 성능

우리의 두 번째 실수는 Prisma에서 "흉내 낸 외래 키 관계" 모드를 켰다는 것입니다. 처음에는 우리의 데이터베이스로 PlanetScale을 사용하려고 했으나, 그것도 우리에게는 최선의 선택이 아니었습니다. (이 내용만으로 다른 블로그 포스트를 하나 더 쓸 수 있습니다.)

Prisma 내에서 외래 키 관계를 에뮬레이션하는 것은 성능적으로 악몽입니다. Prisma로 작성된 어댑터를 통해 스테이징 MongoDB에서 스테이징 PlanetScale로 데이터의 테스트 마이그레이션을 시도했을 때 관찰한 몇 가지 사항들은 다음과 같습니다:

Prisma를 통한 모든 새로운 삽입은 데이터베이스 수준의 트랜잭션을 엽니다(?). 매우 이상한 디자인입니다.
우리는 자주 Vitess 위의 PlanetScale에서 우리의 트랜잭션 풀을 고갈시켰고, 10초-20초 후에 이러한 오류를 겪게 됩니다. 우리가 SQL 데이터베이스에 뭘 엄청나게 많이 덤핑한 것도 아니고, 대충 50-100개의 병렬 삽입 호출을 DB에서 할 때 위의 오류를 겪었습니다. 20M+ 넘는 데이터를 가지고 있었는데, 다운타임 때문에 마이그레이션을 마냥 며칠동안 기다릴 수는 없었습니다.
Prisma에는 SQL 수준의 조인 개념이 없습니다. SQL 조인 또는 하위 쿼리를 사용해야 한다고 생각했던 일부 쿼리에서 우리는 Prisma가 두 테이블에서 데이터를 가져와 그 결과를 "Rust" 엔진에서 결합한다는 것을 발견했습니다. 이것은 절대적으로 쓰래기같은 (absolute trash) 퍼포먼스로 이어졌습니다.
우리가 이것을 깨달았을 때, 우리는 어떻게 Prisma가 실제로 외래 키 제약 조건을 "에뮬레이션"하는지에 대해 매우 의심스러웠습니다. 프리즈마가 실제로 외래 키 제약 조건을 "에뮬레이션"하는 방식에 대해 매우 의심스러웠습니다. 모든 CUD 작업에서 모든 관련 테이블에 대한 연속적인 선택 작업을 수행하나요? 유일한 방법처럼 보입니다. 그리고 우리가 볼 때, 모든 삽입이 제한된 풀 크기를 가진 트랜잭션을 사용하므로, 프로덕션에서 성능 패널티가 불가피하다는 걸 확신했습니다.
모든 삽입 시, 프리즈마는 우리가 원하지 않아도 삽입한 레코드를 반환하는 트랜잭션을 엽니다.

고유 엔진 내부에서 일어나는 SQL 결과 "patching"은 협상 결렬의 요소였습니다. 뭐 나름대로 스스로 최적화를 할 수도 있지만, 비록 15MB짜리 러스트 엔진을 사용한다 하더라도 데이터베이스를 성능적으로 능가할 수는 없을 겁니다.

더 깊게 조사해 보니, 당신의 코드가 'actual DB call'을 절대 하지 않는다는 것을 발견했습니다. 프리즈마 코드는 GraphQL 네트워크 요청(?)을 프리즈마 Rust 쿼리 엔진에 수행하며, 그런 다음 여러분의 요청을 실제 DB 호출로 번역합니다.

PlanetScale 탈주

PlanetScale 포기하기
우리의 PlanetScale 데이터베이스는 여러 레코드의 삽입/읽기에 대한 스트레스 테스트를 통과할 수 있었습니다. 그러나 Vitess 내부의 제한된 트랜잭션 풀 때문에 Prisma를 사용할 때 실패했는데, 이 풀이 매우 빠르게 고갈되었고 그 후에는 몇 분 동안 PlanetScale DB로의 모든 추가 호출이 실패하게 되었습니다.

그러나 PlanetScale을 포기하는 것은 두 가지 이유 때문이었습니다:

외래 키 지원 X: 이것은 우리가 처음에 간과했던 것이지만, MongoDB의 "관계형" 데이터에서 오는 마이그레이션 작업을 더 많이 진행하면서, 우리는 그것이 데이터가 손상되지 않게 하는 큰 안전망이라는 것을 깨달았습니다. 컬렉션 간의 관계를 존중하지 않았기 때문에 MongoDB에서 많은 데이터 손상이 발생했습니다.
이상한 가격 정책: PlanetScale은 월별 행 읽기와 행 쓰기로 가격을 책정합니다. 이상한 것은 제어되지 않는 행 읽기입니다. SQL 쿼리 플래너가 쿼리 계획을 결정하며, 이로 인해 내부적으로 얼마나 많은 행을 읽는지가 결정됩니다. 행 읽기는 행 반환이 아님을 기억하세요. 0행을 반환하는 잘못된 쿼리를 작성할 수 있지만 1M 행의 전체 테이블 스캔을 할 수 있으며 PlanetScale은 그것에 대한 요금을 청구합니다.
VPC 피어링 X: MongoDB Atlas는 전용 클러스터에서 VPC 피어링을 지원했지만 PlanetScale은 기업 플랜에서만 지원했습니다.