ការពន្យល់អំពី Cloud computing: គំនិតស្ថាបត្យកម្មចំនួន 11 ដែលអ្នកត្រូវតែដឹង (4K Masterclass)។

អ្វីដែលវីដេអូនេះគ្របដណ្ដប់

• - ជញ្ជាំងស្ថាបត្យកម្ម និងប្លង់មេ
• - 01. ការធ្វើមាត្រដ្ឋានបញ្ឈរ ទល់នឹង ការធ្វើមាត្រដ្ឋានផ្ដេក
• - 02. ស្ថាបត្យកម្ម Load Balancing (L4 vs. L7 & Health Checks)
• - 03. ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងភាពយឺត
• - 04. គ្មាន Server (FaaS & Firecracker MicroVMs)

កំណត់ត្រាដែលបានបកប្រែ

បកប្រែចេញពីការនិទានដើមជាភាសាអង់គ្លេស។ សំឡេង និងចំណងជើងរងដែលមានគឺស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់ YouTube។

- ជញ្ជាំងស្ថាបត្យកម្ម និងប្លង់មេ

0:00 វិស្វករកម្មវិធីគ្រប់រូបនៅទីបំផុតប្រឈមមុខនឹងជញ្ជាំងស្ថាបត្យកម្មពពក។ អ្នកបង្កើតកម្មវិធីមួយនៅលើកុំព្យូទ័រយួរដៃរបស់អ្នក រុញវាទៅផលិតកម្ម ហើយនៅពេលដែលអ្នកប្រើប្រាស់ពិតប្រាកដមកដល់ ម៉ាស៊ីនមេគាំង ការតភ្ជាប់មូលដ្ឋានទិន្នន័យអស់ និងវិក្កយបត្រ AWS របស់អ្នកមើលទៅដូចជាលេខទូរស័ព្ព្ទ ។ អ្នកអភិវឌ្ឍន៍ភាគច្រើនព្យាយាមដោះស្រាយវិស្វកម្មពពកដោយការទន្ទេញ អក្សរកាត់ផលិតផល AWS បីរយខុសៗគ្នា។ ប៉ុន្តែ Cloud Computing ពិតប្រាកដមិនមែននិយាយអំពីការទន្ទេញកាតាឡុកអ្នកលក់នោះទេ៖ វា ត្រូវបានបង្កើតឡើងនៅលើគំនិតស្ថាបត្យកម្មមូលដ្ឋានចំនួនដប់មួយ។

0:34 នៅក្នុងវគ្គបណ្ដុះបណ្ដាលនេះ យើងនឹងដើរឆ្លងកាត់ប្លង់មេរបស់សហគ្រាសទាំងមូល៖ ចាប់ពី ការធ្វើមាត្រដ្ឋាន និងការធ្វើឱ្យមានតុល្យភាពផ្ទុក រហូតដល់ serverless, ការបំបែកដោយការជំរុញព្រឹត្តិការណ៍ ឋានានុក្រមផ្ទុកទិន្នន័យ និងបណ្ដាញពពក។ ស្ទាត់ជំនាញគំនិតទាំងដប់មួយនេះ ហើយអ្នកអាចរចនា backend ណាមួយនៅលើ AWS GCP ឬ Azure ។ នេះគឺជា The Daily Diff, នៅក្រោមក្រណាត់។

- 01. ការធ្វើមាត្រដ្ឋានបញ្ឈរ ទល់នឹង ការធ្វើមាត្រដ្ឋានផ្ដេក

0:57 គំនិតលេខមួយ៖ ការធ្វើមាត្រដ្ឋាន។ នៅពេលដែលកម្មវិធីរបស់អ្នកជួបប្រទះការកើនឡើងចរាចរណ៍ អ្នកមានវិធីសាស្ត្រមូលដ្ឋានគ្រឹះពីរ ខុសៗគ្នាដើម្បីដោះស្រាយបន្ទុក៖ ការធ្វើមាត្រដ្ឋានបញ្ឈរ ឬការធ្វើមាត្រដ្ឋានផ្ដេក ។ ការធ្វើមាត្រដ្ឋានបញ្ឈរ ឬការធ្វើមាត្រដ្ឋានឡើង គឺមានន័យថាការយក ម៉ាស៊ីនដែលមានស្រាប់របស់អ្នក ហើយបន្ថែមធនធានបន្ថែម៖ ការដំឡើងពី CPU cores បួន ទៅសាមសិបពីរ ឬការផ្លាស់ប្តូរ RAM សាមសិបពីរកិកាបៃ ទៅមួយរយម្ភៃប្រាំបី។ មួយរយម្ភៃប្រាំបី។ ការធ្វើមាត្រដ្ឋានបញ្ឈរតម្រូវឱ្យមានការផ្លាស់ប្តូរស្ថាបត្យកម្មសូន្យ៖ កូដរបស់អ្នក

