ChatGPT အသုံးပြုသူ ၁ ဘီလီယံကျော်အတွက် online storage ကို အမြန်တိုးချဲ့ခြင်း

တစ်စုံတစ်ဦးက အကောင့်ဝင်ခြင်း၊ Codex ဆက်တင်များ စစ်ဆေးခြင်း သို့မဟုတ် ChatGPT တွင် စကားဝိုင်းအသစ် စတင်ခြင်း မည်သည့်လုပ်ဆောင်ချက်ဖြစ်စေ OpenAI ထုတ်ကုန်တိုင်းသည် ဒေတာကို မြန်ဆန်ယုံကြည်စိတ်ချစွာ ရယူနိုင်မှုအပေါ် မူတည်သည်။ ထုတ်ကုန်က မတုံ့ပြန်မီ ထိုလုပ်ဆောင်ချက်တစ်ခုစီအတွက် ဒေတာကို သီးခြားအကြိမ်များစွာ ရှာဖွေရနိုင်သည်။ ထိုတောင်းဆိုချက်များ နှေးလျှင် ထုတ်ကုန်လည်း နှေးသည်ဟု ခံစားရမည်။ ထိုတောင်းဆိုချက်များ မအောင်မြင်လျှင် ထုတ်ကုန်သည် လုံးဝ အလုပ်မလုပ်တော့ပါ။

Habitat သည် OpenAI ထုတ်ကုန်များက လိုအပ်သော အချက်အလက်များကို မြန်ဆန်ယုံကြည်စိတ်ချစွာ ရယူနိုင်ရန် တည်ဆောက်ထားသည့် online storage ပလက်ဖောင်းဖြစ်သည်။ ယခု Habitat သည် ပထဝီဒေသ ၄၀ နီးပါးတွင် အပတ်စဉ် လူ ၁ ဘီလီယံကျော် အသုံးပြုသည့် ထုတ်ကုန်များကို ပံ့ပိုးကာ တစ်စက္ကန့်လျှင် တောင်းဆိုချက် သန်း ၇၀ ကျော် ကိုင်တွယ်နေသည်။ Habitat ကို DevDay 2023 တွင် GPTs များကို ပံ့ပိုးရန် ပထမဆုံး စတင်ခဲ့ပြီး ဒေတာဘေ့စ်တစ်ခုနှင့် ချိတ်ဆက်ထားသည့် ရိုးရှင်းသော Python client-side library အဖြစ် စတင်ခဲ့သည်။ ယနေ့တွင် ဒေတာ 500 petabytes ကျော်ကို ဝန်ဆောင်မှုပေးသည့် ရှုပ်ထွေးသော ဖြန့်ဝေစနစ်ဖြစ်လာသည်။

ဤအတိုင်းအတာရှိ အခြေခံအဆောက်အအုံကို တည်ဆောက်လည်ပတ်ခြင်းသည် မလွယ်ကူသော်လည်း ထူးထူးခြားခြား ခက်ခဲလှသည်လည်း မဟုတ်ပါ။ ကျွန်ုပ်တို့၏ အခြေအနေကို ထူးခြားစေသည်မှာ ရင့်ကျက်သော ပလက်ဖောင်းတစ်ခုကို တစ်ပြိုင်နက် တည်ဆောက်နေစဉ် များပြားလှသော အသုံးပြုသူတိုးတက်မှုနှင့် ထုတ်ကုန်လိုအပ်ချက်ကို ပံ့ပိုးရန် တစ်ခါမျှမကြုံဖူးသည့် အရှိန်ဖြင့် တိုးချဲ့ခဲ့ရခြင်းဖြစ်သည်။ စနစ် engineer များသည် မကြာခဏ ၁၀ ဆအထိ တိုးချဲ့နိုင်ရန် တည်ဆောက်ပြီး နောက်ထပ် ၁၀ ဆအတွက် ပြင်ဆင်နေစဉ် နှစ်အနည်းငယ် ခံနိုင်မည်ဟု မျှော်လင့်ကြသည်။ ကျွန်ုပ်တို့၏ အခြေအနေတွင် လွန်ခဲ့သော သုံးနှစ်လုံး တစ်နှစ်ထက်တစ်နှစ် ၁၀ ဆကျော် တိုးတက်ခဲ့သည်။ ထို့ကြောင့် Habitat ကို တည်ဆောက်လည်ပတ်ရာတွင် လက်ရှိ stack မှ အမြင့်ဆုံးစွမ်းဆောင်ရည် ရယူရန် အစိတ်အပိုင်းတိုင်းကို အနိမ့်ဆုံးအဆင့်အထိ နားလည်ခြင်း၊ အခြေခံရင်းနှီးမြှုပ်နှံမှုများအတွက် အချိန်ရရန် storage နှင့် compute capacity အကျပ်အတည်းများကို ရင်ဆိုင်ခြင်းစသည့် နည်းဗျူဟာဆုံးဖြတ်ချက်များကို အစဉ်လိုက် ချမှတ်ခဲ့ရသည်။

OpenAI ကြီးထွားလာသည်နှင့်အမျှ Habitat လည်း လိုက်ပါကြီးထွားခဲ့ရသည်။ ပထမတွင် အရေးကြီးသော product traffic အတွက် ယုံကြည်စိတ်ချရအောင်၊ ထို့နောက် ကမ္ဘာတစ်ဝန်း အသုံးပြုသူများအတွက် လုံလောက်အောင် မြန်ဆန်စေရန်၊ နောက်ဆုံးတွင် အလွန်ကြီးမားသော အတိုင်းအတာ၌ ကျွမ်းကျင်စွာ လည်ပတ်နိုင်ရန် ဖြစ်သည်။ ဤဆောင်းပါးသည် online storage ကို တိုးချဲ့ခဲ့ပုံ အပိုင်းနှစ်ပိုင်းပါ စီးရီး၏ ပထမပိုင်းဖြစ်သည်။ ဤဆောင်းပါးတွင် Habitat တိုးတက်ပြောင်းလဲလာပုံ၊ library မှ ဝန်ဆောင်မှုအဖြစ် ပြောင်းခဲ့ရသည့် အကြောင်းရင်းနှင့် serving stack များတွင် သုံးလေ့မရှိသော Python ဖြင့် ရေးထားသည့် ဝန်ဆောင်မှုကို ယုံကြည်စိတ်ချရသော storage platform layer ဖြစ်လာအောင် တိုးချဲ့ခဲ့ပုံတို့ကို မျှဝေမည်။

