100 కోట్లకుపైగా ChatGPT వినియోగదారుల కోసం ఆన్‌లైన్ నిల్వను వేగంగా విస్తరించడం

ఎవరైనా లాగిన్ అవుతున్నా, తమ Codex సెట్టింగ్‌లను చూస్తున్నా, ChatGPTలో కొత్త సంభాషణ ప్రారంభిస్తున్నా, ప్రతి OpenAI ఉత్పత్తి డేటాకు వేగవంతమైన, విశ్వసనీయ ప్రాప్యతపై ఆధారపడుతుంది. ఉత్పత్తి స్పందించడానికి ముందు ఆ చర్యల్లో ప్రతిదానికి అనేక వేర్వేరు డేటా శోధనలు అవసరం కావచ్చు. ఆ అభ్యర్థనలు నెమ్మదిస్తే, ఉత్పత్తి కూడా నెమ్మదిగా అనిపిస్తుంది. ఆ అభ్యర్థనలు విఫలమైతే, ఉత్పత్తి పూర్తిగా పనిచేయడం ఆగిపోతుంది.

OpenAI ఉత్పత్తులు అవసరమైన సమాచారాన్ని వేగంగా, విశ్వసనీయంగా పొందేందుకు మేము నిర్మించిన ఆన్‌లైన్ నిల్వ ప్లాట్‌ఫారమే హ్యాబిటాట్. దాదాపు 40 భౌగోళిక ప్రాంతాల్లో, వారానికి 100 కోట్లకుపైగా మంది ఉపయోగించే ఉత్పత్తులకు మద్దతిస్తూ హ్యాబిటాట్ ఇప్పుడు సెకనుకు 7 కోట్లకుపైగా అభ్యర్థనలను నిర్వహిస్తోంది. DevDay 2023లో GPTలకు మద్దతుగా హ్యాబిటాట్ తొలిసారి ప్రారంభమైంది. ఒకే డేటాబేస్‌కు అనుసంధానించిన సరళమైన క్లయింట్-వైపు పైథాన్ లైబ్రరీగా మొదలైంది. నేడు అది 500 పెటాబైట్లకుపైగా డేటాను అందించే సంక్లిష్ట విస్తృత వ్యవస్థ.

ఈ స్థాయిలో మౌలిక సదుపాయాలను నిర్మించి నిర్వహించడం చిన్న విషయం కాదు, కానీ ప్రత్యేకంగా కష్టమైనదీ కాదు. అపారమైన వినియోగదారు వృద్ధి, ఉత్పత్తి డిమాండ్‌కు మద్దతిస్తూ, అదే సమయంలో పరిపక్వ ప్లాట్‌ఫారమ్‌ను నిర్మించేందుకు మేము అపూర్వ వేగంతో విస్తరించాల్సి రావడమే మా పరిస్థితిని ప్రత్యేకం చేసింది. సాధారణంగా వ్యవస్థ ఇంజినీర్లు 10 రెట్ల స్థాయి కోసం నిర్మించి, తదుపరి 10 రెట్లకు సిద్ధమయ్యేలోపు అది కొన్నేళ్లు నిలుస్తుందని ఆశిస్తారు. మా విషయంలో గత మూడేళ్లుగా ఏటా 10 రెట్లకుపైగా వృద్ధి చెందాం. అందువల్ల హ్యాబిటాట్ నిర్మాణం, నిర్వహణ వ్యూహాత్మక నిర్ణయాల పరంపరగా సాగింది: ప్రస్తుత సాంకేతిక సముదాయం నుంచి గరిష్ఠ సామర్థ్యం పొందేందుకు ప్రతి భాగాన్ని లోతుగా అర్థం చేసుకుంటూ, పునాది పెట్టుబడులకు సమయం సంపాదించేందుకు నిల్వ, గణన సామర్థ్య కొరతలను ఎదుర్కొన్నాం.

OpenAI పెరిగేకొద్దీ హ్యాబిటాట్ కూడా పెరగాల్సి వచ్చింది: మొదట కీలక ఉత్పత్తి ట్రాఫిక్‌కు సరిపడా విశ్వసనీయంగా, తర్వాత ప్రపంచ వినియోగదారులకు సరిపడా వేగంగా, చివరకు భారీ స్థాయిలో సమర్థంగా పనిచేసేలా మారింది. ఆన్‌లైన్ నిల్వను ఎలా విస్తరించామనే రెండు భాగాల శ్రేణిలో ఇది మొదటి వ్యాసం. హ్యాబిటాట్ ఎలా పరిణామం చెందింది, దాన్ని లైబ్రరీ నుంచి సేవగా ఎందుకు మార్చాం, సేవల కోసం అరుదుగా వాడే పైథాన్‌లో రాసిన సేవను విశ్వసనీయ నిల్వ ప్లాట్‌ఫారమ్ పొరగా ఎలా విస్తరించామో ఈ వ్యాసంలో వివరిస్తాం.