1:28 និងមូលដ្ឋានទិន្នន័យនៅតែដដែល។ ប៉ុន្តែវាប៉ះនឹងកម្រិត hardware ដ៏សាហាវ។ គ្មានម៉ាស៊ីនតែមួយនៅក្នុងពិភពលោកមាន CPU cores មួយម៉ឺននោះទេ ហើយឧទាហរណ៍កម្រិតខ្ពស់មានតម្លៃថ្លៃ exponentially ។ ការធ្វើមាត្រដ្ឋានផ្ដេក ឬការធ្វើមាត្រដ្ឋានចេញ គឺមានន័យថាការរក្សាម៉ាស៊ីនមេរបស់អ្នក តូច និងមានតម្លៃទំនិញ ប៉ុន្តែដំណើរការឧទាហរណ៍ច្រើនក្នុងពេលដំណាលគ្នានៅពីក្រោយ រ៉ោតទ័រ។ ប្រសិនបើឧទាហរណ៍មួយគាំង ថ្នាំងដែលនៅសល់នឹងស្រូបយកចរាចរណ៍ដោយ គ្មានការរអាក់រអួល។ គោលការណ៍មាសនៃការធ្វើមាត្រដ្ឋានផ្ដេកគឺ

2:01 statelessness៖ ម៉ាស៊ីនមេកម្មវិធីរបស់អ្នកមិនអាចផ្ទុកវគ្គអ្នកប្រើប្រាស់ ឯកសារដែលបានផ្ទុកឡើង ឬស្ថានភាពនៅលើថាសក្នុងស្រុករបស់ពួកគេឡើយ។ ស្ថានភាពត្រូវតែមាននៅក្នុងមូលដ្ឋានទិន្នន័យខាងក្រៅ ឬ cache ដែលអនុញ្ញាតឱ្យថ្នាំងណាមួយដោះស្រាយសំណើអ្នកប្រើប្រាស់ណាមួយ។

- 02. ស្ថាបត្យកម្ម Load Balancing (L4 vs. L7 & Health Checks)

2:17 គំនិតលេខពីរ៖ Load Balancing ។ ការធ្វើមាត្រដ្ឋានផ្ដេកស្តាប់ទៅល្អនៅលើក្រដាស ប៉ុន្តែវាបង្កបញ្ហាមួយភ្លាមៗ៖ នៅពេលដែលអ្នកប្រើប្រាស់មួយម៉ឺននាក់ចូលទៅកាន់ឈ្មោះដែនរបស់អ្នក ម៉ាស៊ីនមេជាក់លាក់មួយណាទទួលបានចរាចរណ៍របស់ពួកគេ? Load balancer ដើរតួជា reverse proxy ដែលស្ថិតនៅចន្លោះអ៊ីនធឺណិតសាធារណៈ និង cluster backend ឯកជនរបស់អ្នក។ វាទទួលយកការតភ្ជាប់ TCP ឬ HTTP ដែលចូលមក ហើយ ចែកចាយសំណើទៅកាន់ឧទាហរណ៍ដែលមានសុខភាពល្អរបស់អ្នក។

