Cloud computing explained: the 11 architecture concepts you must know (4K Masterclass).

ဤဗီဒီယိုတွင် ဖော်ပြထားသောအရာများ

• - ဗိသုကာနံရံနှင့် မာစတာပုံစံ
• - 01. ဒေါင်လိုက်နှင့် အလျားလိုက် အရွယ်အစား
• - 02. Load Balancing Architecture (L4 vs. L7 & Health Checks)
• - 03. Autoscaling နှင့် Elasticity
• - 04. Serverless (FaaS & Firecracker MicroVMs)

ဘာသာပြန်ထားသော စာသားမှတ်တမ်း

မူရင်း အင်္ဂလိပ်စကားပြောမှ ဘာသာပြန်ထားသည်။ ရရှိနိုင်သော အသံနှင့် စာတန်းထိုးများကို YouTube မှ ထိန်းချုပ်ထားသည်။

- ဗိသုကာနံရံနှင့် မာစတာပုံစံ

0:00 ဆော့ဖ်ဝဲအင်ဂျင်နီယာတိုင်းသည် နောက်ဆုံးတွင် cloud ဗိသုကာနံရံကို ရင်ဆိုင်ရမည်ဖြစ်သည်။ သင်သည် သင်၏ laptop တွင် application တစ်ခုတည်ဆောက်ပြီး ထုတ်လုပ်မှုသို့ပို့ဆောင်ပါက၊ အသုံးပြုသူအစစ်အမှန်များရောက်ရှိလာသည်နှင့်တစ်ပြိုင်နက် ဆာဗာများ ပျက်ကျပြီး၊ ဒေတာဘေ့စ်ချိတ်ဆက်မှုများ ပြည့်လျှံလာကာ သင်၏ AWS ဘေလ်သည် ဖုန်းနံပါတ်တစ်ခုကဲ့သို့ ဖြစ်လာသည်။ developer အများစုသည် မတူညီသော AWS ထုတ်ကုန်အတိုကောက်သုံးရာကို မှတ်သားခြင်းဖြင့် cloud engineering ကို ဖြေရှင်းရန် ကြိုးစားကြသည်။ သို့သော် cloud computing အစစ်အမှန်သည် vendor catalog များကို မှတ်သားခြင်းမဟုတ်ဘဲ၊ အခြေခံဗိသုကာမူလတန်း ဆယ့်တစ်ခုအပေါ်တွင် တည်ဆောက်ထားသည်။

0:34 ဤ masterclass တွင် ကျွန်ုပ်တို့သည် လုပ်ငန်းအပြည့်အစုံကို လေ့လာပါမည်။ ၎င်းတို့မှာ scaling နှင့် load balancing မှ serverless, event-driven decoupling, storage hierarchies နှင့် cloud networking တို့ဖြစ်သည်။ ဤအယူအဆ ဆယ့်တစ်ခုကို တတ်မြောက်ပါက AWS, GCP သို့မဟုတ် Azure တွင် မည်သည့် backend ကိုမဆို ဒီဇိုင်းဆွဲနိုင်သည်။ GCP, or Azure. ဤသည်မှာ The Daily Diff, under the hood ဖြစ်သည်။

- 01. ဒေါင်လိုက်နှင့် အလျားလိုက် အရွယ်အစား

0:57 နံပါတ်တစ် အယူအဆ- Scaling။ သင်၏ application သည် traffic တိုးတက်မှုကို ကြုံတွေ့ရသောအခါ၊ load ကို ကိုင်တွယ်ရန် မူလအားဖြင့် မတူညီသောနည်းလမ်း နှစ်ခုရှိသည်။ ၎င်းတို့မှာ vertical scaling သို့မဟုတ် horizontal scaling တို့ဖြစ်သည်။ Vertical scaling သို့မဟုတ် scaling up ဆိုသည်မှာ သင်၏ရှိရင်းစွဲ machine ကိုယူ၍ ပိုမိုများပြားသော resource များကို ထည့်သွင်းခြင်းဖြစ်သည်။ ဥပမာ- CPU cores လေးခုမှ သုံးဆယ့်နှစ်ခုသို့ အဆင့်မြှင့်ခြင်း သို့မဟုတ် RAM သုံးဆယ့်နှစ် gigabytes ကို တစ်ရာ့နှစ်ဆယ့်ရှစ်ခုသို့ ပြောင်းလဲခြင်းတို့ဖြစ်သည်။ တစ်ရာ့နှစ်ဆယ့်ရှစ်။ Vertical scaling သည် ဗိသုကာဆိုင်ရာ ပြောင်းလဲမှု လုံးဝမလိုအပ်ပါ။ သင်၏ code နှင့် database သည် အတူတူပင်ဖြစ်နေပါသည်။

