เพิ่งไปอ่านเจอบทความหนึ่ง เห็นน่าสนใจดี เป็นการอธิบายคุณสมบัติ Microservices คล้ายกับบทความแรกที่ผมเขียน แต่เห็นประโยชน์แต่ละข้อชัดเจนมาก และคิดว่าดัดแปลงไปใช้กับ API Service ทั่วไปได้ด้วย เลยขอบันทึกไว้สักหน่อย

1. ยึดหลักการ ทำหน้าที่เดียวเท่านั้น

แต่ละ Service หรือ API ควรออกแบบขอบเขตการทำงานให้ดี เพื่อไม่ให้เกิดความซับซ้อน และความเกี่ยวข้องกัน เพราะธุรกิจมีความเปลี่ยนแปลงอยู่ตลอดเวลา การไม่ผูกมัดกันไว้ จะง่ายกับการเปลี่ยนแปลงในอนาคต ไม่ว่าจะเปลี่ยนในเชิง Business หรือ Technical ก็ตาม

ตัวอย่าง เช่น Microservices ของแอพสั่งอาหาร ที่สามารถออกแบบตามหน้าที่การทำงานแต่ละส่วนได้ (functionality) เช่น InventoryService, OrderService, PaymentsService, UserProfileService, DeliveryNotificationService

2. แยกการเก็บ Data ออกจากกัน

การใช้ Database ร่วมกัน ก็หมายถึงการพังพร้อมกันด้วยเช่นกัน และการทำงานของแต่ละ Service อาจต้องการความเหมาะสมของ Database ต่างกันด้วย หรือลักษณะ Configuration ที่ต่างกันด้วย

ตัวอย่าง เช่น ProductService จะถูกเก็บลง MongoDB, ส่วน OrderService จะถูกเก็บด้วย PostgreSQL

ปล. ผมเคยมีคำถามในใจว่า ทำไมต้องแบ่งให้ยุ่งยาก และรู้สึกไม่เป็นประโยชน์เท่าไร, คำตอบที่ตอบตัวเองคือ ระบบเราไม่ใหญ่พอ คนใช้ไม่มากพอ ที่ควรจะต้องไปลงทุนแยก Database หรือแม้แต่ทำ Microservices

3. สื่อสารกันด้วย Asynchronous

นอกจากการเขียนโค้ดที่ลดผลกระทบต่อกันแล้ว (Loose Coupling) การสื่อสารระหว่าง Service เป็นอีกจุดที่ต้องทำ เพื่อเป็นการลดความผูกมัดกันของแต่ละ Service ได้

ตัวอย่างเช่น เมื่อบันทึก Order ลงฐานข้อมูลเสร็จแล้ว ระบบไม่จำเป็นต้องรอส่งอีเมลให้เสร็จ ถึงจะ return ว่าการทำงานนี้สำเร็จ

4. ปิดปัญหาให้ไวด้วย Circuit Breaker

ถ้า Microservice ของเราต้องไปเกี่ยวข้องกับ Service ภายนอก และจะทำงานต่อได้ ก็ต่อเมื่อต้องรอ return ผลลัพธ์จากระบบนั้นด้วย ประเด็นคือ ถ้าทำการเชื่อมต่อไม่ได้ จะต้องรอนานแค่ไหน หรือทำอย่างไรต่อ

สิ่งที่ควรทำไว้ คือ กำหนดเวลา Timeout และมีการ return ค่าเริ่มต้น (default) หรือแจ้ง error เพื่อเป็นการตัดจบ และทำ rollback, recovery ต่อไป และ Service ลักษณะแบบนี้ ควรแยกออกไปจาก Service อื่นๆ ให้ได้มากที่สุด เพื่อลดผลกระทบที่จะพังต่อกันเป็นทอดๆ

5. เรียกใช้ Microservice ผ่าน API Gateway

การใช้ API Gateway มาคั่น แทนการเชื่อมต่อโดยตรงไปที่ Microservice มีข้อดีหลายข้อนะ

• เราไม่จำเป็นต้องทำให้ Service ทุกตัวต้องมีฟังก์ชันของการ Authentication, Logging, Throttling ก็ได้ เพราะจะทำให้ทุก Service มีขนาดใหญ่ และดูแลจัดการยาก
• ลดภาระให้แก่ Client ที่จะต้องต่อหลาย Service Endpoint
• ช่วยเรื่อง Security เพื่อเป็นการปิดบัง URL ที่แท้จริงของแต่ละ Service
• เปลี่ยนแปลงฝั่ง Backend ที่ต่อกับ Microservice ในภายหลังได้ เช่น ต้องการเปลี่ยนไปใช้ Version ใหม่ ซึ่งทาง Client เองก็ไม่ต้องไปแก้ไขโค้ดใหม่
• ควบคุม incoming traffic และปฏิเสธิการเรียกใช้แบบไม่ได้รับอนุญาตได้
• กำหนด API Gateway ให้ใช้สำหรับ Internal/External เท่านั้น ก็ได้

ปล. มีข้อดีมากก็จริง แต่ข้อเสียก็มี เพราะเป็น Single point of Failure นะ, อาจเกิดคอขวดได้นะ, เป็นระบบที่ใช้ทุกคน ดังนั้น ใครดูแลล่ะ และต้องดูแลให้ดีด้วยนะ

6. ต้องแน่ใจว่า Service สามารถใช้งานกับผู้ใช้เก่าๆ ได้ (Backwards Compatible)

ถึงแม้ว่าจะออกแบบระบบเป็น Microservice และมี CI/CD ที่สามารถ deploy ระบบขึ้นไปเมื่อไรก็ได้ แต่ต้องมั่นใจว่า ผู้ใช้เก่ายังคงต้องทำงานได้อยู่ ซึ่งวิธีแก้ปัญหาที่นิยมทำกันคือ แจ้งการเปลี่ยนแปลงให้แก่ Client ทั้งหมด ว่าจะเกิดขึ้นวันไหน และตัดการรองรับใน Version เก่า เมื่อไรม แต่การแก้ปัญหาแบบนี้ จะใช้เวลาประสานงาน และบาง Client ก็อาจไม่พร้อมเปลี่ยนแปลงในเร็ววัน ทำให้ระบบเราต้องเลื่อนการ deploy ออกไปอีก

สิ่งที่แนะนำให้ทำนอกเหนือจากประสานงานข้างต้น คือการทำ Test ในส่วนของ Service เราเองให้มีส่วนที่ Coverage ทั้งการเรียกใช้แบบเก่าและแบบใหม่ รวมไปถึงการทำ Stub Data และแจ้งให้ฝั่ง Client ทำ Contract Test กับระบบเขาดูว่าสามารถใช้งานได้ปกติหรือไม่

7. ปลดระวาง Version ที่ไม่ได้ใช้ออกไป

ถึงแม้จะต้องทำให้ใช้งานกับผู้ใช้เก่าๆ (Backwards Compatible) ได้ก็จริง แต่ก็ต้องมีเงื่อนไขและเวลาที่ต้องปลดระวาง Version เก่าออกไป เพื่อลดการดูแลรักษา และการใช้ทรัพยากรหรือค่าใช้จ่ายที่ไม่จำเป็น

ปล. โดยปกติ Open API ใหญ่ๆ อย่าง Facebook จะแจ้งล่วงหน้า 1-2 ปี เพื่อให้เวลาในการ Migrate เป็น Version ซึ่งถ้าตรวจพบว่าไม่ทำ จะไม่สามารถเชื่อมต่อได้เลย

8. แยก Infrastructure Hosting ของแต่ละ Microservice ออกจากกัน

นอกเหนือจาก Database ที่ต้องแยกของแต่ละ Service แล้ว เราควรแยกการ Host ด้วย, ด้วยเหตุผลเดียวกันคือ ถ้าพัง ไม่ควรจะต้องพังไปด้วยกันหมด เช่น HDD เต็ม, HDD พัง, Memory หมด, CPU สูง เป็นต้น

และข้อดีอีกประการหนึ่งคือ บาง Service มีการเรียกใช้งานสูง เราจะสามารถ Scale ออกไปหรือเพิ่ม Spec สำหรับให้บริการเฉพาะ Service นั้นได้ เท่าที่จำเป็น

ปล. หลายที่ใช้เป็น Container เพื่อใช้งานในแต่ละ Service แต่อย่าลืมว่า 1Service 1Container ก็อาจจะพังได้ ดังนั้น เพื่อให้เกิด Availability ในระบบเรา Kubernetes อาจจะต้องเข้าแล้วหนึ่ง สภาพพพ!!

9. การ Deploy ต้องไม่เกี่ยวข้องกัน

ใน Service แต่ละตัว เมื่อไม่ผูกมัดกัน ไม่ส่งผลกระทบต่อกันแล้ว ก็จะต้องสามารถ Deploy ได้โดยที่ไม่เกี่ยวข้องกันด้วย กล่าวคือ ไม่จำเป็นว่า ต้อง Deploy A ก่อน แล้วถึงจะ Deploy B ต่อไปได้

10. สร้างประสิทธิภาพการทำงานในองค์กร

เมื่อ Microservices มีอิสระต่อกันทั้งทีมพัฒนา ทั้งการโค้ด ทั้งการออกแบบ แม้กระทั้งการ Deploy แล้ว สิ่งหนึ่งที่จะต้องปรับด้วยคือมาตรฐานในการออกแบบและเขียนโค้ด (Standards) เพื่อไม่ให้แต่ละทีมต้องเสียเวลาในการออกแบบและสร้าง Solution ของตนเองโดยไม่จำเป็น และยากกับการดูแลรักษาในอนาคตด้วย และเสียรูปแบบการทำงานร่วมกันด้วย

เรื่องนี้สำคัญมากๆนะ เพราะ Service แต่ละตัวถูกสร้างจากคนละทีม แต่ต้องทำงานร่วมกัน ดังนั้น ควรคุยกันก่อนเริ่มทำงาน เช่น API security, log aggregation, monitoring, API documentation, secrets management, config management, distributed tracing ฯลฯ

สรุป

หากเราได้ออกแบบและทำ Service ตามคำแนะนำทั้ง 10 ข้อ แล้วหละก็ เราจะได้ใช้คุณประโยชน์ของ Microservices ตามที่มันถูกคิดขึ้นมา นั่นคือ ไม่ส่งผลกระทบกัน (loosely coupled), กระจายการทำงาน (distributed) และ อิสระจากกัน (independent)

Reference

• 10 Microservices Best Practices for the Optimal Architecture Design
• รูปปกจาก https://www.360logica.com/blog/top-5-best-practices-for-testing-a-microservice-application/

bref คืออะไร

bref เป็นเครื่องมือ open source หนึ่งที่ไว้ deploy และ run serverless สำหรับภาษา PHP โดยมันไป integrate กับ Serverless Framework อีกที (แน่นอน ต้องติดตั้ง Serverless Framework ก่อน) ซึ่งปัจจุบันใช้ได้เฉพาะ AWS Lambda เท่านั้น

สิ่งที่ต้องมีในเครื่อง

• PHP 7.2+
• Composer
• AWS account (ต้องมี permission อย่างน้อย: CloudFormation, CloudWatch, Lambda, S3, API Gateway)
• Node.js

