ผมเคยเขียนในบล็อกเรื่อง ทดสอบความเร็ว .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

ในครั้งนี้มีฟีเจอร์หนึ่งที่น่าสนใจคือ 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

แต่ก็กระนั้นอีก ในหน้าเว็บโปรเจ็คบอกทำงานกับ .NET Core 2.1 ได้ แต่พอลองทำดู กลับบอกว่า ไม่รองรับ .NET Core Runtime!! (ใครแก้ปัญหาสองข้อบนของผมได้ มาแลกเปลี่ยนความรู้กันหน่อยครับ จักหายคาใจ) ก็เลยต้องแกะมัน พบว่า มันไปใช้ Lambda Docker เพื่อสร้าง Environment จำลองขึ้นมาสำหรับทดสอบ.. ปั๊ดโธ่ว แบบนี้ก็เสร็จโก๋!! จึงเป็นที่มาของบล็อกนี้..

คำแนะนำ: ผู้อ่านบล็อกนี้ควรใช้งาน AWS Lambda และ Docker เบื้องต้นแล้ว, ตัวอย่างใช้เป็น .NET Core 2.1 แต่สามารถนำวิธีใช้กับภาษาอื่นๆได้

Lambda Docker คืออะไร? ดีไหม?

เป็น Docker ที่จำลอง Environment ไว้เพื่อทดสอบ (Sandbox) ของ AWS Lambda ซึ่งเคลมตัวเองว่า ใกล้เคียงกับของจริงมากๆ

ถามว่าใกล้เคียงขนาดไหน? คำตอบคือใกล้มากจริงๆ ตามที่เขาโม้ไว้ เพราะภายใน image ของมันประกอบไปด้วย software, libraries, โครงสร้างของไฟล์ และ permissions, environment variables, context objects หรือแม้แต่ user สำหรับใช้เรียก process ก็ยังใช้ชื่อเดียวกัน

ด้วยความเหมือนเป๊ะ มันจึงเหมาะที่จะเอา Lambda Function มาทดสอบบน Docker Environment ที่มีข้อจำกัดคล้ายกับ AWS Lambda ได้เกือบ 100%, และที่สำคัญ มันปรับ Memory, Timeout และใช้ Layer ได้ด้วยนะ

มีข้อดีแล้วก็ต้องมีข้อเสีย ซึ่งตอนนี้ผมพบจุดเดียว คือ เรื่องของเวลาในการคำนวณ ซึ่งเอาไปอ้างอิงไม่ได้ เพราะไม่มี Cold Start และมันเป็น CPU บนเครื่องเรา, ถ้าจำทดสอบเพื่อไปคำนวณค่าใช้จ่าย ควรใช้เครื่องมืออีกตัวชื่อว่า AWS Lambda Power Tuning (ไว้จะเขียนถึงอีกที)

สิ่งที่ต้องติดตั้งก่อนใช้ Lambda Docker

ก่อนไปต่อ ควรติดตั้ง Docker ซะก่อนนะ (เช็คให้เรียบร้อยว่าไม่ติด Security Policy ทำงานได้ดี สามารถ Pull Image และ Run Container ได้)

เริ่มต้นใช้งาน Lambda Docker

รูปแบบของคำสั่งจะเป็นดังนี้

docker run [--rm] -v <code_dir>:/var/task [-v <layer_dir>:/opt] lambci/lambda:<runtime> [<handler>] [<event>]

การทำงานของมันคือ จะสร้าง Docker Container ขึ้นมา และเอาโค้ดของเราไปรันทดสอบ ด้วยตัวแปรต่างๆที่เราระบุไว้ใน Command แค่นั้นเอง

• –rm คือเพื่อให้สร้าง Container มาทดสอบเพียงครั้งเดียว และทำลายตัวเองทิ้ง (ไม่ใส่ก็ได้ รันทำงานซ้ำไปได้เรื่อยๆ)
• -v <code_dir>:/var/task คือ ชี้ที่อยู่ของโค้ดเรา ไปให้ตรงกับโฟลเดอร์ใน Container เพื่อใช้งาน
• -v <layer_dir>:/opt คือ ชี้ที่อยู่ของ layer โค้ด ไปให้ตรงกับโฟลเดอร์ใน Container เพื่อใช้งาน (ถ้าไม่รู้จัก หรือไม่ได้ใช้ ก็ไม่ต้องใส่)
• <runtime>  คือ Runtime Language ที่เราใช้เขียน Function เช่น dotnetcore2.1, nodejs4.3, python3.7, java8, go1.x
• <handler> คือ Fucntion Handler
• <event> คือ Request Input นั่นหละ

ทดสอบรันคำสั่งง่ายๆ

ตัวอย่าง Function ของผมชื่อ aws_lambda_function โดยรับ string เข้าไป จากนั้นจะพ่นออกมาว่า “Hello, <ชื่อ>” โดยมีรูปแบบคำสั่งคือ

docker run --rm -v "$PWD":/var/task lambci/lambda:dotnetcore2.1 aws-lambda-function::aws_lambda_function.Function::FunctionHandler '"iFew"'

เนื่องด้วยการทำงานมันจะ run code ที่ผ่านการ complie แล้ว, ซึ่งถ้าให้แน่ใจ ว่าไม่ได้รันอยู่บนโค้ดชุดเดิม ให้เราทำคำสั่ง compile ก่อนสักครั้ง จากนั้นไปที่โฟลเดอร์โค้ดที่ Compiled และทำคำสั่งด้านบนอีกที (ผมชี้ที่อยู่โค้ดไปที่ $PWD หมายถึง ให้ใช้โค้ดในโฟลเดอร์ปัจจุบันที่ผมอยู่)

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

ทดสอบรันคำสั่งโดยใส่ Environment Variable

จากตัวอย่างแรก สังเกตว่ามัน Allocate Memory ให้ถึง 1,536MB เลยทีเดียว (เป็น Default ของมัน) ซึ่งผมอยากกำหนดให้ใช้ Memory แค่ 128MB และ Timeout 30 วินาที เพื่อทดสอบการทำงาน ในสภาพแวดใกล้เคียงของจริง ด้วยคำสั่งนี้

docker run --rm -v "$PWD":/var/task -e AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 -e AWS_LAMBDA_FUNCTION_TIMEOUT=30 lambci/lambda:dotnetcore2.1  aws-lambda-function::aws_lambda_function.Function::FunctionHandler '"iFew"'

ซึ่ง ใช้ parameter ชื่อ -e ของ Docker นั่นหละเป็นตัวกำหนด โดยลัพลัพธ์ที่ได้ คือ

สังเกตว่า Memory ตอนนี้จัดสรรให้แค่ 128MB เท่านั้น ส่วน Timoue ยังไม่เห็นผลในตอนนี้เพราะโค้ดง่ายๆ ทำงานไว

ตัว environment ให้ใช้งานต่างๆ ดูเพิ่มเติมได้ที่ https://github.com/lambci/docker-lambda

ทดสอบรันคำสั่งโดยอ้างอิงกับ Database ภายนอก

การใช้งานจริงๆของเรา มันไม่ง่ายเหมือน Function ด้านบนแน่นอน ซึ่งผมเจอปัญหานี้เช่นกัน และใน Document ไม่ได้บอกไว้ว่าทำอย่างไร งมอยู่สักพัก ถึงเจอวิธี โดยการใช้ทำให้ Lambda Docker ของเราอยู่ในวง Network เดียวกับ Docker Database ที่ผมมีซะ (พอดีผมใช้ MySQL บน Docker, ถ้าใครใช้ MySQL เข้าใจว่าสามารถใช้งานได้เลย เนื่องจาก network เป็นแบบ bridge ที่ทำให้ Container เราต่ออินเทอร์เน็ตหรือวง Network ในเครื่องเราได้อยู่แล้ว)