2:47 Load balancers ដំណើរការនៅស្រទាប់បណ្ដាញសំខាន់ពីរ។ Load Balancers បណ្ដាញ Layer 4 ដំណើរការនៅស្រទាប់ transport ការបញ្ជូនបន្តកញ្ចប់ TCP និង UDP ឆៅដោយផ្អែកលើអាសយដ្ឋាន IP និង port ជាមួយនឹង microsecond latency និងសំណើរាប់លានក្នុងមួយវិនាទី។ Load Balancers កម្មវិធី Layer 7 ត្រួតពិនិត្យពិធីការ HTTP ដោយខ្លួនវា៖ ការអាន URL paths, request headers, cookies និង HTTP methods ។ នេះអនុញ្ញាតឱ្យមាន path-based routing៖ ការផ្ញើសំណើ slash-api ទៅកាន់ backend cluster របស់អ្នក និងសំណើ slash-static ទៅកាន់

3:25 object store ។ ជាពិសេស load balancers អនុវត្ត active health checks ។ រៀងរាល់ពីរបីវិនាទីម្តង balancer នឹង ping health endpoint នៅលើរាល់ ឧទាហរណ៍។ ប្រសិនបើឧទាហរណ៍មួយបញ្ចេញកំហុសប្រាំរយបីដងជាប់គ្នា ឬ បរាជ័យក្នុងការឆ្លើយតប វាត្រូវបានដកចេញដោយស្វ័យប្រវត្តិពី pool ដោយ គ្មានសំណើដែលបានទម្លាក់ឡើយ។

- 03. ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងភាពយឺត

3:45 គំនិតលេខបី៖ Autoscaling ។ ប្រសិនបើ web app របស់អ្នកត្រូវការម៉ាស៊ីនមេពីរនៅម៉ោងបីព្រឹក ប៉ុន្តែម៉ាស៊ីនមេម្ភៃអំឡុងពេលបើកដំណើរការពាក់កណ្តាលថ្ងៃ ការចុចប៊ូតុងដោយដៃនៅក្នុង cloud console គឺជាផ្លូវដែលធានាដល់ការរអាក់រអួល និងការក្ស័យធន។ Autoscaling នាំមកនូវភាពយឺតដែលបត់បែនបានទៅកាន់ horizontal server pools ។ Auto Scaling Group ត្រួតពិនិត្យ metrics ការអនុវត្តដូចជាមធ្យម ការប្រើប្រាស់ CPU, network I-O ឬ queue backlog depth ។ នៅពេលដែលមធ្យម CPU ឆ្លងកាត់កម្រិតកំណត់មួយ — ឧទាហរណ៍

4:19 ចិតសិបភាគរយក្នុងរយៈពេលបីនាទីជាប់គ្នា — autoscaler នឹងបើកដំណើរការដោយស្វ័យប្រវត្តិ virtual machines ថ្មី ចុះឈ្មោះពួកវាជាមួយ load balancer របស់អ្នក ហើយចាប់ផ្តើមបញ្ជូនបន្តចរាចរណ៍។ ការធ្វើមាត្រដ្ឋានចូលក៏សំខាន់ដែរ៖ នៅពេលដែលរលកចរាចរណ៍ស្រកចុះ autoscaler បញ្ឈប់ឧទាហរណ៍លើសដើម្បីឱ្យអ្នកឈប់ចំណាយសម្រាប់ idle compute ។ ដើម្បីការពារ flapping — ដែលម៉ាស៊ីនមេត្រូវបានបង្កើតឡើងយ៉ាងលឿន និង បំផ្លាញក្នុងវដ្តដ៏គ្មានទីបញ្ចប់ — cloud architects កំណត់រចនាសម្ព័ន្ធ cooldown periods ។ គំនិតលេខបួន៖ Serverless ។

- 04. គ្មាន Server (FaaS & Firecracker MicroVMs)

4:53 អស់រយៈពេលជាច្រើនឆ្នាំ ក្រុមទីផ្សារបានផ្សព្វផ្សាយ serverless ជា magic code ដែលកំពុងដំណើរការនៅលើមេឃ។ តាមពិត serverless នៅតែប្រើម៉ាស៊ីនមេ — ប៉ុន្តែអ្នកមិនមែនជាម្ចាស់ បំណះ ឬបង់ប្រាក់សម្រាប់ពួកវាទេ នៅពេលដែលគ្មានកូដកំពុងដំណើរការ។ ជាមួយ Function-as-a-Service ដូចជា AWS Lambda ឬ Google Cloud Functions អ្នកសរសេរ handler function ឯករាជ្យមួយ។ នៅពេលដែលមានសំណើ HTTP, ការផ្ទុកឯកសារ S3 ឬការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យ កើតឡើង cloud runtime នឹងចាប់ផ្ដើម ephemeral

