ایک ارب سے زائد ChatGPT صارفین کے لیے آن لائن ذخیرے کی تیز توسیع (حصہ دوم)

OpenAI کی تمام مصنوعات کو ڈیٹا تک تیز، قابلِ اعتماد رسائی چاہیے، جو ہمارا ذخیرہ پلیٹ فارم Habitat فراہم کرتا ہے. اسے 40 جغرافیائی خطوں میں ایک ارب سے زیادہ صارفین کو ملی سیکنڈوں میں جواب دینا ہوتا ہے. ہمارے بنیادی ڈھانچے کو ایک غیر معمولی چیلنج درپیش تھا: زبردست اضافے اور نئے استعمال کو سنبھالنا، اور ساتھ ہی بھروسا مندی، کارکردگی اور مصنوعات کے ڈویلپرز کی کام کی رفتار بہتر بناتے رہنا. اس چیلنج کے حل کے لیے ہمیں اپنے آن لائن ذخیرہ پلیٹ فارم کے ڈیزائن اور اسے چلانے کے طریقے پر نئے سرے سے غور کرنا پڑا. ہم مسلسل فوائد اور نقصانات کا جائزہ لیتے رہے، اس ترتیب سے: پہلے مصنوعات کی انتہائی اہم درخواستوں کے لیے کافی قابلِ اعتماد بننا، پھر عالمی صارفین کے لیے کافی تیز، اور آخر میں بہت بڑے پیمانے پر مہارت سے نظام چلانا.

دو حصوں کی یہ تحریر بتاتی ہے کہ ہم نے Habitat کو ایک سادہ کلائنٹ لائبریری اور ڈیٹابیس سے عالمی سطح پر تقسیم شدہ ذخیرہ پلیٹ فارم کیسے بنایا، جو 500 پیٹابائٹ سے زیادہ ڈیٹا فراہم کرتا ہے. حصہ اوّل میں Habitat کے Python کلائنٹ سے ایک خدمت بننے کے سفر پر توجہ دی گئی تھی. اس میں ان تکنیکوں کا بھی ذکر تھا جن سے ہم Python پر مبنی خدمت کو اس حد سے بہت آگے لے جا سکے جسے بہت سے لوگ عملی سمجھتے ہیں.

اس تحریر، حصہ دوم، میں ہم بتاتے ہیں کہ ہم نے ذخیرے کے بنیادی جزو Azure Cosmos DB کو کیسے وسیع کیا. Azure ٹیم کے ساتھ قریبی تعاون سے ہم مشترکہ انتظام والے کنٹینروں پر مبنی کثیر کرایہ داری کے قابلِ عمل طریقے تک پہنچے، جو وسیع عالمی پیمانے پر ڈیٹا پڑھنے کی عمدہ کارکردگی دیتا ہے.

کمپنیوں کا حجم بڑھنے پر بنیادی ڈھانچے کی ٹیمیں اکثر واحد کرایہ دار نظاموں سے کثیر کرایہ دار نظاموں کی طرف جاتی ہیں. واحد کرایہ داری میں مصنوعات کے ہر حصے کی ٹیم اپنا نظام چلاتی ہے. اس سے خرابی کا دائرہ محدود، ذمہ داریوں کی حدیں واضح اور کام کے بوجھ الگ رہتے ہیں. ٹیموں اور مصنوعات کے حصوں میں اضافے کے ساتھ اسے چلانا مہنگا ہو جاتا ہے. واحد کرایہ داری ہر مصنوعات ٹیم کو گنجائش کی منصوبہ بندی کا ذمہ دار بناتی ہے اور اکثر ضرورت سے کہیں زیادہ وسائل مختص ہونے کا سبب بنتی ہے.

اس کے برعکس کثیر کرایہ داری اختیار ایک مرکزی ڈیٹابیس ٹیم کو دیتی ہے، جسے وسائل مختص کرنے کا زیادہ علم اور تجربہ ہوتا ہے. مگر کثیر کرایہ داری کے اپنے مسائل ہیں، جیسے زیادہ وسائل استعمال کرنے والے پڑوسی: ایک کرایہ دار وسائل کا غیر معمولی بڑا حصہ استعمال کرکے دوسروں کو نقصان پہنچاتا ہے.

Habitat میں بڑے پیمانے پر قابلِ اعتماد اور وسائل کا مؤثر استعمال کرنے والا ذخیرہ نظام بنانے کے لیے ہمیں ان تمام فوائد اور نقصانات کو تولنا پڑا. آج Habitat، OpenAI کی کئی مصنوعات کے لیے کثیر کرایہ دار ڈیٹابیس کی تہہ ہے. مگر ہمارا سفر گھوم کر واپس آیا: پہلے ایک کثیر کرایہ دار Azure Cosmos DB کنٹینر، پھر پسِ پشت واحد کرایہ دار کنٹینروں کی فراہمی، اور آخر میں بطور طے شدہ انتخاب دوبارہ کثیر کرایہ دار کنٹینر. Habitat میں کثیر کرایہ داری کا ہمارا سفر ابھی ابتدائی مرحلے میں ہے. ہم بہت سے استعمال سنبھالتے ہیں، مگر جہاں ممکن ہو Azure Cosmos DB کی بلٹ اِن بنیادی سہولتیں استعمال کرکے اس شعبے میں سرمایہ کاری مؤخر کر سکے ہیں.

Azure Cosmos DB کے ساتھ اپنے سفر سے پہلے کچھ بنیادی باتیں:

