AWS သည် ၎င်း၏ elastic ဝန်ဆောင်မှုများကို ချက်ပြုတ်နည်း။ ဆာဗာများနှင့် ဒေတာဘေ့စ်ကို ချဲ့ထွင်ခြင်း။

တိမ်တွေဟာ မှော်သေတ္တာတစ်ခုလိုပါပဲ - သင်လိုအပ်တာတွေကို သင်မေးပြီး အရင်းအမြစ်တွေက ဘယ်နေရာမှာမှ ပေါ်လာမှာမဟုတ်ပါဘူး။ စက်အတုများ၊ ဒေတာဘေ့စ်များ၊ ကွန်ရက်များ - ဤအရာအားလုံးသည် သင့်အတွက်သာဖြစ်သည်။ အခြား cloud ငှားရမ်းသူများလည်း ရှိသော်လည်း သင်၏ Universe တွင် သင်သည် တစ်ဦးတည်းသော အုပ်စိုးရှင်ဖြစ်သည်။ သင်လိုအပ်သောအရင်းအမြစ်များကို အမြဲလက်ခံရရှိမည်မှာ သေချာသည်၊ သင်သည်မည်သူ့ကိုမျှ ထည့်သွင်းစဉ်းစားခြင်းမရှိသည့်အပြင် ကွန်ရက်သည် မည်သို့မည်ပုံဖြစ်မည်ကို လွတ်လပ်စွာဆုံးဖြတ်ပါ။ cloud သည် အရင်းအမြစ်များကို ပျော့ပျောင်းစွာခွဲဝေပေးပြီး ငှားရမ်းသူများကို တစ်ဦးနှင့်တစ်ဦး လုံးဝခွဲထုတ်စေသည့် ဤမှော်ပညာသည် မည်သို့လုပ်ဆောင်သနည်း။

AWS cloud သည် 2006 ခုနှစ်မှစတင်၍ ဆင့်ကဲဆင့်ကဲပြောင်းလဲလာခဲ့သည့် mega-super complex system တစ်ခုဖြစ်သည်။ ဤဖွံ့ဖြိုးတိုးတက်မှု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်ခဲ့သည်။ Vasily Pantyukhin - Amazon Web Services Architect ။ ဗိသုကာပညာရှင်တစ်ဦးအနေဖြင့်၊ သူသည် နောက်ဆုံးရလဒ်တွင်သာမက AWS မှကျော်ဖြတ်သည့် စိန်ခေါ်မှုများတွင်လည်း အတွင်းပိုင်းကိုကြည့်ရှုနိုင်မည်ဖြစ်သည်။ စနစ်ဘယ်လိုအလုပ်လုပ်လဲဆိုတာကို ပိုနားလည်လာလေလေ၊ ယုံကြည်မှုပိုရှိလာလေပါပဲ။ ထို့ကြောင့် Vasily သည် AWS cloud ဝန်ဆောင်မှုများ၏ လျှို့ဝှက်ချက်များကို မျှဝေမည်ဖြစ်သည်။ အောက်တွင် ရုပ်ပိုင်းဆိုင်ရာ AWS ဆာဗာများ၏ ဒီဇိုင်း၊ ပျော့ပျောင်းသော ဒေတာဘေ့စ် အတိုင်းအတာ၊ စိတ်ကြိုက် Amazon ဒေတာဘေ့စ်နှင့် ၎င်းတို့၏ စျေးနှုန်းကို တပြိုင်နက်တည်း လျှော့ချနေစဉ် virtual machines များ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် နည်းလမ်းများဖြစ်သည်။ Amazon ၏ ဗိသုကာဆိုင်ရာ ချဉ်းကပ်မှုများအကြောင်း အသိပညာသည် သင့်အား AWS ဝန်ဆောင်မှုများကို ပိုမိုထိရောက်စွာအသုံးပြုရန် ကူညီပေးမည်ဖြစ်ပြီး သင့်ကိုယ်ပိုင်ဖြေရှင်းချက်များကို တည်ဆောက်ရန်အတွက် အကြံဉာဏ်သစ်များပေးမည်ဖြစ်သည်။