ลองดูตัวอย่างคำสั่งนี้ครับ

docker run --rm -v "$PWD":/var/task --network mysql -e TEST_LAMBDA_DBCONNECTION="server=mysql;userid=root;password=1234;database=test_lambda;convert zero datetime=True; CharSet=utf8" -e AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 lambci/lambda:dotnetcore2.1 list_profile::list_profile.Function::Get

จะสังเกตว่ามีตัวแปรแปลกๆมานิดนึง คือ –network mysql หมายถึง ให้ Container นี้อยู่ในวง Network ชื่อ mysql โดยในวงนั้นผมมี Container MySQL อยู่ในนั้นอยู่แล้ว

จากนั้นผมระบุ Environment Variable ชื่อว่า TEST_LAMBDA_DBCONNECTION เข้าไป เนื่องจากโค้ดของผมเรียกใช้ config ผ่าน Environment Variable (ตามหลักการข้อ 3. Config ใน The Twelve Factor)

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

แถมนิดนึง วิธีการสร้าง Docker Network

คำสั่งง่ายๆ คือ

docket create network <ชื่อnetworkที่ต้องการ>

แค่นี้ก็จะได้วง Network มาแล้วครับ โดยในตัวอย่างผมใช้ชื่อวงว่า mysql

ดังนั้น หากเรามี Container อยู่แล้ว ให้เพิ่มเข้าวง Network ด้วยคำสั่ง

docker network connect <ชื่อnetwork> <ชื่อcontainer>

ทดสอบรันคำสั่งโดยส่ง Request Input ด้วย APIGatewayProxy (หรือรันคำสั่งแบบมี JSON Input ยาวๆ)

โดยปกติผมจะใช้ AWS API Gateway อยู่แล้ว ดังนั้นตัว Request Input ผมจะชอบใช้ในรูปแบบของ API Gateway Proxy Request เพราะมันสามารถส่ง Request Input ได้ทั้งแบบ Path Parameter, Query String, Header, Body ซึ่งลดควมซับซ้อน ไม่ต้องไปทำการ Mapping Input Data อะไรให้ยุ่งยากใน AWS API Gateway ซึ่งถ้าคุณใช้เหมือนกัน ก็สามารถเอาตัวอย่างนี้ไปทดสอบกับ Lambda Docker ได้ครับ

โดยตัว API Gateway Proxy Request เนื้อมันจริงๆคือ JSON ที่ AWS API Gateway รับเข้าไป จากนั้นมันจะกระทำการ Mapping นั่นโน่นนี่ให้เอง และสร้าง Request ตามที่เรากำหนดใน JSON นั้นไปทำงานกับ Function เราอีกที ซึ่งรูปแบบของ JSON มันจะยาวมากๆ ครับ ดังนั้น การส่ง Input ยาวๆ เราสามารถทำได้สามแบบ

ในตัวอย่างแรก สามารถใส่ event ต่อท้ายได้ตามรูปแบบมาตรฐานของมันเลยครับ

docker run --rm -v "$PWD":/var/task --network mysql -e TEST_LAMBDA_DBCONNECTION="server=mysql;userid=root;password=1234;database=test_lambda;convert zero datetime=True; CharSet=utf8" -e AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 lambci/lambda:dotnetcore2.1 get_profile::get_profile.Function::Get '{"resource":"/{proxy+}","path":"/","httpMethod":"GET","headers":null,"queryStringParameters":null,"pathParameters":{"id":"1"},"stageVariables":null,"requestContext":{"accountId":"AAAAAAAAAAAA","resourceId":"5agfss","stage":"test-invoke-stage","requestId":"test-invoke-request","identity":{"cognitoIdentityPoolId":null,"accountId":"AAAAAAAAAAAA","cognitoIdentityId":null,"caller":"BBBBBBBBBBBB","apiKey":"test-invoke-api-key","sourceIp":"test-invoke-source-ip","cognitoAuthenticationType":null,"cognitoAuthenticationProvider":null,"userArn":"arn:aws:iam::AAAAAAAAAAAA:root","userAgent":"Apache-HttpClient/4.5.x (Java/1.8.0_102)","user":"AAAAAAAAAAAA"},"resourcePath":"/{proxy+}","httpMethod":"GET","apiId":"t2yh6sjnmk"},"body":null}'

ตัวอย่างสอง สามารถใส่ event ด้านหน้า ในรูปแบบ stdin ได้

โดยใช้การ echo ค่า JSON ที่เราต้องการส่งออกไป จากนั้นให้ ใส่ | คั่นคำสั่งรัน Container เพื่อรับไปใช้ พร้อมกับระบุ parameter เพิ่มเติมอีกหน่อยคือ

-i -e DOCKER_LAMBDA_USE_STDIN=1

ตัวอย่าง

echo '{"resource":"/{proxy+}","path":"/","httpMethod":"GET","headers":null,"queryStringParameters":null,"pathParameters":{"id":"1"},"stageVariables":null,"requestContext":{"accountId":"AAAAAAAAAAAA","resourceId":"5agfss","stage":"test-invoke-stage","requestId":"test-invoke-request","identity":{"cognitoIdentityPoolId":null,"accountId":"AAAAAAAAAAAA","cognitoIdentityId":null,"caller":"BBBBBBBBBBBB","apiKey":"test-invoke-api-key","sourceIp":"test-invoke-source-ip","cognitoAuthenticationType":null,"cognitoAuthenticationProvider":null,"userArn":"arn:aws:iam::AAAAAAAAAAAA:root","userAgent":"Apache-HttpClient/4.5.x (Java/1.8.0_102)","user":"AAAAAAAAAAAA"},"resourcePath":"/{proxy+}","httpMethod":"GET","apiId":"t2yh6sjnmk"},"body":null}' | docker run --rm -v "$PWD":/var/task -i -e DOCKER_LAMBDA_USE_STDIN=1 --network mysql -e TEST_LAMBDA_DBCONNECTION="server=mysql;userid=root;password=1234;database=test_lambda;convert zero datetime=True; CharSet=utf8" -e AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 lambci/lambda:dotnetcore2.1 get_profile::get_profile.Function::Get

ตัวอย่างสาม สามารถใส่ event ด้านหน้า ในรูปแบบ stdin ได้ โดยเรียกใช้ข้อมูลจากไฟล์

แบบนี้เหมือนกับด้านบน เพียงแต่ผมแปลงนิดหน่อย ให้พ่นข้อมูลจากไฟล์แทน โดยใช้คำสั่ง cat เช่น

cat /Users/chitpong/Sourcecode/aws-serverless/profile/test/get_profile.Tests/SampleRequests/TestGetMethod.json | docker run --rm -v "$PWD":/var/task -i -e DOCKER_LAMBDA_USE_STDIN=1 --network mysql -e TEST_LAMBDA_DBCONNECTION="server=mysql;userid=root;password=1234;database=test_lambda;convert zero datetime=True; CharSet=utf8" -e AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 lambci/lambda:dotnetcore2.1 get_profile::get_profile.Function::Get

ในที่นี้ผมใช้ JSON ไฟล์เดียวกันกับที่ผมเขียนทดสอบใน Unit Test

สรุป

