ผมเคยเขียนในบล็อกเรื่อง ทดสอบความเร็ว .NET Core 3.0 และฟีเจอร์ ReadyToRun (R2R) ในการทำ AWS Lambda ซึ่งตอนนั้น ได้ทำเป็น Custom Runtime และผลลัพธ์ที่ได้ .NET Core 3.0 เร็วกว่า 2.1 นิดเดียว แทบไม่เห็นความต่าง ดีขึ้นแค่เสถียร เพราะมันไปช้าที่ AWS Custom Library ดังนั้นผมจึงแนะนำให้ทุกคนไปใช้ LambdaNative แทน แต่ก็ยังมีปัญหาว่า Microsoft.DotNet.ILCompiler ไม่รองรับการทำงานที่ซับซ้อน อย่างการเรียกใช้งาน Database ร่วมกับ EFCore หรือ Dapper จึงทำให้ต้องเลี่ยงไปใช้ต่อตรงด้วย ADO.NET แทน

ปัจจัยที่ทำให้ .NET Core 3.1 ทำงานได้ไวใน AWS Lambda

จากที่ทดสอบเอง, ดู Benchmark, และอ่านๆ จากหลายแหล่ง พบว่ามีหลักๆ มี 2 เรื่อง ที่เป็นฟีเจอร์ใหม่ใน .NET Core 3 ที่ช่วยให้ AWS Lambda ทำงานได้ไวขึ้น คือ