ဟောပြောသူအကြောင်း- Vasily Pantyukhin (ကြက်) .ru ကုမ္ပဏီများတွင် Unix စီမံခန့်ခွဲသူအဖြစ် စတင်ခဲ့ပြီး ကြီးမားသော Sun Microsystem ဟာ့ဒ်ဝဲတွင် 6 နှစ်ကြာ လုပ်ကိုင်ခဲ့ပြီး EMC တွင် ဒေတာဗဟိုပြုကမ္ဘာကို 11 နှစ်ကြာ ဟောပြောခဲ့သည်။ ၎င်းသည် သဘာဝအတိုင်း ပုဂ္ဂလိက တိမ်တိုက်များအဖြစ် ပြောင်းလဲလာပြီး 2017 ခုနှစ်တွင် အများသူငှာ နေရာများသို့ ပြောင်းရွှေ့ခဲ့သည်။ ယခု သူသည် AWS cloud တွင် အသက်ရှင်နေထိုင်ရန်နှင့် ဖွံ့ဖြိုးတိုးတက်စေရန်အတွက် နည်းပညာဆိုင်ရာ အကြံဉာဏ်များကို ပေးပါသည်။

မသက်ဆိုင်ကြောင်းရှင်းလင်းချက်- အောက်ပါအရာအားလုံးသည် Vasily ၏ကိုယ်ရေးကိုယ်တာထင်မြင်ချက်ဖြစ်ပြီး Amazon Web Services ၏ရပ်တည်ချက်နှင့်မကိုက်ညီပါ။ ဗီဒီယိုရိုက်ကူးခြင်း။ ဆောင်းပါးကို အခြေခံထားသည့် အစီရင်ခံစာကို ကျွန်ုပ်တို့၏ YouTube ချန်နယ်တွင် ရရှိနိုင်ပါသည်။

ငါဘာကြောင့် Amazon စက်ပစ္စည်းအကြောင်းပြောနေတာလဲ။

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

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

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

Amazon cloud မှာ စလုပ်တုန်းကတော့ ဒါဟာ ကျွန်တော့်အတွက် လျှို့ဝှက်ဆန်းကြယ်မှုတစ်ခုပါပဲ။ ဤလျှို့ဝှက်ဆန်းကြယ်မှုသာလျှင် ကားပေါ်တွင် ယာဉ်မောင်းတစ်ဦးရှိ၍ AWS တွင် သန်းနှင့်ချီ၍ရှိသောကြောင့်၊ အသုံးပြုသူအားလုံး တပြိုင်နက် ခုတ်မောင်း၊ ဂတ်စ်နှင့် ဘရိတ်ကို နှိပ်ပါ။ သူတို့လိုရာကို သွားကြတာ အံ့ဩစရာပဲ၊ အဲဒါ ငါ့အတွက် အံ့ဖွယ်ပါပဲ။ စနစ်သည် ဤစကြဝဠာတွင် သူတစ်ယောက်တည်းရှိနေသည်ဟု ထင်စေရန်အတွက် စနစ်သည် အသုံးပြုသူတစ်ဦးစီထံ အလိုအလျောက် လိုက်လျောညီထွေဖြစ်အောင်၊ အတိုင်းအတာနှင့် ပျော့ပျောင်းစွာ ချိန်ညှိပေးသည်။

နောက်ပိုင်း Amazon မှာ ဗိသုကာတစ်ယောက်အနေနဲ့ အလုပ်စလုပ်တဲ့အခါ မှော်ပညာက နည်းနည်းတော့ ပျက်သွားတယ်။ ဘယ်လိုအခက်အခဲတွေ ကြုံနေရတယ်၊ အဲဒါတွေကို ဘယ်လိုဖြေရှင်းရမလဲ၊ ဝန်ဆောင်မှုတွေကို ဘယ်လိုဖွံ့ဖြိုးအောင် လုပ်မလဲဆိုတာကို မြင်ခဲ့ရတယ်။ စနစ်အလုပ်လုပ်ပုံကို နားလည်မှု တိုးလာသည်နှင့်အမျှ ဝန်ဆောင်မှုအပေါ် ယုံကြည်မှုပိုရှိလာပါသည်။ ဒါကြောင့် AWS cloud ရဲ့ ပါးပြင်အောက်က ဓါတ်ပုံတစ်ပုံကို မျှဝေချင်ပါတယ်။

ဘာအကြောင်းပြောရမလဲ

ကွဲပြားသော ချဉ်းကပ်နည်းကို ငါရွေးချယ်ခဲ့သည်- ငါပြောသင့်ပြောထိုက်သော စိတ်ဝင်စားဖွယ်ကောင်းသော ဝန်ဆောင်မှု 4 ခုကို ရွေးချယ်ခဲ့သည်။

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

