100 కోట్లకు పైగా ChatGPT వినియోగదారుల కోసం వేగంగా ఆన్‌లైన్ నిల్వ విస్తరణ (భాగం 2)

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

సాధారణ క్లయింట్ లైబ్రరీ, డేటాబేస్‌గా మొదలైన Habitatను 500 పెటాబైట్లకు పైగా డేటాను అందించే ప్రపంచవ్యాప్త పంపిణీ నిల్వ వేదికగా ఎలా తీర్చిదిద్దామో ఈ రెండు భాగాల శ్రేణి వివరిస్తుంది. Habitat ఒక Python క్లయింట్ నుంచి సేవగా ఎలా పరిణమించిందో భాగం 1లో వివరించాం. Python ఆధారిత సేవను చాలామంది ఆచరణ సాధ్యమని భావించే హద్దులకు మించి విస్తరించడానికి తోడ్పడిన పద్ధతులనూ అందులో చర్చించాం.

ఈ భాగం 2లో, అంతర్లీన నిల్వ భాగమైన 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 ఇంజినీరింగ్ బృందాలు మా సేవా పొరల నుంచి Azure Cosmos DB భౌతిక నిల్వ పొరల వరకు Habitatలోని ప్రతి పొరనూ సంయుక్తంగా పర్యవేక్షిస్తాయి. ప్రత్యక్ష సేవల్లో వాడనిదైనా వాటితో సమాన పరిమాణం ఉన్న Azure Cosmos DB ఖాతాలో మార్పులను అమలు చేసి పరీక్షిస్తాం. SDKలను కలిసి పరీక్షించి మెరుగుపరుస్తాం. మా Azure Cosmos DB ఖాతాల విస్తరణ, పరిమాణ నిర్ణయానికి ఉత్తమ పద్ధతులను నిర్ధారిస్తాం. Teams ద్వారా పరస్పరం నేరుగా ఇంజినీరింగ్ బృందాలను సంప్రదించగలం. సపోర్ట్ అంచెల ద్వారా వెళ్లకుండా నేరుగా అత్యవసర హెచ్చరికలు పంపే మార్గాలనూ ఏర్పాటు చేశాం.

గత ఏడాదిగా Azure Cosmos DB నియంత్రణ వ్యవస్థ, గేట్‌వే విస్తరణ సామర్థ్యాన్ని పెంచేందుకు సంయుక్తంగా ఎంతో కృషి చేశాం. మెటాడేటా విభజన భాగాన్ని రక్షించేందుకు గేట్‌వేలో లోడ్ రక్షణ, వివిధ మెటాడేటా కాషింగ్‌ను జోడించాం. కనెక్షన్ పూలింగ్, కనెక్షన్ల పునర్వినియోగంతో మా Python habitat-service ప్రక్రియల సమూహం కలిగించే ఒత్తిడిని తగ్గించాం. వీలైన చోట పనిభారాలను ఒకే ప్రాంతంలో ఉంచి, వేర్వేరు VPCలతో కీలక పనిభారాలను ఆఫ్‌లైన్ పనిభారాల నుంచి వేరుచేశాం.

గత ఏడాది మా Azure Cosmos DB స్థిరత్వానికి ఈ స్థాయి సంయుక్త ఇంజినీరింగ్ కీలకమైంది. పెద్దదైన లేదా కీలకమైన ఏ వ్యవస్థకైనా ఇలాంటి సమష్టి కృషి అవసరం: బాధ్యతల చుట్టూ గోడలు కట్టుకోకుండా, సంస్థాగత హద్దులను దాటి కలిసి పనిచేయాలి.

భాగం 1లో చెప్పినట్లుగా, మా మూల సూత్రం: ముందు పనిచేసేలా చేయాలి, ఆపై వేగం పెంచాలి, చివరగా ఖర్చు తగ్గించాలి. ముందు విశ్వసనీయత, తర్వాత పనితీరు, ఆ తర్వాత వనరుల సమర్థ వినియోగం. Habitat, OpenAIకి కీలక మౌలిక వ్యవస్థగా మారింది కాబట్టి దాన్ని విశ్వసనీయంగా చేయడమే తొలి ప్రాధాన్యమైంది. 2025లో వ్యవస్థ స్థిరపడి, OpenAI ప్రపంచవ్యాప్తంగా విస్తరించడంతో, ప్రతిస్పందన జాప్యం వినియోగదారులకు, ఉత్పత్తి బృందాలకు తదుపరి అడ్డంకిగా మారింది.