• Azure Cosmos DB اکاؤنٹ کنٹینروں کا ایک مجموعہ اور نقل سازی کی پالیسی متعین کرتا ہے

• ہر کنٹینر کے لیے درخواست اکائی فی سیکنڈ (RU/s) میں تھروپٹ کی ایک مقدار مختص ہوتی ہے

• ہر کنٹینر میں ڈیٹا مقررہ منطقی پارٹیشن کلید کے مطابق حصوں میں بانٹ کر محفوظ کیا جاتا ہے، اور ہر کلید کے ذخیرے اور تھروپٹ کی حدیں دستاویزات میں درج ہیں

• Azure Cosmos DB منطقی پارٹیشن کلیدوں کو کم تعداد میں موجود بنیادی مادی پارٹیشنوں پر تقسیم کرتا ہے. ذخیرہ حد سے بڑھنے پر، یا مختص تھروپٹ برقرار رکھنے کے لیے مزید مادی پارٹیشن درکار ہونے پر، وہ انہیں کئی مادی پارٹیشنوں میں بانٹ دیتا ہے

ابتدا میں ہم کلائنٹ کا ہر بوجھ آنے دیتے تھے اور اضافی بوجھ روکنے کے لیے ہر منطقی پارٹیشن کلید کی بیان کردہ 10 ہزار RU/s حد پر انحصار کرتے تھے. شروع میں ہم ہر اکاؤنٹ میں صرف ایک طے شدہ Azure Cosmos DB کنٹینر بھی استعمال کرتے تھے. یہ مناسب طور پر چلتا رہا، مگر چند وجوہ سے مسائل پیدا ہوئے:

ابتدائی API فیصلوں کی وجہ سے ہم نے منطقی پارٹیشن کلید کا انتخاب براہِ راست کلائنٹس کے اختیار میں دیا تھا. نتیجتاً مصنوعات کے مختلف استعمال میں عام پارٹیشن کلیدوں، مثلاً user_id یا workspace_id، کے درمیان اکثر تصادم ہوتا ہے. چونکہ یہ استعمال ایک ہی منطقی پارٹیشن کلید پر Azure Cosmos DB کی حدوں میں شریک تھے، اس ڈیزائن نے کسی بھی صارف کے مجموعی تھروپٹ کو محدود کر دیا.

Habitat اور Azure Cosmos DB پر منتقل ہونے سے پہلے Postgres کو وسیع کرتے وقت ایک عام مسئلہ یہ تھا کہ کسی بہت زیادہ فعال تنظیم یا کلید کی بے شمار درخواستیں پورا ڈیٹابیس بند کر سکتی تھیں—یعنی ایک کرایہ دار غیر متناسب طور پر زیادہ بوجھ پیدا کرتا تھا. ان کلیدوں کو کیش میں رکھنے اور کیش میں ڈیٹا نہ ملنے کی صورت میں لیز کا طریقہ بنانے پر خاصی مشترکہ محنت ہوئی، تاکہ اس سے پیدا ہونے والا بوجھ بنیادی ڈیٹابیس کو مفلوج نہ کرے.

اگرچہ دستاویزات میں ڈیٹا کے حجم اور تھروپٹ کی حدیں منطقی پارٹیشن کلیدوں پر لاگو بتائی گئی ہیں، اصل میں ان کا نفاذ مادی پارٹیشن پر ہوتا ہے. عملی طور پر اس کا مطلب ہے کہ منطقی پارٹیشن 10,000 RU/s تک نہیں پہنچ سکتے. اس کے بجائے، وہ اسی مادی پارٹیشن پر موجود ہر دوسری منطقی پارٹیشن کلید کے ساتھ اس کی حدوں میں حصہ دار ہوتے ہیں.

یوں زیادہ وسائل استعمال کرنے والے پڑوسی بہت سی غیر متعلقہ منطقی پارٹیشن کلیدوں کو متاثر کر سکتے تھے. مصنوعات کی کم استعمال ہونے والی خصوصیات کے ڈیٹا پر کام کرنے والے بوجھ، لاگ اِن اور رجسٹریشن کے بنیادی عمل میں خلل ڈالتے تھے.

کسی مادی پارٹیشن کی تھروپٹ حد بھی بدلتی رہتی ہے اور Azure Cosmos DB کنٹینر کو مختص کل تھروپٹ پر منحصر ہوتی ہے. کنٹینر کے لیے مختص تھروپٹ اس کے مادی پارٹیشنوں میں تقریباً برابر تقسیم ہوتا ہے.

ڈیٹا بڑھنے پر مادی پارٹیشن تقسیم ہوتے ہیں، جس سے ان کی کل تعداد بڑھتی ہے، مگر مختص کل تھروپٹ وہی رہتا ہے. نتیجتاً ڈیٹا بڑھنے کے ساتھ ہر پارٹیشن کی مؤثر تھروپٹ حد گھٹتی جاتی ہے.

ذخیرے کی سب سے زیادہ ضرورت والے، بلاب جیسے استعمال میں یہ ایسی خرابی پیدا کرتا ہے کہ صرف ذخیرہ بڑھنے سے فعال کام کے بوجھ کے لیے تھروپٹ کی گنجائش گھٹ جاتی ہے، چاہے درخواستوں کی شرح اور استعمال مستحکم رہیں.