ဆာဗာမဲ့လုပ်ဆောင်ချက်များ (Lambda) သည် cloud တွင် အရွယ်အစားအရှိဆုံး ဝန်ဆောင်မှု ဖြစ်နိုင်သည်။

ဒေတာဘေ့စကို ချဲ့ထွင်ခြင်း။. ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် scalable databases များကို မည်သို့တည်ဆောက်ပုံအကြောင်း ပြောပြပါမည်။

ကွန်ရက်ချဲ့ထွင်ခြင်း။. ကျွန်ုပ်တို့၏ကွန်ရက်၏စက်ပစ္စည်းကို ကျွန်ုပ်ဖွင့်မည့်နောက်ဆုံးအပိုင်း။ ဤသည်မှာ အံ့သြဖွယ်ကောင်းလှသည် - cloud အသုံးပြုသူတိုင်းသည် cloud တွင် တစ်ယောက်တည်းရှိနေသည်ဟု ယုံကြည်ကြပြီး အခြားအိမ်ငှားများကို လုံးဝမတွေ့ရပါ။

မှတ်ချက်။ ဤဆောင်းပါးတွင် server optimization နှင့် database scaling ကို ဆွေးနွေးပါမည်။ နောက်ဆောင်းပါးတွင် ကွန်ရက်ချဲ့ထွင်ခြင်းကို သုံးသပ်ပါမည်။ ဆာဗာမဲ့လုပ်ဆောင်ချက်တွေက ဘယ်မှာလဲ။ ၎င်းတို့အကြောင်း သီးခြားစာသားကို ထုတ်ဝေခဲ့သည်"သေးငယ်သော်လည်း စမတ်ကျသည်။ Unboxing Firecracker microvirtual“ ၎င်းသည် မတူညီသောစကေးချဲ့နည်းများစွာအကြောင်း ဆွေးနွေးထားပြီး Firecracker ဖြေရှင်းချက် - virtual machine နှင့် containers များ၏ အကောင်းဆုံးအရည်အသွေးများ၏ ပေါင်းစပ်မှုတစ်ခုဖြစ်သည်။

ဆာဗာများ

cloud က ခဏတာသာ ရှိတယ်။ ဒါပေမယ့် ဒီခဏတာသာ ရှိတဲ့ သဘောသဘာဝက ရုပ်ပိုင်းဆိုင်ရာ ပုံစံတစ်ခု ရှိနေဆဲပဲ—ဆာဗာတွေပေါ့။ အစပိုင်းမှာတော့ သူတို့ရဲ့ ဗိသုကာပုံစံက ဂန္ထဝင်ပါပဲ။ စံ x86 chipset၊ ကွန်ရက်ကတ်တွေ၊ Linux၊ virtual machine များကို လည်ပတ်စေခဲ့သော Xen hypervisor။

2012 ခုနှစ်တွင် ဤဗိသုကာလက်ရာသည် ၎င်း၏တာဝန်များကို ကောင်းစွာဆောင်ရွက်နိုင်ခဲ့သည်။ Xen သည် ကြီးမားသော hypervisor ဖြစ်သည်၊ သို့သော် ၎င်းတွင် အဓိက အားနည်းချက်တစ်ခုရှိသည်။ တော်လောက်ပါပြီ။ device emulation အတွက် မြင့်မားသော overhead. အသစ်၊ ပိုမိုမြန်ဆန်သော ကွန်ရက်ကတ်များ သို့မဟုတ် SSD ဒရိုက်ဗ်များ ရရှိနိုင်လာသည်နှင့်အမျှ၊ ဤအရာသည် အလွန်မြင့်မားလာသည်။ ဒီပြဿနာကို ဘယ်လိုဖြေရှင်းမလဲ။ မျက်နှာစာနှစ်ခုကို တစ်ပြိုင်နက်တည်း လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်၊ hardware နှင့် hypervisor နှစ်မျိုးလုံးကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။. အလုပ်က အရမ်းလေးနက်တယ်။

ဟာ့ဒ်ဝဲနှင့် ဟိုက်ပါဗစ်ဆာတို့ကို အကောင်းဆုံးဖြစ်အောင်လုပ်ခြင်း။

အရာအားလုံးကို တစ်ပြိုင်နက်လုပ်ပြီး ကောင်းကောင်းလုပ်ရင် အလုပ်မဖြစ်ပါဘူး။ “ကောင်းသည်” ဟူသည်မှာလည်း အစပိုင်းတွင် မရှင်းလင်းခဲ့ပေ။

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

