# የክላውድ ኮምፒውተር ማብራሪያ፡ ማወቅ ያለብዎት 11 የህንፃ ንድፍ ፅንሰ ሀሳቦች (4K Masterclass)።

Published: 2026-09-15

አብዛኞቹ የሶፍትዌር መሐንዲሶች በመቶዎች የሚቆጠሩ የሻጭ ምርት ምህፃረ ቃላትን በAWS, GCP, እና Azure ላይ በማስታወስ የክላውድ አርክቴክቸር ለመማር ይሞክራሉ። ነገር ግን የእውነተኛው ዓለም የክላውድ ምህንድስና በአስራ አንድ መሰረታዊ የህንፃ ንድፍ መርሆዎች ላይ የተገነባ ነው። በዚህ 4K ማስተርክላስ ውስጥ ኒኮ የተሟላውን የድርጅት እቅድ ያብራራል፡ ከአቀባዊ ከቁመት መለኪያ እና አግድም መለኪያ እና Layer 7 የሎድ ባላንስ እስከ ተለዋዋጭ አውቶስኬሊንግ፣ ከሰርቨር-ነጻ ማይክሮቪኤም አፈፃፀም፣ አሲንክሮናዊ በክስተት የሚመራ መለያየት፣ ኮንቴይነር ኦርኬስትሬሽን፣ ባለአራት ምሰሶ ማከማቻ ተዋረድ፣ በከፍተኛ ተገኝነት እና በ11 ዘጠኞች ጥንካሬ መካከል ያለው ወሳኝ ልዩነት፣ ዲክላራቲቭ ኢንፍራስትራክቸር አስ ኮድ እና ቨርቹዋል ፕራይቬት ክላውድ ኔትወርኪንግ። እነዚህን አስራ አንድ ፅንሰ ሀሳቦች በመቆጣጠር፣ ማንኛውንም የኋላ-መጨረሻ ምርት ውስጥ መገንባት ይችላሉ። ብይን፡ SHIP IT።

Canonical: https://thedailydiff.dev/am/video/2026-09-14-cloud-computing-explained-4k/

## ይህ ቪዲዮ ምን ይሸፍናል

- - የህንፃ ንድፍ ግድግዳ እና ዋና እቅድ
- - 01. ቀጥ ያለ vs. አግድም ልኬት
- - 02. የሎድ ባላንስ አርክቴክቸር (L4 vs. L7 & ጤናማነት ማረጋገጫዎች)
- - 03. አውቶማቲክ ሚዛን ማስተካከያ እና የመለጠጥ ችሎታ
- - 04. ሰርቨር የለሽ (FaaS & Firecracker MicroVMs)

## ምዕራፎች

- 0:00 - የህንፃ ንድፍ ግድግዳ እና ዋና እቅድ
- 0:57 - 01. ቀጥ ያለ vs. አግድም ልኬት
- 2:17 - 02. የሎድ ባላንስ አርክቴክቸር (L4 vs. L7 & ጤናማነት ማረጋገጫዎች)
- 3:45 - 03. አውቶማቲክ ሚዛን ማስተካከያ እና የመለጠጥ ችሎታ
- 4:50 - 04. ሰርቨር የለሽ (FaaS & Firecracker MicroVMs)
- 6:05 - 05. በክስተት የሚመራ አርክቴክቸር (EDA & መለያየት)
- 7:13 - 06. ኮንቴይነር ኦርኬስትሬሽን (ዶከር & ኩበርኔትስ)
- 8:16 - 07. አራቱ የክላውድ ማከማቻ ምሰሶዎች (S3, EBS, DBs & ሬዲስ)
- 9:44 - 08. ከፍተኛ ተገኝነት እና ዘጠኞች (ባለብዙ AZ ምትኬ)
- 10:53 - 09. ዘላቂነት vs. ተገኝነት (ለምን 11 ዘጠኞች የስራ ጊዜ አይደለም)
- 12:14 - 10. መሠረተ ልማት እንደ ኮድ (Terraform vs. Console Drift)
- 13:20 - 11. ክላውድ ኔትወርኪንግ (VPC, Subnets, NAT & Security Groups)
- 14:26 - 12. የተሟላው የድርጅት እቅድ እና ብይን

## የተተረጎመ ግልባጭ

ከዋናው የእንግሊዝኛ ትረካ የተተረጎመ። የሚገኙ ኦዲዮ እና መግለጫ ጽሑፎች በYouTube ቁጥጥር ስር ናቸው።

### - የህንፃ ንድፍ ግድግዳ እና ዋና እቅድ