နောင်ဆောင်းပါးတွင် အကြီးစား multi-tenancy ယုံကြည်စိတ်ချရမှု တည်ဆောက်ပုံ၊ read performance ကို အကောင်းဆုံးဖြစ်စေရန် အလွှာလိုက် မဟာဗျူဟာနှင့် မကြုံစဖူး လိုအပ်ချက်ကို ယုံကြည်စိတ်ချစွာ ကိုင်တွယ်ရန် Azure Cosmos DB နှင့် ပူးပေါင်းမှုကို တိုးချဲ့ပုံတို့အား အသေးစိတ် ဆွေးနွေးမည်။

Habitat သည် ရိုးရှင်းသော အယူအဆတစ်ခုမှ စတင်ခဲ့သည်။ ထုတ်ကုန် engineer များသည် ဒေတာဘေ့စ်စီမံခန့်ခွဲမှုကို စဉ်းစားစရာ မလိုသင့်ပါ။ Habitat ကို DevDay 2023 တွင် GPTs များအား ပံ့ပိုးရန် ChatGPT ၏ အဓိက server နှင့် ဆက်သွယ်သည့် Python library အသေးတစ်ခုအဖြစ် ပထမဆုံး စတင်ခဲ့သည်။ ၎င်းသည် နောက်ကွယ်တွင် ဒေတာဘေ့စ် application ဖြစ်သော Azure Cosmos DB နှင့် ချိတ်ဆက်ထားသည့် လုပ်ဆောင်ချက်အနည်းငယ်ကို ပံ့ပိုးခဲ့သည်။

Library ၏ တာဝန်မှာ အောက်ခံအသေးစိတ်အချက်များကို ကျွမ်းကျင်စရာမလိုဘဲ ထုတ်ကုန်အဖွဲ့များအား ဒေတာသိမ်းဆည်းရယူရန် ရိုးရှင်းသော နည်းလမ်းပေးခြင်းဖြစ်သည်။ Habitat က ပါဝင်သည့် ဒေတာအမျိုးအစား၊ ဒေတာလာရမည့် သို့မဟုတ် သွားရမည့်နေရာ၊ တောင်းဆိုချက်ကို ခွင့်ပြုထားခြင်း ရှိမရှိ စသည်တို့ကို ဆုံးဖြတ်သည့် လိုအပ်သောလုပ်ငန်းများအား ကိုင်တွယ်ပေးသည်။

ထုတ်ကုန် engineer များသည် စီမံချက် ရှာဖွေခြင်း၊ routing၊ authorization၊ encryption၊ serialization၊ request shaping နှင့် connection pooling တို့ကို စိတ်ပူစရာမလိုပါ။ ဒေတာသည် Azure Cosmos DB၊ cache သို့မဟုတ် အခြား storage အမျိုးအစားမှ လာခြင်းရှိမရှိကိုပင် စဉ်းစားစရာ မလိုပါ။

Self-service Postgres နှင့် Azure Cosmos DB အသုံးပြုမှုမှ ဖယ်ခွာရန် ဗဟိုက စနစ်တကျ မတွန်းအားပေးခဲ့သော်လည်း ဤ Python library သည် ကောင်းမွန်စွာ အလုပ်လုပ်ပြီး OpenAI ရှိ ထုတ်ကုန် engineer များအကြား Habitat ကို လျင်မြန်စွာ လက်ခံအသုံးပြုလာကြသည်။

ထုတ်ကုန်လိုအပ်ချက်များ ပြောင်းလဲလာသည့်အခါ client-side caching၊ compression သို့မဟုတ် encryption ကဲ့သို့ လုပ်ဆောင်ချက်များကို shared library တွင် ထုတ်ကုန် developer များက အလွယ်တကူ ထည့်သွင်းနိုင်ခဲ့သည်။

၂၀၂၅ ခုနှစ်လယ်တွင် Habitat သည် client-side implementation အဖြစ် ၎င်း၏ အကန့်အသတ်သို့ ရောက်ရှိခဲ့သည်။ Habitat layer ပိုမိုရှုပ်ထွေးလာပြီး OpenAI ၏ ဝန်ဆောင်မှုအရေအတွက် တိုးလာသဖြင့် backward-compatible protocol အပြောင်းအလဲများ လုပ်ရန် မဖြစ်နိုင်တော့ပါ။

တစ်ကြိမ်တွင် အရေးအကြီးဆုံး ဒေတာအစုများကို ဒေသအလိုက် ဖြန့်ထားသော Azure Cosmos DB account များသို့ ပြောင်းရွှေ့ခြင်းဖြင့် ဒေသတစ်ခုတည်း outage ဖြစ်သည့်အခါ ထိခိုက်မှုအတိုင်းအတာကို လျှော့ချလိုခဲ့သည်။ ဤအပြောင်းအလဲအတွက် feature flag နောက်တွင် ပိတ်ထားသည့် routing logic အပိုကို client ထဲ ထည့်ခြင်း၊ client အားလုံးသို့ ဖြန့်ချိပြီးကြောင်း သေချာစေခြင်းနှင့် ထို့နောက် feature flag ကို ဖွင့်ခြင်းတို့ လိုအပ်ခဲ့သည်။