ကျွန်ုပ်တို့သည် လူယုတ်မာတိုင်းကို လျှောက်လှမ်းကာ တိုင်ကြားချက်များနှင့် အကြံပြုချက်များကို နားထောင်ပါသည်။ ထို့နောက်ကျွန်ုပ်တို့သည်အခြားအစိတ်အပိုင်းကိုပြောင်းလဲပါ။ ထို့ကြောင့်၊ အသုံးပြုသူများနှင့် ပံ့ပိုးကူညီမှုများအပေါ်အခြေခံ၍ ကျွန်ုပ်တို့သည် ဗိသုကာတစ်ခုလုံးကို ဖြည်းဖြည်းချင်းပြောင်းလဲပါသည်။

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

ထို့နောက် EBS - Elastic Block Storage ဒေတာ သိုလှောင်မှုအား ပိတ်ဆို့ရန် ဝင်ရောက်ခွင့်ကို ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် ကွန်ရက်နှင့် သိုလှောင်မှု ပေါင်းစပ်မှုဖြစ်သည်။ အခက်အခဲမှာ Network Accelerator ကတ်များသည် စျေးကွက်တွင် တည်ရှိနေသော်လည်း Storage Accelerator ဟာ့ဒ်ဝဲကို ရိုးရှင်းစွာ ဝယ်ယူရန် ရွေးချယ်ခွင့်မရှိပေ။ ဒီတော့ ကျွန်တော်တို့က startup တစ်ခုဆီ ပြောင်းသွားတယ်။ Annapurna ဓာတ်ခွဲခန်းကျွန်ုပ်တို့အတွက် အထူး ASIC ချစ်ပ်များကို တီထွင်ခဲ့သူဖြစ်သည်။ ၎င်းတို့သည် အဝေးထိန်း EBS အတွဲများကို NVMe စက်ပစ္စည်းများအဖြစ် တပ်ဆင်ခွင့်ပြုထားသည်။

သာဓကများ C4 ပြဿနာနှစ်ခုကို ဖြေရှင်းပေးခဲ့တယ်။ ပထမအချက်မှာ ကျွန်ုပ်တို့သည် အလားအလာရှိသော အနာဂတ်အတွက် အခြေခံအုတ်မြစ်ကို အကောင်အထည်ဖော်ခဲ့သော်လည်း ထိုအချိန်က NVMe နည်းပညာအသစ်ဖြစ်သည်။ ဒုတိယ၊ ကျွန်ုပ်တို့သည် EBS သို့ တောင်းဆိုချက်များကို ကတ်အသစ်တစ်ခုသို့ လွှဲပြောင်းခြင်းဖြင့် ဗဟိုပရိုဆက်ဆာကို သိသိသာသာ ဖြုတ်ချခဲ့သည်။ ၎င်းသည် ကောင်းမွန်လာပြီဖြစ်သောကြောင့် ယခု Annapurna Labs သည် Amazon ၏ အစိတ်အပိုင်းဖြစ်သည်။

2017 ခုနှစ် နိုဝင်ဘာလတွင်၊ hypervisor ကိုယ်တိုင်ပြောင်းလဲရန်အချိန်ရောက်ပြီဟု ကျွန်ုပ်တို့သဘောပေါက်ပါသည်။

hypervisor အသစ်ကို ပြုပြင်ထားသော KVM kernel modules များအပေါ် အခြေခံ၍ တီထွင်ခဲ့သည်။

၎င်းသည် စက်ပစ္စည်းအတုယူခြင်း၏ အကျုံးဝင်မှုကို အခြေခံကျကျ လျှော့ချနိုင်ပြီး ASICs အသစ်များနှင့် တိုက်ရိုက်အလုပ်လုပ်နိုင်စေခဲ့သည်။ ဖစ်စဉ်များ S5 hood အောက်တွင် hypervisor အသစ်ဖြင့်အလုပ်လုပ်သောပထမဆုံး virtual machines များဖြစ်သည်။ ငါတို့က သူ့ကို နာမည်ပေးတယ်။ Nitro.

timeline ပေါ်ရှိ သာဓကများ၏ ဆင့်ကဲဖြစ်စဉ်။

2017 ခုနှစ် နိုဝင်ဘာလကတည်းက ပေါ်ထွက်ခဲ့သော virtual machines အမျိုးအစားအသစ်အားလုံးကို ဤ hypervisor တွင် အသုံးပြုပါသည်။ Bare Metal သာဓကများတွင် hypervisor မရှိပါ။အထူးပြု Nitro ကတ်များကို အသုံးပြုသောကြောင့် ၎င်းတို့ကို Nitro ဟုခေါ်သည်။

