การประยุกต์ใช้รูปแบบ WAF กับสถาปัตยกรรมจริง

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

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

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

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

สำหรับการเพิ่มประสิทธิภาพต้นทุน ให้แทนที่ VM ที่เปิดทำงานตลอดเวลาด้วยชุดการปรับขนาด Virtual Machine ซึ่งลดขนาดลงในช่วงนอกเวลาเร่งด่วน สำหรับฐานข้อมูล ให้ประเมินว่าบริการ PaaS ที่มีการจัดการ เช่น Azure SQL Database ซึ่งใช้ระดับ DTU ที่เหมาะสม มีค่าใช้จ่ายน้อยกว่า VM เต็มรูปแบบที่ใช้ SQL Server หรือไม่ ซื้ออินสแตนซ์แบบสงวนไว้สำหรับความจุพื้นฐานที่คาดการณ์ล่วงหน้าได้ 12 เดือน

ปรับปรุงความเป็นเลิศด้านการปฏิบัติงานด้วยการกำหนดโครงสร้างพื้นฐานทั้งหมดเป็นแม่แบบ Bicep หรือ ARM ที่จัดเก็บไว้ในการควบคุมเวอร์ชัน สร้างกระบวนการ CI/CD ใน Azure Pipelines หรือ GitHub Actions เพื่อปรับใช้การเปลี่ยนแปลงโครงสร้างพื้นฐานและโค้ดแอปพลิเคชันโดยอัตโนมัติ เพิ่มจุดตรวจสอบการปรับใช้ ซึ่งได้แก่การทดสอบควันแบบอัตโนมัติและการอนุมัติด้วยตนเอง ก่อนที่การเปลี่ยนแปลงจะไปถึงสภาพแวดล้อมจริง

สำหรับประสิทธิภาพและประสิทธิผล ให้เพิ่ม Azure Cache for Redis ไว้หน้าฐานข้อมูลเพื่อแคชคำค้นที่มีการอ่านบ่อยและลดภาระของฐานข้อมูล ปรับใช้ทรัพยากรแบบคงที่ (รูปภาพ, CSS, JavaScript) ผ่าน Azure CDN เพื่อให้บริการจากโหนดขอบที่อยู่ใกล้ผู้ใช้ทั่วโลก ทดสอบโหลดแอปพลิเคชันหลังการเปลี่ยนแปลงแต่ละครั้ง เพื่อยืนยันว่าการปรับปรุงนั้นวัดผลได้

การเปลี่ยนแปลงสถาปัตยกรรมทุกครั้งมีข้อแลกเปลี่ยน ตัวอย่างเช่น การย้ายไปใช้สถาปัตยกรรมหลายโซนช่วยเพิ่มความน่าเชื่อถือ แต่เพิ่มต้นทุน (สองโซน = สอง VM) การเพิ่มการแคชด้วย Redis ช่วยเพิ่มประสิทธิภาพ แต่เพิ่มความซับซ้อนด้านการปฏิบัติงาน (มี Service อีกหนึ่งรายการที่ต้องตรวจสอบและดูแล) เอกสารสถาปัตยกรรมที่ดีจะบันทึกข้อแลกเปลี่ยนเหล่านี้ไว้อย่างชัดเจน เพื่อให้สถาปนิกในอนาคตเข้าใจเหตุผลของการตัดสินใจ

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

Microsoft เผยแพร่สถาปัตยกรรมอ้างอิงสำหรับรูปแบบเวิร์กโหลดทั่วไปที่ ศูนย์สถาปัตยกรรม Azure ซึ่งครอบคลุมสถาปัตยกรรมแอปพลิเคชันเว็บ ไมโครเซอร์วิสบน AKS กระบวนการประมวลผลข้อมูลวิเคราะห์ และอื่น ๆ อีกมากมาย สถาปัตยกรรมอ้างอิงแต่ละแบบได้รับการประเมินตามเสาหลักทั้งห้าของกรอบงาน Well-Architected แล้ว และมีหมายเหตุเกี่ยวกับข้อแลกเปลี่ยนของรูปแบบนั้นโดยเฉพาะ

ใช้บันทึกการตัดสินใจด้านสถาปัตยกรรม (ADR)เพื่อจัดทำเอกสารเกี่ยวกับทางเลือกสำคัญด้านสถาปัตยกรรม บริบทที่ใช้ตัดสินใจ ทางเลือกอื่นที่พิจารณา และผลกระทบต่อเสาหลักของกรอบงาน Well-Architected การจัดเก็บ ADR ไว้ในการควบคุมเวอร์ชันร่วมกับฐานโค้ดจะสร้างประวัติที่ตรวจสอบได้ และช่วยให้สมาชิกใหม่ในทีมเข้าใจว่าเหตุใดสถาปัตยกรรมจึงมีลักษณะเช่นนั้น

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

ในบทเรียนนี้ คุณได้เรียนรู้ว่า รูปแบบของกรอบงาน Well-Architectedนำมาใช้โดยประเมินการตัดสินใจด้านสถาปัตยกรรมแต่ละครั้งเทียบกับเสาหลักทั้งห้า สามารถปรับปรุงแบบวนซ้ำได้โดยเริ่มจากปัญหาที่มีผลกระทบสูงสุด และต้องจัดทำเอกสารข้อแลกเปลี่ยนเพื่อให้สถาปนิกในอนาคตเข้าใจเหตุผลเบื้องหลัง ต่อไปเราจะสำรวจ SLA ของ Azure และวิธีคำนวณ SLA แบบรวมสำหรับสถาปัตยกรรมที่มีหลาย Service