เป็นรุปแบบการทดสอบ AWS Lambda แบบที่ไม่เสียเงินอีกรูปแบบหนึ่ง และค่อนข้างทำงานได้เหมือนจริงตามที่เราต้องการ ซึ่งถ้าใช้งานบ่อยๆ การทำคำสั่งแบบนี้อาจจะยาวและเสียเวลาหน่อย ก็ให้ไปเขียนเป็น shell script หรือ makefile เพื่อรันก็จะไวขึ้นอีกนิด

ทั้งนี้ทั้งนั้น ผมก็ยังยืนยันแบบเดิมว่า ทดสอบด้วยการเขียน Unit Test เถอะครับ

Reference

• https://github.com/lambci/docker-lambda
• https://github.com/lambci/docker-lambda/issues/23

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

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

1. ปรับ Version ที่ Integration Request ใน API Gateway

วิธีนี้เหมาะสำหรับ

• ผู้ใช้ API Gateway เป็น Event Trigger เรียกใช้งาน Lambda Function
• มี Lambda Function จำนวนน้อย
• ทำไว้ใช้บน Test Environment เท่านั้น
• ไม่ได้ต้องการทำ Version ให้กับ Lambda Function ทุกตัว
• ถ้าใช้ AWS API Gateway วิธีการนี้ จะสามารถใช้งานสิ่งที่เราปรับเปลี่ยนได้ก็ต่อเมื่อมีการกดปุ่ม Deploy API

ปัญหาที่พบในวิธีนี้

• ถ้าไม่ใช้ API Gateway จะทำแบบนี้ไม่ได้
• ถ้ามี Lambda Function จำนวนมากๆ ต้องไล่เปลี่ยนทีละตัว ก็จะเป็นงานหนักมาก

วิธีนี้เป็นวิธี basic ที่สุดสำหรับ ผู้ใช้ API Gateway เป็น Event Trigger เรียกใช้งาน Lambda Function ซึ่งตอนผมลองเล่นแรกๆก็ทำแบบนี้แหละ

ในตัวอย่าง บนหน้าของ AWS API Gateway เมื่อเราสร้าง Resource และ Method แล้ว จะมีส่วนของ Integration Request

ในหน้าของ Integration Request เราสามารถแก้ไขการเรียกใช้งาน Lambda Function โดยระบุ Version ได้จากที่นี่เลย

2. สร้าง Version URL ใน API Gateway

วิธีนี้เหมาะสำหรับ

• ผู้ใช้ API Gateway เป็น Event Trigger เรียกใช้งาน Lambda Function
• ต้องการให้ผู้ใช้ API เดิมยังใช้งานได้ตามปกติ และผู้ใช้ใหม่ก็สามารถใช้ API ใหม่ได้ (หรือจะกำหนด Permission ของกลุ่มผู้ใช้เพิ่มด้วยก็ได้)
• มี Lambda Function จำนวนไม่มากนัก
• สามารถ Custom Lambda ในแต่ละ URL Version ได้ โดยไม่กระทบกับ URL Version อื่น
• ถ้าใช้ AWS API Gateway วิธีการนี้ จะสามารถใช้งานสิ่งที่เราปรับเปลี่ยนได้ก็ต่อเมื่อมีการกดปุ่ม Deploy API

ปัญหาที่พบในวิธีนี้

• ถ้าไม่ใช้ API Gateway หรือ Middleware ที่สามารถจัดการ Router ได้ จะทำแบบนี้ไม่ได้
• จะงานหนักทันที ถ้ามี Lambda Function จำนวนมากๆ และต้องสร้าง URL Gateway ใหม่อีกชุดหนึ่ง และกำหนด Version ใหม่ (แต่ใช้ Tools จำพวก Infrastructure as code ช่วยปั๊มได้)

วิธีนี้เพิ่มมิติของการทำ Versioning โดยการกำหนด URL Version ไปด้วย ทำให้แยกกลุ่มของผู้ใช้งานได้ โดยไม่กระทบกัน

มีหลายแบรนด์ดังที่ใช้วิธีการแบบนี้ เช่น

ในตัวอย่าง บนหน้าของ AWS API Gateway คือให้เราสร้าง Resource เป็น Version ไว้เลย

จากนั้นในแต่ละ Method ใน Resource Version ต่างๆ ให้เรากำหนด Version ใน Integration Request เหมือนเดิมแบบวิธีแรก

3. สร้าง Version และกำหนด Alias ให้กับ Lambda Function

วิธีนี้เหมาะสำหรับ

• ทุกคนที่จะนำ Lambda Function ไปใช้งาน
• มี Lambda Function จำนวนน้อยจนถึงมากๆ
• ใช้ได้กับทุก Environment ไม่ว่าจะ Test หรือ Production
• มีการกำหนด Version ให้กับ Lambda Function อยู่เสมอ

ปัญหาที่พบในวิธีนี้

• ต้องระบุ Description ใน Version ให้ดี เพื่อที่จะได้รู้ว่า แต่ละตัว มีการปรับเปลี่ยนอะไร
• การเปลี่ยน Verion ใน Alias Name จะทำให้การทำงานไปใช้ Lambda Version นั้นทันที ไม่หมือนกับตอนทำกับ API Gateway ที่ทดสอบก่อนได้ แล้วค่อยกดปุ่ม Deploy API (แต่ทั้งนีก็สามารถ Rollback ได้ทันที)

เป็นวิธีที่ซับซ้อนขึ้นอีกนิดจากข้างต้น แต่มีประสิทธิภาพ และทาง Amazon เองก็แนะนำให้ทำแบบนี้ (AWS Lambda Function Versioning and Aliases)

โปรแกรมเมอร์เองจะต้องมีการกำหนดเวอร์ชั่นภายในทีมให้ชัดเจนว่า เมื่อไรถึงจะต้อง publish version ออกมา และนำไปลิงค์เข้าใน Alias Name เพราะการกำหนดแบบนี้จะทำให้การทำงานของ lambda เปลี่ยนทันที ไม่มีการผ่าน Deploy API

วิธีการทำ คือ เมื่อเรามี Version ของ Lambda อยู่แล้ว ให้ทำการสร้าง Alias Name และทำการเชื่อมกันว่า ชื่อ Alias ไหน ชี้ไป Version ไหน

ถ้าต้องการเปลี่ยน Version ก็สามารถคลิกที่ชื่อ Alias แล้วเลื่อนลงมาแก้ไข Config ได้ภายหลัง, รูปนี้ตัวอย่างของ Alias ชื่อ Prod ชี้ไปหาฟังก์ชั่น simple-hello Version 1

รูปนี้ตัวอย่างของ Alias ชื่อ Dev ชี้ไปหาฟังก์ชั่น simple-hello Version $LATEST

ในตัวอย่าง บนหน้าของ AWS API Gateway คือให้เราสร้าง Resource และกำหนดให้ Integration Request ของ Method ชี้ไปหา Alias ชื่อว่า Prod (แต่เดิมเราชี้ไปหาเลข Version, ตอนนี้ชี้ไปหาชื่อ Alias แทน) จากนั้นผม Deploy API ไปหา prod stage รอบหนึ่งก่อน เพื่อให้จำค่านั้น แล้วผมก็กลับมาเปลี่ยน Method ให้ชี้ไปหา Alias ชื่อว่า Dev และทำการ Deploy API ไปหา dev stage อีกครั้ง

ผลที่ได้จากการทำวิธีนี้