လာမည့်နှစ်နှစ်အတွင်းတွင်၊ Nitro ဖြစ်ရပ်အမျိုးအစားအရေအတွက်သည် A1၊ C5၊ M5၊ T3 နှင့် အခြားဒါဇင်အချို့ကို ကျော်လွန်သွားခဲ့သည်။

ဥပမာ အမျိုးအစားများ။

ခေတ်မီ Nitro စက်တွေ ဘယ်လိုအလုပ်လုပ်လဲ။

၎င်းတို့တွင် အဓိက အစိတ်အပိုင်း ၃ ခု ရှိသည်- Nitro hypervisor (အထက်တွင် ဆွေးနွေးခဲ့သည်)၊ လုံခြုံရေး ချစ်ပ်နှင့် Nitro ကတ်များ။

လုံခြုံရေး ချစ်ပ် motherboard တွင်တိုက်ရိုက်ပေါင်းစပ်ထားသည်။ ၎င်းသည် host OS ၏ loading ကိုထိန်းချုပ်ခြင်းကဲ့သို့သောအရေးကြီးသောလုပ်ဆောင်ချက်များစွာကိုထိန်းချုပ်သည်။

Nitro ကတ်များ - အမျိုးအစား လေးမျိုးရှိပါတယ်။ ၎င်းတို့အားလုံးကို Annapurna Labs မှ ဖန်တီးထားပြီး အများသုံး ASICs များကို အခြေခံထားသည်။ သူတို့ရဲ့ Firmware တစ်ချို့မှာလည်း အသုံးများပါတယ်။

Nitro ကတ် လေးမျိုး။

ကတ်များထဲမှ တစ်ခုနှင့် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ကွန်ယက်VPC. ၎င်းကို ကွန်ရက်ကတ်တစ်ခုအနေဖြင့် virtual machines များတွင် မြင်နိုင်သည်။ ENA - Elastic Network Adapter. ၎င်းသည် ရုပ်ပိုင်းဆိုင်ရာကွန်ရက်မှတဆင့် ထုတ်လွှင့်သည့်အခါ အသွားအလာကို ဖုံးအုပ်ပေးသည် (ဆောင်းပါး၏ ဒုတိယအပိုင်းတွင် ဤအကြောင်းကို ဆွေးနွေးပါမည်)၊ Security Groups firewall ကို ထိန်းချုပ်ပြီး လမ်းကြောင်းနှင့် အခြားကွန်ရက်အရာများအတွက် တာဝန်ရှိပါသည်။

ပိတ်ဆို့သိုလှောင်မှုနှင့်အတူ ကတ်များကို ရွေးချယ်ပါ။ EBS နှင့် server တွင်တည်ဆောက်ထားသော disk များ။ ၎င်းတို့သည် guest virtual machine အဖြစ် ပေါ်လာသည်။ NVMe အဒက်တာများ. ၎င်းတို့သည် data encryption နှင့် disk monitoring အတွက်လည်း တာဝန်ရှိပါသည်။

Nitro ကတ်များ၊ hypervisor နှင့် လုံခြုံရေး ချစ်ပ်များ၏ စနစ်အား SDN ကွန်ရက် သို့မဟုတ် ပေါင်းစပ်ထားသည်။ Software Defined Network. ဤကွန်ရက်ကို စီမံခန့်ခွဲရန် တာဝန်ရှိသည် (Control Plane) controller ကတ်.

ဟုတ်ပါတယ်၊ ကျွန်ုပ်တို့သည် ASICs အသစ်များကို ဆက်လက်ဖန်တီးနေပါသည်။ ဥပမာအားဖြင့်၊ 2018 နှစ်ကုန်တွင် ၎င်းတို့သည် စက်သင်ယူခြင်းလုပ်ငန်းဆောင်တာများနှင့် ပိုမိုထိရောက်စွာလုပ်ဆောင်နိုင်စေသည့် Inferentia ချစ်ပ်ကို ထုတ်ပြန်ခဲ့သည်။

Inferentia Machine Learning Processor ချစ်ပ်။

အတိုင်းအတာ ဒေတာဘေ့စ်

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

