OpenAI поділилася подробицями щодо того, як масштабує роботу бази даних PostgreSQL для обслуговування майже 800 мільйонів користувачів ChatGPT та API-платформи. Попри популярність векторних баз даних, OpenAI зробила ставку на класичну реляційну СУБД із відкритим кодом — PostgreSQL.
В OpenAI повідомили, що вся інфраструктура ChatGPT й API для 800 мільйонів користувачів працює на одному primary-інстансі PostgreSQL. Це не розподілена база даних і не шардований кластер. Усі операції запису обробляє один Azure PostgreSQL Flexible Server, тоді як майже 50 read-реплік, розгорнутих у кількох регіонах, відповідають за читання. Система обробляє мільйони запитів за секунду, забезпечуючи p99-затримку на рівні кількох десятків мілісекунд і доступність на рівні «п’яти дев’яток».
Такий підхід суперечить поширеним уявленням про масштабування й дає корпоративним архітекторам практичне уявлення про те, що реально працює у надвеликих масштабах.
Основний висновок, за словами фахівців OpenAI, полягає не в тому, щоб копіювати її стек. Архітектурні рішення мають визначатися характером навантажень та операційними обмеженнями, а не панікою через масштаб чи модними інфраструктурними трендами.
Конфігурація PostgreSQL в OpenAI демонструє, наскільки далеко можуть зайти перевірені системи за умови цілеспрямованої оптимізації без передчасної перебудови архітектури.
«Протягом багатьох років PostgreSQL була однією з найкритичніших внутрішніх систем зберігання даних, що забезпечує роботу таких продуктів, як ChatGPT й API OpenAI. За останній рік навантаження на PostgreSQL зросло більш ніж у 10 разів і продовжує збільшуватися», — написав інженер OpenAI Bohan Zhang у технічному матеріалі.
Досягти такого масштабу компанії вдалося завдяки точковим оптимізаціям. Зокрема використання пулінгу з’єднань дало можливість скоротити час встановлення з’єднання із 50 мс до 5 мс, а блокування кешу — уникнути проблеми thundering herd, коли одночасні промахи кешу призводять до перевантаження бази даних.
PostgreSQL використовується для обробки операційних даних ChatGPT й API-платформи OpenAI. Навантаження має переважно read-орієнтований характер, що робить PostgreSQL придатним вибором. Водночас механізм багатоверсійного контролю паралельності (MVCC) створює складнощі за інтенсивних операцій запису.
Під час оновлення даних PostgreSQL копіює весь рядок, створюючи нову версію, що призводить до write amplification і змушує запити переглядати кілька версій, щоб знайти актуальні дані. Замість боротьби із цим обмеженням OpenAI побудувала свою стратегію з урахуванням вказаних компромісів. На такому масштабі вони визначають, які навантаження залишаються в PostgreSQL, а які потрібно переносити в інші системи.
За класичною логікою масштабування компанії зазвичай обирають один із двох шляхів: шардінг PostgreSQL між кількома primary-інстансами або міграцію на розподілені SQL-бази даних на кшталт CockroachDB чи YugabyteDB. Більшість організацій зробили б це задовго до досягнення позначки у 800 мільйонів користувачів.
Обидва підходи знімають обмеження одного writer’а, але суттєво ускладнюють систему: застосунки мають маршрутизувати запити між шардами, ускладнюється управління розподіленими транзакціями, а операційні витрати різко зростають.
OpenAI обрала іншу, гібридну стратегію. У PostgreSQL більше не створюють нових таблиць. Усі нові навантаження за замовчуванням спрямовуються в шардовані системи, зокрема Azure Cosmos DB. Наявні write-інтенсивні навантаження, які можна горизонтально розділити, поступово мігрують. Усе інше залишається в PostgreSQL з агресивною оптимізацією.
Такий підхід дає підприємствам практичну альтернативу повній перебудові архітектури. Замість багаторічного переписування сотень endpoint’ів команди можуть ідентифікувати конкретні вузькі місця й переносити лише проблемні навантаження у спеціалізовані системи.
Досвід OpenAI демонструє низку практик, які можуть бути корисними для компаній будь-якого масштабу. Серед них — багаторівневий захист операційної стабільності, що поєднує блокування кешу, пулінг з’єднань і rate limiting на рівні застосунку, проксі та SQL-запитів. Ізоляція навантажень дає можливість розділяти низько- та високопріоритетний трафік між різними інстансами, щоб неоптимізована нова функція не впливала на основні сервіси.
Окрему увагу OpenAI приділяє перевірці SQL-запитів, згенерованих ORM-фреймворками, такими як Django, SQLAlchemy або Hibernate. Компанія зафіксувала випадок, коли один ORM-запит із 12 JOIN’ами спричинив кілька інцидентів високої критичності під час пікових навантажень. Зручність автоматичної генерації SQL може приховувати ризики масштабування, які проявляються лише в продакшені.
Ще один принцип — жорстка операційна дисципліна. OpenAI дозволяє лише легкі зміни схем, будь-які операції, які призводять до повного переписування таблиці, заборонені. Тайм-аут для змін схеми становить 5 секунд, довгі запити автоматично перериваються, а під час backfill-операцій застосовуються настільки суворі обмеження, що процес може тривати понад тиждень.
В OpenAI дійшли висновку, що read-орієнтовані навантаження з епізодичними сплесками запису можуть працювати на single-primary PostgreSQL значно довше, ніж вважається. Рішення про шардінг має базуватися на характері навантажень, а не на кількості користувачів.
Цей підхід особливо релевантний для AI-застосунків, де переважає читання і є непередбачувані піки трафіку. Саме такі умови дають можливість single-primary PostgreSQL масштабуватися ефективно.
Головний урок простий: потрібно ідентифікувати реальні вузькі місця, максимально оптимізувати перевірену інфраструктуру і мігрувати лише там, де це необхідно. Повна перебудова архітектури не завжди є відповіддю на виклики масштабування.
Читайте також на ProIT, що OpenAI запускає функцію прогнозування віку в ChatGPT.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