4. สร้าง Version และกำหนด Alias ให้กับ Lambda Function พร้อมกับทำ URL Verioning

วิธีนี้คือการผสมข้อ 3 และ 4 เข้าด้วยกัน กล่าวคือ ใช้ Alias Name ด้วย เพื่อให้แก้ไข Version ที่ตัว Lambda Function ได้เองเลย พร้อมกับทำ URL กำหนด Version ไว้ เพื่อป้องกันผลกระทบ กรณี เปลี่ยน Version ใน Lambda Function ผิด

สรุป

วิธีการระบุ API Version มีหลายวิธีการให้เลือกใช้ พยายามหา Best Practice ก็อาจจะเจอหลายๆแบบ แล้วแต่ว่าคนเขียนเคยทำแบบไหนแล้วเหมาะกับงานของเขา

แถม

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

ส่วนข้อดีข้อเสีย มีเทียบไว้ให้เข้าใจง่ายๆ

อ้างอิง

• https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html
• https://docs.aws.amazon.com/lambda/latest/dg/aliases-intro.html
• https://mathieu.fenniak.net/aint-nobody-got-time-for-that-api-versioning/
• https://www.icapps.com/blog/api-versioning-overview

ตัว AWS Lambda เอง เลยออกเครื่องมือตัวหนึ่งสำหรับชาว .Net ชื่อว่า AWS .NET Mock Lambda Test Tool เป็นเครื่องมือที่ช่วยให้นักพัฒนาสามารถทดสอบ Business Logic ของโค้ดตัวเองได้ง่ายๆ ไม่โดนคิดเงิน และคล้ายกับที่ทำงานบน AWS ด้วย

วิธีติดตั้ง

ติดตั้งเครื่องมือด้วยคำสั่งนี้

dotnet tool install -g Amazon.Lambda.TestTool-2.1

เสร็จเรียบร้อยครับ!

วิธีการใช้งาน

ให้เข้าไปที่โฟลเดอร์ของโค้ดเรา และอยู่ใน level เดียวกับที่มีไฟล์ .csproj จากนั้นรันคำสั่ง

dotnet publish

เพื่อให้ build ไฟล์ DLL binary ก่อน จากนั้นรันคำสั่ง

dotnet lambda-test-tool-2.1

เมื่อรันคำสั่งแล้วจะมีหน้าตาประมาณนี้

มันจะทำการ Mock Server ให้เรา จากนั้นมันจะเปิด Brower ขึ้นมา ให้เรากรอกข้อมูล Input เพื่อทำการทดสอบ

สรุป

ใช้ง่ายไหมครับ ผมลองตัด Internet แล้วทดสอบ ก็ยังใช้ได้อยู่ แปลว่ามันไม่ได้วิ่งไปหา Amazon เพื่อทำให้เราเสียเงินในการทดสอบ, รวมถึงให้เรา Develop ได้ทุกที่แม้ไม่มีเน็ตด้วย

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

• YAML based CloudFormation templates are not yet supported.
• No mechanism for setting custom Environment variables.
• NuGet packages that use native dependencies are not supported.

ถ้าถามผม อย่างไรเสีย การมี Unit Test ก็ดีกว่านะครับ 😀

Reference

• https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

เพราะเมื่อระบบเราใหญ่ขึ้น สมมติว่ามี 100 Functions และต้องเรียกใช้ Library คล้ายกัน ปัญหาคือ

1. เราจะควบคุม Version ของ Library ให้เหมือนกันทุก Function ได้ไหม
2. Filesize ของ Deployment Package เราจะใหญ่ เพราะ ทุก Function ต้องแพ็ค Library ที่เกี่ยวข้องติดไปด้วยทุกตัว
3. เมื่อ Deployment Package เราใหญ่ จะทำให้ช่วงเวลา Cold Start ของ Lambda เรา ช้าขึ้นไปอีก

Amazon เลยมีฟีเจอร์หนึ่งให้ใช้คือ Lambda Layers เพื่อใช้เก็บ Libraries, Custom Runtime หรือพวก Dependencies ต่างๆ แยกออกจาก Function ของเรา เพื่อให้ Function เราเล็กลง และสามารถเรียกใช้ Layers ต่างๆที่ Function อื่นได้ด้วย

คำแนะนำ: บทความนี้จะอ่านเข้าใจ ถ้าคุณใช้ AWS Lambda เบื้องต้นเป็นแล้ว

ปัญหา Lambda Layers กับ C# .Net Core

ในขณะที่ผมกำลังเขียนบล็อกนี้ (7 Feb 2019) ตัว AWS Lambda เอง รองรับการทำ Layers แค่ Node.js, Python, และ Ruby functions เท่านั้น

ส่วนภาษาอื่นๆ อาจจะลำบากหน่อย เพราะ Dependency อยู่ในโฟลเดอร์ข้างนอก project เช่น C# ของ MacOS จะอยู่ใน /usr/local/share/dotnet/ ซึ่งเราจะต้องสร้าง Runtime package store ของ project นั้น แล้วไปคัดเลือก Dependency เอง จากนั้น zip file ออกมานำไปใช้ใน Lambda Layer ส่วนโค้ดของเรา เมื่อทำคำสั่ง publish แล้ว เราต้อง zip เฉพาะโค้ดเราเท่านั้น และนำไปขึ้น AWS เอง และทำการลิงค์กัน… ฟังดูยุ่งยากเนอะ

แต่อย่าเพิ่งตกใจไป ที่เขียนบล็อกนี้เพราะ Amazon กำลังปรับปรุงเครื่องมือ AWS CLI ของตัวเอง เพื่อให้ชาว C# .Net Core ทำทำ Layers ได้ง่ายๆแล้ว ซึ่งขณะนี้อยู่ในช่วงของ Beta Version เพิ่งปล่อย Docs มาให้ได้อ่านกันเพียง 20 วันนี้เอง

Amazon Lambda Tools V.3.2.0-beta1 ที่มาพร้อมกับ คำสั่ง “dotnet lambda publish-layers”

ถ้าอ่านถึงตรงนี้ ชาว C# น่าจะอยากใช้งาน Layer กันบ้างแล้ว แต่เราจะไม่สามารถใช้กับ AWS Lambda Tools เวอร์ชั่นปัจจุบันได้ (ตอนนี้คือ V.3.1.2) ดังนั้นต้องเอาตัว Beta มาใช้ ด้วยวิธีการ Build Package มันขึ้นมาเองเอง

สำหรับคนที่ไม่เคยใช้ AWS CLI จำเป็นต้องทำสองขั้นตอนนี้ก่อน คือ

1. ติดตั้ง AWS CLI
2. สร้าง Configuration เพื่อให้ AWS User เรา ใช้ได้กับ AWS CLI

แต่ถ้าเรามี AWS CLI พร้อมใช้อยู่แล้ว ให้เริ่มติดตั้ง Amazon Lambda Tools กันเลยได้ให้ทำการ clone repo https://github.com/aws/aws-extensions-for-dotnet-cli.git

1.ให้ทำการ clone repo https://github.com/aws/aws-extensions-for-dotnet-cli.git

git clone https://github.com/aws/aws-extensions-for-dotnet-cli.git

2. จากนั้นทำการ checkout branchไปที่ “lambda-layers”

git checkout lambda-layers

3.สร้าง NuGet Package ใหม่ของ amazon.lambda.tools

dotnet msbuild buildtools/build.proj /t:build-nuget-packages