• SQL - client နှင့် request dispatchers သည် ၎င်းတွင် အလုပ်လုပ်ပါသည်။
• စားစရိတ် အရောင်းအဝယ်များ - ဤနေရာတွင်၊ ACID နှင့်အရာအားလုံးရှင်းလင်းသည်။
• သိမ်းဆည်းခြင်း။ကြားခံရေကန်များမှ ပံ့ပိုးပေးသော၊
• သစ်ခုတ်ခြင်း။ - redo မှတ်တမ်းများနှင့်အတူအလုပ်လုပ်ပေးသည်။ MySQL တွင် ၎င်းတို့အား PosgreSQL - Write Ahead Logs (WAL) တွင် Bin Logs ဟုခေါ်သည်။
• သိုလှောင်မှု - disk သို့တိုက်ရိုက်မှတ်တမ်းတင်ခြင်း။

ဒေတာဘေ့စ်ဖွဲ့စည်းပုံ အလွှာ။

ဒေတာဘေ့စ်များကို ချဲ့ထွင်ရန် မတူညီသော နည်းလမ်းများ ရှိသည်- sharding၊ Shared Nothing architecture၊ shared disks။

သို့သော်၊ ဤနည်းလမ်းအားလုံးသည် တူညီသော monolithic ဒေတာဘေ့စ်ဖွဲ့စည်းပုံကို ထိန်းသိမ်းထားသည်။ ၎င်းသည် အတိုင်းအတာကို သိသိသာသာ ကန့်သတ်ထားသည်။ ဤပြဿနာကိုဖြေရှင်းရန်ကျွန်ုပ်တို့သည်ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဒေတာဘေ့စကိုတီထွင်ခဲ့သည်။ အမေဇုံ Aurora. ၎င်းသည် MySQL နှင့် PostgreSQL တို့နှင့် တွဲဖက်အသုံးပြုနိုင်သည်။

အမေဇုံ Aurora

ပင်မဒေတာဘေ့စ်မှ သိုလှောင်မှုနှင့် မှတ်တမ်းအဆင့်များကို ခွဲထုတ်ရန် အဓိက ဗိသုကာဆိုင်ရာ စိတ်ကူးဖြစ်သည်။

ရှေ့ကိုကြည့်လိုက်ပါ၊ ကျွန်ုပ်တို့သည် ကက်ရှ်အဆင့်ကိုလည်း သီးခြားပြုလုပ်ထားသည်ဟု ပြောပါမည်။ ဗိသုကာလက်ရာသည် monolith ဖြစ်မလာတော့ဘဲ တစ်ဦးချင်းလုပ်ကွက်များကို ချဲ့ထွင်ရာတွင် လွတ်လပ်မှုထပ်ဆင့်ရရှိပါသည်။

မှတ်တမ်းနှင့် သိုလှောင်မှုအဆင့်များသည် ဒေတာဘေ့စ်မှ သီးခြားဖြစ်သည်။

သမားရိုးကျ DBMS သည် ဘလောက်များပုံစံဖြင့် သိုလှောင်မှုစနစ်သို့ ဒေတာကို ရေးသည်။ Amazon Aurora တွင် ကျွန်ုပ်တို့သည် ဘာသာစကားပြောနိုင်သော စမတ်သိုလှောင်မှုကို ဖန်တီးခဲ့သည်။ မှတ်တမ်းများကို ပြန်လုပ်ပါ။. အတွင်းတွင်၊ သိုလှောင်မှုသည် မှတ်တမ်းများကို ဒေတာဘလောက်များအဖြစ် ပြောင်းလဲပေးကာ ၎င်းတို့၏ ခိုင်မာမှုကို စောင့်ကြည့်ကာ အလိုအလျောက် အရန်သိမ်းသည်။

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

သိုလှောင်မှုအလွှာကို ဖြန့်ဝေသည့်စနစ်အဖြစ် အကောင်အထည်ဖော်သည်။ ၎င်းတွင် ရုပ်ပိုင်းဆိုင်ရာ ဆာဗာများ အများအပြား ပါဝင်ပါသည်။ ပြန်လည်လုပ်ဆောင်မှုမှတ်တမ်းတစ်ခုစီကို လုပ်ဆောင်ပြီး တစ်ပြိုင်နက် သိမ်းဆည်းထားသည်။ ခြောက်ထုံး. ၎င်းသည် ဒေတာကာကွယ်ရေးနှင့် ဝန်ချိန်ခွင်လျှာကို သေချာစေသည်။

