🥇Postgres အင်္ဂါနေ့ နံပါတ် 5- “PostgreSQL နှင့် Kubernetes။ CI/CD၊ စမ်းသပ်မှု အလိုအလျောက်စနစ်»

ပြီးခဲ့သည့်နှစ်ကုန်ပိုင်းတွင် ရုရှား PostgreSQL အသိုင်းအဝိုင်း၏ နောက်ထပ် တိုက်ရိုက်ထုတ်လွှင့်မှုတစ်ခု ဖြစ်ပွားခဲ့သည်။ #RuPostgres၎င်း၏ပူးတွဲတည်ထောင်သူ Nikolai Samokhvalov သည် Kubernetes ၏အကြောင်းအရာတွင်ဤ DBMS အကြောင်း Flant နည်းပညာဒါရိုက်တာ Dmitry Stolyarov နှင့်စကားပြောခဲ့သည်။

ကျွန်ုပ်တို့သည် ဤဆွေးနွေးမှု၏ အဓိကအပိုင်း၏ စာသားမှတ်တမ်းကို ထုတ်ဝေနေပြီး၊ အသိုင်းအဝိုင်း YouTube ချန်နယ် ဗီဒီယို အပြည့်အစုံ တင်ထားသည်-

ဒေတာဘေ့စ်များနှင့် Kubernetes

NS: ယနေ့ ကျွန်ုပ်တို့သည် VACUUM နှင့် CHECKPOINT များအကြောင်း မပြောပါ။ Kubernetes အကြောင်း ပြောချင်ပါတယ်။ မင်းမှာ နှစ်ပေါင်းများစွာ အတွေ့အကြုံရှိတယ်ဆိုတာ ငါသိတယ်။ မင်းရဲ့ဗီဒီယိုတွေကို ငါကြည့်ခဲ့ပြီး အဲဒီထဲကတချို့ကိုတောင် ပြန်ကြည့်ရအောင်... အချက်ကို တည့်တည့်ကြည့်ရအောင်- ဘာလို့ K8s မှာ Postgres ဒါမှမဟုတ် MySQL က ဘာကြောင့်လဲ။

DS: ဤမေးခွန်းအတွက် တိကျသောအဖြေမရှိနိုင်ပါ။ ဒါပေမယ့် ယေဘူယျအားဖြင့် ဒါက ရိုးရှင်းမှုနဲ့ အဆင်ပြေမှု... အလားအလာပါ။ လူတိုင်းက စီမံခန့်ခွဲတဲ့ ဝန်ဆောင်မှုတွေကို လိုချင်ကြပါတယ်။

NS: ဘယ်လိုလဲ။ RDSအိမ်မှာသာ

DS:Yes: RDS လိုပဲ၊ ဘယ်နေရာမှာမဆို။

NS“ဘယ်နေရာမှာမဆို” သည် ကောင်းသောအချက်ဖြစ်သည်။ ကုမ္ပဏီကြီးများတွင် အရာအားလုံးသည် မတူညီသောနေရာများတွင် ရှိနေသည်။ ကုမ္ပဏီကြီးတစ်ခုဆိုရင် အဆင်သင့်လုပ်ထားတဲ့ ဖြေရှင်းချက်ကို ဘာကြောင့်မယူတာလဲ။ ဥပမာအားဖြင့်၊ Nutanix တွင် ၎င်း၏ကိုယ်ပိုင်တိုးတက်မှုများ၊ အခြားကုမ္ပဏီများ (VMware...) တွင်တူညီသော "RDS၊ အိမ်၌သာ" ရှိသည်။

DS: သို့သော် အချို့သောအခြေအနေများတွင်သာ လုပ်ဆောင်မည့် သီးခြားအကောင်အထည်ဖော်မှုအကြောင်း ကျွန်ုပ်တို့ပြောနေပါသည်။ Kubernetes အကြောင်းပြောရင်၊ အခြေခံအဆောက်အဦ အမျိုးမျိုးရှိတယ် (K8s မှာ ဖြစ်နိုင်တယ်)။ အခြေခံအားဖြင့်၎င်းသည် cloud အတွက် APIs များအတွက်စံတစ်ခုဖြစ်သည်။

NS: ဒါကလည်း အခမဲ့ပါ။

DS: ဒါ သိပ်အရေးမကြီးပါဘူး။ စျေးကွက်၏ အလွန်ကြီးမားသော အပိုင်းမဟုတ်သည့်အတွက် လွတ်လပ်မှုသည် အရေးကြီးပါသည်။ တခြားအရာတစ်ခုက အရေးကြီးတယ်... အစီရင်ခံစာကို မှတ်မိနေလိမ့်မယ်"ဒေတာဘေ့စ်များနှင့် Kubernetes"?

NS: ဟုတ်ကဲ့။

DS: အဲဒါကို အရမ်းဝဝါးထင်ထင် လက်ခံခဲ့တာကို ငါသဘောပေါက်တယ်။ လူအချို့က ကျွန်ုပ်ပြောသည်မှာ- "ယောက်ျားတို့၊ Kubernetes တွင် ဒေတာဘေ့စ်များအားလုံးကို ရအောင်ယူကြပါစို့!"၊ အချို့က ၎င်းတို့သည် ဆိုးရွားလှသော စက်ဘီးများဟု ဆုံးဖြတ်ထားချိန်တွင် အချို့က ထင်မြင်ယူဆကြသည်။ ဒါပေမယ့် လုံးဝခြားနားတဲ့ အရာတစ်ခုကို ကျွန်တော်ပြောချင်ပါတယ်- “ဘာတွေဖြစ်နေလဲ၊ ဘယ်လိုအခက်အခဲတွေရှိလဲ၊ ဘယ်လိုဖြေရှင်းနိုင်မလဲဆိုတာကို ကြည့်လိုက်ပါ။ Kubernetes ဒေတာဘေ့စ်များကို ယခု အသုံးပြုသင့်ပါသလား။ ထုတ်လုပ်မှု? ကောင်းပြီ၊ မင်းကြိုက်မှသာလျှင်... တစ်ချို့အရာတွေကို လုပ်ပါ။ ဒါပေမယ့် dev တစ်ယောက်အတွက်၊ ငါအဲဒါကို အကြံပေးတယ်လို့ ပြောလို့ရပါတယ်။ ဆော့ဖ်ဝဲအတွက်၊ ပတ်ဝန်းကျင်ဖန်တီးခြင်း/ဖျက်ခြင်း၏ သွက်လက်တက်ကြွမှုသည် အလွန်အရေးကြီးပါသည်။"

NS: dev အားဖြင့်၊ သင်သည် ထုတ်ကုန်မဟုတ်သော ပတ်ဝန်းကျင်အားလုံးကို ဆိုလိုပါသလား။ ဇာတ်ညွှန်း၊ QA...

DS: perf stands အကြောင်းပြောရင်၊ လိုအပ်ချက်တွေက အတိအကျရှိတာကြောင့် ဖြစ်နိုင်ပါတယ်။ ဇာတ်ခုံအတွက် အလွန်ကြီးမားသော ဒေတာဘေ့စ် လိုအပ်သည့် အထူးကိစ္စရပ်များအကြောင်း ပြောနေမည်ဆိုလျှင်၊ ယင်းသည် အငြိမ်မနေဘဲ၊ သက်တမ်းရှည်သော ပတ်ဝန်းကျင်တစ်ခုဖြစ်ပါက၊ K8s တွင်ရှိသော ဒေတာဘေ့စ်ထားရှိခြင်း၏ အကျိုးကျေးဇူးကား အဘယ်နည်း။

NS: မရှိပါ။ သို့သော် ကျွန်ုပ်တို့သည် ငြိမ်သက်နေသော ပတ်ဝန်းကျင်များကို မည်သည့်နေရာတွင် မြင်နိုင်သနည်း။ ငြိမ်သက်နေသော ပတ်ဝန်းကျင်သည် မနက်ဖြန်တွင် အသုံးမဝင်တော့ပါ။

DS: Staging သည် တည်ငြိမ်နိုင်သည်။ ငါတို့မှာ ဖောက်သည်တွေရှိတယ်...

NS: ဟုတ်တယ်၊ ငါလည်း တစ်ခုရှိတယ်။ သင့်တွင် 10 TB ဒေတာဘေ့စ်နှင့် 200 GB အဆင့်ရှိလျှင် ပြဿနာကြီးတစ်ခုဖြစ်သည်။

DS: ငါ့မှာ အရမ်းမိုက်တဲ့ ကိစ္စရှိတယ်။ စတိတ်စင်ပေါ်တွင် ပြောင်းလဲမှုများပြုလုပ်သည့် ထုတ်ကုန်ဒေတာဘေ့စ်တစ်ခုရှိသည်။ ခလုတ်တစ်ခုပါရှိသည်- "ထုတ်လုပ်မှုသို့ထွက်ပါ" ။ ဤပြောင်းလဲမှုများ - deltas - ထုတ်လုပ်မှုတွင် (၎င်းတို့ကို API မှတဆင့်ရိုးရှင်းစွာထပ်တူပြုပုံရသည်) ကိုထည့်သွင်းထားသည်။ ဤသည်မှာ အလွန်ထူးခြားဆန်းပြားသော ရွေးချယ်မှုတစ်ခုဖြစ်သည်။

