အင်တာနက်တောင်းဆိုမှုများကို အရှိန်မြှင့်ပြီး ငြိမ်းချမ်းစွာ အိပ်စက်ပါ။

Netflix သည် ဤအပိုင်းကို ဖန်တီးပြီး တက်ကြွစွာ တီထွင်ဖန်တီးနေသည့် ကုမ္ပဏီဖြစ်ပြီး အင်တာနက် ရုပ်သံစျေးကွက်တွင် ဦးဆောင်သူဖြစ်သည်။ Netflix သည် ၎င်း၏ကျယ်ပြန့်သောရုပ်ရှင်များနှင့် တီဗီစီးရီးများ၏ ကျယ်ပြောလှသော ကက်တလောက်အတွက်သာမက ကမ္ဘာဂြိုဟ်၏ထောင့်တိုင်းနှင့် မျက်နှာပြင်တိုင်းနီးပါးမှ ရရှိနိုင်သော စက်ပစ္စည်းများအတွက်သာမက ၎င်း၏ယုံကြည်စိတ်ချရသော အခြေခံအဆောက်အအုံနှင့် ထူးခြားသောအင်ဂျင်နီယာယဉ်ကျေးမှုအတွက်လည်း လူသိများသည်။

ရှုပ်ထွေးသောစနစ်များ ဖန်တီးခြင်းနှင့် ပံ့ပိုးခြင်းအတွက် Netflix ချဉ်းကပ်မှု၏ ရှင်းလင်းသော ဥပမာကို DevOops 2019 တွင် တင်ပြခဲ့သည် Sergey Fedorov - Netflix မှ ဖွံ့ဖြိုးတိုးတက်ရေးဒါရိုက်တာ။ Nizhny Novgorod State University ၏ ကွန်ပြူတာသင်္ချာနှင့် သင်္ချာဌာနမှ ဘွဲ့ရရှိသူ။ Lobachevsky သည် Netflix ရှိ Open Connect တွင်ပထမဆုံးသောအင်ဂျင်နီယာများထဲမှတစ် ဦး ဖြစ်သည်။ ဗီဒီယိုဒေတာကို စောင့်ကြည့်ခြင်းနှင့် ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် စနစ်များကို ဖန်တီးခဲ့ပြီး အင်တာနက်ချိတ်ဆက်မှုအမြန်နှုန်းကို အကဲဖြတ်ရန် ရေပန်းစားသော FAST.com ဝန်ဆောင်မှုကို စတင်ခဲ့ပြီး ပြီးခဲ့သောနှစ်အနည်းငယ်အတွင်း Netflix အက်ပလီကေးရှင်းသည် သုံးစွဲသူများအတွက် တတ်နိုင်သမျှ မြန်ဆန်စွာ အလုပ်လုပ်နိုင်စေရန်အတွက် အင်တာနက်တောင်းဆိုမှုများကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ခဲ့သည်။

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

၎င်း၏အစီရင်ခံစာတွင် Sergei ကအသေးစိတ်ပြောခဲ့သည်။

• client နှင့် server အကြားအင်တာနက်တောင်းဆိုမှုများနှောင့်နှေးမှုအပေါ်အကျိုးသက်ရောက်မှုရှိသည်နှင့် ပတ်သက်၍
• ဤနှောင့်နှေးမှုကို မည်သို့လျှော့ချနိုင်မည်နည်း။
• အမှားအယွင်းခံနိုင်သော စနစ်များကို ဒီဇိုင်းဆွဲခြင်း၊ ထိန်းသိမ်းခြင်းနှင့် စောင့်ကြည့်နည်း၊
• အချိန်တိုအတွင်း ရလဒ်များအောင်မြင်ရန် နှင့် လုပ်ငန်းအတွက် အန္တရာယ်အနည်းဆုံးနည်းဖြင့်၊
• ရလဒ်တွေကို ဘယ်လိုခွဲခြမ်းစိတ်ဖြာပြီး အမှားတွေကနေ သင်ခန်းစာယူမလဲ။

ကော်ပိုရေးရှင်းကြီးများတွင် အလုပ်လုပ်နေသူများသာမက အဆိုပါမေးခွန်းများအတွက် အဖြေများကို လိုအပ်ပါသည်။

တင်ပြထားသော အခြေခံမူများနှင့် နည်းစနစ်များကို အင်တာနက် ထုတ်ကုန်များကို တီထွင်ပြီး ပံ့ပိုးပေးသူတိုင်း သိရှိပြီး ကျင့်သုံးသင့်ပါသည်။

နောက်တစ်ခုကတော့ ဟောပြောသူရဲ့ အမြင်နဲ့ ဇာတ်ကြောင်းပါ။

အင်တာနက်အမြန်နှုန်း၏အရေးပါမှု

အင်တာနက်တောင်းဆိုမှုများ၏ အမြန်နှုန်းသည် လုပ်ငန်းနှင့် တိုက်ရိုက်သက်ဆိုင်သည်။ စျေးဝယ်လုပ်ငန်းကို သုံးသပ်ကြည့်ပါ- ၂၀၀၉ ခုနှစ်တွင် Amazon စကားပြောသည်။100ms နှောင့်နှေးခြင်းသည် အရောင်း၏ 1% ဆုံးရှုံးစေသည်။

မိုဘိုင်းဆိုက်များနှင့် အပလီကေးရှင်းများနောက်တွင် မိုဘိုင်းလ်စက်ပစ္စည်းများ ပိုများလာပါသည်။ သင့်စာမျက်နှာကို ဖွင့်ရန် 3 စက္ကန့်ထက် ပိုကြာပါက သင့်အသုံးပြုသူ တစ်ဝက်ခန့် ဆုံးရှုံးသွားမည်ဖြစ်သည်။ အတူ ဇူလိုင်လ 2018 Google သည် ရှာဖွေမှုရလဒ်များတွင် သင့်စာမျက်နှာ၏ loading speed ကို ထည့်သွင်းစဉ်းစားသည်- စာမျက်နှာပိုမြန်လေ၊ Google တွင် ၎င်း၏ရာထူးပိုမြင့်လေဖြစ်သည်။

latency သည် အရေးပါသော ဘဏ္ဍာရေးအဖွဲ့အစည်းများတွင် ချိတ်ဆက်မှုအမြန်နှုန်းသည်လည်း အရေးကြီးပါသည်။ 2015 ခုနှစ်တွင် Hibernia Networks ပြီးပြီ။ နယူးယောက်နှင့်လန်ဒန်ကြားရှိ မြို့များကြားနေချိန်ကို 400ms လျှော့ချရန် ဒေါ်လာသန်း 6 ကေဘယ်လ်တစ်ခု။ 66 ms latency လျှော့ချမှုအတွက် $1 သန်းကို စိတ်ကူးကြည့်ပါ။

အတိုင်း သုတေသန5 Mbit/s အထက် ချိတ်ဆက်မှုအမြန်နှုန်းများသည် ပုံမှန်ဝဘ်ဆိုဒ်တစ်ခု၏ loading speed ကို တိုက်ရိုက်သက်ရောက်မှု မရှိတော့ပါ။ သို့သော်၊ ချိတ်ဆက်မှု latency နှင့် စာမျက်နှာဖွင့်ခြင်းအမြန်နှုန်းကြားတွင် တစ်ပြေးညီ ဆက်စပ်မှုရှိသည်-