ဝန်ဆောင်မှု ဒါဇင်များစွာတွင် ဖြန့်ချိအသုံးချမှုများကို ညှိနှိုင်းပြီး အဖွဲ့တစ်ခုစီနှင့် ဖြန့်ချိရန် ရက်ပေါင်းများစွာ ကြာခဲ့သည်။ ၎င်းကို မဖွင့်မီ sharding logic မှန်ကန်ကြောင်း သေချာစေရန် shadowing အချို့ ထည့်လိုကြောင်း သိရှိခဲ့သည်။ ၎င်းကို ဖြန့်ချိရန် နောက်ထပ် ရက်အနည်းငယ် ကြာခဲ့သည်။ မှားနေကြောင်း သိလိုက်ရသည့် အရာအတွက် bug fix လုပ်ရပါသလား။ နောက်ထပ် ရက်အနည်းငယ် ထပ်ကြာသည်။ နောက်ဆုံး flag ကို ဖွင့်ရန် အဆင်သင့်ဖြစ်ချိန်တွင် အဖွဲ့တစ်ဖွဲ့က မသက်ဆိုင်သော အကြောင်းရင်းဖြင့် ၎င်းတို့၏ ဝန်ဆောင်မှုကို bug ပါသည့် ယခင် client သို့ rollback လုပ်လိုက်သဖြင့် ကျွန်ုပ်တို့ အပြင်းအထန် ရှောင်ရှားခဲ့သော outage ဖြစ်ပေါ်ခဲ့သည်။

Client library အပြောင်းအလဲများကြောင့် ဝန်ဆောင်မှု ဒါဇင်များစွာအကြား ရှုပ်ထွေးစွာ ညှိနှိုင်းရပြီး ယင်းလုပ်ငန်းစဉ်သည် ပိုမိုထိရှလွယ်၊ မထိရောက်ဘဲ လုပ်ငန်းလည်ပတ်မှု ချို့ယွင်းချက် ဖြစ်လွယ်လာသည်။ အနာဂတ် ဖြန့်ချိအသုံးချမှုများတွင် ဤလုပ်ငန်းလည်ပတ်မှု ပျံ့နှံ့မှုကို လျှော့ချရန် Habitat ကို သီးခြားဝန်ဆောင်မှုတစ်ခုအဖြစ် ပြောင်းရန် ဆုံးဖြတ်ခဲ့သည်။

Storage logic ကို သီးခြားဝန်ဆောင်မှုအဖြစ် ခွဲထုတ်ခြင်းဖြင့် ဖြန့်ချိအသုံးချမှု၊ လေ့လာနိုင်စွမ်းနှင့် ပလက်ဖောင်းတိုးတက်မှုတို့အတွက် တစ်ခုတည်းသော ထိန်းချုပ်ရာနေရာကို တည်ဆောက်ခဲ့သည်။ ပြန့်ကျဲနေသည့် update များကို စီမံမည့်အစား တိုးတက်မှုများကို ဗဟိုမှ အကောင်အထည်ဖော်ကာ OpenAI ထုတ်ကုန်တိုင်းအား ချက်ချင်း အကျိုးရှိစေနိုင်ခဲ့သည်။

ဗဟိုဝန်ဆောင်မှုက အခိုင်မာဆုံး ဒေတာလုံခြုံရေးနှင့် ကိုယ်ရေးအချက်အလက်ကာကွယ်ရေး အခြေခံစွမ်းရည်များ ပေးရန် တစ်ခုတည်းသော ထိန်းချုပ်ရာနေရာလည်း ရရှိစေသည်။ Habitat ဝန်ဆောင်မှုတွင် access control policy များကို ဗဟိုမှ မဖြစ်မနေ လိုက်နာစေခြင်း၊ audit log မှတ်တမ်းတင်ခြင်းနှင့် Azure Cosmos DB ကဲ့သို့ အောက်ခံ storage resource များကို အသုံးပြုခွင့် ကန့်သတ်ခြင်းတို့ ပြုလုပ်နိုင်သည်။ Habitat သည် အသုံးပြုသူဒေတာကို ကာကွယ်ရန်နှင့် ပြင်ပ၊ အတွင်းပိုင်းနှင့် အေးဂျင့်များ၏ ခွင့်ပြုချက်မရှိသော ဝင်ရောက်မှုကို တားဆီးရန် အရေးပါသော အခန်းကဏ္ဍမှ ပါဝင်သည်။

ဝန်ဆောင်မှုတစ်ခု လိုအပ်ကြောင်း သိခဲ့သော်လည်း ဝန်ဆောင်မှုအဖြစ် အသုံးပြုရာတွင် Python ၏ အပိုကုန်ကျစရိတ်ရှိသည့်တိုင် Python မှ ချက်ချင်း မပြောင်းရွှေ့လိုသေးပါ။ ဆောင်ကြဉ်းပေးမှု ပမာဏမြင့် ဝန်ဆောင်မှုအတွက် Python သုံးခြင်းသည် local library ကို တိုက်ရိုက်အသုံးပြုခြင်းနှင့်ယှဉ်လျှင် ကွန်ရက်ကြန့်ကြာချိန် တိုးစေပြီး CPU နှင့် မမ်မိုရီ တိုးချဲ့စရိတ်များစွာ ပိုကုန်စေသည်။ ထို့ပြင် ၁၀၀ ဆအထိ တိုးချဲ့သောအခါ Python ၏ ထိရောက်မှုနည်းခြင်းကို လက်ခံနိုင်မည်မဟုတ်သဖြင့် နောက်ဆုံးတွင် ပြန်လည်ရေးသားရမည်မှာ သေချာသလောက်ဖြစ်ကြောင်း သိခဲ့သည်။