5:23 micro-virtual-machine ដូចជា Firecracker ក្នុងរយៈពេលតិចជាងប្រាំមីលីវិនាទី។ កូដរបស់អ្នកប្រតិបត្តិ ត្រឡប់ការឆ្លើយតប ហើយបិទ។ ប្រសិនបើគ្មាននរណាម្នាក់ចូលមើលគេហទំព័ររបស់អ្នករយៈពេលបីខែ វិក្កយបត្រ compute របស់អ្នកគឺពិតប្រាកដ សូន្យដុល្លារ និងសូន្យសេន។ ប្រសិនបើអ្នកប្រើប្រាស់មួយលាននាក់ចូលក្នុងពេលដំណាលគ្នា អ្នកផ្តល់សេវានឹងបើកដំណើរការ microVMs មួយលាន ក្នុងពេលដំណាលគ្នា។ ការផ្លាស់ប្តូរវិស្វកម្មគឺពិតប្រាកដ៖ cold start latency នៅពេលចាប់ផ្តើម runtimes ថ្មី កម្រិតប្រតិបត្តិដប់ប្រាំនាទីរឹងមាំ នៅលើ Lambda និង statelessness ដ៏តឹងរ៉ឹង។

5:55 Serverless មិនអាចយកឈ្នះបានសម្រាប់ event pipelines និង sporadic APIs ប៉ុន្តែមិនល្អសម្រាប់ Persistent WebSockets ឬ multi-hour training runs ។

- 05. ស្ថាបត្យកម្មជំរុញដោយព្រឹត្តិការណ៍ (EDA & Decoupling)

6:05 គំនិតលេខប្រាំ៖ ស្ថាបត្យកម្មជំរុញដោយព្រឹត្តិការណ៍ ឬ EDA ។ នៅក្នុងស្ថាបត្យកម្មប្រពៃណី សេវាកម្មទំនាក់ទំនង synchronously ។ សេវាកម្ម checkout របស់អ្នកហៅ payment, payment ហៅ inventory inventory ហៅ fraud ហើយ fraud ហៅ email ។ នេះបង្កើតបានជា synchronous cascade of doom ។ ប្រសិនបើអ្នកផ្តល់អ៊ីមែលភាគីទីបីជួបប្រទះបញ្ហាបណ្ដាញ ហើយចំណាយពេលដប់ វិនាទីដើម្បីឆ្លើយតប សំណើ checkout ទាំងមូលរបស់អតិថិជនរបស់អ្នកនឹងអស់ពេលដោយ កំហុស។ នៅក្នុងស្ថាបត្យកម្មជំរុញដោយព្រឹត្តិការណ៍ សេវាកម្មត្រូវបានបំបែកទាំងស្រុង។

6:37 នៅពេលដែលអតិថិជនចុចទិញ សេវាកម្ម checkout មិនហៅសេវាកម្ម downstream ទេ។ វាគ្រាន់តែបោះពុម្ពព្រឹត្តិការណ៍មួយដែលមានឈ្មោះថា OrderPlaced ទៅកាន់ Event Bus កណ្តាលដូចជា Amazon EventBridge ឬ SNS topic ។ ការ checkout បញ្ចប់ក្នុងរយៈពេលហាសិបមីលីវិនាទី។ Downstream workers សម្រាប់ payment, inventory deduction និង email receipts ទាញសារដោយឯករាជ្យពី SQS queues ផ្ទាល់ខ្លួនរបស់ពួកគេ។ ប្រសិនបើសេវាកម្មអ៊ីមែលចុះខ្សោយរយៈពេលមួយម៉ោង សារនឹងរង់ចាំដោយសុវត្ថិភាព ត្រូវបានផ្ទុកនៅក្នុង queue ដោយគ្មានការបញ្ជាទិញណាមួយត្រូវបានទម្លាក់ឡើយ។

- 06. Container Orchestration (Docker & Kubernetes)