భారీ స్థాయిలో బహుళ-అద్దె విశ్వసనీయతను ఎలా సాధించాం, రీడ్ పనితీరు అనుకూలీకరణకు మా పొరల వ్యూహం ఏమిటి, అపూర్వ డిమాండ్‌ను విశ్వసనీయంగా నిర్వహించేందుకు అజూర్ కాస్మోస్ DBతో భాగస్వామ్యాన్ని ఎలా విస్తరించామో తదుపరి వ్యాసంలో వివరిస్తాం.

ఉత్పత్తి ఇంజినీర్లు డేటాబేస్ నిర్వహణ గురించి ఆలోచించాల్సిన అవసరం ఉండకూడదనే సరళ ఆలోచనతో హ్యాబిటాట్ మొదలైంది. DevDay 2023లో GPTలకు మద్దతుగా, ChatGPT ప్రధాన సర్వర్‌తో పరస్పర చర్య చేసే చిన్న పైథాన్ లైబ్రరీగా హ్యాబిటాట్ మొదట ప్రారంభమైంది. అంతర్గతంగా అజూర్ కాస్మోస్ DB డేటాబేస్ అనువర్తనానికి అనుసంధానమయ్యే కొద్ది కార్యకలాపాలకు అది మద్దతిచ్చింది.

అంతర్గత వివరాల్లో నైపుణ్యం అవసరం లేకుండా డేటాను నిల్వ చేసి తిరిగి పొందేందుకు ఉత్పత్తి బృందాలకు సరళ మార్గం ఇవ్వడమే లైబ్రరీ పని. డేటా రకం ఏమిటి, అది ఎక్కడి నుంచి రావాలి లేదా ఎక్కడికి వెళ్లాలి, అభ్యర్థనకు అనుమతి ఉందా వంటి అవసరమైన పనులన్నింటినీ హ్యాబిటాట్ చూసుకుంది.

స్కీమా శోధన, రూటింగ్, అధికారీకరణ, ఎన్‌క్రిప్షన్, సీరియలైజేషన్, అభ్యర్థన రూపకల్పన, కనెక్షన్ పూలింగ్ గురించి ఉత్పత్తి ఇంజినీర్లు ఆలోచించాల్సిన అవసరం లేదు. డేటా అజూర్ కాస్మోస్ DB, క్యాష్‌లు లేదా ఇతర నిల్వలలో ఎక్కడి నుంచి వస్తుందో కూడా వారు పరిగణించాల్సిన అవసరం లేదు.

స్వీయ-సేవ పోస్ట్‌గ్రెస్, అజూర్ కాస్మోస్ DB వాడకాన్ని మాన్పించేందుకు కేంద్రీకృత ప్రయత్నం లేకపోయినా, ఈ పైథాన్ లైబ్రరీ బాగా పనిచేసి OpenAI ఉత్పత్తి ఇంజినీర్లలో హ్యాబిటాట్ వేగంగా ప్రాచుర్యం పొందింది.

ఉత్పత్తి అవసరాలు మారేకొద్దీ, క్లయింట్-వైపు క్యాషింగ్, కుదింపు, ఎన్‌క్రిప్షన్ వంటి సదుపాయాల మద్దతును భాగస్వామ్య లైబ్రరీకి జోడించడం కూడా డెవలపర్లకు సులభంగా ఉండేది.

2025 మధ్య నాటికి క్లయింట్-వైపు అమలుగా హ్యాబిటాట్ తన పరిమితులను చేరుకుంది. హ్యాబిటాట్ పొర సంక్లిష్టమై, OpenAI సేవల సంఖ్య పెరగడంతో వెనుకకు అనుకూలమైన ప్రోటోకాల్ మార్పులు అసాధ్యమయ్యాయి.

ఒక సందర్భంలో, అత్యంత కీలక డేటా సమితులను ప్రాంతాలవారీగా విస్తరించిన అజూర్ కాస్మోస్ DB ఖాతాలకు మార్చి, ఏదైనా ఒక ప్రాంత అంతరాయం ప్రభావ పరిధిని తగ్గించాలనుకున్నాం. ఈ మార్పు కోసం క్లయింట్‌లో అదనపు రూటింగ్ తర్కాన్ని ఫీచర్ ఫ్లాగ్ వెనుక నిలిపిన స్థితిలో జోడించి, అన్ని క్లయింట్లకు విడుదలైనట్లు నిర్ధారించి, ఆపై ఫ్లాగ్‌ను ప్రారంభించాల్సి వచ్చింది.

