Как Prisma сэкономила 98 % на расходах на распространение с помощью Cloudflare R2

Ниже приводится гостевой пост, написанный Пьером-Антуаном Миллсом, Мигелем Фернандесом и Петрой Донкой из Prisma. Prisma предоставляет серверную библиотеку, которая помогает разработчикам читать и записывать данные в базу данных интуитивно понятным, эффективным и безопасным способом.

Миссия Prisma — пересмотреть подход разработчиков к созданию приложений, управляемых данными. По своей сути Prisma предоставляет библиотеку объектно-реляционного сопоставления (ORM) TypeScript нового поколения с открытым исходным кодом, которая открывает новый уровень опыта разработчиков благодаря интуитивно понятной модели данных, миграции, безопасности типов и автозаполнению.

Prisma ORM пережила значительный рост, привлекая активное сообщество разработчиков. И хотя это было большой проблемой, этот рост привел к взрывному росту наших затрат на инфраструктуру AWS. Изучив широкий спектр альтернатив, мы выбрали хранилище Cloudflare R2 — и в результате очень рады, что наши затраты на распространение движка снизились на 98%, обеспечивая при этом первоклассную производительность.

Это было естественно: Prisma уже является технологическим партнером Cloudflare, предлагая глубокую интеграцию баз данных с Cloudflare Workers. Продукты Cloudflare обеспечивают большую часть базовой инфраструктуры для Prisma Accelerate и Prisma Pulse, расширяя возможности разработки продуктов, ориентированных на пользователя. В этом посте мы подробно расскажем, как мы решили расширить наше постоянное сотрудничество с Cloudflare на Prisma ORM и как мы перешли с AWS S3 + CloudFront на Cloudflare R2 с нулевым временем простоя.

Распространение Prisma ORM и ее движков

Prisma ORM упрощает доступ к данным благодаря типобезопасному клиенту Prisma и обеспечивает эффективное управление базами данных через интерфейс командной строки Prisma, чтобы разработчики могли сосредоточиться на разработке продукта.

И клиент Prisma, и Prisma CLI полагаются на Prisma Engines, которые реализованы на Rust и распространяются в виде скомпилированных двоичных файлов для конкретной платформы. Механизмы Prisma выполняют множество задач: от предоставления информации о схеме для генерации типов или миграции базы данных до преобразования запросов Prisma в SQL и выполнения этих запросов к базе данных. Думайте о движках как о слое Prisma ORM, который взаимодействует с базой данных.

Одним из первых шагов для начала работы с Prisma для разработчика является установка клиента Prisma и интерфейса командной строки Prisma из npm. После установки этим пакетам для работы необходимы Prisma Engines. Эти движки имеют сложные правила для целевой платформы и изначально предполагалось, что они будут распространяться отдельно от пакета npm, чтобы их можно было использовать за пределами экосистемы Node.js. В результате они загружаются по требованию Prisma CLI, загружая только то, что строго необходимо для данного проекта.

По состоянию на середину 2023 года на долю двигателей приходится 100 миллионов загрузок в месяц и 250 терабайт исходящей передачи данных, с постоянным увеличением из месяца в месяц по мере роста нашей пользовательской базы. Это подчеркивает важность высокодоступной, глобальной и масштабируемой инфраструктуры, которая обеспечивает загрузку механизма с низкой задержкой для пользователей Prisma по всему миру.

Наше оригинальное решение: AWS S3 и CloudFront

На ранней стадии разработки Prisma ORM наша команда инженеров искала инструменты для создания CDN для распространения движка. Имея обширный опыт работы с AWS, мы выбрали очевидное: хранилище BLOB-объектов S3 для файлов ядра и CloudFront для кэширования содержимого ближе к пользователю.

По большей части мы были довольны AWS, и он мог масштабироваться в соответствии с нашими требованиями. Однако по мере того, как наша база пользователей продолжала расти, росли и затраты. При нашем масштабе трафика передача данных стала значительной статьей затрат, которая, как мы знали, будет только расти.

