สวัสดีทุกคน! หลักสูตรเริ่มต้นวันนี้ จากการที่เราได้จัดสัมมนาผ่านเว็บที่เกี่ยวข้องกับการทบทวน ELB โดยเฉพาะ เราพิจารณาประเภทของบาลานเซอร์และสร้าง EC2 instance หลายรายการด้วยบาลานเซอร์ เรายังศึกษาตัวอย่างการใช้งานอื่นๆ ด้วย
, คุณจะ:
- ทำความเข้าใจว่า AWS Load Balancing คืออะไร
- รู้ประเภทของ Elastic Load Balancer และส่วนประกอบต่างๆ
- ใช้ AWS ELB ในการปฏิบัติงานของคุณ
ทำไมคุณต้องรู้เรื่องนี้เลย?
- มีประโยชน์หากคุณวางแผนที่จะสอบการรับรอง AWS
- นี่เป็นวิธีง่ายๆ ในการกระจายโหลดระหว่างเซิร์ฟเวอร์
- นี่เป็นวิธีง่ายๆ ในการเพิ่ม Lambda ไปยังบริการของคุณ (ALB)
ดำเนินการบทเรียนแบบเปิด วิศวกรระบบของบริษัทการตลาดเพื่อการพัฒนาและสนับสนุนเว็บไซต์
การแนะนำ
ประโยชน์ของ Elastic Load Balancer สามารถดูได้ในแผนภาพด้านล่าง ซึ่งแสดงตัวอย่างง่ายๆ:
Load Balancer ยอมรับคำขอและกระจายคำขอข้ามอินสแตนซ์ เรามีอินสแตนซ์แยกกันหนึ่งอินสแตนซ์ มีฟังก์ชัน Lambda และมีกลุ่ม AutoScaling (กลุ่มของเซิร์ฟเวอร์)
ประเภท AWS ELB
1. มาดูประเภทหลักกัน:
โหลดบาลานเซอร์แบบคลาสสิก โหลดบาลานเซอร์ตัวแรกจาก AWS ใช้งานได้ทั้ง OSI Layer 4 และ Layer 7 ซึ่งรองรับ HTTP, HTTPS, TCP และ SSL โดยจัดให้มีการปรับสมดุลโหลดพื้นฐานสำหรับอินสแตนซ์ Amazon EC2 หลายอินสแตนซ์ และทำงานได้ทั้งในระดับคำขอและระดับการเชื่อมต่อ มาเปิดกันดีกว่า (เน้นด้วยสีเทา):
บาลานเซอร์นี้ถือว่าล้าสมัย ดังนั้นจึงแนะนำให้ใช้ในบางกรณีเท่านั้น ตัวอย่างเช่น สำหรับแอปพลิเคชันที่สร้างขึ้นบนเครือข่าย EC2‑Classic โดยหลักการแล้ว ไม่มีใครหยุดเราไม่ให้สร้างมันขึ้นมา:
2. โหลดบาลานเซอร์เครือข่าย เหมาะสำหรับปริมาณงานหนัก ทำงานที่ OSI Layer 4 (สามารถใช้ได้ใน EKS และ ECS) รองรับ TCP, UDP และ TLS
Network Load Balancer กำหนดเส้นทางการรับส่งข้อมูลไปยังเป้าหมายใน Amazon VPC และสามารถประมวลผลคำขอหลายล้านคำขอต่อวินาทีด้วยเวลาแฝงที่ต่ำมาก นอกจากนี้ยังได้รับการปรับให้เหมาะสมเพื่อรองรับรูปแบบการรับส่งข้อมูลที่มีการบรรทุกกะทันหันและเปลี่ยนแปลง
3. โหลดบาลานเซอร์ของแอปพลิเคชัน. ทำงานบนเลเยอร์ 7 รองรับ Lambda รองรับกฎระดับส่วนหัวและเส้นทาง รองรับ HTTP และ HTTPS
มอบการกำหนดเส้นทางคำขอขั้นสูงที่เน้นไปที่การส่งมอบแอปพลิเคชันที่สร้างขึ้นบนสถาปัตยกรรมสมัยใหม่ รวมถึงไมโครเซอร์วิสและคอนเทนเนอร์ กำหนดเส้นทางการรับส่งข้อมูลไปยังเป้าหมายใน Amazon VPC ตามเนื้อหาของคำขอ
สำหรับผู้ใช้จำนวนมาก Application Load Balancer เป็นตัวเลือกแรกที่จะมาแทนที่ Classic Load Balancer เนื่องจาก TCP ไม่เหมือนกันกับ HTTP
มาสร้างมันขึ้นมาด้วยเหตุนี้เราจึงมีโหลดบาลานเซอร์สองตัวอยู่แล้ว:
ส่วนประกอบสมดุลโหลด
ส่วนประกอบโหลดบาลานซ์ทั่วไป (เหมือนกันกับบาลานเซอร์ทั้งหมด):
- นโยบายการบันทึกการเข้าถึง
— บันทึกการเข้าถึง ELB ของคุณ หากต้องการตั้งค่า คุณสามารถไปที่คำอธิบายและเลือกปุ่ม "แก้ไขแอตทริบิวต์":
จากนั้นเราระบุ S3Bucket - พื้นที่จัดเก็บอ็อบเจ็กต์ Amazon:
- โครงการ
— บาลานเซอร์ภายในหรือภายนอก ประเด็นก็คือ LoadBalancer ของคุณจะต้องได้รับที่อยู่ภายนอกเพื่อให้สามารถเข้าถึงได้จากภายนอก หรืออาจเป็นโหลดบาลานเซอร์ภายในของคุณ
- กลุ่มรักษาความปลอดภัย
— การควบคุมการเข้าถึงบาลานเซอร์ โดยพื้นฐานแล้วนี่คือไฟร์วอลล์ระดับสูง
- เครือข่ายย่อย
— ซับเน็ตภายใน VPC ของคุณ (และโซนความพร้อมใช้งานตามลำดับ) มีการระบุซับเน็ตระหว่างการสร้าง หาก VPC ถูกจำกัดตามภูมิภาค ซับเน็ตจะถูกจำกัดตามโซนความพร้อมใช้งาน เมื่อสร้าง Load Balancer จะเป็นการดีกว่าถ้าสร้างในเครือข่ายย่อยอย่างน้อยสองเครือข่าย (ช่วยหากเกิดปัญหากับ Availability Zone หนึ่งแห่ง)
- ฟัง
— โปรโตคอลบาลานเซอร์ของคุณ ตามที่กล่าวไว้ข้างต้น สำหรับ Classic Load Balancer อาจเป็น HTTP, HTTPS, TCP และ SSL สำหรับ Network Load Balancer - TCP, UDP และ TLS สำหรับ Application Load Balancer - HTTP และ HTTPS
ตัวอย่างสำหรับโหลดบาลานเซอร์แบบคลาสสิก:
แต่ใน Application Load Balancer เราเห็นอินเทอร์เฟซที่แตกต่างกันเล็กน้อยและตรรกะที่แตกต่างกันโดยทั่วไป:
ส่วนประกอบ Load Balancer v2 (ALB และ NLB)
ตอนนี้เรามาดูตัวบาลานเซอร์เวอร์ชัน 2 กันดีกว่า Application Load Balancer และ Network Load Balancer บาลานเซอร์เหล่านี้มีคุณสมบัติส่วนประกอบของตัวเอง ตัวอย่างเช่นแนวคิดดังกล่าวปรากฏว่ากลุ่มเป้าหมาย - อินสแตนซ์ (และฟังก์ชัน) ด้วยองค์ประกอบนี้ เราจึงมีโอกาสที่จะระบุกลุ่มเป้าหมายที่เราต้องการกำหนดเส้นทางการรับส่งข้อมูลไป
พูดง่ายๆ ก็คือ ในกลุ่มเป้าหมาย เราจะระบุกรณีที่ทราฟฟิกจะมา หากใน Classic Load Balancer เดียวกัน คุณเพียงแค่เชื่อมต่อความเข้มกับบาลานเซอร์ทันที จากนั้นใน Application Load Balancer คุณจะต้อง:
- สร้างโหลดบาลานเซอร์
- สร้างกลุ่มเป้าหมาย
- ส่งตรงผ่านพอร์ตที่ต้องการหรือกฎ Load Balancer ไปยังกลุ่มเป้าหมายที่ต้องการ
- ในกลุ่มเป้าหมายที่คุณกำหนดอินสแตนซ์
ตรรกะการทำงานนี้อาจดูซับซ้อนกว่า แต่จริงๆ แล้วสะดวกกว่า
องค์ประกอบต่อไปคือ กฎของผู้ฟัง (กฎสำหรับการกำหนดเส้นทาง) สิ่งนี้ใช้ได้กับ Application Load Balancer เท่านั้น หากใน Network Load Balancer คุณเพียงสร้าง Listener และส่งการรับส่งข้อมูลไปยังกลุ่มเป้าหมายเฉพาะ จากนั้นใน Application Load Balancer ทุกอย่าง .
ทีนี้ลองพูดคำสองสามคำเกี่ยวกับองค์ประกอบถัดไป - IP ยืดหยุ่น (ที่อยู่แบบคงที่สำหรับร้อง) หากกฎการกำหนดเส้นทางของ Listener ส่งผลต่อ Application Load Balancer เท่านั้น Elastic IP จะส่งผลต่อ Network Load Balancer เท่านั้น
มาสร้าง Network Load Balancer กัน:
และในระหว่างกระบวนการสร้างเราจะเห็นว่าเราได้รับโอกาสในการเลือก Elastic IP:
Elastic IP มอบที่อยู่ IP เดียวที่สามารถเชื่อมโยงกับอินสแตนซ์ EC2 ที่แตกต่างกันเมื่อเวลาผ่านไป หากอินสแตนซ์ EC2 มีที่อยู่ Elastic IP และอินสแตนซ์นั้นถูกยกเลิกหรือหยุดทำงาน คุณสามารถเชื่อมโยงอินสแตนซ์ EC2 ใหม่กับที่อยู่ Elastic IP ได้ทันที อย่างไรก็ตาม แอปพลิเคชันปัจจุบันของคุณจะไม่หยุดทำงาน เนื่องจากแอปพลิเคชันยังคงเห็นที่อยู่ IP เดียวกัน แม้ว่า EC2 จริงจะมีการเปลี่ยนแปลงก็ตาม
ที่นี่ ในหัวข้อว่าทำไมถึงต้องใช้ Elastic IP ดูสิ เราเห็นที่อยู่ IP 3 แห่ง แต่จะไม่อยู่ที่นี่ตลอดไป:
Amazon เปลี่ยนแปลงสิ่งเหล่านี้เมื่อเวลาผ่านไป อาจจะทุกๆ 60 วินาที (แต่ในทางปฏิบัติ แน่นอนว่าไม่บ่อยนัก) ซึ่งหมายความว่าที่อยู่ IP สามารถเปลี่ยนแปลงได้ และในกรณีของ Network Load Balancer คุณสามารถผูกที่อยู่ IP และระบุไว้ในกฎ นโยบาย ฯลฯ ของคุณได้
วาดข้อสรุป
ELB ให้การกระจายการรับส่งข้อมูลขาเข้าโดยอัตโนมัติไปยังหลายเป้าหมาย (คอนเทนเนอร์, อินสแตนซ์ Amazon EC2, ที่อยู่ IP และฟังก์ชัน Lambda) ELB สามารถกระจายการรับส่งข้อมูลด้วยโหลดที่แตกต่างกันทั้งภายใน Availability Zone เดียวและข้าม Availability Zone หลายแห่ง ผู้ใช้สามารถเลือกจากบาลานเซอร์สามประเภทที่มีความพร้อมใช้งานสูง การปรับขนาดอัตโนมัติ และการป้องกันที่ดี ทั้งหมดนี้เป็นสิ่งสำคัญเพื่อให้มั่นใจถึงความทนทานต่อความเสียหายของแอปพลิเคชันของคุณ
ข้อได้เปรียบหลัก:
- ความพร้อมใช้งานสูง. ข้อตกลงการบริการถือว่ามีความพร้อมใช้งาน 99,99% สำหรับโหลดบาลานเซอร์ ตัวอย่างเช่น Availability Zone หลายแห่งช่วยให้แน่ใจว่าการรับส่งข้อมูลจะได้รับการประมวลผลโดยออบเจ็กต์ที่สมบูรณ์เท่านั้น ในความเป็นจริง คุณสามารถปรับสมดุลการโหลดทั่วทั้งภูมิภาค โดยเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังเป้าหมายที่ดีในโซนความพร้อมใช้งานที่แตกต่างกัน
- ความปลอดภัย. ELB ทำงานร่วมกับ Amazon VPC โดยมอบความสามารถด้านความปลอดภัยที่หลากหลาย - การจัดการใบรับรองแบบผสานรวม การตรวจสอบสิทธิ์ผู้ใช้ และการถอดรหัส SSL/TLS ทั้งหมดนี้ให้การจัดการการตั้งค่า TLS แบบรวมศูนย์และยืดหยุ่น
- ความยืดหยุ่น. ELB สามารถจัดการกับการเปลี่ยนแปลงการรับส่งข้อมูลเครือข่ายกะทันหันได้ และการผสานรวมอย่างลึกซึ้งกับ Auto Scaling จะทำให้แอปพลิเคชันมีทรัพยากรเพียงพอหากโหลดเปลี่ยนแปลง โดยไม่ต้องมีการแทรกแซงด้วยตนเอง
- มีความยืดหยุ่น. คุณสามารถใช้ที่อยู่ IP เพื่อกำหนดเส้นทางคำขอไปยังเป้าหมายแอปพลิเคชันของคุณได้ ซึ่งให้ความยืดหยุ่นเมื่อจำลองแอปพลิเคชันเป้าหมาย ทำให้สามารถโฮสต์หลายแอปพลิเคชันบนอินสแตนซ์เดียวได้ เนื่องจากแอปพลิเคชันสามารถใช้พอร์ตเครือข่ายเดียวและมีกลุ่มความปลอดภัยแยกกัน การสื่อสารระหว่างแอปพลิเคชันจึงง่ายขึ้นเมื่อเรามีสถาปัตยกรรมที่ใช้ไมโครเซอร์วิส
- การติดตามและตรวจสอบ. คุณสามารถตรวจสอบแอปพลิเคชันแบบเรียลไทม์ได้โดยใช้คุณสมบัติ Amazon CloudWatch เรากำลังพูดถึงตัวชี้วัด บันทึก การติดตามคำขอ พูดง่ายๆ ก็คือ คุณจะสามารถระบุปัญหาและระบุจุดคอขวดของประสิทธิภาพได้ค่อนข้างแม่นยำ
- การปรับสมดุลโหลดแบบไฮบริด. ความสามารถในการโหลดบาลานซ์ระหว่างทรัพยากรในองค์กรและ AWS โดยใช้โหลดบาลานเซอร์เดียวกัน ทำให้การโยกย้ายหรือขยายแอปพลิเคชันในองค์กรไปยังระบบคลาวด์เป็นเรื่องง่าย การจัดการความล้มเหลวยังทำได้ง่ายขึ้นโดยใช้ระบบคลาวด์
หากคุณสนใจรายละเอียด ต่อไปนี้คือลิงก์ที่เป็นประโยชน์อีกสองสามลิงก์จากเว็บไซต์อย่างเป็นทางการของ Amazon:
- .
ที่มา: will.com