4.ทำการ uninstall amazon.lambda.tools ตัวเก่าออก (หากใครยังไม่เคยใช้มาก่อน ก็ไม่ต้องทำบรรทัดนี้)

dotnet tool uninstall -g amazon.lambda.tools

5.ติดตั้ง package amazon.lambda.tools ใหม่

dotnet tool install -g --add-source ./Deployment/nuget-packages/ Amazon.Lambda.Tools --version 3.2.0-beta1

เมื่อติดตั้งเสร็จ ให้ลองพิมพ์ “dotnet lambda“ ดูครับ จะต้องได้เวอร์ชั่น 3.2.0-beta1 และมีคำสั่ง publish-layer เพิ่มเข้ามา (นอกจากมี publish-layer แล้ว ยังทำให้คำสั่ง deploy-function และ package รองรับการใช้งาน layers ด้วย)

มาลองสร้าง Lambda Layers ของภาษา C# .Net Core กัน

ก่อนอื่นเลย เราต้องมี S3 Bucket ก่อน เพราะว่าเมื่อทำคำสั่งนี้ มันจะเก็บ Package ต่างๆ ไว้ที่ S3 ซึ่งในที่นี้ผมตั้งชื่อว่า lambda-profile-dependency

จากนั้นเข้าไปที่โฟลเดอร์ C# Project ของเรา และเราจะใช้คำสั่ง dotnet lambda publish-layer ซึ่งมีรูปแบบการใช้งานดังนี้

dotnet lambda publish-layer layer-name --layer-type runtime-package-store --s3-bucket bucket-name

โดย

• layer-name คือ ชื่อของ Layer ที่เราต้องการ
• bucket-name คือ ชื่อของ S3 Bucket ที่เราจะใช้เก็บไฟล์
• runtime-package-store คือ type ของ layer ซึ่งคำสั่งนี้ถูกทำเผื่อไว้ในอนาคต ว่าจะมีประเภทของ package ให้เลือกได้ ตอนนี้มีให้ใช้อย่างเดียวคือ runtime package

ในที่นี้ ถ้าผมต้องการเก็บลง S3 Bucket ชื่อ lambda-profile-dependency และตั้งชื่อ Layer ว่า profile-lib จะได้คำสั่งประมาณนี้

dotnet lambda publish-layer profile-lib --layer-type runtime-package-store --s3-bucket lambda-profile-dependency

เมื่อรันคำสั่ง มันก็จะทำการแพ็คไฟล์นั่นนู่นนี่ไปเรื่อยๆ จนสุดท้าย ออกมาจะต้องได้ ARN ของ AWS Lambda Layer ที่เราจะใช้งาน ตามภาพด้านล่าง (บรรทัดสุดท้าย)

ให้เราคัดลอก ARN ไปใช้ในคำสั่ง deploy lambda ด้วยรูปแบบดังนี้

dotnet lambda deploy-function function-name --function-layers layer-arn

โดย

• function-name คือ ชื่อ Lambda Function ของเรา
• layer-arn คือ ARN ของ Lambda Layer ที่เราจะลิงค์ถึง (รูปแบบจะประมาณนี้ arn:aws:lambda:[region-name]:[aws-user-id]:layer:[layer-name]:[layer-version])

ดังนั้น ถ้าผมต้องการ Function ชื่อ list_profile และ ใช้ layer ที่เพิ่งสร้างขึ้นเมื่อสักครู่ จะใช้คำสั่งดังนี้

dotnet lambda deploy-function list_profile –-function-role MyRole --function-layers arn:aws:lambda:ap-southeast-1:819684245502:layer:profile-lib:1

เมื่อรันคำสั่ง มันก็จะทำการแพ็คไฟล์ เพื่อเตรียม deploy โดยมันจะแยกเอาเฉพาะไฟล์ Function ของเราเท่านั้น ไม่เอาพวก dependency library เข้าไปด้วย (ขั้นตอนนี้ ทำมือเองได้ แต่ใช้คำสั่งเถอะ เร็วกว่า)

เป็นอันว่าเสร็จเรียบร้อย Lambda Function ของเรา กับ Lambda Layer ถูกนำขึ้นไปไว้บน AWS และผูกมิตรกันให้ด้วย

สำรวจผลลัพธ์ Lambda Function และ Lambda Layer หลัง Deployment

ลองมาดูกันว่าผลลัพธ์หลังจากการใช้งาน Lambda Layer เป็นอย่างไร

เพิ่มเติม: อย่าลืมว่า การคิดเงินของ AWS Lambda มันคิดที่หน่วย 100ms นะ
อย่าง cold start จากที่โดนคิดเงิน 16000ms จะเหลือแค่ 15500ms หายไป 500ms

คำเตือน: ถ้าเราเคยมี Environment Variable เดิมอยู่ มันจะหายไป!!!

สรุป

ถ้าชาว C# .Net Core อยากใช้ Lambda Layer ก็ลองทำตามในบล็อกนี้ได้เลย หรือไม่ก็รอ AWS CLI เวอร์ชั่น 3.2.0 ออกตัวเต็ม ก็ได้ครับ แต่เท่าที่ลองใช้ ไม่มีปัญหาอะไรนะ สะดวกดี

และข้อจำกัดตอนนี้ คือ Lambda Layer มีให้ใช้กันที่ 5 Layers ดังนั้น ต้องมาคิดต่อว่าจะจัดสรร Dependency กันอย่างไร เพื่อให้ใช้ประโยชน์ร่วมกันเยอะที่สุด

อ้างอิง

• https://github.com/aws/aws-extensions-for-dotnet-cli/blob/lambda-layers/docs/Layers.md
• https://github.com/aws/aws-extensions-for-dotnet-cli/tree/lambda-layers
• https://github.com/aws/aws-extensions-for-dotnet-cli/issues/58

วิธีติดตั้ง

การใช้งานมี 2 แบบครับ คือใช้คำสั่ง coverlet ทำงานเลย ให้ติดตั้งด้วยคำสั่ง

dotnet tool install --global coverlet.console

หรือทำงานผ่านคำสั่ง dotnet test ให้เพิ่ม nuget package ด้วยคำสั่ง

dotnet add package coverlet.msbuild

วิธีใช้งาน

ในตัวอย่างนี้ โครงสร้างโปรเจ็คผมจะหน้าตาตามรูปภาพด้านล่าง และผมเข้าจะยกตัวอย่างคำสั่งทั้งหมดกรณีที่อยู่ในโฟลเดอร์ /tests/web.UnitTest/

ดังนั้น เมื่อต้องการดู Code Coverage ผ่านคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.xml" --format opencover

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

• bin/Debug/netcoreapp2.1/api.dll : คือ ที่อยู่ของไฟล์ Unit Test Binary ที่เรา Build มาแล้ว
• test web.UnitTest.csproj –no-build : คือ arguments เพื่อบอกว่าเราต้องการทดสอบด้วย MSTest ไปที่ File Project ไหน, และผมเพิ่มไปว่า ไม่ต้อง ทำการ build project ใหม่ เพราะผมสั่ง build ไปแล้ว (ถ้าใครไม่สั่ง build ก่อน ให้เอา –no-build ออกด้วยนะ)
• ../web.UnitTest.Results/Coverage.xml : คือ ที่อยู่ของไฟล์ report ซึ่งผมให้ใช้เป็น Formet ของ OpenCover จึงจ้องมีนามสกุล .xml (ค่ามาตรฐาน ถ้าไม่ระบุ มันจะเป็น JSON)
• opencover : คือ Format ของไฟล์ report ที่เราจะนำไปใช้งานต่อ

