กรณีศึกษา: เหตุใดฉันจึงใช้ AWS Cloud Infrastructure สำหรับผลิตภัณฑ์ของฉัน

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

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

ความต้องการ

ลูกค้ามีข้อกำหนดหลักสองข้อที่โซลูชันที่เสนอต้องเป็นไปตาม:

1. ความปลอดภัย
2. ความสามารถในการปรับขนาด

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

ภาพรวมของแนวคิดด้านความปลอดภัยของ AWS

ประโยชน์หลักประการหนึ่งของการตั้งค่าโครงสร้างพื้นฐาน AWS Cloud ของคุณเองคือการแยกเครือข่ายอย่างสมบูรณ์และการควบคุมระบบคลาวด์ของคุณอย่างสมบูรณ์ นั่นเป็นเหตุผลหลักที่ว่าทำไมคุณถึงเลือกเส้นทาง Infrastructure as a Service (IaaS) แทนที่จะใช้สภาพแวดล้อม Platform as a Service (PaaS) ที่ค่อนข้างง่ายกว่า ซึ่งมีค่าเริ่มต้นด้านความปลอดภัยที่มั่นคง แต่ไม่มีการควบคุมที่ละเอียดและสมบูรณ์ที่คุณได้รับ ตั้งค่าระบบคลาวด์ของคุณเองด้วย AWS

แม้ว่า LEVELS จะเป็นผลิตภัณฑ์รุ่นเยาว์เมื่อพวกเขาเข้าหา Toptal สำหรับบริการให้คำปรึกษาของ AWS พวกเขาเต็มใจที่จะผูกมัดกับ AWS และรู้ว่าพวกเขาต้องการการรักษาความปลอดภัยที่ล้ำสมัยด้วยโครงสร้างพื้นฐานของพวกเขา เนื่องจากพวกเขามีความกังวลเกี่ยวกับข้อมูลผู้ใช้และความเป็นส่วนตัวเป็นอย่างมาก ยิ่งไปกว่านั้น พวกเขากำลังวางแผนที่จะสนับสนุนการประมวลผลบัตรเครดิตในอนาคต ดังนั้นพวกเขาจึงรู้ว่าพวกเขาจะต้องตรวจสอบให้แน่ใจว่ามีการปฏิบัติตาม PCI-DSS ในบางจุด

คลาวด์ส่วนตัวเสมือน (VPC)

การรักษาความปลอดภัยบน AWS เริ่มต้นด้วยการสร้าง Amazon Virtual Private Cloud (VPC) ของคุณเอง ซึ่งเป็นเครือข่ายเสมือนเฉพาะที่โฮสต์ทรัพยากร AWS ของคุณและแยกทางตรรกะออกจากเครือข่ายเสมือนอื่นๆ ใน AWS Cloud VPC มีช่วงที่อยู่ IP ของตัวเอง ซับเน็ตที่กำหนดค่าได้ทั้งหมด ตารางเส้นทาง รายการควบคุมการเข้าถึงเครือข่าย และกลุ่มความปลอดภัย (อย่างมีประสิทธิภาพคือไฟร์วอลล์)

ด้วย LEVELS เราเริ่มต้นด้วยการแยกสภาพแวดล้อมการผลิตของเราออกจากการพัฒนา การทดสอบ และสภาพแวดล้อม QA แนวคิดแรกคือการเรียกใช้แต่ละส่วนเป็น VPC ที่แยกออกมาอย่างสมบูรณ์ โดยแต่ละส่วนจะเรียกใช้บริการทั้งหมดตามที่แอปพลิเคชันต้องการ หลังจากพิจารณามาบ้างแล้ว ปรากฏว่าเราสามารถอนุญาตให้มีการแบ่งปันทรัพยากรในสภาพแวดล้อมที่ไม่ใช่การผลิตจริงทั้งสามแบบ ซึ่งช่วยลดต้นทุนได้ในระดับหนึ่ง

ดังนั้นเราจึงตัดสินสภาพแวดล้อมการใช้งานจริงเป็น VPC เดียว โดยมีสภาพแวดล้อมการพัฒนา การทดสอบ และ QA เป็น VPC อื่น

เข้าถึงการแยกในระดับ VPC

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