သို့သော် Netflix သည် ပုံမှန်ထုတ်ကုန်တစ်ခုမဟုတ်ပါ။ သုံးစွဲသူအပေါ် latency နှင့် speed ၏ သက်ရောက်မှုသည် ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် ဖွံ့ဖြိုးတိုးတက်မှု၏ တက်ကြွသောနယ်ပယ်တစ်ခုဖြစ်သည်။ အပလီကေးရှင်းတင်ခြင်းနှင့် latency ပေါ်မူတည်၍ အကြောင်းအရာရွေးချယ်မှုများရှိသော်လည်း တည်ငြိမ်သောဒြပ်စင်များကိုဖွင့်ခြင်းနှင့် တိုက်ရိုက်လွှင့်ခြင်းတို့သည် ချိတ်ဆက်မှုအမြန်နှုန်းပေါ်တွင်မူတည်ပါသည်။ အသုံးပြုသူအတွေ့အကြုံကို လွှမ်းမိုးနိုင်သည့် အဓိကအချက်များကို ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းသည် Netflix ရှိအဖွဲ့များစွာအတွက် ဖွံ့ဖြိုးတိုးတက်မှု၏တက်ကြွသောနယ်ပယ်တစ်ခုဖြစ်သည်။ ရည်မှန်းချက်များထဲမှတစ်ခုမှာ Netflix စက်ပစ္စည်းများနှင့် cloud အခြေခံအဆောက်အအုံများကြားတွင် တောင်းဆိုမှုများ၏ကြာချိန်ကို လျှော့ချရန်ဖြစ်သည်။

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

Netflix အတွင်း

မတူညီသော စက်ပစ္စည်းထောင်ပေါင်းများစွာသည် Netflix အက်ပ်များကို ပံ့ပိုးပေးသည်။ ၎င်းတို့ကို Android၊ iOS၊ TV နှင့် ဝဘ်ဘရောက်ဆာများအတွက် သီးခြားဗားရှင်းများ ပြုလုပ်ပေးသည့် မတူညီသောအဖွဲ့လေးဖွဲ့က တီထွင်ဖန်တီးထားသည်။ ကျွန်ုပ်တို့သည် အသုံးပြုသူအတွေ့အကြုံကို မြှင့်တင်ရန်နှင့် ပုဂ္ဂိုလ်ရေးသီးသန့်ပြုလုပ်ရန် အားထုတ်မှုများစွာကို သုံးစွဲပါသည်။ ဒါကိုလုပ်ဖို့၊ ရာနဲ့ချီတဲ့ A/B စစ်ဆေးမှုတွေကို အပြိုင်လုပ်ဆောင်ပါတယ်။

ပုဂ္ဂိုလ်ရေးသီးသန့်ပြုလုပ်ခြင်းကို AWS cloud ရှိ ရာနှင့်ချီသော microservices များမှ ပံ့ပိုးထားပြီး၊ ပုဂ္ဂိုလ်ရေးသီးသန့်အသုံးပြုသူဒေတာ၊ query dispatch၊ telemetry၊ Big Data နှင့် Encoding တို့ကို ပံ့ပိုးပေးပါသည်။ Traffic Visualization သည် ဤကဲ့သို့ ဖြစ်သည်-

သရုပ်ပြဗီဒီယိုလင့်ခ် (6:04-6:23)

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

ကျွန်ုပ်တို့၏အခြေခံအဆောက်အအုံ၏နောက်ထပ်အရေးကြီးသောအစိတ်အပိုင်းမှာ အသုံးပြုသူထံသို့ တည်ငြိမ်သောအကြောင်းအရာများကို ပေးဆောင်သည့် Open Connect CDN ဖြစ်သည် - ဗီဒီယိုများ၊ ရုပ်ပုံများ၊ ကုဒ်၊ စသည်ဖြင့်။ CDN သည် စိတ်ကြိုက်ဆာဗာများ (OCA - Open Connect Appliance) တွင် တည်ရှိသည်။ အတွင်းတွင် NGINX နှင့် ဝန်ဆောင်မှုအစုံပါရှိသော အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ထားသော FreeBSD လည်ပတ်နေသော SSD နှင့် HDD drive များရှိသည်။ ကျွန်ုပ်တို့သည် ဟာ့ဒ်ဝဲနှင့် ဆော့ဖ်ဝဲလ် အစိတ်အပိုင်းများကို ဒီဇိုင်းဆွဲကာ အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပေးသောကြောင့် ထိုကဲ့သို့သော CDN ဆာဗာသည် သုံးစွဲသူများထံ တတ်နိုင်သမျှ အချက်အလက်များစွာ ပေးပို့နိုင်မည်ဖြစ်သည်။

အင်တာနက်အသွားအလာဖလှယ်သည့်နေရာ (Internet eXchange - IX) ရှိ ဤဆာဗာများ၏ "နံရံ" သည် ဤကဲ့သို့ ဖြစ်သည်-

Internet Exchange သည် အင်တာနက်ဝန်ဆောင်မှုပေးသူများနှင့် အကြောင်းအရာပံ့ပိုးပေးသူများအတွက် အင်တာနက်ပေါ်ရှိ ဒေတာကို တိုက်ရိုက်ဖလှယ်ရန် အချင်းချင်း “ချိတ်ဆက်” နိုင်စေပါသည်။ ကျွန်ုပ်တို့၏ဆာဗာများကို တပ်ဆင်သည့် ကမ္ဘာတစ်ဝှမ်းတွင် ခန့်မှန်းခြေအားဖြင့် 70-80 Internet Exchange Points များရှိပြီး ၎င်းတို့ကို လွတ်လပ်စွာ တပ်ဆင်ထိန်းသိမ်းထားပါသည်။

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

AWS ဝန်ဆောင်မှုအစုတစ်ခုသည် သုံးစွဲသူများထံမှ ဗီဒီယိုတောင်းဆိုမှုများကို CDN ဆာဗာများသို့ ပေးပို့ခြင်းအပြင် ဆာဗာများကိုယ်တိုင် စီစဉ်သတ်မှတ်ခြင်း - အကြောင်းအရာ၊ ပရိုဂရမ်ကုဒ်၊ ဆက်တင်များ စသည်တို့ကို အပ်ဒိတ်လုပ်ခြင်း။ နောက်ဆုံးတွင်၊ ကျွန်ုပ်တို့သည် AWS နှင့် Internet Exchange အမှတ်များရှိ ဆာဗာများကို ချိတ်ဆက်ပေးသည့် ကျောရိုးကွန်ရက်ကိုလည်း တည်ဆောက်ခဲ့သည်။ ကျောရိုးကွန်ရက်သည် ကျွန်ုပ်တို့၏လိုအပ်ချက်များအပေါ်အခြေခံ၍ ကျွန်ုပ်တို့ဒီဇိုင်းရေးဆွဲကာ ပြင်ဆင်သတ်မှတ်နိုင်သော ဖိုက်ဘာအော့ပတစ်ကေဘယ်လ်များနှင့် router များ၏ ကမ္ဘာလုံးဆိုင်ရာကွန်ရက်တစ်ခုဖြစ်သည်။