డజన్ల కొద్దీ సేవల్లో అమలులను సమన్వయం చేసి, ప్రతి బృందంతో కలిసి విడుదల చేయడానికి రోజుల సమయం పట్టింది. దీన్ని ప్రారంభించేముందు, షార్డింగ్ తర్కం సరిగ్గా ఉందని నిర్ధారించేందుకు కొంత షాడోయింగ్ జోడించాలని గ్రహించాం. దాన్ని విడుదల చేయడానికి మరో రెండు రోజులు పట్టింది. తప్పుగా ఉందని గుర్తించిన అంశానికి బగ్ పరిష్కారమా? మరో రెండు రోజులు. చివరకు ఫ్లాగ్‌ను ప్రారంభించేందుకు సిద్ధమయ్యాం. కానీ ఒక బృందం సంబంధంలేని కారణాలతో తమ సేవను గతంలో బగ్ ఉన్న క్లయింట్‌కు వెనక్కి మార్చింది. దాంతో మేము ఎంతో కష్టపడి నివారించాలనుకున్న అంతరాయమే ఏర్పడింది.

క్లయింట్ లైబ్రరీ మార్పులకు డజన్ల కొద్దీ సేవల మధ్య సంక్లిష్ట సమన్వయం అవసరమైంది. ఈ ప్రక్రియ క్రమంగా బలహీనంగా, అసమర్థంగా, నిర్వహణ వైఫల్యాలకు లోనయ్యేదిగా మారింది. భవిష్యత్తు అమలుల్లో ఈ నిర్వహణ విస్తరణను తగ్గించేందుకు హ్యాబిటాట్‌ను ప్రత్యేక సేవగా మార్చాలని నిర్ణయించాం.

నిల్వ తర్కాన్ని స్వతంత్ర సేవగా వేరుచేయడం ద్వారా అమలులు, పరిశీలనీయత, ప్లాట్‌ఫారమ్ మెరుగుదలలకు ఒకే నియంత్రణ కేంద్రాన్ని ఏర్పాటు చేశాం. విభిన్న నవీకరణలను విడిగా నిర్వహించకుండా, మెరుగుదలలను కేంద్రీకృతంగా అమలు చేసి ప్రతి OpenAI ఉత్పత్తికి తక్షణ ప్రయోజనాలు అందించగలిగాం.

అత్యంత బలమైన డేటా భద్రత, గోప్యత మౌలికాలను అందించేందుకు కేంద్రీకృత సేవ ఒకే నియంత్రణ బిందువును కూడా ఇస్తుంది. యాక్సెస్ నియంత్రణ విధానాలను కేంద్రీకృతంగా అమలు చేయడానికి, ఆడిట్ లాగింగ్ నిర్వహించడానికి, అజూర్ కాస్మోస్ DB వంటి అంతర్గత నిల్వ వనరుల ప్రాప్యతను పరిమితం చేయడానికి హ్యాబిటాట్ సేవ ఉపయోగపడుతుంది. వినియోగదారు డేటాను రక్షించడంలో, బాహ్య, అంతర్గత, ఏజెంట్ పాత్రధారుల అనధికార ప్రాప్యతను అడ్డుకోవడంలో హ్యాబిటాట్ కీలక పాత్ర పోషిస్తుంది.

మాకు ఒక సేవ అవసరమని తెలుసు. అయితే, సేవగా పైథాన్‌కు అదనపు భారం ఉన్నప్పటికీ, అప్పుడే దాని నుంచి మారాలని అనుకోలేదు. అధిక థ్రూపుట్ సేవకు పైథాన్‌ను ఉపయోగించడం వల్ల స్థానిక లైబ్రరీ అమలుతో పోలిస్తే నెట్‌వర్క్ ఆలస్యం, CPU మరియు మెమరీ స్కేలింగ్ ఖర్చులు గణనీయంగా పెరిగాయి. పైగా, 100 రెట్లు ఎక్కువ స్థాయిలో పైథాన్ అసమర్థతలు ఆమోదయోగ్యం కావని గుర్తించాం. అందువల్ల చివరకు తిరిగి రాయడం దాదాపు ఖాయమైంది.

అయితే, దీన్ని సాంకేతిక రుణాన్ని వ్యూహాత్మకంగా స్వీకరించడంగా చూశాం. అప్పుడు మా ప్రధాన లక్ష్యం ఖర్చు లేదా వనరుల అనుకూలీకరణ కాదు. ఉత్పత్తి డెవలపర్లకు అడ్డంకులు తొలగించి, ప్లాట్‌ఫారమ్ స్థిరత్వాన్ని సాధించడం. స్వల్పకాలంలో పైథాన్ సేవ పనితీరు పరిమితులను అంగీకరించడం వల్ల తక్షణ సవాళ్లకు ప్రాధాన్యమిచ్చి, ప్రధాన APIలను స్థాపించి, దృఢమైన మౌలిక సదుపాయాలను నిర్మించగలిగాం.