7:13 គំនិតលេខប្រាំមួយ៖ Container Orchestration ។ Docker បានដោះស្រាយការវេចខ្ចប់៖ វាខ្ចប់កូដកម្មវិធីរបស់អ្នក បណ្ណាល័យប្រព័ន្ធ ការកំណត់រចនាសម្ព័ន្ធ និង runtime ទៅក្នុង immutable image ដែលដំណើរការដូចគ្នានៅលើ MacBook របស់អ្នក និងនៅក្នុង cloud ។ ប៉ុន្តែការវេចខ្ចប់កុងតឺន័រគឺងាយស្រួល។ ការដំណើរការកុងតឺន័រប្រាំរយនៅទូទាំង virtual machines រូបវន្តហាសិបគឺកន្លែងដែល វិស្វកម្មខូច។ នោះហើយជាមូលហេតុដែល container orchestrators ដូចជា Kubernetes និង AWS ECS

7:41 មាន។ Orchestrator ផ្តល់នូវ control plane៖ API server etcd state store និង scheduler ឆ្លាតវៃ។ អ្នកប្រកាសស្ថានភាពដែលអ្នកចង់បាន៖ ខ្ញុំចង់បាន replicas ដប់នៃ auth service របស់ខ្ញុំជាមួយនឹង RAM ពីរកិកាបៃនីមួយៗ។ scheduler ត្រួតពិនិត្យ cluster ដាក់ pods នៅលើ nodes ដែលមាន memory ទំនេរ កំណត់រចនាសម្ព័ន្ធបណ្ដាញផ្ទៃក្នុង និងផ្សះផ្សាការពិតជាបន្តបន្ទាប់។ ប្រសិនបើ node ជួបប្រទះការបរាជ័យ hardware, Kubernetes រកឃើញ ការបាត់បង់ និងរៀបចំកាលវិភាគឡើងវិញភ្លាមៗនូវ pods ដែលត្រូវបានផ្លាស់ទីលំនៅទាំងអស់ទៅកាន់

- 07. សសរស្តម្ភផ្ទុកទិន្នន័យ Cloud ទាំង 4 (S3, EBS, DBs & Redis)

8:16 healthy nodes ។ គំនិតលេខប្រាំពីរ៖ ឋានានុក្រមផ្ទុកទិន្នន័យ Cloud ។ អ្នកចាប់ផ្តើមដំបូងតែងតែចាត់ទុក cloud storage ជាធុងតែមួយដែលអ្នកបោះ ឯកសារ។ នៅក្នុងស្ថាបត្យកម្មផលិតកម្ម ការផ្ទុកទិន្នន័យត្រូវបានបែងចែកជាសសរស្តម្ភបួនផ្សេងគ្នា ដោយផ្អែកលើ access patterns និង latency ។ ទីមួយគឺ Object Storage ដូចជា Amazon S3 ឬ Google Cloud Storage ។ អ្នកចូលប្រើឯកសារតាមរយៈ HTTP REST APIs ដោយប្រើ ការហៅ PUT និង GET សាមញ្ញ។ វាផ្តល់នូវសមត្ថភាពផ្ដេកគ្មានកំណត់ក្នុងតម្លៃពីរ សេនក្នុងមួយកិកាបៃក្នុងមួយខែ

8:49 ធ្វើឱ្យវាល្អសម្រាប់វីដេអូ ការផ្ទុកឡើងរបស់អ្នកប្រើប្រាស់ កំណត់ហេតុ និងការបម្រុងទុក។ ទីពីរគឺ Block Storage ដូចជា Amazon EBS ។ ទាំងនេះគឺជា virtual hard drives ដែលត្រូវបានភ្ជាប់ដោយផ្ទាល់ទៅនឹង virtual machine ជាក់លាក់មួយ តាមរយៈ high-speed interconnects ។ ពួកវាត្រូវបាន format ទៅជា filesystems ស្តង់ដារដូចជា ext4 ដែលគាំទ្រការចូលប្រើ read និង write random លឿនដែលតម្រូវដោយ database engines ។ ទីបីគឺ Managed Databases៖ relational engines ដូចជា PostgreSQL នៅលើ RDS ដែលផ្តល់នូវ ACID transactions និង complex joins