1:28 နှင့်ဒေတာဘေ့စ်သည် အတူတူပင်ဖြစ်နေသည်။ သို့သော် ၎င်းသည် ကြမ်းတမ်းသော hardware ကန့်သတ်ချက်ကို ထိမှန်သည်။ ကမ္ဘာပေါ်ရှိ မည်သည့် machine တစ်ခုမျှ CPU cores တစ်သောင်း မရှိပါ။ ထိပ်တန်း instance များသည် အဆပေါင်းများစွာ စျေးနှုန်းကြီးမြင့်သည်။ Horizontal scaling သို့မဟုတ် scaling out ဆိုသည်မှာ သင်၏ဆာဗာများကို သေးငယ်ပြီး ကုန်ကျစရိတ်နည်းစွာ ထိန်းသိမ်းထားခြင်းဖြစ်ပြီး router နောက်တွင် instance အများအပြားကို တစ်ပြိုင်နက်တည်း အပြိုင်လည်ပတ်စေခြင်းဖြစ်သည်။ instance တစ်ခုပျက်ကျပါက ကျန် nodes များသည် traffic ကို zero downtime ဖြင့် စုပ်ယူသည်။ zero downtime. Horizontal scaling ၏ ရွှေစည်းမျဉ်းမှာ

2:01 statelessness ဖြစ်သည်။ သင်၏ application server များသည် user session များ၊ upload လုပ်ထားသော files များ သို့မဟုတ် state များကို ၎င်းတို့၏ local disks တွင် သိမ်းဆည်း၍မရပါ။ State သည် ပြင်ပ database သို့မဟုတ် cache တွင်ရှိရမည်ဖြစ်ပြီး၊ မည်သည့် node ကိုမဆို user request တစ်ခုခုကို ကိုင်တွယ်ခွင့်ပြုသည်။

- 02. Load Balancing Architecture (L4 vs. L7 & Health Checks)

2:17 နံပါတ်နှစ် အယူအဆ- Load Balancing။ Horizontal scaling သည် စာရွက်ပေါ်တွင် ကောင်းမွန်သော်လည်း ချက်ချင်းပြဿနာတစ်ခု ဖြစ်ပေါ်စေသည်။ အသုံးပြုသူတစ်သောင်းသည် သင်၏ domain name ကို ဝင်ရောက်ကြည့်ရှုသောအခါ၊ မည်သည့်ဆာဗာသည် ၎င်းတို့၏ traffic ကို လက်ခံရရှိမည်နည်း။ load balancer သည် public internet နှင့် သင်၏ private backend cluster ကြားတွင် reverse proxy အဖြစ် ဆောင်ရွက်သည်။ ၎င်းသည် ဝင်လာသော TCP သို့မဟုတ် HTTP ချိတ်ဆက်မှုများကို လက်ခံပြီး သင်၏ ကျန်းမာသော instance များတစ်လျှောက် request များကို ဖြန့်ဝေပေးသည်။

2:47 load balancer များသည် အဓိက network layers နှစ်ခုတွင် လုပ်ဆောင်သည်။ Layer 4 Network Load Balancer များသည် transport layer တွင် လုပ်ဆောင်ပြီး၊ IP address နှင့် port ကိုအခြေခံ၍ raw TCP နှင့် UDP packets များကို လမ်းကြောင်းပြောင်းပေးသည်။ microsecond latency နှင့် တစ်စက္ကန့်လျှင် request သန်းပေါင်းများစွာဖြင့်ဖြစ်သည်။ Layer 7 Application Load Balancer များသည် HTTP protocol ကိုယ်တိုင်ကို စစ်ဆေးသည်။ URL paths, request headers, cookies နှင့် HTTP methods များကို ဖတ်သည်။ ၎င်းသည် path-based routing ကို လုပ်ဆောင်နိုင်သည်။ slash-api request များကို သင်၏ backend cluster သို့ပို့ပြီး slash-static request များကို object store သို့ပို့သည်။ အရေးကြီးသည်မှာ load balancer များသည် active health

3:25 စစ်ဆေးမှုများ ပြုလုပ်သည်။ စက္ကန့်အနည်းငယ်တိုင်းတွင် balancer သည် instance တိုင်းရှိ health endpoint ကို ping လုပ်သည်။ instance တစ်ခုသည် ဆက်တိုက်ငါးရာ error သုံးခုကို ထုတ်ပြန်ပါက သို့မဟုတ် တုံ့ပြန်ရန် ပျက်ကွက်ပါက ၎င်းကို pool မှ အလိုအလျောက်ဖယ်ရှားပစ်သည်။ zero dropped request ဖြင့်ဖြစ်သည်။ zero dropped requests.

- 03. Autoscaling နှင့် Elasticity