కంప్యూటింగ్, నిల్వ సామర్థ్యాలు తరచూ వేర్వేరు ప్రాంతాల్లో ఉండటంతో ప్రాంతాల మధ్య అభ్యర్థనలు తప్పనిసరయ్యాయి.

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

2026లో దీనిపైనే ప్రధానంగా దృష్టి పెట్టాం. Habitat అభ్యర్థనల్లో 90%కు పైగా ఉండే రీడ్‌ల పనితీరు మెరుగుదలకు అంచెల వ్యూహాన్ని రూపొందించాం:

డేటా రెసిడెన్సీ అవసరాలున్న వినియోగదారుల కోసం ప్రపంచవ్యాప్తంగా వివిధ Azure ప్రాంతాల్లో మాకు పలు Azure Cosmos DB ఖాతాలు ఉన్నాయి. కచ్చితమైన డేటా రెసిడెన్సీ అవసరాలు లేనివారికీ డేటాను దగ్గరగా ఉంచడం వల్ల జాప్యం తగ్గి, వినియోగ అనుభవం మెరుగవుతుంది.

అయితే భౌతిక క్లౌడ్ సామర్థ్యం డేటా ఉంచే చోటును పరిమితం చేస్తుంది. అందువల్ల డేటా రెసిడెన్సీ అవసరాలకు మించి దీన్ని విస్తృతంగా అమలు చేయలేకపోతున్నాం. మా డేటా సమితులు ఎంతో పెద్దవి. చాలా ప్రాంతాలు తమ వాటా వినియోగదారుల ట్రాఫిక్‌కు అవసరమైన భారీ నిల్వను సమకూర్చలేవు.

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

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

ప్రతి అభ్యర్థనకూ అవసరమైన ప్రామాణీకరణ మెటాడేటా వంటి, జాప్యం అతి కీలకమైన పనిభారాల కోసం అనేక ద్వితీయ ప్రాంతాలకు ప్రతిరూపించే Azure Cosmos DB ఖాతాలను వాడతాం. దీంతో కంప్యూటింగ్, Habitat మధ్య రానూపోనూ పట్టే సమయం తగ్గుతుంది. కొన్ని ఖాతాలు మేం ట్రాఫిక్‌ను నిర్వహించే మొత్తం 40 Azure ప్రాంతాలకు ప్రతిరూపిస్తాయి; మరికొన్ని ప్రతి ఖండంలో కనీసం ఒక ప్రాంతానికి ప్రతిరూపిస్తాయి.

వేర్వేరు ప్రతిరూపణ అమరికలున్న ఖాతాల మధ్య డేటా సమితులను తరలించేందుకు, అనుకున్నదానికంటే ముందే Habitatలో క్లయింట్లకు కనిపించకుండా పనిచేసే డేటా తరలింపు, రూటింగ్ పొరను నిర్మించాల్సి వచ్చింది.

అయితే ఈ విధానానికీ చివరికి సామర్థ్య పరిమితి ఉంది. అందుకే జాగ్రత్తగా ఎంచుకున్న కొన్ని డేటా సమితులకే దీన్ని పరిమితం చేశాం.

Habitat పనిభారాల్లో డేటా చదవడమే అత్యధికం. అప్లికేషన్లు నిరంతరం సెట్టింగ్‌లు, స్థితి, ఇతర లక్షణాలను తెచ్చుకుంటాయి. తరచూ వాడే కొద్ది రకాల డేటా నుంచే ట్రాఫిక్‌లో అత్యధిక భాగం వస్తుంది. దీంతో ఈ వ్యవస్థ పంపిణీ కాషింగ్‌కు ఎంతో అనువుగా ఉంటుంది. ఒకే ప్రాంతపు మౌలిక వ్యవస్థలో కాషింగ్ పనితీరును పెంచుతుంది. ప్రాంతాల మధ్య పనిచేసేటప్పుడు ఆ ప్రయోజనం మరింత పెరుగుతుంది: ప్రాంతాంతర జాప్యాన్ని వినియోగదారుకు “కనిపించకుండా” చేయగలదు.

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

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