الگ کنٹینر پارٹیشن کلیدوں کی ان حدوں اور زیادہ وسائل استعمال کرنے والے پڑوسیوں کے مسائل کو جزوی طور پر حل کرتے ہیں. الگ کنٹینر استعمال کرنے سے ہر ایک کو آزاد مادی پارٹیشن دیے جا سکتے ہیں. پھر صرف اسی کنٹینر کے مختلف کام کے بوجھ ایک دوسرے کے وسائل زیادہ استعمال کر سکتے ہیں یا ان کی پارٹیشن کلیدیں آپس میں ٹکرا سکتی ہیں. اس کا منفی پہلو یہ ہے کہ نئے کنٹینر مہیا کرنے میں اضافی محنت لگتی ہے—ہر کنٹینر کی گنجائش کے لیے الگ منصوبہ بندی چاہیے. اس لیے ہم صرف وہاں کنٹینر بنانا چاہتے ہیں جہاں کسی خدمت یا استعمال کو الگ کرنا معقول ہو.

ہم نے سخت علیحدگی درکار رکھنے والے اہم ترین نئے استعمال کے لیے الگ Azure Cosmos DB کنٹینر استعمال کرنا شروع کیے. ساتھ ہی کمزور پارٹیشنوں کے لیے ایک اسکرپٹ استعمال کیا جو ہر کنٹینر کے مختص کل تھروپٹ کو اس کے مادی پارٹیشنوں کی تعداد سے ہم آہنگ رکھتا تھا. یوں ہم درپیش مسائل سے بڑی حد تک بچ گئے.

لیکن ابتدا ایک طے شدہ کنٹینر سے کرنے کی وجہ سے بہت سے پرانے اہم استعمال بدقسمتی سے وہیں پھنسے رہے؛ ڈیٹا منتقل کیے بغیر انہیں الگ نہیں کیا جا سکتا تھا. مشترکہ طے شدہ کنٹینر کے ڈیٹا پر اب بھی منحصر اہم خدمات کو بچانے کے لیے ہم اکثر ٹیموں کو نئی خدمات یا بڑی خصوصیات کے لیے الگ کنٹینر بنانے کا مشورہ دیتے تھے. ہمارا حجم بڑھنے کے ساتھ طے شدہ کنٹینر پر دباؤ بڑھا اور عملی نظام میں خرابی کے واقعات بھی بڑھے. ہم ہر نئی خدمت یا بڑی خصوصیت کے لیے کنٹینر مہیا کرنے لگے، محض طے شدہ کنٹینر کو مزید بوجھ سے بچانے کے لیے.

اس سے ہم پوری سائٹ کی کئی بندشوں سے بچے، اور خرابی کا دائرہ کسی خصوصیت یا خدمت کی کارکردگی متاثر ہونے تک محدود رہا. مگر بالآخر نئے کنٹینر مہیا کرنے کی اضافی محنت ہمارے لیے مسئلہ بن گئی:

پرانے مشترکہ طے شدہ کنٹینر میں کسی ایک نئے استعمال کا 0 سے 10 لاکھ QPS تک پہنچنا، مجموعی استعمال میں نمایاں تبدیلی لانے کا امکان نہیں رکھتا تھا. لیکن الگ کنٹینر میں کسی نئے استعمال کا 0 سے 10 لاکھ QPS تک پہنچنا، صرف اندرونی آزمائشی استعمال کے بنیادی بوجھ سے 1,000 گنا زیادہ ہو سکتا تھا.

مخصوص کنٹینروں کے ساتھ اب ٹیموں کو یاد رکھنا پڑتا تھا کہ اجرا سے پہلے متوقع تھروپٹ کے مطابق کنٹینروں کی گنجائش مختص کریں. مصنوعات کی ٹیمیں اکثر خصوصیات جاری کر دیتیں اور پہلے سے گنجائش بڑھانا بھول جاتیں. پھر اجرا کے دن ہم سنگین خرابیوں کے ہنگامی اجلاسوں میں آخری لمحے کنٹینروں کی گنجائش بڑھانے کی کوشش کرتے رہتے.

مختلف کام کے بوجھ یکجا کرنے کا یہ کثیر کرایہ دار نظاموں کا بنیادی فائدہ ہے، جو اس کنٹینر حکمتِ عملی میں بہتر علیحدگی کے بدلے ہمیں چھوڑنا پڑتا ہے.

وقت کے ساتھ مخصوص کنٹینروں کے استعمال کی نگرانی کے لیے مصنوعات کی گہری معلومات بھی ضروری ہو گئیں، تاکہ معلوم ہو کہ آمدورفت کب بدلے گی یا بڑھے گی.

ہم اضافے کے رجحانات کے مطابق ہر کنٹینر کا مختص تھروپٹ بڑھانے کے لیے بنیادی کنٹرول پلین اسکرپٹ دے سکتے ہیں. لیکن مجموعی اضافے میں استحکام نہ ہونے سے درست توسیع کے لیے عملاً OpenAI کی ہر مصنوعات ٹیم کو گنجائش کی منصوبہ بندی میں شامل ہونا پڑا.

تنظیمی سطح پر یہ طریقہ بڑھتے حجم کے ساتھ نہیں چل سکا، کیونکہ ہر خدمت کی ذمہ دار ٹیم Azure Cosmos DB کے وسائل مختص کرنے پر مختلف درجے کی توجہ دیتی تھی.

