Ipinaliwanag ang cloud computing: ang 11 konsepto ng arkitektura na dapat mong malaman (4K Masterclass).

Ang sakop ng video na ito

• - Ang Architecture Wall & Master Blueprint
• - 01. Vertical vs. Horizontal Scaling
• - 02. Load Balancing Architecture (L4 vs. L7 & Health Checks)
• - 03. Autoscaling & Elasticity
• - 04. Serverless (FaaS & Firecracker MicroVMs)

Isinaling transcript

Isinalin mula sa orihinal na salaysay sa English. Ang available na audio at mga caption ay kinokontrol ng YouTube.

- Ang Architecture Wall & Master Blueprint

0:00 Bawat software engineer ay sa huli ay nahaharap sa pader ng cloud architecture. Nagbubuo ka ng application sa iyong laptop, i-push ito sa production, at sa sandaling dumating ang mga totoong user, nag-crash ang mga server, nauubusan ng database connections, at ang iyong AWS bill ay parang isang numero ng telepono. Karamihan sa mga developer ay sinusubukang lutasin ang cloud engineering sa pamamagitan ng pagsasaulo ng tatlong daang magkakaibang acronym ng produkto ng AWS. Ngunit ang totoong cloud computing ay hindi tungkol sa pagsasaulo ng mga vendor catalog: ito ay binuo sa labing-isang pangunahing architectural primitive.

0:34 Sa masterclass na ito, lalakarin natin ang buong enterprise blueprint: mula sa scaling at load balancing hanggang sa serverless, event-driven decoupling, mga storage hierarchy, at cloud networking. Masterin ang labing-isang konseptong ito, at makakapagdisenyo ka ng anumang backend sa AWS, GCP, o Azure. Ito ang The Daily Diff, sa ilalim ng hood.

- 01. Vertical vs. Horizontal Scaling

0:57 Konsepto numero uno: Scaling. Kapag ang iyong application ay nakakaranas ng paglaki ng traffic, mayroon kang dalawang panimulang magkaibang paraan upang hawakan ang load: vertical scaling, o horizontal scaling. Ang vertical scaling, o scaling up, ay nangangahulugang pagkuha ng iyong kasalukuyang makina at pagdaragdag ng mas maraming resources: pag-upgrade mula sa apat na CPU cores patungo sa tatlumpu't dalawa, o pagpapalit ng tatlumpu't dalawang gigabytes ng RAM para sa isang daan at dalawampu't walong. Ang vertical scaling ay nangangailangan ng zero architectural changes: ang iyong code

1:28 at database ay nananatiling eksaktong pareho. Ngunit ito ay tumatama sa isang brutal na hardware ceiling. Walang isang makina sa mundo na may sampung libong CPU cores, at ang mga top-tier na instance ay may exponential price premium. Ang horizontal scaling, o scaling out, ay nangangahulugang panatilihing maliit ang iyong mga server at may presyo ng produkto, ngunit nagpapatakbo ng maraming instance nang parallel sa likod ng isang router. Kung nag-crash ang isang instance, ang natitirang mga node ay sumisipsip ng traffic na may zero downtime. Ang gintong panuntunan ng horizontal scaling ay

2:01 statelessness: ang iyong mga application server ay hindi maaaring mag-imbak ng mga session ng user, na-upload na file, o estado sa kanilang mga lokal na disk. Dapat manirahan ang estado sa isang panlabas na database o cache, na nagpapahintulot sa anumang node na hawakan ang anumang kahilingan ng user.

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

2:17 Konsepto numero dalawa: Load Balancing. Ang horizontal scaling ay maganda sa papel, ngunit nagpapakilala ito ng agarang problema: kapag sampung libong user ang tumama sa iyong domain name, alin sa partikular na server ang tumatanggap ng kanilang traffic? Ang isang load balancer ay gumaganap bilang isang reverse proxy na nakaupo sa pagitan ng pampublikong internet at ang iyong pribadong backend cluster. Tinatanggap nito ang mga papasok na koneksyon ng TCP o HTTP at ibinabahagi ang mga kahilingan sa iyong malulusog na instance.