Metaకు చెందిన TAO వంటి వ్యవస్థలను అనుసరిస్తూ, కాష్ ప్రతులను చెల్లనివిగా గుర్తించేందుకు మరింత అధునాతన పద్ధతిని ఎంచుకున్నాం. Habitat సమీకృత కాష్, Azure Cosmos DB మార్పుల ఫీడ్ ద్వారా డేటా మార్పుల సేకరణ (CDC)పై ఆధారపడుతుంది. కొన్ని సెకన్లలోనే ప్రపంచవ్యాప్తంగా కాష్ చెల్లుబాటు రద్దులను పంపి, అధిక హిట్ రేటుతో పాటు తక్కువ పాతబడిన డేటాను సాధిస్తుంది. మా మౌలిక వ్యవస్థలోని ఒక సేవ ఈ మార్పుల ఫీడ్‌ను స్వీకరిస్తుంది. అంతర్లీన డేటా మారినప్పుడు స్థానిక కాష్‌లలోని ప్రతులను చెల్లనివిగా చేస్తుంది. దీంతో తదుపరిసారి చదివేటప్పుడు కాష్ మిస్ ఏర్పడి, తాజా డేటా సంస్కరణ కాష్‌లో చేరుతుంది.

అసలు Python కంటే మెరుగైన పనితీరు గల Rustలో కోడ్‌ను తిరగరాశాం. దీంతో Habitat సేవలోని అదనపు భారాన్ని తొలగించి జాప్యాన్ని గణనీయంగా తగ్గించాం.

ఈ మార్పులతో ప్రపంచవ్యాప్త మొత్తం రీడ్ 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 సేవను విస్తరిస్తూ, అత్యవసర ఇంజినీరింగ్ సవాళ్లకు ప్రాధాన్యమిచ్చాం. దీంతో చిన్న బృందమే వేగంగా పెరుగుతున్న నిల్వ వేదికకు తోడ్పడగలిగింది. మొదట అత్యంత కీలక ఉత్పత్తి ట్రాఫిక్‌కు విశ్వసనీయతపై, తర్వాత ప్రపంచ వినియోగదారులకు రీడ్ పనితీరుపై, చివరగా భారీ స్థాయిలో నిర్వహణ సమర్థతపై దృష్టి పెట్టాం. ఈ పద్ధతి విశ్వసనీయత, పనితీరు, ఉత్పత్తి అభివృద్ధి వేగాన్ని మెరుగుపరుస్తూనే వేగవంతమైన వృద్ధి, కొత్త వినియోగ సందర్భాలకు వీలు కల్పించింది.

తదుపరి 100 కోట్ల వినియోగదారుల కోసం Habitat, సంభాషణల నిల్వను విస్తరించాలంటే, మా మౌలిక వ్యవస్థ అంతటా మరింత భారీ స్థాయిలో డేటాను ప్రతిరూపించే సవాలును పరిష్కరించాలి. దీనికి ముందస్తు చర్యగా, భారీ Habitat డేటా రకాలకు అనుకూలమైన ఎక్సాబైట్ స్థాయి ఆన్‌లైన్ నిల్వ వ్యవస్థను సొంతంగా నిర్మిస్తున్నాం. అభివృద్ధిలో ఉన్న ఈ వ్యవస్థ Rocksetకు చెందిన RocksDB Cloud మూల భాగాన్ని Raft ఆధారిత ప్రతిరూపణతో కలుపుతుంది. ఇది Azure Cosmos DB మాదిరి డాక్యుమెంట్ నమూనానే అమలు చేస్తుంది. కానీ విడదీసిన నిల్వ, భౌతిక ప్రతిరూపణతో అవసరమైన ఫ్లాష్ సామర్థ్యాన్ని తగ్గిస్తుంది; బదులుగా గరిష్ఠ qps తక్కువగా ఉంటుంది.

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