మా సొంత కోడింగ్ మోడళ్ల వేగవంతమైన పురోగతి భవిష్యత్తులో సాంకేతిక మార్గాన్ని సులభతరం చేస్తుందని కూడా లెక్కగట్టి పందెం వేశాం. పైథాన్ నుంచి పూర్తిగా మారాల్సిన సమయానికి Codex, GPT ఆ మార్పును సాధ్యం చేస్తాయని నమ్మాం. చివరకు ఆ అంచనా నిజమైంది.

పనితీరు పరంగా హ్యాబిటాట్‌ను పైథాన్ సేవగా నడపడం ఉత్తమం కాదు, కానీ అది అవసరమైన ఎంపిక. పైథాన్‌తో వేగంగా ముందుకు వెళ్లగలం. అంతమాత్రాన జాగ్రత్తను పక్కనపెట్టి, గణనీయంగా అధిక ఆలస్యాలను అంగీకరించలేం. సగటు వినియోగదారు అభ్యర్థన వందలాది డేటాబేస్ కాల్‌లకు దారితీసినప్పుడు, అత్యంత నెమ్మదైన కాల్ ఆలస్యమే వినియోగదారుకు అనిపిస్తుంది. ఈ స్థాయిలో పైథాన్ సేవను నడపడంలో ప్రధాన సవాలు చివరి అంచు ఆలస్యాలను నిర్వహించడమేనని గుర్తించాం.

I/O ఆధారిత పనులను ఏకకాలంలో అమలు చేయడానికి అసింకియో పైథాన్‌కు తోడ్పడుతుంది. కానీ పైథాన్ GIL పరిమితిని అధిగమించి CPU సమాంతరతను అందించదు. I/O అధికంగా ఉండే అభ్యర్థన ప్రాక్సీయింగ్‌తో పాటు, హ్యాబిటాట్ అనేక CPU-భారీ బాధ్యతలు, నేపథ్య పనులను నిర్వహిస్తుంది: రూటింగ్, కుదింపు, ఎన్‌క్రిప్షన్, చెక్‌సమ్ లెక్కింపు, దిగువ వ్యవస్థల ఆరోగ్య తనిఖీ, అభ్యర్థన షాడోయింగ్, హెడ్జింగ్.

మా సేవలో ఇన్ని CPU-భారీ పనులు, నేపథ్య విధులు ఉండటంతో అసింకియో షెడ్యూలింగ్ ఆలస్యం చివరి అంచు అభ్యర్థన ఆలస్యాన్ని సులభంగా అధిగమించగలదు. తొలి సేవ ప్రారంభానికి ముందు సర్దుబాటు చేస్తుండగా, p99 లేదా అంతకంటే ఎక్కువ ఆలస్యమున్న అభ్యర్థన ట్రేస్‌లలో దిగువ నిల్వ వేగంగా స్పందించినా, ప్రతిస్పందనను పార్స్ చేసే కొరూటీన్ మళ్లీ షెడ్యూల్ అయ్యే వరకు అభ్యర్థనలు తరచూ నిలిచిపోవడం చూశాం.

OpenAIలో పైథాన్ సేవలకు మెమరీ, CPU, నెట్‌వర్క్, డిస్క్ వినియోగంపై సాధారణ వినియోగం, సంతృప్తి కొలమానాలతో పాటు అసింకియో లూప్‌ను, దాని రద్దీని పర్యవేక్షించి తగినట్లు సర్దుబాటు చేయడం కీలకం.

నేపథ్య పనులను క్రమానుగతంగా షెడ్యూల్ చేసి, ఊహించిన అమలు సమయానికి వాస్తవ సమయానికి మధ్య తేడాను నమోదు చేయడం ద్వారా ఈవెంట్ లూప్ షెడ్యూలింగ్ ఆలస్యాన్ని నిజ సమయంలో ప్రత్యక్షంగా కొలుస్తాం. అధిక వినియోగంలో ఖరీదైన పనులు అనేకం ఉంటే, ఒక్కో ప్రాసెస్‌కు కొద్ది ఏకకాల అభ్యర్థనలే వందల మిల్లీసెకన్లు, కొన్ని అరుదైన సందర్భాల్లో సెకన్లపాటు షెడ్యూలింగ్ హెచ్చుతగ్గులను కలిగిస్తాయి.

అందువల్ల ఒక్కో ప్రాసెస్ కొద్ది ఏకకాల అభ్యర్థనలనే నిర్వహించేలా ఉంచి, పైథాన్ వర్కర్ ప్రాసెస్‌ల సంఖ్యను భారీగా పెంచాం.

తొలి సేవ ప్రారంభంలో ప్రత్యక్ష CPU ప్రొఫైలింగ్ ద్వారా అధిక అసింకియో ఆలస్యానికి, తద్వారా అధిక చివరి అంచు ఆలస్యాలకు ఒక మూలకారణాన్ని కనుగొన్నాం: స్టాట్‌సిగ్ ద్వారా మా ఫీచర్ ఫ్లాగ్ కాన్ఫిగరేషన్‌లను క్రమానుగతంగా JSON పార్స్ చేయడం. స్టాట్‌సిగ్ ఫీచర్ ఫ్లాగ్‌లను నిర్వహించి, A/B పరీక్షలు తదితరాలకు ఉపయోగపడే సాధనం.

