คำอธิบายคลาวด์คอมพิวติ้ง: 11 แนวคิดทางสถาปัตยกรรมที่คุณต้องรู้ (4K Masterclass)

วิดีโอนี้ครอบคลุมอะไรบ้าง

• - กำแพงสถาปัตยกรรมและแผนผังหลัก
• - 01. การปรับขนาดในแนวตั้งเทียบกับแนวราบ
• - 02. สถาปัตยกรรม Load Balancing (L4 เทียบกับ L7 และ Health Checks)
• - 03. Autoscaling และ Elasticity
• - 04. Serverless (FaaS และ Firecracker MicroVMs)

บทถอดเสียงที่แปลแล้ว

แปลจากการบรรยายภาษาอังกฤษต้นฉบับ เสียงและคำบรรยายที่มีให้จะควบคุมโดย YouTube

- กำแพงสถาปัตยกรรมและแผนผังหลัก

0:00 วิศวกรซอฟต์แวร์ทุกคนต้องเผชิญกับกำแพงสถาปัตยกรรมคลาวด์ในที่สุด คุณสร้างแอปพลิเคชันบนแล็ปท็อปของคุณ ผลักดันไปยังการใช้งานจริง และเมื่อผู้ใช้จริงเข้ามา เซิร์ฟเวอร์ก็ล่ม การเชื่อมต่อฐานข้อมูลก็เต็ม และบิล AWS ของคุณก็ดูเหมือนเบอร์โทรศัพท์ นักพัฒนาส่วนใหญ่พยายามแก้ปัญหาการพัฒนาคลาวด์โดยการท่องจำ ตัวย่อผลิตภัณฑ์ AWS ที่แตกต่างกันสามร้อยรายการ แต่การประมวลผลบนคลาวด์ที่แท้จริงไม่ใช่การท่องจำแคตตาล็อกของผู้จำหน่าย: มันสร้างขึ้นบนหลักการทางสถาปัตยกรรมพื้นฐานสิบเอ็ดประการ

0:34 ในมาสเตอร์คลาสนี้ เราจะเดินผ่านพิมพ์เขียวองค์กรทั้งหมด: ตั้งแต่ การปรับขนาดและการโหลดบาลานซ์ไปจนถึงเซิร์ฟเวอร์ไร้เซิร์ฟเวอร์ การแยกส่วนที่ขับเคลื่อนด้วยเหตุการณ์ ลำดับชั้นการจัดเก็บข้อมูล และเครือข่ายคลาวด์ เชี่ยวชาญแนวคิดทั้งสิบเอ็ดนี้ และคุณสามารถออกแบบแบ็กเอนด์ใดก็ได้บน AWS GCP หรือ Azure นี่คือ The Daily Diff เบื้องหลัง

- 01. การปรับขนาดในแนวตั้งเทียบกับแนวราบ

0:57 แนวคิดที่หนึ่ง: การปรับขนาด เมื่อแอปพลิเคชันของคุณมีการเติบโตของการรับส่งข้อมูล คุณมีสองวิธีที่แตกต่างกันโดยพื้นฐาน ในการจัดการโหลด: การปรับขนาดในแนวตั้ง หรือการปรับขนาดในแนวราบ การปรับขนาดในแนวตั้ง หรือการปรับเพิ่ม หมายถึงการนำเครื่องที่มีอยู่ของคุณ และเพิ่มทรัพยากร: อัปเกรดจาก 4 คอร์ CPU เป็น 32 หรือเปลี่ยน RAM ขนาด 32 กิกะไบต์เป็น 128 การปรับขนาดในแนวตั้งไม่จำเป็นต้องมีการเปลี่ยนแปลงสถาปัตยกรรมใดๆ: โค้ดของคุณ