NS: RDS မှာ ဒါမှမဟုတ် Heroku မှာထိုင်နေတဲ့ တောင်ကြားမှာရှိတဲ့ startup တွေကို ငါမြင်ဖူးတယ် - ဒါတွေက လွန်ခဲ့တဲ့ 2-3 နှစ်လောက်က ဇာတ်လမ်းတွေဖြစ်ပြီး အမှိုက်ပုံကြီးကို သူတို့ရဲ့ laptop မှာ ဒေါင်းလုဒ်လုပ်ကြတယ်။ အဘယ်ကြောင့်ဆိုသော် ဒေတာဘေ့စ်သည် 80 GB သာရှိသေးပြီး လက်ပ်တော့တွင် နေရာလွတ်ရှိနေသောကြောင့်ဖြစ်သည်။ ထို့နောက် ၎င်းတို့သည် မတူညီသောတိုးတက်မှုများကိုလုပ်ဆောင်ရန် ဒေတာဘေ့စ် 3 ခုရှိရန် လူတိုင်းအတွက် အပိုဒစ်များကို ဝယ်ယူကြသည်။ ဒါကလည်း ဒီလိုပါပဲ။ သူတို့ဟာ ထုတ်ကုန်တွေကို အဆင့်မြှင့်တင်ဖို့ မကြောက်ကြဘူးလို့လည်း ကျွန်တော်မြင်ပါတယ် - ကုမ္ပဏီအပေါ်မှာ အများကြီးမူတည်ပါတယ်။ ဒါပေမယ့် သူတို့ အရမ်းကြောက်ကြပြီး သူတို့မှာ အချိန်နဲ့လက် မလုံလောက်တာကို ကျွန်တော်မြင်တယ်။ ဒါပေမယ့် ဒီအကြောင်းအရာကို ဆက်မသွားခင် Kubernetes အကြောင်း ကြားချင်ပါတယ်။ ဘယ်သူကမှ ကုန်ပစ္စည်းမပေါ်သေးဘူးဆိုတာကို ငါ မှန်ကန်စွာ နားလည်ပါသလား။

DS: ကျွန်ုပ်တို့တွင် သေးငယ်သောဒေတာဘေ့စ်များရှိသည်။ ကျွန်ုပ်တို့သည် ပုံတူများပြုလုပ်ရန် အလွန်ပျင်းရိခဲ့သည့်အတွက် ဆယ်ဂဏန်းဂစ်ဂါဘိုက်နှင့် အရေးမပါသောဝန်ဆောင်မှုများအကြောင်း ပြောနေပါသည်။ Kubernetes အောက်တွင် ပုံမှန်သိုလှောင်မှုရှိကြောင်း ပေးထားသည်။ ဤဒေတာဘေ့စ်သည် သိုလှောင်မှုစနစ်၏ထိပ်တွင် VMware တွင် အခြေအနေအရ အတုအယောင်စက်တစ်ခုတွင် အလုပ်လုပ်ခဲ့သည်။ ငါတို့က အဲဒါကို ချထားတယ်။ PV ယခု ကျွန်ုပ်တို့သည် ၎င်းကို စက်မှစက်သို့ လွှဲပြောင်းနိုင်ပြီဖြစ်သည်။

NS: 100 GB အထိ အရွယ်အစားရှိသော ဒေတာဘေ့စ်များကို ကောင်းသောဒစ်များနှင့် ကွန်ရက်ကောင်းကောင်းတွင် မိနစ်အနည်းငယ်အတွင်း ထုတ်ယူနိုင်သည် မဟုတ်လား။ တစ်စက္ကန့်လျှင် 1 GB အမြန်နှုန်းသည် ထူးခြားဆန်းပြားတော့မည်မဟုတ်ပါ။

DS: ဟုတ်ကဲ့၊ linear operation အတွက် ဒါက ပြဿနာမဟုတ်ပါဘူး။

NS: ကောင်းပြီ၊ ငါတို့ စဉ်းစားစရာပဲ ကွာ။ ထုတ်ကုန်မဟုတ်သော ပတ်ဝန်းကျင်အတွက် Kubernetes ကို ကျွန်ုပ်တို့ စဉ်းစားနေပါက ကျွန်ုပ်တို့ ဘာလုပ်သင့်သနည်း။ ဒါကို Zalando မှာတွေ့တယ်။ အော်ပရေတာလုပ်ပါ။Crunchy တွင်၊ လွှအခြားရွေးချယ်စရာများ ရှိသေးသည်။ အဲ OnGres - ဒါက စပိန်က ကျွန်တော်တို့ရဲ့ သူငယ်ချင်းကောင်း Alvaro ပါ၊ သူတို့လုပ်တဲ့အရာက အဓိကအားဖြင့် မဟုတ်ဘူး။ အော်ပရေတာနှင့် ဖြန့်ဖြူးမှုတစ်ခုလုံး (StackGres) ထို့ကြောင့်၊ Postgres ကိုယ်တိုင်အပြင်၊ Envoy proxy ကို အရန်ကူးယူရန်လည်း ဆုံးဖြတ်ခဲ့သည်။

DSသံတမန် : ဘာအတွက်လဲ။ အထူးသဖြင့် Postgres အသွားအလာကို ဟန်ချက်ညီစေသလား။

NSဟုတ်တယ်။ ဆိုလိုတာက သူတို့က ဒါကို မြင်တယ်- မင်းယူရင် Linuxdistribution နဲ့ kernel အကြောင်းပြောရင် ပုံမှန် PostgreSQL က kernel ဖြစ်ပြီး သူတို့က cloud-friendly ဖြစ်ပြီး Kubernetes မှာ run တဲ့ distribution တစ်ခုလုပ်ချင်ကြတယ်။ components တွေ (backup တွေ၊ etc.) ကို ချိတ်ဆက်ပြီး ကောင်းကောင်းအလုပ်လုပ်အောင် debug လုပ်နေတယ်။

DS: အရမ်းမိုက်တယ်! အခြေခံအားဖြင့်၎င်းသည်သင်၏ကိုယ်ပိုင်စီမံထားသော Postgres ကိုဖန်တီးရန်ဆော့ဖ်ဝဲဖြစ်သည်။

NS: U LinuxDistribution တွေမှာ အမြဲတမ်းပြဿနာတစ်ခုရှိနေပါတယ်။ အဲဒါကတော့ hardware အားလုံးကို support လုပ်ဖို့ driver တွေကို ဘယ်လိုဖန်တီးရမလဲဆိုတာပါပဲ။ ပြီးတော့ Kubernetes မှာ အလုပ်လုပ်မယ်လို့ သူတို့ထင်နေကြပါတယ်။ Zalando ရဲ့ AWS ကို မကြာသေးခင်ကမှ မှီခိုနေရတာကို ကျွန်တော်တို့မြင်တွေ့ခဲ့ရပြီး အဲဒါက သိပ်မကောင်းပါဘူး။ သီးခြား infrastructure တစ်ခုကို မှီခိုနေစရာ မလိုပါဘူး။ ဒါဆိုရင် ဘာကိုဆိုလိုတာလဲ။

DS: Zalando သည် မည်သို့သော အခြေအနေသို့ ရောက်ရှိခဲ့သည်ကို ကျွန်ုပ်အတိအကျမသိရသော်လည်း ယခု Kubernetes သိုလှောင်မှုတွင် ယေဘုယျနည်းလမ်းဖြင့် ဒစ်ခ်အရန်ကူးယူရန် မဖြစ်နိုင်သည့်နည်းလမ်းဖြင့် ပြုလုပ်ထားသည်။ မကြာသေးမီက ပုံမှန်ဗားရှင်း - နောက်ဆုံးဗားရှင်း CSI သတ်မှတ်ချက်များ — ကျွန်ုပ်တို့သည် လျှပ်တစ်ပြက်ပုံများကို တတ်နိုင်သမျှ ပြုလုပ်ထားသော်လည်း ၎င်းကို မည်သည့်နေရာတွင် အကောင်အထည်ဖော်မည်နည်း။ ရိုးရိုးသားသားပြောရရင် အရာအားလုံးက အရမ်းကြမ်းနေတုန်းပဲ... AWS, GCE, Azure, vSphere ထိပ်မှာ CSI ကို ကြိုးစားနေပေမယ့် အဲဒါကို စတင်အသုံးပြုပြီးတာနဲ့ အဆင်သင့်မဖြစ်သေးတာကို တွေ့နိုင်ပါတယ်။

NSထို့ကြောင့် တစ်ခါတစ်ရံတွင် ကျွန်ုပ်တို့သည် အခြေခံအဆောက်အအုံကို အားကိုးနေရပါသည်။ ဒါက နာကျင်မှုတွေ ကြီးထွားလာတဲ့ အစောပိုင်းအဆင့်ပဲလို့ ကျွန်တော်ထင်ပါတယ်။ မေးခွန်း- K8s တွင် PgSQL ကို စမ်းသုံးလိုသော အသစ်များကို သင်မည်သို့ အကြံဉာဏ်ပေးမည်နည်း။ ဘယ်အော်ပရေတာဖြစ်နိုင်မလဲ။