1. Built-in JSON support : ซึ่งปกติผู้เขียน C# เวลาต้องแปลง Object, Array ออกไปเป็น JSON จะต้องใช้ Library อย่างเช่น Newtonsoft.Json ซึ่งมันดีนะ แต่มันก็คือการจัดการ String บน .NET แบบ UTF-16 ซึ่งจะเปลืองทรัพยากรมากในการ convert ไปๆมาๆ
   
   แต่สำหรับ .NET Core 3.0 เป็นต้นมา ได้ built-in JSON Converter เข้าไปเลย และทำงานแบบ UTF-8 encoder ตั้งแต่ต้น จึงไวขึ้น และเมื่อ Core มันมี JSON Converter มาแล้ว ก็ไม่ต้องเรียก 3rd Party Library จึงทำให้ AWS Lambda เราตัวเล็กลงด้วย (ดูการเปรียบเทียบ The Battle of C# to JSON Serializers in .NET Core 3)
2. ReadyToRun : เป็นฟีเจอร์ที่ Microsoft ภูมิใจนำเสนอมา ตั้งแต่ปล่อยตัว .NET Core 3.0 Preview 6 แล้ว นั่นคือทำให้ .NET Core application แปลงเป็น Native App ส่งผลให้มีการทำงานที่ไวขึ้น มี startup time ที่ดีขึ้น (AOT – ahead-of-time) เพราะไปลดปริมาณงานที่ต้องแปลง Byte Code เป็น Executable Code ลง (JIT – Just in Time)

ดังนั้น แม้ว่า 3.1 จะเร็วขึ้นมาบ้าง แต่ก็ยังแนะนำให้ทำ AWS Lambda เป็น ReadyToRun นะครับ

การ Migrate ไปใช้ .NET Core 3.1 Runtime บน AWS Lambda

แก้แค่ 3 จุดหลักๆ (ส่วนโค้ดอื่นๆ ที่ไม่รองรับหลังจากทำ 3+1 ข้อนี้ ก็ไปตามแก้กันต่ออีกนะ)

1. เปลี่ยน Target Framework ใหม่

<TargetFramework>netcoreapp3.1</TargetFramework>

2. เปลี่ยนการเรียกใช้ JSON ใหม่

ใช้ JSON Package ใหม่ชื่อ

Amazon.Lambda.Serialization.SystemTextJson

และระบุใน Class Handler ใหม่เป็น

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

3. ใน Deployment Config เปลี่ยน Function Runtime ใหม่ (aws-lambda-tools-defaults.json)

"framework" : "netcoreapp3.1",
"function-runtime":"dotnetcore3.1",

ในกรณี ต้องการทำเป็น ReadyToRun จะต้องเพิ่มใน Csproj file ด้วยดังนี้

<PublishReadyToRun>true</PublishReadyToRun>
<TieredCompilation>false</TieredCompilation>
<TieredCompilationQuickJit>false</TieredCompilationQuickJit>

ที่ต้องปิด Tiered Compilation เพราะจะเกิด Startup Time สูงขึ้น และใช้ Memory เยอะขึ้นโดยใช่เหตุ (อ้างอิง Performance จาก .NET Core 3.0 AWS Lambda Benchmarks and Recommendations และหากใครต้องการเข้าใจ What’s new in .NET Core 3.0)

และถ้าจะใช้ ReadyToRun จะต้อง Build และ Publish เป็น Linux Runtime นะครับ ไม่สามารถ Build Image บน Windows/Mac แล้วเอาขึ้นไปทำงานบน AWS Lambda ได้ เนื่องจากบนนั้นจะเป็น Amazon Linux 2 (ไปดูลิงค์ Demo ของผมที่ด้านล่างได้ ว่าทำอย่างไร)

ผลทดสอบ Cold Start ของ AWS Lambda .NET Core 2.1 เมื่อเทียบกับ 3.1 และ 3.1 ReadyToRun

ผมใช้โค้ดทดสอบตัวเดิมกับที่เคยทดสอบในบล็อก ทดสอบความเร็ว .NET Core 3.0 และฟีเจอร์ ReadyToRun (R2R) ในการทำ AWS Lambda ซึ่งได้ลองรัน 2.1 ก่อน จากนั้น migrate ไปเป็น 3.1 เพื่อเก็บข้อมูล และสุดท้ายก็ Compile ไปเป็น 3.1 ReadyToRun เพื่อเก็บข้อมูล

โดยการทำงานของโค้ดจะมีการเชื่อมต่อ MySQL Database 5.6 โดยมี table ชื่อ members ที่มี 3 รายการ (ค่าจะผันผวนบ้าง อาจเกิดจากการเรียกใช้ MySQL Database)

จะสังเกตได้ว่า แค่แปลงไปใช้ Runtime 3.1 และ Built-in JSON ก็ลดเวลาการเกิด Cold Start ลงไปหนึ่งเท่าตัวเลยทีเดียว

และเมื่อทำเป็น 3.1 ReadyToRun ก็เร็วขึ้นอีกราวๆ 100ms และเมื่อเพิ่ม config เพื่อปิดการใช้ Tiered Compilation ก็ทำให้เร็วขึ้นไปอีก 100-300ms เมื่อใช้ Memory 128MB และ 256MB

แต่มีข้อสังเกตว่า การทำ ReadyToRun มีความเสถียรขึ้น รันครั้งที่ 2 เป็นต้นไป ไม่เจอว่าเกิน 100ms เลย (อย่าลืมว่า AWS Lambda คิดเงินทุกๆ 100ms ดังนั้นเมื่อเกิน มันจะปัดเศษขึ้นไปเป็นอีก 100ms) ส่วนความเร็วที่ผันผวนขึ้นลง 3-5ms ผมคิดว่ามีความต่างน้อยมากๆ ไม่จำเป็นต้องใส่ใจก็ได้ ถ้างานเราไม่ได้ซีเรียสกับเวลาแค่นี้

และเมื่อเราไม่ใช้ LambdaNative กับ Microsoft.DotNet.ILCompiler  ตัวปัญหาแล้ว มันจึงทำให้เราใช้ Library ต่างๆ อย่าง Dapper ได้แล้วครับ ไม่ต้องใช้ ADO มา Mapping Object เองอีกต่อไป แต่ก็ต้องแลกกับเวลาที่มากขึ้นอีก 15-30%

สรุป

ใครใช้ .NET Core 2.1 บน AWS Lambda อยู่ หรือใช้ LambdaNative หรือใช้ Custom Runtime ตามที่ผมเคยเขียนถึง แนะนำให้เปลี่ยนมาใช้ .NET Core 3.1 ของ AWS Official Runtime ครับ ไวกว่ามาก และถ้าเป็นไปได้ ก็ควรทำให้เป็น ReadyToRun Image ด้วย เพื่อประสิทธิภาพที่ดีขึ้นครับ

ส่วนใครอยากลองดูโค้ดตัวอย่าง ดูได้จากด้านล่างนี้เลย

Code Demo

• AWS Lambda .NET Core 3.1 แบบธรรมดา
• AWS Lambda .NET Core 3.1 แบบทำเป็น ReadyToRun
• AWS Lambda .NET Core 3.1 แบบทำเป็น ReadyToRun และใช้ Dapper ในการเรียกใช้งาน MySQL Database

อ้างอิง

• https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/
• https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0
• https://medium.com/@zaccharles/a-close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be
• https://vincepergolizzi.com/programming/2020/04/01/dotnet-core-3.1-lambda.html

Performance Testing, Load Testing กับ Stress Testing ต่างกันอย่างไร

ก่อนจะไปถึงเครื่องมือ มาทำความเข้าใจกันก่อนว่า Test ทั้ง 3 ตัวนี้ ต่างกันอย่างไร

ต้องบอกว่า Load Testing และ Stress Testing เป็นส่วนหนึ่งใน Performance Testing ซึ่งคือ การที่เราทดสอบในแง่มุมต่างๆ เพื่อบ่งบอกประสิทธิภาพของระบบ เช่น

• ระบบมีการทำงานได้เร็วไหม? ความเร็วเท่าไร? ที่จำนวน Request แต่ละชุด (Load Testing)
• ถ้าระบบทำงานหนักๆ ติดต่อกันนาน จะเกิดปัญหาไหม? (Endurance Testing)
• ถ้าระบบทำงานหนักมากๆ จนล่ม สามารถกลับมาทำงานได้ไหม? ใช้เวลากลับมา นานแค่ไหน? (Recovery Testing)
• ถ้าระบบทำงานสูงขึ้นเรื่อยๆ แบบเกินปกติ จะรองรับได้ที่เท่าไร? (Stress Testing)
• ถ้าระบบมีการใช้งานพุ่งสูงแบบกระทันหัน จะเกิดปัญหาไหม? (Spike Testing)

จริงๆ มีมากกว่านี้ แต่จากรายการข้างต้น เรียกว่าเป็นกลุ่มของ Non-Functional Testing ที่ไม่ได้เห็น Bug ชัดเจนจากการเขียนโปรแกรมที่ผิดพลาด จึงอาจต้องอาศัยคนหรือเครื่องมือเพื่อจำลองสถานการณ์ขึ้นมา ว่าได้ตามเกณฑ์ที่กำหนดหรือเปล่า

รู้จักกับ k6 – Open source load testing tool

k6 เป็นเครื่องมือ Open source ที่เขียนด้วยภาษา Go สำหรับทำ Load Testing โดยทำคำสั่งผ่าน CLI คล้ายกับ ab (ApacheBench) แต่ด้วยความที่มันเป็น Scriptable tools เลยทำให้สามารถเขียนโค้ดทดสอบเพิ่มเติมได้ โดยใช้ภาษา Javascript และแน่นอน มันจึงทำ Automated Testing ได้สะดวกขึ้น และน่าจะถูกใจชาว Developer ด้วย

อธิบายเพิ่มเติม: ab (ApacheBench) เป็นเครื่องมือประเภท Non-Scriptable ข้อดีคือใช้งานง่าย เพียงพิมพ์คำสั่งและตามด้วย parameter ที่กำหนด ก็ใช้งานได้เลย เหมาะกับคนทั่วไปที่ไม่ต้องเขียนโค้ดเป็น แต่ข้อเสียคือ ไม่สามารถทำอะไรได้นอกเหนือจาก parameter ที่มีให้ ตัวอย่างเช่น

ab -n 100 -c 10 http://www.website.com/ -H "clientId:1234" -H  "token:a2ds5mvo93mcnsk3ncsju3nxdl"

ส่วนเครื่องมือที่นิยมอีกตัวหนึ่ง คือ Apache jMeter ที่สามารถเขียนคำสั่งได้ด้วย XML แต่ก็ต้องทำภายใต้ข้อจำกัดของ XML Syntax ที่เขาเตรียมไว้ให้

วิธีติดตั้ง k6

k6 รองรับการใช้งาน 3 ระบบ เลือกติดตั้งตามความเหมาะสมได้เลยครับ

สำหรับชาว Linux (deb and rpm packages)

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61
echo "deb https://dl.bintray.com/loadimpact/deb stable main" | sudo tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get install k6

สำหรับชาว Mac (brew)

brew install k6

สำหรับชาว Windows (MSI installer)

ไปโหลดได้ที่: https://dl.bintray.com/loadimpact/windows/k6-v0.26.1-amd64.msi
หรือเข้าไปดู release ล่าสุดได้ที่ https://github.com/loadimpact/k6/releases

ติดตั้งใช้งานผ่าน Docker

docker pull loadimpact/k6

เริ่มต้นทดสอบ Load Testing ด้วย k6 อย่างง่าย

ลองมาทดสอบด้วยการส่ง Request ไปหาเว็บไซต์ http://test.k6.io กัน โดยการสร้างไฟล์ k6-script.js ขึ้นมา และใส่โค้ดไปดังนี้

import http from 'k6/http';
import { sleep } from 'k6';

export default function() {
  http.get('http://test.k6.io');
  sleep(1);
}

จากนั้นทำการ run ชุดโค้ดทดสอบด้วยคำสั่ง ดังนี้

k6 run k6-script.js

จะได้ผลลัพธ์ออกมาแบบนี้ครับ

โดยที่ค่าสำคัญๆ ที่เราจะใช้ดู คือ

• duration : เวลาที่จะใช้ทดสอบ (ในที่นี้ไม่ได้ระบุ จึงไม่ได้ใช้)
• iterations : จำนวนครั้ง request ที่ใช้ทดสอบ (ในที่นี้ไม่ได้ระบุ จึงเป็นค่า 1)
• vus : ย่อมาจาก virtual user หรือการจำลองคนใช้งาน 1 คน (ในที่นี้ไม่ได้ระบุ จึงเป็นค่า 1)
• max : คือจำนวน vus มากที่สุดที่จะใช้ทดสอบ โดยจะใช้ระบุคู่กับ duration เท่านั้น (ในที่นี้ไม่ได้ระบุ จึงเป็นค่า 1) และในการทำ stage จะใช้ชื่อว่า target
• data_received : จำนวน Byte ที่มีการรับกลับมาจากการทดสอบ
• data_sent : จำนวน Byte ที่มีการส่งออกไปเพื่อทดสอบ
• http_req_duration : จำนวนเวลารวมที่มีการ request ทดสอบ (ผลรวมของ http_req_sending + http_req_waiting + http_req_receiving)
• http_reqs : จำนวนครั้งที่มี request ในช่วงเวลา duration ที่กำหนด

ส่วนค่าอื่นๆ อ่านคำอธิบายได้จากที่นี่ครับ https://k6.io/docs/getting-started/results-output

ลองใส่ k6 Parameters ง่ายๆ เพื่อกำหนดรูปแบบการทดสอบ

กำหนดให้ vus เป็น 10 และ duration time เป็น 30 วินาที

k6 run --vus 10 --duration 30s k6-script.js

กำหนดให้ vus เป็น 10 และขยับขึ้นไปที่ 20 ภายในเวลา 30 วินาที

k6 run --vus 10 --duration 30s --max 20 k6-script.js

กำหนดให้ vus เป็น 10 และ iteration เป็น 100 ครั้ง (หมายถึง 1 vus ทำการ request 10 ครั้ง)

k6 run --vus 10 --iterations 100 k6-script.js

ข้อมูล Parameters ต่างๆ สามารถดูเพิ่มเติมได้ที่นี่ครับ https://k6.io/docs/using-k6/options

เปลี่ยนจากการระบุ Parameters รูปแบบการทดสอบ มาเป็นเขียนโค้ด

parameter ต่างๆ เราสามาถเขียนในรูปแบบโค้ด ใน Javascript เราได้ด้วยนะครับ เช่น

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
  vus: 10,
  iterations: 100,
};