డిఫాల్ట్‌గా స్టాట్‌సిగ్ ఎలాంటి హెచ్చుతగ్గులు లేకుండా ప్రతి నిమిషం తాజా కాన్ఫిగరేషన్‌ల కోసం తనిఖీ చేసేది. ఆ కాన్ఫిగరేషన్‌లో ప్రతి సేవకు చెందిన ఉత్పత్తి నియమాలన్నీ ఉండేవి. మరోచోట, CPU వినియోగాన్ని పెంచి ఆలస్యాలను తగ్గించడానికి ఒక్కో పాడ్‌లో గరిష్ఠంగా 8 పైథాన్ ప్రాసెస్‌లు నడపాలని నిర్మాణాత్మక నిర్ణయం తీసుకున్నారు. దీంతో ప్రతి నిమిషంలో ఏదో ఒక సమయంలో ఒక్కో పాడ్‌లోని వర్కర్లన్నీ కొనసాగుతున్న అభ్యర్థనల ప్రాసెసింగ్‌ను ఆపి, భారీ కాన్ఫిగరేషన్ ఫైలును పార్స్ చేయడానికి CPU చక్రాలను వెచ్చించేవి.

CPU ప్రొఫైలింగ్‌తో మూలకారణం తెలిసిన తర్వాత పరిష్కారం సూటిగా ఉంది: చిన్న లక్ష్యిత కాన్ఫిగరేషన్‌ను అమలు చేయడం, తాజాకరణ విరామాన్ని పెంచడం, ఇలాంటి నేపథ్య పనులకు కొంత సమయ వైవిధ్యం జోడించడం.

అసింకియో ఆలస్యాన్ని తక్కువగా ఉంచేందుకు సర్వర్ ప్రాసెస్‌లలో అభ్యర్థనలను సమంగా పంచడం కూడా కీలకం. సర్దుబాటు లేకుంటే కనెక్షన్ పూలింగ్ దీనికి విరుద్ధంగా మారవచ్చు.

క్లయింట్-వైపు కనెక్షన్ పూలింగ్‌లో అనేక ఏకకాల అభ్యర్థనలు చేసే ఒక క్లయింట్ ప్రాసెస్ కొద్ది సర్వర్ కనెక్షన్లనే ఏర్పాటు చేసి, తన మొత్తం లోడ్‌ను కొద్ది ప్రాసెస్‌లకే పంపవచ్చు. లోడ్ బ్యాలెన్సింగ్ విధానాన్ని సర్దుబాటు చేయకముందు మా సేవలో వినియోగం విస్తృతంగా మారేది. కొన్ని చివరి ప్రాసెస్‌లు సగటుతో పోలిస్తే 5–10 రెట్లు ఎక్కువ ఏకకాల అభ్యర్థనలను నిర్వహించేవి.

మా సేవలో ఒక భాగాన్ని అధిక భారానికి గురిచేసిన క్లయింట్‌ను నిలిపివేసినా, ఆకస్మిక ట్రాఫిక్ ముగిసిన చాలాసేపటి తర్వాత కూడా కొన్ని ప్రాసెస్‌లు క్షీణించిన స్థితిలోనే ఉన్న ఒక యాదృచ్ఛిక ఘటనలో దీన్ని కనుగొన్నాం. వాస్తవానికి, ఆ ప్రాసెస్‌ల పనితీరు అదుపు తప్పి క్షీణించిందని గమనించాం. వాటిని పునఃప్రారంభించే వరకు అవి మరింత ఎక్కువ అభ్యర్థనలను అందుకుంటూనే ఉన్నాయి. ఒక పాడ్ అధిక భారానికి గురయ్యాక, ఏదో ప్రవర్తన మరింత ట్రాఫిక్‌ను అదే పాడ్‌కు కట్టిపడేసేది. మా సహచరుల్లో కొందరికి గత పని నుంచి బాగా పరిచయమైన వైఫల్యాల తరగతి ఇది: మెటాస్టేబుల్ వైఫల్యం⁠(కొత్త విండోలో తెరుచుకుంటుంది).