ด้วยสภาพแวดล้อมการพัฒนา การทดสอบ และ QA ที่แชร์ VPC เดียวกัน การเข้าถึงข้ามพรมแดนจึงเป็นไปได้ในกรณีที่กำหนดค่าผิดพลาด แต่เนื่องจากสภาพแวดล้อมเหล่านั้นใช้ข้อมูลทดสอบ จึงไม่มีข้อกังวลด้านความปลอดภัยที่แท้จริงหากไม่มีการแยกอยู่

โมเดลความปลอดภัยของร้านค้าสินทรัพย์

เนื้อหาจะถูกจัดเก็บในที่จัดเก็บอ็อบเจ็กต์ Amazon Simple Storage Service (S3) โครงสร้างพื้นฐานการจัดเก็บข้อมูล S3 นั้นไม่ขึ้นกับ VPC โดยสมบูรณ์ และรูปแบบการรักษาความปลอดภัยนั้นแตกต่างกัน พื้นที่จัดเก็บได้รับการจัดระเบียบในบัคเก็ต S3 แยกกันสำหรับแต่ละสภาพแวดล้อมและ/หรือคลาสของสินทรัพย์ ปกป้องแต่ละบัคเก็ตด้วยสิทธิ์การเข้าถึงที่เหมาะสม

ด้วย LEVELS สินทรัพย์หลายประเภทได้รับการระบุ: การอัปโหลดของผู้ใช้ เนื้อหาที่สร้าง LEVELS (วิดีโอส่งเสริมการขายและเนื้อหาที่คล้ายกัน) เว็บแอปพลิเคชันและเนื้อหา UI (โค้ด JS ไอคอน แบบอักษร) การกำหนดค่าแอปพลิเคชันและโครงสร้างพื้นฐาน และบันเดิลการปรับใช้ฝั่งเซิร์ฟเวอร์

แต่ละรายการจะได้รับบัคเก็ต S3 แยกต่างหาก

การจัดการความลับของแอปพลิเคชัน

เมื่อใช้ AWS จะมี ร้านค้าพารามิเตอร์ AWS Systems Manager ที่เข้ารหัสหรือ AWS Secrets Manager ซึ่งเป็นบริการคีย์-ค่าที่มีการจัดการซึ่งออกแบบมาเพื่อรักษาความลับให้ปลอดภัย (คุณสามารถเรียนรู้เพิ่มเติมที่ Linux Academy และ 1Strategy)

AWS จัดการคีย์การเข้ารหัสพื้นฐานและจัดการการเข้ารหัส/ถอดรหัส ข้อมูลลับเองสามารถใช้นโยบายสิทธิ์ในการอ่านและเขียนตามคำนำหน้าคีย์ สำหรับทั้งโครงสร้างพื้นฐานและผู้ใช้ (เซิร์ฟเวอร์และนักพัฒนาตามลำดับ)

การเข้าถึง SSH ของเซิร์ฟเวอร์

การเข้าถึง SSH ไปยังเซิร์ฟเวอร์ในสภาพแวดล้อมแบบอัตโนมัติและไม่เปลี่ยนรูปไม่จำเป็นเลย บันทึกสามารถแยกและส่งไปยังบริการบันทึกเฉพาะ การตรวจสอบยังถูกถ่ายโอนไปยังบริการตรวจสอบเฉพาะ อย่างไรก็ตาม อาจมีความจำเป็นในการเข้าถึง SSH เป็นครั้งคราวสำหรับการตรวจสอบการกำหนดค่าและการดีบัก

เพื่อจำกัดพื้นผิวการโจมตีของเซิร์ฟเวอร์ พอร์ต SSH จะไม่ถูกเปิดเผยต่อเครือข่ายสาธารณะ เซิร์ฟเวอร์เข้าถึงได้ผ่านโฮสต์ Bastion ซึ่งเป็นเครื่องเฉพาะที่อนุญาตให้เข้าถึง SSH ภายนอก ได้รับการป้องกันเพิ่มเติมโดยอนุญาตเฉพาะช่วงที่อยู่ IP ที่อนุญาตที่ไฟร์วอลล์ การเข้าถึงถูกควบคุมโดยการปรับใช้คีย์ SSH สาธารณะของผู้ใช้กับกล่องที่เหมาะสม (ปิดใช้งานการเข้าสู่ระบบด้วยรหัสผ่าน) การตั้งค่าดังกล่าวมีประตูที่ค่อนข้างยืดหยุ่นสำหรับผู้โจมตีที่ประสงค์ร้ายที่จะผ่านเข้าไป