2:47 Ang mga load balancer ay nagpapatakbo sa dalawang pangunahing network layer. Ang Layer 4 Network Load Balancers ay nagpapatakbo sa transport layer, nagruruta ng raw TCP at UDP packets batay sa IP address at port na may microsecond latency at milyon-milyong kahilingan bawat segundo. Ang Layer 7 Application Load Balancers ay sumusuri sa HTTP protocol mismo: nagbabasa ng mga URL path, request header, cookies, at HTTP mga pamamaraan. Nagbibigay-daan ito sa path-based routing: nagpapadala ng slash-api mga kahilingan sa iyong backend cluster at slash-static na mga kahilingan sa isang

3:25 object store. Mahalaga, ang mga load balancer ay nagsasagawa ng mga aktibong health check. Bawat ilang segundo, pinipindot ng balancer ang isang health endpoint sa bawat instance. Kung ang isang instance ay nagtatapon ng tatlong magkakasunod na limang-daang error o nabigong tumugon, awtomatiko itong pinapaalis mula sa pool na may zero dropped requests.

- 03. Autoscaling & Elasticity

3:45 Konsepto numero tatlo: Autoscaling. Kung ang iyong web app ay nangangailangan ng dalawang server sa alas tres ng umaga, ngunit dalawampung server sa panahon ng isang tanghali na paglulunsad, ang manu-manong pag-click ng mga pindutan sa cloud console ay isang garantisadong landas sa downtime at pagkabangkarote. Ang Autoscaling ay nagdudulot ng dynamic na elasticity sa mga horizontal server pool. Sinusubaybayan ng Auto Scaling Group ang mga sukatan ng performance tulad ng average CPU utilization, network I-O, o queue backlog lalim. Kapag ang average na CPU ay tumawid sa isang tinukoy na threshold — sabihin,

4:19 pitumpung porsyento sa loob ng tatlong magkakasunod na minuto — awtomatikong inilulunsad ng autoscaler ang mga bagong virtual machine, irehistro ang mga ito sa iyong load balancer, at nagsisimulang mag-ruta ng traffic. Pantay na mahalaga ang pag-scale in: kapag humupa ang traffic wave, tinatapos ng autoscaler ang labis na mga instance kaya tumitigil ka sa pagbabayad para sa idle compute. Upang maiwasan ang flapping — kung saan ang mga server ay mabilis na nilikha at nawasak sa isang walang katapusang thrashing loop — kino-configure ng mga cloud architect ang cooldown periods. Konsepto numero apat: Serverless.

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 Sa loob ng maraming taon, ipinagtanggol ng mga marketing team ang serverless bilang magic code na tumatakbo sa langit. Sa katotohanan, ang serverless ay gumagamit pa rin ng mga server — ngunit hindi mo pagmamay-ari, i-patch, o bayaran ang mga ito kapag walang code na tumatakbo. Sa Function-as-a-Service tulad ng AWS Lambda o Google Cloud Functions, sumusulat ka ng isang standalone handler function. Kapag nangyari ang isang HTTP request, S3 file upload, o pagbabago ng database, ang cloud runtime ay nag-boot ng isang panandaliang

5:23 micro-virtual-machine tulad ng Firecracker sa ilalim ng limang millisecond. Ang iyong code ay tumatakbo, nagbabalik ng tugon, at nagsasara. Kung walang bumisita sa iyong website sa loob ng tatlong buwan, eksaktong zero dolyar at zero cents ang iyong compute bill. Kung sabay-sabay na tumama ang isang milyong user, ang provider ay umiikot ng isang milyong concurrent microVMs. Ang mga engineering trade-off ay totoo: cold start latency kapag nagpapalit ng sariwang runtimes, isang matibay na labinlimang minutong limitasyon sa pagpapatupad sa Lambda, at mahigpit na statelessness.