DSပြဿနာကတော့ Postgres က ကျွန်တော်တို့အတွက် 3% ဖြစ်ပါတယ်။ ကျွန်ုပ်တို့ Kubernetes တွင် မတူညီသော ဆော့ဖ်ဝဲလ်များစွာ စာရင်းတစ်ခုလည်း ရှိသည်၊ ကျွန်ုပ်သည် အရာအားလုံးကို စာရင်းပင်မပြုစုပါ။ ဥပမာ၊ Elasticsearch။ အော်ပရေတာများ အများအပြားရှိပါသည်- အချို့မှာ တက်ကြွစွာ ဖွံ့ဖြိုးတိုးတက်နေပြီး အချို့မှာ မဟုတ်ပါ။ ကျွန်ုပ်တို့သည် အော်ပရေတာတွင်ရှိသင့်သည်များကို ကျွန်ုပ်တို့ကိုယ်တိုင်အလေးအနက်ထားရန် လိုအပ်ချက်များကို ရေးဆွဲထားပါသည်။ Kubernetes အတွက် အထူးအော်ပရေတာတစ်ခုတွင် - "Amazon ၏အခြေအနေများတွင် တစ်ခုခုလုပ်ဆောင်ရန် အော်ပရေတာ" တွင် မဟုတ်ဘဲ... တကယ်တော့၊ ကျွန်ုပ်တို့ (= သုံးစွဲသူအားလုံးနီးပါး) သည် အော်ပရေတာတစ်ခုတည်းကို အသုံးပြုသည် - Redis အတွက် (ကျွန်ုပ်တို့ သူ့အကြောင်း ဆောင်းပါးတစ်ပုဒ်ကို မကြာမီ ထုတ်ဝေပါမည်).

NS: MySQL အတွက်ရော မဟုတ်ဘူးလား။ Percona... ၎င်းတို့သည် ယခုအခါ MySQL၊ MongoDB နှင့် Postgres တို့တွင် လုပ်ဆောင်နေသောကြောင့် ၎င်းတို့သည် ဒေတာဘေ့စ်အားလုံးအတွက်၊ cloud ပံ့ပိုးပေးသူအားလုံးအတွက် universal solution တစ်မျိုးမျိုးကို ဖန်တီးရမည်ဖြစ်ပါသည်။

DS: MySQL အတွက် အော်ပရေတာများကို ကြည့်ရန် ကျွန်ုပ်တို့တွင် အချိန်မရှိပါ။ ဒါက ကျွန်တော်တို့ရဲ့ အဓိက အာရုံစိုက်မှု မဟုတ်သေးပါဘူး။ MySQL သည် standalone တွင် ကောင်းမွန်စွာ အလုပ်လုပ်ပါသည်။ ဒေတာဘေ့စ်တစ်ခုဖွင့်ရုံနဲ့ စတင်နိုင်ရင် အော်ပရေတာတစ်ခုကို ဘာကြောင့်သုံးရသလဲ... Docker container ကို Postrges နဲ့ ဖွင့်နိုင်သလို ရိုးရှင်းတဲ့နည်းလမ်းနဲ့ စတင်နိုင်ပါတယ်။

NS: ဒါကလည်း မေးစရာရှိတယ်။ အော်ပရေတာ လုံးဝ မရှိဘူးလား?

DS: ဟုတ်ကဲ့၊ ကျွန်ုပ်တို့၏ 100% တွင် အော်ပရေတာမပါဘဲ PostgreSQL လည်ပတ်နေပါသည်။ အခုထိ။ Prometheus နှင့် Redis အတွက် အော်ပရေတာအား ကျွန်ုပ်တို့ တက်ကြွစွာ အသုံးပြုပါသည်။ ကျွန်ုပ်တို့တွင် Elasticsearch အတွက် အော်ပရေတာတစ်ခုကို ရှာရန် အစီအစဉ်ရှိသည် - ၎င်းသည် 100% သောကိစ္စများတွင် Kubernetes တွင်ထည့်သွင်းလိုသောကြောင့် "မီးလောင်နေသည်" အဖြစ်ဆုံးဖြစ်သည်။ MongoDB ကိုလည်း Kubernetes တွင် အမြဲထည့်သွင်းထားကြောင်း သေချာစေလိုပါသည်။ ဤတွင် အချို့သော ဆန္ဒများ ပေါ်လာသည် - ဤကိစ္စများတွင် တစ်စုံတစ်ခု ပြီးမြောက်နိုင်သည်ဟူသော ခံစားချက်မျိုး ရှိပါသည်။ ပြီးတော့ ကျွန်တော်တို့ Postgres ကိုတောင် မကြည့်ဘူး။ ဟုတ်ပါတယ်၊ ကွဲပြားတဲ့ရွေးချယ်စရာတွေရှိတယ်ဆိုတာ ကျွန်တော်တို့သိပါတယ်၊ ဒါပေမယ့် တကယ်တော့ ကျွန်တော်တို့မှာ သီးခြားရပ်တည်ခွင့်ရှိပါတယ်။

Kubernetes တွင် စမ်းသပ်ရန်အတွက် DB

NS: စမ်းသပ်မှု ခေါင်းစဉ်ကို ဆက်သွားကြရအောင်။ DevOps ရှုထောင့်မှ ဒေတာဘေ့စ်သို့ ပြောင်းလဲမှုများကို မည်သို့ထုတ်မည်နည်း။ မိုက်ခရိုဝန်ဆောင်မှုများ၊ ဒေတာဘေ့စ်များစွာ ရှိပြီး တစ်စုံတစ်ခုသည် တစ်ချိန်လုံး တစ်နေရာတွင် ပြောင်းလဲနေသည်။ ပုံမှန် CI/CD ကို DBMS ရှုထောင့်မှ စီစဥ်အောင် ပြုလုပ်နည်း။ မင်းရဲ့ချဉ်းကပ်ပုံကဘာလဲ။

DS: အဖြေတစ်ခုတော့ မရနိုင်ပါ။ ရွေးချယ်စရာများစွာရှိပါသည်။ ပထမအချက်မှာ ကျွန်ုပ်တို့ထုတ်လိုသော အခြေခံအရွယ်အစားဖြစ်သည်။ ကုမ္ပဏီများသည် dev နှင့် stage တွင် prod database မိတ္တူထားရှိခြင်းအပေါ် ကွဲပြားခြားနားသော သဘောထားရှိကြောင်း သင်ကိုယ်တိုင်ပြောခဲ့သည်။

NS: GDPR ရဲ့ အခြေအနေတွေအရတော့ သူတို့က ပိုသတိထားနေကြတယ်လို့ ထင်ပါတယ်... ဥရောပမှာ သူတို့ ဒဏ်ငွေတွေ စသွင်းနေပြီလို့ ပြောလို့ရပါတယ်။

DS: ဒါပေမယ့် ထုတ်လုပ်မှုကနေ အမှိုက်သိမ်းပြီး ရှုပ်ယှက်ခတ်နေတဲ့ ဆော့ဖ်ဝဲကို မကြာခဏ ရေးနိုင်ပါတယ်။ ထုတ်ကုန်ဒေတာကို ရရှိသည် (လျှပ်တစ်ပြက်ရိုက်ချက်၊ အမှိုက်ပုံ၊ ဒွိမိတ္တူ...)၊ သို့သော် ၎င်းကို အမည်ဝှက်ထားသည်။ ယင်းအစား၊ မျိုးဆက် script များ ရှိနိုင်သည်- ၎င်းတို့သည် ဖိုင်တွဲများ သို့မဟုတ် ကြီးမားသော ဒေတာဘေ့စ်ကို ထုတ်ပေးသည့် script တစ်ခု ဖြစ်နိုင်သည်။ ပြဿနာမှာ- အခြေခံပုံတစ်ခုဖန်တီးရန် အချိန်မည်မျှကြာသနည်း။ ၎င်းကို အလိုရှိသောပတ်ဝန်းကျင်တွင် အသုံးချရန် အချိန်မည်မျှကြာသနည်း။

ကျွန်ုပ်တို့သည် အစီအစဥ်တစ်ခုသို့ ရောက်လာသည်- အကယ်၍ client တွင် ပုံသေဒေတာအစုံ (ဒေတာဘေ့စ်၏ အနိမ့်ဆုံးဗားရှင်း) ရှိလျှင် ၎င်းတို့ကို မူရင်းအတိုင်း အသုံးပြုပါသည်။ ပြန်လည်သုံးသပ်ခြင်းပတ်ဝန်းကျင်များအကြောင်းပြောနေလျှင် ဌာနခွဲတစ်ခုဖန်တီးသောအခါ၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်း၏ဥပမာတစ်ခုကို ဖြန့်ကျက်ထားပါသည် - ကျွန်ုပ်တို့သည် ထိုနေရာတွင် သေးငယ်သောဒေတာဘေ့စ်တစ်ခုကို ထုတ်လွှတ်ပါသည်။ ဒါပေမယ့် ကောင်းကောင်းထွက်လာတယ်။ option ကိုကျွန်ုပ်တို့သည် တစ်နေ့လျှင် တစ်ကြိမ် (ညဘက်တွင်) ထုတ်လုပ်မှုမှ အမှိုက်ပုံးကိုယူပြီး ၎င်းအပေါ်အခြေခံ၍ ဤတင်ထားသောဒေတာဖြင့် PostgreSQL နှင့် MySQL ဖြင့် Docker container တစ်ခုကို တည်ဆောက်သောအခါ။ အကယ်၍ သင်သည် ဤပုံမှ ဒေတာဘေ့စ်ကို အကြိမ် 50 ချဲ့ရန် လိုအပ်ပါက၊ ၎င်းသည် ရိုးရှင်းပြီး လျင်မြန်စွာ လုပ်ဆောင်သည်။

NS: ရိုးရိုးကူးယူခြင်းဖြင့် ?

DS: ဒေတာကို Docker ပုံတွင် တိုက်ရိုက်သိမ်းဆည်းပါသည်။ အဲဒါတွေ။ ကျွန်ုပ်တို့တွင် 100 GB ရှိသော်လည်း အဆင်သင့်လုပ်ထားသော ပုံတစ်ခုရှိသည်။ Docker ရှိ အလွှာများ၏ ကျေးဇူးကြောင့် ဤပုံကို ကျွန်ုပ်တို့ လိုအပ်သလောက် အကြိမ်များစွာ လျင်မြန်စွာ အသုံးချနိုင်ပါသည်။ နည်းလမ်းက မိုက်ပေမယ့် ကောင်းကောင်းအလုပ်လုပ်တယ်။