การเข้าถึงฐานข้อมูล

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

สามารถใช้แนวทางที่คล้ายกันได้ โดยใช้โครงสร้างพื้นฐานโฮสต์ป้อมปราการเดียวกันกับช่องสัญญาณ SSH จำเป็นต้องใช้ช่องสัญญาณ SSH แบบคู่ อันหนึ่งไปยังโฮสต์ Bastion และอีกช่องหนึ่งไปยังเซิร์ฟเวอร์ที่มีสิทธิ์เข้าถึงฐานข้อมูล (โฮสต์ Bastion ไม่มีสิทธิ์เข้าถึงเซิร์ฟเวอร์ฐานข้อมูล) ผ่านช่องสัญญาณที่สองนั้น การเชื่อมต่อจากเครื่องไคลเอนต์ของผู้ใช้ไปยังเซิร์ฟเวอร์ฐานข้อมูลพร้อมใช้งานแล้ว

ภาพรวมแนวคิดเรื่องความสามารถในการปรับขนาดของ AWS

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

ด้วย AWS แนวทางที่ดีที่สุดในการปรับขยายขนาดได้คือการใช้ประโยชน์จากบริการของ AWS ที่ได้รับการจัดการพร้อมการตรวจสอบและการทดสอบระบบอัตโนมัติที่ทดสอบกับลูกค้าหลายพันรายที่ใช้แพลตฟอร์ม เพิ่มกลไกการสำรองและกู้คืนข้อมูลลงในส่วนผสม และคุณจะได้รับข้อกังวลมากมายจากตารางโดยอาศัยตัวแพลตฟอร์มเอง

การมีออฟโหลดทั้งหมดนั้นช่วยให้มีทีมปฏิบัติการที่มีขนาดเล็กลง ซึ่งค่อนข้างจะชดเชยค่าใช้จ่ายที่สูงขึ้นของบริการที่มีการจัดการแพลตฟอร์ม ทีม LEVELS ยินดีที่จะเลือกเส้นทางนั้นทุกที่ที่ทำได้

Amazon Elastic Compute Cloud (EC2)

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

การจัดเตรียมอินสแตนซ์ EC2 จะต้องเป็นแบบอัตโนมัติทั้งหมด การทำงานอัตโนมัติทำได้โดยใช้ AMI ที่กำหนดเองสำหรับเซิร์ฟเวอร์ประเภทต่างๆ และ Auto Scaling Groups จะดูแลกลุ่มเซิร์ฟเวอร์แบบไดนามิกที่ทำงานอยู่โดยการรักษาจำนวนอินสแตนซ์ของเซิร์ฟเวอร์ที่ทำงานอยู่อย่างเหมาะสมในฟลีตตามปริมาณการใช้งานปัจจุบัน

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

บริการฐานข้อมูลเชิงสัมพันธ์ของ Amazon (RDS)

ทีมงานได้ใช้งาน Amazon RDS สำหรับ MySQL แล้ว แต่ยังไม่มีการพัฒนาการสำรองข้อมูลที่เหมาะสม ความทนทานต่อข้อผิดพลาด และกลยุทธ์ด้านความปลอดภัย ในการทำซ้ำครั้งแรก อินสแตนซ์ฐานข้อมูลได้รับการอัปเกรดเป็นคลัสเตอร์สองอินสแตนซ์ใน VPC แต่ละรายการ ซึ่งกำหนดค่าเป็นต้นแบบและตัวจำลองการอ่าน ซึ่งรองรับการเฟลโอเวอร์อัตโนมัติ

ในการทำซ้ำครั้งต่อไป ด้วยความพร้อมใช้งานของกลไก MySQL เวอร์ชัน 5.7 โครงสร้างพื้นฐานได้รับการอัปเกรดเป็นบริการ Amazon Aurora MySQL แม้ว่าจะมีการจัดการเต็มรูปแบบ แต่ Aurora ไม่ใช่โซลูชันที่มีการปรับขนาดโดยอัตโนมัติ นำเสนอการปรับขนาดพื้นที่เก็บข้อมูลอัตโนมัติ หลีกเลี่ยงปัญหาการวางแผนความจุ แต่สถาปนิกโซลูชันยังคงต้องเลือกขนาดอินสแตนซ์การประมวลผล