3:45 နံပါတ်သုံး အယူအဆ- Autoscaling။ သင်၏ web app သည် နံနက်သုံးနာရီတွင် server နှစ်ခုလိုအပ်သော်လည်း၊ နေ့လည်စတင်ချိန်တွင် server နှစ်ဆယ်လိုအပ်ပါက cloud console တွင် ခလုတ်များကို ကိုယ်တိုင်နှိပ်ခြင်းသည် downtime နှင့် ဒေဝါလီခံခြင်းသို့ ဦးတည်သွားမည်ဖြစ်သည်။ cloud console သည် downtime နှင့် ဒေဝါလီခံခြင်းသို့ ဦးတည်သွားမည်ဖြစ်သည်။ Autoscaling သည် horizontal server pool များသို့ dynamic elasticity ကို ဆောင်ကြဉ်းပေးသည်။ Auto Scaling Group သည် ပျမ်းမျှ CPU အသုံးပြုမှု၊ network I-O သို့မဟုတ် queue backlog ကဲ့သို့သော စွမ်းဆောင်ရည်စံနှုန်းများကို စောင့်ကြည့်သည်။ အတိမ်အနက်။ ပျမ်းမျှ CPU သည် သတ်မှတ်ထားသော ကန့်သတ်ချက်ကို ကျော်လွန်သောအခါ — ဥပမာ၊ ပျမ်းမျှ CPU သည် သတ်မှတ်ထားသော ကန့်သတ်ချက်ကို ကျော်လွန်သောအခါ — ဥပမာ၊

4:19 ဆက်တိုက်သုံးမိနစ်အတွက် ရာခိုင်နှုန်းခုနစ်ဆယ် — autoscaler သည် အလိုအလျောက် virtual machines အသစ်များကို စတင်ပြီး ၎င်းတို့ကို သင်၏ load balancer ဖြင့် မှတ်ပုံတင်ကာ traffic ကို စတင်လမ်းကြောင်းပြောင်းပေးသည်။ နှင့် traffic ကို စတင်လမ်းကြောင်းပြောင်းပေးသည်။ အလားတူပင် scaling in သည် အရေးကြီးသည်။ traffic wave လျော့နည်းသွားသောအခါ၊ autoscaler သည် ပိုလျှံနေသော instance များကို အဆုံးသတ်သဖြင့် သင်သည် idle compute အတွက် ပေးဆောင်ခြင်းကို ရပ်ဆိုင်းသည်။ flapping ကို ကာကွယ်ရန် — ဆာဗာများကို လျင်မြန်စွာ ဖန်တီးပြီး အဆုံးမရှိ လည်ပတ်နေသော loop တွင် ဖျက်ဆီးခြင်း — cloud architect များသည် cooldown ကာလများကို သတ်မှတ်သည်။ နံပါတ်လေး အယူအဆ- Serverless။

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 နှစ်ပေါင်းများစွာ marketing အဖွဲ့များသည် serverless ကို ကောင်းကင်ယံတွင် လည်ပတ်နေသော မှော်ဆန်သော code အဖြစ် တင်ပြခဲ့ကြသည်။ ကောင်းကင်ယံတွင် လည်ပတ်နေသော မှော်ဆန်သော code။ လက်တွေ့တွင် serverless သည် server များကို အသုံးပြုနေဆဲဖြစ်သည်။ သို့သော် သင်သည် ၎င်းတို့ကို ပိုင်ဆိုင်ခြင်း၊ patch လုပ်ခြင်း သို့မဟုတ် code မလည်ပတ်သည့်အခါ ပေးဆောင်ခြင်း မရှိပါ။ AWS Lambda သို့မဟုတ် Google Cloud Functions ကဲ့သို့ Function-as-a-Service ဖြင့်၊ သင်သည် standalone handler function တစ်ခုကို ရေးသားသည်။ HTTP request, S3 file upload သို့မဟုတ် database ပြောင်းလဲမှုတစ်ခု ဖြစ်ပေါ်သောအခါ cloud runtime သည် ephemeral micro-virtual-machine တစ်ခုကို

5:23 Firecracker ကဲ့သို့ ငါး millisecond အောက်တွင် စတင်သည်။ သင်၏ code သည် execute လုပ်ပြီး တုံ့ပြန်မှုတစ်ခုကို ပြန်ပေးကာ ပိတ်သွားသည်။ မည်သူမျှ သင်၏ website ကို သုံးလကြာ မကြည့်ရှုပါက သင်၏ compute bill သည် တစ်ပြားဝတ်ရူပံ ၅၀ ပြည့်ဝသော ဘေလ်ဖြစ်သည်။ အသုံးပြုသူတစ်သန်းသည် တစ်ပြိုင်နက်တည်း ဝင်ရောက်ကြည့်ရှုပါက provider သည် concurrent microVMs တစ်သန်းကို စတင်သည်။ engineering trade-offs များသည် အစစ်အမှန်ဖြစ်သည်။ fresh runtime များ စတင်သည့်အခါ cold start latency, Lambda တွင် hard limit ၁၅ မိနစ် နှင့် တင်းကျပ်သော statelessness။

5:55 Serverless သည် event pipeline များနှင့် sporadic API များအတွက် အကောင်းဆုံးဖြစ်သော်လည်း၊ persistent WebSockets သို့မဟုတ် နာရီပေါင်းများစွာကြာသော training run များအတွက် မကောင်းပါ။