NS: ဒါဆို သင်စမ်းသပ်လိုက်တဲ့အခါ Docker ထဲမှာပဲ ပြောင်းလဲသွားမှာပဲ မဟုတ်လား။ Docker တွင် ကူးယူရေးသားပါ - ၎င်းကို စွန့်ပစ်ပြီး ထပ်သွားပါ၊ အရာအားလုံး အဆင်ပြေပါသည်။ အတန်း! အဲဒါကို အပြည့်အဝ သုံးနေပြီလား?

DS: အချိန်ကြာမြင့်စွာ။

NS: ကျွန်ုပ်တို့သည် အလွန်ဆင်တူသောအရာများကို ပြုလုပ်ပါသည်။ ကျွန်ုပ်တို့သာလျှင် Docker ၏ ကော်ပီ-on-write ကို အသုံးမပြုသော်လည်း အခြားတစ်ခုဖြစ်သည်။

DS: ဒါက ယေဘူယျ မဟုတ်ဘူး။ Docker သည် နေရာတိုင်းတွင် အလုပ်လုပ်ပါသည်။

NS: သီအိုရီအရ ဟုတ်ပါတယ်။ ဒါပေမယ့် ကျွန်တော်တို့မှာ module တွေရှိပါတယ်၊ သင်သည် မတူညီသော modules များကို ပြုလုပ်နိုင်ပြီး မတူညီသော ဖိုင်စနစ်များဖြင့် လုပ်ဆောင်နိုင်ပါသည်။ ဒီမှာ ခဏလေး။ Postgres ဘက်မှကြည့်လျှင် ကျွန်ုပ်တို့သည် ဤအရာအားလုံးကို ကွဲပြားစွာကြည့်ပါသည်။ အခု ကျွန်တော် Docker ဘက်ကို ကြည့်လိုက်တော့ အရာအားလုံးက မင်းအတွက် အဆင်ပြေတယ်ဆိုတာ တွေ့လိုက်ရတယ်။ ဥပမာ 1 TB ဒေတာဘေ့စ်သည် ကြီးမားပါက၊ ဤအရာအားလုံးသည် အချိန်ကြာသည်- ညဘက်တွင် လုပ်ဆောင်မှုများ၊ Docker ထဲသို့ အရာအားလုံးကို ထည့်သွင်းခြင်း... နှင့် 5 TB ကို Docker တွင် ထည့်ထားလျှင် ... သို့မဟုတ် အားလုံးအဆင်ပြေပါသလား။

DS: ကွာခြားချက်က ဘာလဲ။ အဲဒါတွေက blobs၊ bits နဲ့ bytes တွေပဲ ဖြစ်ပါတယ်။

NS: ကွာခြားချက်မှာ ဤအရာဖြစ်သည်- ၎င်းကို အမှိုက်ပုံနှင့် ပြန်လည်ရယူခြင်းမှတဆင့် သင်ပြုလုပ်ပါသလား။

DS: လုံးဝမလိုအပ်ပါဘူး။ ဤပုံကိုဖန်တီးရန် နည်းလမ်းများသည် ကွဲပြားနိုင်သည်။

NS: အချို့သော ဖောက်သည်များအတွက်၊ အခြေခံပုံတစ်ပုံကို ပုံမှန်ထုတ်လုပ်မည့်အစား၊ ကျွန်ုပ်တို့သည် ၎င်းကို ခေတ်မီအောင် အဆက်မပြတ်ပြုလုပ်နိုင်ရန် ဖန်တီးထားပါသည်။ ၎င်းသည် အခြေခံအားဖြင့် ပုံစံတူဖြစ်သည်၊ သို့သော် ၎င်းသည် မာစတာထံမှ တိုက်ရိုက်မဟုတ်ဘဲ မှတ်တမ်းတစ်ခုမှတစ်ဆင့် ဒေတာကို လက်ခံရရှိခြင်းဖြစ်သည်။ အရန်များယူသည့် WAL များကို နေ့တိုင်းဒေါင်းလုဒ်လုပ်ထားသည့် ဒွိစုံမှတ်တမ်းတစ်ခု... ထို့နောက် အဆိုပါ WAL များသည် အနည်းငယ်နှောင့်နှေးခြင်းဖြင့် အခြေခံပုံသို့ရောက်ရှိသည် (စာသားအရ 1-2 စက္ကန့်)။ ကျွန်ုပ်တို့သည် ၎င်းကို မည်သည့်နည်းဖြင့် မွေးထုတ်ခဲ့သည် - ယခု ကျွန်ုပ်တို့တွင် မူရင်းအတိုင်း ZFS ရှိသည်။

DS: သို့သော် ZFS ဖြင့် သင်သည် node တစ်ခုတွင်သာ ကန့်သတ်ထားသည်။

NS: ဟုတ်ကဲ့။ ဒါပေမယ့် ZFS မှာလည်း မှော်ဆန်တယ်။ ပေးပို့: ၎င်းနှင့်အတူ သင်သည် လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုကို ပေးပို့နိုင်သော်လည်း (ဤအရာကို ငါတကယ်မစမ်းသပ်ရသေးပါ၊ သို့သော်...) သင်သည် မြစ်ဝကျွန်းပေါ်ဒေသနှစ်ခုကြားသို့ ပေးပို့နိုင်ပါသည်။ PGDATA. အမှန်တော့၊ ကျွန်ုပ်တို့တွင် ထိုသို့သောအလုပ်များအတွက် အမှန်တကယ် မစဉ်းစားမိသော အခြားကိရိယာတစ်ခုရှိသည်။ PostgreSQL ရှိသည်။ pg_rewind"စမတ်" rsync ကဲ့သို့အလုပ်လုပ်သော၊ သင်ကြည့်ရှုရန်မလိုအပ်သောအရာများစွာကိုကျော်သွားသည်၊ အဘယ်ကြောင့်ဆိုသော်ထိုနေရာတွင်ဘာမှမပြောင်းလဲသောကြောင့်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ဆာဗာနှစ်ခုကြားတွင် အမြန်ထပ်တူပြုခြင်းကို ပြုလုပ်နိုင်ပြီး အလားတူနည်းဖြင့် ပြန်ကြည့်နိုင်သည်။

ဒါကြောင့် DBA ဘက်ကနေ၊ ငါတို့က မင်းပြောခဲ့တဲ့အတိုင်းပဲ လုပ်ခွင့်ပြုတဲ့ tool တစ်ခုကို ဖန်တီးဖို့ ကြိုးစားနေတယ်၊ ငါတို့မှာ ဒေတာဘေ့စ်တစ်ခုရှိတယ်၊ ဒါပေမယ့် တစ်ခုခုကို အကြိမ် 50 လောက်နီးပါး တပြိုင်နက်တည်း စမ်းသပ်ချင်တယ်။

DSအကြိမ် 50 ဆိုသည်မှာ Spot instances 50 ကို မှာယူရန် လိုအပ်ပါသည်။

NS: မဟုတ်ဘူး၊ ငါတို့က စက်တစ်ခုတည်းမှာ အကုန်လုပ်တယ်။

DS: ဒါပေမယ့် ဒီဒေတာဘေ့စ်တစ်ခုက terabyte ဆိုရင် အဆ 50 ဘယ်လိုချဲ့မလဲ။ အများစုမှာ အခြေအနေအရ 256 GB RAM လိုအပ်ပါသလား။

NS: ဟုတ်တယ်၊ တစ်ခါတစ်လေ မင်းမှတ်ဉာဏ်အများကြီးလိုတယ်၊ ဒါက ပုံမှန်ပါပဲ။ ဒါပေမယ့် ဒါက ဘဝရဲ့ ဥပမာတစ်ခုပါ။ ထုတ်လုပ်မှုစက်တွင် 96 cores နှင့် 600 GB ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ ဒေတာဘေ့စ်အတွက် 32 cores (ယခု 16 cores ပင်) နှင့် 100-120 GB memory ကို အသုံးပြုပါသည်။

DS: ပြီးတော့ အုပ်ရေ 50 က အဲဒီထဲမှာ အဆင်ပြေလား?

NS: ဒါဆို မိတ္တူတစ်ခုပဲရှိတယ်၊ ဒါဆို copy-on-write (ZFS) အလုပ်လုပ်တယ်... အသေးစိတ်ကို ပြောပြမယ်။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် 10 TB ဒေတာဘေ့စ်တစ်ခုရှိသည်။ ၎င်းတို့သည် ၎င်းအတွက် disk တစ်ခုပြုလုပ်ခဲ့ပြီး ZFS သည်လည်း ၎င်း၏အရွယ်အစားကို 30-40 ရာခိုင်နှုန်းဖြင့် ချုံ့ခဲ့သည်။ ကျွန်ုပ်တို့သည် ဒေါင်းလုဒ်စစ်ဆေးမှုကို မလုပ်သောကြောင့်၊ တိကျသောတုံ့ပြန်မှုအချိန်သည် ကျွန်ုပ်တို့အတွက် အရေးမကြီးပါ- ၎င်းကို ၂ ဆအထိ နှေးစေပါ - ဒါကောင်းပါတယ်။