0:00 እያንዳንዱ የሶፍትዌር መሐንዲስ በመጨረሻ የክላውድ አርክቴክቸር ግድግዳ ይገጥመዋል። አፕሊኬሽንዎን በላፕቶፕዎ ላይ ይገነባሉ፣ ወደ ምርት ያስገቡታል፣ እና እውነተኛ ተጠቃሚዎች እንደመጡ፣ ሰርቨሮች ይበላሻሉ፣ የዳታቤዝ ግንኙነቶች ይወጣሉ፣ እና የእርስዎ AWS ሂሳብ እንደ ስልክ ቁጥር ይሆናል። አብዛኞቹ ገንቢዎች የክላውድ ምህንድስና ችግርን ለመፍታት በመቶዎች የሚቆጠሩ የተለያዩ የAWS ምርት ምህፃረ ቃላትን በማስታወስ ይሞክራሉ። ነገር ግን እውነተኛው የክላውድ ኮምፒዩቲንግ የሻጭ ካታሎጎችን ማስታወስ አይደለም፡ እሱ በአስራ አንድ መሰረታዊ የህንፃ ንድፍ መርሆዎች ላይ የተገነባ ነው።

0:34 በዚህ ማስተርክላስ፣ የተሟላውን የድርጅት እቅድ እናሳልፋለን፡ ከ ልኬት እና ሎድ ባላንስ እስከ ሰርቨር የለሽ፣ በክስተት የሚመራ መለያየት፣ ማከማቻ ተዋረዶች፣ እና የክላውድ ኔትወርኪንግ። እነዚህን አስራ አንድ ፅንሰ ሀሳቦች በመቆጣጠር፣ ማንኛውንም የኋላ-መጨረሻ በAWS ላይ GCP፣ ወይም Azure ላይ መንደፍ ይችላሉ። ይህ The Daily Diff ነው፣ ከመጋረጃው በታች።

### - 01. ቀጥ ያለ vs. አግድም ልኬት

0:57 ፅንሰ ሀሳብ ቁጥር አንድ፡ ልኬት። የእርስዎ መተግበሪያ የትራፊክ እድገት ሲያጋጥመው፣ ሎዱን ለመቋቋም መሰረታዊ የሆኑ ሁለት የተለያዩ መንገዶች አሉዎት፡ ቀጥ ያለ ልኬት፣ ወይም አግድም ልኬት። ቀጥ ያለ ልኬት፣ ወይም ወደ ላይ ማሳደግ፣ ማለት ያለዎትን ማሽን ወስዶ ተጨማሪ ሀብቶችን መጨመር ማለት ነው፡ ከአራት የሲፒዩ ኮሮች ወደ ሰላሳ ሁለት ማሻሻል፣ ወይም ሰላሳ ሁለት ጊጋባይት ራም መቶ ሃያ ስምንት ጊጋባይት መለወጥ። ቀጥ ያለ ልኬት ምንም አይነት የህንፃ ንድፍ ለውጦችን አይፈልግም፡ ኮድዎ

1:28 እና ዳታቤዝዎ በትክክል ተመሳሳይ ሆነው ይቆያሉ። ነገር ግን ከባድ የሃርድዌር ገደብ ይደርሳል። በዓለም ላይ አንድም ማሽን አስር ሺህ ሲፒዩ ኮሮች የሉትም፣ እና ከፍተኛ ደረጃ ያላቸው ምሳሌዎች ከፍተኛ የዋጋ ጭማሪ ይዘዋል። አግድም ልኬት፣ ወይም ወደ ውጭ ማሳደግ፣ ማለት ሰርቨሮችዎን ትንሽ እና በዋጋ ቆጣቢ ማድረግ፣ ነገር ግን በርካታ ምሳሌዎችን በትይዩ ከራውተር ጀርባ ማስኬድ ነው። አንድ ምሳሌ ከተበላሸ፣ ቀሪዎቹ ኖዶች ትራፊኩን ያለምንም የአገልግሎት መቋረጥ ይቀበላሉ። የአግድም ልኬት ወርቃማው ህግ

2:01 ሁኔታ-የለሽነት ነው፡ የእርስዎ አፕሊኬሽን ሰርቨሮች የተጠቃሚ ክፍለ ጊዜዎችን፣ የተሰቀሉ ፋይሎችን፣ ወይም ሁኔታን በአካባቢያዊ ዲስኮች ላይ ማከማቸት አይችሉም። ሁኔታው በውጫዊ ዳታቤዝ ወይም መሸጎጫ ውስጥ መኖር አለበት፣ ማንኛውም ኖድ ማንኛውንም የተጠቃሚ ጥያቄ እንዲያስተናግድ ያስችለዋል።

### - 02. የሎድ ባላንስ አርክቴክቸር (L4 vs. L7 & ጤናማነት ማረጋገጫዎች)

