การวิเคราะห์โดยละเอียดของ AWS Lambda

การแปลบทความจัดทำขึ้นเฉพาะสำหรับนักศึกษาของหลักสูตร “บริการคลาวด์”. สนใจพัฒนาไปในทิศทางนี้หรือไม่? ชมมาสเตอร์คลาสโดย Egor Zuev (TeamLead ที่ InBit) “บริการ AWS EC2” และเข้าร่วมกลุ่มหลักสูตรถัดไป : เริ่ม 26 กันยายนนี้

การวิเคราะห์โดยละเอียดของ AWS Lambda

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

AWS แลมบ์ดา

AWS Lambda เป็นบริการประมวลผลแบบไร้เซิร์ฟเวอร์ที่ขับเคลื่อนด้วยเหตุการณ์ ซึ่งช่วยให้คุณสามารถเรียกใช้โค้ดโดยไม่ต้องจัดเตรียมหรือจัดการเซิร์ฟเวอร์ และขยายบริการ AWS อื่นๆ โดยใช้ตรรกะที่กำหนดเอง Lambda ตอบสนองต่อเหตุการณ์ต่างๆ โดยอัตโนมัติ (เรียกว่าทริกเกอร์) เช่น คำขอ HTTP ผ่าน Amazon API Gateway การเปลี่ยนแปลงข้อมูลในบัคเก็ต Amazon S3 หรือตาราง Amazon DynamoDB หรือคุณสามารถเรียกใช้โค้ดของคุณผ่านการเรียก API โดยใช้ AWS SDK และการเปลี่ยนสถานะใน AWS Step Functions

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

เมื่อใดจึงควรเปลี่ยนไปใช้แลมบ์ดา

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

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

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

ที่นี่คุณสามารถสร้างการดำเนินการเชิงบริการที่ไม่ได้ทำงานอย่างต่อเนื่อง ตัวอย่างทั่วไปคือการปรับขนาดภาพ แม้ในกรณีของระบบแบบกระจาย ฟังก์ชัน Lambda ก็ยังคงมีความเกี่ยวข้อง

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

ความปลอดภัย

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

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

หากพูดถึง AWS Lambda โดยเฉพาะ AWS มีหน้าที่รับผิดชอบในการจัดการโครงสร้างพื้นฐาน บริการพื้นฐานที่เกี่ยวข้อง ระบบปฏิบัติการ และแพลตฟอร์มแอปพลิเคชัน ในขณะที่ลูกค้ามีหน้าที่รับผิดชอบในการรักษาความปลอดภัยของโค้ด การจัดเก็บข้อมูลที่เป็นความลับ การควบคุมการเข้าถึงข้อมูลดังกล่าว ตลอดจนบริการและทรัพยากรของ Lambda (Identity and Access Management, IAM) รวมถึงภายในขีดจำกัดของฟังก์ชันที่ใช้

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

การวิเคราะห์โดยละเอียดของ AWS Lambda

โมเดลความรับผิดชอบร่วมกันใช้ได้กับ AWS Lambda

รันไทม์แลมบ์ดา

ข้อได้เปรียบหลักของ Lambda คือการทำหน้าที่ในนามของคุณ บริการจะจัดสรรทรัพยากรที่จำเป็นเอง คุณสามารถหลีกเลี่ยงการเสียเวลาและความพยายามในการบริหารระบบและมุ่งเน้นไปที่ตรรกะทางธุรกิจและการเขียนโค้ด

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

ระนาบที่สองคือระนาบข้อมูล มันก็เหมือนกับเครื่องบินควบคุมที่มีภารกิจของตัวเอง Control Plane มี API สำหรับจัดการฟังก์ชัน (CreateFunction, UpdateFunctionCode) และควบคุมวิธีที่ Lambda สื่อสารกับบริการ AWS อื่นๆ ส่วนข้อมูลจะควบคุม Invoid API ซึ่งเรียกใช้ฟังก์ชัน Lambda หลังจากเรียกใช้ฟังก์ชันแล้ว เครื่องบินควบคุมจะจัดสรรหรือเลือกสภาพแวดล้อมรันไทม์ที่มีอยู่ซึ่งเตรียมไว้ล่วงหน้าสำหรับฟังก์ชันนั้น จากนั้นจึงรันโค้ดในนั้น