ကျွန်ုပ်တို့သည် ပရိုဂရမ်မာများ၊ QA၊ DBA စသည်တို့ကို အခွင့်အရေးပေးပါသည်။ 1-2 threads တွင်စမ်းသပ်မှုကိုလုပ်ဆောင်ပါ။ ဥပမာအားဖြင့်၊ ၎င်းတို့သည် ရွှေ့ပြောင်းခြင်းတစ်မျိုးမျိုး လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် တစ်ပြိုင်နက် 10 core မလိုအပ်ပါ - ၎င်းတွင် 1 Postgres နောက်ခံ၊ 1 core လိုအပ်သည်။ ရွှေ့ပြောင်းခြင်း စတင်ပါမည်။ autovacuum စတင်နေဆဲဖြစ်ပြီး၊ ထို့နောက်ဒုတိယ core ကိုအသုံးပြုမည်ဖြစ်သည်။ ကျွန်ုပ်တို့တွင် 16-32 cores များကိုခွဲဝေပေးထားသောကြောင့် လူ 10 ဦးကို တစ်ပြိုင်နက်တည်း လုပ်ဆောင်နိုင်သည်၊ ပြဿနာမရှိပါ။

ကာယကံကြောင့် PGDATA အလားတူပင်၊ ကျွန်ုပ်တို့သည် Postgres ကို အမှန်တကယ် လှည့်စားနေပါသည်။ လှည့်ကွက်မှာ ဤသို့ဖြစ်သည်- ဥပမာ၊ 10 Postgres ကို တပြိုင်နက်တည်း လွှင့်တင်သည်။ များသောအားဖြင့် ပြဿနာက ဘာလဲ။ တင်ကြတယ်။ shared_buffers25% ဆိုကြပါစို့။ ထို့ကြောင့်၎င်းသည် 200 GB ဖြစ်သည်။ မမ်မိုရီကုန်သွားသောကြောင့် ၎င်းတို့ထဲမှ သုံးခုထက်ပို၍ ဖွင့်မရနိုင်ပါ။

သို့သော် တစ်ချိန်ချိန်တွင် ၎င်းသည် မလိုအပ်ကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ခဲ့သည်- ကျွန်ုပ်တို့သည် shared_buffers ကို 2 GB သို့ သတ်မှတ်ခဲ့သည်။ PostgreSQL ရှိသည်။ effective_cache_size၊ လက်တွေ့တွင် ၎င်းသည် တစ်ခုတည်းသောလွှမ်းမိုးမှုဖြစ်သည်။ အစီအစဉ်များ. အဲဒါကို 0,5 TB လို့ သတ်မှတ်တယ်။ ပြီးတော့ သူတို့တကယ်ရှိမနေဘူးဆိုတာတောင် အရေးမကြီးပါဘူး- သူက သူတို့ရှိနေတယ်လို အစီအစဥ်တွေလုပ်တယ်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ရွှေ့ပြောင်းခြင်းတစ်မျိုးမျိုးကို စမ်းသပ်သောအခါတွင် အစီအစဉ်အားလုံးကို စုဆောင်းနိုင်သည် - ထုတ်လုပ်မှုတွင် မည်သို့ဖြစ်လာမည်ကို ကျွန်ုပ်တို့ မြင်တွေ့ရမည်ဖြစ်သည်။ စက္ကန့်များသည် ကွဲပြားသည် (ပိုမိုနှေးကွေးသည်)၊ သို့သော် ကျွန်ုပ်တို့ အမှန်တကယ်ဖတ်ရှုခဲ့သော ဒေတာနှင့် အစီအစဉ်များသည် ၎င်းတို့ကိုယ်တိုင် (ထိုနေရာတွင် ချိတ်ဆက်ထားသည်များ စသည်ဖြင့်) သည် ထုတ်လုပ်မှုနှင့် တူညီပါသည်။ ပြီးတော့ စက်တစ်လုံးမှာ ဒီလိုစစ်ဆေးမှုများစွာကို အပြိုင်လုပ်ဆောင်နိုင်ပါတယ်။

DS: ဒီမှာ ပြဿနာနည်းနည်းရှိမယ် မထင်ဘူးလား။ ပထမတစ်ခုသည် PostgreSQL တွင်သာအလုပ်လုပ်သောဖြေရှင်းချက်ဖြစ်သည်။ ဤချဉ်းကပ်မှုသည် အလွန်ပုဂ္ဂလိကဖြစ်ပြီး၊ ၎င်းသည် သာမန်မဟုတ်ပေ။ ဒုတိယအချက်မှာ Kubernetes (နှင့် cloud နည်းပညာများ ယခုသွားနေသည့် အရာအားလုံး) တွင် node အများအပြားပါဝင်ပြီး အဆိုပါ nodes များသည် ပေါ်ပင်များဖြစ်သည်။ သင့်ကိစ္စတွင်၊ ၎င်းသည် stateful၊ persistent node ဖြစ်သည်။ ဤအရာများသည် ကျွန်ုပ်အား ပဋိပက္ခဖြစ်စေသည်။

NS: ပထမ၊ ကျွန်တော်သဘောတူပါတယ်၊ ဒါက Postgres ဇာတ်လမ်းသက်သက်ပါ။ အကယ်၍ ကျွန်ုပ်တို့တွင် တိုက်ရိုက် IO တစ်မျိုးမျိုးနှင့် မှတ်ဉာဏ်အားလုံးနီးပါးအတွက် ကြားခံရေကန်တစ်ခု ရှိပါက၊ ဤချဉ်းကပ်မှုမှာ အလုပ်မဖြစ်နိုင်ဟု ထင်ပါသည်၊ အစီအစဉ်များသည် ကွဲပြားမည်ဖြစ်သည်။ သို့သော် ယခုအချိန်တွင် ကျွန်ုပ်တို့သည် Postgres နှင့်သာ အလုပ်လုပ်သည်၊ အခြားသူများအကြောင်းကို ကျွန်ုပ်တို့ မစဉ်းစားပါ။

Kubernetes အကြောင်း။ ကျွန်ုပ်တို့တွင် အမြဲရှိနေသော ဒေတာဘေ့စ်တစ်ခုရှိသည်ကို နေရာတိုင်းတွင် သင်ကိုယ်တိုင်ပြောပြပါ။ အကယ်၍ သာဓကပျက်ကွက်ပါက၊ အဓိကအရာမှာ disk ကိုသိမ်းဆည်းရန်ဖြစ်သည်။ ဤနေရာတွင် Kubernetes ရှိ ပလပ်ဖောင်းတစ်ခုလုံးလည်း ရှိပြီး Postgres ပါသော အစိတ်အပိုင်းသည် သီးခြားဖြစ်သည် (တစ်နေ့တွင် ထိုနေရာတွင် ရှိနေမည်ဖြစ်သော်လည်း)။ ထို့ကြောင့်၊ အရာအားလုံးသည် ဤကဲ့သို့ဖြစ်သည်- ဥပမာ ပြုတ်ကျသော်လည်း ကျွန်ုပ်တို့သည် ၎င်း၏ PV ကို သိမ်းဆည်းပြီး ဘာမှမဖြစ်ခဲ့သကဲ့သို့ အခြား (အသစ်) သာဓကနှင့် ရိုးရိုးရှင်းရှင်း ချိတ်ဆက်ထားသည်။

DS: ကျွန်ုပ်၏အမြင်အရ၊ Kubernetes တွင် pods များကို ဖန်တီးပါသည်။ K8s - elastic: knots များကို လိုအပ်သလို အမိန့်ပေးသည်။ တာဝန်မှာ Pod တစ်ခုကို ဖန်တီးပြီး X အရင်းအမြစ်များ လိုအပ်သည်ဟု ပြောပြီးနောက် K8s သည် ၎င်းကို သူ့ဘာသာသူ ရှာဖွေဖော်ထုတ်မည်ဖြစ်သည်။ သို့သော် Kubernetes ရှိ သိုလှောင်မှု ပံ့ပိုးမှုမှာ မတည်ငြိမ်သေးပါ။ 1.16တွင် 1.17 (ဤထုတ်ဝေမှုကို ထုတ်ပြန်ခဲ့သည်။ ထိုရက်သတ္တပတ်၏ လွန်ခဲ့သော) ဤအင်္ဂါရပ်များသည် beta သာဖြစ်လာသည်။

ခြောက်လမှတစ်နှစ်ကြာသည် - ၎င်းသည်ပိုမိုသို့မဟုတ်လျော့နည်းတည်ငြိမ်လာလိမ့်မည်၊ သို့မဟုတ်အနည်းဆုံး၎င်းကိုဤကဲ့သို့ကြေငြာလိမ့်မည်။ ထို့နောက် လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် အရွယ်အစားပြောင်းနိုင်ခြေသည် သင့်ပြဿနာကို လုံးဝဖြေရှင်းပေးပါသည်။ ဘာလို့လဲဆိုတော့ မင်းမှာ အခြေခံရှိတယ်။ ဟုတ်ပါသည်၊ ၎င်းသည် အလွန်မြန်မည်မဟုတ်ပါ၊ သို့သော် အချို့သောအကောင်အထည်ဖော်မှုများသည် disk စနစ်ခွဲအဆင့်တွင် ကူးယူကာ ကူးယူရေးသားနိုင်သောကြောင့် "အဖုံးအောက်" ပေါ်တွင်မူတည်ပါသည်။

NS: ဤဗားရှင်းကို စတင်ပံ့ပိုးရန်အတွက် အင်ဂျင်အားလုံး (Amazon၊ Google...) အတွက်လည်း လိုအပ်သည် - ၎င်းသည် အချိန်အနည်းငယ်ကြာပါသည်။