5:55 Ang Serverless ay hindi matatalo para sa event pipelines at sporadic APIs, ngunit mahirap para sa persistent WebSockets o multi-hour training runs.

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

6:05 Konsepto numero lima: Event-Driven Architecture, o EDA. Sa tradisyonal na arkitektura, ang mga serbisyo ay nakikipag-ugnayan nang sabay-sabay. Ang iyong checkout service ay tumatawag sa payment, ang payment ay tumatawag sa inventory, ang inventory ay tumatawag sa fraud, at ang fraud ay tumatawag sa email. Lumilikha ito ng synchronous cascade of doom. Kung ang third-party email provider ay nakakaranas ng network hiccup at tumatagal ng sampung segundo upang tumugon, ang buong kahilingan sa checkout ng iyong customer ay nag-time out na mayroong error. Sa isang event-driven architecture, ang mga serbisyo ay ganap na decoupled.

6:37 Kapag nag-click ang isang customer ng buy, hindi tinatawag ng checkout service ang mga downstream service. Naglalathala lamang ito ng isang event na tinatawag na OrderPlaced sa isang central Event Bus tulad ng Amazon EventBridge o isang SNS topic. Nakumpleto ang checkout sa limampung millisecond. Ang mga downstream worker para sa pagbabayad, pagbabawas ng imbentaryo, at mga email receipt ay kumukuha ng mga mensahe nang independiyente mula sa kanilang sariling dedikadong SQS queues. Kung bumaba ang email service sa loob ng isang oras, ligtas na naghihintay ang mga mensahe na naka-buffer sa queue nang walang isang dropped order.

- 06. Container Orchestration (Docker & Kubernetes)

7:13 Konsepto numero anim: Container Orchestration. Nalutas ng Docker ang packaging: binabalot nito ang iyong application code, mga system library, configuration, at runtime sa isang immutable image na tumatakbo nang magkapareho sa iyong MacBook at sa cloud. Ngunit madali ang pag-package ng isang container. Ang pagpapatakbo ng limang daang container sa limampung pisikal na virtual machine ay kung saan bumabagsak ang engineering. Kaya't umiiral ang mga container orchestrator tulad ng Kubernetes at AWS ECS.

7:41 Ang isang orchestrator ay nagbibigay ng control plane: isang API server, isang etcd state store, at isang intelligent scheduler. Idineklara mo ang iyong nais na estado: Gusto ko ng sampung replica ng aking auth service na may dalawang gigabytes ng RAM bawat isa. Sinusuri ng scheduler ang cluster, naglalagay ng mga pod sa mga node na may libreng memorya, kinokonfigure ang internal networking, at patuloy na nagkakasundo sa realidad. Kung ang isang node ay nakakaranas ng pagkabigo sa hardware, nakikita ng Kubernetes ang pagkawala at agad na muling nag-iiskedyul ng lahat ng displaced pods sa

- 07. Ang 4 na Haligi ng Cloud Storage (S3, EBS, DBs & Redis)

8:16 malulusog na node. Konsepto numero pito: Ang Cloud Storage Hierarchy. Ang mga nagsisimula ay kadalasang tinatrato ang cloud storage bilang isang solong bucket kung saan ka nagtatapon ng mga file. Sa production architecture, ang storage ay nahahati sa apat na natatanging haligi batay sa mga pattern ng pag-access at latency. Una ay Object Storage, tulad ng Amazon S3 o Google Cloud Storage. Ina-access mo ang mga file sa pamamagitan ng HTTP REST APIs gamit ang simpleng PUT at GET calls. Nag-aalok ito ng walang hanggang horizontal capacity sa dalawang sentimo bawat gigabyte bawat buwan,