သို့သော် ၎င်းကို နည်းပညာကြွေးမြီအား မဟာဗျူဟာအရ ယာယီလက်ခံခြင်းဟု ကျွန်ုပ်တို့ သဘောထားခဲ့သည်။ ထိုအချိန်က အဓိကရည်မှန်းချက်မှာ ကုန်ကျစရိတ် သို့မဟုတ် ရင်းမြစ်များကို အကောင်းဆုံးဖြစ်စေရန် မဟုတ်ဘဲ ထုတ်ကုန် developer များ၏ အတားအဆီးများကို ဖယ်ရှားပြီး ပလက်ဖောင်းတည်ငြိမ်မှု ရရှိရန်ဖြစ်သည်။ ကာလတိုအတွင်း Python ဝန်ဆောင်မှု၏ စွမ်းဆောင်ရည်အလျှော့အတင်းကို လက်ခံခြင်းဖြင့် ပိုအရေးပေါ်သော စိန်ခေါ်မှုများကို ဦးစားပေးကာ အဓိက API များကို သတ်မှတ်ပြီး ခိုင်မာသည့် အခြေခံအဆောက်အအုံကို တည်ဆောက်နိုင်ခဲ့သည်။

ကျွန်ုပ်တို့၏ coding မော်ဒယ်များ လျင်မြန်စွာ တိုးတက်လာခြင်းက အနာဂတ်နည်းပညာလမ်းကြောင်းကို ပိုမိုလွယ်ကူစေမည်ဟုလည်း တွက်ချက်ကာ လောင်းကြေးထပ်ခဲ့သည်။ Python မှ အပြည့်အဝ ပြောင်းရွှေ့ရန် လိုအပ်လာချိန်တွင် Codex နှင့် GPT တို့က ထိုပြောင်းရွှေ့မှုကို ဖြစ်မြောက်စေမည်ဟု ယုံကြည်ခဲ့သည်။ နောက်ဆုံးတွင် ထိုခန့်မှန်းချက် မှန်ကန်ကြောင်း သက်သေပြနိုင်ခဲ့သည်။

Habitat ကို Python ဝန်ဆောင်မှုအဖြစ် လည်ပတ်ခြင်းသည် စွမ်းဆောင်ရည်အရ အကောင်းဆုံးမဟုတ်သော်လည်း မဖြစ်မနေ ရွေးချယ်ရသည့် နည်းလမ်းဖြစ်သည်။ Python က ကျွန်ုပ်တို့ကို လျင်မြန်စွာ ဆောင်ရွက်နိုင်စေသော်လည်း သတိမထားဘဲ ကြန့်ကြာချိန် သိသိသာသာ ပိုဆိုးလာခြင်းကို လက်ခံနိုင်သည်ဟု မဆိုလိုပါ။ ပျမ်းမျှ အသုံးပြုသူတောင်းဆိုချက်တစ်ခုက ဒေတာဘေ့စ်ခေါ်ဆိုမှု ရာနှင့်ချီ ဖြစ်ပေါ်စေသည့်အခါ အနှေးဆုံးခေါ်ဆိုမှု၏ ကြန့်ကြာမှုကို အသုံးပြုသူက ခံစားရသည်။ ဤအတိုင်းအတာဖြင့် Python ဝန်ဆောင်မှု လည်ပတ်ရာတွင် အဓိကစိန်ခေါ်မှုမှာ tail latency များကို စီမံခြင်းဖြစ်ကြောင်း တွေ့ရှိခဲ့သည်။

Asyncio သည် Python ကို I/O အဓိက workload များအား တစ်ပြိုင်တည်း လုပ်ဆောင်နိုင်စေသော်လည်း Python GIL ကို ကျော်လွှားပြီး CPU parallelism ပေးနိုင်ခြင်းမရှိပါ။ I/O များသည့် request proxying အပြင် Habitat သည် routing၊ compression၊ encryption၊ checksum တွက်ခြင်း၊ downstream ကျန်းမာရေးစစ်ဆေးခြင်း၊ request shadowing နှင့် hedging စသည့် CPU အလွန်သုံးသော တာဝန်များနှင့် နောက်ခံလုပ်ငန်းများကို ကိုင်တွယ်သည်။

ဝန်ဆောင်မှုတွင် CPU အလွန်သုံးသော အလုပ်ဝန်နှင့် နောက်ခံလုပ်ငန်းများ များပြားသဖြင့် asyncio scheduling ကြန့်ကြာမှုက tail request latency ကို အလွယ်တကူ လွှမ်းမိုးနိုင်သည်။ ပထမဆုံး ဝန်ဆောင်မှုမစတင်မီ ချိန်ညှိစဉ် p99 နှင့်အထက် ကြန့်ကြာသော တောင်းဆိုချက် trace များတွင် downstream storage က လျင်မြန်စွာ တုံ့ပြန်သော်လည်း တုံ့ပြန်ချက်ကို ခွဲခြမ်းရန် သက်ဆိုင်ရာ coroutine အား ပြန်လည် schedule လုပ်သည်အထိ စောင့်ရင်း တောင်းဆိုချက်များ မကြာခဏ ရပ်တန့်နေသည်ကို တွေ့ခဲ့သည်။

OpenAI ရှိ Python ဝန်ဆောင်မှုများအတွက် မမ်မိုရီ၊ CPU၊ ကွန်ရက်နှင့် disk အသုံးပြုမှုဆိုင်ရာ ပုံမှန် utilization နှင့် saturation တိုင်းတာချက်များအပြင် asyncio loop မည်မျှအလုပ်များနေသည်ကို စောင့်ကြည့်ပြီး လိုအပ်သလို ချိန်ညှိရန် အလွန်အရေးကြီးသည်။