export default function() {
  http.get('http://test.k6.io');
  sleep(1);
}

จากนั้นก็สั่ง run โค้ด แบบไม่ต้องระบุ parameter ก็จะได้ผลลัพธ์เหมือนกัน

k6 run k6-script.js

รูปแบบการใช้งานต่างๆ อ่านได้จากที่นี่ครับ https://k6.io/docs/getting-started/running-k6 และสามารถดู Options ต่างๆ ได้ที่นี่ครับ https://k6.io/docs/using-k6/options

ทดสอบ Load Testing แบบ Stages ด้วยการกำหนดจำนวน vus ให้ขึ้นลงตามระยะเวลาที่กำหนด

บางทีเราต้องการจำลองการทดสอบจำนวนคนเข้า (vus) ในแต่ละช่วงเวลาไม่เท่ากัน จะขยับขึ้น (ramping up) จะลง (ramping down) หรือจะขึ้นไปเรื่อยๆ ก็สามารถระบุเป็น Stages ได้ เช่น

ต้องการทดสอบโดยให้ vus มีประมาณจาก 1 ไป 20 vus ภายในเวลา 30 วินาที จากนั้นให้ลดลงมาที่ 10 vus ภายในเวลา 1:30นาที และลดลงเป็น 0 ภายในเวลา 20 วินาที จะเขียนโค้ด ดังนี้

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
  stages: [
    { duration: '30s', target: 20 },
    { duration: '1m30s', target: 10 },
    { duration: '20s', target: 0 },
  ],
};

