Cloud
น้องๆ หลายคนคงคุ้นเคยกับ AWS Lambda ในฐานะ Serverless Function ที่เอาไว้รันโค้ดสั้นๆ ตอบสนองต่อ Event ต่างๆ เช่น มีไฟล์อัพโหลดขึ้น S3 ก็ให้ Lambda ทำงานประมวลผลรูปภาพ แต่พอใช้งานจริงจัง จะเจอปัญหาที่ Lambda แบบพื้นฐานแก้ไม่ได้ หรือแก้ได้แต่ไม่สวยงามเท่าที่ควร
ตรงนี้แหละที่ Advanced Patterns เข้ามาช่วย! มันคือเทคนิคและแนวทางการออกแบบ Lambda Function ให้ทำงานได้อย่างมีประสิทธิภาพ, scalable, maintainable และรองรับ use case ที่ซับซ้อนมากขึ้น สมัยผมทำร้านเน็ต SiamCafe ก็เคยเจอเคสลูกค้าอยากได้ระบบคิดเงินตามชั่วโมงการใช้งานแบบ Realtime ซึ่งถ้าใช้ Lambda แบบพื้นๆ คงปวดหัวน่าดู
ทำไมถึงสำคัญน่ะเหรอ? ลองนึกภาพว่าน้องๆ สร้างระบบใหญ่ๆ ที่มี Lambda เป็นร้อยๆ ตัว ถ้าเขียนแบบไม่คิดอะไรเลย ระบบจะกลายเป็น Spaghetti Code ที่แก้กันไม่หวาดไม่ไหว Advanced Patterns ช่วยให้น้องๆ ออกแบบระบบให้เป็นระเบียบ, debug ง่าย และปรับปรุงต่อยอดได้ในอนาคต
Lambda ส่วนใหญ่มักจะทำงานแบบ Asynchronous หมายความว่า Event trigger Lambda แล้ว Lambda ก็ทำงานของมันไป โดยไม่ต้องรอให้ Lambda ทำงานเสร็จ Event ก็จบไปแล้ว ตรงนี้สำคัญมาก เพราะถ้าเราต้องการให้ Lambda ทำงานต่อเนื่องกันหลายๆ ขั้นตอน เราต้องใช้เทคนิคเช่น Step Functions หรือ SQS เข้ามาช่วย
Lambda Layers คือที่ที่เราเอา Library หรือ Dependencies ต่างๆ ที่ Lambda ต้องใช้ มารวมกันไว้ แล้ว Lambda ทุกตัวก็แชร์ Layer เดียวกัน ทำให้ไม่ต้องอัพโหลด Dependencies ซ้ำๆ ในทุก Lambda ลดขนาดของ Lambda Function และทำให้ Deployment เร็วขึ้น สมัยก่อนตอนผมทำ SiamCafe ถ้าต้องลง Font ใหม่ในทุกเครื่องนี่เหนื่อยเลย Lambda Layers ก็คล้ายๆ กัน
AWS Lambda มี Concurrent Execution Limit ซึ่งจำกัดจำนวน Lambda Function ที่รันพร้อมๆ กันได้ ถ้ามี Request เข้ามาเยอะเกิน Limit Lambda จะ Throw Error ออกมา เราต้องเข้าใจเรื่องนี้ เพื่อออกแบบระบบให้ Scalable และ Handle Error ได้อย่างถูกต้อง
การเริ่มต้นใช้งาน Advanced Patterns ไม่ได้ยากอย่างที่คิดครับ สิ่งสำคัญคือต้องเข้าใจโจทย์ปัญหาที่เราต้องการจะแก้ก่อน แล้วค่อยเลือก Pattern ที่เหมาะสมมาใช้
Choreography Pattern คือการออกแบบระบบที่ Lambda Function แต่ละตัวทำงานเป็นอิสระต่อกัน โดยสื่อสารกันผ่าน Event ตัวอย่างเช่น เมื่อมี Order ใหม่เข้ามา Lambda ตัวแรกจะสร้าง Record ใน Database แล้ว Publish Event "OrderCreated" ออกมา Lambda ตัวที่สองจะ Subscribe Event นี้ แล้วส่ง Email แจ้งลูกค้า Lambda ตัวที่สามก็จะ Subscribe Event นี้ แล้วตัด Stock สินค้า
import boto3
import json
sqs = boto3.client('sqs')
queue_url = 'YOUR_SQS_QUEUE_URL'
def lambda_handler(event, context):
try:
message = {
'order_id': '12345',
'customer_email': 'test@example.com',
'items': ['item1', 'item2']
}
response = sqs.send_message(
QueueUrl=queue_url,
MessageBody=json.dumps(message)
)
print(f"Message sent to SQS: {response['MessageId']}")
return {
'statusCode': 200,
'body': json.dumps('Order processed and message sent to SQS!')
}
except Exception as e:
print(f"Error: {e}")
return {
'statusCode': 500,
'body': json.dumps(f'Error processing order: {e}')
}
Orchestration Pattern คือการใช้ AWS Step Functions เพื่อควบคุม Workflow ของ Lambda Function Step Functions จะกำหนดลำดับการทำงานของ Lambda แต่ละตัว และ Handle Error ในกรณีที่ Lambda ตัวใดตัวหนึ่ง Fail วิธีนี้เหมาะกับ Use Case ที่ต้องการความแน่นอนและ Transactional Consistency
Lambda Layers ช่วยให้เราจัดการ Dependencies ได้ง่ายขึ้น สร้าง Layer โดยการ Zip ไฟล์ Dependencies แล้ว Upload ขึ้น AWS จากนั้น Configure Lambda Function ให้ใช้ Layer ที่เราสร้างไว้
# Example Dockerfile for creating a Lambda Layer
FROM public.ecr.aws/lambda/python:3.9
# Set the working directory
WORKDIR /var/task
# Copy the requirements file
COPY requirements.txt .
# Install the dependencies
RUN pip install -r requirements.txt -t .
# Create the zip archive
RUN zip -r layer.zip .
# You can then upload layer.zip to AWS Lambda Layers
ดูวิดีโอเพิ่มเติมเกี่ยวกับAws Lambda Advanced Patterns:
AWS Lambda ไม่ได้เป็นทางเลือกเดียวสำหรับการรันโค้ดบน Cloud ยังมีทางเลือกอื่นๆ อีกมากมาย เช่น AWS EC2, AWS ECS, AWS Fargate แต่ละทางเลือกก็มีข้อดีข้อเสียแตกต่างกันไป
| ทางเลือก | ข้อดี | ข้อเสีย | เหมาะกับ |
|---|---|---|---|
| AWS Lambda | Serverless, Scalable, Pay-per-use | Limited execution time, Cold start | Event-driven tasks, Microservices |
| AWS EC2 | Full control, Customizable | Requires server management, Higher cost | Long-running applications, Complex configurations |
| AWS ECS/Fargate | Containerized applications, Scalable | Requires container management, Moderate cost | Microservices, Web applications |
สรุปคือ ถ้างานของน้องๆ เป็น Event-driven, ใช้เวลารันไม่นาน และต้องการ Scalability สูง AWS Lambda คือตัวเลือกที่ดี แต่ถ้าต้องการ Control แบบเต็มที่ หรือมี Application ที่รันนานๆ EC2 อาจจะเหมาะสมกว่า ลองเข้าไปดูข้อมูลเพิ่มเติมที่ SiamCafe Blog นะครับ มีบทความเกี่ยวกับ Cloud Computing อีกเยอะเลย
สมัยผมทำร้านเน็ต SiamCafe ก็ต้องเลือก Server ให้เหมาะสมกับจำนวนผู้ใช้งานและความต้องการของเกมส์ต่างๆ Lambda ก็เหมือนกัน ต้องเลือกให้เหมาะกับงานที่เราจะใช้
หวังว่าบทความนี้จะเป็นประโยชน์กับน้องๆ นะครับ ถ้ามีคำถามอะไรเพิ่มเติม ถามมาได้เลย ยินดีให้คำปรึกษาเสมอ หรือจะแวะไปอ่านบทความอื่นๆ ที่ SiamCafe Blog ก็ได้นะ มีเรื่อง IT สนุกๆ อีกเยอะ
เอาล่ะน้องๆ มาถึงส่วนที่พี่จะแชร์ประสบการณ์จริงที่เจอมา สมัยทำร้านเน็ตนี่แหละ คือตอนนั้น Cloud มันยังไม่มีหรอกนะ แต่หลักการหลายๆ อย่างมันเอามาปรับใช้ได้เหมือนกัน อย่างเรื่อง Lambda นี่ พี่ว่าหัวใจสำคัญคือ "ทำให้มันเล็กเข้าไว้" คือ Function นึงทำหน้าที่เดียวจบ อย่าไปยัดทุกอย่างเข้าไปใน Function เดียว เดี๋ยวจะปวดหัวตอนแก้ปัญหา
อีกเรื่องที่สำคัญมากๆ คือเรื่อง Logging และ Monitoring สมัยก่อนพี่ใช้ Log file ธรรมดานี่แหละ แต่ Cloud นี่มีเครื่องมือให้ใช้เยอะแยะ เลือกใช้ให้เป็นประโยชน์ อย่าง CloudWatch Logs นี่แหละ ช่วยชีวิตพี่มาหลายครั้งแล้ว
1. ใช้ Lambda Layers ช่วยชีวิต สมัยก่อนนะ เวลาโปรแกรมเราต้องใช้ Library อะไรซ้ำๆ กันหลายโปรแกรม เราก็ต้อง copy library นั้นไปไว้ทุกโปรแกรม ใช่ไหม? Lambda Layers นี่แหละคือพระเอก มันคือที่เก็บ Library กลาง ที่ Lambda Function หลายๆ ตัวสามารถเรียกใช้ได้ ทำให้เราไม่ต้องเสียเวลา copy library ซ้ำๆ ลดขนาด package ของ Lambda Function เราด้วย
# ตัวอย่างการสร้าง Lambda Layer
import boto3
s3 = boto3.client('s3')
def lambda_handler(event, context):
bucket = event['bucket']
key = event['key']
response = s3.get_object(Bucket=bucket, Key=key)
content = response['Body'].read().decode('utf-8')
print(content)
return {
'statusCode': 200,
'body': 'Successfully read file from S3!'
}
2. Asynchronous Invocation คือทางออก เคยไหม Lambda Function ของเราต้องไปเรียก Function อื่นต่อ? ถ้าเรียกแบบ Synchronous คือรอให้ Function ปลายทางทำงานเสร็จก่อน Function เราถึงจะทำงานต่อได้ มันจะช้ามาก! Asynchronous Invocation นี่แหละคือคำตอบ Function เราแค่ส่งงานไปให้ Function ปลายทาง แล้วก็ทำงานของตัวเองต่อได้เลย ปล่อยให้ Function ปลายทางไปจัดการเอง
3. Dead Letter Queues (DLQ) ป้องกันข้อมูลหาย เคยเจอไหม Lambda Function ทำงานผิดพลาด แล้วข้อมูลหายไปเลย? DLQ นี่แหละคือตัวช่วย มันคือ Queue ที่เอาไว้เก็บ Event ที่ Lambda Function ประมวลผลผิดพลาด ทำให้เราสามารถตรวจสอบหาสาเหตุของ Error และนำข้อมูลกลับมาประมวลผลใหม่ได้
4. Container Image ทำให้ชีวิตง่ายขึ้น สมัยก่อนตอน deploy อะไรทีนึงนี่วุ่นวายมาก ต้อง setup environment นู่นนี่นั่น Container Image นี่แหละคือทางออก เราสามารถสร้าง Image ที่มีทุกอย่างที่ Lambda Function เราต้องการ แล้ว deploy ขึ้น Cloud ได้เลย ง่ายกว่าเดิมเยอะ
iCafeForexLambda Timeout ส่วนใหญ่เกิดจาก Function เราทำงานนานเกินไป ลองเช็คดูว่า Function เรามีการเรียก API ที่ช้าหรือเปล่า หรือมีการประมวลผลข้อมูลจำนวนมากเกินไปหรือเปล่า ถ้าเป็นไปได้ให้พยายามลดเวลาการทำงานของ Function ให้สั้นลง หรือเพิ่ม Timeout ของ Lambda Function แต่ต้องระวังเรื่อง Cost ด้วยนะ
Lambda Cold Start คือช่วงเวลาที่ Lambda Function ถูกเรียกใช้งานครั้งแรก หรือไม่ได้ถูกเรียกใช้งานมานาน AWS จะต้องเตรียม Instance ใหม่เพื่อรัน Function ของเรา ทำให้ใช้เวลานานกว่าปกติ วิธีแก้คือ Keep-Alive หรือ Provisioned Concurrency แต่ก็ต้องแลกมาด้วย Cost ที่สูงขึ้น
Lambda Permission Denied เกิดจากการที่ Lambda Function ของเราไม่มีสิทธิ์ในการเข้าถึง Resource ที่ต้องการ เช่น S3 Bucket หรือ DynamoDB Table ต้องตรวจสอบ IAM Role ที่ Lambda Function ใช้อยู่ ว่ามี Permission ที่ถูกต้องหรือไม่
SiamCafe BlogLambda นี่มันของดีจริงๆ นะน้องๆ แต่ต้องเข้าใจหลักการทำงานของมัน และรู้จัก Best Practices ต่างๆ ถึงจะใช้งานได้อย่างมีประสิทธิภาพ อย่าลืมว่าทุกอย่างมี Trade-off เลือกใช้ให้เหมาะสมกับ Requirement ของเรา แล้วชีวิตจะง่ายขึ้นเยอะ