- 05. Event-Driven Architecture (EDA & Decoupling)

6:05 နံပါတ်ငါး အယူအဆ- Event-Driven Architecture သို့မဟုတ် EDA။ ရိုးရာဗိသုကာပညာများတွင် ဝန်ဆောင်မှုများသည် synchronous ဖြစ်သည်။ သင်၏ checkout service သည် payment ကို ခေါ်သည်။ payment သည် inventory ကို ခေါ်သည်။ inventory သည် fraud ကို ခေါ်သည်။ fraud သည် email ကို ခေါ်သည်။ ၎င်းသည် synchronous cascade of doom ကို ဖန်တီးသည်။ third-party email provider သည် network ပြဿနာတစ်ခု ကြုံတွေ့ရပြီး တုံ့ပြန်ရန် ဆယ်စက္ကန့်ကြာပါက၊ သင်၏ customer ၏ checkout request အပြည့်အစုံသည် error ဖြင့် timeout ဖြစ်သွားသည်။ event-driven architecture တွင် ဝန်ဆောင်မှုများသည် လုံးဝ decoupling ဖြစ်သည်။

6:37 customer တစ်ဦး ဝယ်ယူမည်ကို နှိပ်လိုက်သောအခါ checkout service သည် downstream service များကို မခေါ်ပါ။ ၎င်းသည် OrderPlaced ဟုခေါ်သော event တစ်ခုကို ဗဟို Event Bus သို့ Amazon EventBridge သို့မဟုတ် SNS topic သို့သာ ထုတ်ပြန်သည်။ Event Bus ကဲ့သို့ Amazon EventBridge သို့မဟုတ် SNS topic သို့သာ ထုတ်ပြန်သည်။ checkout သည် millisecond ငါးဆယ်အတွင်း ပြီးစီးသည်။ payment, inventory deduction နှင့် email receipts အတွက် downstream worker များသည် ၎င်းတို့၏ကိုယ်ပိုင် dedicated SQS queue များမှ message များကို လွတ်လပ်စွာ ဆွဲထုတ်သည်။ email service သည် တစ်နာရီကြာ ပျက်သွားပါက message များသည် queue တွင် တစ်ဦးတည်းသော dropped order မရှိဘဲ လုံခြုံစွာ စောင့်ဆိုင်းနေသည်။

- 06. Container Orchestration (Docker & Kubernetes)

7:13 နံပါတ်ခြောက် အယူအဆ- Container Orchestration။ Docker သည် packaging ကို ဖြေရှင်းပေးသည်။ ၎င်းသည် သင်၏ application code, system libraries, configuration နှင့် runtime ကို immutable image တစ်ခုအဖြစ် ထုပ်ပိုးပေးသည်။ ၎င်းသည် သင်၏ MacBook နှင့် cloud တွင် တူညီစွာ လည်ပတ်သည်။ သို့သော် container တစ်ခုကို ထုပ်ပိုးခြင်းသည် လွယ်ကူသည်။ physical virtual machine ငါးဆယ်တစ်လျှောက် container ငါးရာကို လည်ပတ်ခြင်းသည် engineering ပျက်စီးသွားသည့်နေရာဖြစ်သည်။ ထို့ကြောင့် Kubernetes နှင့် AWS ECS ကဲ့သို့သော container orchestrator များရှိနေသည်။

7:41 orchestrator သည် control plane တစ်ခုကို ပေးသည်။ ၎င်းမှာ API server, etcd state store နှင့် intelligent scheduler တို့ဖြစ်သည်။ an etcd state store, and an intelligent scheduler. သင်၏ လိုချင်သော state ကို ကြေညာသည်။ ကျွန်ုပ်သည် auth service ၏ replicas ဆယ်ခုကို လိုချင်ပြီး တစ်ခုချင်းစီတွင် RAM နှစ် gigabytes ရှိသည်။ scheduler သည် cluster ကို စစ်ဆေးပြီး free memory ရှိသော node များပေါ်တွင် pods များကို နေရာချသည်။ internal networking ကို သတ်မှတ်ပြီး လက်တွေ့ကို ဆက်လက် ချိန်ညှိသည်။ node တစ်ခု hardware ပျက်စီးမှု ကြုံတွေ့ရပါက Kubernetes သည် ထိုဆုံးရှုံးမှုကို ဆုံးရှုံးမှုကို သိရှိပြီး ပြောင်းရွှေ့ထားသော pods အားလုံးကို

- 07. Cloud Storage ၏ တိုင်ကြီး ၄ တိုင် (S3, EBS, DBs & Redis)