နောက်ခံလုပ်ငန်းများကို အချိန်မှန် schedule လုပ်ပြီး မျှော်မှန်းထားသည့် လုပ်ဆောင်ချိန်နှင့် အမှန်တကယ် လုပ်ဆောင်ချိန်တို့၏ ကွာခြားချက်ကို မှတ်တမ်းတင်ခြင်းဖြင့် event loop scheduling ကြန့်ကြာမှုကို အချိန်နှင့်တစ်ပြေးညီ လက်တွေ့တိုင်းတာနိုင်သည်။ အသုံးပြုမှုမြင့်ပြီး ကုန်ကျစရိတ်ကြီးသော လုပ်ငန်းများ များသည့်အခါ လုပ်ငန်းစဉ်တစ်ခုလျှင် တစ်ပြိုင်တည်းတောင်းဆိုချက် အနည်းငယ်သာရှိလျှင်ပင် scheduling jitter သည် မီလီစက္ကန့် ရာနှင့်ချီအထိ၊ အချို့အစွန်းရောက်အခြေအနေများတွင် စက္ကန့်အနည်းငယ်အထိ ဖြစ်နိုင်သည်။

ထို့ကြောင့် လုပ်ငန်းစဉ်တစ်ခုစီအား တစ်ပြိုင်တည်းတောင်းဆိုချက် အနည်းငယ်သာ ပေးပို့ပြီး Python worker လုပ်ငန်းစဉ်အရေအတွက်ကို အကြီးအကျယ် တိုးချဲ့ထားရသည်။

ပထမဆုံး ဝန်ဆောင်မှုစတင်ရာတွင် live service CPU profiling မှတစ်ဆင့် asyncio ကြန့်ကြာမှုမြင့်ခြင်းနှင့် ထို့ကြောင့် tail latency မြင့်ခြင်း၏ အကြောင်းရင်းတစ်ခုကို တွေ့ရှိခဲ့သည်။ ယင်းမှာ feature flag များကို စီမံပြီး A/B test စသည်တို့ လုပ်နိုင်သည့် Statsig မှတစ်ဆင့် feature flag စီစဉ်သတ်မှတ်ချက်များကို အချိန်မှန် JSON parsing လုပ်ခြင်းဖြစ်သည်။

မူလအတိုင်းဆိုလျှင် Statsig သည် jitter မရှိဘဲ မိနစ်တိုင်း config အသစ်ကို စစ်ဆေးရန် သတ်မှတ်ထားပြီး config တွင် ဝန်ဆောင်မှုအားလုံး၏ production rule အားလုံး ပါဝင်သည်။ အခြားတစ်ဖက်တွင် CPU အသုံးပြုမှုမြင့်စေပြီး ကြန့်ကြာချိန်လျှော့ချရန် pod တစ်ခုလျှင် Python လုပ်ငန်းစဉ် ၈ ခုအထိ လည်ပတ်စေသည့် ဗိသုကာဆုံးဖြတ်ချက် ချထားခဲ့သည်။ ယင်းတို့ပေါင်းလိုက်သောအခါ မိနစ်တိုင်း pod တစ်ခုစီ၏ worker အားလုံးသည် လက်ရှိတောင်းဆိုချက်များကို စီမံနေရာမှ ရပ်ပြီး ကြီးမားသော configuration file ကို CPU ဖြင့် ခွဲခြမ်းနေသည့် အခိုက်အတန့်တစ်ခု ရှိလာသည်။

CPU profiling ဖြင့် အကြောင်းရင်းကို သိရှိပြီးနောက် ဖြေရှင်းချက်မှာ ရိုးရှင်းသည်။ ပစ်မှတ်ထားသည့် config အသေးတစ်ခု ဖြန့်ချိအသုံးချခြင်း၊ refresh interval ကို ရှည်စေခြင်းနှင့် ဤကဲ့သို့သော နောက်ခံလုပ်ငန်းများတွင် jitter ထည့်ခြင်းတို့ဖြစ်သည်။

Asyncio ကြန့်ကြာမှုကို နိမ့်စေရန် server လုပ်ငန်းစဉ်များအကြား တောင်းဆိုချက် load ကို ကောင်းစွာမျှတစေရန်လည်း အရေးကြီးသည်။ မချိန်ညှိထားပါက connection pooling သည် ယင်းနှင့် ဆန့်ကျင်ဘက် အကျိုးသက်ရောက်နိုင်သည်။

Client-side connection pooling တွင် တစ်ပြိုင်တည်းတောင်းဆိုချက် များစွာပြုလုပ်သည့် client လုပ်ငန်းစဉ်တစ်ခုသည် server connection အနည်းငယ်သာ တည်ဆောက်နိုင်ပြီး ၎င်း၏ load အားလုံးကို လုပ်ငန်းစဉ်အနည်းငယ်သို့သာ ပို့မိနိုင်သည်။ Load balancing နည်းလမ်းကို မပြင်ဆင်မီ ဝန်ဆောင်မှုအသုံးပြုမှု ကွာခြားချက် အလွန်ကြီးမားခဲ့ပြီး အချို့ tail လုပ်ငန်းစဉ်များက ပျမ်းမျှထက် တစ်ပြိုင်တည်းတောင်းဆိုချက် ၅ ဆမှ ၁၀ ဆအထိ ကိုင်တွယ်ခဲ့ရသည်။

ဝန်ဆောင်မှုတစ်စိတ်တစ်ပိုင်းကို ဝန်ပိစေသည့် client ကို ရပ်လိုက်သည့်တိုင် လုပ်ငန်းစဉ်အချို့သည် burst traffic ပြီးနောက် အတော်ကြာအထိ စွမ်းဆောင်ရည်ကျဆင်းနေသည့် မတော်တဆဖြစ်ရပ်တစ်ခုမှ ဤအချက်ကို တွေ့ရှိခဲ့သည်။ အမှန်တွင် ထို လုပ်ငန်းစဉ်များသည် ပြန်လည်စတင်သည့်အချိန်အထိ တောင်းဆိုချက် ပိုမိုလက်ခံရင်း ထိန်းမနိုင်သည့် စွမ်းဆောင်ရည်ကျဆင်းမှုကို ကြုံခဲ့သည်။ Pod တစ်ခု ဝန်ပိသွားသည်နှင့် အချို့သော အပြုအမူက ထို pod ပေါ်သို့ traffic ပိုမိုရောက်အောင် ချည်နှောင်ထားသည်။ ဤသည်မှာ ယခင်အလုပ်အတွေ့အကြုံများမှ ကျွန်ုပ်တို့၏ အဖွဲ့ဝင်အချို့ ကောင်းစွာသိရှိထားသည့် ချို့ယွင်းမှုအမျိုးအစားဖြစ်သော metastable failure⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ဖြစ်သည်။