9:21 និង NoSQL engines ដូចជា DynamoDB ដែលផ្តល់នូវ single-digit millisecond latency ក្នុងទំហំធំ។ ហើយទីបួនគឺ In-Memory Caches ដូចជា Redis ។ ការអានទិន្នន័យពី RAM ចំណាយពេល microseconds ជំនួសឱ្យ milliseconds ។ Caches ស្ថិតនៅពីមុខមូលដ្ឋានទិន្នន័យរបស់អ្នក ការការពារវាពីចរាចរណ៍ read ដដែលៗ និងការគ្រប់គ្រង volatile user session tokens ។

- 08. ភាពអាចប្រើបានខ្ពស់ & The Nines (Multi-AZ Failover)

9:44 គំនិតលេខប្រាំបី៖ ភាពអាចប្រើបានខ្ពស់ ឬ HA ។ ភាពអាចប្រើបានឆ្លើយសំណួរមួយ៖ តើភាគរយប៉ុន្មាននៃពេលវេលាដែលកម្មវិធីរបស់អ្នក កំពុងដំណើរការ និងអាចទៅដល់បានដោយអ្នកប្រើប្រាស់? នៅក្នុងកិច្ចសន្យាសហគ្រាស ភាពអាចប្រើបានត្រូវបានវាស់ជា nines ។ Two nines ឬ 99% ភាពអាចប្រើបាន អនុញ្ញាតឱ្យមាន downtime ជាងបីថ្ងៃកន្លះ រៀងរាល់ឆ្នាំ។ Four nines បន្ថយ downtime ដែលអនុញ្ញាតឱ្យមានហាសិបពីរនាទី និង five nines អនុញ្ញាតឱ្យមាន downtime សរុបតែប្រាំនាទីក្នុងមួយឆ្នាំ។

10:15 ដើម្បីសម្រេចបាននូវភាពអាចប្រើបានខ្ពស់ អ្នកត្រូវតែលុបបំបាត់ single points of failure នៅទូទាំង fault domains ។ នៅក្នុង cloud នោះមានន័យថាការដាក់ពង្រាយនៅទូទាំង Availability Zones ច្រើន។ Availability Zone មិនមែនជា rack តែមួយទេ៖ វាគឺជា data centers រូបវន្តមួយ ឬច្រើនផ្សេងគ្នា ដែលនៅឆ្ងាយរាប់ម៉ាយល៍ជាមួយនឹងថាមពល និងការត្រជាក់ឯករាជ្យ។ ដោយការដំណើរការ active instances នៅក្នុង Zone A និង Zone B ជាមួយនឹង synchronous database replication ការវាយប្រហារដោយរន្ទះ ឬការកាត់ fiber ដែលធ្វើឱ្យ ខូចខាតដល់កន្លែងរូបវន្តទាំងមូលបណ្តាលឱ្យមាន automated failover

10:50 ក្នុងរយៈពេលសាមសិបវិនាទីដោយគ្មានការអន្តរាគមន៍ពីមនុស្ស។

- 09. ភាពធន់ ទល់នឹង ភាពអាចប្រើបាន (ហេតុអ្វី 11 Nines មិនមែន Uptime)

10:53 គំនិតទីប្រាំបួន៖ ភាពធន់ធៀបនឹងភាពអាចរកបាន។ នេះគឺជាអន្ទាក់គំនិតទូទៅបំផុតតែមួយគត់នៅក្នុងស្ថាបត្យកម្ម Cloud ការសម្ភាសន៍។ វិស្វករតែងតែប្រើពាក្យទាំងនេះជំនួសគ្នា ប៉ុន្តែពួកវាវាស់លក្ខណៈសម្បត្តិខុសគ្នាទាំងស្រុង។ ភាពអាចរកបានវាស់ពេលវេលាដំណើរការ៖ តើខ្ញុំអាចធ្វើការហៅទូរស័ព្ទ API ដើម្បីអាន ឬសរសេរ ទិន្នន័យរបស់ខ្ញុំបានទេនៅវិនាទីនេះ? ភាពធន់វាស់ការរក្សាទុក៖ តើទិន្នន័យរបស់ខ្ញុំនឹងនៅគង់វង្សដោយគ្មានការខូចខាតជាអចិន្ត្រៃយ៍ ប៊ីតរលួយ ការបាត់បង់ ឬការបំផ្លាញក្នុងរយៈពេលដប់ឆ្នាំដែរឬទេ?