ลองมาดูการใช้งานผ่านคำสั่ง dotnet test แบบปกติบ้าง

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover

ถ้าให้เดาค่าต่างๆ คงพอเดากันได้นะครับ ระบุเหมือนด้านบนเลย แต่คำสั่งหนึ่งที่ต้องมีเสมอคือ

/p:CollectCoverage=true 

เพื่อบ่งบอกว่า เราต้องการ Generate Code Coverage ออกมาด้วย

การแสดงผล

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

ความหมายที่ได้จากการแสดงผล คือ

• Module : ชื่อ System ที่มันทำการทดสอบ
• Method coverage : จำนวนของ Function/Method ที่ถูกเรียกใช้งาน
• Branch coverage : จำนวนของ Branch หรือเงื่อนไขใน if statement ถูกเรียกใช้งานทั้ง true และ false
• Line coverage : จำนวนของบรรทัดที่ถูกเรียกใช้งาน

อ้างอิงคำอธิบายจาก http://www.somkiat.cc/introduction-to-code-coverage/

กำหนดคุณภาพ ด้วยการตั้ง Threshold

คราวนี้ ถ้าเราอยากตั้งค่าว่า ถ้า Code Coverage เรามี Test ครอบคลุมต่ำกว่า xx% เราจะไม่ให้ผ่านการทดสอบ โดยเพิ่ม Argument ชื่อ threshold ลงไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

coverlet bin/Debug/netcoreapp2.1/api.dll --target "dotnet" --targetargs "test web.UnitTest.csproj --no-build" --output "../web.UnitTest.Results/Coverage.json" --threshold 80

ตัวอย่างด้วยคำสั่ง dotnet test

dotnet test --no-restore --no-build --logger:"trx;LogFileName=Results.trx" --results-directory:"../web.UnitTest.Results" /p:CollectCoverage=true /p:CoverletOutput="../web.UnitTest.Results/Coverage.xml" /p:CoverletOutputFormat=opencover /p:Threshold=80 /

ซึ่งในตัวอย่างผมกำหนดว่า Coverage ทุกประเภทจะต้องเกิน 80% ถึงจะเรียกว่าผ่าน ถ้าต่ำกว่านั้นจะ Fail ทันที ดังรูปด้านล่าง

และเราสามารถกำหนดเฉพาะ Coverage ได้ด้วย เช่นผมต้องการเช็คเฉพาะ Line Coverage ก็สามารถเพิ่ม Argument เข้าไป ดังนี้

ตัวอย่างด้วยคำสั่ง coverlet

--threshold-type line

ตัวอย่างด้วยคำสั่ง dotnet test

 /p:ThresholdType=line

ผลที่ได้คือ

สรุป

ถ้าเทียบกับ minicover แล้ว ตัวนี้ค่อนข้างใช้งานง่าย ไม่ซับซ้อนมากนัก รองรับ .Net Core 2.2.1 ตัวล่าสุดด้วย และสามารถแจกแจงรายละเอียด ตาม Coverage Type ต่างๆ พร้อมออก Report ได้ เช่น json, lcov, opencover (xml file), cobertura (xml file) และ teamcity ถ้าสนในรายละเอียดมากกว่านี้ ไปดูได้ที่ Github ของผู้พัฒนาได้เลยครับ ที่ https://github.com/tonerdo/coverlet

Featured image from: https://www.aapnainfotech.com/test-coverage-much-testing-enough/

ทบทวน “5 คุณสมบัติของ Unit Test ที่ดี” อีกครั้ง

ก่อนจะไปต่อ ขอทบทวนคุณสมบัติที่ดีของ Unit Test อีกรอบ ที่ควรจะต้องเป็นไปตามหลักการของ FIRST คือ

• Fast: ทำงานได้เร็ว
• Isolated: เป็นอิสระจากกัน
• Repeatable: ทำซ้ำได้ ไม่ขึ้นกับระบบอื่นๆ เช่น API ภายนอก, Database, File System
• Self-Verify: แสดงให้เห็นผลการทดสอบ ผ่าน หรือไม่ผ่านได้อย่างชัดเจน
• Timely: เขียนให้ถูกเวลา คือ ควรมี Test ก่อน เพื่อให้ได้เข้าใจปัญหา และจึงเขียนโค้ดเข้ามาแก้ปัญหานั้น

คราวนี้ การที่ Unit Test ของเราต้องไปทำงานร่วมกับสิ่งอื่นๆ มันมักทำให้ขัดแย้งกับ 5 ข้อ ข้างต้น เช่น

• เมื่อเราต้องการทดสอบ Function ที่ต้องต่อกับ Database มันก็จะทำงานไม่เร็ว เพราะ Query นาน, มันทำซ้ำไม่ได้ เพราะต้องเพิ่มลบข้อมูลจาก Database ตลอด แล้วไหนจะกระทบตัวอื่นๆที่อาจจะใช้ Database เดียวกันด้วย
• เมื่อเราต้องการทดสอบ Function ที่ต้องต่อกับ API ภายในของเราเอง หรือภายนอก มันก็ทำงานไม่เร็ว เพราะมีเรื่องของความเร็ว Network/Internet ซึ่งถ้า Internet ล่ม ก็ทำซ้ำไม่ได้ หรือถ้าส่งข้อมูลไปให้แล้วบาง API ก็ส่งข้อมูลซ้ำไม่ได้ เช่น ส่งข้อมูลไป API สมัครสมาชิกที่มีเงื่อนไขสมัครด้วยอีเมลเดียวเท่านั้น
• เมื่อเราต้องการทดสอบ Function ที่ต้องไปทำงานร่วมกับ Function อื่น แต่มันยังทำไม่เสร็จหรือไม่ได้ทำ เราก็ทดสอบไม่ได้อยู่ดี

ดังนั้น ถ้าต้องการให้ Unit Test ของเราทำงานได้ตามคุณสมบัติดังกล่าว เราจะต้องสร้างการทำงานสิ่งอื่นๆที่เกี่ยวข้องขึ้นมา ซึ่ง จะมีอยู่  5 ประเภท เรียกรวมๆ ว่า Test Doubles

Test Doubles คืออะไร

Image from: https://blogs.sap.com/

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

คำว่า Test Doubles มาจากหนังสือที่ลุง Gerard Meszaros เขาเขียนมันขึ้นมา โดยแปลงมาจากคำว่า Stunt Double ที่ใช้ในการทำหนัง ซึ่ง Stunt Double คือ สตั๊นแมนหรือนักแสดงที่มีหน้าตา รูปร่าง แต่งตัวคล้ายกับพระเอก แล้วออกไปแสดงแทนพระเอกในบางฉาก

คราวนี้พอมาเป็น Test Doubles โดยอธิบายมุมเดียวกับ Stunt Double มันก็คือ อะไรบางอย่างที่เราทำมันขึ้นมาเพื่อให้มันทำงานแทนของจริง ในขณะที่เราไม่ได้ต้องการทดสอบมัน อย่างเช่น API ของคนอื่น, Class/Function ของคนอื่น, Database  เป็นต้น

Test Doubles 5 ประเภท มีอะไรบ้าง

อย่างที่บอก ว่าเราเคยเรียกทุกสิ่งที่ถูกจำลองว่า Mock  แต่เมื่อพิจารณาดีๆ มันมีจุดแตกต่างกัน ซึ่งเราจะใช้การเรียกประเภทต่างๆ อ้างอิงตามที่ลุง Gerard Meszaros ได้เขียนอธิบายไว้ และทั่วโลกก็ใช้เรียกตามนี้เช่นกัน ดังนั้นเวลาใช้สื่อสารเราจะได้เข้าใจตรงกัน