Connection pool ကြောင့်ဟု သံသယရှိသဖြင့် connection ပြန်သုံးနိုင်သည့် အများဆုံးကြာချိန်ကို ကန့်သတ်ကာ စမ်းသပ်ခဲ့သည်။ ယင်းက စွမ်းဆောင်ရည်ကျဆင်းမှုကို အမှန်တကယ် ကန့်သတ်ပေးပြီး စုံစမ်းသည့် ဦးတည်ချက် မှန်ကြောင်း အတည်ပြုခဲ့သည်။ ထပ်မံစုံစမ်းရာ Python ၏ aiohttp TCPConnector သည် မူလအတိုင်း LIFO connection ပြန်သုံးမှုကို အသုံးပြုကြောင်း တွေ့ခဲ့သည်။ နောက်ဆုံးပြန်ရောက်သည့် connection ကို နောက်တောင်းဆိုချက်အတွက် ရွေးခြင်းဖြစ်သည်။ ပုံမှန်အားဖြင့် ယင်းသည် သင့်လျော်သော မူလသတ်မှတ်ချက်ဖြစ်သည်။ မကြာသေးမီက connection များကို ပြန်သုံးခြင်းက burst traffic ကို ကိုင်တွယ်ရန် ဖန်တီးထားသော အပို connection များအား အားနေချိန်ကုန်ဆုံးစေပြီး ထိန်းသိမ်းစရိတ်ကို လျှော့ချပေးသည်။ သို့သော် ဤအခြေအနေတွင် ကျွန်ုပ်တို့အတွက် metastable failure ဖြစ်စေခဲ့သည်။ တောင်းဆိုချက်များ တစ်ဟုန်ထိုးဝင်ချိန်တွင် နှေးပြီး ဝန်ပိနေသော server များသို့ ပို့သည့် တောင်းဆိုချက်များက connection ကို pool သို့ နောက်ကျမှ ပြန်ပို့သည်။ ထို့ကြောင့် နောက်တောင်းဆိုချက်များက ယင်းတို့ကို ပိုမိုရွေးချယ်ကာ ရုန်းကန်နေရပြီးသား pod များပေါ်သို့ traffic တဖြည်းဖြည်း ပိုမိုစုပြုံစေသည်။ Connection pool ကို FIFO ပြန်သုံးမှု အသုံးပြုရန် ပြင်ဆင်ခြင်းက ဤ feedback loop ကို ဖြတ်တောက်ပြီး steady-state တောင်းဆိုချက်ကွာခြားမှုကိုပင် လျှော့ချပေးခဲ့သည်။

ယနေ့တွင် OpenAI အခြေခံအဆောက်အအုံတစ်လျှောက် connection pooling နှင့် server load ကို ပိုသိရှိသည့် balancing မဟာဗျူဟာများ ပေးရန် Istio နှင့် Envoy ကို အဓိကအားထားပြီး ဤပြဿနာကို လုံးဝရှောင်ရှားထားသည်။

Asyncio ကြန့်ကြာမှုနိမ့်စေရန် ချိန်ညှိပြီး Python လုပ်ငန်းစဉ်များစွာ ထားရှိခြင်း၏ ဘေးထွက်ဆိုးကျိုးတစ်ခုမှာ အလွန်များပြားသော connection များဖြင့် downstream dependency များကို အလွယ်တကူ ဝန်ပိစေနိုင်ခြင်းဖြစ်ပြီး ယင်းကို “thundering herd” ဟု ခေါ်သည်။

နေ့စဉ် ပုံမှန် ဖြန့်ချိအသုံးချမှုကို ဖြည်းဖြည်းလုပ်ရန် မချိန်ညှိထားပါက connection များ အလှည့်ကျ ပြတ်တောက်ချိတ်ဆက်မှုကြောင့် CPU အပြောင်းအလဲကြီး ဖြစ်စေနိုင်သည်။ သို့မဟုတ် connection leak တစ်ခုက NAT gateway ကို ပြည့်ကျပ်စေပြီး ကွန်ရက်ကို ရပ်တန့်စေနိုင်သည်။ ဤပြဿနာများသည် အခြားဝန်ဆောင်မှုများတွင်လည်း ထူးဆန်းသည်မဟုတ်ပါ။ သို့သော် လုပ်ငန်းစဉ်အရေအတွက် ဆယ်ဆခန့်ပိုများခြင်းကြောင့် ဖြစ်ပေါ်စေမည့် အတိုင်းအတာ သိသိသာသာ နိမ့်လာပြီး ဆောင်ကြဉ်းပေးမှု ပမာဏတစ်ခုတည်းအပေါ် အခြေခံ၍ steady state တွင် client များ ကိုင်တွယ်ရန် မမျှော်လင့်ထားသော ကွန်ရက်ဆိုင်ရာ ရင်းမြစ်များကို မကြာခဏ ပြည့်ကျပ်စေသည်။