2:17 ፅንሰ ሀሳብ ቁጥር ሁለት፡ የሎድ ባላንስ። አግድም ልኬት በወረቀት ላይ ጥሩ ይመስላል፣ ነገር ግን ወዲያውኑ ችግር ያመጣል፡ አስር ሺህ ተጠቃሚዎች የጎራ ስምዎን ሲጎበኙ፣ የትኛው የተለየ ሰርቨር ትራፊካቸውን ይቀበላል? የሎድ ባላንስ እንደ ተገላቢጦሽ ፕሮክሲ በህዝባዊው ኢንተርኔት እና በግል የኋላ-መጨረሻ ክላስተርዎ መካከል ሆኖ ይሰራል። የገቢ TCP ወይም HTTP ግንኙነቶችን ይቀበላል እና ጥያቄዎችን በጤናማ ምሳሌዎችዎ ላይ ያሰራጫል።

2:47 የሎድ ባላንሰሮች በሁለት ዋና ዋና የአውታረ መረብ ንብርብሮች ይሰራሉ። Layer 4 Network Load Balancers በትራንስፖርት ንብርብር ይሰራሉ፣ ጥሬ TCP እና UDP ፓኬጆችን በአይፒ አድራሻ እና ወደብ መሰረት በማድረግ በማይክሮሰከንድ መዘግየት እና በሚሊዮኖች የሚቆጠሩ ጥያቄዎች በሰከንድ። Layer 7 Application Load Balancers የHTTP ፕሮቶኮልን ራሱን ይመረምራሉ፡ የዩአርኤል መንገዶችን፣ የጥያቄ ራስጌዎችን፣ ኩኪዎችን፣ እና HTTP ዘዴዎችን በማንበብ። ይህ መንገድ-ተኮር መረጣን ያስችላል፡ slash-api ጥያቄዎችን ወደ የኋላ-መጨረሻ ክላስተርዎ እና slash-static ጥያቄዎችን ወደ

3:25 ኦብጀክት ማከማቻ በመላክ። ከሁሉም በላይ፣ የሎድ ባላንሰሮች ንቁ ጤናማነት ማረጋገጫዎችን ያከናውናሉ። በየጥቂት ሰከንዶች፣ ባላንሰሩ በእያንዳንዱ ምሳሌ ላይ ያለውን የጤናማነት መግቢያ ይፈትሻል። አንድ ምሳሌ ሶስት ተከታታይ አምስት መቶ ስህተቶችን ከጣለ ወይም ምላሽ መስጠት ካልቻለ፣ ያለምንም የተቋረጡ ጥያቄዎች በራስ-ሰር ከመሰብሰቢያው ይወገዳል።

### - 03. አውቶማቲክ ሚዛን ማስተካከያ እና የመለጠጥ ችሎታ

3:45 ፅንሰ ሀሳብ ቁጥር ሶስት፡ አውቶማቲክ ሚዛን ማስተካከያ። የእርስዎ የድር መተግበሪያ ከጠዋቱ ሶስት ሰዓት ላይ ሁለት ሰርቨሮች የሚያስፈልገው ከሆነ፣ ነገር ግን እኩለ ቀን ማስጀመሪያ ላይ ሃያ ሰርቨሮች የሚያስፈልገው ከሆነ፣ በክላውድ ኮንሶል ውስጥ ቁልፎችን በእጅ ጠቅ ማድረግ የአገልግሎት መቋረጥ እና ኪሳራ የተረጋገጠ መንገድ ነው። አውቶማቲክ ሚዛን ማስተካከያ ተለዋዋጭ የመለጠጥ ችሎታን ለአግድም ሰርቨር ገንዳዎች ያመጣል። አንድ አውቶማቲክ ሚዛን ማስተካከያ ቡድን እንደ አማካይ የሲፒዩ አጠቃቀም፣ የአውታረ መረብ I-O፣ ወይም የጥበቃ ክምችት ጥልቀት ያሉ የአፈፃፀም መለኪያዎችን ይከታተላል። አማካይ ሲፒዩ የተወሰነ ገደብ ሲያልፍ — ለምሳሌ፣

4:19 ለሶስት ተከታታይ ደቂቃዎች ሰባ በመቶ — አውቶማቲክ ሚዛን ማስተካከያው በራስ-ሰር አዲስ ቨርቹዋል ማሽኖችን ያስጀምራል፣ ከሎድ ባላንስዎ ጋር ያስመዘግባቸዋል፣ እና ትራፊክን መምራት ይጀምራል። እኩል አስፈላጊ የሆነው መቀነስ ነው፡ የትራፊክ ማዕበሉ ሲቀንስ፣ አውቶማቲክ ሚዛን ማስተካከያው ከመጠን በላይ የሆኑ ምሳሌዎችን ያጠፋል ስለዚህ ለስራ ፈት ኮምፒዩቲንግ ክፍያ አይከፍሉም። መፈራረቅን ለመከላከል — ሰርቨሮች በፍጥነት የሚፈጠሩ እና በማያልቅ የድካም ዑደት ውስጥ የሚጠፉበት — የክላውድ አርክቴክቶች የማቀዝቀዣ ጊዜዎችን ያዋቅራሉ። ፅንሰ ሀሳብ ቁጥር አራት፡ ሰርቨር የለሽ።

