Menskalakan PostgreSQL untuk menyokong 800 juta pengguna ChatGPT

Selama bertahun-tahun, PostgreSQL telah menjadi salah satu sistem data paling kritikal yang beroperasi di sebalik tabir, menguasakan produk teras seperti ChatGPT dan API OpenAI. Memandangkan pangkalan pengguna kami berkembang dengan pesat, permintaan terhadap pangkalan data kami juga telah meningkat secara eksponen. Sepanjang tahun lalu, beban PostgreSQL kami telah meningkat lebih daripada 10 kali ganda, dan ia terus meningkat dengan pesat.

Usaha kami untuk memajukan infrastruktur pengeluaran kami bagi mengekalkan pertumbuhan ini mendedahkan satu wawasan baharu: PostgreSQL boleh diskalakan untuk menyokong beban kerja bacaan yang jauh lebih besar daripada apa yang di sangka ramai. Sistem ini (pada mulanya dicipta oleh sekumpulan saintis di University of California, Berkeley) telah membolehkan kami menyokong trafik global yang sangat besar dengan satu instans Azure PostgreSQL pelayan fleksibel⁠(dibuka dalam tetingkap baru) utama dan hampir 50 replika baca yang tersebar di pelbagai rantau di seluruh dunia. Ini adalah kisah tentang bagaimana kami telah menskalakan PostgreSQL di OpenAI untuk menyokong berjuta-juta pertanyaan sesaat bagi 800 juta pengguna melalui pengoptimuman yang ketat dan kejuruteraan yang mantap; kami juga akan membincangkan pengajaran utama yang kami pelajari sepanjang perjalanan.

Selepas pelancaran ChatGPT, trafik meningkat pada kadar yang belum pernah berlaku sebelum ini. Untuk menyokongnya, kami dengan pantas melaksanakan pengoptimuman yang meluas pada kedua-dua lapisan aplikasi dan pangkalan data PostgreSQL, meningkatkan skala dengan menambah saiz instans, dan memperluas skala dengan menambah lebih banyak replika baca. Seni bina ini telah berkhidmat dengan baik kepada kami untuk jangka masa yang lama. Dengan penambahbaikan yang berterusan, ia terus menyediakan landasan yang luas untuk pertumbuhan masa depan.

Mungkin mengejutkan bahawa seni bina primer tunggal dapat memenuhi tuntutan skala OpenAI; namun, melaksanakannya dalam amalan tidaklah mudah. Kami telah melihat beberapa SEV yang disebabkan oleh beban berlebihan Postgres, dan ia sering mengikuti corak yang sama: isu huluan menyebabkan lonjakan mendadak dalam beban pangkalan data, seperti kehilangan cache yang meluas akibat kegagalan lapisan cache, lonjakan gabungan berbilang hala yang mahal sehingga menepukan CPU, atau ribut penulisan daripada pelancaran ciri baharu. Apabila penggunaan sumber meningkat, kependaman pertanyaan meningkat dan permintaan mula tamat masa. Percubaan semula kemudian terus meningkatkan beban, mencetuskan kitaran ganas yang berpotensi menjejaskan keseluruhan perkhidmatan ChatGPT dan API.

Walaupun PostgreSQL berskala dengan baik untuk beban kerja kami yang banyak bacaan, kami masih menghadapi cabaran semasa tempoh trafik penulisan yang tinggi. Ini sebahagian besarnya disebabkan oleh pelaksanaan kawalan serentak pelbagai versi (MVCC) PostgreSQL, yang menjadikannya kurang cekap untuk beban kerja yang berat penulisan. Sebagai contoh, apabila pertanyaan mengemas kini tuple atau bahkan satu medan, seluruh baris disalin untuk mencipta versi baharu. Di bawah beban penulisan yang berat, ini mengakibatkan penguatan penulisan yang ketara. Ia juga meningkatkan penguatan bacaan, kerana pertanyaan perlu mengimbas melalui pelbagai versi tupel (tupel mati) untuk mendapatkan yang terkini. MVCC memperkenalkan cabaran tambahan seperti pembengkakan jadual dan indeks, peningkatan beban penyelenggaraan indeks, dan penalaan autovacuum yang rumit. (Anda boleh menemui kupasan mendalam tentang isu-isu ini dalam blog yang saya tulis bersama Prof. Andy Pavlo di Carnegie Mellon University yang bertajuk The Part of PostgreSQL We Hate the Most⁠(dibuka dalam tetingkap baru), dipetik⁠(dibuka dalam tetingkap baru) dalam halaman Wikipedia PostgreSQL.)