ปล. ตัวอย่างที่จะใช้ต่อไปนี้ เขียนด้วย .Net Core 2

1. Dummy

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

ถามว่าโง่ได้ขนาดไหน ก็เช่น สร้าง Class เปล่าๆ หรือ Function ที่คืนค่า null หรือ throw exception ก็ยังได้ โดยไม่ต้องสนใจว่ามันทำงานอย่างไร เราสนแค่ว่า ตัวที่เราจะทดสอบสามารถเรียกมันแล้วผ่านไปได้โดยไม่ติดขัด

ตัวอย่าง Dummy

ผมมีโค้ดสำหรับการ Login โดย Constructor Member() จะเป็นส่ง Username/Password ไปตรวจสอบ ซึ่งถ้าถูกต้อง ก็จะทำงานต่างๆ ได้ เช่น แสดงข้อความ “Welcome to member area” ใน method Profile()

View the code on Gist.

ผมสร้าง Interface ขึ้นมาชื่อ IAuthorize และคลาสที่ถูกนำไปใช้งานคือ Authorize โดยภายในนั้นมี CheckAuthorize() ซึ่งจะทำการตรวจสอบว่า Login ถูกต้องหรือไม่

และผมสร้างคลาสอีกตัวชื่อ DummyAuthorize เพื่อที่จะใช้ทดสอบ โดยผมไม่ได้ return อะไรออกไปว่าเป็น true/false มีเพียงส่งค่าว่างเปล่าประเภท Boolean ออกไป

View the code on Gist.

มาดูในไฟล์ Unit Test ซึ่งผมต้องการตรวจสอบว่าสามารถสร้าง Object ของ Member ได้หรือไม่ แต่ติดว่า มันต้องใส่ Username/Password ใน Constructor ด้วยทุกครั้ง ดังนั้น ผมจึงใช้ DummyAuthorize แทน เพื่อให้มันทำงานทะลุผ่านไปได้

View the code on Gist.

นี่แหละครับ การทำงานของ Dummy ใส่อะไรไปแล้วใช้แทน Dependency ตัวอื่นๆ ได้ เพื่อทะลุไปทำงานอย่างอื่นต่อตามที่ต้องการ ซึ่งในตัวอย่างนี้ ผมลองเช็ค Type Object  Member ดู

2. Stub

Stub คือการกำหนดสถานะหรือสิ่งต่างๆให้เป็นไปตามที่เราต้องการ (State verification) โดยหน้าตาจะคล้ายกับ Dummy แต่ Stub เราจะต้องกำหนดค่าที่จะใช้ด้วย เพื่อให้ได้ผลลัพธ์ออกมาตามที่เราต้องการ

เช่น Test Case ของสมการ 1 + X จะต้องได้เท่ากับ 2 โดยที่ X คือ Function ภายนอกที่เราไปเรียกใช้ และผลลัพธ์จะต้องออกมาเป็น 2 เสมอ ดังนั้น เราจะต้องกำหนดค่า X ว่าต้องเป็น 1 เท่านั้น (ซึ่งต่างจาก Dummy ที่ไม่สนใจการระบุค่า)

และที่เราชอบเรียกกันว่า Mock ส่วนมากคือการทำ Stub นี่เอง เพราะเราเขียนโค้ดขึ้นมาเพื่อให้ได้ค่าอย่างใดอย่างหนึ่งนำไปใช้งานต่อ และแสดงผลลัพธ์ปลายทางที่เราต้องการ

ตัวอย่าง Stub

ผมอ้างอิงจากโค้ดชุดเก่าของ Dummy แต่เปลี่ยน Unit Test ใหม่ โดยผมต้องการตรวจสอบว่า เมื่อเรียกใช้ Profile() จะต้องแสดงข้อความ “Welcome to member area” ขึ้นมา

View the code on Gist.

และเช่นกัน ผมสร้าง Class ชื่อ StubAuthorize จาก IAuthorize และใน CheckAuthorize() จะระบุเป็น true เสมอ เพื่อให้ Unit Test ผมแสดงข้อความ “Welcome to member area” ขึ้นเสมอ

View the code on Gist.

อาจจะมีความสงสัยว่า ถ้าเราใส่ Username/Password เข้าไปตอนสร้าง object Member เลยได้ไหม อย่างไรก็คืนค่าเป็น  true เสมอ ตอบเลยว่าได้ แต่มีจุดให้คิดเพิ่ม คื อ

1. เราต้องการตรสวจสอบการเรียกใช้ Profile() ว่าแสดงผลถูกต้องหรือไม่ ในสถานะที่เราต้องการให้มันทำงานถูกต้อง ดังนั้นเราไม่ได้ต้องการตรวจสอบ CheckAuthorize() ว่าทำงานถูกต้องหรือไม่ อันนี้จะเขียนเป็นอีก Unit Test หนึ่ง (แต่ก็ไม่ผิดนะครับ เพราะเป็นรูปแบบ Unit Test – Sociable ซึ่งลองอ่านได้ที่ รูปแบบการทดสอบของ Unit Test)
2. แน่ใจหรือไม่ว่า Username/Password ที่ใส่ค้างไว้ จะไม่เปลี่ยนในภายหลัง

3. Mock

ชื่อนี้สร้างความสับสนกันทั้งโลก ซึ่ง Mock ใน Test Doubles จะหมายถึง การทดสอบพฤติกรรมการทำงานของสิ่งๆหนึ่ง (Behavior Verification) อย่าง Class/Function เป็นต้น ว่าทำงานตามที่เราต้องการหรือไม่

กล่าวคือ Mock ไม่ได้สนใจผลลัพธ์ปลายทาง แต่สนใจการทำงานของสิ่งที่ต้องการทดสอบ เช่น ส่งค่าเข้าไปใน process แล้วค่านั้นมีการเปลี่ยนแปลงไปตามที่เราคาดหวังหรือไม่

ตัวอย่าง Mock

ระบบ Login ที่ผมสร้างไว้ จะระบุ Username/Password ผ่าน Constructure ชื่อ Member() จากนั้นจะทำการส่งต่อไปให้ CheckAuthorize() เพื่อตรวจสอบว่าถูกต้องหรือไม่ โดยถ้า ถูกต้อง มันจะแสดงผลออกมาที่ Profile() ว่า “Welcome to member area”

ดังนั้น Unit Test ผมจะมีหน้าตาประมาณนี้ ซึ่งผมจะ Assert ไปสองค่าว่า มีการใช้งาน CheckAuthorize() และผลลัพธ์ที่ได้คือ “Welcome to member area”

View the code on Gist.

จากนั้นผมสร้าง Class ชื่อ MockAuthorize จาก IAuthorize โดยผมสร้างตัวแปร checkAuthorizeWasCalled ขึ้นมา เพื่อใช้ตรวจสอบการทำงาน

View the code on Gist.

ซึ่งถ้าพฤติกรรมการทำงานของโค้ดผมถูกต้อง จะต้องมีขั้นตอนคือ

1. ส่ง Username/Password ผ่าน Constructure ชื่อ Member()
2. จากนั้นส่งต่อไปให้ CheckAuthorize()
3. เปลี่ยนค่าตัวแปร checkAuthorizeWasCalled จากค่า  false เป็น true
4. โยนกลับมาที่ Profile() ให้แสดงผลลัพธ์