AWS Lambda รองรับภาษาการเขียนโปรแกรมที่หลากหลาย รวมถึง Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 และอื่นๆ ผ่านสภาพแวดล้อมรันไทม์ที่เกี่ยวข้อง AWS อัปเดตแพตช์รักษาความปลอดภัยเป็นประจำ และดำเนินกิจกรรมการบำรุงรักษาอื่นๆ ในสภาพแวดล้อมเหล่านี้ Lambda อนุญาตให้คุณใช้ภาษาอื่นได้เช่นกัน โดยคุณต้องใช้รันไทม์ที่เหมาะสมด้วยตนเอง แล้วคุณจะต้องดูแลบำรุงรักษารวมถึงตรวจสอบความปลอดภัยด้วย

มันทำงานอย่างไรและบริการจะทำหน้าที่ของคุณอย่างไร?

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

การวิเคราะห์โดยละเอียดของ AWS Lambda

โมเดลการแยก AWS Lambda

การแยกสภาพแวดล้อมรันไทม์ถูกนำมาใช้โดยใช้กลไกหลายประการ ที่ระดับบนสุดของแต่ละสภาพแวดล้อม จะมีสำเนาของส่วนประกอบต่อไปนี้แยกกัน:

  • รหัสฟังก์ชั่น
  • เลเยอร์ Lambda ใดๆ ที่เลือกไว้สำหรับฟังก์ชันนี้
  • สภาพแวดล้อมการดำเนินการฟังก์ชัน
  • พื้นที่ผู้ใช้ขั้นต่ำตาม Amazon Linux

กลไกต่อไปนี้ใช้เพื่อแยกสภาพแวดล้อมการดำเนินการที่แตกต่างกัน:

  • cgroups - จำกัดการเข้าถึง CPU, หน่วยความจำ, ที่เก็บข้อมูลและทรัพยากรเครือข่ายสำหรับแต่ละสภาพแวดล้อมรันไทม์
  • เนมสเปซ - การจัดกลุ่ม ID กระบวนการ, ID ผู้ใช้, อินเทอร์เฟซเครือข่าย และทรัพยากรอื่น ๆ ที่จัดการโดยเคอร์เนล Linux แต่ละรันไทม์ทำงานในเนมสเปซของตัวเอง
  • seccomp-bpf - จำกัด การเรียกของระบบที่สามารถนำมาใช้ในรันไทม์
  • iptables และตารางเส้นทาง - การแยกสภาพแวดล้อมการดำเนินการออกจากกัน
  • chroot - ให้การเข้าถึงระบบไฟล์พื้นฐานอย่างจำกัด

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

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

การบันทึกสภาพแวดล้อมและสถานะของกระบวนการ

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

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

โอนข้อมูลการโทร

Invoid API สามารถใช้ได้ในสองโหมด: โหมดเหตุการณ์และโหมดการตอบกลับคำขอ ในโหมดเหตุการณ์ การโทรจะถูกเพิ่มลงในคิวเพื่อดำเนินการในภายหลัง ในโหมดการตอบกลับคำขอ ฟังก์ชันจะถูกเรียกใช้ทันทีพร้อมกับเพย์โหลดที่ให้มา หลังจากนั้นการตอบกลับจะถูกส่งกลับ ในทั้งสองกรณี ฟังก์ชันจะทำงานในสภาพแวดล้อม Lambda แต่มีเส้นทางเพย์โหลดต่างกัน