အပေါ် Sandvine ခန့်မှန်းချက်ကျွန်ုပ်တို့၏ CDN အခြေခံအဆောက်အဦသည် အမြင့်ဆုံးနာရီများအတွင်း ကမ္ဘာ့အင်တာနက်အသွားအလာ၏ ⅛ ခန့်နှင့် Netflix သည် အရှည်ကြာဆုံးဖြစ်သည့် မြောက်အမေရိကရှိ သွားလာမှု၏ ⅓ ကို ပေးဆောင်ပါသည်။ အထင်ကြီးလောက်စရာ ကိန်းဂဏန်းများ ဖြစ်သော်လည်း ကျွန်ုပ်အတွက် အံ့သြဖွယ်အကောင်းဆုံး အောင်မြင်မှုများထဲမှ တစ်ခုမှာ CDN စနစ်တစ်ခုလုံးကို လူ 150 အောက်ရှိသော အဖွဲ့မှ တီထွင်ထိန်းသိမ်းထားခြင်း ဖြစ်ပါသည်။

အစပိုင်းတွင်၊ CDN အခြေခံအဆောက်အအုံသည် ဗီဒီယိုဒေတာပေးပို့ရန် ဒီဇိုင်းထုတ်ထားသည်။ သို့သော်လည်း အချိန်ကြာလာသည်နှင့်အမျှ AWS cloud ရှိ client များထံမှ dynamic တောင်းဆိုမှုများကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် ၎င်းကိုလည်း အသုံးပြုနိုင်ကြောင်း သိရှိလာခဲ့သည်။

အင်တာနက် အရှိန်မြှင့်ခြင်းအကြောင်း

ယနေ့တွင်၊ Netflix တွင် AWS ဒေသ 3 ခုရှိပြီး၊ cloud သို့တောင်းဆိုမှုများ၏ကြာချိန်သည် အနီးဆုံးဒေသမှဖောက်သည်မည်မျှဝေးသည်အပေါ် မူတည်မည်ဖြစ်သည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့တွင် တည်ငြိမ်သောအကြောင်းအရာများကို ပေးပို့ရန်အသုံးပြုသော CDN ဆာဗာများစွာရှိသည်။ ဒိုင်းနမစ်မေးခွန်းများကို အရှိန်မြှင့်ရန် ဤဘောင်ကို အသုံးပြုရန် နည်းလမ်းရှိပါသလား။ သို့သော် ကံမကောင်းစွာဖြင့်၊ ဤတောင်းဆိုမှုများကို ကက်ရှ်လုပ်ရန် မဖြစ်နိုင်ပါ - API များကို ပုဂ္ဂိုလ်ရေးသီးသန့်ပြုလုပ်ထားပြီး ရလဒ်တစ်ခုစီသည် ထူးခြားပါသည်။

CDN ဆာဗာတွင် ပရောက်စီတစ်ခုပြုလုပ်ပြီး ၎င်းမှတစ်ဆင့် လမ်းကြောင်းများကို စတင်ပေးပို့ကြပါစို့။ ပိုမြန်မှာလား။

ပစ္စည်း

ကွန်ရက်ပရိုတိုကောများ အလုပ်လုပ်ပုံကို သတိရကြပါစို့။ ယနေ့တွင်၊ အင်တာနက်ပေါ်ရှိ အသွားအလာအများစုသည် TCP နှင့် TLS အောက်လွှာပရိုတိုကောများပေါ်တွင်မူတည်သည့် HTTPs ကိုအသုံးပြုသည်။ ကလိုင်းယင့်တစ်ဦး ဆာဗာသို့ ချိတ်ဆက်ရန်အတွက်၊ ၎င်းသည် လက်ဆွဲနှုတ်ဆက်ပြီး လုံခြုံသောချိတ်ဆက်မှုတစ်ခုကို ထူထောင်ရန်အတွက်၊ ကလိုင်းယင့်သည် ဆာဗာနှင့် မက်ဆေ့ချ်များကို သုံးကြိမ် လဲလှယ်ရန်နှင့် ဒေတာလွှဲပြောင်းရန် အနည်းဆုံး နောက်ထပ်တစ်ကြိမ် လိုအပ်သည်။ အသွားအပြန်ခရီး (RTT) 100 ms ၏ latency ဖြင့်၊ ဒေတာပထမဘစ်ကိုလက်ခံရရှိရန် ကျွန်ုပ်တို့ 400 ms ကြာလိမ့်မည်-

ကျွန်ုပ်တို့သည် လက်မှတ်များကို CDN ဆာဗာတွင်ထားပါက၊ CDN သည် ပိုမိုနီးကပ်ပါက client နှင့် server အကြား လက်ဆွဲနှုတ်ဆက်ချိန်ကို သိသိသာသာ လျှော့ချနိုင်သည်။ CDN ဆာဗာသို့ latency သည် 30ms ဖြစ်သည်ဟု ယူဆကြပါစို့။ ထို့နောက် ပထမဘစ်ကို လက်ခံရရှိရန် 220 ms ကြာပါမည်။

ဒါပေမယ့် အားသာချက်တွေက မကုန်ပါဘူး။ ချိတ်ဆက်မှုတစ်ခုတည်ဆောက်ပြီးသည်နှင့် TCP သည် ပိတ်ဆို့နေသောဝင်းဒိုးကို တိုးပေးသည် (ထိုချိတ်ဆက်မှုအပေါ် အပြိုင်ပို့နိုင်သော အချက်အလက်ပမာဏ)။ ဒေတာပက်ကေ့ချ်တစ်ခု ပျောက်ဆုံးသွားပါက၊ TCP ပရိုတိုကော (TCP New Reno ကဲ့သို့) ၏ ဂန္ထဝင်အကောင်အထည်ဖော်မှုများသည် ဖွင့်ထားသော “ဝင်းဒိုး” ကို ထက်ဝက်လျှော့ချနိုင်သည်။ ပိတ်နေသည့်ဝင်းဒိုး၏ ကြီးထွားမှုနှင့် ဆုံးရှုံးမှုမှ ပြန်လည်ရယူသည့် အရှိန်သည် ဆာဗာသို့ နှောင့်နှေးမှု (RTT) ပေါ်တွင် မူတည်သည်။ ဤချိတ်ဆက်မှုသည် CDN ဆာဗာအထိသာ သွားပါက၊ ဤပြန်လည်ရယူခြင်းက ပိုမိုမြန်ဆန်မည်ဖြစ်သည်။ တစ်ချိန်တည်းမှာပင်၊ ပက်ကတ်ဆုံးရှုံးမှုသည် အထူးသဖြင့် ကြိုးမဲ့ကွန်ရက်များအတွက် စံဖြစ်စဉ်တစ်ခုဖြစ်သည်။