1:28 และฐานข้อมูลยังคงเหมือนเดิมทุกประการ แต่มันชนเพดานฮาร์ดแวร์ที่รุนแรง ไม่มีเครื่องเดียวในโลกที่มีคอร์ CPU หนึ่งหมื่นคอร์ และอินสแตนซ์ระดับสูงสุดมีค่าพรีเมียมในราคาที่เพิ่มขึ้นเป็นทวีคูณ การปรับขนาดในแนวราบ หรือการปรับขยาย หมายถึงการรักษาเซิร์ฟเวอร์ของคุณให้ มีขนาดเล็กและมีราคาที่เหมาะสม แต่รันหลายอินสแตนซ์พร้อมกันอยู่เบื้องหลัง เราเตอร์ หากอินสแตนซ์หนึ่งล่ม โหนดที่เหลือจะดูดซับการรับส่งข้อมูลโดยไม่มี การหยุดทำงาน การปรับขนาดในแนวราบมีกฎทองคือ

2:01 statelessness: เซิร์ฟเวอร์แอปพลิเคชันของคุณไม่สามารถจัดเก็บเซสชันผู้ใช้ ไฟล์ที่อัปโหลด หรือสถานะบนดิสก์ภายในเครื่องได้ สถานะต้องอยู่ในฐานข้อมูลภายนอกหรือแคช ซึ่งทำให้โหนดใดก็ได้สามารถจัดการคำขอของผู้ใช้ใดก็ได้

- 02. สถาปัตยกรรม Load Balancing (L4 เทียบกับ L7 และ Health Checks)

2:17 แนวคิดที่สอง: Load Balancing การปรับขนาดในแนวราบฟังดูดีบนกระดาษ แต่มันนำมาซึ่งปัญหาทันที: เมื่อผู้ใช้หนึ่งหมื่นคนเข้าถึงชื่อโดเมนของคุณ เซิร์ฟเวอร์เฉพาะไหนที่จะรับการรับส่งข้อมูลของพวกเขา? Load Balancer ทำหน้าที่เป็น Reverse Proxy ที่อยู่ระหว่างอินเทอร์เน็ตสาธารณะ และคลัสเตอร์แบ็กเอนด์ส่วนตัวของคุณ มันยอมรับการเชื่อมต่อ TCP หรือ HTTP ที่เข้ามา และ กระจายคำขอไปยังอินสแตนซ์ที่ทำงานได้ของคุณ

2:47 Load Balancer ทำงานที่สองชั้นเครือข่ายหลัก Layer 4 Network Load Balancer ทำงานที่ชั้นขนส่ง เราเตอร์แพ็กเก็ต TCP และ UDP ดิบตามที่อยู่ IP และพอร์ต ด้วยความหน่วงเวลาไมโครวินาทีและคำขอหลายล้านครั้งต่อวินาที Layer 7 Application Load Balancer ตรวจสอบโปรโตคอล HTTP ด้วยตัวเอง: อ่านพาธ URL, ส่วนหัวคำขอ, คุกกี้ และวิธีการ HTTP สิ่งนี้ทำให้สามารถกำหนดเส้นทางตามพาธได้: ส่งคำขอ slash-api ไปยังคลัสเตอร์แบ็กเอนด์ของคุณ และคำขอ slash-static ไปยัง

3:25 ออบเจกต์สโตร์ ที่สำคัญ Load Balancer ทำการตรวจสอบสุขภาพแบบแอคทีฟ ทุกๆ สองสามวินาที Balancer จะส่ง ping ไปยังจุดสิ้นสุดสุขภาพของแต่ละ อินสแตนซ์ หากอินสแตนซ์ส่งข้อผิดพลาด 500 ติดต่อกันสามครั้ง หรือ ไม่ตอบสนอง มันจะถูกนำออกจากพูลโดยอัตโนมัติโดยไม่มี คำขอที่ถูกทิ้งใดๆ

- 03. Autoscaling และ Elasticity

3:45 แนวคิดที่สาม: Autoscaling หากเว็บแอปของคุณต้องการเซิร์ฟเวอร์สองเครื่องตอนตีสาม แต่ต้องการเซิร์ฟเวอร์ยี่สิบเครื่องระหว่างการเปิดตัวตอนกลางวัน การคลิกปุ่มด้วยตนเองใน คอนโซลคลาวด์รับประกันว่าจะนำไปสู่การหยุดทำงานและการล้มละลาย Autoscaling นำความยืดหยุ่นแบบไดนามิกมาสู่พูลเซิร์ฟเวอร์แนวนอน Auto Scaling Group ตรวจสอบเมตริกประสิทธิภาพ เช่น ค่าเฉลี่ย การใช้ CPU, I-O เครือข่าย หรือความลึกของคิวที่ค้างอยู่ เมื่อค่าเฉลี่ย CPU เกินเกณฑ์ที่กำหนด — เช่น