export default function() {
  http.get('http://test.k6.io');
  sleep(1);
}

ผลลัพธ์ที่ได้คือ ทดสอบจำนวน 2:20 นาที มี requests ได้ถึง 1,394 ครั้ง

ทดสอบส่งค่าผ่าน HTTP Request และทำการเช็คผลลัพธ์ที่ได้

ได้ลอง Get data ไปแล้ว คราวนี้มาลองส่ง Input data ผ่าน Post บ้าง และระบุ Header ด้วย จากนั้นจะต้องได้ผลลัพธ์ตามที่เรากำหนด ซึ่งจะมีรูปแบบการเขียนดังนี้

import { check } from "k6";
import http from 'k6/http';

export default function() {
  var url = 'http://test.loadimpact.com/login.php';
  var formdata = {
    login: 'admin',
    password: '123',
  };

  var params = {
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    redirects: 1
  };

  let res = http.post(url, formdata, params);
  let jar = http.cookieJar();
  let cookies = jar.cookiesForURL(url);

  check(res, {
    "is status 200": r => r.status === 200,
    "has cookie 'sid'": (r) => cookies.sid.length > 0,
    "has cookie 'uid'": (r) => cookies.uid.length > 0,
    "cookie 'sid' has correct value": (r) => cookies.sid == "39b77ac6-39c4-4c43-98b3-6b2816682036",
    "cookie 'uid' has correct value": (r) => cookies.uid == "3221"
 });

}