تنظیم بڑھنے کے ساتھ ان عملی مسائل کو بڑے پیمانے پر سنبھالنا مشکل ہو گیا. منصوبہ بندی کے لیے ایک مرکزی ٹیم نہ ہونے سے کئی ٹیموں کی منصوبہ بندی ناقص رہی. نتیجتاً ہم دوبارہ کثیر کرایہ دار حل کی طرف آئے اور مشترکہ کرایہ داری کے ڈیزائن سے اپنے ابتدائی مسائل حل کرنے کے لیے Azure ٹیم کے ساتھ قریبی تعاون کیا:

سب سے زیادہ فعال کلیدوں کی درخواستوں کی شرح پہلے محدود کرنے سے زیادہ وسائل استعمال کرنے والے پڑوسی کسی مادی پارٹیشن کا پورا دستیاب تھروپٹ نہیں لے سکتے. اس سے وہ اثر کم ہوتا ہے جس میں ایک زیادہ فعال کلید پوری سائٹ کو متاثر کر سکتی ہے.

درخواستوں کی درجہ بندی والا QoS اسی طرح آف لائن کام کے بوجھ، مثلاً بڑی مقدار میں ڈیٹا داخل کرنے یا نکالنے، کو کسی مادی پارٹیشن کا پورا تھروپٹ استعمال کرنے سے روکتا ہے. ان کاموں کی درخواستوں کو کم ترجیح دینے سے پہلے انہی کی شرح محدود ہوتی ہے، اور آخری صارفین کی زیادہ ترجیحی، تعاملی درخواستیں اس پابندی سے بچتی ہیں.

Azure Cosmos DB میں پہلے سے سرورلیس وضع موجود تھی، جو مختص وسائل والی وضع میں ہمارے کمزور پارٹیشنوں کا مسئلہ حل کر سکتی تھی. لیکن ایک بڑا نقصان تھا: اس کی توسیع صرف ذخیرے کے استعمال پر ہوتی تھی، اور ہر مادی پارٹیشن میں RU کا استعمال 5 ہزار RU/s تک محدود تھا. اس سے کمزور پارٹیشنوں کا مسئلہ حل ہوتا، مگر زیادہ RU درکار رکھنے والے استعمال کو بڑھانا ممکن نہ رہتا.

Azure Cosmos DB ٹیم نے ہمارے لیے بہتر سرورلیس وضع بنائی، جس میں ہر مادی پارٹیشن 10 ہزار RU/s تک بڑھ سکتا تھا. ذخیرے کے استعمال کے علاوہ RU کے استعمال کی بنیاد پر بھی پارٹیشن تقسیم ہونے لگے. یوں ہمیں کنٹینروں کی دستی نگرانی اور گنجائش بڑھانے کی ضرورت نہ رہی.

ان تبدیلیوں سے ہم دوبارہ ایک مشترکہ کنٹینر استعمال کرنے لگے. کام کے بوجھ کی علیحدگی برقرار رہی، جبکہ مصنوعات کی ٹیموں کے لیے ابتدائی یا مسلسل گنجائش کی منصوبہ بندی بہت آسان ہو گئی. تب سے گزرے مہینوں میں مصنوعات کی تیاری تیز ہونے کے باوجود وسائل کی فراہمی یا زیادہ وسائل استعمال کرنے والے پڑوسیوں سے متعلق کوئی واقعہ پیش نہیں آیا.

جب کمپنیاں OpenAI کے حجم تک پہنچتی ہیں تو زیرِ انتظام خدمات کم ہی «زیرِ انتظام» رہتی ہیں. بہت سے کام کے بوجھ کلاؤڈ فراہم کنندہ کے بنیادی ڈھانچے میں معمول سے ہٹ جاتے ہیں. جب OpenAI، Azure Cosmos DB کے سب سے بڑے صارفین میں شامل ہوا تو اسے کامیابی سے چلانے کے لیے مختلف طریقہ درکار تھا: مشترکہ آزمائشیں، مشترکہ ڈیش بورڈ، انجینئرنگ کے براہِ راست رابطے، اور صرف ہمارے پیمانے پر سامنے آنے والی خرابیوں کی مشترکہ ذمہ داری. آج ہمارا سب سے بڑا Azure Cosmos DB اکاؤنٹ دسیوں پیٹابائٹ ڈیٹا محفوظ کرتا ہے اور 2 کروڑ QPS سے زیادہ درخواستیں پوری کرتا ہے. ہماری معلومات کے مطابق صرف ہماری کمپنی نے Azure Cosmos DB کو اس پیمانے پر تعینات کیا ہے.

2024 کے آخر میں ایک علاقائی بندش نے واضح کر دیا کہ یہ تعاون کیوں ضروری تھا. اس وقت ہمارے سب سے بڑے Azure Cosmos DB اکاؤنٹس میں سے ایک کے بنیادی Azure خطے میں بجلی چلی گئی. اس کے بعد متبادل خطے پر منتقلی کے عمل میں معلوم ہوا کہ ہمارے سب سے بڑے اکاؤنٹس کو ثانوی خطے پر منتقل ہونے میں کئی گھنٹے لگیں گے. نہ ہماری ٹیم نے، نہ Azure Cosmos DB ٹیم نے ہمارے پیمانے پر یہ آزمایا تھا.