4:19 เจ็ดสิบเปอร์เซ็นต์เป็นเวลาสามนาทีติดต่อกัน — Autoscaler จะเปิดใช้งาน เครื่องเสมือนใหม่โดยอัตโนมัติ ลงทะเบียนกับ Load Balancer ของคุณ และเริ่มกำหนดเส้นทางการรับส่งข้อมูล สิ่งสำคัญเท่าเทียมกันคือการปรับขนาดลง: เมื่อคลื่นการรับส่งข้อมูลลดลง Autoscaler จะยุติอินสแตนซ์ส่วนเกินเพื่อให้คุณหยุดจ่ายเงินสำหรับ การประมวลผลที่ไม่ได้ใช้งาน เพื่อป้องกันการสั่นไหว — ซึ่งเซิร์ฟเวอร์ถูกสร้างและ ถูกทำลายอย่างรวดเร็วในวงจรที่ไม่สิ้นสุด — สถาปนิกคลาวด์กำหนดค่า ช่วงเวลา Cooldown แนวคิดที่สี่: Serverless

- 04. Serverless (FaaS และ Firecracker MicroVMs)

4:53 เป็นเวลาหลายปีที่ทีมการตลาดนำเสนอ Serverless ว่าเป็นโค้ดวิเศษ ที่ทำงานบนฟ้า ในความเป็นจริง Serverless ยังคงใช้เซิร์ฟเวอร์ — แต่คุณไม่ได้เป็นเจ้าของ แพทช์ หรือจ่ายเงินสำหรับมันเมื่อไม่มีโค้ดทำงาน ด้วย Function-as-a-Service เช่น AWS Lambda หรือ Google Cloud Functions คุณเขียนฟังก์ชันตัวจัดการแบบสแตนด์อะโลน เมื่อมีคำขอ HTTP, การอัปโหลดไฟล์ S3 หรือการเปลี่ยนแปลงฐานข้อมูล เกิดขึ้น รันไทม์คลาวด์จะบูตเครื่อง

5:23 ไมโครเวอร์ชวลแมชชีนชั่วคราว เช่น Firecracker ภายในห้ามิลลิวินาที โค้ดของคุณจะทำงาน ส่งคืนการตอบสนอง และปิดตัวลง หากไม่มีใครเข้าชมเว็บไซต์ของคุณเป็นเวลาสามเดือน บิลค่าคอมพิวเตอร์ของคุณจะเป็น ศูนย์ดอลลาร์และศูนย์เซนต์ หากผู้ใช้หนึ่งล้านคนเข้าชมพร้อมกัน ผู้ให้บริการจะเปิดใช้งานหนึ่งล้าน ไมโครVM พร้อมกัน ข้อดีข้อเสียทางวิศวกรรมนั้นเป็นของจริง: ความหน่วงเวลา Cold Start เมื่อเปิดรันไทม์ใหม่ ข้อจำกัดการทำงานที่เข้มงวดสิบห้านาที บน Lambda และ Statelessness ที่เข้มงวด

5:55 Serverless นั้นไร้เทียมทานสำหรับ Event Pipelines และ API ที่เป็นระยะๆ แต่ไม่ดีสำหรับ WebSockets ที่คงทนหรือการรันการฝึกอบรมหลายชั่วโมง

- 05. สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA และ Decoupling)

6:05 แนวคิดที่ห้า: สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ หรือ EDA ในสถาปัตยกรรมดั้งเดิม บริการสื่อสารกันแบบ Synchronous บริการ Checkout เรียก Payment, Payment เรียก Inventory, Inventory เรียก Fraud และ Fraud เรียก Email สิ่งนี้สร้างน้ำตก Synchronous แห่งหายนะ หากผู้ให้บริการอีเมลภายนอกประสบปัญหาเครือข่ายและใช้เวลาสิบ วินาทีในการตอบสนอง คำขอ Checkout ทั้งหมดของลูกค้าของคุณจะหมดเวลาด้วย ข้อผิดพลาด ในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ บริการต่างๆ จะถูกแยกออกจากกันอย่างสมบูรณ์