కనెక్షన్ పూల్‌దే తప్పని అనుమానించాం. గరిష్ఠ కనెక్షన్ పునర్వినియోగ వ్యవధిని పరిమితం చేసి పరీక్షించగా క్షీణత నిజంగానే తగ్గింది; మా దర్యాప్తు దిశ సరైనదని నిర్ధారణ అయింది. పైథాన్ aiohttp TCPConnector డిఫాల్ట్‌గా LIFO కనెక్షన్ పునర్వినియోగాన్ని వాడుతుందని తదుపరి దర్యాప్తులో తెలిసింది: ఇటీవల తిరిగివచ్చిన కనెక్షన్‌నే తదుపరి అభ్యర్థనకు ఎంచుకుంటుంది. సాధారణంగా ఇది సమంజసమైన డిఫాల్ట్. ఇటీవలి కనెక్షన్ల పునర్వినియోగం ఆకస్మిక ట్రాఫిక్ కోసం సృష్టించిన అదనపు కనెక్షన్లు నిష్క్రియ గడువు ముగిసేలా చేసి, వాటి నిర్వహణ భారాన్ని తగ్గిస్తుంది. ఈ సందర్భంలో అది మాకు మెటాస్టేబుల్ వైఫల్యాన్ని కలిగించింది. అభ్యర్థనల ఆకస్మిక రద్దీలో నెమ్మదైన, అధిక భారమున్న సర్వర్లకు వెళ్లిన అభ్యర్థనలు కనెక్షన్లను పూల్‌కు ఆలస్యంగా తిరిగి పంపాయి. అందువల్ల తదుపరి అభ్యర్థనలు వాటినే ఎక్కువగా ఎంచుకుని, ఇప్పటికే ఇబ్బందిపడుతున్న పాడ్‌లపై ట్రాఫిక్‌ను క్రమంగా కేంద్రీకరించాయి. FIFO పునర్వినియోగం వాడేలా కనెక్షన్ పూల్‌ను సవరించడం ఈ ప్రతిపుష్టి చక్రాన్ని విచ్ఛిన్నం చేసి, స్థిర స్థితిలో అభ్యర్థన వ్యత్యాసాన్ని కూడా తగ్గించింది.

నేడు OpenAI మౌలిక సదుపాయాలంతటా కనెక్షన్ పూలింగ్, సర్వర్ లోడ్‌ను మెరుగ్గా పరిగణించే బ్యాలెన్సింగ్ వ్యూహాల కోసం ప్రధానంగా ఇస్టియో, ఎన్వాయ్‌పై ఆధారపడి ఈ సమస్యను పూర్తిగా నివారిస్తున్నాం.

తక్కువ అసింకియో ఆలస్యం కోసం సర్దుబాటు చేయడం, ఇన్ని పైథాన్ ప్రాసెస్‌లు ఉండటం వల్ల భారీ సంఖ్యలో కనెక్షన్లతో దిగువ ఆధారిత వ్యవస్థలను సులభంగా ముంచెత్తవచ్చు. దీన్ని “ఒక్కసారిగా దూసుకొచ్చే మంద” అంటారు.

సాధారణ రోజువారీ అమలును నెమ్మదిగా జరిగేలా సర్దుబాటు చేయకపోతే, కనెక్షన్ల మార్పిడి వల్ల గణనీయమైన CPU ఒడిదుడుకులు ఏర్పడవచ్చు. లేదా కనెక్షన్ లీక్ NAT గేట్‌వేను సంతృప్తిపరచి నెట్‌వర్క్‌ను నిలిపివేయవచ్చు. ఇతర సేవలకూ ఇవి అసాధారణ సమస్యలు కావు. కానీ ప్రాసెస్‌లు పదింతలు ఎక్కువగా ఉండటం వల్ల ఇవి తలెత్తే పరిమితి గణనీయంగా తగ్గుతుంది. కేవలం థ్రూపుట్ ఆధారంగా స్థిర స్థితిలో నిర్వహించాల్సి వస్తుందని క్లయింట్లు ఊహించని నెట్‌వర్క్ వనరులు తరచూ సంతృప్తమవుతాయి.

కనెక్షన్ సమీకరణను గరిష్ఠం చేసేందుకు ఎన్వాయ్‌పై కూడా ఆధారపడతాం. మల్టీప్లెక్సింగ్ ప్రయోజనం పొందేందుకు పైథాన్ HTTP/1 కనెక్షన్లను HTTP/2కు ఉన్నతీకరించి, ఆ కనెక్షన్లను పూల్ చేసి వాటి జీవితకాలాన్ని పొడిగించేందుకు దీన్ని ఉపయోగిస్తాం. ప్రతి స్వతంత్ర పైథాన్ ప్రాసెస్‌లో తక్కువ ప్రభావవంతంగా ఉండే రేటు పరిమితులు, సర్క్యూట్ బ్రేకర్లను అమలు చేయడానికి ఎన్వాయ్ ఒక కేంద్రీకృత స్థానాన్ని కూడా అందిస్తుంది.