ယာဉ်ကြောပိတ်ဆို့မှုကို ဖြစ်စေနိုင်သည့် သုံးစွဲသူများထံမှ သွားလာမှုများကြောင့် အထူးသဖြင့် အမြင့်ဆုံးအချိန်များတွင် အင်တာနက် bandwidth ကို လျှော့ချနိုင်သည်။ သို့သော် အချို့သော တောင်းဆိုမှုများကို အခြားသူများထက် ဦးစားပေးရန် အင်တာနက်တွင် နည်းလမ်းမရှိပါ။ ဥပမာအားဖြင့်၊ ကွန်ရက်ကိုတင်ဆောင်သည့် "လေးလံသော" ဒေတာစီးကြောင်းများအတွက် အသေးစားနှင့် latency-sensitive တောင်းဆိုမှုများကို ဦးစားပေးပါ။ သို့သော်လည်း ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ကျောရိုးကွန်ရက်ရှိခြင်းသည် တောင်းဆိုမှုလမ်းကြောင်း၏တစ်စိတ်တစ်ပိုင်းဖြစ်သော CDN နှင့် cloud အကြားတွင် ၎င်းကိုလုပ်ဆောင်နိုင်စေပြီး ၎င်းကိုကျွန်ုပ်တို့အပြည့်အဝစီစဉ်နိုင်သည်။ သေးငယ်ပြီး latency-sensitive packets များကို ဦးစားပေးထားကြောင်း သေချာစေပြီး ကြီးမားသောဒေတာစီးဆင်းမှုသည် အနည်းငယ်ကြာသွားကြောင်း သေချာစေနိုင်ပါသည်။ CDN သည် client နှင့် နီးကပ်လေလေ၊ ထိရောက်မှု ပိုလေဖြစ်သည်။

အပလီကေးရှင်းအဆင့် ပရိုတိုကောများ (OSI အဆင့် 7) သည်လည်း latency အပေါ် သက်ရောက်မှုရှိသည်။ HTTP/2 ကဲ့သို့သော ပရိုတိုကောအသစ်များသည် အပြိုင်တောင်းဆိုမှုများ၏ စွမ်းဆောင်ရည်ကို ပိုကောင်းအောင်လုပ်ဆောင်သည်။ သို့သော်၊ ကျွန်ုပ်တို့တွင် ပရိုတိုကောအသစ်များကို မပံ့ပိုးနိုင်သော စက်ပစ္စည်းအဟောင်းများဖြင့် Netflix သုံးစွဲသူများရှိသည်။ ဖောက်သည်အားလုံးကို အပ်ဒိတ်လုပ်ခြင်း သို့မဟုတ် အကောင်းဆုံးပြင်ဆင်သတ်မှတ်ခြင်းမပြုနိုင်ပါ။ တစ်ချိန်တည်းမှာပင်၊ CDN proxy နှင့် cloud အကြားတွင် ပြီးပြည့်စုံသော ထိန်းချုပ်မှုနှင့် အသစ်၊ အကောင်းဆုံး ပရိုတိုကောများနှင့် ဆက်တင်များကို အသုံးပြုနိုင်စွမ်းရှိသည်။ ပရိုတိုကောအဟောင်းများပါရှိသော ထိရောက်မှုမရှိသောအပိုင်းသည် client နှင့် CDN ဆာဗာကြားတွင်သာ လုပ်ဆောင်မည်ဖြစ်သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် CDN နှင့် cloud ကြားရှိပြီးသားချိတ်ဆက်မှုတစ်ခုတွင် multiplex တောင်းဆိုမှုများကို ပြုလုပ်နိုင်ပြီး TCP အဆင့်တွင် ချိတ်ဆက်အသုံးပြုမှုကို ပိုမိုကောင်းမွန်စေပါသည်။

ကျွန်တော်တို့ တိုင်းတာတယ်။

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

• အရှိန်: ပရောက်စီက ပိုမြန်မှာလား။
• ယုံကြည်စိတ်ချရမှု: မကြာခဏ ကွဲသွားမှာလား။
• ရှုပ်ထွေး: အပလီကေးရှင်းများနှင့် မည်သို့ပေါင်းစပ်ရမည်နည်း။
• ၏ကုန်ကျစရိတ်: ထပ်လောင်းအခြေခံအဆောက်အအုံကို အသုံးပြုရန် မည်မျှကုန်ကျသနည်း။

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

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

1. RUM သို့မဟုတ် passive တောင်းဆိုမှု တိုင်းတာခြင်း။ ကျွန်ုပ်တို့သည် သုံးစွဲသူများထံမှ လက်ရှိတောင်းဆိုမှုများ၏ လုပ်ဆောင်ချိန်ကို တိုင်းတာပြီး သုံးစွဲသူ၏ လွှမ်းခြုံမှုကို အပြည့်အဝသေချာစေပါသည်။ အားနည်းချက်မှာ အချက်များစွာကြောင့်၊ ဥပမာ၊ မတူညီသော တောင်းဆိုချက်အရွယ်အစား၊ ဆာဗာနှင့် client ပေါ်တွင် လုပ်ဆောင်ချိန်တို့ကြောင့် အချက်ပြမှုမှာ အလွန်တည်ငြိမ်မှုမရှိခြင်း ဖြစ်သည်။ ထို့အပြင်၊ ထုတ်လုပ်မှုတွင်အကျိုးသက်ရောက်မှုမရှိဘဲ ဖွဲ့စည်းမှုအသစ်တစ်ခုကို သင်မစမ်းသပ်နိုင်ပါ။
2. ဓာတ်ခွဲစမ်းသပ်မှုများ။ သုံးစွဲသူများကို အတုယူသည့် အထူးဆာဗာများနှင့် အခြေခံအဆောက်အအုံများ။ ၎င်းတို့၏အကူအညီဖြင့် ကျွန်ုပ်တို့သည် လိုအပ်သောစစ်ဆေးမှုများကို လုပ်ဆောင်ပါသည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် တိုင်းတာခြင်းရလဒ်များအပေါ် အပြည့်အဝထိန်းချုပ်နိုင်ပြီး ရှင်းလင်းသောအချက်ပြမှုကို ရရှိမည်ဖြစ်သည်။ သို့သော် စက်များနှင့် အသုံးပြုသူတည်နေရာများ (အထူးသဖြင့် ကမ္ဘာတစ်ဝှမ်းရှိ ဝန်ဆောင်မှုနှင့် စက်ပစ္စည်းမော်ဒယ်ထောင်ပေါင်းများစွာအတွက် ပံ့ပိုးမှုဖြင့်) ပြီးပြည့်စုံသော လွှမ်းခြုံမှုမရှိပါ။

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

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