6:37 เมื่อลูกค้าคลิกซื้อ บริการ Checkout จะไม่เรียกบริการ Downstream แต่จะเผยแพร่เหตุการณ์ที่เรียกว่า OrderPlaced ไปยัง Event Bus ส่วนกลาง เช่น Amazon EventBridge หรือหัวข้อ SNS การ Checkout เสร็จสมบูรณ์ภายในห้าสิบมิลลิวินาที Worker Downstream สำหรับการชำระเงิน การหักสินค้าคงคลัง และใบเสร็จรับเงินทางอีเมล ดึงข้อความอย่างอิสระจากคิว SQS เฉพาะของตนเอง หากบริการอีเมลล่มเป็นเวลาหนึ่งชั่วโมง ข้อความจะรออย่างปลอดภัย บัฟเฟอร์ในคิวโดยไม่มีคำสั่งซื้อที่ถูกทิ้งแม้แต่รายการเดียว

- 06. การจัดเรียงคอนเทนเนอร์ (Docker และ Kubernetes)

7:13 แนวคิดที่หก: การจัดเรียงคอนเทนเนอร์ Docker แก้ปัญหาการแพ็คเกจ: มันห่อหุ้มโค้ดแอปพลิเคชันของคุณ ไลบรารีระบบ การกำหนดค่า และรันไทม์ไว้ในอิมเมจที่ไม่สามารถเปลี่ยนแปลงได้ ซึ่งทำงานเหมือนกันบน MacBook ของคุณและบนคลาวด์ แต่การแพ็คเกจคอนเทนเนอร์นั้นง่าย การรันคอนเทนเนอร์ห้าร้อยคอนเทนเนอร์บนเครื่องเสมือนจริงห้าสิบเครื่องคือจุดที่ วิศวกรรมพังทลาย นั่นคือเหตุผลที่ Container Orchestrator เช่น Kubernetes และ AWS ECS

7:41 มีอยู่ Orchestrator มี Control Plane: เซิร์ฟเวอร์ API ที่เก็บสถานะ etcd และตัวกำหนดตารางเวลาอัจฉริยะ คุณประกาศสถานะที่ต้องการ: ฉันต้องการสำเนาสิบชุดของบริการตรวจสอบสิทธิ์ของฉัน แต่ละชุดมี RAM สองกิกะไบต์ ตัวกำหนดตารางเวลาจะตรวจสอบคลัสเตอร์ วาง Pod บนโหนดที่มีหน่วยความจำว่าง กำหนดค่าเครือข่ายภายใน และปรับปรุงความเป็นจริงอย่างต่อเนื่อง หากโหนดประสบความล้มเหลวของฮาร์ดแวร์ Kubernetes จะตรวจจับ การสูญเสียและกำหนดตารางเวลา Pod ที่ถูกแทนที่ทั้งหมดใหม่ทันที

- 07. สี่เสาหลักของการจัดเก็บข้อมูลบนคลาวด์ (S3, EBS, DBs และ Redis)

8:16 ไปยังโหนดที่ทำงานได้ดี แนวคิดที่เจ็ด: ลำดับชั้นการจัดเก็บข้อมูลบนคลาวด์ ผู้เริ่มต้นมักจะมองว่าพื้นที่เก็บข้อมูลบนคลาวด์เป็นถังเดียวที่คุณทิ้ง ไฟล์ ในสถาปัตยกรรมที่ใช้งานจริง พื้นที่เก็บข้อมูลแบ่งออกเป็นสี่เสาหลักที่แตกต่างกัน โดยพิจารณาจากรูปแบบการเข้าถึงและความหน่วงเวลา อันดับแรกคือ Object Storage เช่น Amazon S3 หรือ Google Cloud Storage คุณเข้าถึงไฟล์ผ่าน HTTP REST APIs โดยใช้ การเรียก PUT และ GET แบบง่ายๆ มีความจุแนวนอนไม่จำกัดที่สองเซ็นต์ต่อกิกะไบต์ต่อเดือน