เป็นอันว่าพฤติกรรมของ Login ของผมมีการเรียกใช้ CheckAuthorize() เพื่อตรวจสอบ Username/Password ถูกต้องนะ

ตัวอย่าง Mock โดยการใช้ Moq4

คราวนี้เมื่อเราเข้าใจวิธีการปกติแล้ว ลองดูตัวอย่างโค้ดของการใช้ Library ชื่อ Moq4  ซึ่งจะทำให้ง่ายขึ้น เพราะสร้างตัว Mock CheckAuthorize() ไว้ใน Unit Test ได้เลย จากนั้นผม Create Object ขึ้นมา และทำการ Verify ว่ามีการเรียกใช้ CheckAuthorize() เกิดขึ้นหรือไม่

View the code on Gist.

4. Spy

ชื่อนี้แปลตรงตัวคือ สายลับ โดยเราจะส่งสายลับไปดูว่า ระบบของเรามีการเรียกใช้ Function ที่เราต้องการทดสอบจริงๆไหม ซึ่งคล้ายกับ Mock แต่แค่ไม่ได้สนใจพฤติกรรมว่าทำอะไรไปบ้าง ต้องได้ค่าอะไร (Exclusive Behavior Verification)

เช่น เรามีระบบรายชื่อที่จะต้องส่งอีเมลออกไป 100 รายการ ระบบของเราจะต้องมีการเรียก Function การส่งอีเมลเป็นจำนวน 100 รอบ ตามที่ต้องการจริงๆ

ตัวอย่าง Spy

ผมทำการสร้าง object Member ขึ้นมาสองครั้ง โดยมันจะต้องไปเรียกใช้งาน CheckAuthorize() จำนวนสองครั้งเช่นกัน ดังนั้นผมจึงทดสอบว่ามีการเรียกใช้งานจำนวนสองครั้งจริงหรือไม่

View the code on Gist.

จากนั้นผมสร้าง Class ชื่อ SpyAuthorize จาก IAuthorize โดยผมสร้างตัวแปร checkAuthorizeWasCalled ขึ้นมา เพื่อใช้นับจำนวนการเรียกใช้งาน

View the code on Gist.

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

5. Fake

ชื่อก็บอกอยู่ว่าคือการโกหกหลอกลวงนะฮะ ฮ่าๆ มันคือการจำลองอะไรบางอย่างให้เสมือนจริง เหมือนมากจนเป็นข้อเสียหนึ่งที่เราอาจจะสับสนเอง โดยเหมาะกับใช้ในกรณีที่ไม่สามารถทำบน Production หรือระบบที่เราไม่ต้องการให้เกิดผลกระทบ

โดยกรณีนี้ถูกยกตัวอย่างขึ้นมาชัดเจน ก็คือ การใช้ In-Memory เก็บข้อมูลสำหรับทดสอบ แทนการใช้ Database จริงๆ  เป็นต้น

เช่น ระบบมีการสร้าง Order ไว้ใน Database แต่ไม่อยากสร้างจริงใน Database เพราะจะทำให้เลข Order ID ถูกเพิ่มจำนวนเข้าไป และก็ห้ามลบออกด้วย เพราะ Order ID จะขาดช่วง, ดังนั้นเราจะต้องสร้าง Database จำลองขึ้นมา ซึ่งถ้าให้ทุกเครื่องต้องทดสอบได้ และมีความเร็วมากๆ เราก็ต้องใช้ In-Memory นั่นเอง

ตัวอย่าง Fake

ผมต้องการทดสอบว่า Function ชื่อ Get_Member_Information_By_ID() สามารถส่ง Member ID เข้าไป และคืนค่าจาก Database เป็นไปตามที่ผมกำหนดหรือไม่ ดังนั้น แทนที่ผมจะเรียกใช้ Database จริง ผมจึงสร้าง In-Memory Database ขึ้นมาก้อนหนึ่งชื่อ get_by_id_members และทำการใส่ข้อมูลเข้าไปก่อน จากนั้นส่ง Member ID 1 เข้าไปให้ Get_Member_Information_By_ID และทำการตรวจสอบว่า ได้ชื่อ เบอร์โทร วันเดือนปีเกิด ตามใน Database จริงๆหรือไม่

View the code on Gist.

สรุป

Test Doubles มี 5 ประเภท ที่จะนำไปเลือกใช้ได้ตามสมควร

1. Dummy: ใช้อะไรก็ได้เพื่อ By Pass การทำงาน แทนการใช้ Dependency จริง
2. Stub: กำหนดค่าบางอย่าง เพื่อให้ได้ผลลัพธ์เป็นค่าที่เราต้องการเสมอ
3. Mock: เพื่อ verify ว่า process ที่เรียกใช้ มีการส่งค่าไปหา Dependency ตรงตามที่เราคาดหวังหรือเปล่า
4. Fake: จำลองบางอย่างขึ้นมาเพื่อใช้แทนของจริง
5. Spy: เพื่อ verify ให้แน่ชัดในการใช้ process เช่น โดนเรียกใช้ไปกี่ครั้ง หรือพารามิเตอร์อะไรถูกส่งไปบ้าง

หากต้องการเขียน Unit Test เราเลี่ยงไม่ได้ที่จะต้องเรียนรู้เรื่อง Test Doubles เพื่อตัดการเกี่ยวข้องกับสิ่งต่างๆ ทรี่ไม่จำเป็นออก (Dependency) เพราะว่า เราต้องการเจาะจงทดสอบเพียงอย่างเดียวเท่านั้น อย่างอื่นที่ไม่ทดสอบ เราก็จำลองขึ้นมาโดยใช้ Dummy, Stub, Fake ตามแต่จะเลือกใช้ และเราก็ใช้ Mock, Spy เพื่อทดสอบว่าโค้ดที่เขียน มันได้ทำงานถูกต้องจริงๆใช่ไหม ซึ่งวิธีการนี้ นำไปใช้ได้กับทุกภาษาโปรแกรม

และถ้าสังเกตให้ดี จะใช้ Test Double ได้ จำเป็นต้องรู้เรื่อง Unit Test,  Dependency-Injection และการเขียนโปรแกรมแบบ  Object-Oriented ด้วยนะฮะ ไม่เช่นนั้น เข้าใจยากเลยทีเดียว

อ้างอิง

• Test Doubles: mocks, dummies and stubs  << ตัวอย่างน่าสนใจ เข้าใจง่ายดี
• Test Doubles — Fakes, Mocks and Stubs. << แนะนำให้อ่านครับ สรุปเข้าใจง่าย ตัวอย่างดี อ่านง่าย
• The Little Mocker << แนะนำให้อ่านครับ  อ่านง่าย ตัวอย่างเข้าใจง่ายมาก บทความนี้เขียนจากพื้นฐานเว็บนี้
• Mocks Aren’t Stubs << แนะนำให้อ่านครับ อธิบายละเอียดเลย
• Understanding Test Doubles (Mock vs Stub) << แนะนำให้อ่านครับ สรุปสั้นๆ ตัวอย่างดี อ่านง่าย
• มาดูกันว่า Mock, Stub และ Dummy แตกต่างกันอย่างไร ? << ผมอ้างอิงการแปลภาษาไทยจากเว็บพี่ปุ๋ย
• และสุดท้าย กราบขอบพระคุณพี่บอย Elder แห่งสยามชำนาญกิจ ที่ช่วยอ่านรีวิวและแนะนำมา ณ ที่นี้ครัช