Untuk mengurangkan batasan ini dan mengurangkan tekanan penulisan, kami telah memindahkan, dan terus memindahkan, boleh dipecahkan (iaitu beban kerja yang boleh dipartisikan secara mendatar), beban kerja berat penulisan kepada sistem berserpihan seperti Azure Cosmos DB, mengoptimumkan logik aplikasi untuk meminimumkan penulisan yang tidak perlu. Kami juga tidak lagi membenarkan penambahan jadual baharu kepada pasang atur PostgreSQL semasa. Beban kerja baharu secara lalai ditetapkan kepada sistem yang terpecah-pecah.

Walaupun infrastruktur kami telah berkembang, PostgreSQL kekal tidak terpecah, dengan satu instans utama yang melayani semua penulisan. Rasional utama adalah bahawa pemecahan beban kerja aplikasi sedia ada akan menjadi sangat kompleks dan memakan masa, memerlukan perubahan kepada ratusan titik akhir aplikasi dan berpotensi mengambil masa berbulan-bulan atau bahkan bertahun-tahun. Memandangkan beban kerja kami terutamanya berintensifkan bacaan, dan kami telah melaksanakan pengoptimuman yang meluas, seni bina semasa masih menyediakan ruang yang mencukupi untuk menyokong pertumbuhan trafik yang berterusan. Walaupun kami tidak menolak kemungkinan untuk melakukan sharding PostgreSQL pada masa hadapan, ia bukanlah keutamaan dalam masa terdekat memandangkan landasan yang mencukupi yang kami miliki untuk pertumbuhan semasa dan masa hadapan.

Dalam bahagian berikut, kami akan menyelami cabaran yang kami hadapi dan pengoptimuman meluas yang kami laksanakan untuk menanganinya serta mencegah gangguan pada masa hadapan, mendorong PostgreSQL ke hadnya dan menskalakannya kepada berjuta-juta pertanyaan sesaat (QPS).

Cabaran: Dengan hanya seorang penulis, persediaan primer tunggal tidak dapat menskalakan penulisan. Lonjakan penulisan yang berat boleh membebankan sistem utama dengan cepat dan menjejaskan perkhidmatan seperti ChatGPT dan API kami.

Penyelesaian: Kami meminimumkan beban pada pelayan utama sebanyak mungkin—baik bacaan mahupun penulisan—untuk memastikan ia mempunyai kapasiti yang mencukupi bagi menangani lonjakan penulisan. Trafik bacaan dialihkan kepada replika di mana sahaja yang boleh. Namun, beberapa pertanyaan baca mesti kekal pada pangkalan utama kerana ia adalah sebahagian daripada transaksi penulisan. Untuk perkara tersebut, kami menumpukan perhatian untuk memastikan ia cekap dan mengelakkan pertanyaan yang perlahan. Untuk trafik penulisan, kami telah memindahkan beban kerja yang boleh dipecahkan dan berat dari segi penulisan ke sistem berpecah seperti Azure CosmosDB. Beban kerja yang lebih sukar untuk dipecahkan tetapi masih menjana jumlah penulisan yang tinggi mengambil masa lebih lama untuk dipindahkan, dan proses itu masih berterusan. Kami juga telah mengoptimumkan aplikasi kami secara agresif untuk mengurangkan beban penulisan; sebagai contoh, kami telah membetulkan pepijat aplikasi yang menyebabkan penulisan berlebihan dan memperkenalkan penulisan malas, jika sesuai, untuk melancarkan lonjakan trafik. Selain itu, apabila mengisi semula medan jadual, kami menguatkuasakan had kadar yang ketat untuk mencegah tekanan penulisan yang berlebihan.

Cabaran: Kami mengenal pasti beberapa pertanyaan yang memerlukan kos tinggi dalam PostgreSQL. Pada masa lalu, lonjakan volum secara mendadak dalam pertanyaan ini akan menggunakan sejumlah besar CPU, memperlahankan kedua-dua ChatGPT dan permintaan API.