تقریباً ایک ماہ بعد ان اکاؤنٹس کو اصل خطے میں واپس لاتے وقت ہم ایک اور سنگین بندش کا سبب بنے. اصل خطے سے جڑنے کی اچانک یلغار نے وہاں کے Azure Cosmos DB گیٹ وے کو مفلوج کر دیا. گیٹ وے وضع میں Azure Cosmos DB کلائنٹ کے متبادل نظام پر منتقل ہونے کے طریقے میں ایک خاص رویے کی وجہ سے تمام کلائنٹس فوراً اصل خطے سے کنکشن قائم کرکے درخواستیں بھیجنے لگے، حالانکہ صرف کچھ مادی پارٹیشن وہاں واپس آئے تھے.

ہر بندش میں OpenAI اور Azure دونوں نے اپنے ہنگامی واقعات سنبھالنے کے طریقے اپنائے، کئی بنیادی اسباب شناخت کیے اور اصلاحات نافذ کیں. لیکن یہ بندشیں ایک بڑے نظامی مسئلے کی علامات تھیں، جو ہماری ٹیم اور Azure Cosmos DB ٹیم کے نظام چلانے اور آزمانے کے طریقوں کے درمیان تھا. ابتدا میں زیرِ انتظام خدمات استعمال کرکے ہم تیزی سے آگے بڑھ سکے اور کاروباری اہداف پر توجہ دے سکے. بڑے پیمانے پر زیرِ انتظام خدمات میں فراہم کنندہ کا انتظام ناکافی ہو جاتا ہے، اور ڈیزائن سے لے کر نظام چلانے تک ہر سطح پر اس کے ساتھ گہرا انضمام درکار ہوتا ہے.

آج Habitat اور Azure کی انجینئرنگ ٹیمیں مل کر Habitat کی ہر تہہ کی نگرانی کرتی ہیں، ہماری خدمات کی تہوں سے لے کر Azure Cosmos DB کے مادی ذخیرے کی تہوں تک. ہم تبدیلیاں ایک ایسے Azure Cosmos DB اکاؤنٹ پر چلاتے اور آزماتے ہیں جو عملی نظام جتنا بڑا ہے، مگر عملی نظام کا حصہ نہیں. ہم SDKs کو مل کر آزماتے اور بہتر بناتے ہیں، اور اپنے Azure Cosmos DB اکاؤنٹس کی توسیع اور حجم طے کرنے کے بہترین طریقے وضع کرتے ہیں. Teams کے ذریعے ہماری انجینئرنگ ٹیموں کا براہِ راست رابطہ ہے. ہم نے معاونت کے مختلف درجوں سے گزرے بغیر ایک دوسرے کو براہِ راست ہنگامی اطلاع دینے کے طریقے بھی فراہم کیے ہیں.

گزشتہ سال Azure Cosmos DB کے کنٹرول پلین اور گیٹ وے کی توسیع پذیری بہتر بنانے کے لیے بڑی مقدار میں مشترکہ کام ہوا. میٹا ڈیٹا پارٹیشن کو بچانے کے لیے گیٹ وے میں بوجھ سے تحفظ اور Azure Cosmos DB کے مختلف میٹا ڈیٹا کی کیشنگ شامل کی گئی. کنکشن پولنگ اور کنکشنوں کے زیادہ دوبارہ استعمال سے ہمارے Python habitat-service پراسیسوں کا دباؤ کم کیا گیا. جہاں ممکن تھا کام کے بوجھ ایک ہی مقام پر رکھے گئے، اور مختلف VPCs کے ذریعے اہم کام کے بوجھ کو آف لائن کام کے بوجھ سے الگ کیا گیا.

انجینئرنگ میں اس درجے کے اشتراک نے گزشتہ سال ہمارے Azure Cosmos DB کو مستحکم رکھنے میں فیصلہ کن کردار ادا کیا. کوئی بھی کافی بڑا یا اہم نظام ایسے اشتراک کا تقاضا کرتا ہے: ذمہ داریوں کی دیواریں ہٹا کر تنظیمی حدود سے آگے مل کر کام کرنا.

جیسا کہ حصہ اوّل میں بتایا، ہمارا بنیادی فلسفہ ہے: پہلے اسے کارآمد بنائیں، پھر تیز، پھر کم خرچ. پہلے بھروسا مندی، پھر کارکردگی، پھر وسائل کا مؤثر استعمال. Habitat، OpenAI کے لیے ایک اہم بنیادی ڈھانچا بن چکا تھا، اس لیے پہلی ترجیح اسے قابلِ اعتماد بنانا تھی. 2025 میں نظام مستحکم ہوا اور OpenAI عالمی سطح پر پھیلا، تو تاخیر صارفین اور مصنوعات کی ٹیموں کے لیے اگلی رکاوٹ بن گئی.

کمپیوٹنگ اور ذخیرے کی گنجائش اکثر الگ خطوں میں ہوتی تھی، اس لیے بین العلاقائی درخواستیں ناگزیر تھیں.

ڈیٹا کہاں محفوظ تھا اور درخواست کہاں پوری ہوتی تھی، اس کے لحاظ سے تاخیر میں بہت فرق ہوتا تھا. Habitat کی درخواستیں تیزی سے پوری کرنے کے لیے ڈویلپرز کلائنٹ کی طرف اضافی کیشنگ، درخواستوں کی گروہ بندی، ڈیٹابیس میں پڑھنے اور لکھنے کے عمل کو کم کرنے، اور جہاں ممکن ہو فوری تکمیل کے لیے ضروری سلسلے سے دوسرے کام ہٹانے پر انحصار کرتے تھے. اس سے مصنوعات کے کچھ دلچسپ ڈیزائن بنے جو ڈیٹابیس کے مسائل کے باوجود بہتر چلتے تھے، مگر مصنوعات زیادہ پیچیدہ اور ان میں تبدیلی کی رفتار سست ہو گئی. یوں Habitat کا مقصد پورا نہ ہوا: ڈیٹابیس کو سمجھنے کی ضرورت کے بغیر مصنوعات تیزی سے تیار کرنا.