8:49 na ginagawa itong perpekto para sa video, user uploads, logs, at backups. Pangalawa ay Block Storage, tulad ng Amazon EBS. Ang mga ito ay virtual hard drive na direktang nakakabit sa isang partikular na virtual machine sa mataas na bilis na interconnects. Nagfo-format ang mga ito sa mga standard na filesystem tulad ng ext4, sumusuporta sa mabilis na random read at write access na kinakailangan ng mga database engine. Pangatlo ay Managed Databases: relational engine tulad ng PostgreSQL sa RDS na nagbibigay ng mga transaksyon ng ACID at kumplikadong joins,

9:21 at NoSQL engine tulad ng DynamoDB na naghahatid ng single-digit millisecond latency sa napakalaking scale. At pang-apat ay In-Memory Caches tulad ng Redis. Ang pagbabasa ng data mula sa RAM ay tumatagal ng microseconds sa halip na milliseconds. Ang mga cache ay nakaupo sa harap ng iyong database, na pinoprotektahan ito mula sa paulit-ulit na read traffic at pamamahala ng mga pabago-bagong token ng session ng user.

- 08. High Availability & Ang Nines (Multi-AZ Failover)

9:44 Konsepto numero ocho: High Availability, o HA. Sinusagot ng availability ang isang tanong: ilang porsyento ng oras ang iyong application na operational at naaabot ng mga user? Sa mga kontrata ng enterprise, ang availability ay sinusukat sa nines. Dalawang nines, o siyamnapu't siyam na porsyento na availability, ay nagpapahintulot ng mahigit tatlo at kalahating araw ng downtime bawat taon. Apat na nines ang nagpapababa ng pinapayagang downtime sa limampu't dalawang minuto, at limang nines ay nagpapahintulot ng halos limang minuto ng kabuuang downtime bawat

10:15 taon. Upang makamit ang high availability, dapat mong alisin ang mga single point of failure sa mga fault domain. Sa cloud, nangangahulugan iyon ng pag-deploy sa maraming Availability Zones. Ang isang Availability Zone ay hindi isang solong rack: ito ay isa o higit pang natatanging pisikal na data center na milya-milya ang layo na may independent power at cooling. Sa pamamagitan ng pagpapatakbo ng mga aktibong instance sa Zone A at Zone B na may synchronous database replication, ang pagtama ng kidlat o fiber cut na nagpapabagsak sa buong pisikal na pasilidad ay nagreresulta sa isang automated failover

10:50 sa loob ng tatlumpung segundo nang walang interbensyon ng tao.

- 09. Durability vs. Availability (Bakit 11 Nines Ay Hindi Uptime)

10:53 Konsepto bilang siyam: Durability versus Availability. Ito ang pinakakaraniwang conceptual trap sa cloud architecture na mga interbyu. Madalas gamitin ng mga inhinyero ang mga salita nang halinhinan, ngunit sinusukat nila ang ganap na magkakaibang mga katangian. Sinusukat ng Availability ang uptime: maaari ba akong gumawa ng API call upang basahin o isulat ang aking data sa sandaling ito? Sinusukat ng Durability ang pagpapanatili: mananatili ba ang aking data nang walang permanenteng bit rot, korupsyon, o pagkasira sa loob ng sampung taon?

11:24 Tingnan ang Amazon S3 Standard. Ang Service Level Agreement nito ay nag-aalok ng siyamnapu't siyam punto siyam na porsyento availability, na nagpapahintulot ng humigit-kumulang apatnapu't tatlong minuto ng downtime bawat buwan kung saan ang isang API request ay maaaring magbalik ng five-hundred error. Ngunit ang S3 ay nangangako ng eleven nines ng durability: siyamnapu't siyam punto siyam siyam siyam siyam siyam siyam siyam siyam siyam na porsyento. Kung mag-iimbak ka ng sampung milyong file sa S3, maaari mong asahan na mawalan ng

11:56 average na isang file bawat sampung libong taon. Nakakamit ito ng S3 sa pamamagitan ng erasure-coding objects at pagkopya ng mga chunks sa hindi bababa sa tatlong heograpikal na hiwalay na pasilidad ng data. Sa panahon ng isang malaking regional network outage, maaaring pansamantalang hindi magamit ang S3, ngunit hindi kailanman nawawala ang iyong data.

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