ไม่สามารถหลีกเลี่ยงเวลาหยุดทำงานเนื่องจากการปรับขนาดได้ แต่สามารถลดให้เหลือน้อยที่สุดได้โดยใช้ความสามารถในการรักษาอัตโนมัติ ด้วยความสามารถในการจำลองแบบที่ดีขึ้น Aurora จึงมีฟังก์ชันการเฟลโอเวอร์ที่ราบรื่น การปรับขนาดจะดำเนินการโดยการสร้างตัวจำลองการอ่านด้วยกำลังการประมวลผลที่ต้องการ จากนั้นจึงดำเนินการเฟลโอเวอร์ไปยังอินสแตนซ์นั้น ตัวจำลองการอ่านอื่นๆ ทั้งหมดจะถูกนำออกจากคลัสเตอร์ ปรับขนาด และนำกลับเข้ามาในคลัสเตอร์ ต้องใช้การเล่นกลแบบแมนนวล แต่ก็ทำได้มากกว่า

ข้อเสนอ Aurora Serverless ใหม่ช่วยให้สามารถปรับขนาดทรัพยากรการประมวลผลได้โดยอัตโนมัติในระดับหนึ่ง ซึ่งเป็นคุณสมบัติที่คุ้มค่าที่จะมองหาในอนาคตอย่างแน่นอน

บริการ AWS ที่มีการจัดการ

นอกเหนือจากองค์ประกอบทั้งสองนี้ ส่วนที่เหลือของระบบยังได้รับประโยชน์จากกลไกการปรับขนาดอัตโนมัติของบริการของ AWS ที่มีการจัดการเต็มรูปแบบ ได้แก่ Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), พื้นที่จัดเก็บอ็อบเจ็กต์ Amazon S3, ฟังก์ชัน AWS Lambda และ Amazon Simple Notification Service (SNS) โดยที่สถาปนิกไม่ต้องการความพยายามในการปรับขนาดโดยเฉพาะ

โครงสร้างพื้นฐานที่ไม่แน่นอนเทียบกับโครงสร้างพื้นฐานที่ไม่เปลี่ยนรูป

เราตระหนักดีถึงสองวิธีในการจัดการโครงสร้างพื้นฐานของเซิร์ฟเวอร์ - โครงสร้างพื้นฐานที่ เปลี่ยนแปลง ได้ซึ่งเซิร์ฟเวอร์ได้รับการติดตั้งและอัปเดตและแก้ไขอย่างต่อเนื่องในสถานที่ และโครงสร้างพื้นฐานที่ ไม่เปลี่ยนรูป ซึ่งเซิร์ฟเวอร์จะไม่ถูกแก้ไขหลังจากเตรียมใช้งาน และการปรับเปลี่ยนการกำหนดค่าหรือการอัปเดตเซิร์ฟเวอร์จะได้รับการจัดการโดยการจัดเตรียมเซิร์ฟเวอร์ใหม่จากอิมเมจทั่วไปหรือสคริปต์การติดตั้ง แทนที่เซิร์ฟเวอร์เก่า

ด้วย LEVELS ทางเลือกคือการเรียกใช้ โครงสร้างพื้นฐานที่ไม่เปลี่ยนรูป แบบโดยไม่มีการอัปเกรดแบบแทนที่ การเปลี่ยนแปลงการกำหนดค่า หรือการดำเนินการด้านการจัดการ ข้อยกเว้นเพียงอย่างเดียวคือการปรับใช้แอปพลิเคชันซึ่งเกิดขึ้นในสถานที่

ข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้างพื้นฐานที่ไม่แน่นอนและไม่เปลี่ยนรูปสามารถพบได้ในบล็อกของ HashiCorp

ภาพรวมสถาปัตยกรรม

ในทางเทคนิค LEVELS เป็นแอปบนอุปกรณ์เคลื่อนที่และเว็บแอปที่มีแบ็กเอนด์ REST API และบริการพื้นหลังบางส่วน ซึ่งเป็นแอปพลิเคชันทั่วไปในปัจจุบัน ในเรื่องนั้น โครงสร้างพื้นฐานต่อไปนี้ได้รับการเสนอและกำหนดค่า:

การแยกเครือข่ายเสมือน - Amazon VPC