Постоянно растущая стоимость этих услуг побудила нас изучить альтернативные варианты, которые могли бы лучше удовлетворить наши потребности, сохраняя при этом, по крайней мере, тот же уровень производительности и надежности. Prisma стремится предоставлять нашим пользователям лучшие продукты и решения, и важной частью этого обязательства является целенаправленное распределение наших ресурсов, включая разумные расходы, чтобы мы могли наилучшим образом обслуживать нашу растущую базу пользователей.

Изучаем варианты распространения

Мы тщательно изучали различные технологии и услуги, которые обеспечивали надежную и быструю дистрибуцию двигателей, оставаясь при этом экономически эффективными.

Бесплатные решения: GitHub и npm.

Поскольку Prisma ORM — это решение с открытым исходным кодом, мы изучили различные способы бесплатного распространения модулей через существующие каналы распространения. В этой области у нас были как GitHub Releases, так и npm в качестве кандидатов на размещение и распространение файлов нашего движка. Мы отказались от выпусков GitHub на раннем этапе, поскольку качество обслуживания не было гарантировано, что было требованием для нас по отношению к нашим пользователям, поэтому мы можем быть уверены, что предоставим хороший опыт разработки при любых обстоятельствах.

Мы также проверили npm и подтвердили, что размещение файлов движка будет соответствовать их Условиям обслуживания. Это сделало npm жизнеспособным вариантом, но также означало, что нам придется изменить логику загрузки и выгрузки нашего движка, чтобы приспособить его к другой системе. Кроме того, это означало, что нам придется обновить многие предыдущие версии Prisma CLI, что потребует от наших пользователей обновления, чтобы воспользоваться преимуществами нового решения.

Платные решения: CDN и Cloudflare

Затем мы рассматривали возможность замены только CloudFront, на долю которого приходилось 97% наших затрат на распространение, сохранив при этом S3 в качестве источника. Когда мы оценили различные CDN, мы обнаружили, что альтернативы могут привести к снижению затрат примерно на 70%.

Мы также изучили предложения Cloudflare и были впечатлены Облачная вспышка R2, альтернатива AWS S3 + CloudFront. Он предлагает надежное хранилище BLOB-объектов, совместимое с S3, и использует сеть Cloudflare для глобального распространения с низкой задержкой. Кроме того, у него нет исходящих затрат, а цена рассчитывается исключительно на основе общего объема хранимых данных и операций с этими данными. Учитывая нашу зависимость от Cloudflare портфель продуктов для нашего Платформа данныхи обширный опыт работы с их платформой Workers, мы уже высоко доверяли качеству продуктов Cloudflare.

Чтобы окончательно принять решение, мы внедрили тест, чтобы подтвердить наши предположения о качестве обслуживания Cloudflare. Мы развернули скрипт в 50 городах по всему миру, что соответствует нашему входящему трафику, для измерения задержек загрузки файлов нашего движка (~ 15 МБ). Тест проводился несколько раз, при этом задержки для различных состояний кэша записывались и сравнивались с нашим предыдущим решением на базе AWS. Результаты подтвердили, что надежность и производительность Cloudflare R2 были как минимум на уровне AWS S3 + CloudFront. А поскольку R2 совместим с S3, нам не нужно будет вносить существенные изменения в наше программное обеспечение, чтобы перейти на Cloudflare. Это были отличные результаты, и нам не терпелось переключиться!

Наше решение: переход на Cloudflare R2

Чтобы перенести распространение файлов нашего движка на Cloudflare, нам нужно было убедиться, что мы можем осуществить переход без каких-либо сбоев или последствий для наших пользователей.