8:49 เหมาะสำหรับวิดีโอ การอัปโหลดของผู้ใช้ บันทึก และการสำรองข้อมูล อันดับที่สองคือ Block Storage เช่น Amazon EBS สิ่งเหล่านี้คือฮาร์ดไดรฟ์เสมือนที่ติดตั้งโดยตรงกับเครื่องเสมือนเฉพาะ ผ่านการเชื่อมต่อความเร็วสูง พวกมันจัดรูปแบบเป็นระบบไฟล์มาตรฐานเช่น ext4 รองรับการเข้าถึงแบบสุ่มที่รวดเร็วในการอ่านและเขียนที่จำเป็นสำหรับเครื่องมือฐานข้อมูล อันดับที่สามคือ Managed Databases: เครื่องมือเชิงสัมพันธ์เช่น PostgreSQL บน RDS ที่ให้บริการ ACID Transactions และ Join ที่ซับซ้อน

9:21 และเครื่องมือ NoSQL เช่น DynamoDB ที่ส่งมอบความหน่วงเวลาเพียงหลักเดียว มิลลิวินาทีในขนาดใหญ่ และอันดับที่สี่คือ In-Memory Caches เช่น Redis การอ่านข้อมูลจาก RAM ใช้เวลาไมโครวินาทีมากกว่ามิลลิวินาที แคชจะอยู่หน้าฐานข้อมูลของคุณ ปกป้องมันจากการรับส่งข้อมูลการอ่านซ้ำๆ และจัดการโทเค็นเซสชันผู้ใช้ที่ไม่แน่นอน

- 08. ความพร้อมใช้งานสูงและการคงทน (การเฟลโอเวอร์หลายโซนความพร้อมใช้งาน)

9:44 แนวคิดที่แปด: High Availability หรือ HA Availability ตอบคำถามเดียว: กี่เปอร์เซ็นต์ของเวลาที่แอปพลิเคชันของคุณ ทำงานและผู้ใช้เข้าถึงได้? ในสัญญาองค์กร ความพร้อมใช้งานจะวัดเป็น Nines Two Nines หรือความพร้อมใช้งาน 99 เปอร์เซ็นต์ อนุญาตให้มีการหยุดทำงานมากกว่าสามวันครึ่ง ในแต่ละปี Four Nines ลดเวลาหยุดทำงานที่อนุญาตเหลือ 52 นาที และ Five Nines อนุญาตให้มีเวลาหยุดทำงานรวมเพียงห้านาทีต่อ

10:15 ปี เพื่อให้มีความพร้อมใช้งานสูง คุณต้องกำจัดจุดเดียวที่ล้มเหลว ในโดเมนความผิดพลาดต่างๆ ในคลาวด์ นั่นหมายถึงการติดตั้งใช้งานในหลาย Availability Zones Availability Zone ไม่ใช่แร็คเดียว: มันคือศูนย์ข้อมูลทางกายภาพที่แตกต่างกันอย่างน้อยหนึ่งแห่ง ที่อยู่ห่างกันหลายไมล์พร้อมพลังงานและความเย็นที่เป็นอิสระ โดยการรันอินสแตนซ์ที่ทำงานอยู่ใน Zone A และ Zone B ด้วยการจำลองฐานข้อมูลแบบ Synchronous การถูกฟ้าผ่าหรือสายเคเบิลขาดที่ทำให้ สถานที่ทางกายภาพทั้งหมดล่มส่งผลให้เกิดการเฟลโอเวอร์อัตโนมัติ

10:50 ในสามสิบวินาทีโดยไม่ต้องมีการแทรกแซงจากมนุษย์

- 09. ความคงทนเทียบกับความพร้อมใช้งาน (เหตุใด 11 Nines จึงไม่ใช่ Uptime)