8:16 ကျန်းမာသော node များပေါ်သို့ ချက်ချင်း ပြန်လည် စီစဉ်ပေးသည်။ နံပါတ်ခုနစ် အယူအဆ- Cloud Storage Hierarchy။ စတင်သူများသည် cloud storage ကို files များကို ပစ်ထည့်သည့် single bucket တစ်ခုအဖြစ် မကြာခဏ မှတ်ယူကြသည်။ ထုတ်လုပ်မှုဗိသုကာပညာတွင် storage ကို access patterns နှင့် latency ကို အခြေခံ၍ မတူညီသော တိုင်ကြီးလေးခုအဖြစ် ပိုင်းခြားထားသည်။ ပထမဆုံးမှာ Object Storage ဖြစ်သည်။ Amazon S3 သို့မဟုတ် Google Cloud Storage ကဲ့သို့ဖြစ်သည်။ သင်သည် HTTP REST API များမှတစ်ဆင့် files များကို ရယူသည်။ ရိုးရှင်းသော PUT နှင့် GET call များ အသုံးပြု၍ဖြစ်သည်။ ၎င်းသည် တစ်လလျှင် တစ် gigabyte လျှင် နှစ်ဆင့်နှုန်းဖြင့် အဆုံးမရှိသော horizontal capacity ကို ပေးသည်။

8:49 ၎င်းသည် video, user uploads, logs နှင့် backups များအတွက် အကောင်းဆုံးဖြစ်သည်။ ဒုတိယမှာ Block Storage ဖြစ်သည်။ Amazon EBS ကဲ့သို့ဖြစ်သည်။ ဤအရာများသည် မြန်နှုန်းမြင့် ချိတ်ဆက်မှုများမှတစ်ဆင့် သီးခြား virtual machine တစ်ခုသို့ တိုက်ရိုက်ချိတ်ဆက်ထားသော virtual hard drive များဖြစ်သည်။ မြန်နှုန်းမြင့် ချိတ်ဆက်မှုများမှတစ်ဆင့်ဖြစ်သည်။ ၎င်းတို့သည် ext4 ကဲ့သို့သော standard filesystem များအဖြစ် format လုပ်ပြီး၊ database engine များလိုအပ်သော မြန်ဆန်သော random read နှင့် write access ကို ပံ့ပိုးသည်။ တတိယမှာ Managed Databases ဖြစ်သည်။ RDS ပေါ်ရှိ PostgreSQL ကဲ့သို့သော relational engine များသည် ACID transaction များနှင့် complex join များကို ပေးသည်။ DynamoDB ကဲ့သို့သော NoSQL engine များသည်

9:21 single-digit millisecond latency ကို အကြီးအကျယ် ပေးသည်။ အကြီးအကျယ် ပေးသည်။ စတုတ္ထမှာ Redis ကဲ့သို့ In-Memory Caches များဖြစ်သည်။ RAM မှ data ကို ဖတ်ခြင်းသည် millisecond အစား microsecond များကြာသည်။ caches များသည် သင်၏ database ရှေ့တွင်ရှိပြီး ၎င်းကို ထပ်ခါတလဲလဲ read traffic မှ ကာကွယ်သည်။ အသုံးပြုသူ session token များကို စီမံခန့်ခွဲသည်။

- 08. High Availability နှင့် The Nines (Multi-AZ Failover)

9:44 နံပါတ်ရှစ် အယူအဆ- High Availability သို့မဟုတ် HA။ Availability သည် မေးခွန်းတစ်ခုကို ဖြေသည်။ သင်၏ application သည် မည်သည့်အချိန်ရာခိုင်နှုန်းတွင် လည်ပတ်နေပြီး အသုံးပြုသူများထံသို့ ရောက်ရှိနိုင်သနည်း။ လုပ်ငန်းသုံးစာချုပ်များတွင် availability ကို nines ဖြင့် တိုင်းတာသည်။ nines နှစ်ခု သို့မဟုတ် ၉၉ ရာခိုင်နှုန်း availability သည် တစ်နှစ်လျှင် သုံးရက်ခွဲကျော် downtime ကို ခွင့်ပြုသည်။ တစ်နှစ်လျှင် သုံးရက်ခွဲကျော် downtime ကို ခွင့်ပြုသည်။ nines လေးခုသည် ခွင့်ပြုထားသော downtime ကို ငါးဆယ့်နှစ်မိနစ်သို့ လျှော့ချပြီး၊ nines ငါးခုသည် တစ်နှစ်လျှင် စုစုပေါင်း downtime ငါးမိနစ်ခန့်သာ ခွင့်ပြုသည်။

10:15 High availability ရရှိရန်အတွက် fault domain များတစ်လျှောက် ပျက်စီးမှုဖြစ်စေနိုင်သော အချက်များကို ဖယ်ရှားရမည်။ cloud တွင် ၎င်းသည် Availability Zone များစွာတွင် deployment လုပ်ခြင်းကို ဆိုလိုသည်။ Availability Zone သည် rack တစ်ခုတည်းမဟုတ်ဘဲ၊ သီးခြား physical data center တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုပြီး မိုင်ပေါင်းများစွာကွာဝေးကာ သီးခြား power နှင့် cooling ရှိသည်။ Zone A နှင့် Zone B တွင် active instance များကို synchronous database replication ဖြင့် လည်ပတ်ခြင်းဖြင့်၊ လျှပ်စီးလက်ခြင်း သို့မဟုတ် fiber ပြတ်တောက်ခြင်းကြောင့် physical facility တစ်ခုလုံး ပျက်စီးသွားပါက အလိုအလျောက် failover ဖြစ်ပေါ်စေသည်။