1. အပလီကေးရှင်းကို တင်ပြီး ကနဦးလုပ်ဆောင်ချက် ပြီးပြီးချင်း မကြာမီတွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ စုံစမ်းစစ်ဆေးမှုများကို လုပ်ဆောင်ပါသည်။
2. ဖောက်သည်သည် ဆာဗာထံ တောင်းဆိုချက်တစ်ခု ပြုလုပ်ပြီး စမ်းသပ်မှုအတွက် "ကြော်ချက်" ကို လက်ခံရရှိသည် ။ စာရွက်သည် HTTP(များ) တောင်းဆိုမှုတစ်ခုပြုလုပ်ရန်လိုအပ်သည့် URL များစာရင်းဖြစ်သည်။ ထို့အပြင်၊ ဟင်းချက်နည်းသည် တောင်းဆိုမှုဘောင်များကို စီစဉ်သတ်မှတ်သည်- တောင်းဆိုမှုများကြားနှောင့်နှေးမှု၊ တောင်းဆိုထားသည့်ဒေတာပမာဏ၊ HTTP(များ) ခေါင်းစီးများ၊ စသည်တို့ဖြစ်သည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် မတူညီသော ချက်ပြုတ်နည်းများစွာကို တပြိုင်တည်း စမ်းသပ်နိုင်သည် - ဖွဲ့စည်းမှုတစ်ခုကို တောင်းဆိုသောအခါ၊ ကျွန်ုပ်တို့သည် မည်သည့်စာရွက်ကို ထုတ်ရမည်ကို ကျပန်းဆုံးဖြတ်ပါသည်။
3. ကလိုင်းယင့်ပေါ်ရှိ ကွန်ရက်အရင်းအမြစ်များကို တက်ကြွစွာအသုံးပြုခြင်းနှင့် မဆန့်ကျင်စေရန်အတွက် စုံစမ်းစစ်ဆေးမှုစတင်ချိန်ကို ရွေးချယ်ထားသည်။ အမှန်တကယ်အားဖြင့်၊ ကလိုင်းယင့်သည် တက်ကြွခြင်းမရှိသည့်အခါ အချိန်ကို ရွေးချယ်သည်။
4. စာရွက်ကို လက်ခံရရှိပြီးနောက်၊ client သည် URL တစ်ခုစီကို တဆက်တည်း တောင်းဆိုမှုများ ပြုလုပ်သည်။ လိပ်စာတစ်ခုစီထံ တောင်းဆိုချက်ကို ထပ်ခါတလဲလဲ ခေါ်ဆိုနိုင်သည်။ "ပဲမျိုးစုံ" ။ ပထမသွေးခုန်နှုန်းတွင်၊ ချိတ်ဆက်မှုတစ်ခုတည်ဆောက်ရန်နှင့် ဒေတာဒေါင်းလုဒ်လုပ်ရန် အချိန်မည်မျှကြာသည်ကို တိုင်းတာသည်။ ဒုတိယသွေးခုန်နှုန်းတွင်၊ သတ်မှတ်ပြီးသားချိတ်ဆက်မှုတစ်ခုပေါ်တွင် ဒေတာကိုတင်ရန် လိုအပ်သည့်အချိန်ကို ကျွန်ုပ်တို့တိုင်းတာသည်။ တတိယတစ်ခု မတိုင်မီ၊ ကျွန်ုပ်တို့သည် နှောင့်နှေးမှုကို သတ်မှတ်ပြီး ပြန်လည်ချိတ်ဆက်မှုတစ်ခု ထူထောင်ခြင်း၏ အမြန်နှုန်းကို တိုင်းတာနိုင်သည် စသည်တို့ဖြစ်သည်။

   စမ်းသပ်မှုအတွင်း၊ ကျွန်ုပ်တို့သည် စက်တွင်ရရှိနိုင်သည့် ကန့်သတ်ချက်များအားလုံးကို တိုင်းတာသည်-

   • DNS တောင်းဆိုချိန်၊
   • TCP ချိတ်ဆက်မှု သတ်မှတ်ချိန်၊
   • TLS ချိတ်ဆက်မှု သတ်မှတ်ချိန်၊
   • ဒေတာပထမဘိုက်ကို လက်ခံရရှိသည့်အချိန်၊
   • စုစုပေါင်း loading အချိန်;
   • အခြေအနေရလဒ်ကုဒ်။
5. ပဲမျိုးစုံအားလုံးပြီးစီးပြီးနောက်၊ နမူနာသည် ခွဲခြမ်းစိတ်ဖြာရန်အတွက် တိုင်းတာမှုအားလုံးကို တင်ပါသည်။

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

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

လက်တွေ့စမ်းသပ်ခြင်းသီအိုရီ- ရှေ့ပြေးပုံစံ

ထိုသို့သောစနစ်ဖြင့် ကျွန်ုပ်တို့သည် တောင်းဆိုမှု latency တွင် CDN proxy များ၏ ထိရောက်မှုကို အကဲဖြတ်နိုင်ခဲ့သည်။ ယခုသင်လိုအပ်သည်-

• ပရောက်စီ ရှေ့ပြေးပုံစံ ဖန်တီးပါ။
• ရှေ့ပြေးပုံစံကို CDN ပေါ်တွင်တင်ပါ။
• တိကျသော CDN ဆာဗာတစ်ခုပေါ်တွင် သုံးစွဲသူများအား ပရောက်စီတစ်ခုသို့ မည်သို့ညွှန်ကြားရမည်ကို ဆုံးဖြတ်ပါ။
• ပရောက်စီမပါဘဲ AWS ရှိ တောင်းဆိုမှုများနှင့် စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ပါ။

တာဝန်မှာ အဆိုပြုထားသော ဖြေရှင်းချက်၏ ထိရောက်မှုကို တတ်နိုင်သမျှ မြန်မြန် အကဲဖြတ်ရန် ဖြစ်သည်။ ကွန်ရက်ချိတ်ဆက်မှု ကောင်းမွန်သော စာကြည့်တိုက်များ ရရှိနိုင်ခြင်းကြောင့် ရှေ့ပြေးပုံစံကို အကောင်အထည်ဖော်ရန် Go ကို ရွေးချယ်ခဲ့သည်။ CDN ဆာဗာတစ်ခုစီတွင်၊ ကျွန်ုပ်တို့သည် မှီခိုမှုကို လျှော့ချရန်နှင့် ပေါင်းစပ်မှုကို ရိုးရှင်းစေရန် ရှေ့ပြေးပုံစံ ပရောက်စီကို static binary တစ်ခုအဖြစ် ထည့်သွင်းထားသည်။ ကနဦးအကောင်အထည်ဖော်မှုတွင်၊ ကျွန်ုပ်တို့သည် တတ်နိုင်သမျှ standard အစိတ်အပိုင်းများကို အသုံးပြုပြီး HTTP/2 ချိတ်ဆက်မှုပေါင်းစည်းခြင်းနှင့် multiplexing တောင်းဆိုခြင်းအတွက် အသေးစားမွမ်းမံမှုများကို အသုံးပြုပါသည်။