### - 04. ሰርቨር የለሽ (FaaS & Firecracker MicroVMs)

4:53 ለዓመታት፣ የግብይት ቡድኖች ሰርቨር የለሽነትን እንደ አስማታዊ ኮድ በሰማይ ውስጥ እንደሚሰራ ሲያቀርቡ ነበር። በእውነቱ፣ ሰርቨር የለሽነት አሁንም ሰርቨሮችን ይጠቀማል — ግን እርስዎ አይይዙም፣ አይጠግኑም፣ ወይም ኮድ በማይሰራበት ጊዜ አይከፍሉም። እንደ AWS Lambda ወይም Google Cloud Functions ባሉ Functions-as-a-Service፣ ብቻውን የሚሰራ የሃንድለር ተግባር ይጽፋሉ። የHTTP ጥያቄ፣ የS3 ፋይል ሰቀላ፣ ወይም የዳታቤዝ ለውጥ ሲከሰት፣ የክላውድ የሩጫ ጊዜ ጊዜያዊ

5:23 ማይክሮ-ቨርቹዋል-ማሽን እንደ Firecracker ከአምስት ሚሊሰከንድ በታች ያስነሳል። ኮድዎ ይሰራል፣ ምላሽ ይመልሳል፣ እና ይዘጋል። ሶስት ወር ሙሉ ማንም ድር ጣቢያዎን ካልጎበኘ፣ የኮምፒዩቲንግ ሂሳብዎ በትክክል ዜሮ ዶላር እና ዜሮ ሳንቲም ነው። አንድ ሚሊዮን ተጠቃሚዎች በአንድ ጊዜ ቢጎበኙት፣ አቅራቢው አንድ ሚሊዮን በአንድ ጊዜ የሚሰሩ ማይክሮቪኤሞችን ያሽከረክራል። የምህንድስና ስምምነቶች እውን ናቸው፡ አዳዲስ የሩጫ ጊዜዎችን ሲያስነሱ የቅዝቃዜ መዘግየት፣ በ Lambda ላይ ያለው አስራ አምስት ደቂቃ ከፍተኛ የአፈፃፀም ገደብ፣ እና ጥብቅ ሁኔታ-የለሽነት።

5:55 ሰርቨር የለሽነት ለክስተት ቧንቧ መስመሮች እና አልፎ አልፎ ለሚገበሩ APIs ተወዳዳሪ የሌለው ነው፣ ነገር ግን ለቋሚ WebSockets ወይም ለበርካታ ሰዓታት ለሚወስዱ የሥልጠና ስራዎች ደካማ ነው።

### - 05. በክስተት የሚመራ አርክቴክቸር (EDA & መለያየት)

6:05 ፅንሰ ሀሳብ ቁጥር አምስት፡ በክስተት የሚመራ አርክቴክቸር፣ ወይም EDA። በባህላዊ አርክቴክቸሮች ውስጥ፣ አገልግሎቶች በአንድ ጊዜ ይገናኛሉ። የእርስዎ የክፍያ አገልግሎት ክፍያን ይጠራል፣ ክፍያ የዕቃ ክምችትን ይጠራል፣ የዕቃ ክምችት ማጭበርበርን ይጠራል፣ እና ማጭበርበር ኢሜይልን ይጠራል። ይህ የአንድ ጊዜ የመበላሸት ሰንሰለት ይፈጥራል። የሶስተኛ ወገን ኢሜይል አቅራቢ የአውታረ መረብ ችግር ካጋጠመው እና ምላሽ ለመስጠት አስር ሰከንድ ከወሰደ፣ የደንበኛዎ አጠቃላይ የክፍያ ጥያቄ ከስህተት ጋር ጊዜው ያልፍበታል። በክስተት በሚመራ አርክቴክቸር ውስጥ፣ አገልግሎቶች ሙሉ በሙሉ የተለዩ ናቸው።

6:37 ደንበኛ ሲገዛ፣ የክፍያ አገልግሎት ወደ ታች ያሉትን አገልግሎቶች አይጠራም። በቀላሉ OrderPlaced የሚባል ክስተት ወደ ማዕከላዊ የክስተት አውቶቡስ እንደ Amazon EventBridge ወይም የSNS ርዕስ ያትማል። ክፍያው በአምሳ ሚሊሰከንዶች ውስጥ ይጠናቀቃል። ለክፍያ፣ ለዕቃ ክምችት ቅናሽ፣ እና ለኢሜይል ደረሰኞች ያሉ ወደ ታች የሚሰሩ ስራዎች መልዕክቶችን በራሳቸው በተዘጋጁ የSQS ወረፋዎች ውስጥ በራሳቸው ያወጣሉ። የኢሜይል አገልግሎት ለአንድ ሰዓት ያህል ቢጠፋ፣ መልዕክቶች ያለምንም የተቋረጠ ትዕዛዝ በወረፋው ውስጥ በደህና ይጠብቃሉ።