11:24 សូមក្រឡេកមើល Amazon S3 Standard។ កិច្ចព្រមព្រៀងកម្រិតសេវាកម្មរបស់វាផ្តល់ជូន ៩៩.៩ ភាគរយ ភាពអាចរកបាន ដែលអនុញ្ញាតឱ្យមានពេលវេលាមិនដំណើរការប្រហែល ៤៣ នាទីក្នុងមួយខែ ដែលសំណើសុំ API អាចត្រឡប់កំហុស ៥០០។ ប៉ុន្តែ S3 សន្យាថានឹងមានភាពធន់ ១១ ប្រាំបួន៖ កៅសិបប្រាំបួន ចំណុចប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ប្រាំបួន ភាគរយ។ ប្រសិនបើអ្នករក្សាទុកឯកសារដប់លាននៅក្នុង S3 អ្នកអាចរំពឹងថានឹងបាត់បង់ជាមធ្យម

11:56 ឯកសារមួយរៀងរាល់មួយម៉ឺនឆ្នាំម្តង។ S3 សម្រេចបាននេះដោយការកូដវត្ថុ និងចម្លងបំណែកនៅទូទាំង យ៉ាងហោចណាស់កន្លែងទិន្នន័យបីដែលបំបែកពីគ្នាដោយភូមិសាស្ត្រ។ ក្នុងអំឡុងពេលនៃការដាច់បណ្តាញក្នុងតំបន់ដ៏ធំមួយ S3 អាចនឹងមិនអាចប្រើបានជាបណ្ដោះអាសន្ន ប៉ុន្តែទិន្នន័យរបស់អ្នកមិនដែលត្រូវបានបំផ្លាញឡើយ។

- 10. Infrastructure as Code (Terraform ទល់នឹង Console Drift)

12:14 គំនិតទីដប់៖ ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ ឬ IaC។ នៅដំណាក់កាលដំបូងនៃការគណនា Cloud វិស្វករបានចូលទៅក្នុង AWS კონសូលគ្រប់គ្រងគេហទំព័រ ហើយចុចដោយដៃដើម្បីបង្កើតម៉ាស៊ីននិម្មិត កំណត់រចនាសម្ព័ន្ធ Subnet និងភ្ជាប់ក្រុមសុវត្ថិភាព។ ឧស្សាហកម្មនេះហៅវាថា ClickOps ហើយក្នុងការផលិត វាគឺជាគ្រោះមហន្តរាយ ទាំងស្រុង។ ការផ្លាស់ប្តូរ Console ដោយដៃមិនមានផ្លូវសវនកម្ម គ្មានយន្តការបង្វិលត្រឡប់ ហើយជៀសមិនរួចបណ្តាលឱ្យមានការប្រែប្រួលការកំណត់រចនាសម្ព័ន្ធរវាងបរិស្ថាន staging និង production។ ជាមួយនឹងឧបករណ៍ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ

12:48 ដូចជា Terraform, OpenTofu, Pulumi, ឬ AWS CDK អ្នកកំណត់រចនាសម្ព័ន្ធ Cloud ទាំងមូលរបស់អ្នកនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធប្រកាសដែលបានរក្សាទុកក្នុង Git។ រាល់ការផ្លាស់ប្តូរទៅកាន់ Port បើក ឬ Database Replica ត្រូវឆ្លងកាត់ សំណើទាញ និងការត្រួតពិនិត្យដោយមិត្តភ័ក្តិ។ ការដំណើរការ terraform plan មើលជាមុននូវ API diff ពិតប្រាកដមុនពេល អ្វីមួយត្រូវបានប៉ះពាល់ ហើយការបង្វិល replica ដូចគ្នានៃ production stack របស់អ្នក ចំណាយពេលបួននាទីជំនួសឱ្យបួនសប្តាហ៍។

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