ผลลัพธ์ที่ได้คือ

ในตัวอย่าง ผมได้ทดสอบการ login เข้าสู่ระบบ โดยส่ง login, password ผ่าน form data ไปให้ url จากนั้น ทำการตรวจสอบความถูกต้อง 5 เรื่อง คือ

• ได้ HTTP Status Codes คือกลับมาเป็น 200 หรือไม่
• มี Cookie ชื่อ sid หรือไม่
• มี Cookie ชื่อ uid หรือไม่
• Cookie ชื่อ sid มีค่าที่ต้องการหรือไม่
• Cookie ชื่อ uid มีค่าที่ต้องการหรือไม่

ซึ่ง จากผลลัพธ์ สามารถเรียกใช้งานได้ และมีความถูกต้อง 5 เรื่อง ข้างต้นด้วย

ซึ่งถ้าผมอยากทำ Load Testing ระบบ login นี้ด้วยการจำลองสัก 10 vus จำนวน 100 ครั้ง ก็ใช้คำสั่งที่เราเคยลองทำมาคือ

k6 run --vus 10 --iterations 100 k6-script-http.js 

สรุป

จากที่ได้ลองเล่น k6 ดู ผมชอบตรงที่สามารถเขียนโค้ดการทดสอบได้ (Scriptable) และเขียนด้วยภาษา Javascript ที่นักพัฒนาเว็บไซต์ในโลกส่วนใหญ่มักจะเขียนเป็นกันอยู่แล้ว รวมไปถึง ตัว k6 เอง ใช้ภาษา Go ที่มีความสามารถในการทำงานที่เร็วและไม่กิน Memory มากนัก คิดว่าต่อไปคงได้เปลี่ยนจาก ApacheBench มาใช้ k6 แทน อย่างไม่ต้องสงสัยเลยครับ