จัดแจงเตรียมเครื่องมือทำงาน

ตรียม AWS Credential Key และ Secret Code (ถ้ามีแล้ว ข้ามได้ครับ)

Install serverless (ถ้ามีแล้ว ข้ามได้ครับ)

npm install -g serverless

Config serverless with AWS (ถ้าเคยทำแล้ว ข้ามได้ครับ)

serverless config credentials --provider aws --key <key> --secret <secret>

สร้างโฟลเดอร์ที่จะใช้งาน

mkdir php-bref-function

Install bref

composer require bref/bref

ทำ PHP Function Serverless ตัวแรก

Create PHP Lambda

vendor/bin/bref init

เมื่อ Enter จะแสดงข้อความให้เลือกประเภท Lambda

What kind of lambda do you want to create? (you will be able to add more functions later by editing `serverless.yml`) [PHP function]:
  [0] PHP function
  [1] HTTP application
  [2] Console application

ในที่นี้เราจะสร้าง PHP Function สามารถกด Enter ผ่านไป หรือกดคีย์หมายเลข 0 ก็ได้ จะได้ไฟล์ประมาณนี้

Config PHP Lambda

เมื่อสร้าง Application เสร็จ ให้แก้ไขไฟล์ serverless.yml ดังนี้

โดย

provider > region : คือทวีปที่เราใช้ AWS โดยทั่วไปที่ไทยใช้เป็น ap-southeast-1
functions > php-bref-function : โดย php-bref-function ชื่อ function เราแก้ตามที่ต้องการได้เลย
functions > handler : ช่องทางแรกที่ Lambda จะเรียกทำงาน
functions > layers : เป็น custom runtime แต่ในที่นี้ bref ได้สร้างเป็น layer เพื่อเรียกใช้งาน ไม่เอามาผสมกับ core code ของเรา (ทำความเข้าใจ AWS Lambda Layer คืออะไร)

อธิบายเพิ่มเติมเกี่ยวกับ Layers
สำหรับ PHP functions ให้ระบุเป็น php-74 หรือ php-73
ใช้สำหรับสร้าง PHP function เพื่อประมวลผลเท่านั้น ไม่ใช่ HTTP Application