2026 میں یہ ہماری خاص توجہ کا مرکز رہا ہے. ہم نے پڑھنے کی کارکردگی بہتر بنانے کے لیے کئی سطحوں پر حکمتِ عملی بنائی ہے، کیونکہ Habitat کی 90% سے زیادہ درخواستیں ڈیٹا پڑھنے کی ہوتی ہیں:

ڈیٹا ریزیڈنسی کے تقاضے رکھنے والے صارفین کے لیے دنیا بھر میں Azure کے مختلف خطوں میں ہمارے متعدد Azure Cosmos DB اکاؤنٹس ہیں. جن صارفین پر ڈیٹا ریزیڈنسی کی سخت پابندیاں نہیں، ان کے قریب ڈیٹا رکھنے سے بھی تاخیر کم اور تجربہ بہتر ہوتا ہے.

عملی طور پر ہم ڈیٹا ریزیڈنسی کی ضروریات سے ہٹ کر بڑے پیمانے پر ایسا نہیں کر سکتے، کیونکہ ڈیٹا رکھنے کی جگہ کلاؤڈ کی مادی گنجائش سے محدود ہے. ہمارے ڈیٹا مجموعے اتنے بڑے ہیں کہ بہت سے خطوں میں صارفین کی آمدورفت کے متناسب حصے کے لیے درکار وسیع ذخیرے کی گنجائش نہیں.

جہاں ڈیٹا سینٹر کی گنجائش، بجلی یا ٹھنڈک محدود ہو، وہاں کبھی ہمیں سیدھا انتخاب کرنا پڑتا ہے: اسی مقام پر ذخیرہ رکھنے اور Habitat کی تاخیر گھٹانے کے لیے گنجائش مختص کریں، یا اسے درخواستیں پوری کرنے کی اضافی کمپیوٹنگ کے لیے استعمال کرکے ذخیرے کی درخواستیں دور بھیجیں.

اس لیے ڈیٹا کہاں رکھا جائے، یہ فیصلہ اکثر دو ضرورتوں میں توازن کا ہوتا ہے: الف) مختلف مصنوعات اور صارف گروہوں کے لیے تاخیر کم کرنا، اور ب) ذخیرے اور کمپیوٹنگ کی اصل دستیاب گنجائش.

جن کاموں میں تاخیر کم رکھنا سب سے اہم ہے، مثلاً ہر درخواست پر درکار توثیقی میٹا ڈیٹا، ان کے لیے ہم کئی ثانوی خطوں میں نقلیں رکھنے والے Azure Cosmos DB اکاؤنٹس استعمال کرتے ہیں. اس سے کمپیوٹنگ اور Habitat کے درمیان آمدورفت کا وقت کم ہوتا ہے. کچھ اکاؤنٹس Azure کے ان تمام 40 خطوں میں نقلیں رکھتے ہیں جہاں ہم درخواستیں پوری کرتے ہیں؛ دوسرے ہر براعظم کے کم از کم ایک خطے میں نقل رکھتے ہیں.

ہمیں Habitat میں ڈیٹا کی منتقلی اور راستہ بندی کی ایسی تہہ توقع سے پہلے بنانی پڑی جس کی اندرونی تفصیلات صارف سے پوشیدہ رہیں، تاکہ مختلف نقل سازی ترتیب والے اکاؤنٹس کے درمیان ڈیٹا مجموعے منتقل کیے جا سکیں.

لیکن یہ طریقہ بھی بالآخر گنجائش سے محدود ہے، اس لیے صرف چند منتخب ڈیٹا مجموعوں کے لیے استعمال ہوتا ہے.

Habitat کے کام کا زیادہ تر بوجھ ڈیٹا پڑھنے کا ہے: ایپلی کیشنز مسلسل ترتیبات، حالت اور دوسری خصوصیات حاصل کرتی ہیں. آمدورفت کا بڑا حصہ ان نسبتاً کم اقسام کے فعال ڈیٹا سے آتا ہے جن تک بار بار رسائی ہوتی ہے. اس لیے یہ نظام تقسیم شدہ کیشنگ کے لیے خاص طور پر موزوں ہے. کیشنگ ایک خطے کے بنیادی ڈھانچے میں بھی کارکردگی بہتر کرتی ہے، مگر کئی خطوں میں یہ فائدہ بڑھ جاتا ہے، جہاں اس سے بین العلاقائی تاخیر «چھپائی» جا سکتی ہے.