Connection fan-in ကို အမြင့်ဆုံးဖြစ်စေရန် Envoy ကိုလည်း အားထားသည်။ Multiplexing ကို အသုံးချရန် Python ၏ HTTP/1 connection များကို HTTP/2 သို့ အဆင့်မြှင့်ပြီး ထို connection များကို pool လုပ်ကာ သက်တမ်းတိုးရန် Envoy ကို အသုံးပြုသည်။ Envoy သည် သီးခြား Python လုပ်ငန်းစဉ်တစ်ခုစီတွင်ဆိုလျှင် ထိရောက်မှုနည်းမည့် rate limit နှင့် circuit breaker များကို အကောင်အထည်ဖော်ရန် ဗဟိုနေရာတစ်ခုလည်း ပေးသည်။

Python ကို ဤမျှအထိ တိုးချဲ့နိုင်ခဲ့သည့် အကြောင်းရင်းတစ်ခုမှာ တောင်းဆိုချက်ကုန်ကျစရိတ်ကို ကြိုတင်ခန့်မှန်းနိုင်စေသော Habitat ၏ ကန့်သတ်ထားသည့် API ဖြစ်သည်။ ဇယားကြီးများကို scan လုပ်ခြင်း သို့မဟုတ် ဇယားများစွာကို join လုပ်ခြင်း ဖြစ်စေနိုင်သည့် မည်သည့် SQL query မဆို client များအား တည်ဆောက်ခွင့်ပေးမည့်အစား Habitat က ရိုးရှင်းသော NoSQL API ကို ပေးထားသည်။ အစွမ်းထက် API မပါခြင်းသည် Habitat ဒီဇိုင်းတွင် ရည်ရွယ်ချက်ရှိရှိ ပြုလုပ်ထားသော အလျှော့အတင်းဖြစ်သည်။

ရိုးရှင်းပြီး ကြိုတင်ခန့်မှန်းနိုင်ကာ လုပ်ဆောင်ရမည့်ပမာဏ မပြောင်းလဲသော တောင်းဆိုချက်များအတွက် အကောင်းဆုံးဖြစ်စေရန် ရည်ရွယ်သည်။ ကျွန်ုပ်တို့၏ အတွေ့အကြုံအရ ဤစနစ်များကို တိုးချဲ့ရန် သိသိသာသာ လွယ်ကူပြီး မှားယွင်းစွာ အသုံးပြုရန် ခက်ခဲသည်။ ခန့်မှန်းမရသော fanout ပါသည့် တောင်းဆိုချက်များသည် လုပ်ငန်းလည်ပတ်မှုအရ အန္တရာယ်ရှိသည်။ ၎င်းတို့က isolation နှင့် load balancing ကို ရှုပ်ထွေးစေပြီး ဝန်ဆောင်မှုနှင့် client နှစ်ဖက်စလုံးအတွက် တိုးချဲ့ဖြေရှင်းရန်ခက်သည့် latency cliff များ ဖြစ်စေသည်။

Habitat နှင့် Azure Cosmos DB သို့ မပြောင်းရွှေ့မီ OpenAI ၏ online ဒေတာအများစုကို Postgres တွင် သိမ်းဆည်းခဲ့သည်။ ထိုစဉ်က production သို့ မဖြန့်ချိမီ query နှင့် စီမံချက် အပြောင်းအလဲအားလုံး ကောင်းမွန်စွာ လည်ပတ်ပြီး indexed data ကို အသုံးပြုကြောင်း စစ်ဆေးရန် လွယ်ကူခဲ့သည်။ အဖွဲ့နှင့် ထုတ်ကုန်များ ကြီးထွားလာသည်နှင့်အမျှ ယင်းကို စီမံ၍မရတော့ဘဲ hot path ပေါ်ရှိ ကုန်ကျစရိတ်ကြီးသော query အသစ်တစ်ခုတည်းက ဒေတာဘေ့စ်ကို ရပ်တန့်စေသည့် outage များ မကြာခဏ ဖြစ်လာသည်။

ဤပြဿနာမှာ ကုန်ကျစရိတ်မညီမျှခြင်းဖြစ်သည်။ လည်ပတ်ရန် ကုန်ကျစရိတ်ကြီးပြီး ခက်ခဲသော SQL query များကို ရေးရန်မူ စျေးသက်သာပြီး လွယ်ကူသည်။ Habitat တွင် ယင်းကို ရှောင်ရှားထားပြီး ကုန်ကျစရိတ်ကြီးသော query များကို client ဘက်မှ အလွန်ရှင်းလင်းစွာ မြင်နိုင်စေသည်။ Habitat ကို ဝန်ပိစေနိုင်သည့် အကန့်အသတ်မဲ့ query မရှိပါ။ ရှုပ်ထွေးသော join နှင့် graph traversal များအတွက် ထုတ်ကုန်အဖွဲ့များက ခက်ခဲသည့်အပိုင်းအချို့ကို လုပ်ဆောင်ရသဖြင့် ဒီဇိုင်းတစ်ခုလုံး ပိုထိရောက်လာစေသည်။

Habitat သည် TAO⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှ စိတ်ကူးရယူကာ client သတ်မှတ်ထားသည့် object နှင့် edge type များအပေါ် အခြေခံသော NoSQL API ကို ပေးထားသည်။ Client များသည် object၊ edge နှင့် ၎င်းတို့၏ ဆက်နွှယ်ပုံကို ကြိုတင်သတ်မှတ်သော်လည်း type တစ်ခုစီ၏ အကြောင်းအရာကို မသတ်မှတ်ပါ။ ရရှိလာသည့် ဆက်နွှယ်မှုများသည် graph နှင့် ဆင်တူသော်လည်း Habitat ကိုယ်တိုင်က object တစ်ခု၏ တိုက်ရိုက် edge များကို query လုပ်ခြင်းမှလွဲ၍ ပုံမှန် graph traversal query များကို မပံ့ပိုးပါ။