### - 06. ኮንቴይነር ኦርኬስትሬሽን (ዶከር & ኩበርኔትስ)

7:13 ፅንሰ ሀሳብ ቁጥር ስድስት፡ የኮንቴይነር ኦርኬስትሬሽን። ዶከር ማሸግን ፈትቷል፡ የእርስዎን አፕሊኬሽን ኮድ፣ የስርዓት ቤተ-መጽሐፍት፣ ውቅር፣ እና የሩጫ ጊዜ ወደ የማይለወጥ ምስል ያጠቃልላል ይህም በMacBookዎ ላይ እና በክላውድ ውስጥ በትክክል ይሰራል። ነገር ግን ኮንቴይነርን ማሸግ ቀላል ነው። አምስት መቶ ኮንቴይነሮችን በአምሳ አካላዊ ቨርቹዋል ማሽኖች ላይ ማስኬድ ምህንድስና የሚበላሽበት ነው። ለዚህም ነው እንደ Kubernetes እና AWS ECS ያሉ የኮንቴይነር ኦርኬስትራዎች

7:41 ያሉ። አንድ ኦርኬስትራ የቁጥጥር ፓኔል ያቀርባል፡ የAPI ሰርቨር፣ የetcd ሁኔታ ማከማቻ፣ እና ብልህ የጊዜ ሠሌዳ አውጪ። የሚፈለገውን ሁኔታዎን ያውጃሉ፡ አስር የauth አገልግሎቴን ሪፕሊካዎች እያንዳንዳቸው ሁለት ጊጋባይት ራም እንዲኖራቸው እፈልጋለሁ። የጊዜ ሠሌዳ አውጪው ክላስተሩን ይመረምራል፣ ፖዶችን ባዶ ማህደረ ትውስታ ባላቸው ኖዶች ላይ ያስቀምጣል፣ ውስጣዊ ኔትወርኪንግን ያዋቅራል፣ እና እውነታውን ያለማቋረጥ ያስተካክላል። አንድ ኖድ የሃርድዌር ብልሽት ካጋጠመው፣ Kubernetes ኪሳራውን ይፈትሻል እና ወዲያውኑ የተፈናቀሉትን ፖዶች ሁሉ ወደ ጤናማ

### - 07. አራቱ የክላውድ ማከማቻ ምሰሶዎች (S3, EBS, DBs & ሬዲስ)

8:16 ኖዶች ያመጣል። ፅንሰ ሀሳብ ቁጥር ሰባት፡ የክላውድ ማከማቻ ተዋረድ። ጀማሪዎች ብዙውን ጊዜ የክላውድ ማከማቻን ፋይሎችን የሚጥሉበት አንድ ባልዲ አድርገው ይይዛሉ። በምርት አርክቴክቸር ውስጥ፣ ማከማቻ በአራት የተለያዩ ምሰሶዎች የተከፋፈለ ነው እንደ መዳረሻ መንገዶች እና መዘግየት። የመጀመሪያው የኦብጀክት ማከማቻ ነው፣ እንደ Amazon S3 ወይም Google Cloud ማከማቻ። ፋይሎችን በHTTP REST APIs በመጠቀም ቀላል PUT እና GET ጥሪዎችን ያገኛሉ። በወር በጊጋባይት ሁለት ሳንቲም ላይ ማለቂያ የሌለው አግድም አቅም ያቀርባል፣

8:49 ለቪዲዮ፣ የተጠቃሚ ሰቀላዎች፣ ምዝግቦች እና ምትኬዎች ተስማሚ ያደርገዋል። ሁለተኛው የብሎክ ማከማቻ ነው፣ እንደ Amazon EBS። እነዚህ በቀጥታ ከተወሰነ ቨርቹዋል ማሽን ጋር በከፍተኛ ፍጥነት በሚያገናኙት መረቦች ላይ የተጫኑ ቨርቹዋል ሃርድ ድራይቮች ናቸው። ወደ መደበኛ የፋይል ስርዓቶች እንደ ext4 ይቀረፃሉ፣ በዳታቤዝ ኢንጂኖች ለሚፈለገው ፈጣን የዘፈቀደ ንባብ እና ጽሑፍ መዳረሻ ድጋፍ ይሰጣሉ። ሶስተኛው የሚተዳደሩ ዳታቤዞች ናቸው፡ እንደ PostgreSQL በRDS ላይ ያሉ ሪላሽናል ኢንጂኖች ACID ግብይቶችን እና ውስብስብ ትስስሮችን የሚያቀርቡ፣