ใครสนใจ สามารถไปดูข้อมูลเพิ่มเติมต่อได้ที่ https://k6.io/

ใครอยากได้ Demo ที่ผมทดสอบ หาได้จากที่นี่ครับ https://github.com/ifew/k6-load-testing

ส่วนใครอยากดูผลการ Benchmark ทดสอบเครื่องมือ Load Tesing สามารถดูได้ที่ https://k6.io/blog/comparing-best-open-source-load-testing-tools (ดูข้อมูลและกราฟทดสอบก็พอ อย่าไปเชื่อผลสรุปมันมาก เพราะค่อนข้างลำเอียง อารมณ์ล้วนๆ จากคนเขียน k6 เอง ฮ่าๆ)

Reference

• https://k6.io/
• https://k6.io/blog/comparing-best-open-source-load-testing-tools/

ในครั้งนี้มีฟีเจอร์หนึ่งที่น่าสนใจคือ ReadyToRun (R2R) ซึ่งจริงๆ มันมาตั้งแต่ .NET Core 3 Preview 6 แล้ว นั่นคือทำให้ .NET Core application แปลงเป็น Native App ให้ไวขึ้น ส่งผลกับ startup time ที่ดีขึ้น (AOT – ahead-of-time) จากแต่เดิมซึ่งมีเพียงแค่ แปลง Byte Code เป็น Executable Code (JIT – Just in Time)

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

เริ่มต้นใช้ ReadyToRun (How to Use)

วิธีการใช้ ReadyToRun ไม่ยาก แค่ตั้ง Config ในไฟล์ csproj ได้เลย ตัวอย่างที่ผมใช้จะประมาณนี้

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <LangVersion>latest</LangVersion>
    <AWSProjectType>Lambda</AWSProjectType>
    <PublishReadyToRun>true</PublishReadyToRun>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

Config R2R ที่ใช้บ่อย จะมี ดังนี้

• PublishReadyToRun คือ บอกให้แอพเรา Publish เป็น ReadyToRun Image
• PublishTrimmed คือ ตัด assemblies ที่ไม่ได้ใช้ออกไป ซึ่งจะช่วยลดขนาดไฟล์ได้ (โดยจะวิเคราะห์ IL จาก Library ที่ชื่อว่า IL linker สามารถไปดู Docs เพื่อกำหนดค่าต่างๆได้)
• PublishSingleFile คือ บอกว่าจะ Publish โดยแพ็คมาให้เป็น Executable File ไฟล์เดียว (ดูข้อมูลเพิ่มเติมได้ที่ design)

และเวลา publish จะต้องระบุ RuntimeIdentifier ด้วย เช่น

dotnet publish -r win-x64 -c Release

ดู Runtime เพิ่มเติมได้ที่ .NET Core Runtime IDentifier (RID) catalog

วิธีการทดสอบ (Test Scenarios)

ผมเคยทดสอบ AWS Lambda เพื่อแก้ปัญหา Cold Start ด้วยหลายๆ วิธี (อ่านเพิ่มเติมได้จาก 9 วิธีจัดการกับ Cold Start ใน Serverless ให้ทำงานได้ไวที่สุด พร้อมตัวอย่าง) ครั้งนี้ผมจึงอ้างอิงจากโค้ดชุดเดิม โดยจะทดสอบ 3 Scenarios ดังนี้