Object တစ်ခုစီနှင့် သက်ဆိုင်ရာ edge များကို storage-level partition တစ်ခုတည်းတွင် အတူထားရန် graph ကို partition ခွဲသော်လည်း object နှင့် ၎င်း၏ edge ညွှန်သည့် အဝေးရှိ object တို့ကို အတူထားရန် database level တွင် အထူးမကြိုးပမ်းပါ။ ထို့ကြောင့် မော်ဒယ်ကို အလျားလိုက် တိုးချဲ့ရန် လွယ်ကူစွာ partition ခွဲနိုင်သော်လည်း object များကြား hop တစ်ခုတည်းအတွက်ပင် မတူညီသော ဒေသများရှိ Azure Cosmos DB account နှစ်ခုမှ ရယူရနိုင်သဖြင့် graph traversal များ မထိရောက်ပါ။

ပိုမိုရှုပ်ထွေးသော query လိုအပ်သည့် client များအတွက် Rockset မှတစ်ဆင့် ရယူနိုင်သော Habitat ၏ offline secondary view ကို ပေးထားသည်။ Online storage မှ အပြောင်းအလဲများကို သီးခြား Rockset instance များသို့ အချိန်နှင့်တစ်ပြေးညီနီးပါး stream လုပ်ရန် change data capture (CDC) ကို အသုံးပြုသည်။ Client အဖွဲ့တစ်ခုစီသည် မိမိတို့၏ ရှုပ်ထွေးသော query လိုအပ်ချက်များအတွက် ကိုယ်ပိုင် Rockset instance ကို တိုးချဲ့ရန် တာဝန်ရှိသည်။

Rockset စီစဉ်ပေးရခြင်းက client များအတွက် အပိုအခက်အခဲ ဖြစ်စေသော်လည်း ယခုအချိန်အတွက် သင့်လျော်သော အလျှော့အတင်းဟု ယူဆသည်။ ရိုးရှင်းသော query များကို မူလရွေးချယ်မှုအဖြစ် ထားပြီး ရှုပ်ထွေးသော query လိုအပ်သူများအတွက် အခြားလမ်းတစ်ခု ပေးထားခြင်းဖြစ်သည်။ ဤဒီဇိုင်းသည် online storage ကို read-heavy analytical နှင့် ရှာဖွေအလုပ်ဝန်များမှ သီးခြားခွဲထားပေးသည်။

Python ဖြင့် ပြန်လည်ရေးသားခြင်းကို တစ်နှစ်ရွှေ့ဆိုင်းခဲ့သဖြင့် အလွန်လျင်မြန်စွာ ကြီးထွားနေစဉ် ပိုအရေးပေါ်ပြီး အကျိုးသက်ရောက်မှုကြီးသော စိန်ခေါ်မှုများကို အာရုံစိုက်နိုင်ခဲ့သည်။ ပလက်ဖောင်း ရင့်ကျက်လာပြီး ကြီးထွားမှု ဆက်လက်အရှိန်မြင့်နေချိန်တွင် Habitat သည် OpenAI ၌ core အရေအတွက်အလိုက် ဒုတိယအကြီးဆုံး ဝန်ဆောင်မှုနှင့် Envoy အသုံးပြုမှုအလိုက် စတုတ္ထဖြစ်လာသဖြင့် Python ကို ကျော်လွန်ပြောင်းရွှေ့ရန် အချိန်တန်လာသည်။ အမြင့်ဆုံးအချိန်တွင် Python က တစ်စက္ကန့်လျှင် တောင်းဆိုချက် သန်း ၂၀ ကျော်ကို ဝန်ဆောင်မှုပေးနိုင်စေခဲ့သည်။

၂၀၂၆ ဒုတိယသုံးလပတ်တွင် engineer ၂ ဦး၊ Codex နှင့် GPT‑5.5 တို့ဖြင့် ဝန်ဆောင်မှုတစ်ခုလုံးကို Rust ဖြင့် ပြန်ရေးနိုင်ခဲ့သည်။ ယခု Rust ဝန်ဆောင်မှုအသစ်က production တောင်းဆိုချက်များ၏ ၉၅% ကို ကိုင်တွယ်နေပြီး လာမည့်ရက်သတ္တပတ်များတွင် Python ကို လုံးဝရပ်ဆိုင်းမည်။ ဒေတာအရ Rust ဝန်ဆောင်မှုသည် Python ဗားရှင်းထက် CPU အသုံးပြုမှု ၆ ဆနှင့် မမ်မိုရီအသုံးပြုမှု ၁၅ ဆ ပိုထိရောက်ပြီး ပျမ်းမျှနှင့် tail latency တို့လည်း သိသိသာသာ နိမ့်သည်။ နောင် blog တွင် နောက်ထပ်သင်ယူရရှိချက်များကို မျှဝေရန် စီစဉ်ထားသည်။

Python နှင့် ယခု Rust ဝန်ဆောင်မှုသည် Habitat ၏ အစိတ်အပိုင်းတစ်ခုသာ ဖြစ်သည်။ ChatGPT အသုံးပြုသူ ၁ ဘီလီယံကျော်ကို ဝန်ဆောင်မှုပေးရန် online storage ကို လျင်မြန်စွာ တိုးချဲ့ခဲ့ပုံ စီးရီး၏ အပိုင်း ၂ တွင် storage layer နှင့် Habitat က ဒေတာ 500 petabytes ကျော်၊ တစ်စက္ကန့်လျှင် တောင်းဆိုချက် သန်း ၇၀ ကျော်ကို ဝန်ဆောင်မှုပေးပုံတို့အား ဆွေးနွေးမည်။

စွမ်းဆောင်ရည်အမြင့်ဆုံး အတိုင်းအတာရှိ OLTP စနစ်များကို လုပ်ကိုင်လိုပြီး ဤအင်ဂျင်နီယာလုပ်ငန်းမျိုးကို စိတ်ဝင်စားပါက ကျွန်ုပ်တို့အဖွဲ့၏ လစ်လပ်ရာထူးကို ကြည့်ပါ⁠။