Azure Functions: ทริกเกอร์ ไบนดิง และการโฮสต์แบบเข้าใจง่าย

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

ตัวอย่างเช่น ฟังก์ชันสามารถรันเมื่อมีคำขอ HTTP เข้ามา เมื่อมีการอัปโหลดไฟล์ไปยังสตอเรจ หรือเมื่อถึงเวลาตามกำหนดการ

คำว่า “ไร้เซิร์ฟเวอร์” ไม่ได้แปลว่าไม่มีเซิร์ฟเวอร์อยู่เลย แต่หมายความว่า Azure จัดการโครงสร้างพื้นฐานให้ทั้งหมด ตั้งแต่การจัดเตรียม ทยอยขยายขนาด และบำรุงรักษาเบื้องหลัง

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

Azure Functions คืออะไร?

Azure Function คือโค้ดขนาดเล็กที่รันเมื่อถูกทริกเกอร์โดยเหตุการณ์ที่เลือก กำหนดลอจิกเองได้ และให้ Azure จัดการส่วนที่เหลือทั้งหมด

โมเดลนี้กำหนดด้วยแนวคิดหลัก 3 ประการ

1. การประมวลผลแบบขับเคลื่อนด้วยเหตุการณ์ ทำให้โค้ดรันเฉพาะเมื่อมีสิ่งเกิดขึ้น ไม่ได้รันตลอดเวลา
2. การสเกลอัตโนมัติ ทำให้ Azure เพิ่มหรือลดทรัพยากรคอมพิวต์ตามปริมาณงาน
3. การคิดค่าบริการตามการใช้งานจริง บนแผนโฮสต์บางประเภทจะจ่ายเฉพาะเวลาที่โค้ดรันจริงเท่านั้น

ฟังก์ชันหนึ่งควรทำงานย่อยหนึ่งอย่างให้จบ เช่น ปรับขนาดรูปภาพหรือประมวลผลข้อความ ส่วน Function App คือคอนเทนเนอร์ที่บรรจุฟังก์ชันหนึ่งหรือมากกว่า และจัดการการตั้งค่าร่วมกัน เช่น การกำหนดค่าและการดีพลอย สำหรับทุกฟังก์ชันภายใน

การทำงานของ Azure Functions

วงจรชีวิตของฟังก์ชันสามารถมองเป็นรูปแบบง่าย ๆ ดังนี้:

1. เกิดเหตุการณ์ เช่น มีการอัปโหลดไฟล์หรือมีการเรียก HTTP
2. ทริกเกอร์ตรวจจับเหตุการณ์และเริ่มฟังก์ชันทันที
3. ฟังก์ชันรันโค้ดของตน
4. ไบนดิงเชื่อมฟังก์ชันเข้ากับบริการอื่นเพื่ออ่านอินพุตหรือส่งเอาต์พุตที่ต้องการ
5. Azure จัดการทรัพยากรคอมพิวต์เบื้องหลังตามแผนการโฮสต์ที่เลือก

โฟลว์นี้เหมือนกันไม่ว่าภาษาใดหรือตัวเลือกการโฮสต์ใด (ในขั้นตอนส่วนใหญ่ตามที่กล่าว) ที่เปลี่ยนมีเพียงทริกเกอร์ โค้ด และไบนดิง

ทริกเกอร์ของ Azure Functions

ทุกฟังก์ชันต้องมีทริกเกอร์เพียงหนึ่งเดียว ทริกเกอร์กำหนดว่าฟังก์ชันเริ่มอย่างไร ประเภทที่พบบ่อยที่ควรรู้มีดังนี้:

• HTTP Trigger: รันฟังก์ชันเมื่อได้รับคำขอ HTTP มักใช้สร้าง API
• Timer Trigger: รันฟังก์ชันตามกำหนดเวลา เช่น ทุกชั่วโมงหรือวันละครั้ง
• Blob Storage Trigger: รันฟังก์ชันเมื่อมีการเพิ่มหรือเปลี่ยนไฟล์ใน Azure Blob Storage
• Queue Trigger: รันฟังก์ชันเมื่อมีข้อความใหม่มาถึงในคิว
• Event Hub Trigger: รันฟังก์ชันเพื่อตอบสนองต่อสตรีมของเหตุการณ์ เหมาะมากกับข้อมูลปริมาณสูง

ไบนดิงของ Azure Functions

ทริกเกอร์กับไบนดิงมักถูกสับสน แม้ดูคล้ายกันแต่ทำหน้าที่ต่างกันโดยสิ้นเชิง ทริกเกอร์เริ่มฟังก์ชัน ส่วนไบนดิงเชื่อมฟังก์ชันเข้ากับข้อมูล โดยอ่านหรือส่งต่อข้อมูลนั้น

Input bindings

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

Output bindings

ใช้ส่งผลลัพธ์ของฟังก์ชันไปที่อื่น ตัวอย่างเช่น เขียนข้อความที่ประมวลผลแล้วลงในคิว

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

วิธีสร้าง Azure Function แรกของคุณ