DS: ငါတို့ အဲဒါတွေကို မသုံးသေးဘူး။ ငါတို့က ငါတို့ကို သုံးတယ်။

Kubernetes အတွက် ဒေသတွင်း ဖွံ့ဖြိုးတိုးတက်မှု

NS: စက်တစ်ခုတည်းတွင် pods အားလုံးကို ထည့်သွင်းပြီး ထိုကဲ့သို့သော စမ်းသပ်မှုလေးတစ်ခု ပြုလုပ်သည့်အခါတွင် သင်သည် ထိုသို့သောဆန္ဒကို တွေ့ကြုံဖူးပါသလား။ အယူအဆအထောက်အထားကို လျင်မြန်စွာရရန်၊ ၎င်းအတွက် စက်အများအပြားကို မဖော်ပြဘဲ အပလီကေးရှင်းသည် Kubernetes တွင် အလုပ်လုပ်ကြောင်း ကြည့်ပါ။ Minikube ရှိတယ်ဟုတ်လား။

DS: ဤကိစ္စသည် node တစ်ခုပေါ်တွင်ဖြန့်ကျက်ထားသည် - ဒေသဖွံ့ဖြိုးရေးအတွက် သီးသန့်ဖြစ်သည် ။ သို့မဟုတ် ထိုသို့သောပုံစံ၏ သရုပ်အချို့။ စားသည် မီနီကူဘီ, ရှိသည် k3s, ကြင်နာ. ကျွန်ုပ်တို့သည် Docker တွင် Kubernetes ကိုအသုံးပြုခြင်းဆီသို့ ဦးတည်နေပါသည်။ ယခု ကျွန်ုပ်တို့သည် ၎င်းကို စမ်းသပ်မှုများအတွက် စတင်လုပ်ဆောင်နေပြီဖြစ်သည်။

NS: ဒါက Docker ပုံတစ်ပုံတည်းမှာ pods အားလုံးကို ခြုံဖို့ ကြိုးပမ်းမှုလို့ ကျွန်တော်ထင်ခဲ့ဖူးတယ်။ ဒါပေမယ့် ဒါက လုံးဝကို ကွဲပြားတဲ့ အရာတစ်ခုလို့ ထွက်လာတယ်။ မည်သို့ပင်ဆိုစေကာမူ Docker တွင် သီးခြားကွန်တိန်နာများ၊ သီးခြား pods များရှိသည်။

DS: ဟုတ်ကဲ့။ ပြီးတော့ ရယ်စရာကောင်းတဲ့ အတုယူမှုတစ်ခုရှိတယ်၊ ဒါပေမယ့် အဓိပ္ပါယ်က ဒါက... ငါတို့မှာ ဖြန့်ကျက်ဖို့ အသုံးဝင်မှုတစ်ခုရှိတယ်- werf. ကျွန်ုပ်တို့သည် ၎င်းအား အခြေအနေဆိုင်ရာမုဒ်တစ်ခုအဖြစ် ပြုလုပ်လိုပါသည်။ werf up- "ငါ့ကို ဒေသတွင်း Kubernetes ယူလိုက်ပါ။" ပြီးရင် conditional ကို run လိုက်ပါ။ werf follow. ထို့နောက် developer သည် IDE ကို တည်းဖြတ်နိုင်မည်ဖြစ်ပြီး၊ အပြောင်းအလဲများကို မြင်နိုင်ပြီး ပုံများကို ပြန်လည်တည်ဆောက်ပေးသည့် စနစ်တွင် လုပ်ငန်းစဉ်တစ်ခု စတင်မည်ဖြစ်ပြီး ၎င်းတို့ကို local K8s တွင် ပြန်လည်အသုံးချမည်ဖြစ်သည်။ ဒါက ဒေသခံတွေရဲ့ ပြဿနာကို ဖြေရှင်းဖို့ ကြိုးစားချင်တာပါ။

K8s လက်တွေ့တွင် လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် ဒေတာဘေ့စ်ပုံတူပွားခြင်း။

NS: copy-on-write သို့ ပြန်သွားလျှင်။ တိမ်တိုက်တွေမှာ လျှပ်တစ်ပြက်ပုံတွေ ရှိနေတာကို သတိထားမိတယ်။ အလုပ်လုပ်ပုံချင်း မတူကြပါ။ ဥပမာအားဖြင့်၊ GCP တွင်- သင့်တွင် United States အရှေ့ဘက်ကမ်းရိုးတန်းတွင် multi-terabyte ဥပမာတစ်ခုရှိသည်။ သင်သည် အချိန်အခါအလိုက် လျှပ်တစ်ပြက်ရိုက်ချက်များ ရိုက်သည်။ လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုမှ အနောက်ဘက်ကမ်းရိုးတန်းရှိ disk မိတ္တူကို သင်ကောက်ယူလိုက်သည်- မိနစ်အနည်းငယ်အတွင်း အရာအားလုံးအဆင်သင့်ဖြစ်ပြီ၊ ၎င်းသည် အလွန်လျင်မြန်စွာအလုပ်လုပ်သည်၊ ကက်ရှ်ကိုသာ မှတ်ဉာဏ်တွင်ဖြည့်ရန် လိုအပ်သည်။ သို့သော် ဤပုံတူရုပ်ပုံများ (လျှပ်တစ်ပြက်ပုံများ) သည် အသံအတိုးအကျယ်အသစ်ကို 'ပံ့ပိုး' နိုင်ရန်ဖြစ်သည်။ သာဓကများစွာဖန်တီးရန် လိုအပ်သောအခါ ၎င်းသည် အေးမြသည်။

ဒါပေမယ့် စမ်းသပ်မှုတွေအတွက်၊ Docker မှာ သင်ပြောနေတဲ့ ဒါမှမဟုတ် ZFS၊ btrfs နဲ့ LVM မှာတောင် သင်ပြောနေတဲ့ လျှပ်တစ်ပြက်ရိုက်ချက်တွေဟာ သင့်အား စက်တစ်ခုတည်းမှာ အမှန်တကယ် ဒေတာအသစ်ဖန်တီးခွင့်မပြုပါဘူး။ cloud တွင်၊ သင်သည် ၎င်းတို့အတွက် အချိန်တိုင်း ပေးဆောင်ဆဲဖြစ်ပြီး စက္ကန့်မစောင့်ဘဲ မိနစ်များ (ထိုကိစ္စတွင်) ပျင်းရိနေပါသည်။နာရီဖြစ်နိုင်သည်)။

ယင်းအစား သင်သည် ဤဒေတာကို တစ်စက္ကန့် သို့မဟုတ် နှစ်ပိုင်းအတွင်း ရနိုင်သည်၊ စမ်းသပ်မှုကို ပြေးပြီး စွန့်ပစ်လိုက်ပါ။ ဤလျှပ်တစ်ပြက်များသည် မတူညီသောပြဿနာများကို ဖြေရှင်းပေးသည်။ ပထမကိစ္စတွင် - အတိုင်းအတာနှင့်ပုံတူအသစ်များရယူရန်နှင့်ဒုတိယတွင်စမ်းသပ်မှုများအတွက်။

DS: ငါသဘောမတူဘူး။ Volume Cloning ကို မှန်ကန်စွာ လုပ်ဆောင်ခြင်းသည် cloud ၏ အလုပ်ဖြစ်သည်။ သူတို့ရဲ့ အကောင်အထည်ဖော်မှုကို ကျွန်တော် မကြည့်ရသေးပေမယ့် ဟာ့ဒ်ဝဲမှာ ဘယ်လိုလုပ်ဆောင်လဲဆိုတာ သိပါတယ်။ ကျွန်ုပ်တို့တွင် Ceph ရှိသည်၊ ၎င်းသည် မည်သည့်ရုပ်ထုထည်ကိုမဆို ခွင့်ပြုသည် (RBD) ပြော ကိုယ်ပွား ဆယ်ဂဏန်းမီလီစက္ကန့်အတွင်း တူညီသောဝိသေသလက္ခဏာများရှိသော ဒုတိယအတွဲကို ရယူပါ၊ IOPS'အေမီ, etc. အတွင်းတွင် ရှုပ်ထွေးသော ကော်ပီ-on-write ပါရှိသည်ကို နားလည်ရန် လိုအပ်ပါသည်။ Cloud က ဘာကြောင့် ဒီလိုပဲ မလုပ်သင့်တာလဲ။ သူတို့ ဒါကို တစ်နည်းမဟုတ်တစ်နည်းလုပ်ဖို့ ကြိုးစားနေတာ သေချာပါတယ်။

NS: သို့သော် ဥပမာတစ်ခုကို မြှင့်တင်ရန်၊ Docker ကို ထိုနေရာသို့ ယူဆောင်လာရန် စက္ကန့်၊ စက္ကန့် ဆယ်ချီကြာနေသေးသည်။

DS: သာဓကတစ်ခုလုံးကို မြှင့်တင်ရန် အဘယ်ကြောင့် လိုအပ်သနည်း။ ကျွန်ုပ်တို့တွင် 32 cores၊ 16... ပါရှိပြီး ၎င်းနှင့် အံဝင်ခွင်ကျဖြစ်နိုင်သည် - ဥပမာ လေးခု။ ကျွန်ုပ်တို့သည် ပဉ္စမတစ်ခုကို မှာယူသောအခါ၊ ဥပမာကို မြှင့်တင်ထားပြီး၊ ထို့နောက် ၎င်းကို ဖျက်ပစ်မည်ဖြစ်သည်။