สำหรับ HTTP applications ให้ระบุเป็น php-74-fpm หรือ php-73-fpm
โดย runtime ตัวนี้จะใช้ PHP-FPM เพื่อทำงานแบบ HTTP applications จะเหมือนกับที่เราเขียน PHP ปกติ คือเขียนเสร็จแล้วต้องเปิดผ่าน PHP hosting หรือพวก Nginx, Apache (สามารถใช้ได้กับ Symfony และ Laravel ได้ด้วยนะ)
(Read more at https://bref.sh/docs/runtimes/#bref-runtimes)

ทดสอบ PHP Function Serverless บน localhost

เมื่อสร้างเสร็จแล้ว ลองทดสอบบนเครื่องตัวเองได้นะครับ ด้วยคำสั่งนี้

serverless invoke local --docker -f <function-name>

เปลี่ยน <function-name> ให้เป็นชื่อ function ของเรา ซึ่งที่นี้คือ php-bref-function โดยผลลัพธ์ “Hello World”

แต่ถ้าอยากส่ง data payload เข้าไป ให้ใช้คำสั่งนี้

serverless invoke local --docker -f <function-name> --data '{"name": "iFew"}'

ผลลัพธ์ที่ได้คือ “Hello iFew”

ทำการ Deploy PHP Function Serverless เพื่อทดสอบบน AWS Lambda

จะลอง Deploy ขึ้นไปทดสอบบน AWS Lambda ด้วยคำสั่ง

serverless deploy

จะได้ผลลัพธ์ประมาณนี้

สังเกตว่ามีจะมีการ pack file และทำการ upload ขึ้นไปไว้บน S3 เพื่อพักไว้ก่อน และ Deploy ไปที่ Lambda อีกที

ทดสอบอีกรอบว่า บน AWS Lambda ใช้งานได้จริงหรือไม่

serverless invoke -f <function-name>

ถ้าใช้งานได้ ก็จะแสดง output ออกมาตามที่โค้ดเราเขียนไว้

ผลการทดสอบความเร็ว ของ PHP Function Serverless ด้วย bref

ทำงานด้วย Memory 1024MB (ค่ามาตรฐาน) ได้ประมาณ​ 14-15ms

ทำงานด้วย Memory 256MB ได้ประมาณ​ 75-80ms

ทำงานด้วย Memory 128MB ได้ประมาณ​ 270-290ms

ลองทำ PHP HTTP Application Serverless ดูบ้าง

วิธีการทำแบบเดิมเลยครับ ต่างกันตอนเลือกประเภท Lambda ให้เลือกประเภท [1] HTTP application แทน พร้อมกับแก้ serverless.yml ในหัวข้อ function > layer ให้เป็น php-74-fpm หรือ php-73-fpm แทน

วิธีการทดสอบบน localhost ให้ใช้คำสั่ง ดังนี้

php -S localhost:8000 index.php

จากนั้นเปิด browser ไปที่ http://localhost:8000 จะเจอหน้าตาแบบนี้

ซึ่งเมื่อเรา Deploy ไปอยู่บน AWS Lambda ขั้นตอนของ bref จะทำการ upload ไป S3 และ deploy ไป Lambda เหมือนกับกรณี PHP Function แต่เพิ่มเติมคือ จะไปทำการสร้าง API Gateway ให้ด้วย เพื่อเป็นช่องทางการ access เข้าไปใช้งาน ไม่ว่าจะเป็น Website หรือ API (ให้ดูที่ endpoints)

ถ้าลองเปิด url ดูแล้วก็จะได้เหมือนกับที่ลองใน localhost

ส่วนผลการทดสอบความเร็ว จะไม่สามารถ invocation ได้นะครับ ต้องเปิดผ่าน API Gateway เท่านั้น

ผมลองดู SPeed Network ด้วย Chrome แต่ความเร็วที่ได้ มันผ่าน stack ชั้น API Gateway ก่อน เลยทำให้ไม่รู้ว่า AWS Lambda จริงๆทำงานเร็วแค่ไหน แต่ผลลัพธ์ที่ได้ อยู่ราวๆ 80-100ms ถือว่าเร็วเลยหละ

วิธีการลบ PHP Serverless Application บน AWS Lambda

ผมแนะนำว่าให้ใช้คำสั่งแทนนะครับ เพราะการไปลบบน AWS Lambda อย่างเดียว อาจจะไม่ครบ อาจจะต้องไปตามหาใน S3, CloudFormation, API Gateway และอาจจะหลายสิ่ง จึงแนะนำให้ใช้คำสั่งของ serverless แทน ดังนี้ครับ

serverless remove

อยากลบตัวไหน ให้เข้าไปที่ folder ของ application นั้น มันจะทำการลบตามที่เรา config ในไฟล์ serverless.yml ครับ

สรุป

ถ้าใครอยากทำ Serverless ด้วย PHP และ AWS Lambda ผมแนะนำให้ใช้ bref เลยครับ ค่อนข้างสะดวก ส่วนเรื่องความเร็วที่ได้ถือว่าประทับใจ เมื่อเทียบกับ .NET Core (ใน Memory เท่ากัน) แต่ก็ยังช้ากว่า Node.js, Go, Python

ข้อสังเกต

1. Default Memory คือ 1024MB ระวังให้ดีว่าจะเผลอเสียเงินเยอะโดยใช้เหตุครับ
2. Default Timeout คือ 6 วินาที
3. ไม่พบ Cold Start จากการ run ครั้งแรก เพราะครั้งต่อๆ ไป ก็ยังทำงานด้วยเวลาพอกัน

ตัวอย่างโค้ด

• PHP HTTP Application : https://github.com/ifew/php-bref-http
• PHP Function : https://github.com/ifew/php-bref-function

Update 27 Sep 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US East (Ohio), EU (Frankfurt), and Asia Pacific (Tokyo) – ที่มา aws.amazon.com

…

ผมเชื่อว่าใครก็ตามที่ตัดสินใจทำ Serverless มักเจอปัญหาที่แก้ไม่ตกคือ เรื่อง Cold Start ซึ่งบล็อกนี้ผมขอแชร์ประสบการณ์ที่ได้แก้ปัญหาทั้งหมด 9 วิธี เผื่อจะเป็นประโยชน์กันนะครับ (ขออ้างอิงจากผู้ให้บริการ AWS Lambda และภาษาที่ใช้พัฒนา C# .NET Core)

ทำความเข้าใจ Cold Start คืออะไร

ขอเกริ่นถึงสั้นๆ ของการทำงาน Serverless คือ เมื่อมีการร้องขอ (Request) ไปที่ Instances (เข้าใจง่ายๆ คือ Server ตัวหนึ่ง) เพื่อให้มันทำงาน มันจะใช้เวลาช่วงหนึ่งเพื่อทำการ Initial Instances จากนั้นค่อยเรียกโค้ดที่เราเขียน ขึ้นมาทำงานตามคำสั่ง

เมื่อมีการเรียกซ้ำอีก มันก็จะทำต่อเนื่องได้ทันที ไม่ต้องเสียเวลา Initial Instances ใหม่ แต่เมื่อทำงานเสร็จและปล่อยไว้สักระยะหนึ่ง เจ้า Instances ตัวนั้นก็จะเข้าสู่โหมด Idle อีก (หรือบางคนเรียกว่า หลับ, sleep) ดังนั้นเมื่อมีการร้องขอ (Request) ใช้งานอีกครั้ง จะเกิดกระบวนการ Initial Instances แบบเดิม ก่อนที่จะทำงานโค้ดของเรา

การ Initial Server ในครั้งแรก หรือครั้งหลังจากโหมด Idle นี่เอง เราจะเรียกว่า Cold Start

และมากกว่านั้น ภาษาที่ต้องมีการ Compile จะมีขั้นตอน 1-3 นานกว่าภาษา Script หลายเท่า (ผมลองพ่น Hello World โดยใช้ Node ไม่ถึง 1 วินาที, เทียบกับ .Net Core ใช้เวลา 4-5 วินาที)

และมีคำถามบ่อยๆ ว่าจะเข้าสู่โหมด Idle ภายในกี่นาที คำตอบคือ ไม่มีใครสามารถตอบได้ชัดเจน บางแหล่งก็บอก 30-45 นาที บางแหล่งก็บอก 15 นาที แต่สำหรับผมที่เล่นเอง จะเจอแถวๆ 5 นาทีเป็นต้นไป เรียกได้ว่าลุกไปเข้าห้องน้ำแป๊บนึง พอกลับมา มันก็ช้าอีกแล้ว (ผมใช้ AWS Lambda ที่ ap-southeast-1)

อ่านพื้นฐานเรื่อง Serverless และ AWS Lambda ฉบับเต็มได้ที่

• มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้

9 วิธีเพื่อใช้ลดเวลา Cold Start

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

1. เพิ่ม Memory Allocated
2. Lean and Clean Code
3. ลด และ/หรือ เลือกใช้ Dependency ที่จำเป็นและเหมาะสม
4. Warm ตัว Server ของเราตลอดเวลา
5. Warm ตัว Server ของเราตามเวลาที่เหมาะสม
6. ใช้ Custom Runtimes และเลือกใช้ Runtimes ที่ทำงานได้เร็ว
7. ใช้ Custom Runtimes และทำเป็น Native App
8. หลีกเลี่ยงการใช้ VPC ถ้าไม่จำเป็น
9. เลือกภาษาเพื่อใช้ทำ Serverless ที่เหมาะสม

1. เพิ่ม Memory Allocated

วิธีง่ายที่สุดคือใช้เงินจอง Memory ให้กับ AWS Lambda Instances มากๆ (Memory Allocated) ซึ่งมันก็เห็นผลได้เร็วและชัดเจนซะด้วย

กรณีแบบนี้ผมคิดว่าเหมาะกับการคำนวณ (Compute) ที่ไม่ได้เกิดขึ้นบ่อย แต่ต้องทำงานได้ไว และไม่ต้องการแก้ไขให้ยุ่งยาก — หรือพูดสั้นๆ คือ ยอมจ่ายค่า Memory ที่แพงขึ้น แลกกับ Duration Time ที่ลดลง แต่นานๆที เรียกใช้

กรณีนี้ผมทดลองด้วย C# .NET Core 2.1 ดึงข้อมูลจาก MySQL จำนวน 3 รายการ

สังเกตได้ว่า ยิ่งเพิ่ม Memory Allocated มากเท่าไร ก็ยิ่งลดเวลา Cold Start ได้มากเป็นเท่าตัว

แต่วิธีการนี้อาจจะไม่ดี 100% กับทุกกรณี เช่น ทดสอบแสดงข้อความ “Hello World” ด้วยภาษา Javascript ตามรูปด้านล่าง

สังเกตว่า แม้เพิ่ม Memory Allocated ไปมากเท่าใด เวลาของ Cold Start ก็ไม่ต่างกันมากนัก และ Memory สูงที่สุด ก็ไม่ได้บ่งบอกว่าจะเร็วที่สุดด้วย ดังนั้นเราจึงควรหาวิธีอื่นเพื่อลด Cold Start แทน

ถ้าให้ผมแนะนำ กรณีเพิ่ม Memory Allocated นี้ เราไม่ควรจะคาดเดา ซึ่งผมเคยเขียนวิธีการทดสอบไว้แล้ว สามารถอ่านวิธีการได้ที่ จัดสรรทรัพยากร AWS Lambda อย่างไร ให้ราคาถูกและเร็วที่สุด

2. Lean and Clean Code

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

การเรียกใช้ Config จาก JSON File วิธีนี้จะทำให้เราต้องเรียกใช้ Package Dependency จัดการไฟล์ JSON ต่างๆ ซึ่งเราสามารถย้ายไปใช้ Environment Variable แทนได้ ซึ่งถูกต้องตามหลัก The Twelve Factors ด้วย

หรือการเรียกใช้ Package Dependency เกินความจำเป็น หรือไม่ได้ใช้แล้ว แต่ลืมลบ กรณีนี้เครื่องมือดีๆ สามารถช่วยเราได้ เช่น Visual Studio ที่จะทำการแจ้งเตือนให้เราลบตัวไม่ใช้ออก

ทั้งนี้ รวมไปถึงพวก Class, Function ต่างๆ ที่เขียนไว้ แต่ไม่ได้ใช้ ก็ต้องลบออกด้วย

ยิ่งเราทำให้ขนาดโค้ดเราเล็กลงได้เท่าไร ก็ทำให้ไฟล์ที่แพ็คขึ้นสู่ AWS Lambda (Deployment Package File) เล็กลงตามเท่านั้น มันจะส่งผลเรื่อง Cold Start ที่ลดเวลาลงไปด้วย

ลองดูได้จากสถติของเว็บ mikhail.io ที่เขาใช้ Javascript ในการแสดงคำว่า “Hello World” แต่ทดลองเพิ่ม NPM packages เข้าไปใน Deployment Package File ด้วย

ผลกระทบต่อมา ถ้าเราทำให้ Deployment Package File ใหญ่ขึ้น หมายถึงการทำให้ AWS Lambda Instances ใหญ่ขึ้นตามด้วย ถ้ามาถึงขั้นนี้แล้ว แม้จะเพิ่ม Memory เข้าไปช่วยเท่าไร ก็ไม่เห็นผลนะครับ เพราะ Cold Start ยังนานเหมือนเดิม แถมเสียเงินค่า Memory เพิ่มขึ้นด้วย

3. ลด และ/หรือ เลือกใช้ Dependency ที่จำเป็นและเหมาะสม

ข้อนี้จำเป็นต้อง Debug ให้เห็นรายละเอียดก่อน เพื่อประเมินว่าอะไรคือจุดที่ทำให้โค้ดเราทำงานช้า หรืออาจจะไปดูจาก Benchmark ที่มีผู้ทดสอบเปรียบเทียบ Package ต่างๆ เพื่อที่เราจะได้เลือกใช้ได้เหมาะสมตั้งแต่เริ่มพัฒนางาน

ปกติผมเขียน .NET Core ผมจะใช้ Entity Framework (EF) Core หรือ EF Core เพราะมันเหมือนชุดมาตรฐานที่ทำงานได้เข้ากันดี และมีเครื่องมือค่อนข้างครบ แต่ปรากฎว่า EF Core นี่เอง ทำให้ใช้เวลา Cold Start มากกว่าเดิมอย่างแสนสาหัส!!

ผมฝืนใช้มันอยู่นาน และไปหาทางแก้วิธีอื่นแทน จนกลับมาเอะใจตอนที่ Compile ว่า EF Core มันตัวใหญ่นี่หว่า ผมเลยลองเปลี่ยนไปใช้ ADO.NET หรือ Micro ORM อย่าง Dapper แทน ซึ่งผลปรากฎว่า เร็วขึ้นอีก 100% เลยทีเดียว

เรื่องนี้คงไม่ขอเขียนเยอะ กราฟมันบอกชัดเจนอยู่แล้ว หากใครสนใจลองเอาไปเปรียบเทียบ สามารถดาวน์โหลดโค้ดของผมได้จากที่นี่ (ต้องใช้ .NET Core 3.0, MySQL)

• ADO.NET – https://github.com/ifew/aws-lambda-db
• Dapper – https://github.com/ifew/aws-lambda-dapper
• Entity Framework (EF) Core – https://github.com/ifew/aws-lambda-efcore

กรณี Benchmark เทียบ Database Framework ดูเพิ่มเติมได้ที่

• Dapper vs Entity Framework vs ADO.NET Performance Benchmarking
• Fetch performance of various .NET ORM / Data-access frameworks
• Entity Framework Core 2.0 vs. Dapper performance benchmark, querying SQL Azure tables

4. Warm ตัว Server ของเราตลอดเวลา

หากเรามีความจำเป็นต้องใช้ Lambda อยู่บ่อยๆ มีผู้เข้าใช้กระจัดกระจายแบบกำหนดเวลาไม่ได้ รู้แต่เข้าเมื่อไร ต้องเร็ว เช่น การแสดงรายการสินค้าของหน้าเว็บไซต์ E-Commerce เป็นต้น ถ้าสุดท้ายแล้วเราไม่สามารถแก้ไขโค้ดได้อีก หรือไม่อยากเพิ่ม Memory อีก เราก็ต้องทำให้ Server ของเราตื่นอยู่เสมอนั่นเอง

วิธีการคือ การตั้งเวลาให้มี Cronjob ไปเรียก (Ping) Server ของเราอยู่เรื่อยๆ อย่างเช่น AWS Lambda ที่ผมเจอ จะ Idle ทุกๆ 5 นาทีไปแล้ว ผมก็ต้องหา Cronjob ไปทำการ Invoke Lambda ประมาณนาทีที่ 5 เสมอ

วิธีการแบบนี้จะเปลือง Request มาก เพราะแปลว่า 1 วัน ผมจะต้องปลุกมัน 288 ครั้ง ถ้าครั้งหนึ่งต้องใช้เวลาประมวลผล (Duration Time) 2 วินาที และจอง Memory 512MB คิดดูว่าเดือนหนึ่งผมจะต้องเสียเงินไปเท่าไร

ซึ่งหากใครสนใจลองทำ วิธีนี้ค้นเจอได้ตามเว็บทั่วไป ส่วนมากจะใช้ CloudWatch ในการทำ ซึ่งผมไม่รู้ว่าทำไมถึงแนะนำให้ทำกันแบบนี้ แต่มันก็ไม่ผิดนะ ถ้าเหมาะสมกับรูปแบบงาน คือ ถ้าตัว Server เราถูกเรียกบ่อยทั้งวัน กอปรกับใช้เวลาประมวลผลไม่มาก ใช้ Memory ไม่สูง ก็อาจจะเหมาะสม

สามารถดูเพิ่มเติมได้ที่

• How to Keep Your Lambda Functions Warm
• Tutorial: Schedule AWS Lambda Functions Using CloudWatch Events
• Lambda Warmer: Optimize AWS Lambda Function Cold Starts
• Lambda Warmer

5. Warm ตัว Server ของเราตามเวลาที่เหมาะสม

วิธีการนี้เหมือนกับข้อ 4 คือมี Conjob ไปเรียก (Ping) Server แต่ต่างกันที่ กำหนดเวลาในการเรียกให้ถี่มากน้อย ขึ้นกับการใช้งานจริง

เช่น 08:00-22:00 คนเข้าเว็บไซต์เยอะ ก็ให้เรียกทุก 5 นาที เพื่อให้ Instances ไม่เข้าโหมด Idle ส่วนเวลาตั้งแต่ 22:01-07:59 ให้เรียกทุก 10 นาที แทน เป็นต้น

หรือใคร Advance หน่อย ก็ทำสคริ้ปอัตโนมัติเพื่อ Edit Config Lambda ในช่วงเวลา 22:01-07:59 เพื่อปรับ Memory ขึ้นไป แต่ไม่ต้องทำการ Ping ซึ่งมันก็จะไปใช้สูตรแบบข้อ 1. เพิ่ม Memory Allocated แทนการใช้แบบข้อ 4. เพื่อ Warm ตัว Server ตลอดเวลา

สามารถดูเพิ่มเติมได้ที่

• AWS CLI – Modify the version-specific settings of a Lambda function
• How to trigger aws lambda at different schedule every day

6. ใช้ Custom Runtimes และเลือกใช้ Runtimes ที่ทำงานได้เร็ว

กรณีของผู้ให้บริการอย่าง Amazon ได้เพิ่มฟีเจอร์มาให้กับ AWS Lambda คือ การ Custom Runtimes ได้เอง โดยไม่จำเป็นต้องใช้ตัวมาตรฐานที่ให้มา

ตัวอย่างเช่น .NET Core Runtime ที่ทาง Amazon มีมาให้คือ version 1.0 และ 2.1 เท่านั้น

.NET Runtimes (ดูเพิ่มเติม ได้ที่ AWS Lambda Runtimes)

แต่ปัจจุบันมี 2.2 และ 3.0 แล้ว ซึ่งถ้าเราพบว่า 3.0 ทำงานได้ดีกว่า หรือไวกว่า เราก็สามารถสร้าง Runtimes ขึ้นมาเองได้ หรืออาจจะไปสร้างเป็น PHP Runtimes ก็ยังได้ ถ้าเราอยากจะใช้ แต่ Amazon ไม่ได้ทำรองรับ

ในประเด็นนี้ ผมพยายามทดสอบหลายครั้ง ผมพบว่าใน .NET Core เมื่อทำ Custom Runtimes แล้ว ไม่ได้ช่วยทำให้ไวขึ้นแต่อย่างใด แถมช้าลงด้วย มีดีอย่างเดียวคือ ได้ใช้ฟีเจอร์ใหม่ๆ ในเวอร์ชั่นใหม่ (แต่ในภาษาอื่นๆ ถ้าใครทำดูแล้วได้ผลที่ดีขึ้น ลองมาแชร์กันได้ครับ)

สังเกตว่า ตัวมาตรฐาน .NET Core 2.1 Runtimes ทำงานได้ไวกว่าที่ผม Custom Runtimes เอง ที่เวอร์ชั่น 3.0 (แม้ว่าจริงๆแล้วผล Benchmark ของ .NET Core 3.0 จะทำงานได้ไวกว่า 2.1 ในสภาพแวดล้อมที่ไม่ใช่ AWS Lambda ก็ตาม)

ใครอยากทดสอบ Custom Runtimes ลองดูโค้ดตัวอย่างที่ผมทำไว้ได้

• .NET Core 3.0 – https://github.com/ifew/aws-lambda-crt-example
• .NET Core 3.0 with ADO.NET – https://github.com/ifew/aws-lambda-crt-db
• .NET Core 3.0 with Dapper – https://github.com/ifew/aws-lambda-crt-db-dapper

เรื่อง Custom Runtimes สามารถศึกษาเพิ่มเติมได้ที่นี่ครับ

• Custom AWS Lambda Runtimes
• Benchmarking Lambda’s New Custom Runtime for .NET Core

7. ใช้ Custom Runtimes และทำเป็น Native App

แม้ว่าการทำ Custom Runtimes ผมจะไม่พอใจกับผลลัพธ์ที่เกิดขึ้น (กรณี C# .NET Core) แต่เราสามารถเอาวิธีการเดียวกันมาเรียกใช้ Binary Executable File แทนได้นะ ด้วยการทำโค้ดของเราให้เป็น Native Application ซะเลย

การแก้ไขปัญหาด้วยวิธีนี้ ผมภูมิใจนำเสนอมากๆๆๆ เรียกได้ว่า เป็นไม้ตาย ที่แก้ปัญหา Cold Start ได้อยู่หมัดจากทุกๆ วิธีที่ผมทำมาเลยทีเดียว แต่ก็ค่อนข้างทำยากและมีข้อจำกัดเยอะ

มาลองดูสถิติที่ผมทำบน C# .NET Core กัน ว่าผลแตกต่างแค่ไหน ซึ่งผมเทียบโดยใช้ Database Framework ต่างกัน 3 ตัว ที่ทำงานต่างกันบน Runtimes แบบปกติ (.NET Core 2.1), Custom Runtimes (.NET Core 3.0) และ Native (.NET Core 3.0 + CoreRT)

จากตาราง ตัว Lambda Native (ช่องสีเขียว) ชนะใสๆ แบบขาดรอย เพราะ Cold Start แค่ 1.3 วินาที ในขณะที่ตัวอื่นๆ ทำงานที่ 10-33 วินาที (เทียบกันที่ ADO.NET)

สังเกตว่าทำไมผมมี Lambda Native แค่ ADO.NET อย่างเดียว

เนื่องจาก Lambda Native ใช้ Runtimes ชื่อว่า CoreRT ซึ่งมันเป็น .NET Core runtime อีกตัวที่พัฒนามาเพื่อ AOT (ahead of time compilation) โดยเฉพาะ กล่าวคือ มันจะแปลงภาษาจาก High-Level Programming เช่น C#, Java ไปเป็นภาษาเครื่อง (Machine code) กันเลยทีเดียว

แต่ๆๆ เจ้าตัว CoreRT ยังไม่สมบูรณ์นัก และมีผู้ใช้งานไม่มาก หาข้อมูลได้ยาก จึงทำให้การพัฒนาได้ยากตาม รวมไปถึงหลายสิ่งยังไม่สามารถใช้งานได้ เช่น เมื่อมีการเอา Dapper มาใช้ แต่โดนแจ้ง Error ว่า “Operation is not supported on this platform” ด้วยเหตุผลนี้เอง ผมถึงบอกว่า ทำไมยังมีข้อจำกัดอยู่ และทำได้ยาก

ดูตัวอย่างที่ผมทำได้ที่นี่

• Hello World – https://github.com/ifew/aws-lambda-lambdanative
• ADO.NET – https://github.com/ifew/aws-lambda-lambdanative-db

สามารถดูข้อมูลการทำ Lambda Native เพิ่มเติมได้ที่

• LambdaNative – https://github.com/zaccharles/lambda-native
• CoreRT – https://github.com/dotnet/corert

8. หลีกเลี่ยงการใช้ VPC ถ้าไม่จำเป็น

Update 6 Nov 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US West (N. California), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and South America (San Paulo) – ที่มา aws.amazon.com

Update 27 Sep 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US East (Ohio), EU (Frankfurt), and Asia Pacific (Tokyo) – ที่มา aws.amazon.com

…

คำแนะนำจาก theburningmonk.com บอกว่า ควรหลีกเลี่ยง ถ้าไม่จำเป็น เพราะการใช้ VPC มันจะกำหนดให้ Lambda ต้องสร้าง ENIs ขึ้นมา (Elastic Network Interface) เพื่อใช้คุยกันภายใน VPC และในเว็บไซต์บอกว่า กระบวนการนี้มันจะทำให้เพิ่มเวลา Cold Start อีกประมาณ 10 วินาที!!

และในเว็บไซต์ epsagon.com ได้ให้ข้อมูลเพิ่มเติมว่า การกำหนด Memory ที่มากขึ้น ใน AWS Lambda ของภาษา C# , Java มันจะทำการสร้าง ENIs เพิ่มจำนวนขึ้นด้วย แม้ว่า AWS Lambda จะมีกระบวนการที่นำ ENIs เก่ามาใช้ใหม่ได้ก็ตาม โดยสังเกตได้จากสูตรที่ชี้แจงไว้ใน AWS Document

ดังนั้น สรุปได้คือ ถ้าเราใช้ VPS และยิ่งเพิ่ม Memory Allocate เข้าไปในตัว AWS Lambda มันก็จะยิ่งเพิ่ม ENIs ให้เหมาะสมกัน และจะส่งผลกับ Cold Start ที่ใช้เวลามากขึ้นตามไปด้วย

ปล. มีข่าวดีแว่วๆมา อ้างอิงจาก @jeremy_daly ที่เข้าร่วมงาน AWS re:Invent ว่า AWS มีแผนจะแก้ปัญหาเรื่องนี้ภายในปี 2019 นี่แหละครับ

9. เลือกภาษาเพื่อใช้ทำ Serverless ที่เหมาะสม

ข้อสุดท้าย ถ้าไม่ผูกติดกับภาษาในการพัฒนา Serverless แนะนำให้ใช้ตระกูล Scripting Language แทน Compiled language จะช่วยแก้ปัญหา Cold Start ได้อย่างมาก

ลองดูจากสถิติของเว็บไซต์ mikhail.io

พวก JavaScript, Python, Go, Java, และ Ruby จะทำงานเสร็จแถวๆ 500ms หรือไม่เกิน 800ms แต่สำหรับ C# จะใช้เวลาตั้งแต่ 0.8 จนถึง 5 วินาที เลยทีเดียว

ตัวอย่างสถิติอีกสักแห่ง จากเว็บไซต์ read.acloud.guru

สถิติจากเว็บไซต์นี้ ได้ผลใกล้เคียงกับที่แรกคือ พวก JavaScript, Python ยังคงทำงานได้เร็วแถวๆ 500ms ส่วน Java และ C# ใช้เวลา Cold Start นานมาก

และให้ข้อมูลเพิ่มเติมนิดนึงครับว่า แม้จะเปลี่ยนผู้ให้บริการ ก็ได้ผลไม่ต่างกัน ถ้าหากใครคิดว่า ใช้ C# บน Azure Function น่าจะเร็วกว่า AWS Lambda นั้น คิดผิดนะคร้าบบบ..

ให้สังเกตว่า C# บน Azure Function ทำงานได้ช้ากว่า AWS Lambda ประมาณ 500ms – 1 วินาที เลยทีเดียว

อ่านข้อมูลการเปรียบเทียบเพิ่มเติมได้ที่นี่

• Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go
• How does language, memory and package size affect cold starts of AWS Lambda?

สรุป

ตอนนี้เราก็คงต้องต่อสู่กับ Cold Start กันต่อไป เพราะเราไม่สามารถแก้ไขอะไรมันได้มากนัก ส่วนผู้ให้บริการเองอย่าง Amazon, Azure, Google Cloud ก็รู้ปัญหานี้เช่นกัน และพยายามปรับปรุงมันให้ดีขึ้นอยู่เรื่อยๆ แต่ที่สำคัญ ก่อนที่เราจะตัดสินใจใช้ Serverless เราต้องคิดให้ดีก่อนว่าเหมาะสมกับงานของเราแล้วหรือยัง

—

ที่มาภาพหน้าปก http://www.drunktiki.com/2016/08/17/yoda-pug/yoda-pug-jpg/

ใน Slide ของ Become a Serverless Black Belt ได้พูดถึงเรื่องการจัดสรรทรัพยากรไว้หลายหน้า และในหน้าปิดท้ายของตอน ได้บอกไว้ว่า

Dont’s Guestimate

หมายถึง เรื่องพวกนี้ “อย่าไปเดา” นะหนู เพราะเราไม่สามารถรู้ได้เลยว่า โค้ดที่เราเขียน ใช้ Memory เท่าไร ดังนั้นจะต้องจัดสรรให้มันเท่าไรถึงจะเพียงพอ ซึ่งถ้าจัดให้มากไป ก็เสียเงินจับจองเมมโมรี่ (Allocated Memory) โดยเปล่าประโยชน์, และถ้าจัดให้น้อยไป ก็ใช้เวลาคำนวณนานขึ้น (Computed Time) ไม่ว่าจะทางใด ก็มีผลกับค่าใช้จ่ายที่เกิดขึ้นทั้งคู่.. ความสนุก Serverless มันอยู่ตรงนี้แหละ!!

เลิกเดา แล้วมาคุยกันด้วยข้อมูลดีกว่า

ใน Slide เรื่องเดียวกัน ได้อ้างถึงเครื่องมือตัวหนึ่ง ชื่อ AWS Lambda Power Tuning ที่พัฒนาโดย Alex Casalboni และเขาได้เล่าที่มาในบล็อก AWS Lambda Power Tuning with AWS Step Functions ว่า Serverless Developer ทุกคนมักหลับหูหลับตาเพื่อจัดสรรทรัพยากร หรือไม่ก็ใช้วิธีการ Manual Test เพื่อทดสอบดูทีละแบบ ซึ่งมันก็เสียเวลาและไม่ได้ผลลัพธ์ที่ดีแน่นอน

พี่แกเลยบอกว่า ถ้าเช่นนั้นเรามาใช้วิธี Data-Driven ดีกว่า! แกเลยเริ่มจากทำโพลสำรวจใน Twitter ว่าสิ่งที่สังเกตเห็นมันเป็นจริงไหม

ซึ่งกว่า 50% ในโพล เคยใช้ Memory เท่าไรก็ตั้งไว้แบบเดิมเท่านั้น ไม่ได้สนใจที่จะ Tuning อะไร และครึ่งหนึ่งนิยมตั้งค่าไว้ที่ 128MB ทุก Function ด้วยเหตุผลที่ว่า เพราะมันราคาถูกที่สุดน่ะสิ! ไม่ได้สนใจเลยว่าจะทำงานได้ไวไหม

แต่ไม่ว่าจะเลือกตอบข้อไหน ก็ยังไม่ใช่สิ่งที่ควรทำในการตั้งค่า Memory ให้กับ Serverless อย่าง AWS Lambda

จากนั้นเขาก็เขียนเล่าถึงเหตุผลว่าทำไม Function ทำงานได้ช้า และคอนเซปของการแก้ปัญหาของ (ซึ่งถ้าใครอยากอ่านฉบับเต็ม ไปอ่านได้ที่ AWS Lambda Power Tuning with AWS Step Functions) จนสรุปได้ว่า การ Tuning Memory ทีละลำดับ พร้อมกับทดสอบเรียกใช้ (Invocating) ด้วยจำนวนที่ต้องการ ​กับ Lambda Function ทีละตัว คือหนทางที่เหมาะสม และต้องเป็นการทดสอบแบบ Automate ทั้งหมดด้วย เพื่อความรวดเร็ว จึงเป็นที่มาของเครื่องมือ AWS Lambda Power Tuning ที่ผมกำลังจะเขียนถึง

รู้จักกับ AWS Lambda Power Tuning

เจ้าเครื่องมือ AWS Lambda Power Tuning นี้ ถูกพัฒนาด้วย Node.js โดยจะมี Lambda Function จำนวน 4 ตัว และเราต้องสร้าง Role กับ StepFunction เพื่อใช้มัน

แต่ไม่ต้องตกใจ ว่าจะยุ่งยาก เพราะโค้ดบน Github นาย Alex ได้มีไฟล์ Serverless.yml หรือเป็น AWS CloudFormation Script ไว้ให้เราใช้ Provision Infrastructure เรียบร้อย แต่เราจะต้องรันคำสั่งด้วยเครื่องมือชื่อ Serverless

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

ถ้าทำเอง น่าจะใช้เวลามากๆ เลยทีเดียว กว่าจะทดสอบ Lambda ได้ทีละตัว

ตัวอย่างผลลัพธ์ของ AWS Lambda Power Tuning

เช่น ผมมี Lambda Function เพื่อแสดงรายการสินค้า 1 ตัว ผมต้องการรู้ว่า Memory ในช่วง 128 MB – 1024 MB จำนวนเท่าไรจะเหมาะสมที่สุด..

ตัว AWS Lambda Power Tuning ก็จะเรียก Function ของมันมาเรียงเป็น Step ทำงานให้เราดูเป็นกราฟ

เมื่อทำการทดสอบเสร็จ จะสรุปที่ Output ด้านขวามือ เพื่อบอกว่า ควรใช้ Power (Memory) เท่าไร ถึงจะคุ้มค่าที่สุด ด้วย Cost และ Duration Time เท่าไร

ถ้าใครอยากเห็นรายละเอียดการทดสอบแต่ละ Memory ให้เลื่อนลงมาดูด้านล่าง จะมี Output บอกอีกส่วนหนึ่งแบบละเอียด

คราวนี้ ทดสอบครั้งแรก ผมไม่ค่อยเชื่อผลเท่าไร จึงลองทดสอบทั้งหมด 4 รอบ, แต่ละรอบและแต่ละ Memory ผมจำลองให้มีการร้องขอ (Invocation) จำนวน 10 ครั้ง จำนวน 3 รอบ และ 100 ครั้ง จำนวน 1 รอบ ผลที่ได้ออกมา คือ

Execution #1 – Invocation 10

Execution #2 – Invocation 10

Execution #3 – Invocation 10

Execution #4 – Invocation 100

จากผลการทดสอบ แปลว่า Function แสดงรายการสินค้า ถ้าใช้ Memory ที่ 320 MB จะเร็วและถูกที่สุด โดยเราไม่จำเป็นต้องใช้ Memory ถึง 1024 MB ก็ได้ เพราะผลที่ได้อาจจะไม่ต่างกันมาก ไม่ว่าจะมีการเรียกใช้ 10 ครั้งหรือ 100 ครั้ง ต่อเนื่องก็ตาม

(อย่าลืมว่า ค่าใช้จ่ายการ Compute จะปัดเศษขึ้น เป็นหน่วย 100ms นะครับ ไม่ว่าจะ 40.2ms , 80.8ms ก็ถูกปัดไปคิดเงินเป็น 100ms เท่ากัน)

ปล. จุดสังเกต คือ Memory 256 MB จะทำงานได้ช้ากว่า และแพงกว่า ทั้ง 4 รอบเลย ตรงนี้ผมต้องไปตรวจสอบในระดับ Source Code, Logs, หรือใช้ AWS X-Ray ดูต่อว่าทำไม

วิธีการติดตั้ง AWS Lambda Power Tuning ผ่าน Serverless

** หากใครไม่สะดวกติดตั้งผ่าน Serverless สามารถทำด้วยการ Clone git แล้วรันสคริ้ป ซึ่งสามารถดูได้ที่ https://github.com/alexcasalboni/aws-lambda-power-tuning **

ขายของมานาน มาดูวิธีติดตั้งและใช้งานกัน ซึ่งในที่นี้ผมยกตัวอย่างของ MacOS, Linux ส่วนชาว Windows ให้ใช้ PowerShell ดูนะครับ

ความต้องการก่อนติดตั้งใช้งาน

1. AWS Account จะต้องมีสิทธิ์ใช้งาน ดังนี้
   • cloudformation:*
   • states:*
   • lambda:*
   • iam:CreateRole
2. เครื่องที่ติดตั้งจะต้องมี npm (วิธีติดตั้ง npm)

ติดตั้ง Serverless Framework และใส่ AWS credentials

$ npm install serverless -g
$ serverless config credentials --provider aws --key XXX --secret YYY

ติดตั้ง AWS Lambda Power Tuning

$ serverless install -u https://github.com/alexcasalboni/aws-lambda-power-tuning

ทำการติดตั้ง Package Dependency

$ cd aws-lambda-power-tuning
$ npm install

สร้าง Config ของ State Machine ในไฟล์ serverless.yml

$ npm run generate -- -A ACCOUNT_ID [-R eu-west-1] [-P 128,256,512,1024]

เช่น

$ npm run generate -- -A 182000046000 -R ap-southeast-1 -P 128,192,256,320,448,512,704,1024

ทำการ Deploy AWS Lambda Power Tuning

$ serverless deploy

วิธีการใช้งาน AWS Lambda Power Tuning

เมื่อติดตั้งเสร็จแล้ว ลองเช็คที่ AWS Lambda Function เรา จะเจอฟังก์ชั่นเพิ่มขึ้นมา ดังนี้

จากนั้นให้ไปดูที่เซอร์วิส Step Function จะพบ State Machine

ให้กดที่ Start Excution

กรอกข้อมูล State Machine Input สำหรับจะใช้ทำงาน โดยมีรูปแบบตามนี้

{
    "lambdaARN": "your-lambda-function-arn",
    "num": 10
}

เช่น

รอสักครู่ จะมี Status บอกเราว่า Successed พร้อมบอกรายละเอียดการทำงาน และผลลัพธ์ ซึ่งถ้ามันขึ้นว่า Failed ให้เราไปดูที่ Exception ได้

การกำหนดค่า State Machine Input

เราสามารถกำหนด parameters ของ input ได้ ดังนี้:

• lambdaARN (จำเป็น): ARN ของ Lambda Function ที่ต้องการทดสอบ
• num (จำเป็น): หมายเลขจำนวนที่ต้องการทดสอบเรียกใช้งาน (invocations) ต่อครั้งและต่อ Memory ที่เรากำหนด (อย่างน้อย 5, แนะนำ: 10 – 100)
• payload (string/object): Input สำหรับใช้ใน Lambda Function ที่ต้องการทดสอบ (ใส่เป็นข้อมูล JSON)
• parallelInvocation (ค่าตั้งต้น: false): ถ้าเราใส่เป็น true, จะมีการเรียก Execute พร้อมๆ กัน ตามจำนวนที่เราระบุใน num

สรุป

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

อ้างอิง

• https://serverless.com/blog/aws-lambda-power-tuning/
• https://github.com/alexcasalboni/aws-lambda-power-tuning
• https://www.slideshare.net/AmazonWebServices/become-a-serverless-black-belt-optimizing-your-serverless-applications-aws-online-tech-talks

แต่ที่ชวนฉงนคือ การทำงานของ Serverless เป็นแบบ เกิดขึ้น และทำ Process แล้วก็ดับไป มันจะทำเป็น WebSocket ได้ด้วยหรอ เพราะต้องเปิดแช่ Connection เพื่อสื่อสารกันตลอดเวลา

โพสต์นี้จะแชร์แนวคิดให้อ่านกัน ว่ามันเป็นไปได้จริงๆ ด้วยบริการของ Amazon API Gateway และ AWS Lambda ส่วนโค้ดตัวอย่าง ไปดูได้ที่ Github (aws-lambda-websocket) ผมได้เลย

อธิบายการทำงาน

การทำ Websocket ด้วย Lambda มีจุดสำคัญอยู่ 2 จุด คือ

1.Amazon API Gateway

ซึ่งทาง Amazon เอง เพิ่งประกาศฟีเจอร์ WebSocket นี้เมื่อ 3 เดือนที่แล้วนี่เอง (18 ธันวาคม 2561) โดยสามารถใช้งานกับบริการต่างๆของ Amazon ได้ เช่น AWS Lambda, Amazon Kinesis, หรืออื่นๆที่เชื่อมต่อด้วย HTTP endpoint

ซึ่งใน Amazon API Gateway ส่วนของ Websocket API จะมีการ Config Resource Type ต่างจากแบบ REST คือ

1. route ที่เอาไว้เป็นช่องทางจัดการคำขอต่างๆที่มาจากผู้เรียกใช้ (route selection expression)
2. routeKey ที่เป็นช่องทางของคำขอ โดยแบ่งได้ 3 routeKey หลัก คือ
   • $default – ใช้สำหรับคำขอที่ไม่เข้าเงื่อนไขใดๆเลย จากผู้รองขอ เช่น การส่งข้อมูล Error ให้กับผู้ร้องขอ
   • $connect – ใช้สำหรับเมื่อมีผู้ร้องขอเพื่อขอใช้งาน และตรวจพบว่าเป็นการเรียกใช้ Websockets นี้ครั้งแรก (การที่เคยขอใช้ และ Connection ของ WebSocket หมดอายุไป ก็ต้องเรียก Connect ใหม่เช่นกัน)
   • $disconnect – ใช้สำหรับบอกว่าผู้ใช้งานมีการ Disconnect จาก API ไปแล้ว ก็จะทำการตัด Connection ของ WebSocket ออกไปด้วย

2.การเก็บ Connection ID ลง ฐานข้อมูล

โดยปกติถ้าเราเขียน WebSocket ทั่วไป มันจะทำการเก็บ Connection ID ไว้ใน Server แต่เมื่อเราทำบน Serverless อย่าง AWS Lambda ที่ธรรรมชาติของมันพร้อมจะปิดสวิตส์ตัวเองเสมอเมือ่ไม่ได้ใช้งานนานๆ เราจึงต้องเพิ่มการเก็บ Connection ID ลงในฐานข้อมูลแทน เพื่ออ้างอิงไว้ใช้ เมื่อ Lambda เราตื่นขึ้นมาทำงานต่อ

ตัวอย่างการทำงาน AWS Lambda กับ WebSocket

ในรูปตัวอย่าง อธิบายการทำงานของระบบ Chat ที่ใช้ Lambda และ WebSocket API โดยมีขั้นตอนคือ

• ผู้ใช้ เข้ามาใช้งาน Chat Room ซึ่งระบบก็จะทำการ connect ไปที่ WebSocket API
• ระบบ WebSocket API จะทำการสร้าง Connection ID และส่ง message กลับไปหาผู้ร้องขอตาม URL ที่มีการเรียกใช้มาตอนแรก (URL Callback) เพื่อบอกว่า ทำการเชื่อมต่อสำเร็จ (Connected) พร้อมทั้งเก็บ Connection ID ไว้ในฐานข้อมูลด้วย
• เมื่อผู้ใช้ส่งข้อความ Chat ไปให้ WebSocket API มันจะส่ง message นั้นไปที่ Reosource ที่เรากำหนดไว้ (ซึ่งในที่นี้คือ Lambda Function สำหรับการ Chat) โดยไม่ต้อง connect ใหม่อีกรอบ
• message ที่ถูกส่งมา จะถูกกระจายส่งไปหา Connection ทุกคนที่มี Connection ID อยู่ในรายการฐานข้อมูล
• สุดท้าย เมื่อพบว่าผู้ใช้ออกจากห้อง Chat Room ไปแล้ว ตัว WebSocket API จะ Disconnect ผู้ใช้คนนั้นอัตโนมัติ

ผมทดลองโดยเปิด Connection ไว้ สามหน้าต่าง ซึ่งจะมี Connection ID ต่างกัน ดังนั้น เมื่อผมส่ง message ออกจากหน้าต่างไหนก็ตาม มันจะถูกเผยแพร่ไปหาหน้าต่างอื่นๆ ด้วย ดังนั้น จึงเหมาะกับงานประเภททำงานแบบ Realtime และ Broadcast เช่น Chat, Notification, Bidding หรือแม้แต่ระบบโหวตและนับคะแนนเสียงเลือกตั้ง

ตัวอย่างโค้ด ดาวน์โหลดได้ที่ https://github.com/ifew/aws-lambda-websocket

ค่าใช้จ่าย สำหรับ AWS Lambda WebSocket

ค่าใช้จ่ายในส่วนของ AWS Lambda จะเหมือนเดิม ตามที่เคยเขียนเล่าไว้ในบล็อก มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้

จะมีที่แตกต่างคือการคิดเงินในฝั่งของ Amazon API Gateway ที่คิดตาม request และ จำนวนนาทีที่มีการเชื่อมต่ออยู่ สามารถดูได้จากตารางด้านล่าง

ถามว่าแพงไหม ผมก็ไม่รู้นะ อยู่ที่การใช้งานของแต่ละระบบ แต่จำนวน request 1พันล้านแรก ราคา $1.15 กับ connection 1 ล้านนาที ราคา $0.288 คงเป็นตัวเลขที่ถูกแสนถูก มากๆ เท่ากับข้าวแกงจานนึง

แต่ตัวแปรสำคัญคงอยู่ที่ Lambda Compute ที่อาจจะแพง ฮ่าๆ เพราะ การทำงาน 1 ชุด จะมี Lambda อย่างน้อย 3 ตัวแน่นอน คือ Connect, Disconnect, Default ส่วน Lambda จะมีค่าใช้จ่ายสูงแค่ไหน ก็กลับไปดูจำนวน request และ compute time (วิธีคิดอ่านได้จากบล็อก มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้ )

ข้อจำกัด

• รองรับผู้ใช้งานได้ 10,000 requests ต่อวินาที (RPS) ต่อ region (สามารถขอเพิ่มจากทาง Amazon ได้)
• ระบบจะทำการเพิ่มให้ 500 requests ในทุกๆวินาที ต่อ region
• ส่งข้อมูลผ่าน WebSocket (frame size) ได้ไม่เกิน 32 KB ถ้าต้องใช้มากกว่านั้น ต้องตัดข้อมูลเป็นเฟรมๆเพื่อส่ง, ซึ่งถ้าส่งเกิน ระบบจะทำการ Disconnect อัตโนมัติ
• ระยะเวลาสำหรับ Connection อยู่ได้ 2 ชั่วโมง
• เข้าสู่โหมด Idle Connection Timeout ที่เวลา 10 นาที กรณีไม่มีการส่งข้อมูลอะไรผ่าน WebSocket API
• สามารถทำ AWS Lambda authorizers ต่อ API ได้ 10 ตัว (สามารถขอเพิ่มจากทาง Amazon ได้)
• สร้าง Routes ต่อ API ได้ไม่เกิน 300 ตัว (สามารถขอเพิ่มจากทาง Amazon ได้)
• ทำการเชื่อมต่อ API กับ Resource ต่างๆ เช่น AWS Lambda (Integrations) ได้ไม่เกิน 300 ตัว (สามารถขอเพิ่มจากทาง Amazon ได้)
• สามารถมี Stages ต่อ API ได้ไม่เกิน 10 ตัว (สามารถขอเพิ่มจากทาง Amazon ได้)

สรุป

น่าสนใจมากๆ สำหรับการทำ WebSocket ด้วย Serverless ดูเป็นเรื่องน่าสนุกดีสำหรับผม เหมือนได้เล่นของใหม่ ที่พยายามพลิกแพลง Serverless มาทำ แต่ถามว่าดีหรือไม่ เหมาะสมไหม ตอนนี้มันยังใหม่มาก หาเคสตัวอย่างใหญ่ๆ ไม่เจอ (หรืออาจจะมีแต่ไม่มีใครเปิดเผย) ดังนั้นถ้าให้บอกข้อดีที่นึกออกตอนนี้ ก็คงเรื่องของราคาค่า Server ที่มันถูกลง ตาม benefit เดิมของ Serverless นั่นแหละ, ส่วนข้อเสียที่ผมพบตอนนี้ รู้สึกทดสอบยาก ณ ตอนเขียนบล็อกนี้ยังนึกการทำ Integration Test ไม่ออกเลย นอกจากการ Deploy ขึ้นไปทดสอบบน AWS เอง, หากใครคิดออก หรือมีตัวอย่างเจ๋งๆ ก็แชร์กันได้นะครับ

อ้างอิง

• https://aws.amazon.com/th/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/
• รูปปกจาก https://blog.stanko.io/do-you-really-need-websockets-343aed40aa9b?gi=77181225da63

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

Serverless คืออะไร?

Serverless ถ้าแปลตรงตัวก็คงเรียกว่า “ไม่มี Server” กล่าวคือ เมื่อมีการเรียกใช้งานอะไรสักอย่าง มันจะสร้าง Server ชั่วคราวขึ้นมาเพื่อประมวลผล และเมื่อส่งผลลัพธ์ให้เราเสร็จ มันก็จะหยุดทำงาน หรือทำลายตัวเองทิ้งไป

ปล. จริงๆ มันก็มี Server นั่นเอง ผมอยากแปลมันว่า “Server ชั่วคราว” มากกว่า แต่เพื่อความเข้าใจตรงกันขอใช้คำแปลแบบท่านอื่นๆแล้วกัน เพราะส่วนตัวคิดว่า คำว่า “Serverless ทำงานแบบไร้ Server” มันเป็นข้อความทางการตลาด ให้คนสนใจ แต่ค่อนข้างสร้างความสับสนว่าเป็นไปได้ด้วยหรอ?!

iFew

ถ้าไล่ประวัติตามรูปด้านบน เริ่มต้นมาจากสมัย Internet มาแรกๆ ที่เราต้องตั้งเครื่อง Server ทีละตัว หรือหลายๆเครื่องตามปริมาณที่รองรับคนได้ ต้องดูแลเองทุกอย่าง

จนถึงวันหนึ่งที่อุปกรณ์ต่างๆ เริ่มมีราคาถูกลงและสเปกแรงขึ้น เราจึงประหยัดต้นทุนด้วยการจำลอง Server หลายๆตัว ลงในเครื่อง Server ตัวเดียว หรือที่เรียกกันว่า VM (Virtual Machine)

และเมื่อ Internet เร็วและแรงขึ้น ก็ได้เกิดบริการที่เรียกว่า Cloud Computer ซึ่งใน Cloud เองก็ใช้สถาปัตยกรรมหลายรูปแบบแล้วแต่ผู้ให้บริการ จนมาถึงยุคปัจจุบัน ที่กำลังอยู่ในช่วงของความนิยมใช้ Container อย่างเข่น Docker, Kubernates และก็กำลังก้าวเข้าสู่ยุค Serverless ที่ผมกำลังจะเล่าถึง

สังเกตไหมครับว่า อะไรที่เปลี่ยนไป?…

สิ่งที่เปลี่ยนไปคือ สิ่งที่เราใช้ประมวลผลมันเล็กลงเรื่อยๆ จากเครื่อง Server ย่อยลงมาเหลือแค่ระดับ VM มาเป็น Container รวมถึงการจัดการเรื่องเหล่านี้ก็ถูกผลักไปให้ทางผู้ให้บริการดูแลมากขึ้น จากที่ต้องดูแลเรื่อง Hardware + Network + Middleware + Application ก็เหลือเพียงแค่โฟกัสเรื่อง Application อย่างเดียว (ส่วน SaaS มันคือการไปใช้ระบบของคนอื่นเลย ไม่ต้องทำเอง ไม่ต้องดูแล)

ซึ่ง ผมไม่รู้ว่าใครเริ่มก่อนกัน ระหว่าง Hardware กับ Software แต่มันสอดคล้องกับแนวโน้มการพัฒนา Software ที่นิยมย่อยชิ้นส่วนให้เล็กลง แบบที่เราคุ้นชื่อกันตอนนี้ เช่น Microservice ที่เกิดมาเพื่อลดข้อผิดพลาดที่เป็นผลพวงจากการทำงานที่เกี่ยวข้องกัน รวมถึงจัดการทรัพยากรให้เหมาะสม และก็ลากไปเกี่ยวโยงอีกว่า เพื่อรองรับกับวิธีบริหารจัดการในแบบ Interative and Incremental อย่าง Scrum, DSDM, XP เป็นต้น

และเมื่อมันไม่มี Server ให้เราจัดการและดูแล ก็จะเป็นหน้าที่ของผู้ให้บริการ Serverless ต่างๆ ที่จะทำแทนเรา โดยมันจะมีการขยายตัว (Scale out) หดตัว (Scale down) เพื่อจัดทรัพยากรย์ต่างๆ ให้รองรับปริมาณการทำงานตามความเหมาะสมแบบอัตโนมัติ และคิดค่าใช้จ่ายตามการใช้งานจริง

AWS Lambda คืออะไร?

เป็น Serverless Platform ที่สร้างโดย Amazon ตั้งแต่ November 2014 โดยมีรูปแบบเป็น FaaS (Function-as-a-Service) หรือว่าง่ายๆ คือ Lambda 1 ตัวที่ถูกสร้างชั่วคราวเพื่อมาใช้งาน จะมีเพียง 1 Function หรือหนึ่งการทำงานเท่านั้น (ประมาณว่า Server 1 ตัว เก็บแค่ 1 Function)

และมันได้ออกแบบมาเป็น EDA (Event-driven architecture) คือ ต้องมี Event Trigger ไปเรียกมันขึ้นมาใช้งาน ไม่สามารถทำงานได้ด้วยตัวเอง

ตอนนี้รองรับภาษายอดนิยม อย่าง Node.js, Python, Java, Go, Ruby และ C# (.NET Core) และถ้าใครใช้ PHP แม้จะยังไม่รองรับ แต่ก็สามารถทำ PHP Custom Runtime เองได้

รายละเอียดอื่นๆ ไปดูเพิ่มเติมได้ที่ https://aws.amazon.com/lambda/ ครับ

Serverless ทำงานอย่างไร?

ตามที่เกริ่นไปก่อนหน้า เมื่อมันไม่มี Server เปิดทิ้งไว้ มันจึงต้องมีอะไรบางอย่างไปสะกิดเพื่อปลุกมันให้ตื่น (หรือที่เรียกว่า Event Trigger) โดยส่วนมากแล้วก็ถูกนำไปใช้กับ API Gateway เพื่อทำเป็น API Backend

โดยเมื่อมีใครเรียกใช้มัน มันก็จะสร้าง Server (หรือเรียกว่า Instant) ขึ้นมาเพื่อประมวลผลอะไรบางอย่าง และส่งผลลัพธ์ให้เรา และเมื่อไม่ได้ใช้บริการมันในระยะเวลาหนึ่ง มันจะกลับไปหลับเหมือนเดิม (หรือเรียกว่า Idle, Sleep) เพื่อรอการเรียกอีกครั้ง ซึ่งในขณะที่มันหลับอยู่ก็จะไม่คิดค่าบริการกับเรา

ลงในรายละเอียดอีกนิด และสำคัญมากๆ คือ ตอนมัน Initial เพื่อสร้าง Server ขึ้นมา มันจะโหลดโค้ดของเรา และทำการติดตั้งนั่นโน่นนี่ และรันโค้ดของเราเพื่อมาทำงาน

ที่มันสร้างและติดตั้งต่างๆนี่เอง เรียกว่าช่วง Cold Start ผมให้ข้อสังเกตว่า ตรงนี้เป็นปัญหาหนึ่งที่ทำให้กินเวลาการประมวลผลเพิ่มขึ้น แต่จะเกิดกับครั้งแรกที่รันเท่านั้น พอรันซ้ำอีกครั้ง ในเวลาไล่เลี่ยกัน (หรือก่อนที่มันจะหลับ) มันจะ execute code อย่างเดียว ก็จะทำให้เร็วตามที่โค้ดเราทำงานจริงๆ

ถามว่า Cold Start กินเวลานานขนาดไหน ต้องบอกว่าเป็นหลักวินาที ยิ่งโค้ดใหญ่มาก จัดสรร Memory ให้น้อย ก็ยิ่งใช้เวลานาน ตรงนี้เป็นจุดหนึ่งที่ต้องคิดเยอะๆ เพราะมีผลกับผู้ใช้งานคนแรก และค่าใช้จ่ายที่ตามมา

ปล. ผมโดนถามบ่อยๆว่า นานแค่ไหนที่ Server จะเข้าสู่โหมด Idle? จากที่เจอเอง ใช้ Server Singapore ผมลุกไปเข้าห้องน้ำ 5-10 นาที กลับมาก็รู้สึกช้าแล้วครับ แต่กับที่ไปหาอ่านของฝรั่ง น่าจะใช้ Server ทวีปอื่น บางคนบอก 15 นาที บางคนบอก 45 นาที ผมจึงเชื่อว่าทวีปน่าจะมีผลกับเวลา Idle

iFew

การทำงานแบบ Continuous Scaling

สั่งเกตว่าใช้คำว่า Continuous Scaling ไม่ใช่ Auto Scaling แบบที่เคยทำกับ Cloud ทั่วไป แล้วมันทำงานอย่างไรล่ะ?

อ้างอิงจากเอกสาร Understanding Scaling Behavior ของ Amazon ได้บอกไว้ว่า AWS Lambda มีการ Initial ครั้งแรกก็จะรองรับ Concurrency ได้จำนวนหนึ่ง แต่จะแตกต่างกันตามแต่ละทวีปที่เราใช้บริการ

เช่น ผมเลือกใช้ของ Singapore ดังนั้นการสร้าง Server ขึ้นมาครั้งแรก มันจะรองรับ Concurrency ที่ 500 และถ้ามีปริมาณผู้ใช้มากขึ้นเรื่อยๆ มันจะทำการเพิ่ม Concurrency ให้ครั้งละ 500 ในทุกๆ 1 นาที จนกว่าจะชนเพดาน Limit ที่เรามี (ซึ่งในภาพตัวอย่าง คือ รองรับได้ที่ 1,000 Concurrency พร้อมกัน ซึ่งทุกคนจะได้ค่ามาตรฐานเป็นเท่านี้ ยกเว้นไปอีเมลขอปริมาณเพิ่มจากทาง Amazon)

โดย Concurrency ทั้งหมดที่เรามีนั้น Amazon จะกระจายให้กับทุก Function ตามการใช้งานจริง เช่น Function A มีการเรียกใช้ 125 Concurrency จะทำให้ Function อื่นๆ ทั้งหมดแย่งกันใช้จาก 875 Concurrency ที่เหลือ ดังนั้น Amazon จึงมีฟีเจอร์ให้เราจอง Concurrency ให้กับ Function ได้ว่า ต้องมีเหลือให้ใช้เสมอ ในจำนวนเท่าไร

รวมไปถึง หากพบว่ามีการประมวลผลแปลกๆ ทำงานนานผิดปกติ หรือพบว่ามีการ Reuqest มากผิดปกติ ซึ่งจะส่งผลกับค่าใช้จ่ายที่มากขึ้น เราสามารถปิดการทำงานชั่วคราวได้ด้วยการลด Concurrency ให้เหลือศูนย์ (Throttle)

Serverless เอาไปใช้งานใดได้บ้าง?

อ้างอิงจากรูป แบ่งตามประเภทแล้ว มันสามารถใช้งานได้ในหลากหลายรูปแบบ แต่เราต้องเข้าใจธรรมชาติมันก่อนนะว่า มันเกิดขึ้น ตั้งอยู่ ดับไป คิดเงินตามการใช้งานจริง และต้องมี Event Trigger ไปปลุกให้มันตื่น

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

ข้อดี/ข้อเสียของ Serverless

หลังจากเข้าใจแล้วว่าคืออะไร ลองมาพิจารณาข้อดีข้อเสียและชั่งน้ำหนักก่อนจะตัดสินใจใช้งานดูนะครับ

• ข้อดี
  • ลดค่าใช้จ่าย เพราะจ่ายเท่าที่ประมวลผลจริง ไม่มีเปิด Server ทิ้งไว้
  • ไม่มี Server ให้ต้องดูแลและจัดการ
  • Scale ได้ต่อเนื่องตามการใช้งานจริง และอัตโนมัติ
• ข้อเสีย
  • เรื่องของการ Initial Server ครั้งแรก (Cold Start) จะใช้เวลานิดหนึ่ง
  • ทรัพยากรที่จำกัด (Memory 128MB-3GB, Limit Concurrency 1,000/region/account)
  • แนวคิดการออกแบบซอร์ฟแวร์ที่จะยากขึ้น ว่าทำอย่างไรให้หั่นการทำงานใหญ่ๆ เป็นการทำงานย่อยๆ
  • การทดสอบใน Local Machine ยาก จำเป็นต้องมี Unit Test (และก็เขียน Unit Test ยากเช่นกัน)
  • Monitoring และ debugging ค่อนข้างยาก (ทำได้แต่เสียเงินเพิ่ม อย่าง AWS Lambda ต้องเปิดบริการอย่าง AWS Cloudwatch, AWS X-Ray ในการดูเพิ่มเติม)
  • OS vulnerabilities ถูกดูแลโดยผู้ให้บริการ Serverless, เราอัพเดท หรือแก้ไขอะไรเองไม่ได้

แถม: Serverless สามารถลดค่าใช้จ่ายได้จริงหรือ?

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

โดย AWS Lambda มีการคิดเงินจากสองส่วน คือ

• คิดตามจำนวนการเรียกใช้ (Requests)
  • ให้ฟรี 1 ล้าน Requests ทุกเดือน
  • 1 ล้านต่อไป คิดที่ $0.20 (~6 บาท)
• คิดตามระยะเวลาประมวลผล (Duration Time)
  • ให้ฟรีประมวลผล 400,000 GB-Seconds* ทุกเดือน
  • ทุกๆ 1 GB-Seconds คิดที่ $0.00001667 (~0.00055011 บาท)
  • ทุกครั้งที่มีประมวลผล จะปัดเศษขึ้นที่หลัก 100ms (เช่น 15237ms = 15300ms, 97.12ms = 100ms, 0.43ms = 100ms)

ปล. GB-Seconds ย่อมาจาก Gigabyte second หมายความว่า การประมวลผลโดยใช้ Memory จำนวน 1 Gigabyte ใน 1 วินาที (เช่น เราจัดสรรให้ฟังก์ชั่นเราทำงาน 3GB แต่มีการประมวลผล 2 วินาที ก็เท่ากับการรันครั้งนี้ใช้งานไป 6 GB-Seconds)

iFew

เรื่อง Requests น่าจะเข้าใจได้ แต่เรื่อง Duration Time กับ Memory อาจจะยังงงๆ ให้ดูภาพด้านล่างนี้ครับ

ในหน้าของ AWS Lambda เองจะมีข้อมูลบอกแบบนี้ ว่า Duration Time ของการประมวลผลจริงๆ เท่าไร (Actual) และคิดเงินที่เท่าไร (Billed) จากนั้นเอา Memory ที่เราจัดสรรให้กับ Server เรา มาคำนวณเพื่อหาว่า GB-Second ของการทำงานครั้งนี้เป็นเท่าไร

โจทย์ตัวอย่าง

ถ้ามีฟังก์ชั่นชื่อ get_product() โดยเราจัดสรร Memory ให้ 128MB มีการเรียกใช้งาน 30 ล้านครั้งใน 1 เดือน ซึ่งแต่ละครั้ง ใช้เวลาประมวลผล 200ms

ในเดือนนั้น เราต้องจ่ายค่าประมวลผล get_product() ทั้งหมด $11.63 โดยคิดเป็นค่า Requests $5.80 และค่าประมวลผล (Compute) $5.83

วิธีการคิด ค่า Requests

สูตรคือ Total requests – Free tier request = Billable requests
แทนค่า 30M requests – 1M free tier requests = 29M Monthly billable requests
สรุป Monthly request charges = 29M * $0.2/M = $5.80

วิธีการคิด ค่า Compute (Duration Time)

สูตรคือ Total compute (seconds) = 30,000,000 * 0.2sec = 6,000,000 seconds
แปลงเป็น GB-Second Total compute (GB-s) = 6,000,000sec * 128MB/1024 = 750,000 GB-s
หา GB-Second ที่ต้องจ่าย 750,000 GB-s – 400,000 free tier GB-s = 350,000 GB-s
สรุป Monthly compute charges = 350,000 * $0.00001667 = $5.83

สรุป

หลังจากที่ผมได้เล่น AWS lambda แล้ว ผมชอบคอนเซ็ปมันนะ รู้สึกว่ามันกำลังพาเราก้าวเข้าสู่ยุคสมัยใหม่ (ขนาดนั้นเลยจริงๆ) แล้วมันก็มาพร้อมกับเรื่องที่เราต้องเรียนรู้อีกมากมาย เพราะจากความรู้สึกส่วนตัวของผม ผมรู้สึกเห็นภาพของ Unit Test และการ Design Architectuer อย่าง Microservice ได้ชัดเจนมาก เพราะด้วย Platform มันบีบให้เราต้องทำ เพราะถ้าเราไม่ทำ มันมีค่าใช้จ่ายโดยตรงที่เราต้องเสีย อย่างจำนวน Request และ Duration Time ชัดเจน (ก่อนหน้านั้น เป็นค่าใช้จ่ายแฝงของการบริหารโปรเจ็คที่เราเห็นภาพไม่ค่อยชัด อย่างเข่นการไม่มี Test)

Slide

• Introduce AWS Lambda for newbie and Non-IT

อ้างอิง

• รูปปกจาก http://alena-vysotskaya.ru/stone-wall-wallpapers/img644822B2784
• รูปอื่นๆ จาก ลิงค์ที่อ้างอิงใต้รูป

Microservices คืออะไร

ถ้าเราจะต้องออกแบบระบบ หรือไปสังเกตว่าระบบไหนเป็น Microservices สามารถสังเกตจากคุณลักษณะ 6 ข้อ ของมันได้ดังต่อไปนี้

A microservice is responsible for a single piece of functionality

มีหน้าที่ในทำงานเพียงแค่อย่างเดียว ซึ่งการจะเขียน Services เพื่อแบ่งหน้าที่การทำงานได้ จะต้องศึกษาถึงขอบเขตของ Services (Type of Capability) ว่าจะแบ่งด้วยหลักเกณฑ์ใด โดย หลักๆ มีสองประเภท คือ

1. A Business Capabilitiy : แบ่งตามจุดมุ่งหมายของ Business เช่น ทำมาเพื่อคำนวณราคาสินค้า, ทำเพื่อเก็บข้อมูลลูกค้าที่ใช้งาน Shopping Cart เป็นต้น โดยการแบ่งตามนี้ มักใช้แนวทางของ DDD (Domain-Driven Development) เข้ามาช่วย
2. A Technical Capability : แบ่งตาม Technology ที่ถูกกำหนดขึ้น เช่น มี Services อื่นต้องการใช้งานกับ Services ของเรา และมีข้อจำกัดบางอย่าง ดังน้ัน ต้องออกแบบ Services ให้ทำงานร่วมกันได้

A microservice is individually deployable

มีอิสระต่อกัน ไม่ผูกพันกับส่วนอื่นๆ สามารถอยู่ได้ด้วยตัวเอง ถ้า Service ตัวหนึ่งพัง หรือปิดลง ตัวอื่นจะต้องไม่พังตามไปด้วย ดังนั้นการ Deploy จะเป็นอิสระจากระบบอื่นๆ ด้วย

 (ภาพจากหนังสือ Microservices in .Net Core)

ยิ่งการ Deploy เป็นก้อนใหญ่มาก ความเสี่ยงที่เกิดกับระบบก็จะมีมากขึ้น ดังนั้น ถ้าจะให้เป็นตามหลักการนี้ จะต้องคำนึงถึงการออกแบบให้เล็กพอที่จะไม่กระทบกับส่วนอื่นๆ และสามารถเปลี่ยนแปลงได้เรื่อยๆ

A microservice consists of one or more processes

ใน Microservices สามารถมีได้หลาย Process แต่ว่า จะต้องไม่ไปเกี่ยวกับ Process ของ Services ตัวอื่นๆ เช่น ระบบ Shopping Cart กับ Product Category จะต้องไม่มี Process การทำงานที่ไปเกี่ยวข้อง ดังนั้น ถ้ามันผูกกันอยู่ และเราต้องการ Deploy Shopping Cart ใหม่ เราจำเป็นต้อง Deploy Product Category ด้วย ทั้งๆที่มันไม่ได้ถูกแก้ไข

 (ภาพจากหนังสือ Microservices in .Net Core)

A microservice owns its own data store.

มีจัดเก็บข้อมูล (Data) เป็นของตนเอง ดังนั้น ถ้า Services แต่ละตัวต้องการใช้ข้อมูลของ Services อื่นๆ จะต้องเรียกผ่าน API ของ Services นั้น จะไม่เรียกตรงไปที่ Database เพราะ ถ้าในแต่ละ Microservices สามารถใช้เทคโนโลยี Database ต่างกันได้ และก็มีโอกาสที่จะเกิดเปลี่ยนแปลงภายหลังได้ ดังนั้น ถ้า Database มีการแก้ไขเกิดขึ้น ตัว API Service ที่เรียกใช้ จะต้องแก้ตามไปด้วย และอีกเหตุผลหนึ่งคือ ส่วนของ Database มักต้องควบคุมเรื่อง Performance และ Scalability ที่จะเกิดขึ้นได้ตลอดเวลา ดังนั้น ถ้ามีส่วนอื่นๆมาเกี่ยวข้องด้วย จะทำให้ควบคุมการใช้งานได้ยาก

 (ภาพจากหนังสือ Microservices in .Net Core)

A small team can maintain a handful of microservices.

ทีมเล็กๆ ก็สามารถดูแลรักษา Microservices ตัวหนึ่งๆได้ สามารถใช้ภาษาเขียนหรือเทคโนโลยีตามที่ทีมถนัดได้ เพราะแต่ละ Services แยกออกจากกัน

ถามว่าทีมเล็กๆที่ว่าควรเป็นเท่าไร คือ ประมาณ 5 คน

A microservice is replaceable.

จะต้องถูกออกแบบมาให้ทดแทนได้ เพราะบางที Requirement เปลี่ยน หรือมีเทคโนโลยีที่เหมาะสมใหม่เข้ามา เช่น ภาษาที่ใช้เขียน, Database ทีมที่พัฒนาจะใช้เวลาเท่าเดิมหรือเวลาที่เหมาะสม ในการพัฒนาใหม่ เพื่อนำไปใช้ทดแทนของเดิมได้ทันที

หน้าตาของโครงสร้าง Microservices

ถ้าอธิบายด้วยรูป เทียบกับการออกแบบแบบเดิม กับ Microservices

 การออกแบบแบบเดิมตามชั้นการทำงาน (Traditional N-tier application architecture)
(ภาพจาก https://www.packtpub.com/)

การออกแบบแบบ Microservices
(ภาพจาก https://www.packtpub.com/)

ดังนั้น ถ้าสมมติว่าเราได้แตก Services ออกมา และมีหลาย Services เชื่อมโยงกัน ภาพจะได้ประมาณนี้

(ภาพจาก https://www.nginx.com/)

ทำไมเราต้องใช้ Microservices

พอเข้าใจและเห็นภาพของ Microservices กันบ้างแล้ว คำถามต่อมาคือ แล้วทำไมต้องใช้ หรือทำแล้วจะได้อะไร?

จาก คุณลักษณะ Microservices 6 ข้อ ข้างต้นที่ว่ามา จะทำให้เกิดผล 3 ข้อ ดังนี้

• Malleable: พลิกแพลงระบบได้ง่าย (ระบบมี Flexible ยืดหยุ่น)
• Scalable : สามารถขยายออกได้ (หรือมีความ Elastic หดเข้าขยายออกได้ง่าย )
• Resilient : ตายไม่เป็น หรือเรียกกลับคืนได้ไว

ถ้ามองให้เห็นภาพว่า 3 ข้อดังกล่าว จะให้ประโยชน์อะไรกับเราได้บ้าง คือ

Enable continuous delivery

ไม่ใช่ว่าทำ CI/CD แล้วจะต้องทำ Microservices นะครับ แต่หมายถึง มันสอดคล้องกัน ทำให้เราสามารถใช้กระบวนการ CI/CD (Continuouse Integration/Continuouse Delivery) ได้ง่ายขึ้น เพราะ

• พัฒนาระบบและแก้ไขได้ไว (ก็มันเล็กนี่นะ)
• ทดสอบได้ด้วยการทำ automated tests (เพราะเล็ก ทดสอบการทำงานแค่อย่างเดียว ไม่ซับซ้อน)
• Deploy ได้อย่างอิสระ
• Operate ได้อย่างมีประสิทธิภาพ

ดังนั้นถ้าสอดคล้องกับการทำ CI/CD แล้ว สิ่งที่เป็นประโยชน์ตามมาในระดับ Business คือ

• เพิ่มความเป็น Agility ให้เกิดขึ้น เพราะยืดหยุ่นและส่งมอบ product ได้ไวขึ้น
• ทำให้ระบบน่าเชื่อถือขึ้น
• ลดความเสี่ยง
• และทำให้ product มีประสิทธิภาพมาขึ้น

High level of maintainability

มีสองมุมมองคือ

มุมมองของ Developer

• ทำงานเพียงหนึ่งเดียว ง่ายต่อการพัฒนาและดูแล
• เก็บข้อมูล (Data) ไว้ที่ตัวเอง และมีการกระทำจากแค่ภายใน Service ตนเอง ทำให้ง่ายต่อการเข้าใจระบบ
• สามารถทำ Automated Test ได้ง่าย เพราะมี Process ทำงานเพียงเรื่องเดียว

อีกมุมคือ มุมมองของ Operatios

• สามารถดูแลได้ด้วยทีมขนาดเล็ก
• ง่ายต่อการ Monitor การทำงานของแต่ละ Service
• มีการ Deploy ที่เป็นอิสระจากกัน

Robust and scalable

Microservices ง่ายต่อการขยาย เพราะเป็นอิสระต่อกัน ดังนั้น ถ้า Services ตัวใดต้องการขยายให้มีขนาดใหญ่ขึ้น(หรือเล็กลง) สามารถทำได้เฉพาะ Services นั้น ไม่จำเป็นต้องทำทั้งระบบ ประหยัดทรัพยากรได้ทางอ้อมด้วย

—

หลังจากได้รู้จัก Microservices ไปแล้ว ยังอยากทำอยู่หรือเปล่าครับ?

อ้างอิง

• Microservices in .NET Core: with examples in Nancy
• ภาพปก https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/