AWS ဒေသများအကြား ဟန်ချက်ညီစေရန်၊ သုံးစွဲသူများကို ဟန်ချက်ညီစေရန် အသုံးပြုသည့် ပထဝီဝင် DNS ဒေတာဘေ့စ်ကို အသုံးပြုခဲ့သည်။ ကလိုင်းယင့်အတွက် CDN ဆာဗာကို ရွေးချယ်ရန်၊ ကျွန်ုပ်တို့သည် Internet Exchange (IX) ရှိ ဆာဗာများအတွက် TCP Anycast ကို အသုံးပြုပါသည်။ ဤရွေးချယ်မှုတွင်၊ ကျွန်ုပ်တို့သည် CDN ဆာဗာအားလုံးအတွက် IP လိပ်စာတစ်ခုကို အသုံးပြုပြီး သုံးစွဲသူအား IP hops အရေအတွက် အနည်းဆုံးဖြင့် CDN ဆာဗာထံသို့ လမ်းညွှန်သွားမည်ဖြစ်ပါသည်။ အင်တာနက်ဝန်ဆောင်မှုပေးသူများ (ISP များ) မှထည့်သွင်းထားသော CDN ဆာဗာများတွင် TCP Anycast ကို configure လုပ်ရန် router ကို ကျွန်ုပ်တို့တွင် ထိန်းချုပ်နိုင်စွမ်းမရှိသောကြောင့် ကျွန်ုပ်တို့အသုံးပြုပါသည်။ တူညီသောယုတ္တိဗေဒဗီဒီယိုကြည့်ရှုခြင်းအတွက် သုံးစွဲသူများကို အင်တာနက်ဝန်ဆောင်မှုပေးသူများထံ လမ်းညွှန်ပေးသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင် တောင်းဆိုမှုလမ်းကြောင်းသုံးမျိုးရှိသည်- ပွင့်လင်းအင်တာနက်မှတစ်ဆင့် cloud သို့၊ IX ရှိ CDN ဆာဗာတစ်ခုမှတစ်ဆင့် သို့မဟုတ် အင်တာနက်ဝန်ဆောင်မှုပေးသူတွင်ရှိသော CDN ဆာဗာမှတစ်ဆင့် အမျိုးအစားများရှိသည်။ ကျွန်ုပ်တို့၏ပန်းတိုင်မှာ မည်သည့်နည်းလမ်းက ပိုကောင်းသနည်း၊ ထုတ်လုပ်မှုသို့ တောင်းဆိုချက်များကို မည်ကဲ့သို့ပေးပို့ပုံနှင့် နှိုင်းယှဉ်ပါက proxy ၏ အကျိုးကျေးဇူးက အဘယ်နည်းဟု နားလည်ရန်ဖြစ်သည်။ ၎င်းကိုလုပ်ဆောင်ရန် ကျွန်ုပ်တို့သည် အောက်ပါအတိုင်း နမူနာစနစ်တစ်ခုကို အသုံးပြုပါသည်။

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

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

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် အရေးကြီးသောအရာများစွာကို လုပ်ဆောင်ခဲ့သည်-

1. ကျွန်ုပ်တို့သည် CDN proxy မှတစ်ဆင့် cloud သို့ client များထံမှ တောင်းဆိုမှုများ၏ မျှော်လင့်ထားသော စွမ်းဆောင်ရည်ကို အကဲဖြတ်ပါသည်။
2. ကျွန်ုပ်တို့သည် စက်ပစ္စည်းအမျိုးအစားအားလုံးမှ တကယ့်ဖောက်သည်များထံမှ ဒေတာကို လက်ခံရရှိခဲ့ပါသည်။
3. သီအိုရီကို 100% အတည်မပြုကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ပြီး CDN ​​proxy ဖြင့် ကနဦးကမ်းလှမ်းချက်သည် ကျွန်ုပ်တို့အတွက် အလုပ်မဖြစ်နိုင်ပါ။
4. ကျွန်ုပ်တို့သည် စွန့်စားခြင်းမပြုပါ - ဖောက်သည်များအတွက် ထုတ်လုပ်မှုပုံစံများကို မပြောင်းလဲခဲ့ပါ။
5. ဘာမှ ပျက်သွားတယ်။

ရှေ့ပြေးပုံစံ 2.0

ထို့ကြောင့် ပုံဆွဲဘုတ်သို့ ပြန်သွားပြီး လုပ်ငန်းစဉ်အားလုံးကို တစ်ဖန်ပြန်လုပ်ပါ။

စိတ်ကူးကတော့ 100% proxy ကိုသုံးမယ့်အစား၊ client တစ်ခုစီအတွက် အမြန်ဆုံးလမ်းကြောင်းကို ဆုံးဖြတ်ပြီး တောင်းဆိုချက်တွေကို အဲဒီကို ပို့မယ် - ဆိုလိုတာကတော့ client steering လို့ခေါ်တဲ့အရာကို ကျွန်တော်တို့ လုပ်မှာပါ။

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

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

1. client သည် host တစ်ခုအသုံးပြု၍ ဥပမာ api.netflix.xom ကိုအသုံးပြု၍ DNS server သို့ တောင်းဆိုချက်တစ်ခုပြုလုပ်သည်။
2. တောင်းဆိုချက်သည် ကျွန်ုပ်တို့၏ DNS ဆာဗာသို့ ရောက်ရှိသည်။
3. DNS ဆာဗာသည် ဤကလိုင်းယင့်အတွက် အမြန်ဆန်ဆုံးလမ်းကြောင်းကို သိရှိပြီး သက်ဆိုင်ရာ IP လိပ်စာကို ထုတ်ပေးပါသည်။

ဖြေရှင်းချက်တွင် နောက်ထပ်ရှုပ်ထွေးမှုတစ်ခုရှိသည်- အာဏာရှင် DNS ဝန်ဆောင်မှုပေးသူများသည် သုံးစွဲသူ၏ IP လိပ်စာကို မမြင်ရပြီး ကလိုင်းယင့်အသုံးပြုသည့် recursive ဖြေရှင်းသူ၏ IP လိပ်စာကိုသာ ဖတ်နိုင်သည်။

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

ဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် တူညီသောနမူနာများကို အသုံးပြုကာ၊ ပြန်ကောက်ချက်ချသော ဖြေရှင်းသူများတစ်ခုစီအတွက် ဖောက်သည်များထံမှ တိုင်းတာမှုရလဒ်များကို စုစည်းပြီး ၎င်းတို့ထဲမှ ဤအုပ်စုကို TCP Anycast ကိုအသုံးပြု၍ IX မှတစ်ဆင့် ပရောက်စီတစ်ခု၊ ISP ပရောက်စီတစ်ခုမှတစ်ဆင့် သို့မဟုတ် cloud သို့ တိုက်ရိုက်ပေးပို့ရန် ဆုံးဖြတ်ပါ။

ကျွန်ုပ်တို့သည် အောက်ပါစနစ်အား ရရှိပါသည်။

ရလဒ် DNS steering model သည် client များမှ client များမှ cloud သို့ ချိတ်ဆက်မှုအမြန်နှုန်း၏ သမိုင်းဝင် လေ့လာတွေ့ရှိချက်များကို အခြေခံ၍ client များအား ညွှန်ကြားနိုင်စေပါသည်။

တဖန် မေးစရာမှာ ဤနည်းလမ်းသည် မည်ကဲ့သို့ ထိထိရောက်ရောက် လုပ်ဆောင်နိုင်မည်နည်း။ ဖြေဆိုရန်အတွက် ကျွန်ုပ်တို့၏ စုံစမ်းစစ်ဆေးရေးစနစ်ကို ထပ်မံအသုံးပြုပါသည်။ ထို့ကြောင့်၊ ပစ်မှတ်များထဲမှ တစ်ခုသည် DNS steering မှ ဦးတည်ရာနောက်သို့ လိုက်သွားသော၊ အခြားတစ်ခုသည် cloud (လက်ရှိထုတ်လုပ်မှု) သို့ တိုက်ရိုက်သွားပါသည်။

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

ရလဒ်အနေဖြင့် ကျွန်ုပ်တို့သည် အရေးကြီးသောအရာများစွာကို လေ့လာသင်ယူခဲ့သည်-