NS: ဟုတ်တယ်၊ စိတ်ဝင်စားစရာကောင်းတယ်၊ Kubernetes က မတူညီတဲ့ဇာတ်လမ်းတစ်ခုဖြစ်လာတယ်။ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်သည် K8s တွင်မဟုတ်ပါ၊ ကျွန်ုပ်တို့တွင် ဥပမာတစ်ခုရှိသည်။ သို့သော် multi-terabyte ဒေတာဘေ့စ်ကိုပွားခြင်းသည် နှစ်စက္ကန့်ထက် မပိုပါ။

DS: ဒါ အရမ်းကောင်းတယ်။ ဒါပေမယ့် ကျွန်တော့်ရဲ့ ကနဦးအချက်ကတော့ ဒါက ယေဘူယျ အဖြေတစ်ခု မဟုတ်ပါဘူး။ ဟုတ်တယ်၊ ကောင်းတယ်၊ ဒါပေမယ့် Postgres အတွက်သာဖြစ်ပြီး node တစ်ခုအတွက်ပဲ သင့်တော်ပါတယ်။

NSPostgres အတွက်သာမက၊ ကျွန်ုပ်ဖော်ပြခဲ့သည့်အတိုင်း ဤအစီအစဥ်များသည် ၎င်းတွင်သာ လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ သို့သော် ကျွန်ုပ်တို့သည် အစီအစဉ်များကို စိတ်မ၀င်စားဘဲ လုပ်ဆောင်မှုစမ်းသပ်ခြင်းအတွက် ဒေတာအားလုံးကို လိုအပ်ပါက၊ ၎င်းသည် မည်သည့် DBMS အတွက်မဆို သင့်လျော်ပါသည်။

DS: လွန်ခဲ့သောနှစ်များစွာက ကျွန်ုပ်တို့သည် LVM လျှပ်တစ်ပြက်ရိုက်ချက်များတွင် အလားတူတစ်ခုခုလုပ်ခဲ့သည်။ ဒါက ဂန္တဝင်ပါပဲ။ ဤနည်းလမ်းကို အလွန်တက်ကြွစွာ အသုံးပြုခဲ့သည်။ Stateful node များသည် နာကျင်မှုမျှသာဖြစ်သည်။ ပစ်မထားသင့်တဲ့အတွက် အမြဲအမှတ်ရနေသင့်ပါတယ်...

NSဤနေရာတွင် မျိုးစပ်ခြင်း ဖြစ်နိုင်ချေကို မြင်ပါသလား။ stateful သည် အချို့သော pod အမျိုးအစားဖြစ်သည် ဆိုကြပါစို့၊ ၎င်းသည် လူပေါင်းများစွာ (စမ်းသပ်သူအများအပြား) အတွက် အဆင်ပြေသည်။ ကျွန်ုပ်တို့တွင် volume တစ်ခုရှိသည်၊ သို့သော် ဖိုင်စနစ်ကြောင့်၊ clones များသည် local ဖြစ်သည်။ pod ပြုတ်ကျသော်လည်း disk ကျန်နေပါက pod တက်လာမည်ဖြစ်ပြီး၊ clones များအားလုံးနှင့်ပတ်သက်သောအချက်အလက်ကိုရေတွက်ကာ၊ အရာအားလုံးကိုထပ်မံကောက်ယူပြီး "ဤ port များပေါ်တွင်သင်၏ clones များအလုပ်လုပ်နေပါသည်၊ ၎င်းတို့နှင့်ဆက်လက်လုပ်ဆောင်နေသည်" ဟုပြောပါ။

DS: နည်းပညာအရ၊ ဆိုလိုသည်မှာ Kubernetes တွင် ၎င်းသည် ကျွန်ုပ်တို့ Postgres အများအပြားကို လုပ်ဆောင်သည့် အကန့်တစ်ခုဖြစ်သည်။

NS: ဟုတ်ကဲ့။ သူ့တွင် ကန့်သတ်ချက်ရှိသည်- တစ်ချိန်တည်းတွင် သူနှင့်အတူ လူ ၁၀ ဦးထက် မပိုစေရပါ။ အကယ်၍ သင်သည် 10 လိုအပ်ပါက၊ ကျွန်ုပ်တို့သည် ထိုကဲ့သို့သော pod တစ်ခုကို စတင်ပါမည်။ ဒုတိယအတွဲကို လက်ခံရရှိပြီးပါက ၎င်းကို အပြည့်အ၀မွေးထုတ်မည်ဖြစ်ပြီး ၎င်းတွင် တူညီသော "ပါးလွှာ" clones 20 ခုရှိသည်။ ဒီအခွင့်အရေးကို မင်းမမြင်ဘူးလား။

DSဤနေရာတွင် လုံခြုံရေးပြဿနာများ ထည့်ရန်လိုသည်။ ဤအဖွဲ့အစည်းအမျိုးအစားသည် ဤ pod သည် ဖိုင်စနစ်တွင် စံမဟုတ်သော လုပ်ဆောင်ချက်များကို လုပ်ဆောင်နိုင်သောကြောင့် မြင့်မားသောအခွင့်ထူးများ (စွမ်းရည်များ) ရှိသည်ဟု ဆိုလိုသည်... ဒါပေမယ့် ထပ်ခါထပ်ခါ ထပ်ခါထပ်ခါ-- ကာလလတ်တွင် Kubernetes တွင် သိုလှောင်မှုကို ပြုပြင်ပေးမည်ဟု ယုံကြည်ပါသည်၊ တိမ်တိုက်များက ဇာတ်လမ်းတစ်ခုလုံးကို အတွဲများဖြင့် ပြုပြင်ပေးမည် - အရာအားလုံးသည် “အလုပ်ဖြစ်” လိမ့်မည်။ အရွယ်အစား ပြောင်းလဲခြင်း၊ ပုံတူပွားခြင်း ရှိလိမ့်မည်... ပမာဏတစ်ခု ရှိသည် - ကျွန်ုပ်တို့သည် "၎င်းကို အခြေခံ၍ အသစ်တစ်ခုကို ဖန်တီးပါ" ဟုဆိုကာ တစ်စက္ကန့်ခွဲကြာပြီးနောက် ကျွန်ုပ်တို့ လိုအပ်သောအရာကို ရရှိပါသည်။

NS: terabyte အများအပြားအတွက် တစ်စက္ကန့်ခွဲကို မယုံဘူး။ Ceph မှာ သင်ကိုယ်တိုင်လုပ်ပေမယ့် တိမ်တွေအကြောင်း ပြောနေတာ။ Cloud သို့သွားပါ၊ EC2 တွင် multi-terabyte EBS ပမာဏကို ပုံတူကူးပြီး စွမ်းဆောင်ရည်က မည်သို့ရှိမည်ကို ကြည့်ရှုပါ။ စက္ကန့်အနည်းငယ် ကြာမည်မဟုတ်ပါ။ ဒီအဆင့်ရောက်ရင် အရမ်းစိတ်ဝင်စားတယ်။ မင်းပြောတာကို ငါနားလည်ပေမယ့် ကွဲလွဲနေဖို့ တောင်းဆိုတယ်။

DS: အိုကေ၊ ဒါပေမယ့် ငါက ကာလလတ်၊ တိုတောင်းတဲ့ ကာလမဟုတ်ဘူးလို့ ပြောခဲ့တယ်။ နှစ်ပေါင်းများစွာ။

Zalando မှ PostgreSQL အတွက် အော်ပရေတာအကြောင်း

ဤအစည်းအဝေး၏အလယ်တွင် Zalando မှ developer ဟောင်း Alexey Klyukin လည်းပါဝင်ပြီး PostgreSQL အော်ပရေတာ၏သမိုင်းကြောင်းကိုပြောခဲ့သည်-