ہم نے Habitat میں تقسیم شدہ ضمنی کیشنگ کی تہہ مربوط کی ہے. یہ حال ہی میں حاصل کیے گئے آبجیکٹس اور ان کے روابط کی نقل Valkey سروروں میں رکھتی ہے، جو ہمارے بنیادی ڈھانچے میں صارفین کی درخواستیں پوری کرنے کی جگہ کے قریب ہیں. ایسے کیش عموماً مدتِ بقا (TTL) استعمال کرتے ہیں، جو کیش میں ڈیٹا ملنے کی شرح اور اس کے پرانے ہونے کے درمیان توازن رکھتی ہے. کم TTL سے ڈیٹا کم پرانا ہوتا ہے، مگر کیشنگ کا فائدہ گھٹتا ہے، کیونکہ اشیا جلد کیش سے خارج ہوتی ہیں اور انہیں زیادہ بار دوبارہ حاصل کرنا پڑتا ہے. زیادہ TTL سے کیش میں ڈیٹا ملنے کی شرح بڑھتی ہے، مگر پرانا ڈیٹا دیر تک فراہم ہوتا ہے، جس سے صارف کا تجربہ خراب اور مصنوعات کا رویہ غیر متوقع ہو جاتا ہے.

دوسرا طریقہ یہ ہے کہ جب ایپلی کیشن اسی بنیادی ڈیٹا میں لکھ رہی ہو، تب کیش کی متعلقہ نقل کو واضح طور پر غیر معتبر کر دیا جائے. اس سے کیش کا ڈیٹا بہت زیادہ تازہ رہتا ہے، مگر اسے درست نافذ کرنا مشکل ہو سکتا ہے. اس میں بھی جزوی ناکامی جیسی کئی غیر معمولی صورتیں ممکن ہیں، جو کیش کو پرانا چھوڑ دیتی ہیں. کئی خطوں میں تعیناتی سے یہ مسائل بڑھتے ہیں: بین العلاقائی نیٹ ورک کم قابلِ اعتماد ہوتے ہیں اور کیش کی تازہ کاری بنیادی ذخیرے کی نقل سازی کے ساتھ متوازی چلتی ہے. اس کے ساتھ TTL استعمال کرنے سے ڈیٹا کے پرانے رہنے کی زیادہ سے زیادہ مدت محدود ہوتی ہے، مگر اوپر بیان کردہ TTL کے فوائد اور نقصانات برقرار رہتے ہیں.

ہم نے Meta کے TAO جیسے نظاموں کی پیروی کرتے ہوئے کیش کو غیر معتبر کرنے کا زیادہ جدید طریقہ اپنایا ہے. Habitat کا مربوط کیش Azure Cosmos DB کی تبدیلی فیڈ سے ڈیٹا کی تبدیلیوں کے اندراج (CDC) پر انحصار کرتا ہے. اس سے نقلیں غیر معتبر ہونے کی اطلاع چند سیکنڈوں میں دنیا بھر میں پہنچتی ہے، کیش میں ڈیٹا ملنے کی شرح زیادہ اور اس کا پرانا پن کم رہتا ہے. ہمارے بنیادی ڈھانچے کی ایک خدمت یہ تبدیلی فیڈ پڑھتی ہے اور بنیادی ڈیٹا تازہ ہونے پر مقامی کیش کی متعلقہ نقلیں غیر معتبر کرتی ہے. یوں اگلی بار پڑھنے پر ڈیٹا کیش میں نہیں ملتا، اور کیش میں اس کا تازہ ترین نسخہ بھر دیا جاتا ہے.

ہم نے Habitat خدمت کا کوڈ Rust میں دوبارہ لکھ کر خود اس کے اندر کا اضافی بوجھ بھی ہٹایا اور تاخیر نمایاں کم کی. یہ اصل Python کوڈ سے زیادہ تیز ہے.

ان تبدیلیوں نے مل کر عالمی سطح پر ڈیٹا پڑھنے کا مجموعی p50 وقت تقریباً 120 ملی سیکنڈ سے گھٹا کر تقریباً 10 ملی سیکنڈ کر دیا ہے. اس سال کے شروع میں کارکردگی پر توجہ دینے کے بعد سے یہ 12 گنا بہتری ہے.

کیشنگ نے درمیانی تاخیر بہت کم کی ہے، مگر سب سے سست درخواستوں کے لیے اب بھی کیش سے باہر کا ڈیٹا بنیادی ذخیرے سے لانا پڑتا ہے، اکثر دور دراز خطوں سے. مزید گنجائش دستیاب ہونے اور ذخیرے کے مؤثر استعمال میں بہتری کے ساتھ ہم ایک زیادہ بنیادی مسئلہ حل کرنا چاہتے ہیں: ڈیٹا کو ابتدا ہی سے اس جگہ کے قریب رکھنا جہاں سے اس تک رسائی ہو گی.

قابلِ اعتماد اور قابلِ توسیع CDC—ڈیٹابیس کی تبدیلیاں آگے کے نظاموں تک پہنچانا—صرف Habitat کی کیشنگ حکمتِ عملی ہی نہیں، اس سے بڑھ کر بھی ایک اہم جزو ہے. ہزاروں کنٹینروں اور لاکھوں کنٹینر پارٹیشنوں کی ہر سیکنڈ درج ہونے والی لاکھوں تبدیلیاں سو سے زیادہ Kafka موضوعات سے گزرتی ہیں. یہ بالآخر ہم آہنگ ہونے والے ثانوی اشاریوں، ڈیٹا منتقلی کے سلسلوں، آف لائن تجزیوں اور حقیقی وقت کی دیگر خصوصیات کو بھی چلاتی ہیں. ہمارا بنیادی ڈھانچا عالمی سطح پر بڑھنے کے ساتھ قطاروں میں تبدیلیوں کی نگرانی زیادہ پیچیدہ ہو گئی ہے. اگر کلائنٹ اپنی قسم کی قطاریں بدلنے پر چلنے والا کال بیک درج کرنا چاہے، تو اسے پہلے معلوم کرنا ہوتا ہے کہ ڈیٹا کن Cosmos اکاؤنٹس اور کنٹینروں میں ہے، متعلقہ خطوں میں کون سی CDC خدمت ان کنٹینروں کی نگرانی کرتی ہے، اور CDC کارکنوں، Kafka اور اپنے وصول کنندہ کی گنجائش مناسب طور پر بڑھانی ہوتی ہے. ہمارا CDC پلیٹ فارم یہ پیچیدگیاں ڈویلپرز سے پوشیدہ رکھ کر سادہ انٹرفیس دینا چاہتا ہے: کلائنٹس قطاریں بدلنے پر چلانے کے لیے فنکشن درج کریں، اور ہم اندرونی ربط اور توسیع سنبھالیں.