10:50 စက္ကန့်သုံးဆယ်အတွင်း လူသားများ၏ ဝင်ရောက်စွက်ဖက်မှုမရှိဘဲ။

- 09. Durability vs. Availability (အဘယ်ကြောင့် 11 Nines သည် Uptime မဟုတ်သနည်း)

10:53 နံပါတ် ၉ အယူအဆ- တာရှည်ခံမှုနှင့် ရရှိနိုင်မှု။ ၎င်းသည် cloud ဗိသုကာပညာ၏ အင်တာဗျူးများတွင် အတွေ့ရများဆုံး သဘောတရားဆိုင်ရာ ထောင်ချောက်ဖြစ်သည်။ အင်ဂျင်နီယာများသည် စကားလုံးများကို မကြာခဏ အပြန်အလှန် အသုံးပြုကြသော်လည်း၊ ၎င်းတို့သည် လုံးဝကွဲပြားခြားနားသော ဂုဏ်သတ္တိများကို တိုင်းတာကြသည်။ ရရှိနိုင်မှုသည် uptime ကို တိုင်းတာသည်- ကျွန်ုပ်၏ဒေတာကို ယခုချက်ချင်းဖတ်ရန် သို့မဟုတ် ရေးရန် API ခေါ်ဆိုမှု ပြုလုပ်နိုင်ပါသလား။ ဒေတာကို ဤအတိုင်းပဲထားရမလား။ တာရှည်ခံမှုသည် ထိန်းသိမ်းမှုကို တိုင်းတာသည်- ကျွန်ုပ်၏ဒေတာသည် ၁၀ နှစ်အတွင်း အမြဲတမ်း bit rot၊ ပျက်စီးခြင်း သို့မဟုတ် ဖျက်ဆီးခြင်းမရှိဘဲ ကျန်ရှိနေမည်လား။ ဆယ်နှစ်ကျော် ဖျက်ဆီးခံရမှာလား။

11:24 Amazon S3 Standard ကို ကြည့်ပါ။ ၎င်း၏ ဝန်ဆောင်မှုအဆင့် သဘောတူညီချက်သည် ၉၉.၉ ရာခိုင်နှုန်း ရရှိနိုင်မှုကို ပေးပါသည်။ ၎င်းသည် လစဉ် မိနစ် ၄၃ ခန့် downtime ကို ခွင့်ပြုထားပြီး API တောင်းဆိုမှုသည် ၅၀၀ error ကို ပြန်လည်ပေးပို့နိုင်ပါသည်။ API တောင်းဆိုမှုသည် ၅၀၀ error ကို ပြန်လည်ပေးပို့နိုင်သည်။ သို့သော် S3 သည် ခိုင်ခံ့မှု ၁၁ ခုကို ကတိပြုသည်- ၉၉ ဒသမ ၉၉၉၉၉၉၉ ၉၉ ရာခိုင်နှုန်း။ သင် S3 တွင် ဖိုင်ပေါင်း ၁၀ သန်းကို သိမ်းဆည်းထားပါက နှစ်တစ်သောင်းလျှင် ဖိုင်တစ်ဖိုင် ဆုံးရှုံးမည်ဟု စာရင်းအင်းအရ မျှော်မှန်းနိုင်သည်။

11:56 ဆယ်နှစ်တစ်သောင်းတိုင်း ပျမ်းမျှဖိုင်တစ်ဖိုင် ဆုံးရှုံးနိုင်သည်ဟု ခန့်မှန်းရသည်။ S3 သည် အရာဝတ္ထုများကို erasure-coding ပြုလုပ်ပြီး အနည်းဆုံး ပထဝီဝင်အရ ကွဲပြားသော ဒေတာစက်ရုံသုံးခုတွင် အပိုင်းအစများကို ပုံတူကူးခြင်းဖြင့် ၎င်းကို အောင်မြင်စေသည်။ အနည်းဆုံး ပထဝီဝင်အရ ခွဲခြားထားသော ဒေတာစက်ရုံသုံးခုတွင် အပိုင်းအစများကို ပုံတူကူးခြင်းဖြင့် အောင်မြင်စေသည်။ ဒေသတွင်း ကွန်ရက်ပြတ်တောက်မှုကြီးတစ်ခု ဖြစ်ပွားနေစဉ်တွင် S3 သည် ယာယီအားဖြင့် ရရှိနိုင်မည်မဟုတ်သော်လည်း သင့်ဒေတာကို မည်သည့်အခါမျှ ဖျက်ဆီးမည်မဟုတ်ပါ။ ရရှိနိုင်မည် မဟုတ်သော်လည်း သင့်ဒေတာသည် လုံးဝပျက်စီးမည်မဟုတ်ပါ။