12:14 Konsepto bilang sampu: Infrastructure as Code, o IaC. Sa mga unang araw ng cloud computing, ang mga inhinyero ay nag-log in sa AWS web management console at mano-manong nag-click upang lumikha ng mga virtual machines, i-configure ang mga subnet, at mag-attach ng mga security group. Tinatawag ito ng industriya na ClickOps, at sa production, ito ay isang ganap na kalamidad. Ang mga manual console changes ay walang audit trail, walang rollback mechanism, at tiyak na nagiging sanhi ng configuration drift sa pagitan ng staging at production environments. Sa mga tool ng Infrastructure

12:48 as Code tulad ng Terraform, OpenTofu, Pulumi, o AWS CDK, tinutukoy mo ang iyong buong cloud architecture sa mga deklaratibong configuration file na nakaimbak sa Git. Bawat pagbabago sa isang open port o database replica ay dumadaan sa isang pull request at peer review. Ang pagpapatakbo ng terraform plan ay nagpi-preview ng eksaktong API diff bago may anumang galawin, at ang pag-set up ng isang magkaparehong replica ng iyong production stack ay tumatagal ng apat na minuto sa halip na apat na linggo.

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

13:20 Konsepto bilang labing-isa: Cloud Networking at Virtual Private Clouds. Kapag nagde-deploy ka ng mga server sa cloud, hindi sila nakaupo nang nakalantad sa raw public internet. Nakatira sila sa loob ng isang software-defined isolated boundary na tinatawag na VPC. Sa loob ng iyong VPC, naglaan ka ng private IP address space tulad ng ten-dot-zero-dot-zero-dot-zero slash sixteen, at hinahati ito sa public at private subnets. Ang isang public subnet ay may direktang ruta sa isang Internet Gateway.

13:51 Naglalaman ito ng mga public-facing asset tulad ng iyong Application Load Balancers at NAT Gateways. Ito lamang ang bahagi ng iyong network na nagtataglay ng public IP addresses. Ang iyong application servers at production databases ay mahigpit na nakatira sa private subnets na walang public IPs at walang inbound routes mula sa internet. Kapag kailangan ng iyong backend servers na mag-download ng mga security updates, ang kanilang outbound traffic ay dumadaan sa NAT Gateway sa public subnet. Nakapalibot sa bawat instance ang Security Groups: stateful na virtual firewalls na nagpapatupad ng prinsipyo ng least privilege.

- 12. Ang Kumpletong Enterprise Blueprint & Hatol

14:28 Ang iyong database security group ay tumatanggap lamang ng mga koneksyon sa port 5432 mahigpit mula sa security group ng iyong application servers, na nagpapangyari na imposibleng makalusot mula sa labas. Kapag nag-zoom out ka, ang labing-isang primitibo na ito ay nagkokonekta sa isang magkakaugnay na sistema. Ang iyong DNS ay nagruta sa isang Load Balancer sa isang public subnet, ang mga autoscaling group ay humahawak sa traffic surges sa maraming Availability Zones, ang mga event bus ay nagde-decouple ng mga backend worker, at ang iyong buong stack ay idine-deploy mula sa Git gamit ang Infrastructure as Code.

15:02 Ang hatol ng masterclass ngayon: SHIP IT. Huwag nang isaulo ang daan-daang acronym ng cloud marketing. Masterin ang labing-isang architecture pattern na ito, decouple ang iyong state, at bumuo ng mga sistema na hindi maaaring mag-fail. Sabihin mo sa akin kung aling cloud concept ang nagbigay sa iyo ng pinakamalaking sakit ng ulo noong una kang nagsimulang gumawa sa mga komento. At upang makuha ang kumpletong architecture cheat sheet, mag-subscribe sa newsletter sa the daily diff dot dev,

15:28 link sa ibaba. At iyon ang diff para ngayon. Ako si Niko mula sa Axrisi. Merge responsibly.

Mga Pinagmulan

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