راز مقیاس پذیری PostgreSQL در OpenAI: چگونه چت جی پی تی ۸۰۰ میلیون کاربر را مدیریت میکند؟

تیم تحریریه استاد آی تی گزارش می دهد: در دنیای فناوری که سرعت رشد کاربران و حجم داده ها به صورت تصاعدی افزایش می یابد، مقیاس پذیری پایگاه های داده یکی از بزرگترین چالش های پیش روی شرکت های بزرگ است. OpenAI، خالق پلتفرم های پیشرویی مانند ChatGPT و Sora، اخیرا با انتشار یک مقاله فنی، پرده از معماری داده ای خود برداشته است که نشان می دهد چگونه توانسته است پایگاه داده PostgreSQL را برای مدیریت ترافیک عظیم ۸۰۰ میلیون کاربر فعال مقیاس بندی کند. این گزارش تحلیلی به عمق این دستاوردهای مهندسی می پردازد و راهکارهای کلیدی OpenAI را برای دستیابی به میلیون ها درخواست در ثانیه (QPS) بررسی می کند.

چالش های فنی در مسیر مقیاس پذیری PostgreSQL

PostgreSQL به عنوان یک سیستم مدیریت پایگاه داده رابطه ای (RDBMS) قدرتمند، سال هاست که یکی از ارکان اصلی زیرساخت های داده OpenAI بوده است. با این حال، با افزایش ۱۰ برابری بار ترافیکی در سال گذشته، محدودیت های ذاتی این سیستم در مواجهه با بارهای سنگین عملیات نوشتن (Write-heavy) آشکار شد. چالش اصلی در این زمینه به پیاده سازی کنترل همزمانی چند نسخه ای (MVCC) در PostgreSQL بازمی گردد.

MVCC و معضلات عملیات نوشتن

MVCC یک مکانیزم کلیدی در PostgreSQL است که امکان می دهد عملیات خواندن و نوشتن به صورت همزمان و بدون قفل شدن داده ها انجام شوند. اما در حجم بالای عملیات نوشتن، این مکانیزم باعث ایجاد پدیده ای به نام تقویت نوشتن (Write Amplification) می شود. هنگامی که یک سطر داده به روزرسانی می شود، به جای تغییر در محل، یک نسخه جدید از کل سطر ایجاد می شود.

این امر منجر به انباشت نسخه های قدیمی سطرها که به آن ها تاپل های مرده (Dead Tuples) گفته می شود، می گردد. انباشت این تاپل ها نه تنها فضای دیسک را افزایش می دهد (Table and Index Bloat)، بلکه باعث تقویت خواندن (Read Amplification) نیز می شود، زیرا کوئری های خواندن باید از میان نسخه های متعدد عبور کنند تا به آخرین نسخه برسند. این مسائل، تنظیمات خودکار Autovacuum را نیز پیچیده تر می سازد.

راهکارهای مهندسی OpenAI برای مدیریت میلیون ها QPS

برای غلبه بر این محدودیت ها و حفظ مقیاس پذیری PostgreSQL در OpenAI، تیم مهندسی این شرکت مجموعه ای از بهینه سازی های گسترده را در لایه های مختلف زیرساخت اعمال کرده است. این راهکارها به آن ها اجازه داده است تا با یک معماری تک سرور اصلی (Single Primary) و نزدیک به ۵۰ کپی خواندنی (Read Replica) در سراسر جهان، ترافیک را مدیریت کنند.

۱. انتقال بارهای سنگین نوشتن به سیستم های شارد شده

اولین و مهم ترین گام، کاهش فشار بر سرور اصلی PostgreSQL بود. OpenAI تصمیم گرفت بارهای کاری سنگین نوشتن که قابلیت شاردینگ (Sharding) یا پارتیشن بندی افقی را داشتند، به سیستم های توزیع شده و شارد شده مانند Azure Cosmos DB منتقل کند. این استراتژی، PostgreSQL را به یک پایگاه داده تخصصی برای بارهای کاری خواندنی (Read-heavy) و داده های حیاتی که شارد کردن آن ها دشوار است، تبدیل کرد. همچنین، هیچ جدول جدیدی اجازه اضافه شدن به دیتابیس PostgreSQL فعلی را ندارد و بارهای کاری جدید به صورت پیش فرض به سیستم های شارد شده هدایت می شوند.