ไดอะแกรมแสดงภาพโครงสร้างของสภาพแวดล้อมหนึ่งๆ ใน ​​VPC สภาพแวดล้อมอื่นๆ เป็นไปตามโครงสร้างเดียวกัน (มี Application Load Balancer (ALB) และคลัสเตอร์ Amazon Aurora ที่แชร์ระหว่างสภาพแวดล้อมที่ไม่ใช่การผลิตใน VPC แต่การตั้งค่าเครือข่ายจะเหมือนกันทุกประการ)

VPC ได้รับการกำหนดค่าในโซนความพร้อมใช้งานสี่โซนภายในภูมิภาค AWS สำหรับความทนทานต่อข้อผิดพลาด ซับเน็ตและกลุ่มความปลอดภัยที่มีรายการควบคุมการเข้าถึงเครือข่าย อนุญาตให้ปฏิบัติตามข้อกำหนดด้านความปลอดภัยและการควบคุมการเข้าถึง

การขยายโครงสร้างพื้นฐานข้ามเขต AWS หลายแห่งเพื่อเพิ่มความทนทานต่อข้อผิดพลาดจะซับซ้อนเกินไปและไม่จำเป็นในช่วงเริ่มต้นของธุรกิจและผลิตภัณฑ์ แต่เป็นตัวเลือกในอนาคต

คอมพิวเตอร์

LEVELS รัน REST API แบบดั้งเดิมกับพนักงานที่ทำงานเบื้องหลังบางส่วนสำหรับตรรกะของแอปพลิเคชันที่เกิดขึ้นในเบื้องหลัง ทั้งสองอย่างนี้ทำงานเป็นฟลีตไดนามิกของอินสแตนซ์ EC2 ธรรมดา ทำงานอัตโนมัติโดยสมบูรณ์ผ่าน Auto Scaling Groups บริการที่มีการจัดการของ Amazon SQS ใช้สำหรับการกระจายงานในเบื้องหลัง (งาน) โดยไม่จำเป็นต้องเรียกใช้ บำรุงรักษา และปรับขนาดเซิร์ฟเวอร์ MQ ของคุณเอง

นอกจากนี้ยังมีงานยูทิลิตี้บางอย่างที่ไม่มีตรรกะทางธุรกิจร่วมกับส่วนที่เหลือของแอปพลิเคชัน เช่น การประมวลผลภาพ งานประเภทดังกล่าวทำงานได้ดีมากบน AWS Lambda เนื่องจาก Lambdas สามารถปรับขนาดในแนวนอนได้ไม่จำกัดและมีการประมวลผลแบบขนานที่ไม่มีใครเทียบได้เมื่อเปรียบเทียบกับพนักงานเซิร์ฟเวอร์

Load Balancing, Auto-scaling และ Fault Tolerance

การทำโหลดบาลานซ์สามารถทำได้ด้วยตนเองผ่าน Nginx หรือ HAProxy แต่การเลือก Amazon Elastic Load Balancing (ELB) จะเพิ่มประโยชน์ของการมีโครงสร้างพื้นฐานการทำโหลดบาลานซ์ที่สามารถปรับขนาดได้โดยอัตโนมัติ มีความพร้อมใช้งานสูง และทนต่อข้อผิดพลาดได้

มีการใช้ Application Load Balancer (ALB) ของ ELB ซึ่งทำให้สามารถใช้การกำหนดเส้นทางเลเยอร์ HTTP ได้ที่ตัวโหลดบาลานซ์ อินสแตนซ์ใหม่ที่เพิ่มไปยังฟลีตจะได้รับการลงทะเบียนโดยอัตโนมัติกับ ALB ผ่านกลไกของแพลตฟอร์ม AWS ALB ยังตรวจสอบความพร้อมใช้งานของอินสแตนซ์อยู่ตลอดเวลา มีอำนาจในการยกเลิกการลงทะเบียนและยกเลิกอินสแตนซ์ที่ไม่แข็งแรง เรียกใช้การปรับขนาดอัตโนมัติเพื่อแทนที่ด้วยอินสแตนซ์ใหม่ ด้วยการทำงานร่วมกันระหว่างทั้งสองนี้ การรักษาอัตโนมัติของกอง EC2 สามารถทำได้

Application Data Store

