0Pricing
AWS Solutions Architect · บทเรียน

Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์

เรียกใช้ฟังก์ชันที่ตำแหน่ง Edge ของ CloudFront และเชื่อม Lambda กับ SQS, SNS, DynamoDB Streams และ Kinesis เพื่อสร้างสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์

Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์ เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

Lambda@Edge คืออะไร

Lambda@Edge ช่วยให้คุณเรียกใช้ฟังก์ชัน Lambda ที่ ตำแหน่ง Edge ของ CloudFront ทั่วโลก ซึ่งอยู่ใกล้ผู้ใช้ปลายทางมากกว่า แทนที่จะทำงานใน Region ส่วนกลาง วิธีนี้ทำให้คุณปรับแต่งคำขอและการตอบกลับ HTTP ได้ โดยมีเวลาแฝงเพิ่มที่ระดับ CDN ต่ำกว่าหนึ่งมิลลิวินาที ฟังก์ชัน Lambda@Edge จะถูกนำไปใช้งานทั่วโลกและถูกเรียกใช้เมื่อเกิดเหตุการณ์แคชของ CloudFront ทั้งกรณีพบและไม่พบข้อมูล จึงเหมาะสำหรับงานปรับแต่งคำขอที่มีน้ำหนักเบา

จุดทริกเกอร์ทั้งสี่ของ CloudFront

Lambda@Edge สามารถดักจับทราฟฟิกได้สี่จุดในวงจรชีวิตคำขอของ CloudFront:

  • คำขอจากผู้ชม: ทำงานเมื่อ CloudFront ได้รับคำขอจากผู้ชม (ผู้ใช้) ก่อนตรวจสอบแคช
  • คำขอไปยังต้นทาง: ทำงานเมื่อ CloudFront ส่งต่อคำขอที่ไม่พบในแคชไปยังต้นทาง
  • การตอบกลับจากต้นทาง: ทำงานเมื่อต้นทางส่งการตอบกลับกลับมา ก่อนจัดเก็บลงแคช
  • การตอบกลับไปยังผู้ชม: ทำงานก่อนที่ CloudFront จะส่งการตอบกลับคืนให้ผู้ชม

ข้อจำกัดของ Lambda@Edge เมื่อเทียบกับ Lambda ปกติ

Lambda@Edge มีข้อจำกัดที่เข้มงวดกว่า Lambda ปกติ: หน่วยความจำสูงสุด 128 MB (เหตุการณ์จากผู้ชม), 1 GB (เหตุการณ์จากต้นทาง), หมดเวลาสูงสุด 5 วินาที (ผู้ชม) และ 30 วินาที (ต้นทาง) ต้องสร้างฟังก์ชันใน us-east-1 และนำไปใช้งานที่ Edge ผ่าน CloudFront ไม่รองรับ VPC ไม่มีตัวแปรสภาพแวดล้อม และไม่มี Lambda Layers ข้อจำกัดเหล่านี้หมายความว่า Lambda@Edge ออกแบบมาสำหรับการแปลงข้อมูลที่มีน้ำหนักเบา ไม่ใช่การประมวลผลหนัก

กรณีการใช้งานทั่วไปของ Lambda@Edge

Lambda@Edge เหมาะอย่างยิ่งสำหรับ: การทดสอบ A/B (เขียน URL ใหม่ให้ชี้ไปยังเส้นทางต้นทางที่ต่างกันตามคุกกี้), การตรวจสอบสิทธิ์ (ตรวจสอบ JWT ที่ Edge ก่อนส่งต่อไปยังต้นทาง), การจัดการส่วนหัว HTTP (เพิ่มส่วนหัวด้านความปลอดภัย เช่น HSTS, CSP และ X-Frame-Options), การปรับ URL ให้เป็นมาตรฐาน (เปลี่ยนเส้นทางจาก www ไปยัง non-www หรือบังคับใช้เครื่องหมายทับท้าย) และ การปรับเนื้อหาเฉพาะบุคคล (แสดงเนื้อหาที่ต่างกันตามประเทศของผู้ชมจากส่วนหัว CloudFront-Viewer-Country)

// Viewer Request: Add security headers
exports.handler = async (event) => {
    const response = event.Records[0].cf.response;
    response.headers['strict-transport-security'] = [{
        key: 'Strict-Transport-Security',
        value: 'max-age=63072000; includeSubdomains; preload'
    }];
    response.headers['x-frame-options'] = [{
        key: 'X-Frame-Options',
        value: 'DENY'
    }];
    return response;
};