13:20 គំនិតទីដប់មួយ៖ បណ្តាញ Cloud និង Virtual Private Clouds។ នៅពេលអ្នកដាក់ពង្រាយ server ទៅ Cloud ពួកវាមិនត្រូវបានបង្ហាញនៅលើ អ៊ីនធឺណិតសាធារណៈឆៅនោះទេ។ ពួកវារស់នៅខាងក្នុងព្រំដែនដាច់ដោយឡែកដែលកំណត់ដោយ Software ហៅថា VPC។ នៅក្នុង VPC របស់អ្នក អ្នកបែងចែកចន្លោះអាសយដ្ឋាន IP ឯកជនដូចជា ១០.០.០.០/១៦ ហើយបែងចែកវា ទៅជា Subnet សាធារណៈ និងឯកជន។ Subnet សាធារណៈមានផ្លូវផ្ទាល់ទៅកាន់ Internet Gateway។

13:51 វាផ្ទុកទ្រព្យសម្បត្តិដែលប្រឈមមុខនឹងសាធារណៈជនដូចជា Application Load Balancers និង NAT Gateways។ វាគឺជាផ្នែកតែមួយគត់នៃបណ្តាញរបស់អ្នកដែលមានអាសយដ្ឋាន IP សាធារណៈ។ Application server និង Database Production របស់អ្នករស់នៅយ៉ាងតឹងរ៉ឹងនៅក្នុង Subnet ឯកជន ដោយគ្មាន IP សាធារណៈ និងគ្មាន Inbound Route ពីអ៊ីនធឺណិត។ នៅពេល Backend server របស់អ្នកត្រូវការទាញយកការអាប់ដេតសុវត្ថិភាព Outbound Traffic របស់ពួកវាធ្វើដំណើរឆ្លងកាត់ NAT Gateway នៅក្នុង Subnet សាធារណៈ។ ជុំវិញរាល់ Instance គឺជា Security Group៖ Firewall និម្មិត Stateful ដែលអនុវត្តគោលការណ៍នៃសិទ្ធិអប្បបរមា។

- 12. ប្លង់មេរបស់សហគ្រាសពេញលេញ & សាលក្រម

14:28 Security Group នៃ Database របស់អ្នកទទួលយកតែ Connection នៅលើ Port ៥៤៣២ យ៉ាងតឹងរ៉ឹងពី Security Group នៃ Application server របស់អ្នក ដែលធ្វើឱ្យការជ្រៀតចូលពីខាងក្រៅមិនអាចទៅរួចតាមគណិតវិទ្យា។ នៅពេលអ្នកពង្រីកចេញ វត្ថុបុរាណទាំងដប់មួយនេះភ្ជាប់គ្នាទៅជាប្រព័ន្ធមួយដែលមានភាពស៊ីសង្វាក់គ្នា។ DNS របស់អ្នកធ្វើដំណើរទៅ Load Balancer នៅក្នុង Subnet សាធារណៈ ក្រុម Autoscaling គ្រប់គ្រង Traffic surges នៅទូទាំង Availability Zone ជាច្រើន Event Bus ញែក Backend worker ចេញពីគ្នា ហើយ Stack ទាំងមូលរបស់អ្នក ត្រូវបានដាក់ពង្រាយពី Git ដោយប្រើ Infrastructure as Code។

15:02 សាលក្រម Masterclass ថ្ងៃនេះ៖ SHIP IT។ ឈប់ទន្ទេញចាំអក្សរកាត់ Cloud Marketing រាប់រយទៀត។ ធ្វើជាម្ចាស់លើ Architecture Pattern ទាំងដប់មួយនេះ ញែក State របស់អ្នកចេញពីគ្នា ហើយបង្កើតប្រព័ន្ធដែលមិនអាចបរាជ័យបាន។ ប្រាប់ខ្ញុំពីគំនិត Cloud ណាដែលធ្វើឱ្យអ្នកឈឺក្បាលបំផុតនៅពេលអ្នកចាប់ផ្តើមដំបូង សាងសង់នៅក្នុង Comment។ ហើយដើម្បីទាញយក Architecture Cheat Sheet ពេញលេញ ជាវព្រឹត្តិប័ត្រព័ត៌មាននៅ the daily diff dot dev

15:28 តំណភ្ជាប់ខាងក្រោម។ ហើយនោះគឺជា Diff សម្រាប់ថ្ងៃនេះ។ ខ្ញុំឈ្មោះ Niko មកពី Axrisi។ បញ្ចូលដោយការទទួលខុសត្រូវ។

ប្រភព

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