Хотя URL-адреса R2 соответствуют формату S3, Prisma CLI использует фиксированный домен для указания на распространение файлов механизма. Этот фиксированный домен позволил нам перейти, не внося никаких изменений в код старых версий Prisma, и просто указать существующие URL-адреса на R2. Однако для перехода нам нужно было изменить конфигурацию DNS, чтобы она указывала на Cloudflare. Хотя это кажется тривиальным, потенциальные проблемы, такие как неожиданные проблемы с распространением DNS или проблемы с проверкой сертификата при подключении через TLS, потребовали от нас планирования заранее, чтобы действовать уверенно и безопасно.

Мы модифицировали конвейер выпуска Prisma ORM для загрузки ресурсов как в S3, так и в R2, а также использовали R2 Super Slurper для переноса прошлых версий движка в R2. Это гарантировало, что все выпуски Prisma, прошлые и будущие, существовали в обоих местах. Мы также установили проверки мониторинга Grafana для извлечения файлов движка из R2, используя конфигурацию DNS и TLS, аналогичную желаемой производственной настройке, но через экспериментальный домен. Эти проверки мониторинга позже были повторно использованы во время окончательного отключения трафика, чтобы гарантировать отсутствие сбоев в обслуживании.

Поскольку обеспечение отсутствия влияния или сбоев в работе наших пользователей имело первостепенное значение, мы приступили к постепенному развертыванию изменений DNS с использованием балансировки нагрузки DNS — метода, при котором группа записей псевдонимов, назначенных домену, имеет разный вес. Это означало, что преобразователь DNS направлял больше трафика на записи с более высоким весом. Мы начали с конфигурации балансировки нагрузки, имитирующей нашу старую настройку, с одной записи (файл контроль), указывающий на AWS CloudFront, а другой ( кандидат), указывающий на R2. Первоначально весь вес был на контроль, эффективно сохраняя старую маршрутизацию к CloudFront. Мы также установили минимально возможный TTL, чтобы изменения веса записей вступили в силу как можно скорее, создавая больший контроль над распространением DNS. Кроме того, мы реализовали проверку работоспособности, которая перенаправляет весь трафик на контроль если задержки загрузки были значительно выше или были обнаружены ошибки, обеспечивая стабильный откат.

На данный момент все было на месте и мы могли приступить к развертыванию.

Внедрение началось с постепенного увеличения веса DNS R2, и наши панели мониторинга показали, что загрузки Cloudflare были пропорциональны весу, присвоенному R2. Поскольку в Cloudflare направлялось всего лишь 5% трафика, коэффициент попадания в кеш, как и ожидалось, приблизился к 100%. Задержки соответствовали контроль, поэтому все проверки работоспособности прошли успешно, и наш резервный вариант так и не активировался. В течение часа мы постепенно увеличивали вес DNS R2, чтобы без каких-либо проблем управлять 25%, 50% и, наконец, 100% трафика. Переход не мог пройти более гладко.

После мониторинга в течение дополнительных двух дней мы упростили топологию DNS и перенаправили трафик исключительно на Cloudflare. Мы были очень довольны изменениями и, как и ожидалось, начали замечать значительное снижение затрат на инфраструктуру, не говоря уже о нулевом времени простоя и отсутствии сообщений о проблемах со стороны пользователей.

Успех

Переход на Cloudflare R2 прошел легко благодаря их великолепному продукту и инструментам, интуитивно понятной платформе и команде поддержки. У нас остались отличные впечатления от их обслуживания: стабильно высокое время безотказной работы, производительность и задержка. Cloudflare еще раз оказалась ценным партнером, который помог нам масштабироваться.

Мы очень рады тому, что наши затраты на дистрибуцию двигателей снизились на 98%. Экономически эффективное решение Cloudflare не только обеспечило первоклассную производительность, но и привело к значительной экономии нашей деятельности. Полный успех!

Чтобы узнать больше о том, как Prisma создает решения Data DX с помощью Cloudflare, ознакомьтесь со статьей Переосмысление опыта разработчиков: Prisma и Cloudflare прокладывают путь к Data DX.

А если вы хотите увидеть Prisma в действии, начните с краткого руководства.