CloudFront Functions เทียบกับ Lambda@Edge

CloudFront Functions คือฟังก์ชัน JavaScript ที่มีน้ำหนักเบามาก ซึ่งทำงานเฉพาะในขั้นคำขอและการตอบกลับจากผู้ชม โดยมีเวลาการทำงานจำกัดที่ 2 ms และมีค่าใช้จ่ายต่ำกว่ามาก สำหรับกรณีการใช้งานง่าย ๆ เช่น การเขียน URL ใหม่ การจัดการส่วนหัว และการปรับคีย์แคชให้เป็นมาตรฐาน ควรเลือก CloudFront Functions แทน Lambda@Edge เพราะทำงานเร็วกว่าและมีราคาถูกกว่า ใช้ Lambda@Edge เมื่อต้องการเรียกใช้การเชื่อมต่อเครือข่าย รองรับข้อมูลที่มีขนาดใหญ่กว่า หรือต้องใช้จุดทริกเกอร์คำขอและการตอบกลับจากต้นทาง

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ด้วย Lambda

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ เชื่อมต่อบริการต่าง ๆ ผ่านเหตุการณ์ ซึ่งเป็นข้อความที่แสดงถึงสิ่งที่เกิดขึ้น ใน AWS นั้น Lambda เป็นผู้บริโภคเหตุการณ์หลัก โดยรับเหตุการณ์จาก SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge และบริการอื่น ๆ แต่ละเหตุการณ์จะทริกเกอร์การทำงานของ Lambda ทำให้ระบบตอบสนองแบบอะซิงโครนัสและเป็นอิสระต่อกันได้โดยไม่ต้องเชื่อมโยงกันอย่างแน่นหนา รูปแบบนี้ช่วยให้เกิด การเชื่อมโยงแบบหลวม การปรับขนาดอย่างเป็นอิสระ และ การแยกความเสียหาย

Lambda ในฐานะผู้บริโภค SQS

สามารถกำหนดค่า Lambda ให้เป็น การแมปแหล่งเหตุการณ์ สำหรับ SQS ได้ Lambda จะสำรวจคิว ดึงข้อความได้สูงสุดตาม ขนาดชุด (สูงสุด 10,000 รายการสำหรับคิวมาตรฐาน และ 10 รายการสำหรับ FIFO) และเรียกใช้ฟังก์ชันหนึ่งครั้งต่อหนึ่งชุด หากฟังก์ชันทำงานล้มเหลว ชุดทั้งหมดจะถูกส่งกลับไปยังคิว กำหนดค่า ช่วงเวลารอชุด เพื่อรอข้อความเพิ่มเติมก่อนเรียกใช้ ซึ่งจะช่วยเพิ่มปริมาณงาน ใช้ DLQ กับคิว SQS ต้นทางสำหรับข้อความที่ล้มเหลวซ้ำ ๆ

aws lambda create-event-source-mapping \
  --function-name 'OrderProcessor' \
  --event-source-arn 'arn:aws:sqs:us-east-1:123456789012:OrderQueue' \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 5

Lambda กับ DynamoDB Streams

DynamoDB Streams จะบันทึกการเปลี่ยนแปลงทุกระดับรายการ (INSERT, MODIFY, REMOVE) เป็นลำดับเหตุการณ์ตามลำดับ Lambda อ่านข้อมูลจากสตรีมโดยใช้ การแมปแหล่งเหตุการณ์ ร่วมกับ TRIM_HORIZON (เริ่มจากข้อมูลเก่าที่สุด) หรือ LATEST (เริ่มจากข้อมูลใหม่ล่าสุด) Lambda จะประมวลผลระเบียน ตามลำดับภายในพาร์ทิชัน ชุดที่ล้มเหลวจะขัดขวางการประมวลผลเพิ่มเติมของพาร์ทิชันเดียวกันจนกว่าจะแก้ไข ให้ใช้ การแบ่งชุดเมื่อเกิดข้อผิดพลาด เพื่อแยกชุดที่ล้มเหลวและแยกระเบียนที่มีปัญหา

aws lambda create-event-source-mapping \
  --function-name 'StreamProcessor' \
  --event-source-arn 'arn:aws:dynamodb:us-east-1:123456789012:table/Orders/stream/...' \
  --starting-position TRIM_HORIZON \
  --batch-size 100 \
  --bisect-batch-on-function-error