1. ชุดโค้ด .NET Core Dll file ปกติ ที่เปลี่ยน Version จาก AWS Standard Runtime .NET Core 2.1 มาเป็นทำ Custom Runtime ขึ้นมาเองด้วย .NET Core 3.0.100 ผ่านไลบรารี่ Amazon.Lambda.RuntimeSupport
2. ชุดโค้ด .NET Core Native ที่ใช้ไลบรารี่ LambdaNative และ Microsoft.DotNet.ILCompiler แต่เปลี่ยน Version จากเดิม Custom Runtime .NET Core 2.2 มาเป็น Custom Runtime .NET Core 3.0.100
3. ชุดโค้ด .NET Core Native ที่ใช้ไลบรารี่ LambdaNative อย่างเดียว แต่เปลี่ยน Version จากเดิม Custom Runtime .NET Core 2.2 มาเป็น Custom Runtime .NET Core 3.0.100 โดยจะ Publish เป็น ReadyToRun Image

Database ผมใช้ MySQL 5.5 ที่อยู่บน AWS RDS วงเดียวกันกับ AWS Lambda ที่ผมทดสอบ และจำนวนข้อมูลมีเพียง 3 Rows

ผลการทดสอบ (Benchmark Results)

Scenario 1 – Normal Compile with Custom Runtime .NET Core 2.2 กับ .NET Core 3.0.100 โดยใช้ ADO ในการเชื่อมต่อกับ MySQL

จะสังเกตว่า .NET Core 3.0 ภาพรวมแล้ว เวลาของ Cold Start จะไวกว่า 2.2 เมื่อใช้ Memory 256Mb และ 512Mb แต่เมื่อเรียกใช้งานซ้ำๆ .NET Core 3.0 ทำงานได้ไวกว่าทุกกรณี

คราวนี้ลองมาดูเทียบ .NET Core 3.0.100 ด้วยกัน แบบที่ใช้ ReadyToRun กับแบบไม่ใช้

ผลคือ เมื่อทำเป็น ReadyToRun จะมีความเร็วของ Cold Start มากกว่าเดิม 50% แบบชนะขาดลอย ส่วนการเรียกใช้งานแบบซ้ำๆ ตรงนี้ เลขที่ผมได้ ยังเหวี่ยงๆ แต่โดยรวมถือว่าดีกว่า

มาลองเทียบ .NET Core 3.0.100 แบบที่ใช้ ReadyToRun แต่ใช้ Library Connect MySQL ต่างๆ

ผลตามคาด คล้ายกับบล็อกเดิมที่ผมเคยทดสอบ คือ ADO เร็วที่สุด รองมาเป็น Dapper และช้าสุดคือ EFCore แต่ทั้งนี้ ผมจะทดสอบใหม่อีกครั้งเมื่อ EFCore 3.0 รองรับการใช้งาน MySQL (ซึ่งตอนที่ผมเขียนบล็อกนี้ รองรับ MySQL แค่ EFCore 2.2 อยู่นะครับ)

และให้สังเกต ว่าตรง memory 128 ผมมีคำว่า (max) อยู่ หมายถึงว่า .NET Core 3.0 กิน memory มากขึ้นจน Lambda ใช้เกิน Memory 128Mb

Scenario 2 – .NET Core 3.0.100 with LambdaNative and Microsoft.DotNet.ILCompiler โดยใช้ ADO ในการเชื่อมต่อกับ MySQL

ที่ผมเคยเขียนถึง .NET Core 2.2 และ LambdaNative ไว้ใน 9 วิธีจัดการกับ Cold Start ใน Serverless ให้ทำงานได้ไวที่สุด พร้อมตัวอย่าง เป็นวิธีการที่แก้ปัญหา Cold Start ได้ดีที่สุด แต่เมื่อทดสอบกับ .NET Core 3.0 ด้วยแล้วปรากฎว่า ผมลัพธ์ดีขึ้นกว่าแต่เดิม และความเร็วเสถียรพอกันทุกครั้งที่มีการเรียกซ้ำๆ เป็นที่น่าพอใจมาก