ในระหว่างการเรียกการตอบกลับคำขอ เพย์โหลดจะไหลจาก API การประมวลผลคำขอ (ตัวเรียก API) เช่น AWS API Gateway หรือ AWS SDK ไปยังโหลดบาลานเซอร์ จากนั้นไปยังบริการเรียก Lambda (เรียกใช้บริการ) ส่วนหลังจะกำหนดสภาพแวดล้อมที่เหมาะสมสำหรับการดำเนินการฟังก์ชันและส่งผ่านเพย์โหลดที่นั่นเพื่อให้การโทรเสร็จสมบูรณ์ โหลดบาลานเซอร์รับการรับส่งข้อมูลที่มีการป้องกัน TLS ผ่านทางอินเทอร์เน็ต การรับส่งข้อมูลภายในบริการ Lambda หลังจากโหลดบาลานเซอร์แล้ว จะผ่าน VPC ภายในในภูมิภาค AWS ที่เฉพาะเจาะจง

การวิเคราะห์โดยละเอียดของ AWS Lambda

โมเดลการประมวลผลการโทร AWS Lambda: โหมดตอบกลับคำขอ

การโทรเหตุการณ์สามารถทำได้ทันทีหรือเพิ่มลงในคิว ในบางกรณี คิวจะถูกใช้งานโดยใช้ Amazon SQS (Amazon Simple Queue Service) ซึ่งส่งการเรียกไปยังบริการเติมเต็มการโทร Lambda ผ่านกระบวนการสำรวจภายใน ปริมาณการใช้งานที่ส่งได้รับการปกป้องโดย TLS และไม่มีการเข้ารหัสข้อมูลที่จัดเก็บไว้ใน Amazon SQS เพิ่มเติม

การเรียกเหตุการณ์ไม่ส่งคืนการตอบกลับ ผู้ปฏิบัติงาน Lambda เพียงแต่เพิกเฉยต่อข้อมูลการตอบกลับใดๆ การโทรตามเหตุการณ์จาก Amazon S3, Amazon SNS, CloudWatch และแหล่งที่มาอื่นๆ ได้รับการประมวลผลโดย Lambda ในโหมดเหตุการณ์ การเรียกจากสตรีม Amazon Kinesis และ DynamoDB, คิว SQS, Application Load Balancer และการเรียก API Gateway จะได้รับการประมวลผลในรูปแบบการตอบกลับคำขอ

การตรวจสอบ

คุณสามารถตรวจสอบและตรวจสอบฟังก์ชัน Lambda ได้โดยใช้กลไกและบริการต่างๆ ของ AWS รวมถึงสิ่งต่อไปนี้

อเมซอน คลาวด์วอตช์
รวบรวมสถิติต่างๆ เช่น จำนวนคำขอ ระยะเวลาของคำขอ และจำนวนคำขอที่ล้มเหลว

อเมซอน CloudTrail
ช่วยให้คุณสามารถบันทึก ตรวจสอบอย่างต่อเนื่อง และรักษาข้อมูลกิจกรรมบัญชีที่เกี่ยวข้องกับโครงสร้างพื้นฐาน AWS ของคุณ คุณจะมีประวัติการดำเนินการทั้งหมดโดยใช้ AWS Management Console, AWS SDK, เครื่องมือบรรทัดคำสั่ง และบริการของ AWS อื่นๆ

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

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

ข้อสรุป

AWS Lambda นำเสนอชุดเครื่องมืออันทรงพลังสำหรับการสร้างแอปพลิเคชันที่ปลอดภัยและปรับขนาดได้ แนวทางปฏิบัติด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดหลายประการใน AWS Lambda นั้นเหมือนกับในบริการของ AWS อื่นๆ แม้ว่าจะมีข้อยกเว้นก็ตาม ในเดือนมีนาคม 2019 Lambda ปฏิบัติตามข้อกำหนด SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) และข้อบังคับอื่นๆ ดังนั้น เมื่อคุณคิดที่จะใช้งานแอปพลิเคชันถัดไปของคุณ ให้พิจารณาใช้บริการ AWS Lambda ซึ่งอาจเหมาะสมกับงานของคุณมากที่สุด

ที่มา: will.com

เพิ่มความคิดเห็น