పైథాన్‌ను ఇంత స్థాయికి విస్తరించగలగడానికి ఒక కారణం హ్యాబిటాట్ పరిమిత API. ఇది అభ్యర్థన ఖర్చును ఊహించదగినదిగా ఉంచుతుంది. భారీ పట్టిక స్కాన్‌లు లేదా అనేక పట్టికల మధ్య జాయిన్‌లకు దారితీసే ఏకపక్ష SQL క్వెరీలను క్లయింట్లు రూపొందించడానికి అనుమతించకుండా, హ్యాబిటాట్ సరళమైన NoSQL APIని అందిస్తుంది. శక్తిమంతమైన API లేకపోవడం హ్యాబిటాట్ రూపకల్పనలో ఉద్దేశపూర్వకంగా అంగీకరించిన పరిమితి.

సరళమైన, ఊహించదగిన, స్థిరమైన పని అవసరమయ్యే అభ్యర్థనలకు అనుకూలీకరించడమే మా లక్ష్యం. మా అనుభవంలో, ఈ వ్యవస్థలను విస్తరించడం చాలా సులభం; తప్పుగా ఉపయోగించడం కష్టం. ఊహించలేని విస్తరణగల అభ్యర్థనలు నిర్వహణపరంగా ప్రమాదకరం. అవి వేరుచేయడం, లోడ్ బ్యాలెన్సింగ్‌ను క్లిష్టం చేసి, సేవకు మరియు క్లయింట్లకు స్కేల్ చేయడం కష్టమైన ఆకస్మిక ఆలస్యాలను తెస్తాయి.

హ్యాబిటాట్, అజూర్ కాస్మోస్ DBలకు మారకముందు OpenAI ఆన్‌లైన్ డేటాలో ఎక్కువ భాగం పోస్ట్‌గ్రెస్‌లో నిల్వ ఉండేది. అప్పుడు ఉత్పత్తికి పంపేముందు అన్ని క్వెరీ, స్కీమా మార్పులను సమీక్షించి, అవి సక్రమంగా పనిచేస్తూ సూచీకృత డేటాపైనే నడుస్తున్నాయని నిర్ధారించడం సులభంగా ఉండేది. బృందం, ఉత్పత్తులు పెరిగేకొద్దీ ఇది త్వరగా నిర్వహించలేనిదిగా మారింది. తరచూ కీలక మార్గంలోని ఒక్క ఖరీదైన కొత్త క్వెరీ డేటాబేస్‌ను నిలిపివేసి అంతరాయాలకు కారణమైంది.

ఇక్కడ సమస్య ఖర్చులో అసమతుల్యత: అమలు చేయడం ఖరీదైన, కష్టమైన SQL క్వెరీలను రాయడం చౌక, సులభం. హ్యాబిటాట్‌లో దీన్ని నివారించి, ఖరీదైన క్వెరీలను క్లయింట్ వైపు అత్యంత స్పష్టంగా కనిపించేలా చేస్తాం. హ్యాబిటాట్‌ను అధిక భారానికి గురిచేసే అపరిమిత క్వెరీలు లేవు. సంక్లిష్ట జాయిన్‌లు, గ్రాఫ్ ట్రావర్సల్‌లలో ఉత్పత్తి బృందాలే కొంత కఠిన పని చేయాలి. ఇది మరింత సమర్థమైన రూపకల్పనలకు మొత్తంగా దోహదపడుతుంది.

TAO⁠(కొత్త విండోలో తెరుచుకుంటుంది) స్ఫూర్తితో, క్లయింట్ నిర్వచించిన ఆబ్జెక్ట్, ఎడ్జ్ రకాల చుట్టూ రూపొందించిన NoSQL APIని హ్యాబిటాట్ అందిస్తుంది. క్లయింట్లు ఆబ్జెక్టులు, ఎడ్జ్‌లు, వాటి పరస్పర సంబంధాలను ముందే నిర్వచిస్తారు. కానీ ప్రతి రకంలోని విషయాన్ని కాదు. ఫలిత సంబంధాలు గ్రాఫ్‌ను పోలి ఉంటాయి. అయితే ఒక నిర్దిష్ట ఆబ్జెక్ట్ ప్రత్యక్ష ఎడ్జ్‌ల క్వెరీ మినహా, సాధారణ గ్రాఫ్ ట్రావర్సల్ క్వెరీలకు హ్యాబిటాట్ మద్దతివ్వదు.

ప్రతి ఆబ్జెక్ట్, దాని ఎడ్జ్‌లు నిల్వ-స్థాయి విభజనలో కలిసి ఉండేలా ఈ గ్రాఫ్‌ను విభజిస్తాం. కానీ ఆబ్జెక్టులు, వాటి ఎడ్జ్‌లు సూచించే దూర ఆబ్జెక్టులను కలిసి ఉంచడానికి డేటాబేస్ స్థాయిలో ప్రత్యేక ప్రయత్నం చేయం. ఫలితంగా మోడల్‌ను అడ్డంగా సులభంగా విభజించి విస్తరించవచ్చు. కానీ ఆబ్జెక్టుల మధ్య ఏ దశకైనా వేర్వేరు ప్రాంతాల్లోని రెండు పూర్తి భిన్న అజూర్ కాస్మోస్ DB ఖాతాల నుంచి డేటా తీసుకురావాల్సి రావచ్చు కాబట్టి గ్రాఫ్ ట్రావర్సల్‌లు అసమర్థంగా ఉంటాయి.