သင့်လျော်သော ပုံစံတူများကို အသုံးပြု၍ အကျယ်တဝင့်ဖတ်ခြင်းကို အောင်မြင်နိုင်သည်။ ဖြန့်ဝေထားသော သိုလှောင်မှုသည် ကျွန်ုပ်တို့ ဒေတာရေးသားသော ပင်မဒေတာဘေ့စ်ဥပမာနှင့် ကျန်ပုံတူများအကြား ထပ်တူပြုမှုလိုအပ်မှုကို ဖယ်ရှားပေးပါသည်။ ခေတ်မီဒေတာသည် ပုံစံတူအားလုံးအတွက် ရနိုင်မည်ဟု အာမခံပါသည်။

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

ကျွန်ုပ်တို့သည် သိုလှောင်ခန်းကို ခွဲခြားထားသည်။

DBMS အဆင့်များကို မည်ကဲ့သို့စကေးရမည်နည်း။

ဤတွင်၊ အလျားလိုက် အတိုင်းအတာသည် ပို၍ခက်ခဲသည်။ ဒါဆို အရိုက်ခံရတဲ့လမ်းကို သွားရအောင် classic ဒေါင်လိုက် အတိုင်းအတာ.

ကျွန်ုပ်တို့တွင် master node မှတဆင့် DBMS နှင့် ဆက်သွယ်နိုင်သော application တစ်ခုရှိသည်ဟု ယူဆကြပါစို့။

ဒေါင်လိုက် စကေးချဲ့သောအခါ၊ ကျွန်ုပ်တို့သည် ပရိုဆက်ဆာနှင့် မန်မိုရီပိုရှိသော node အသစ်တစ်ခုကို ခွဲဝေပေးသည်။

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

• ၎င်းသည် သိသာထင်ရှားသော အပလီကေးရှင်း ရပ်တန့်ချိန် လိုအပ်မည်ဖြစ်သည်။
• master node အသစ်တွင် cold cache ရှိပါမည်။ ကက်ရှ်ပူနွေးလာမှသာလျှင် ဒေတာဘေ့စ်စွမ်းဆောင်ရည်သည် အမြင့်ဆုံးဖြစ်လိမ့်မည်။

အခြေအနေကို ဘယ်လိုတိုးတက်အောင်လုပ်မလဲ။ အပလီကေးရှင်းနှင့် master node အကြား ပရောက်စီတစ်ခုကို သတ်မှတ်ပါ။

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

ပြဿနာပြေလည်သွားပုံရသည်။ သို့သော်၊ ကျွန်ုပ်တို့သည် ကက်ရှ်ကို ပူနွေးရန် လိုအပ်နေဆဲဖြစ်သည်။ ထို့အပြင်၊ ပြဿနာအသစ်တစ်ခုပေါ်လာသည် - ယခု proxy သည် ကျရှုံးနိုင်သည့်အလားအလာတစ်ခုဖြစ်သည်။

Amazon Aurora serverless ဖြင့် နောက်ဆုံးဖြေရှင်းချက်

ဤပြဿနာများကို ကျွန်ုပ်တို့ မည်သို့ဖြေရှင်းခဲ့သနည်း။

ပရောက်စီတစ်ခုချန်ခဲ့သည်။. ၎င်းသည် သီးခြားဥပမာတစ်ခုမဟုတ်သော်လည်း အပလီကေးရှင်းများဒေတာဘေ့စ်သို့ချိတ်ဆက်ပေးသော ပရိုစီများမှတစ်ဆင့် ဖြန့်ဝေထားသော အစုအဝေးတစ်ခုဖြစ်သည်။ ချို့ယွင်းပါက၊ မည်သည့် node မဆို ချက်ချင်းနီးပါး အစားထိုးနိုင်သည်။

အရွယ်အစားအမျိုးမျိုးရှိ နွေးထွေးသော ဆုံမှတ်များ ရေကန်တစ်ခုကို ပေါင်းထည့်ခဲ့သည်။. ထို့ကြောင့်၊ အရွယ်အစားပိုကြီးသော သို့မဟုတ် သေးငယ်သော node အသစ်တစ်ခုကို ခွဲဝေပေးရန် လိုအပ်ပါက၊ ၎င်းကို ချက်ချင်းရနိုင်သည်။ တင်ရန်စောင့်စရာမလိုပါ။

အတိုင်းအတာ လုပ်ငန်းစဉ်တစ်ခုလုံးကို အထူးစောင့်ကြည့်ရေးစနစ်ဖြင့် ထိန်းချုပ်ထားသည်။ စောင့်ကြည့်ခြင်းသည် လက်ရှိ master node ၏အခြေအနေကို အဆက်မပြတ်စောင့်ကြည့်သည်။ ဥပမာအားဖြင့်၊ ပရိုဆက်ဆာဝန်သည် အရေးကြီးသောတန်ဖိုးသို့ရောက်ရှိကြောင်းတွေ့ရှိပါက၊ node အသစ်တစ်ခုခွဲဝေရန်လိုအပ်ကြောင်း နွေးထွေးသောဖြစ်ရပ်များ၏အစုအဝေးကို အသိပေးသည်။