Postgres နှင့် Kubernetes နှစ်မျိုးလုံးတွင် ဤအကြောင်းအရာကို ယေဘူယျအားဖြင့် ထိမိခြင်းမှာ ကောင်းပါတယ်။ 2017 ခုနှစ်တွင် Zalando တွင်ကျွန်ုပ်တို့စတင်လုပ်ဆောင်သောအခါ၊ လူတိုင်းလုပ်ချင်သောအကြောင်းအရာတစ်ခုဖြစ်ခဲ့သည်၊ သို့သော်မည်သူမျှမပြုလုပ်ခဲ့ပါ။ လူတိုင်းတွင် Kubernetes ရှိနှင့်ပြီးဖြစ်သော်လည်း ဒေတာဘေ့စ်များကို မည်သို့လုပ်ဆောင်ရမည်ကို မေးသောအခါတွင်ပင်၊ Kelsey HightowerK8s တရားဟောသူ က ဤကဲ့သို့ ပြောကြားခဲ့ပါသည်။
“စီမံခန့်ခွဲထားသော ဝန်ဆောင်မှုများသို့ သွား၍ ၎င်းတို့ကို အသုံးပြုပါ၊ Kubernetes တွင် ဒေတာဘေ့စ်ကို မဖွင့်ပါနှင့်။ မဟုတ်ပါက၊ ဥပမာအားဖြင့်၊ သင်၏ K8s သည် အဆင့်မြှင့်တင်ရန်၊ node အားလုံးကို ပိတ်လိုက်ပြီး သင်၏ဒေတာသည် အဝေးသို့ လွင့်သွားလိမ့်မည်ဖြစ်သည်။"
Kubernetes တွင် Postgres ဒေတာဘေ့စ်ကိုဖွင့်မည့် ဤအကြံပြုချက်ကို ဆန့်ကျင်သော အော်ပရေတာတစ်ခုပြုလုပ်ရန် ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ ပြီးတော့ ငါတို့မှာ အကြောင်းပြချက်ကောင်းတစ်ခုရှိတယ်၊ Patroni. ၎င်းသည် PostgreSQL အတွက် အလိုအလျောက်ပျက်ကွက်မှု၊ မှန်ကန်စွာ လုပ်ဆောင်သည် etcd၊ ကောင်စစ်ဝန် သို့မဟုတ် ZooKeeper အစုအဝေးနှင့်ပတ်သက်သော အချက်အလက်များကို သိုလှောင်မှုအဖြစ် အသုံးပြုခြင်း။ ဥပမာ- လက်ရှိခေါင်းဆောင်ဆိုတာ ဘာလဲ၊ တူညီတဲ့အချက်အလက်တွေကို မေးတဲ့သူတိုင်းကို ပေးမယ့် သိုလှောင်ရုံတစ်ခု - ကျွန်ုပ်တို့မှာ အရာအားလုံးကို ဖြန့်ဝေပေးထားပြီးဖြစ်လို့ - ဦးနှောက်ကွဲခြင်း မရှိစေရပါဘူး။ နောက်ပြီး ငါတို့မှာရှိတယ်။ Docker ပုံ သူ့အဘို့။
ယေဘုယျအားဖြင့်၊ ကုမ္ပဏီတွင်း ဟာ့ဒ်ဝဲဒေတာစင်တာမှ cloud သို့ ပြောင်းရွှေ့ပြီးနောက် အလိုအလျောက်ပျက်ကွက်မှုအတွက် ကုမ္ပဏီ၏လိုအပ်ချက်သည် ပေါ်လာသည်။ cloud သည် တစ်ဦးတည်းပိုင် PaaS (Platform-as-a-Service) ဖြေရှင်းချက်အပေါ် အခြေခံထားသည်။ ၎င်းသည် Open Source ဖြစ်သည်၊ သို့သော် ၎င်းကို စတင်လည်ပတ်ရန် အလုပ်များစွာယူခဲ့ရသည်။ လို့ ခေါ်ပါတယ်။ ငတုံးများ.
အစပိုင်းတွင် Kubernetes မရှိခဲ့ပါ။ ပို၍တိကျသည်မှာ၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖြေရှင်းချက်ကို အသုံးပြုသောအခါတွင် K8s သည် ယခင်ကတည်းကရှိနေပြီဖြစ်သော်လည်း ၎င်းသည် ထုတ်လုပ်ရန်အတွက် မသင့်လျော်ပေ။ ကျွန်တော့်အမြင်အရတော့ 2015 ဒါမှမဟုတ် 2016 ပါ။ 2017 ခုနှစ်တွင်၊ Kubernetes သည် ပို၍ သို့မဟုတ် နည်းပါးလာသည်—ထိုနေရာတွင် ပြောင်းရွှေ့ရန် လိုအပ်ပါသည်။
ပြီးတော့ ကျွန်တော်တို့မှာ Docker container တစ်ခုရှိပြီးသားပါ။ Docker ကိုအသုံးပြုသော PaaS တစ်ခုရှိသည်။ ဘာကြောင့် K8s ကို မစမ်းကြည့်တာလဲ။ သင့်ကိုယ်ပိုင်အော်ပရေတာကို ဘာကြောင့်မရေးတာလဲ။ Avito မှကျွန်ုပ်တို့ထံရောက်လာသော Murat Kabilov သည်၎င်းကိုသူ၏ကိုယ်ပိုင်အစပျိုးမှု - "ကစားရန်" ပရောဂျက်အဖြစ်စတင်ခဲ့ပြီးပရောဂျက်သည် "စတင်ခဲ့သည်" ။
ဒါပေမယ့် ယေဘူယျအားဖြင့်တော့ AWS အကြောင်း ပြောချင်ပါတယ်။ သမိုင်းဆိုင်ရာ AWS ကုဒ် ဘာကြောင့်ရှိနေတာလဲ...
Kubernetes တွင် တစ်ခုခုကို သင်လုပ်ဆောင်သောအခါ၊ K8s သည် ထိုကဲ့သို့ လုပ်ဆောင်နေသည့် အလုပ်ဖြစ်ကြောင်း သင်နားလည်ရန် လိုအပ်ပါသည်။ ၎င်းသည် အချိန်နှင့်အမျှ အမြဲတစေ ဖွံ့ဖြိုးတိုးတက်လာကာ ပိုမိုကောင်းမွန်လာကာ ပြိုကွဲသွားခဲ့သည်။ Kubernetes ရှိ အပြောင်းအလဲများအားလုံးကို အနီးကပ် စောင့်ကြည့်ရန် လိုအပ်ပြီး၊ တစ်စုံတစ်ခု ဖြစ်ပေါ်လာပါက ၎င်းကို စေ့စေ့စပ်စပ် လေ့လာရန် အဆင်သင့်ဖြစ်ရန် လိုအပ်သည် - သင်အလိုထက် ပိုကောင်းသည်။ မူအရ၊ ၎င်းသည် သင့်ဒေတာဘေ့စ်များကို သင်လည်ပတ်သည့် မည်သည့် platform နှင့်မဆို သက်ဆိုင်ပါသည်။
ထို့ကြောင့်၊ ကျွန်ုပ်တို့ထုတ်ပြန်ချက်ကိုပြုလုပ်သောအခါတွင်၊ ကျွန်ုပ်တို့တွင် Postgres သည် ပြင်ပအသံအတိုးအကျယ်ပေါ်တွင် လုပ်ဆောင်နေပါသည် (ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် AWS တွင်အလုပ်လုပ်နေသောကြောင့် EBS) ရှိသည်။ ဒေတာဘေ့စ်သည် ကြီးထွားလာသည်၊ တစ်ချိန်ချိန်တွင် ၎င်းကို အရွယ်အစားပြောင်းလဲရန် လိုအပ်သည်- ဥပမာ၊ EBS ၏ ကနဦးအရွယ်အစားမှာ 100 TB ဖြစ်ပြီး၊ ဒေတာဘေ့စ်သည် ၎င်းတွင် ကြီးထွားလာကာ ယခုအခါတွင် ကျွန်ုပ်တို့သည် EBS 200 TB ပြုလုပ်လိုပါသည်။ ဘယ်လိုလဲ? ဥပမာအသစ်တစ်ခုတွင် dump/restore ပြုလုပ်နိုင်သည်ဟု ဆိုကြပါစို့၊ သို့သော် ၎င်းသည် အချိန်ကြာမြင့်မည်ဖြစ်ပြီး စက်ရပ်သွားမည်ဖြစ်သည်။
ထို့ကြောင့်၊ EBS အခန်းကန့်ကို ချဲ့ပြီး နေရာအသစ်ကို အသုံးပြုရန် ဖိုင်စနစ်ကို ပြောပြမည့် အရွယ်အစားကို လိုချင်ပါသည်။ ၎င်းကိုကျွန်ုပ်တို့ပြုလုပ်ခဲ့သည်၊ သို့သော် ထိုအချိန်တွင် Kubernetes သည် အရွယ်အစားပြောင်းလဲခြင်းလုပ်ဆောင်မှုအတွက် မည်သည့် API မျှ မရှိပါ။ AWS မှာ အလုပ်လုပ်ကတည်းက သူ့ရဲ့ API အတွက် ကုဒ်ကို ရေးခဲ့ပါတယ်။
အခြားပလက်ဖောင်းများအတွက် အလားတူလုပ်ဆောင်ခြင်းမှ သင့်အား မည်သူမျှ တားဆီးခြင်းမပြုပါ။ ၎င်းသည် AWS တွင်သာလည်ပတ်နိုင်သည်ဟူသောကြေငြာချက်တွင်အရိပ်အမြွက်မျှမရှိပါ၊ ၎င်းသည်အခြားအရာအားလုံးတွင်အလုပ်လုပ်မည်မဟုတ်ပါ။ ယေဘူယျအားဖြင့်၊ ၎င်းသည် Open Source ပရောဂျက်ဖြစ်သည်- API အသစ်၏အသုံးပြုမှုကို အရှိန်မြှင့်လိုပါက မည်သူမဆို ကြိုဆိုပါသည်။ စားသည် GitHubတောင်းဆိုမှုများကို ဆွဲထုတ်ပါ - Zalando အဖွဲ့သည် ၎င်းတို့အား တုံ့ပြန်ရန် အလွန်လျင်မြန်ပြီး အော်ပရေတာအား မြှင့်တင်ရန် ကြိုးစားသည်။ ကျွန်တော်သိသလောက်တော့ ပရောဂျက်ပေါ့။ ပါဝင်ခဲ့သည်။ Google Summer of Code နှင့် အခြားသော အလားတူလုပ်ဆောင်မှုများတွင် Zalando သည် ၎င်းအတွက် အလွန်တက်ကြွစွာ လုပ်ဆောင်နေပါသည်။

PS ဘောနပ်စ်။

အကယ်၍ သင်သည် PostgreSQL နှင့် Kubernetes ၏ ခေါင်းစဉ်ကို စိတ်ဝင်စားပါက၊ နောက်တစ်ပတ် Postgres အင်္ဂါနေ့တွင် ကျွန်တော် Nikolai နှင့် စကားပြောခဲ့သည်ကို ကျေးဇူးပြု၍ သတိပြုပါ။ Zalando မှ Alexander Kukushkin. ၎င်းမှဗီဒီယိုကိုရနိုင်သည်။ ဒီမှာ.