Penyelesaian: Beberapa pertanyaan yang mahal, seperti yang menggabungkan banyak jadual bersama-sama, boleh merendahkan prestasi dengan ketara atau malah melumpuhkan keseluruhan perkhidmatan. Kami perlu sentiasa mengoptimumkan pertanyaan PostgreSQL untuk memastikan ia cekap dan mengelakkan corak anti Online Transaction Processing (OLTP) yang biasa. Sebagai contoh, kami pernah mengenal pasti pertanyaan yang sangat mahal yang menggabungkan 12 jadual, di mana lonjakan dalam pertanyaan ini bertanggungjawab terhadap SEV berkeparahan tinggi pada masa lalu. Kita harus mengelakkan gabungan jadual berbilang yang kompleks bila-bila boleh. Jika penggabungan diperlukan, kami belajar untuk mempertimbangkan memecahkan pertanyaan dan sebaliknya memindahkan logik penggabungan yang kompleks ke lapisan aplikasi. Banyak pertanyaan bermasalah ini dijana oleh rangka kerja Object-Relational Mapping (ORM), jadi penting untuk menyemak dengan teliti SQL yang dihasilkannya dan memastikan ia berfungsi seperti yang diharapkan. Ia juga biasa untuk menemui pertanyaan melahu yang berpanjangan dalam PostgreSQL. Mengkonfigurasi tamat masa seperti idle_in_transaction_session_timeout adalah penting untuk mengelakkan ia daripada menyekat autovacuum.

Cabaran: Jika replika baca gagal, trafik masih boleh dihalakan ke replika lain. Namun, bergantung kepada seorang penulis sahaja bermaksud mempunyai satu titik kegagalan—jika ia terhenti, keseluruhan perkhidmatan akan terjejas.

Penyelesaian: Kebanyakan permintaan yang paling kritikal hanya melibatkan pertanyaan bacaan. Untuk mengurangkan titik kegagalan tunggal pada sistem utama, kami mengalihkan bacaan tersebut daripada penulis kepada replika, memastikan permintaan tersebut boleh terus dilayan walaupun sistem utama terhenti. Walaupun operasi tulis masih akan gagal, kesannya berkurangan; ia bukan lagi SEV0 kerana bacaan kekal tersedia.

Untuk mengurangkan kegagalan utama, kami menjalankan sistem utama dalam mod Ketersediaan Tinggi (HA) dengan sandaran panas, iaitu replika yang disegerakkan secara berterusan dan sentiasa bersedia untuk mengambil alih penyampaian trafik. Jika sistem utama mengalami gangguan atau perlu diambil luar talian untuk penyelenggaraan, kami boleh dengan cepat mempromosikan sistem siap sedia untuk meminimumkan masa henti. Pasukan Azure PostgreSQL telah melakukan kerja yang signifikan untuk memastikan failover ini kekal selamat dan boleh dipercayai walaupun di bawah beban yang sangat tinggi. Untuk menangani kegagalan replika baca, kami menggunakan berbilang replika di setiap rantau dengan ruang lebihan kapasiti yang mencukupi, memastikan bahawa kegagalan satu replika tidak menyebabkan gangguan di peringkat rantau.

Cabaran: Kami sering menghadapi situasi di mana permintaan tertentu menggunakan jumlah sumber yang tidak seimbang pada instans PostgreSQL. Ini boleh menyebabkan prestasi menurun untuk beban kerja lain yang berjalan pada contoh yang sama. Sebagai contoh, pelancaran ciri baharu boleh memperkenalkan pertanyaan tidak cekap yang banyak menggunakan CPU PostgreSQL, memperlahankan permintaan untuk ciri kritikal lain.

Penyelesaian: Kami mengendalikan hampir 50 replika bacaan di pelbagai rantau geografi untuk meminimumkan kependaman. Namun, dengan seni bina semasa, pelayan utama mesti menstrim WAL ke setiap replika. Walaupun pada masa ini ia berskala dengan baik dengan jenis instans yang sangat besar dan lebar jalur rangkaian yang tinggi, kami tidak dapat terus menambah replika tanpa had tanpa akhirnya membebankan yang utama. Untuk menangani perkara ini, kami bekerjasama dengan pasukan Azure PostgreSQL mengenai replikasi berperingkat⁠(dibuka dalam tetingkap baru), di mana replika perantaraan menyampaikan WAL kepada replika hiliran. Pendekatan ini membolehkan kami menskalakan kepada lebih daripada seratus replika tanpa membebankan yang utama. Namun, ia juga memperkenalkan kerumitan operasi tambahan, terutamanya dalam pengurusan failover. Ciri ini masih dalam ujian; kami akan memastikan ia kukuh dan boleh beralih dengan selamat sebelum melancarkannya ke pengeluaran.

Cabaran: Lonjakan trafik secara tiba-tiba pada titik akhir tertentu, peningkatan mendadak pertanyaan yang mahal, atau ribut percubaan semula boleh dengan cepat menghabiskan sumber kritikal seperti CPU, I/O, dan sambungan, yang menyebabkan kemerosotan perkhidmatan secara meluas.