- 10. Infrastructure as Code (Terraform vs. Console Drift)

12:14 နံပါတ်ဆယ် အယူအဆ- Infrastructure as Code, သို့မဟုတ် IaC။ cloud computing ၏ အစောပိုင်းကာလများတွင် အင်ဂျင်နီယာများသည် AWS web management console သို့ လော့ဂ်အင်ဝင်ပြီး manual ဖြင့် click လုပ်၍ virtual machines များ ဖန်တီးခဲ့ကြသည်။ web management console သို့ လော့ဂ်အင်ဝင်ပြီး manual ဖြင့် click လုပ်၍ virtual စက်များဖန်တီးခြင်း၊ subnet များပြုပြင်ခြင်းနှင့် လုံခြုံရေးအဖွဲ့များကို ချိတ်ဆက်ခြင်း။ စက်မှုလုပ်ငန်းက ၎င်းကို ClickOps ဟု ခေါ်ပြီး ထုတ်လုပ်မှုတွင် ၎င်းသည် လုံးဝ ဘေးအန္တရာယ်တစ်ခုဖြစ်သည်။ လက်စွဲ console ပြောင်းလဲမှုများတွင် စစ်ဆေးမှတ်တမ်းမရှိပါ၊ ပြန်လှန်မယ့် နည်းလမ်းမရှိပါ၊ ထုတ်လုပ်မှုပတ်ဝန်းကျင်များနှင့် စင်မြင့်များကြား ဖွဲ့စည်းပုံမကိုက်ညီမှုကို မလွဲမသွေ ဖြစ်စေသည်။ Infrastructure as Code ကိရိယာများဖြစ်သော Terraform, ထုတ်လုပ်မှုပတ်ဝန်းကျင်။ Infrastructure

12:48 Terraform ကဲ့သို့သော Code ကိရိယာများအနေဖြင့်၊ OpenTofu, Pulumi သို့မဟုတ် AWS CDK ကို အသုံးပြု၍ Git တွင် သိမ်းဆည်းထားသော declarative configuration files တွင် သင်၏ cloud architecture တစ်ခုလုံးကို သတ်မှတ်နိုင်သည်။ Git တွင် သိမ်းဆည်းထားသော ကြေညာချက် configuration files များတွင် သင်၏ cloud architecture တစ်ခုလုံးကို သတ်မှတ်နိုင်သည်။ ဖွင့်ထားသော ပို့တ်တစ်ခု သို့မဟုတ် ဒေတာဘေ့စ် ပုံတူတစ်ခုသို့ ပြောင်းလဲမှုတိုင်းသည် pull request နှင့် peer review မှတဆင့် ပြုလုပ်သည်။ ဆွဲတင်ခြင်း တောင်းဆိုမှုနှင့် တူညီသူများ၏ သုံးသပ်ချက်။ terraform plan ကို run ခြင်းသည် မည်သည့်အရာကိုမျှ မထိမီ တိကျသော API diff ကို ကြိုတင်ကြည့်ရှုပြီး သင်၏ ထုတ်လုပ်မှု stack ၏ တူညီသော ပုံတူကို တည်ဆောက်ခြင်းသည် လေးပတ်အစား လေးမိနစ်သာ ကြာသည်။ မည်သည့်အရာကိုမျှ မထိမီ တိကျသော API diff ကို ကြိုတင်ကြည့်ရှုပြီး သင်၏ထုတ်လုပ်မှု၏ တူညီသောပုံစံကို တည်ဆောက်ခြင်း။ stack သည် လေးပတ်အစား လေးမိနစ်ကြာသည်။

- 11. Cloud Networking (VPC, Subnets, NAT & Security Groups)

13:20 နံပါတ် ၁၁ အယူအဆ- Cloud Networking နှင့် Virtual Private Clouds။ သင် server များကို cloud သို့ deployment လုပ်သောအခါ ၎င်းတို့သည် raw public internet ပေါ်တွင် ပေါ်လွင်စွာ မတည်ရှိပါ။ ၎င်းတို့သည် VPC ဟုခေါ်သော software-defined isolated boundary အတွင်းတွင် ရှိနေပါသည်။ VPC ဟုခေါ်သော VPC တစ်ခု။ သင်၏ VPC အတွင်းတွင် သင်သည် private IP address space ကို ခွဲဝေပေးပါသည်။ ၁၀.၀.၀.၀/၁၆ ကဲ့သို့သော IP လိပ်စာနေရာကို ခွဲဝေပေးပြီး ၎င်းကို public နှင့် private subnets အဖြစ် ပိုင်းခြားထားသည်။ public နှင့် private subnets များအဖြစ် ပိုင်းခြားထားသည်။ public subnet တစ်ခုတွင် Internet Gateway သို့ တိုက်ရိုက်လမ်းကြောင်းရှိသည်။