9:21 እና እንደ DynamoDB ያሉ NoSQL ኢንጂኖች በአንድ አሃዝ ሚሊሰከንድ መዘግየት በብዛት ያቀርባሉ። እና አራተኛው እንደ Redis ያሉ In-Memory Caches ናቸው። ከራም ዳታ ማንበብ ሚሊሰከንዶች ሳይሆን ማይክሮሰከንዶች ይወስዳል። መሸጎጫዎች ከዳታቤዝዎ ፊት ለፊት ተቀምጠው፣ ከድጋሚ ንባብ ትራፊክ ይጠብቁታል እና ተለዋዋጭ የተጠቃሚ ክፍለ ጊዜ ቶከኖችን ያስተዳድራሉ።

### - 08. ከፍተኛ ተገኝነት እና ዘጠኞች (ባለብዙ AZ ምትኬ)

9:44 ፅንሰ ሀሳብ ቁጥር ስምንት፡ ከፍተኛ ተገኝነት፣ ወይም HA። ተገኝነት ለአንድ ጥያቄ መልስ ይሰጣል፡ የእርስዎ አፕሊኬሽን ምን ያህል በመቶ የሚሆነውን ጊዜ ነው የሚሰራው እና በተጠቃሚዎች የሚደረስበት? በድርጅታዊ ኮንትራቶች ውስጥ፣ ተገኝነት በዘጠኞች ይለካል። ሁለት ዘጠኞች፣ ወይም ዘጠና ዘጠኝ በመቶ ተገኝነት፣ በየዓመቱ ከሶስት ተኩል ቀናት በላይ የአገልግሎት መቋረጥ ያስችላል። አራት ዘጠኞች የተፈቀደውን የአገልግሎት መቋረጥ ወደ ሃምሳ ሁለት ደቂቃዎች ይቀንሳል፣ እና አምስት ዘጠኞች በየዓመቱ አምስት ደቂቃ አጠቃላይ የአገልግሎት መቋረጥ ብቻ

10:15 ይፈቅዳል። ከፍተኛ ተገኝነትን ለማግኘት፣ በአደጋ ክልሎች ላይ ያሉ የውድቀት ነጠላ ነጥቦችን ማስወገድ አለብዎት። በክላውድ ውስጥ፣ ይህ ማለት በበርካታ ተገኝነት ዞኖች ላይ ማሰማራት ማለት ነው። የተገኝነት ዞን አንድ መደርደሪያ አይደለም፡ አንድ ወይም ከዚያ በላይ ልዩ አካላዊ የዳታ ማዕከሎች ማይሎች ተለያይተው በራሳቸው ሃይል እና ማቀዝቀዣ ናቸው። በዞን A እና ዞን B ውስጥ ንቁ ምሳሌዎችን በማመሳሰል የዳታቤዝ ሬፕሊኬሽን በማስኬድ፣ መብረቅ ወይም የፋይበር መቆራረጥ አጠቃላይ አካላዊ መገልገያውን የሚያበላሽ ከሆነ አውቶማቲክ ምትኬን ያስከትላል።

10:50 በሰላሳ ሰከንድ ውስጥ ያለ ምንም የሰው ጣልቃ ገብነት።

### - 09. ዘላቂነት vs. ተገኝነት (ለምን 11 ዘጠኞች የስራ ጊዜ አይደለም)

10:53 ፅንሰ-ሀሳብ ቁጥር ዘጠኝ፡ ጥንካሬ ከተገኝነት ጋር ሲነፃፀር። ይህ በክላውድ አርክቴክቸር ቃለመጠይቆች ውስጥ በጣም የተለመደው ፅንሰ-ሀሳባዊ ወጥመድ ነው። ኢንጂነሮች ቃላቶቹን በተደጋጋሚ በተለዋዋጭነት ይጠቀማሉ ነገር ግን ሙሉ በሙሉ የተለያዩ ባህሪያትን ይለካሉ። ተገኝነት የአፕታይምን ይለካል፡ አሁን መረጃዬን ለማንበብ ወይም ለመፃፍ የኤፒአይ ጥሪ ማድረግ እችላለሁን? የውሂብ ጥበቃን በዚህ ሰከንድ?። ጥንካሬ መረጃዬ ያለቋሚ የቢት መበስበስ፣ መበላሸት ወይም መጥፋት ለአስር አመታት ይቆያል ወይ? የሚለውን ይለካል። አሁን Amazon S3 Standardን ይመልከቱ።