ဖြန့်ဝေထားသော ပရောက်စီများ၊ နွေးထွေးသောဖြစ်ရပ်များနှင့် စောင့်ကြည့်ခြင်း။

လိုအပ်သောပါဝါရှိသော node ကိုရနိုင်သည်။ Buffer Pools များကို ၎င်းထံ ကူးယူပြီး၊ စနစ်သည် ပြောင်းရန် ဘေးကင်းသော အခိုက်အတန့်ကို စောင့်ဆိုင်းနေပါသည်။

အများအားဖြင့် ပြောင်းရန်အခိုက်အတန့်သည် အလွန်လျင်မြန်သည်။ ထို့နောက် proxy နှင့် master node အဟောင်းကြား ဆက်သွယ်ရေးကို ရပ်ဆိုင်းလိုက်ပြီး၊ session အားလုံးကို node အသစ်သို့ ပြောင်းသည်။

ဒေတာဘေ့စ်ကိုယ်ရေးရာဇဝင်နှင့်အတူအလုပ်လုပ်။

ဂရပ်သည် ဆိုင်းထိန်းစနစ်သည် အမှန်တကယ် တိုတောင်းကြောင်း ပြသသည်။ အပြာရောင်ဂရပ်သည် ဝန်ကိုပြသပြီး အနီရောင်အဆင့်များသည် အတိုင်းအတာအချိန်များကိုပြသသည်။ အပြာရောင်ဂရပ်တွင် ရေတိုကျဆင်းမှုသည် တိုတောင်းသောနှောင့်နှေးမှုကို အတိအကျဖော်ပြသည်။

စကားမစပ်၊ Amazon Aurora သည် သင့်အား ငွေကြေးအကုန်အကျသက်သာစေပြီး ဥပမာ၊ စနေ၊ တနင်္ဂနွေများတွင် အသုံးမပြုသည့်အခါတွင် ဒေတာဘေ့စ်ကို ပိတ်ပစ်နိုင်သည်။ ဝန်ကိုရပ်တန့်ပြီးနောက်၊ DB သည် ၎င်း၏ပါဝါကို တဖြည်းဖြည်းလျှော့ချပြီး အချိန်အတန်ကြာ ပိတ်သွားပါသည်။ ဝန်ပြန်တက်လာသောအခါ၊ ချောမွေ့စွာပြန်တက်လာလိမ့်မည်။

Amazon စက်ပစ္စည်းအကြောင်း ဇာတ်လမ်း၏ နောက်အပိုင်းတွင်၊ ကွန်ရက်စကေးချဲ့ခြင်းအကြောင်း ဆွေးနွေးပါမည်။ စာရင်းသွင်းပါ။ မေးလ် ဆောင်းပါးကို လက်လွတ်မခံဘဲ စောင့်မျှော်ကြည့်ရှုပါ။

အပေါ် HighLoad++ Vasily Pantyukhin က အစီရင်ခံတင်ပြပါမည်။ဟူစတန်၊ ငါတို့မှာ ပြဿနာရှိတယ်။ ပျက်ကွက်မှုအတွက် စနစ်များ ဒီဇိုင်း၊ အတွင်းပိုင်း Amazon cloud ဝန်ဆောင်မှုများအတွက် ဖွံ့ဖြိုးတိုးတက်မှုပုံစံများ“ ဖြန့်ဝေသည့်စနစ်များအတွက် ဒီဇိုင်းပုံစံများကို Amazon developer များကအသုံးပြုကြသည်၊ ဝန်ဆောင်မှုမအောင်မြင်ရသည့်အကြောင်းရင်းများ၊ Cell-based architecture၊ Constant Work၊ Shuffle Sharding ဟူသည် စိတ်ဝင်စားစရာဖြစ်လိမ့်မည်။ ညီလာခံကျင်းပရန် တစ်လမပြည့်မီ၊ သင်၏လက်မှတ်များကိုကြိုတင်မှာယူပါ။. အောက်တိုဘာလ 24 ရက်နေ့ နောက်ဆုံးထား စျေးနှုန်းများ မြင့်တက်ခဲ့သည်။

source: www.habr.com