Lambda กับ Kinesis Data Streams

Lambda ประมวลผลระเบียน Kinesis ในลักษณะเดียวกับ DynamoDB Streams โดยมีการทำงานพร้อมกันหนึ่งรายการต่อชาร์ด ตัวเลือกการกำหนดค่าหลัก ได้แก่ ปัจจัยการประมวลผลแบบขนาน (การเรียกใช้ Lambda พร้อมกันสูงสุด 10 รายการต่อชาร์ด โดยประมวลผลชุดย่อยแบบขนาน) และ การกระจายงานแบบขยายประสิทธิภาพ (ปริมาณงานเฉพาะ 2 MB/s ต่อชาร์ดสำหรับผู้บริโภค Lambda) ตัวเลือกเหล่านี้ช่วยเพิ่มปริมาณงานสำหรับสตรีมที่มีปริมาณสูงได้อย่างมากโดยไม่ต้องเพิ่มจำนวนชาร์ด

EventBridge ในฐานะเราเตอร์เหตุการณ์

Amazon EventBridge คือบัสเหตุการณ์ที่แนะนำสำหรับเชื่อมต่อบริการ AWS และแอปพลิเคชันแบบกำหนดเอง เหตุการณ์จะไหลเข้าสู่บัส จากนั้น กฎ จะกรองเหตุการณ์ตามรูปแบบและส่งต่อไปยังเป้าหมาย เช่น Lambda, SQS, Step Functions และบริการอื่น ๆ EventBridge แยกผู้สร้างเหตุการณ์ออกจากผู้บริโภคอย่างสมบูรณ์ โดยทั้งสองฝ่ายไม่จำเป็นต้องรู้จักกัน บัสเหตุการณ์เริ่มต้นจะรับเหตุการณ์จากบริการ AWS ส่วนเหตุการณ์ของแอปพลิเคชันให้สร้าง บัสเหตุการณ์แบบกำหนดเอง

aws events put-rule \
  --name 'OrderPlacedRule' \
  --event-pattern '{"source": ["com.myapp.orders"], "detail-type": ["OrderPlaced"]}' \
  --state ENABLED

aws events put-targets \
  --rule 'OrderPlacedRule' \
  --targets 'Id=LambdaTarget,Arn=arn:aws:lambda:us-east-1:123456789012:function:InventoryUpdater'

รูปแบบการกระจายงาน: SNS ไปยัง Lambda หลายรายการ

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

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Lambda@Edge เรียกใช้ฟังก์ชันที่ตำแหน่ง Edge ของ CloudFront โดยมีจุดทริกเกอร์สี่จุด ได้แก่ คำขอและการตอบกลับจากผู้ชม รวมถึงคำขอและการตอบกลับจากต้นทาง สำหรับงานต่าง ๆ เช่น การตรวจสอบสิทธิ์ การเขียน URL ใหม่ และการจัดการส่วนหัว CloudFront Functions เป็นทางเลือกที่มีค่าใช้จ่ายและเวลาแฝงต่ำกว่าสำหรับการแปลงข้อมูลง่าย ๆ ในขั้นผู้ชม และ รูปแบบที่ขับเคลื่อนด้วยเหตุการณ์ ซึ่งใช้ SQS, DynamoDB Streams, Kinesis, EventBridge และการกระจายงานผ่าน SNS ช่วยให้เกิดสถาปัตยกรรมที่เชื่อมโยงกันแบบหลวม โดย Lambda ตอบสนองต่อเหตุการณ์แบบเรียลไทม์ บทถัดไปเราจะศึกษาเรื่องคิว SQS Standard เทียบกับ FIFO

คำถามที่พบบ่อย

บทเรียน “Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์”

เรียกใช้ฟังก์ชันที่ตำแหน่ง Edge ของ CloudFront และเชื่อม Lambda กับ SQS, SNS, DynamoDB Streams และ Kinesis เพื่อสร้างสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ฟังก์ชัน Lambda: รันไทม์ ทริกเกอร์ และตัวจัดการ
  2. การทำงานพร้อมกัน การจำกัดอัตรา และการทำงานพร้อมกันที่จองไว้
  3. เลเยอร์ Lambda และแพ็กเกจการนำไปใช้งาน
  4. Lambda@Edge และรูปแบบที่ขับเคลื่อนด้วยเหตุการณ์
← กลับไปที่ AWS Solutions Architect