11:24 Amazon S3 Standardን ይመልከቱ። የአገልግሎት ደረጃ ስምምነቱ ዘጠና ዘጠኝ ነጥብ ዘጠኝ በመቶ ተገኝነትን ይሰጣል፣ ይህም በየወሩ ወደ አርባ ሶስት ደቂቃ የሚጠጋ የእረፍት ጊዜን ይፈቅዳል የኤፒአይ ጥያቄ አምስት መቶ ስህተት ሊመልስ በሚችልበት። ነገር ግን S3 የአስራ አንድ ዘጠኝ ጥንካሬን ቃል ገብቷል፡ ዘጠና ዘጠኝ ነጥብ ዘጠኝ ዘጠኝ ዘጠኝ ዘጠኝ ዘጠኝ ዘጠኝ ዘጠኝ ዘጠኝ በመቶ። አስር ሚሊዮን ፋይሎችን በ S3 ውስጥ ካስቀመጡ፣ በስታቲስቲክስ በአስር ሺህ አመት አንድ ፋይል ይጠፋል ብለው መጠበቅ ይችላሉ።

11:56 በአማካይ በየአስር ሺህ ዓመቱ አንድ ፋይል የማጣት ስታቲስቲካዊ ዕድል ይኖራል። S3 ይህንን የሚያሳካው ነገሮችን በማጥፋት-ኮድ በማድረግ እና ቁርጥራጮችን ቢያንስ ሶስት ጂኦግራፊያዊ የተለያየ የመረጃ ማከማቻዎች ላይ በማባዛት ነው። ቢያንስ ሶስት ጂኦግራፊያዊ በተለያዩ የውሂብ ተቋማት ውስጥ ክፍሎችን በማባዛት ነው። በትልቅ የክልል የአውታረ መረብ መቆራረጥ ወቅት S3 ለጊዜው ላይገኝ ይችላል፣ ነገር ግን የእርስዎ ውሂብ በፍፁም አይጠፋም።

### - 10. መሠረተ ልማት እንደ ኮድ (Terraform vs. Console Drift)

12:14 ፅንሰ-ሀሳብ ቁጥር አስር፡ Infrastructure as Code, ወይም IaC። በክላውድ ኮምፒዩቲንግ የመጀመሪያ ቀናት ውስጥ፣ ኢንጂነሮች ወደ AWS ገብተው ነበር የድር አስተዳደር ኮንሶልን በመጠቀም በእጅ በመንካት ቨርቹዋል ማሽኖችን፣ ንዑስ መረቦችን ለማዋቀር እና የደህንነት ቡድኖችን ለማያያዝ። ኢንዱስትሪው ይህንን ClickOps ብሎ ይጠራዋል፣ እና በምርት ውስጥ፣ ፍፁም አደጋ ነው። በእጅ የሚደረጉ የኮንሶል ለውጦች የኦዲት ዱካ የላቸውም፣ የዳግም ማስጀመሪያ ዘዴ የላቸውም፣ እና በእርግጠኝነት በቅድመ-ምርት እና ምርት አካባቢዎች መካከል የቅንብሮች ልዩነትን ያስከትላሉ። በInfrastructure

12:48 እንደ ኮድ መሳሪያዎች እንደ Terraform, OpenTofu, Pulumi, ወይም AWS CDK, የእርስዎን አጠቃላይ የክላውድ አርክቴክቸር በ Git ውስጥ በተከማቹ ገላጭ የቅንብር ፋይሎች ውስጥ ይገልፃሉ። በ Git ውስጥ በተከማቹ ገላጭ የቅንብር ፋይሎች ውስጥ የእርስዎን አጠቃላይ የክላውድ አርክቴክቸር ይገልፃሉ። በተከፈተ ፖርት ወይም የውሂብ ጎታ ቅጂ ላይ የሚደረግ እያንዳንዱ ለውጥ በፑል ጥያቄ እና በእኩዮች ግምገማ ያልፋል። የፑል ጥያቄ እና የፒር ግምገማ ውስጥ ያልፋል። terraform planን ማስኬድ ምንም ነገር ከመነካቱ በፊት ትክክለኛውን የኤፒአይ ልዩነት ቅድመ እይታ ያሳያል፣ እና የእርስዎን የምርት ስብስብ ተመሳሳይ ቅጂ ማሽከርከር ከአራት ሳምንታት ይልቅ አራት ደቂቃዎችን ይወስዳል። ቁልል ከአራት ሳምንታት ይልቅ አራት ደቂቃዎችን ይወስዳል።

### - 11. ክላውድ ኔትወርኪንግ (VPC, Subnets, NAT & Security Groups)