Penyelesaian: Kami melaksanakan had kadar merentasi pelbagai lapisan—aplikasi, pengumpul sambungan, proksi, dan pertanyaan—untuk mencegah lonjakan trafik secara mendadak daripada membebankan instans pangkalan data dan mencetuskan kegagalan berantai. Ia juga penting untuk mengelakkan selang masa cuba semula yang terlalu singkat, yang boleh mencetuskan ribut percubaan semula. Kami juga mempertingkatkan lapisan ORM untuk menyokong pengehadan kadar dan apabila perlu, menyekat sepenuhnya ringkasan pertanyaan tertentu. Bentuk pengurangan beban yang disasarkan ini membolehkan pemulihan cepat daripada lonjakan mendadak pertanyaan yang mahal.

Cabaran: Walaupun perubahan skema yang kecil, seperti menukar jenis lajur, boleh mencetuskan penulisan semula jadual sepenuhnya⁠(dibuka dalam tetingkap baru). Oleh itu, kami melaksanakan perubahan skema dengan berhati-hati—mengehadkannya kepada operasi ringan dan mengelakkan sebarang perubahan yang menulis semula keseluruhan jadual.

Penyelesaian: Hanya perubahan skema ringan yang dibenarkan, seperti menambah atau mengalih keluar lajur tertentu yang tidak mencetuskan penulisan semula jadual sepenuhnya. Kami menguatkuasakan had masa tamat yang ketat selama 5 saat pada perubahan skema. Mencipta dan menggugurkan indeks secara serentak dibenarkan. Perubahan skema dihadkan kepada jadual yang sedia ada. Jika ciri baharu memerlukan jadual tambahan, jadual tersebut mesti berada dalam sistem berpecah alternatif seperti Azure CosmosDB dan bukannya PostgreSQL. Apabila mengisi semula medan jadual, kami mengenakan had kadar yang ketat untuk mencegah lonjakan penulisan. Walaupun proses ini kadangkala boleh mengambil masa lebih daripada seminggu, ia memastikan kestabilan dan mengelakkan sebarang kesan terhadap pengeluaran.

Usaha ini menunjukkan bahawa dengan reka bentuk dan pengoptimuman yang betul, Azure PostgreSQL boleh diskalakan untuk mengendalikan beban kerja pengeluaran terbesar. PostgreSQL mengendalikan berjuta-juta QPS untuk beban kerja yang berat pada bacaan, menggerakkan produk paling kritikal OpenAI seperti ChatGPT dan platform API. Kami menambah hampir 50 replika baca sambil mengekalkan kelewatan replikasi hampir sifar, mengekalkan bacaan berkependaman rendah merentas rantau yang diedarkan secara geografi, dan membina ruang kapasiti yang mencukupi untuk menyokong pertumbuhan masa depan.

Penskalaan ini berfungsi sambil meminimumkan kependaman dan meningkatkan kebolehpercayaan. Kami secara konsisten menyampaikan kependaman p99 sisi klien dalam milisaat dua digit rendah dan ketersediaan lima-sembilan dalam pengeluaran. Dan sepanjang 12 bulan yang lalu, kami hanya mengalami satu insiden SEV-0 PostgreSQL (ia berlaku semasa pelancaran tular⁠(dibuka dalam tetingkap baru) ChatGPT ImageGen, apabila trafik penulisan tiba-tiba melonjak lebih daripada 10 kali ganda apabila lebih 100 juta pengguna baharu mendaftar dalam tempoh seminggu.)

Walaupun kami berpuas hati dengan sejauh mana PostgreSQL telah membawa kami, kami terus mencabar hadnya untuk memastikan kami mempunyai landasan yang mencukupi untuk pertumbuhan masa depan. Kami telah memindahkan beban kerja penulisan lebih mencabar yang boleh dipecahkan kepada sistem berpecah kami seperti CosmosDB. Beban kerja selebihnya yang banyak melibatkan penulisan lebih mencabar untuk dipecahkan kepada shard—kami juga sedang memindahkan beban kerja tersebut secara aktif untuk terus mengurangkan beban penulisan pada PostgreSQL utama. Kami juga sedang bekerjasama dengan Azure untuk membolehkan replikasi bertingkat supaya kami boleh menskalakan dengan selamat kepada lebih banyak replika bacaan.

Memandang ke hadapan, kami akan terus meneroka pendekatan tambahan untuk meningkatkan skala, termasuk PostgreSQL berpecah atau sistem teragih alternatif, selaras dengan keperluan infrastruktur kami yang terus berkembang.