۲. بهینه سازی کوئری ها و جلوگیری از “همسایه پر سر و صدا”

یکی از دلایل اصلی از کار افتادن سرویس ها (SEV) در گذشته، کوئری های پرهزینه و پیچیده بود. OpenAI بر روی بهینه سازی کوئری ها تمرکز کرد و از الگوهای ضد OLTP (Online Transaction Processing) مانند Joinهای پیچیده چند جدولی که اغلب توسط فریم ورک های ORM (Object-Relational Mapping) تولید می شوند، اجتناب کرد.

کارشناسان استاد آی تی معتقدند که رویکرد OpenAI در جداسازی بار کاری (Workload Isolation) یک درس کلیدی برای هر معماری داده ای در مقیاس بزرگ است. با تقسیم درخواست ها به دو سطح اولویت بالا (High-Priority) و اولویت پایین (Low-Priority) و هدایت هر کدام به نمونه های (Instances) مجزا، آن ها توانستند از پدیده “همسایه پر سر و صدا” (Noisy Neighbor) جلوگیری کنند. این امر تضمین می کند که افزایش ناگهانی بار یک ویژگی کم اهمیت، عملکرد سرویس های حیاتی مانند API و ChatGPT را مختل نکند.

۳. مدیریت اتصالات با PgBouncer و محافظت از کش

محدودیت تعداد اتصالات (۵۰۰۰ اتصال در Azure PostgreSQL) یک چالش جدی بود. OpenAI با استقرار PgBouncer به عنوان یک لایه پروکسی، از قابلیت اتصال پولینگ (Connection Pooling) استفاده کرد. این کار زمان راه اندازی اتصال را از ۵۰ میلی ثانیه (ms) به تنها ۵ میلی ثانیه کاهش داد و از بروز طوفان های اتصال (Connection Storms) جلوگیری کرد.

علاوه بر این، برای محافظت از پایگاه داده در برابر طوفان های عدم موفقیت کش (Cache-Miss Storms)، یک مکانیزم قفل گذاری کش (Cache Locking) پیاده سازی شد. این مکانیزم تضمین می کند که اگر چندین درخواست به طور همزمان یک کلید کش را از دست بدهند، تنها یک درخواست اجازه دارد داده ها را از PostgreSQL بازیابی کرده و کش را به روزرسانی کند، در حالی که بقیه منتظر می مانند. این راهکار به طور چشمگیری خواندن های اضافی از دیتابیس را کاهش می دهد.

۴. مدیریت ایمن تغییرات شماتیک

تغییرات در ساختار پایگاه داده (Schema Management) در مقیاس OpenAI بسیار حساس است، زیرا حتی یک تغییر کوچک می تواند باعث بازنویسی کامل جدول (Full Table Rewrite) شود. به همین دلیل، تنها تغییرات شماتیک سبک (Lightweight) مانند افزودن یا حذف ستون های خاص مجاز هستند و یک محدودیت زمانی سختگیرانه ۵ ثانیه ای برای اجرای آن ها اعمال می شود. این رویکرد، پایداری سیستم را در حین توسعه و استقرار ویژگی های جدید تضمین می کند.

نتایج و چشم انداز آینده

تلاش های مهندسی OpenAI ثابت کرد که PostgreSQL با طراحی و بهینه سازی های صحیح، می تواند از پس بزرگترین بارهای کاری تولیدی برآید. این پایگاه داده اکنون میلیون ها QPS را برای بارهای خواندنی مدیریت می کند و با در دسترس بودن پنج نُه (Five-Nines Availability) و تاخیر سمت کاربر (p99 Client-Side Latency) در محدوده دو رقمی میلی ثانیه، عملکردی در سطح جهانی ارائه می دهد.

این دستاوردها نشان دهنده اهمیت مهندسی داده (Data Engineering) و بهینه سازی های دقیق در معماری های ابری است. OpenAI همچنان به دنبال انتقال بارهای کاری سنگین نوشتن باقی مانده به سیستم های شارد شده و همکاری با Azure برای فعال سازی تکثیر آبشاری (Cascading Replication) است تا بتواند تعداد کپی های خواندنی را با خیال راحت افزایش دهد.

برای کسب اطلاعات بیشتر در مورد راهکارهای فنی مورد استفاده در این پروژه، می توانید به مقاله اصلی OpenAI با عنوان “Scaling PostgreSQL to power 800 million ChatGPT users” مراجعه کنید.