พื้นที่เก็บข้อมูลแอปพลิเคชันคือ คลัสเตอร์ Amazon Aurora MySQL ซึ่งประกอบด้วยอินสแตนซ์หลักและอินสแตนซ์ตัวจำลองการอ่านจำนวนหนึ่ง ในกรณีที่อินสแตนซ์หลักล้มเหลว หนึ่งในตัวจำลองการอ่านจะได้รับการเลื่อนระดับเป็นอินสแตนซ์หลักใหม่โดยอัตโนมัติ การกำหนดค่าดังกล่าวเป็นไปตามข้อกำหนดความทนทานต่อข้อผิดพลาดที่ร้องขอ

นอกจากนี้ยังสามารถใช้ตัวจำลองการอ่านตามชื่อเพื่อกระจายโหลดคลัสเตอร์ฐานข้อมูลสำหรับการดำเนินการอ่านข้อมูล

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

การจัดเก็บและให้บริการสินทรัพย์

LEVELS ยอมรับเนื้อหาที่อัปโหลดของผู้ใช้ซึ่งจำเป็นต้องจัดเก็บ พื้นที่จัดเก็บอ็อบเจ็กต์ Amazon S3 เป็นบริการที่จะดูแลงานนั้น นอกจากนี้ยังมีแอสเซทของแอปพลิเคชัน (องค์ประกอบ UI - รูปภาพ ไอคอน แบบอักษร) ซึ่งจำเป็นต้องทำให้พร้อมใช้งานสำหรับแอปไคลเอนต์ ดังนั้นจึงได้รับการจัดเก็บไว้ใน S3 เช่นกัน นำเสนอการสำรองข้อมูลอัตโนมัติของข้อมูลที่อัปโหลดผ่านการจำลองที่จัดเก็บข้อมูลภายใน S3 ให้ความคงทนของข้อมูลตามค่าเริ่มต้น

รูปภาพที่ผู้ใช้อัปโหลดมีขนาดและน้ำหนักที่หลากหลาย ซึ่งมักจะใหญ่เกินความจำเป็นสำหรับการให้บริการโดยตรงและมีน้ำหนักเกิน ทำให้เป็นภาระในการเชื่อมต่อมือถือ การผลิตรูปแบบต่างๆ ในขนาดต่างๆ กันจะช่วยให้สามารถนำเสนอเนื้อหาที่ปรับให้เหมาะสมยิ่งขึ้นสำหรับกรณีการใช้งานแต่ละกรณี AWS Lambda ใช้ประโยชน์จากงานนั้นได้ เช่นเดียวกับการทำสำเนาต้นฉบับของรูปภาพที่อัปโหลดลงในบัคเก็ตสำรองแยกต่างหาก เผื่อไว้ด้วย

สุดท้าย เว็บแอปพลิเคชันที่ทำงานบนเบราว์เซอร์ยังเป็นชุดของสินทรัพย์แบบคงที่อีกด้วย - โครงสร้างพื้นฐานของการรวมอย่างต่อเนื่องของบิลด์จะรวบรวมโค้ด JavaScript และจัดเก็บแต่ละบิลด์ไว้ใน S3 เช่นกัน

เมื่อสินทรัพย์เหล่านี้ทั้งหมดได้รับการจัดเก็บอย่างปลอดภัยใน S3 จะสามารถให้บริการได้โดยตรง เนื่องจาก S3 มีอินเทอร์เฟซ HTTP สาธารณะ หรือผ่าน Amazon CloudFront CDN CloudFront ทำให้ทรัพย์สินกระจายตามภูมิศาสตร์ ลดเวลาแฝงให้กับผู้ใช้ และยังเปิดใช้งานการสนับสนุน HTTPS สำหรับการให้บริการสินทรัพย์คงที่

การจัดหาและการจัดการโครงสร้างพื้นฐาน

การเตรียมใช้งานโครงสร้างพื้นฐานของ AWS เป็นการผสมผสานระหว่างเครือข่าย ทรัพยากรและบริการที่มีการจัดการของ AWS และทรัพยากรการประมวลผล EC2 เปล่า บริการของ AWS ที่ได้รับการจัดการนั้นได้รับการจัดการอย่างดี ไม่มีอะไรเกี่ยวข้องกับพวกเขามากนัก ยกเว้นการจัดเตรียมและการใช้การรักษาความปลอดภัยที่เหมาะสม ในขณะที่ด้วยทรัพยากรการคำนวณ EC2 เราจำเป็นต้องดูแลการกำหนดค่าและระบบอัตโนมัติด้วยตัวเราเอง