ایک داخلی کنٹرول پلین مسلسل یقینی بناتا ہے کہ تمام مطلوبہ کنٹینروں کی تبدیلیاں درج ہوں، پڑھنے کے لیے Cosmos کے خطے چنتا ہے، اور مختلف جغرافیائی خطوں کے ہزاروں کارکنوں میں کام مؤثر انداز سے بانٹتا ہے. نقل رکھنے والے خطوں اور کم ترجیحی فیڈ مطالعے کا استعمال، تاخیر کے لیے حساس Habitat درخواستوں کو پس منظر میں تبدیلیاں درج کرنے کے بوجھ سے بچاتا ہے. اتنے بڑے مجموعے میں کارکنوں کے کریش، کنٹینر مسائل، لیز ذخیرے کی خرابیاں، غلط ترتیبات اور منزل کی ناکامیاں مسلسل ہوتی رہتی ہیں. ہم نے CDC کارکنوں کے دورِ حیات اور لیز سنبھالنے کے عمل کو مضبوط کیا، سلسلوں کی خرابیوں کو ایک دوسرے سے الگ رکھا، اور ترتیبات بدلنے اور نئے نسخے نافذ کرنے کے لیے حفاظتی تدابیر بنائیں. ہم ناقابلِ ترسیل پیغامات کی الگ قطاریں استعمال کرتے ہیں تاکہ ترسیل کی مستقل ناکامی سے اگلے تمام پیغامات نہ رک جائیں. پڑھنے والے اجزا کو Cosmos کے متبادل خطوں پر منتقل کرکے ہم علاقائی بندشوں کے باوجود کام جاری رکھتے ہیں. اپنے پیمانے پر ہمیں Azure کے CDC SDK میں بھی تبدیلیاں کرنی پڑیں. پیش رفت کے نشانات یادداشت میں جمع کرکے صرف وقفے وقفے سے مستقل ذخیرے میں لکھنے سے ان کے اندراج کو زیادہ مؤثر بنایا.

Habitat کے اندر Azure Cosmos DB کا استعمال پیچیدہ ہے، مگر اس کا بنیادی فائدہ ہمیشہ ڈویلپرز سے بنیادی ڈھانچے کی تفصیلات پوشیدہ رکھ کر مصنوعات کی تیاری تیز کرنا رہا ہے. ہمارا CDC پلیٹ فارم بھی یہی کرتا ہے.

ذخیرے کے API کو جان بوجھ کر محدود رکھ کر، Python خدمت کی توسیع جاری رکھ کر، اور فوری ترین انجینئرنگ مسائل کو ترجیح دے کر ایک چھوٹی ٹیم تیزی سے بڑھتا ذخیرہ پلیٹ فارم سنبھال سکی. ہم نے پہلے مصنوعات کی انتہائی اہم درخواستوں کے لیے بھروسا مندی، پھر عالمی صارفین کے لیے پڑھنے کی کارکردگی، اور آخر میں بڑے پیمانے پر نظام چلانے کی کارگزاری پر توجہ دی. اس طریقے سے تیز اضافہ اور نئے استعمال ممکن ہوئے، جبکہ بھروسا مندی، کارکردگی اور مصنوعات کی تیاری کی رفتار بہتر ہوتی گئی.

اگلے ایک ارب صارفین کے لیے Habitat اور گفتگو کے ذخیرے کو وسیع کرنے کی خاطر، ہمیں اپنے بنیادی ڈھانچے میں مزید بڑے پیمانے پر ڈیٹا کی نقلیں بنانے کی دشواری حل کرنی ہے. اس کی پیش بندی کے لیے ہم اندرونِ ادارہ ایگزابائٹ پیمانے کا مخصوص آن لائن ذخیرہ نظام بنا رہے ہیں، جو Habitat کے بڑے حجم والے ڈیٹا کی اقسام کے لیے موزوں ہے. یہ زیرِ تیاری نظام Rockset کے RocksDB Cloud بنیادی جزو کو Raft پر مبنی نقل سازی سے ملاتا ہے. یہ Azure Cosmos DB جیسا ہی دستاویزی ماڈل نافذ کرتا ہے، مگر کمپیوٹنگ سے الگ ذخیرہ اور مادی نقل سازی استعمال کرکے درکار فلیش گنجائش گھٹاتا ہے؛ اس کے بدلے درخواستوں کی زیادہ سے زیادہ فی سیکنڈ شرح کم ہوتی ہے.

اگر آپ جدید ترین پیمانے پر ڈیٹا کے بنیادی ڈھانچے کی ایسی کوششوں میں کام کرنا چاہتے ہیں، تو ہماری خالی آسامیوں پر نظر ڈالیں⁠.