10:53 แนวคิดที่เก้า: ความทนทานกับความพร้อมใช้งาน นี่คือกับดักทางแนวคิดที่พบบ่อยที่สุดในการสัมภาษณ์เกี่ยวกับสถาปัตยกรรมคลาวด์ วิศวกรใช้คำเหล่านี้สลับกันบ่อยครั้ง แต่พวกเขาวัดคุณสมบัติที่แตกต่างกันอย่างสิ้นเชิง ความพร้อมใช้งานวัดระยะเวลาที่ระบบทำงาน: ฉันสามารถเรียกใช้ API เพื่ออ่านหรือเขียนข้อมูลของฉันได้หรือไม่ ในตอนนี้? ความทนทานวัดการรักษา: ข้อมูลของฉันจะอยู่รอดได้โดยไม่มีข้อมูลเสียหาย ถอดรหัส หรือถูกทำลายอย่างถาวรเป็นเวลาสิบปีหรือไม่? ข้อมูลเสียหาย ถอดรหัส หรือถูกทำลายอย่างถาวรเป็นเวลาสิบปีหรือไม่?

11:24 ลองดู Amazon S3 Standard ข้อตกลงระดับบริการของ Amazon S3 Standard มีความพร้อมใช้งานเก้าสิบเก้าจุดเก้าเปอร์เซ็นต์ ซึ่งอนุญาตให้มีเวลาหยุดทำงานประมาณสี่สิบสามนาทีในแต่ละเดือน ที่คำขอ API อาจส่งคืนข้อผิดพลาดห้าร้อย แต่ S3 ให้คำมั่นถึงความทนทานสิบเอ็ดเก้า: เก้าสิบเก้า จุดเก้าเก้าเก้าเก้าเก้าเก้าเก้า เก้าเก้าเปอร์เซ็นต์ หากคุณจัดเก็บไฟล์สิบล้านไฟล์ใน S3 คุณสามารถคาดการณ์ทางสถิติว่าจะสูญเสียไฟล์โดยเฉลี่ยหนึ่งไฟล์ทุกๆ หนึ่งหมื่นปี

11:56 เฉลี่ยหนึ่งไฟล์ทุกๆ หนึ่งหมื่นปี S3 บรรลุเป้าหมายนี้โดยการเข้ารหัสวัตถุด้วยการลบและการจำลองส่วนต่างๆ ใน อย่างน้อยสามศูนย์ข้อมูลที่แยกจากกันทางภูมิศาสตร์ ในระหว่างการหยุดชะงักของเครือข่ายภูมิภาคที่สำคัญ S3 อาจไม่พร้อมใช้งานชั่วคราว แต่ข้อมูลของคุณจะไม่ถูกทำลาย

- 10. โครงสร้างพื้นฐานเป็นโค้ด (Terraform เทียบกับ Console Drift)

12:14 แนวคิดที่สิบ: โครงสร้างพื้นฐานเป็นรหัส หรือ IaC ในช่วงแรกๆ ของคลาวด์คอมพิวติ้ง วิศวกรได้เข้าสู่ระบบ AWS คอนโซลการจัดการบนเว็บและคลิกด้วยตนเองเพื่อสร้างเครื่องเสมือน กำหนดค่าซับเน็ต และแนบกลุ่มความปลอดภัย อุตสาหกรรมเรียกสิ่งนี้ว่า ClickOps และในการผลิต มันเป็นหายนะอย่างแท้จริง การเปลี่ยนแปลงคอนโซลด้วยตนเองไม่มีบันทึกการตรวจสอบ ไม่มีกลไกการย้อนกลับ และหลีกเลี่ยงไม่ได้ที่จะทำให้เกิดความคลาดเคลื่อนในการกำหนดค่าระหว่างสภาพแวดล้อมการจัดเตรียมและ สภาพแวดล้อมการผลิต ด้วยเครื่องมือ Infrastructure as Code

12:48 เช่น Terraform OpenTofu, Pulumi หรือ AWS CDK คุณกำหนดสถาปัตยกรรมคลาวด์ทั้งหมดของคุณ ในไฟล์การกำหนดค่าเชิงประกาศที่จัดเก็บไว้ใน Git ทุกการเปลี่ยนแปลงพอร์ตที่เปิดหรือฐานข้อมูลจำลองจะผ่าน คำขอดึงและตรวจสอบโดยเพื่อนร่วมงาน การรัน terraform plan จะแสดงตัวอย่าง API diff ที่แม่นยำก่อน มีการแตะต้องสิ่งใด และการสร้างแบบจำลองที่เหมือนกันของสแต็กการผลิตของคุณ ใช้เวลาสี่นาทีแทนสี่สัปดาห์