Scenario 3 – .NET Core 3.0.100 with LambdaNative and ReadyToRun โดยใช้ ADO ในการเชื่อมต่อกับ MySQL

ลองใช้ LambdaNative ร่วมกับ ReadyToRun ปรากฎว่าทำงานได้ช้ากว่า ใช้ไลบรารี่ Microsoft.DotNet.ILCompiler เสียอีก

การทำงานของ ReadyToRun จะมีการ Extract Bundle Files (ดูข้อมูลเพิ่มเติมได้ที่ bundler) ก่อนทำการ Execution ผมจึงลองทดสอบแบบทำเป็น Single File ที่เอา Bundle รวมกับโค้ด (PublishSingleFile เป็น true) และแบบ Multiple File ที่เอา Bundle แยกกับโค้ด (PublishSingleFile เป็น false) มาเทียบกัน ปรากฎว่า แบบ Single File ทำงานได้เร็วกว่า (น่าจะมาจาก ahead-of-time ใน .NET Core 3.0 นี้)

ถ้าลองเทียบทั้งหมดจาก Scenario 2 และ Scenario 3 พบว่า .NET Core 3 NativeLambda ที่ทำงานกับ Microsoft.DotNet.ILCompiler จะทำงานได้ไวที่สุด

คราวนี้ลองถ้าลองเปลี่ยนตัว Connect MySQL มาเป็น Dapper ดูบ้าง ผลลัพธ์จะต่างกันขนาดไหน

ในส่วนของ LambdaNative ที่ทำงานกับ Microsoft.DotNet.ILCompiler ปัจจุบันยังไม่รองรับ Dapper เช่นเดิม ดังนั้นจึงมีแต่ผลทดสอบของ LambdaNative ที่ทำงานกับ ReadyToRun ซึ่งผลลัพธ์ที่ได้ Cold Start จะช้ากว่า ADO ประมาณ 0.5-2 วินาที เลยทีเดียว

สรุป

จากผลลัพธ์ทั้งหมดที่ลองทดสอบ ฟันธงได้ว่า .NET Core 3.0 ทำงานได้ไวกว่าเวอร์ชันเก่า ในการนำมาทำ Serverless อย่าง AWS Lambda

แต่ด้วยความที่เป็นของใหม่ ผมเชื่อว่าคงมีอะไรปล่อยออกมาอีกเรื่อยๆ ดังนั้น ขอแนะนำชาว .NET Core ว่ามันคุ้มค่าแก่การ migrate ไปเป็น 3.0 ครับ (ข่าวว่า .NET Core 3.1 จะออกมาในช่วงพฤศจิกายนนี้)

บล็อกนี้ พอเห็น Release ปุ๊บรีบทดสอบและเขียนไว้ทันที ใหม่จนยังไม่มีใครเขียนถึงเลย หากผิดพลาดประการใด สามารถแนะนำ/ติชมได้นะครับ

Demo Source Code

• netcore3-readytorun-efcore – ทดสอบ .NET Core 3 ReadyToRun กับ EFCore
• netcore3-readytorun-dapper – ทดสอบ .NET Core 3 ReadyToRun กับ Dapper
• aws-lambda-netcore3-db – ทดสอบทำ Lambda ด้วย .NET Core 3 กับ ADO
• aws-lambda-netcore3-efcore – ทดสอบทำ Lambda ด้วย .NET Core 3 กับ EFCore
• aws-lambda-netcore3-dapper – ทดสอบทำ Lambda ด้วย .NET Core 3 กับ Dapper
• aws-lambda-lambdanative-db – ทดสอบทำ LambdaNative ด้วย .NET Core 3 กับ ADO
• aws-lambda-netcore3-readytorun-db – ทดสอบทำ Lambda ด้วย .NET Core 3 ReadyToRun กับ ADO
• aws-lambda-netcore3-readytorun-efcore – ทดสอบทำ Lambda ด้วย .NET Core 3 ReadyToRun กับ EFCore
• aws-lambda-netcore3-readytorun-dapper – ทดสอบทำ Lambda ด้วย .NET Core 3 ReadyToRun กับ Dapper

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