13:51 ၎င်းတွင် သင်၏ Application Load Balancers နှင့် NAT Gateways ကဲ့သို့သော public-facing assets များပါရှိသည်။ Gateways များ။ ၎င်းသည် public IP လိပ်စာများ ပိုင်ဆိုင်သည့် သင့်ကွန်ရက်၏ တစ်ခုတည်းသော အစိတ်အပိုင်းဖြစ်သည်။ လိပ်စာများ။ သင်၏ application server များနှင့် ထုတ်လုပ်မှု database များသည် public IP မရှိသော private subnets များတွင်သာ ရှိနေသည်။ အင်တာနက်မှ ဝင်ရောက်လာသော လမ်းကြောင်းများ မရှိပါ။ သင်၏ backend server များသည် လုံခြုံရေး အပ်ဒိတ်များ ဒေါင်းလုဒ်လုပ်ရန် လိုအပ်သောအခါ၊ အင်တာနက်။ သင်၏ backend server များသည် လုံခြုံရေး အပ်ဒိတ်များ ဒေါင်းလုဒ်လုပ်ရန် လိုအပ်သောအခါ၊ ၎င်းတို့၏ အပြင်ဘက်သို့ ထွက်သော traffic လမ်းကြောင်းများသည် public subnet ရှိ NAT Gateway မှတဆင့် ဖြစ်သည်။ subnet ။ instance တိုင်းကို ဝန်းရံထားသော Security Groups များ- stateful virtual firewalls များဖြစ်ပြီး အနည်းဆုံး အခွင့်ထူးခံ နိယာမကို အကောင်အထည်ဖော်သည်။ virtual firewalls များသည် အနည်းဆုံး အခွင့်ထူးခံ နိယာမကို အကောင်အထည်ဖော်သည်။

- 12. စီးပွားရေးလုပ်ငန်းအပြည့်အစုံပုံစံနှင့် စီရင်ချက်

14:28 သင်၏ database security group သည် သင်၏ application server ၏ security group မှသာ port 5432 တွင် ချိတ်ဆက်မှုများကို လက်ခံသည်။ 5432 သည် သင်၏ application server များ၏ လုံခြုံရေးအဖွဲ့မှသာလျှင်၊ အပြင်ဘက်မှ ထိုးဖောက်ဝင်ရောက်မှုကို သင်္ချာနည်းအရ မဖြစ်နိုင်အောင် လုပ်ဆောင်သည်။ အဝေးမှ ကြည့်လိုက်သောအခါ ဤမူလအခြေခံ အစိတ်အပိုင်း ၁၁ ခုသည် စည်းလုံးညီညွတ်သော စနစ်တစ်ခုအဖြစ် ချိတ်ဆက်သွားပါသည်။ သင်၏ DNS သည် public subnet ရှိ Load Balancer သို့ လမ်းကြောင်းပြသည်။ autoscaling group များသည် Availability Zones များစွာတွင် traffic တိုးမြှင့်မှုကို ကိုင်တွယ်ဖြေရှင်းသည်၊ event buses များသည် backend workers များကို ဖြတ်တောက်သည်၊ သင်၏ stack တစ်ခုလုံးကို Infrastructure as Code ကို အသုံးပြု၍ Git မှ deploy လုပ်ထားသည်။ event buses များသည် backend workers များကို ဖြတ်တောက်သည်၊ သင်၏ stack တစ်ခုလုံးကို Git မှ Infrastructure as Code ကို အသုံးပြု၍ deploy လုပ်ထားသည်။

15:02 ယနေ့ masterclass ၏ စီရင်ချက်- SHIP IT။ cloud marketing အတိုကောက် ရာပေါင်းများစွာကို မှတ်သားခြင်း ရပ်လိုက်ပါ။ ဤဗိသုကာပုံစံ ဆယ်ခုကို ကျွမ်းကျင်ပါ၊ သင့်အခြေအနေကို ခွဲထုတ်ပါ၊ ပျက်စီး၍မရသော စနစ်များကို တည်ဆောက်ပါ။ သင် ပထမဆုံး စတင်တည်ဆောက်သောအခါ မည်သည့် cloud အယူအဆက သင့်ကို အခက်ခဲဆုံး ဖြစ်စေခဲ့သည်ကို မှတ်ချက်များတွင် ပြောပြပါ။ မှတ်ချက်များတွင် တည်ဆောက်ခြင်း။ ပြီးပြည့်စုံသော ဗိသုကာ လိမ်လည်မှုစာရွက်ကို ရယူရန်၊ The Daily Diff dot dev တွင် သတင်းလွှာကို စာရင်းသွင်းပါ။

15:28 အောက်ပါ link ။ ဒါက ဒီနေ့အတွက် The Daily Diff ပဲ။ ကျွန်တော် Axrisi က Niko ပါ။ တာဝန်ယူမှုဖြင့် ပေါင်းစည်းပါ။

ရင်းမြစ်များ

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io