1. DNS Steering ကို အသုံးပြု၍ cloud သို့ client များထံမှ တောင်းဆိုမှုများ၏ မျှော်လင့်ထားသော စွမ်းဆောင်ရည်ကို အကဲဖြတ်ပါသည်။
2. ကျွန်ုပ်တို့သည် စက်ပစ္စည်းအမျိုးအစားအားလုံးမှ တကယ့်ဖောက်သည်များထံမှ ဒေတာကို လက်ခံရရှိခဲ့ပါသည်။
3. အဆိုပြုချက်၏ ထိရောက်မှုကို သက်သေပြခဲ့ပြီးဖြစ်သည်။
4. ကျွန်ုပ်တို့သည် စွန့်စားခြင်းမပြုပါ - ဖောက်သည်များအတွက် ထုတ်လုပ်မှုပုံစံများကို မပြောင်းလဲခဲ့ပါ။
5. ဘာမှ ပျက်သွားတယ်။

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

လွယ်ကူသောအပိုင်းသည် ယခု ပြီးသွားပါပြီ - အလုပ်လုပ်ပုံ နမူနာတစ်ခု ရှိပါသည်။ ယခုအခါတွင် ခက်ခဲသောအပိုင်းသည် Netflix ၏ အသွားအလာအားလုံးအတွက် ဖြေရှင်းချက်တစ်ခု စတင်နေပြီး သုံးစွဲသူ သန်း 150၊ စက်ပစ္စည်း ထောင်ပေါင်းများစွာ၊ ရာနှင့်ချီသော microservices နှင့် အမြဲပြောင်းလဲနေသော ထုတ်ကုန်နှင့် အခြေခံအဆောက်အဦများဆီသို့ ဖြန့်ကျက်ချထားပေးပါသည်။ Netflix ဆာဗာများသည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု သန်းပေါင်းများစွာကို လက်ခံရရှိပြီး ဝန်ဆောင်မှုကို ပေါ့ပေါ့ဆဆလုပ်ဆောင်ခြင်းဖြင့် ချိုးဖျက်ရန် လွယ်ကူသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် အင်တာနက်ပေါ်ရှိ ထောင်ပေါင်းများစွာသော CDN ဆာဗာများမှတစ်ဆင့် အသွားအလာကို လမ်းကြောင်းမှန်ပေါ်လွင်စေကာ တစ်စုံတစ်ခု ပြောင်းလဲကာ အဆက်မပြတ် ဖြတ်တောက်သွားကာ အဆက်မပြတ်နှင့် အခန့်မသင့်ဆုံးအချိန်တွင် လမ်းကြောင်းပြောင်းသွားလိုပါသည်။

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

ထို့ကြောင့် အေးချမ်းပြီး ကျန်းမာသော အိပ်စက်ခြင်းအကြောင်း ဆက်လက်ဆွေးနွေးပါမည်။

ပံ့ပိုးမှုတွင် အချိန်မကုန်ဘဲ ဖွံ့ဖြိုးတိုးတက်မှုကို မည်သို့ဆက်လက်လုပ်ဆောင်မည်နည်း။ ကျွန်ုပ်တို့၏ချဉ်းကပ်မှုသည် အခြေခံမူ ၃ ချက်အပေါ် အခြေခံသည်။

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

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

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

1. နမူနာစမ်းသပ်မှု။
2. A/B စမ်းသပ်ခြင်း သို့မဟုတ် ကိန္နရီ။
3. တိုးတက်သော ထုတ်လွှင့်မှု။

နမူနာများဖြင့်၊ ချဉ်းကပ်ပုံကို ဖော်ပြခဲ့ပြီးဖြစ်သည် - အပြောင်းအလဲများကို စိတ်ကြိုက်ချက်ပြုတ်နည်းကို အသုံးပြု၍ ပထမဆုံး စမ်းသပ်သည်။

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

ထို့နောက် Canary ဆာဗာတွင် ပြောင်းလဲမှုများနှင့်အတူ တည်ဆောက်မှုကို ကျွန်ုပ်တို့ ထည့်သွင်းပါ။ ရလဒ်များကို အကဲဖြတ်ရန်၊ ခန့်မှန်းခြေ 100-150 မက်ထရစ်များကို ထိန်းချုပ်မှုဆာဗာများနမူနာနှင့် နှိုင်းယှဉ်သည့်စနစ်တစ်ခုကို လုပ်ဆောင်သည်-

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

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

• ဖောက်သည်များထံမှ - အစည်းအဝေးများနှင့် တောင်းဆိုချက်အရေအတွက်၊ ဆုတ်ယုတ်မှုနှုန်း၊
• ပရောက်စီ - တောင်းဆိုမှုအရေအတွက်နှင့်အချိန်ဆိုင်ရာစာရင်းဇယား၊
• DNS - တောင်းဆိုမှုများ၏နံပါတ်နှင့်ရလဒ်များ;
• cloud edge - cloud ရှိ တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်အတွက် နံပါတ်နှင့် အချိန်။

ဤအရာအားလုံးကို ပိုက်လိုင်းတစ်ခုတည်းသို့ စုစည်းထားပြီး လိုအပ်ချက်များအပေါ်မူတည်၍ အချိန်နှင့်တစ်ပြေးညီ ခွဲခြမ်းစိတ်ဖြာမှုသို့ ပေးပို့ရမည့် မက်ထရစ်များကို ကျွန်ုပ်တို့သည် ပိုမိုအသေးစိတ်စစ်ဆေးရန်အတွက် Elasticsearch သို့မဟုတ် Big Data သို့ ပေးပို့ရန် ဆုံးဖြတ်ပါသည်။

ကျွန်တော်တို့ စောင့်ကြည့်နေပါတယ်။

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

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

ပြဿနာများကို ရှာဖွေပြီး စမ်းသပ်ရန်အတွက် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် open-source real-time system ကို အသုံးပြုပါသည်။ မွေပုံစာအုပျ и Lumen - အမြင်အာရုံအတွက်။ ၎င်းသည် စုစည်းထားသော မက်ထရစ်များကို မှတ်ဉာဏ်တွင် သိမ်းဆည်းထားကာ ယုံကြည်စိတ်ချရပြီး သတိပေးသည့်စနစ်နှင့် ပေါင်းစပ်ထားသည်။ ဒေသန္တရပြုခြင်းနှင့် ရောဂါရှာဖွေခြင်းအတွက်၊ ကျွန်ုပ်တို့သည် Elasticsearch နှင့် Kibana တို့မှ မှတ်တမ်းများကို ဝင်ရောက်ကြည့်ရှုခွင့်ရှိသည်။ စာရင်းအင်းခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် မော်ဒယ်ပြုလုပ်ခြင်းအတွက်၊ ကျွန်ုပ်တို့သည် Tableau တွင် ကြီးမားသောဒေတာနှင့် အမြင်အာရုံကို အသုံးပြုပါသည်။

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

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

• Client Fallback ရာခိုင်နှုန်း - ဖောက်သည်အပြုအမူကို အကဲဖြတ်ခြင်း၊
• ရာခိုင်နှုန်းဖြင့် စစ်ဆေးခြင်းအမှားများ - ကွန်ရက်အစိတ်အပိုင်းများ၏ တည်ငြိမ်မှုဒေတာ။

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