మరింత సంక్లిష్ట క్వెరీ అవసరాలున్న క్లయింట్లకు రాక్‌సెట్ ద్వారా అందుబాటులో ఉండే హ్యాబిటాట్ ఆఫ్‌లైన్ ద్వితీయ వీక్షణను అందిస్తాం. ఆన్‌లైన్ నిల్వలోని మార్పులను దాదాపు నిజ సమయంలో వేరుచేసిన రాక్‌సెట్ ఇన్‌స్టాన్స్‌లకు ప్రసారం చేయడానికి మార్పు డేటా సంగ్రహణను ఉపయోగిస్తాం. సంక్లిష్ట క్వెరీ అవసరాలకు తమ సొంత రాక్‌సెట్ ఇన్‌స్టాన్స్‌ను విస్తరించే బాధ్యత ప్రతి క్లయింట్ బృందానిదే.

రాక్‌సెట్ కేటాయింపు క్లయింట్లకు అదనపు ఇబ్బందిని కలిగిస్తుంది. అయినా ప్రస్తుతం ఇది సరైన సమతుల్య నిర్ణయమని భావిస్తున్నాం: సరళ క్వెరీలను డిఫాల్ట్‌గా ఉంచుతూ, సంక్లిష్ట క్వెరీలు అవసరమైనవారికి ప్రత్యామ్నాయం అందించడం. ఈ రూపకల్పన మా ఆన్‌లైన్ నిల్వను అధిక రీడ్ అవసరమయ్యే విశ్లేషణ, శోధన పనిభారాల నుంచి వేరుచేస్తుంది.

పైథాన్‌ను తిరిగి రాయడాన్ని ఏడాది వాయిదా వేయడంతో మా అతివేగ వృద్ధి సమయంలో మరింత అత్యవసరమైన, ప్రభావవంతమైన సవాళ్లపై దృష్టి పెట్టగలిగాం. ప్లాట్‌ఫారమ్ పరిపక్వమవుతూ, వృద్ధి వేగం పెరుగుతుండగా, కోర్‌ల సంఖ్యలో OpenAIలో రెండో అతిపెద్ద సేవగా, ఎన్వాయ్ విస్తృతిలో నాలుగో స్థానంలో ఉన్న మాకు చివరకు పైథాన్‌ను దాటాల్సిన సమయం వచ్చింది. గరిష్ఠ స్థాయిలో పైథాన్ సెకనుకు 2 కోట్లకుపైగా అభ్యర్థనలను నిర్వహించడంలో తోడ్పడింది.

2026 రెండో త్రైమాసికంలో కేవలం ఇద్దరు ఇంజినీర్లు, Codex, GPT‑5.5తో మొత్తం సేవను రస్ట్‌లో తిరిగి రాయగలిగాం. ఈ కొత్త రస్ట్ సేవ ఇప్పుడు మా ఉత్పత్తి అభ్యర్థనల్లో 95% నిర్వహిస్తోంది. రాబోయే వారాల్లో పైథాన్‌ను పూర్తిగా విరమిస్తాం. పైథాన్ సంస్కరణతో పోలిస్తే రస్ట్ సేవ CPUలో 6 రెట్లు, మెమరీలో 15 రెట్లు సమర్థవంతమని మా డేటా చూపుతోంది. సగటు, చివరి అంచు ఆలస్యాలు కూడా గణనీయంగా తక్కువ. భవిష్యత్తు బ్లాగ్‌లో మరిన్ని పాఠాలను పంచుకుంటాం.

పైథాన్, ఇప్పుడు రస్ట్ సేవ హ్యాబిటాట్‌లో ఒక కోణం మాత్రమే. 100 కోట్లకుపైగా ChatGPT వినియోగదారులకు సేవలందించేందుకు ఆన్‌లైన్ నిల్వను వేగంగా ఎలా విస్తరించామో వివరించే ఈ శ్రేణి రెండో భాగంలో, నిల్వ పొర గురించి, హ్యాబిటాట్ 500 పెటాబైట్లకుపైగా డేటాను, సెకనుకు 7 కోట్లకుపైగా అభ్యర్థనలను ఎలా నిర్వహిస్తుందో చర్చిస్తాం.

మీరు అత్యాధునిక స్థాయిలో OLTP వ్యవస్థలపై పనిచేయాలని, ఇలాంటి ఇంజినీరింగ్‌పై ఆసక్తి కలిగి ఉంటే, మా బృందంలోని ఈ ఖాళీ ఉద్యోగాన్ని చూడండి⁠.