13:20 ፅንሰ-ሀሳብ ቁጥር አስራ አንድ፡ የክላውድ ኔትወርኪንግ እና ቨርቹዋል የግል ክላውዶች። ሰርቨሮችን ወደ ክላውድ ሲያስገቡ፣ በጥሬው የህዝብ ኢንተርኔት ላይ ክፍት ሆነው አይቀመጡም። በVPC በሚባል ሶፍትዌር-የተገለጸ ገለልተኛ ወሰን ውስጥ ይኖራሉ። VPC በሚባል ገለልተኛ ሶፍትዌር-የተገለጸ ወሰን ውስጥ ይኖራሉ። በVPCዎ ውስጥ፣ እንደ አስር-ነጥብ-ዜሮ-ነጥብ-ዜሮ-ነጥብ-ዜሮ ስላሽ አስራ ስድስት ያለ የግል አይፒ አድራሻ ቦታ ይመድባሉ፣ እና ወደ የህዝብ እና የግል ንዑስ መረቦች ይከፋፈሉት። ወደ የህዝብ እና የግል ንዑስ መረቦች ይከፋፈሉት። የህዝብ ንዑስ መረብ ወደ ኢንተርኔት ጌትዌይ ቀጥተኛ መንገድ አለው።

13:51 እንደ የእርስዎ አፕሊኬሽን ሎድ ባላንሰሮች እና NAT ጌትዌይስ ያሉ ይፋዊ ሀብቶችን ይዟል። ይፋዊ የአይፒ አድራሻዎች ያለው የኔትወርክዎ ብቸኛ ክፍል ነው። የእርስዎ የመተግበሪያ ሰርቨሮች እና የምርት ዳታቤዝዎች በጥብቅ የሚኖሩት በግል ንዑስ መረቦች ውስጥ ነው ምንም ይፋዊ አይፒዎች እና ከኢንተርኔት ምንም የገቢ መንገዶች የሉትም። የእርስዎ የኋላ ጫፍ ሰርቨሮች የደህንነት ዝመናዎችን ማውረድ ሲፈልጉ፣ የእነሱ ወጪ ትራፊክ በሕዝብ ንዑስ መረብ ውስጥ ባለው የNAT ጌትዌይ በኩል ያልፋል። እያንዳንዱን ምሳሌ የሚከቡት የደህንነት ቡድኖች ናቸው፡ የጥቂት መብት መርህን የሚያስፈጽሙ ሁኔታዊ ቨርቹዋል ፋየርዎሎች። የጥቂት መብት መርህን የሚያስፈጽሙ ቨርቹዋል ፋየርዎሎች።

### - 12. የተሟላው የድርጅት እቅድ እና ብይን

14:28 የእርስዎ የውሂብ ጎታ የደህንነት ቡድን ግንኙነቶችን በፖርት 5432 ላይ ብቻ ይቀበላል የእርስዎ የመተግበሪያ አገልጋዮች የደህንነት ቡድን ብቻ፣ ይህም ከውጭ ዘልቆ መግባት የሂሳብ ስሌት የማይቻል ያደርገዋል። ከውጭ ዘልቆ መግባት በሂሳብ ስሌት የማይቻል ያደርገዋል። ወደ ኋላ ስታስፋፉ፣ እነዚህ አስራ አንድ የመጀመሪያ ደረጃዎች ወደ አንድ ወጥ ስርዓት ይገናኛሉ። የእርስዎ DNS በሕዝብ ንዑስ መረብ ውስጥ ወደ ሎድ ባላንሰር ይመራል። ራስ-ሰር ሚዛን ቡድኖች በበርካታ ተገኝነት ዞኖች ላይ የትራፊክ መጨመርን ይቆጣጠራሉ፣ የክስተት አውቶቡሶች የኋላ ጫፍ ሰራተኞችን ይለያያሉ፣ እና የእርስዎ አጠቃላይ ስብስብ Infrastructure as Codeን በመጠቀም ከ Git የተዘረጋ ነው።

15:02 የዛሬው ማስተር ክላስ ፍርድ፡ SHIP IT። በመቶዎች የሚቆጠሩ የክላውድ ግብይት አህጽሮተ ቃላትን ማስታወስ አቁም። እነዚህን አስራ አንድ የአርክቴክቸር ቅጦች ይቆጣጠሩ፣ ሁኔታዎን ይለዩ፣ እና ሊሳኩ የማይችሉ ስርዓቶችን ይገንቡ። ለመጀመሪያ ጊዜ መገንባት ሲጀምሩ የትኛው የክላውድ ጽንሰ-ሀሳብ ትልቁን ራስ ምታት እንደሰጠዎት በአስተያየቶቹ ውስጥ ይንገሩኝ። በአስተያየቶቹ ውስጥ ለመገንባት ጀመሩ። እና የተሟላውን የአርክቴክቸር ማጭበርበሪያ ወረቀት ለማግኘት፣ ለዜና መጽሔቱ በ the daily diff dot dev ይመዝገቡ፣

15:28 ከታች ያለው አገናኝ። እና የዛሬው ልዩነት ይህ ነው። እኔ ከ Axrisi የመጣው ኒኮ ነኝ። በኃላፊነት ስሜት ያዋህዱ።

## ምንጮች

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io