1. ကျွန်ုပ်တို့၏ ပရောက်စီ အလုပ်မလုပ်ပါက ကလိုင်းယင့် တုံ့ပြန်မှု ရှိပါသည်။
2. ပြဿနာများကို တုံ့ပြန်သည့် အလိုအလျောက် စတီယာရင်စနစ်ပါရှိပါသည်။

နောက်ဆုံးအကြောင်းအသေးစိတ်။ ကျွန်ုပ်တို့၏စမ်းသပ်မှုစနစ်နှင့် client မှ cloud သို့တောင်းဆိုမှုများအတွက် အကောင်းဆုံးလမ်းကြောင်းကို အလိုအလျောက်အဆုံးအဖြတ်ပေးသည့်စနစ်သည် အချို့သောပြဿနာများကို အလိုအလျောက်ဖြေရှင်းနိုင်စေပါသည်။

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

ဥပမာ:

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

ထို့ကြောင့် System Support ၏ အခြေခံမူများကို အောက်ပါအတိုင်း ရေးဆွဲနိုင်ပါသည်။

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

သင်ခန်းစာများ

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

ကျွန်ုပ်တို့၏အတွေ့အကြုံအပေါ် အခြေခံ၍ အောက်ပါတို့ကို အကြံပြုနိုင်ပါသည်။

1. မင်းရဲ့ ပင်ကိုယ်ကို မယုံပါနဲ့။

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

2. ထုတ်လုပ်မှုမှဒေတာကိုရယူပါ။

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

3. အခြားသူများ၏ အကြံဉာဏ်နှင့် ရလဒ်များကို မလိုက်နာပါနှင့် - သင့်ကိုယ်ပိုင်ဒေတာကို စုဆောင်းပါ။

   ဒေတာစုဆောင်းခြင်းနှင့် ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် အခြေခံမူများကို လိုက်နာပါ၊ သို့သော် အခြားသူများ၏ ရလဒ်များနှင့် ထုတ်ပြန်ချက်များကို မျက်စိစုံမှိတ် လက်မခံပါနှင့်။ သင့်အသုံးပြုသူများအတွက် အဘယ်အရာ အဆင်ပြေမည်ကို သင်သာလျှင် သိနိုင်သည်။ သင့်စနစ်များနှင့် သင့်ဖောက်သည်များသည် အခြားကုမ္ပဏီများနှင့် သိသိသာသာကွာခြားနိုင်ပါသည်။ ကံကောင်းထောက်မစွာ၊ ခွဲခြမ်းစိတ်ဖြာမှုကိရိယာများကို ယခုရရှိနိုင်ပြီး အသုံးပြုရလွယ်ကူသည်။ သင်ရရှိသောရလဒ်များသည် Netflix၊ Facebook၊ Akamai နှင့် အခြားကုမ္ပဏီများမှ တောင်းဆိုထားသည့်အတိုင်း ဖြစ်နိုင်မည်မဟုတ်ပေ။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ DNS တောင်းဆိုမှုများတွင် TLS၊ HTTP2 သို့မဟုတ် စာရင်းဇယားများ၏ စွမ်းဆောင်ရည်သည် Facebook၊ Uber၊ Akamai ၏ရလဒ်များနှင့် ကွဲပြားသည် - ကျွန်ုပ်တို့တွင် မတူညီသောစက်ပစ္စည်းများ၊ သုံးစွဲသူများနှင့် ဒေတာစီးဆင်းမှုများရှိသောကြောင့်ဖြစ်သည်။

4. ဖက်ရှင်ခေတ်ရေစီးကြောင်းများကို မလိုအပ်ဘဲ မလိုက်နာပါနှင့် ထိရောက်မှုကို အကဲဖြတ်ပါ။

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

5. အပလီကေးရှင်းအသစ်များအတွက် ပြင်ဆင်ပါ။

   ပြဿနာအားလုံးကို ခန့်မှန်းရန် ခက်ခဲသကဲ့သို့ အကျိုးကျေးဇူးများနှင့် အသုံးချမှုများကို ကြိုတင်ခန့်မှန်းရန် ခက်ခဲသည်။ ဖောက်သည်အခြေအနေများနှင့်လိုက်လျောညီထွေဖြစ်အောင်သူတို့၏စွမ်းရည်ကို startups များမှသတိပြုပါ။ သင့်ကိစ္စတွင်၊ ပြဿနာအသစ်များနှင့် ၎င်းတို့၏ဖြေရှင်းချက်များကို သင်ရှာဖွေတွေ့ရှိနိုင်သည်။ ကျွန်ုပ်တို့၏ပရောဂျက်တွင်၊ တောင်းဆိုမှုကြာချိန်ကို လျှော့ချရန် ရည်မှန်းချက်တစ်ခု ချမှတ်ထားသည်။ သို့သော်၊ ခွဲခြမ်းစိတ်ဖြာမှုနှင့် ဆွေးနွေးမှုများအတွင်း၊ ကျွန်ုပ်တို့သည် ပရောက်စီဆာဗာများကိုလည်း အသုံးပြုနိုင်ကြောင်း သိရှိနားလည်ခဲ့သည်-

   • AWS ဒေသများတစ်လျှောက် အသွားအလာ မျှတစေရန်နှင့် ကုန်ကျစရိတ်များကို လျှော့ချရန်၊
   • CDN တည်ငြိမ်မှုပုံစံအတွက်၊
   • DNS ကို configure လုပ်ရန်;
   • TLS/TCP ကို ​​စီစဉ်သတ်မှတ်ရန်။

ကောက်ချက်

အစီရင်ခံစာတွင်၊ ဖောက်သည်များနှင့် cloud အကြား အင်တာနက်တောင်းဆိုမှုများကို အရှိန်မြှင့်သည့်ပြဿနာကို Netflix က မည်သို့ဖြေရှင်းကြောင်း ဖော်ပြထားပါသည်။ ကျွန်ုပ်တို့သည် သုံးစွဲသူများထံ နမူနာယူသည့်စနစ်ဖြင့် ဒေတာစုဆောင်းပုံ၊ အင်တာနက်ပေါ်ရှိ အမြန်ဆုံးလမ်းကြောင်းမှတစ်ဆင့် သုံးစွဲသူများထံမှ ထုတ်လုပ်မှုတောင်းဆိုမှုများကို လမ်းကြောင်းပေးရန်အတွက် စုဆောင်းထားသော သမိုင်းအချက်အလက်ကို အသုံးပြုပါ။ ဤလုပ်ငန်းကိုအောင်မြင်ရန် ကွန်ရက်ပရိုတိုကောများ၊ ကျွန်ုပ်တို့၏ CDN အခြေခံအဆောက်အအုံ၊ ကျောရိုးကွန်ရက်နှင့် DNS ဆာဗာများ၏ အခြေခံမူများကို ကျွန်ုပ်တို့အသုံးပြုပုံ။

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

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

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

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

ဒီနှစ်မှာတော့ ညီလာခံကို ဇူလိုင် ၆ ရက်မှ ၁၀ ရက်အထိ ကျင်းပမည်ဖြစ်သည်။ အွန်လိုင်းပုံစံ။ DevOps ၏ဖခင်များထဲမှတစ်ဦးဖြစ်သော John Willis ကိုယ်တိုင်မေးခွန်းများမေးနိုင်သည်။

source: www.habr.com