- 11. เครือข่ายคลาวด์ (VPC, Subnets, NAT และ Security Groups)

13:20 แนวคิดที่สิบเอ็ด: ระบบเครือข่ายคลาวด์และเครือข่ายส่วนตัวเสมือน เมื่อคุณปรับใช้เซิร์ฟเวอร์กับคลาวด์ เซิร์ฟเวอร์เหล่านั้นจะไม่อยู่ในอินเทอร์เน็ตสาธารณะที่เปิดเผยโดยตรง แต่จะอยู่ในขอบเขตแยกที่กำหนดโดยซอฟต์แวร์ ที่เรียกว่า VPC ภายใน VPC ของคุณ คุณจะจัดสรรพื้นที่อยู่ IP ส่วนตัว เช่น สิบจุดศูนย์จุดศูนย์จุดศูนย์ ทับสิบหก และแบ่งออกเป็น ซับเน็ตสาธารณะและส่วนตัว ซับเน็ตสาธารณะมีเส้นทางตรงไปยัง Internet Gateway

13:51 มันเก็บสินทรัพย์ที่หันหน้าเข้าหาสาธารณะ เช่น Application Load Balancers และ NAT เกตเวย์ เป็นส่วนเดียวของเครือข่ายของคุณที่มี IP สาธารณะ เซิร์ฟเวอร์แอปพลิเคชันและฐานข้อมูลการผลิตของคุณจะอยู่ในซับเน็ตส่วนตัวเท่านั้น โดยไม่มี IP สาธารณะและไม่มีเส้นทางขาเข้าจากอินเทอร์เน็ต เมื่อเซิร์ฟเวอร์แบ็คเอนด์ของคุณ ต้องการดาวน์โหลดการอัปเดตความปลอดภัย การรับส่งข้อมูลขาออกจะผ่าน NAT Gateway ในซับเน็ตสาธารณะ รอบๆ อินสแตนซ์ทุกตัวคือ Security Groups: ไฟร์วอลล์เสมือนแบบ Stateful ไฟร์วอลล์เสมือนแบบ Stateful ที่บังคับใช้หลักการของสิทธิ์ขั้นต่ำ

- 12. แผนผังองค์กรที่สมบูรณ์และคำตัดสิน

14:28 กลุ่มความปลอดภัยของฐานข้อมูลของคุณยอมรับการเชื่อมต่อบนพอร์ต 5432 เท่านั้น จากกลุ่มความปลอดภัยของเซิร์ฟเวอร์แอปพลิเคชันของคุณอย่างเคร่งครัด ทำให้การเจาะจากภายนอกเป็นไปไม่ได้ทางคณิตศาสตร์ เมื่อคุณซูมออก องค์ประกอบพื้นฐานทั้งสิบเอ็ดนี้จะเชื่อมโยงกันเป็นระบบที่สอดคล้องกัน DNS ของคุณจะส่งเส้นทางไปยัง Load Balancer ในซับเน็ตสาธารณะ กลุ่มปรับขนาดอัตโนมัติจัดการปริมาณการใช้งานที่เพิ่มขึ้นใน Availability Zones หลายแห่ง event buses แยกส่วนการทำงานของแบ็คเอนด์ และสแต็กทั้งหมดของคุณ จะถูกปรับใช้จาก Git โดยใช้ Infrastructure as Code

15:02 คำตัดสินของมาสเตอร์คลาสวันนี้: SHIP IT หยุดการท่องจำคำย่อทางการตลาดของคลาวด์นับร้อย เชี่ยวชาญรูปแบบสถาปัตยกรรมทั้งสิบเอ็ดนี้ แยกสถานะของคุณ และสร้างระบบที่ไม่สามารถล้มเหลวได้ บอกฉันหน่อยว่าแนวคิดคลาวด์ใดที่ทำให้คุณปวดหัวมากที่สุดเมื่อคุณเริ่มสร้างในความคิดเห็น สร้างในความคิดเห็น และเพื่อรับเอกสารสรุปสถาปัตยกรรมฉบับสมบูรณ์ สมัครรับจดหมายข่าวได้ที่ thedaily diff.dev

15:28 ลิงก์ด้านล่าง และนั่นคือ The Daily 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