Server တစ်ခုစီအတွက် မဟုတ်ဘဲ တစ်ကြိမ်သာ ပေးပို့တဲ့ Alert များ
ကျွန်ုပ်တို့ရဲ့ လည်ပတ်မှု alert တစ်ခုဖြစ်တဲ့ builder တစ်ယောက်ရဲ့ published app အတွက် "credits နည်းနေပြီ" alert ဟာ တစ်ရက်ကို အများဆုံး တစ်ကြိမ်သာ ရောက်သင့်ပါတယ်။ တစ်နေ့ လွှမ်းမိုးတဲ့ နေ့လည်တစ်ခုမှာ ဒါဟာ ငါးကြိမ် ရောက်လာခဲ့ပါတယ်။ အကြောင်းရင်းကတော့ API ရဲ့ မိတ္တူတစ်ခုစီက ကိုယ့် memory ထဲမှာ ပို့ပြီးသား alert တွေကို မှတ်ထားခဲ့ကြလို့ပါ။ server နှစ်ခုက နှစ်ကြိမ် ပို့ခဲ့ပြီး၊ deploy တိုင်းက အဲဒီ memory ကို ဖျက်လိုက်ပြီး ထပ်ပို့ခွင့် ပေးခဲ့ပါတယ်။ တူညီတဲ့ ပုံစံက background job တစ်ခုကိုလည်း အလုပ် နှစ်ကြိမ် လုပ်စေခဲ့ပါတယ်။ ယခု နှစ်ခုလုံးက shared store မှတဆင့် ညှိနှိုင်းပြီး၊ ထို store မရှိတော့ရင် ဘေးကင်းတဲ့ ဘက်ကို ရွေးပြီး ကျရှုံးပါတယ်။
လက္ခဏာ
Mythex က အဖွဲ့ကို ဘာတစ်ခုခု လိုအပ်တဲ့အခါ alert တွေ ပို့ပါတယ်။ ဥပမာ service တစ်ခု ပိတ်သွားတာ၊ job တစ်ခု ရပ်သွားတာ၊ သို့မဟုတ် publish ထားတဲ့ app ရဲ့ credits ကုန်ခါနီးနေတာ။ alert တစ်ခုစီမှာ dedupe window ရှိပြီး ဒါက တူညီတဲ့ alert ကို တစ်ကြိမ်သာ ပို့မယ့် ကာလ ဖြစ်ပါတယ်။ credits နည်းတဲ့ alert အတွက် ဒီ window က ၂၄ နာရီပါ။
နေ့လည်တစ်နေ့တည်းမှာ တူညီတဲ့ alert ငါးခု ရောက်လာတာက window က မစောင့်နိုင်တော့တာကို ဆိုလိုပါတယ်။ ပိုဆိုးတာက ၎င်းတို့ က အတွဲလိုက် ရောက်လာတာ ဖြစ်ပြီး၊ တစ်ခုနဲ့တစ်ခု ခန့်မှန်းခြေ မိနစ် ၁၁ ခြား ရောက်လာပါတယ်။
ဘာကြောင့် ဖြစ်ခဲ့တာလဲ
ကျွန်ုပ်တို့ရဲ့ alerts package က dedupe ကို memory ထဲမှာ ထားခဲ့ပါတယ်။ ဆိုလိုတာက "alert key → နောက်ဆုံးပို့ခဲ့တဲ့ အချိန်" ဇယားတစ်ခုကို run နေတဲ့ process ထဲမှာ ထားခဲ့တာပါ။ ဒါဟာ process တစ်ခုတည်း ရှိပြီး ဘယ်တော့မှ ပြန် မစတာဆိုရင် အလုပ်လုပ်ပါတယ်။ ထုတ်လုပ်မှု (production) မှာတော့ ဒါတွေ မရှိပါဘူး:
- API replica နှစ်ခု။ Production မှာ API မိတ္တူ နှစ်ခု ရှိပါတယ်။ တစ်ခုစီမှာ ကိုယ်ပိုင် ဇယားရှိလို့ alert ကို တစ်ကြိမ်စီ ပို့ခဲ့ကြပါတယ်။ ဒါက အတွဲတွေပါ။
- Deploy များ။ deploy တိုင်းက replica နှစ်ခုလုံးကို process အသစ်နဲ့ ဇယားလွတ်တွေနဲ့ အစားထိုးပါတယ်။ deploy ပြီးတဲ့အခါ alert က တစ်ခါမှ မပို့ဖူးသလို ထပ်ပို့ခဲ့ပါတယ်။
alert အတွဲတစ်ခုထဲက မိနစ် ၁၁ ခန့်ကွာတာက ဒီ alert ကို မြှင့်တင်တဲ့ job ကနေ ရလာတာ ဖြစ်ပါတယ်။ ၎င်းက replica နှစ်ခုစလုံးမှာ run ပြီး lock ယူပါတယ်။ ဒါကြောင့် replica တွေက အလှည့်ကျ နိုင်ကြပြီး၊ သူ့အလှည့် ရောက်တိုင်း alert ကို မြှင့်တင်ခဲ့ကြတာ ဖြစ်ပါတယ်။
ဒီ code ထဲမှာ နောက်ထပ် ပိုတိတ်ဆိတ်တဲ့ bug တစ်ခုလည်း ရှိပါတယ်။ ဇယား အဆုံးမရှိ ကြီးမလာအောင် key ၅၀၀ ရောက်တိုင်း ကိုယ်ကိုယ်တိုင် prune လုပ်ပြီး၊ အသက်ကြီးတဲ့ entry အားလုံး (မိနစ် ၁၅ ထက်ကြီးတာ) ကို ဖျက်ပစ်ပါတယ်၊ သူ့ window ဘာပဲဖြစ်ဖြစ်။ load ကြီးတဲ့အချိန်မှာ ၂၄ နာရီ dedupe က မိနစ် ၁၅ ခန့်သာ ကြာခဲ့ပါတယ်။
ပြင်ဆင်ချက်
alert တစ်ခုအတွက် shared record တစ်ခု
API က alert ပို့ခင်မှာ alert ရဲ့ dedupe key ကို Redis မှာ အခု ယူလိုက်ပါတယ်။ Redis ဆိုတာ replica နှစ်ခုစလုံး ချိတ်ဆက်တဲ့ shared memory store ဖြစ်ပြီး API ပြန်စတဲ့အခါမှာ မပျက်ပါဘူး။ claim က "ဒီ key မရှိရင်သာ သတ်မှတ်ပြီး window ကုန်ရင် သက်တမ်းကုန်စေ" ဆိုတဲ့ လုပ်ဆောင်ချက် တစ်ခုတည်း ဖြစ်ပါတယ်။ ပထမဆုံး claim လုပ်တဲ့ replica က alert ပို့ပြီး၊ တခြားတစ်ခုက key ယူပြီးသား တွေ့တဲ့အခါ တိတ်ဆိတ်နေပါတယ်။ deploy ပြီးနောက် process အသစ်က key ကို ဆက်တွေ့ပါတယ်။
key နဲ့ window ကို alerts package သုံးတဲ့ စည်းမျဉ်း တစ်ခုတည်းကနေ ယူပြီး အခု နှစ်ခုကြား တူညီစွာ သုံးပါတယ်၊ ဒါကြောင့် "တူတဲ့ alert" ဆိုတာကို နှစ်ခုက မတူအောင် မဖြစ်နိုင်ပါ။
ပိတ်မှာထက် ဖွင့်ထားပါ
အရေးကြီးဆုံး ဆုံးဖြတ်ချက်က Redis ကို မရောက်နိုင်တဲ့အခါ ဘာလုပ်မလဲ ဆိုတာပါ။ ကျွန်ုပ်တို့က alert ကို ဘာပဲဖြစ်ဖြစ် ပို့ဖို့ ရွေးပါတယ်။ Redis ပိတ်နေရင် ဒါမှမဟုတ် ၁.၅ စက္ကန့်အတွင်း မဖြေရင် alert ထွက်ပါမယ်။ alert ထပ်နေတာက ဆူညံမှုပါ။ alert ပျောက်သွားတာက လူတစ်ယောက် အသိမပေးခံရတာပါ။
အရေးကြီးဆုံး P0 alert တွေကို dedupe က ဘယ်တော့မှ မတားပါ။
entry တစ်ခုစီက ကိုယ်ပိုင် window ရှိတယ်
alerts package ရဲ့ ကိုယ်ပိုင် memory dedupe မှာ entry တစ်ခုစီက သူ့ window ဘယ်အချိန် ကုန်မလဲ သိမ်းထားပြီး prune က window ကုန်ပြီးသား entry တွေကိုသာ ဖျက်ပါတယ်။ ၂၄ နာရီ key က alert တခြား ဘယ်လောက်ရောက်လာစေကာမှ ၂၄ နာရီ ရှိနေပါတယ်။
တူညီတဲ့ bug တစ်ခု နောက်နေရာမှာ
တူညီတဲ့ ပုံစံက background work တစ်ခုကိုလည်း နှစ်ဆ လုပ်စေခဲ့ပါတယ်။ ၎င်းက workspace တစ်ခုစီရဲ့ status မှတ်တမ်းကို sandbox provider နဲ့ ညှိနေတဲ့ reconciliation job ဖြစ်ပါတယ်။ pass တိုင်းက account ထဲက sandbox အားလုံးကို စာရင်းပြုပါတယ်၊ production မှာထောင်ချီ၊ ခန့်မှန်းခြေ စက္ကန့် ၅၊ နဲ့ run နေ သို့မဟုတ် ရပ်ထားတဲ့ project အားလုံး။ replica နှစ်ခုစလုံးက မိနစ် ၂ တိုင်း run ခဲ့ကြပါတယ်။
ရေးတာတွေက idempotent ဖြစ်ပါတယ်။ ဆိုလိုတာက နှစ်ကြိမ် run ရင်လည်း တစ်ကြိမ် run တဲ့ ရလဒ်အတူတူ ဖြစ်ပါတယ်၊ ဒါကြောင့် ဘာမှ မပျက်ခဲ့ပါဘူး။ အလုပ်ကိုသာ နှစ်ဆ လုပ်ခဲ့တာပါ။ ယခု မိနစ် ၂ window တစ်ခုစီကို usage meter တွေ claim လုပ်တဲ့ နည်းအတိုင်း Redis မှာ claim လုပ်ပြီး၊ claim ရတဲ့ replica တစ်ခုတည်းသာ pass ကို run ပါတယ်။ Redis ကို မရောက်နိုင်ရင် pass ကို ဆက် run ပါတယ်၊ အလုပ်နှစ်ကြိမ် လုပ်တာက အန္တရာယ်မရှိပါ၊ မလုပ်တာက ရှိပါတယ်။
ဘယ်လို စမ်းသပ်ခဲ့လဲ
tests တွေက အမှန်တကယ် setup ကို ပုံဖော်ပါတယ်။ alert module ကို "replica" နှစ်ခုအဖြစ် နှစ်ကြိမ် load လုပ်ပြီး တူညီတဲ့ shared store တစ်ခုကို ညွှန်ပြပါတယ်၊ တစ်ခုစီက alert တူတူ မြှင့်တင်ပြီး၊ "deploy ပြီးနောက်" ကို ကိုယ်စားပြုဖို့ ဒုတိယ သန့်စင်တဲ့ copy တစ်ခု load ပြီး ထပ်မြှင့်တင်ပါတယ်။ alert တစ်ခုသာ ပို့ပါတယ်။ အခြား tests တွေက builder တခြားတစ်ယောက်ရဲ့ alert က ဆက်ပို့တာ၊ P0 ကို replica နှစ်ခုစလုံးက ပို့တာ၊ Redis ပိတ်နေတဲ့အခါ သို့မဟုတ် timeout ကျော်ရင်လည်း alert ဆက်ပို့တာတို့ကို စစ်ပါတယ်။ prune fix အတွက်လည်း test ပါပြီး၊ နာရီ ၂၄ key ဟာ မိနစ် ၂၀ နောက်မှာ ရောက်လာတဲ့ အခြား alert ၆၀၀ ကို ရှင်သန်တာ ဖြစ်ပါတယ်။
reconciliation job အတွက်ကတော့ tick နှစ်ခု တစ်ပြိုင်နက် နဲ့ တူတူ window ထဲက တတိယ tick တို့ရဲ့ ရလဒ် list တစ်ခုတည်းသာ ထွက်ပါတယ်။
ကျွန်ုပ်တို့ ရလိုက်တဲ့ သင်ခန်းစာများ
- In-memory state က process တစ်ခုချင်းစီအတွက်ပဲ။ server တွေကြား မှန်ရမယ့်အရာ ("တစ်ကြိမ်သာ ပို့ပြီး", "တစ်ကြိမ်သာ run") က သူတို့ မျှဝေတဲ့ နေရာမှာ ရှိရမယ်။
- Deploy က restart ပါ။ နောက် restart ထိ ကျန်ရစ်တဲ့ state က ပုံမှန် အလုပ်နေ့တစ်နေ့ကိုတောင် မကျန်ပါ။
- ဘယ်လို ကျရှုံးမလဲ ဆုံးဖြတ်ပါ။ alert အတွက် shared store ပိတ်နေတာ ဆိုရင် alert လျော့တာ မဟုတ်ဘဲ ပိုတာ ဖြစ်သင့်ပါတယ်။
- instance ကိုသာ မကြည့်ဘဲ pattern ကို ရှာပါ။ alert က ဆူညံဆုံး ဖြစ်ခဲ့တာ၊ နှစ်ဆလုပ်နေတဲ့ reconciliation job ကတော့ တူတဲ့ bug ကို တိတ်ဆိတ်စွာ အလုပ်ပိုလုပ်စေခဲ့တာ ဖြစ်ပါတယ်။
ဒါတွေက Mythex အတွင်းက မမြင်ရပါဘူး။ platform ကို ငြိမ်အောင် ဘယ်လိုထိန်းသလဲ သိချင်ရင် deploy တွေကို 502 error သုည အထိ ဘယ်လိုချလဲ နဲ့ swap file မရှိတဲ့ ပြဿနာ ကို ကြည့်ပါ။ service တစ်ခုကို နှစ်ခု ပိုပြေးတာ အကြောင်း အခြေခံ သိချင်ရင် server ဆိုတာ ဘာလဲ လမ်းညွှန်ကို ကြည့်ပါ။