เครื่องมือช่าง

คอนโซล AWS บนเว็บทำให้การจัดการโครงสร้างพื้นฐานของ AWS ที่ “เหมือนอิฐเลโก้” เป็นอะไรที่ไม่สำคัญ และค่อนข้างจะเกิดข้อผิดพลาดเนื่องจากการทำงานด้วยตนเอง นั่นเป็นเหตุผลที่การใช้เครื่องมือเฉพาะเพื่อทำให้งานนั้นเป็นที่ต้องการโดยอัตโนมัติ

หนึ่งในเครื่องมือดังกล่าวคือ AWS CloudFormation ซึ่งพัฒนาและดูแลโดย AWS อีกประการหนึ่งคือ Terraform ของ HashiCorp ซึ่งเป็นทางเลือกที่ยืดหยุ่นกว่าเล็กน้อยโดยนำเสนอผู้ให้บริการแพลตฟอร์มหลายราย แต่สิ่งที่น่าสนใจในที่นี้ส่วนใหญ่เป็นผลมาจากปรัชญาแนวทางโครงสร้างพื้นฐานที่ไม่เปลี่ยนรูปของ Terraform สอดคล้องกับวิธีการรันโครงสร้างพื้นฐาน LEVELS Terraform ร่วมกับ Packer ในการจัดเตรียมอิมเมจ AMI พื้นฐานจึงกลายเป็นสิ่งที่เหมาะสมอย่างยิ่ง

เอกสารประกอบโครงสร้างพื้นฐาน

ประโยชน์เพิ่มเติมของเครื่องมืออัตโนมัติคือไม่ต้องมีเอกสารเกี่ยวกับโครงสร้างพื้นฐานโดยละเอียด ซึ่งจะล้าสมัยไม่ช้าก็เร็ว กระบวนทัศน์ “Infrastructure as Code” (IaC) ของเครื่องมือการจัดเตรียมจะพากย์เป็นเอกสาร พร้อมประโยชน์ของการอัพเดทโครงสร้างพื้นฐานจริงอยู่เสมอ การมีภาพรวมในระดับสูง มีโอกาสน้อยที่จะเปลี่ยนแปลงและค่อนข้างง่ายต่อการบำรุงรักษาเมื่อมีการเปลี่ยนแปลงในท้ายที่สุด เอกสารที่ด้านข้างก็เพียงพอแล้ว

ความคิดสุดท้าย

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

ในเรื่องความปลอดภัย AWS Cloud จะเก็บข้อมูลทั้งหมดและทรัพยากรทั้งหมดภายใน เครือข่ายส่วนตัว ภายในคลาวด์เดียวกัน ไม่จำเป็นต้องมีข้อมูลที่เป็นความลับในการเดินทางผ่านเครือข่ายสาธารณะ การเข้าถึงภายนอกจะได้รับสิทธิ์แบบละเอียดไปยังระบบสนับสนุนที่เชื่อถือได้ (CI/CD, การตรวจสอบจากภายนอก หรือการแจ้งเตือน) ซึ่งจำกัดขอบเขตของการเข้าถึงเฉพาะทรัพยากรที่จำเป็นสำหรับบทบาทของพวกเขาในทั้งระบบ

ออกแบบสถาปัตยกรรมและตั้งค่าอย่างถูกต้อง ระบบดังกล่าวมีความยืดหยุ่น ยืดหยุ่น ปลอดภัย และพร้อมที่จะตอบข้อกำหนดในอนาคตทั้งหมดเกี่ยวกับการปรับขนาดสำหรับการเติบโตของผลิตภัณฑ์หรือการนำการรักษาความปลอดภัยขั้นสูงไปใช้ เช่น การปฏิบัติตามข้อกำหนด PCI-DSS

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

อ่านเพิ่มเติมในบล็อก Toptal Engineering:

• ทำการบ้านของคุณ: 7 เคล็ดลับการสอบสถาปนิกโซลูชันที่ผ่านการรับรองจาก AWS
• Terraform vs. CloudFormation: The Definitive Guide
• การบันทึก SSH และการจัดการเซสชันโดยใช้ AWS SSM
• การทำงานกับ TypeScript และ Jest Support: บทช่วยสอน AWS SAM