นี่คือตัวอย่างง่าย ๆ ของฟังก์ชันที่ทริกเกอร์ด้วย HTTP และส่งคำทักทายกลับ ขั้นตอนคือ:

1. สร้าง Function App ซึ่งเป็นคอนเทนเนอร์สำหรับฟังก์ชันบน Azure
2. เลือกรันไทม์และภาษาที่ต้องการเขียนโค้ด
3. สร้างฟังก์ชันเพื่อเพิ่มฟังก์ชันใหม่ภายใน Function App ของคุณ
4. เลือก HTTP trigger เพื่อให้ฟังก์ชันตอบสนองต่อคำขอจากเว็บได้
5. เพิ่มความสามารถง่าย ๆ เช่น อ่านชื่อจากคำขอและส่งกลับ “Hello, [name].”
6. รันและทดสอบฟังก์ชันด้วยเครื่องมือทดสอบในตัว หรือส่งคำขอจากเบราว์เซอร์ก็ได้
7. ดีพลอยขึ้น Azure เพื่อให้ใช้งานจริงและเข้าถึงได้

ตัวอย่างนี้ตั้งใจทำให้เล็กเพื่อให้เห็นรูปแบบ แล้วต่อยอดได้ตามต้องการ

ภาษาที่ Azure Functions รองรับ

Azure Functions รองรับหลายภาษา เช่น:

• C#
• JavaScript/TypeScript
• Python
• Java
• PowerShell

การซัพพอร์ตและโมเดลการพัฒนาอาจแตกต่างกันไปตามภาษาและเวอร์ชัน แนะนำให้ตรวจสอบ เอกสาร Azure ปัจจุบันก่อนเริ่มโปรเจ็กต์ใหม่ เนื่องจากรายละเอียดเหล่านี้เปลี่ยนบ่อย

ตัวเลือกการโฮสต์ของ Azure Functions

ไม่ใช่ทุก Azure Function จะรันเหมือนกัน Azure จึงมีแผนการโฮสต์หลากหลาย โดยแต่ละแบบมีข้อแลกเปลี่ยนต่างกันให้เลือกตามเคสงานของคุณ ข้อแลกเปลี่ยน ได้แก่:

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

การสเกลและการสตาร์ทเย็น (Cold Start) ใน Azure Functions

มีอีกสองแนวคิดที่สำคัญเมื่อฟังก์ชันรันในระบบจริง ได้แก่:

การสเกลอัตโนมัติ

Azure จะเฝ้าดูปริมาณงานของฟังก์ชัน เมื่อความต้องการเพิ่มขึ้นก็เพิ่มอินสแตนซ์คอมพิวต์ และเมื่อความต้องการลดลงก็ลดลง โดยไม่ต้องจัดการเอง

การสตาร์ทเย็น (Cold start)

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

กรณีใช้งานทั่วไปของ Azure Functions

โมเดลแบบขับเคลื่อนด้วยเหตุการณ์เหมาะกับปัญหาทั่วไปหลายอย่าง เช่น:

API และเว็บฮุค

รองรับคำขอ HTTP ขาเข้าโดยไม่ต้องรันเว็บเซิร์ฟเวอร์ตลอดเวลา

การประมวลผลไฟล์และรูปภาพ

ทริกเกอร์ฟังก์ชันเมื่อมีไฟล์เข้าสู่สตอเรจ แล้วปรับขนาด แปลงรูปแบบ หรือสแกนไฟล์นั้น

งานตามกำหนดเวลา

รันงานล้างข้อมูล รายงาน หรือการเตือนตามตัวจับเวลา โดยไม่ต้องมีเซิร์ฟเวอร์ที่เปิดตลอดเวลา

ไปป์ไลน์ประมวลผลข้อมูล

ประมวลผลข้อความหรือเหตุการณ์เมื่อมาถึงทีละขั้นตอน

IoT และการประมวลผลเหตุการณ์

รองรับข้อมูลจากเซนเซอร์หรืออุปกรณ์ปริมาณมากขณะสตรีมเข้ามา

งานเบื้องหลัง

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

การมอนิเตอร์และแก้ปัญหา Azure Functions

เมื่อฟังก์ชันเผยแพร่ใช้งานแล้ว จำเป็นต้องมีการมองเห็นการทำงานว่าดำเนินไปอย่างไร

สามารถดูบันทึกเหตุการณ์ (logs) ของการรันแต่ละครั้ง ซึ่งมีประโยชน์มากในการดีบัก และตรวจสอบ Application Insights ในเครื่องมือของ Azure ซึ่งติดตามประสิทธิภาพ คำขอ และความล้มเหลวในที่เดียว

ควรติดตามความล้มเหลวของการเรียกใช้งาน (invocation) เพื่อรู้ว่าฟังก์ชันไม่เสร็จเพราะเหตุใดและเมื่อใด การมอนิเตอร์ประสิทธิภาพยังช่วยระบุฟังก์ชันที่ช้าก่อนจะกลายเป็นปัญหา และสามารถกำหนดพฤติกรรมการลองใหม่ (retry) ให้การรันที่ล้มเหลวลองใหม่โดยอัตโนมัติ

สรุป

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

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