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/

ใน 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

แต่ก็กระนั้นอีก ในหน้าเว็บโปรเจ็คบอกทำงานกับ .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

ตัว 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

วิธีติดตั้ง

การใช้งานมี 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/

แต่กระนั้น โปรแกรมเมอร์อย่างเรามักไม่ชอบทำ API Document หรอกครับ เขียนๆไปแค่ให้มี สิ่งที่ได้มักเป็นเอกสารที่ใช้งานได้บ้างไม่ได้บ้าง เพราะเป็นภาษาที่คนเขียนเข้าใจแค่ตัวเอง หรือตัวอย่างไม่ชัดเจน หรือมีข้อมูลใช้งานไม่ครบถ้วน หนักไปกว่านั้นคือ บ่นว่าไม่มีเวลา แล้วก็ไม่ทำมันซะเลย (แต่มีเวลาไปอธิบายให้ผู้ใช้ทีละคนๆ 555)

ดังนั้น จะดีกว่าไหม ถ้าเราเขียนโค้ด API เสร็จ แล้วมีเครื่องมือสร้าง API Document ให้เราได้เลยอัตโนมัติ, อ่ะ ตอบแทนละกัน “ดีว่ะ!”

เครื่องมือหนึ่งที่ผมจะแนะนำในบล็อกนี้ ชื่อว่า Swagger ซึ่งมันสามารถสร้างเอกสารการใช้งาน API (API Document) และเครื่องมือทดสอบให้เราได้ในทันที (Testing Tools) โดยมันจะแปลงจากคำสั่งในโค้ดของเราออกมาให้นั่นเอง

ในบล็อกนี้ผมลองใช้ Swagger กับ .NET Core 2 นะครับ สำหรับภาษาอื่นๆ สามารถหาข้อมูลเพิ่มเติมได้ที่ Swagger Open Source Integrations

ว่าแล้ว เรามาเริ่มทำตามขั้นตอนกันเลย

ติดตั้ง NuGet packages

ให้เราเข้าไปที่โฟลเดอร์ของ API เราก่อน และพิมพ์คำสั่ง add package ดังนี้

[code lang=”shell”]dotnet add api.csproj package Swashbuckle.AspNetCore[/code]

ติดตั้ง Configure Swagger ใน Middleware

เพิ่มโค้ดเข้าไปใน ConfigureServices() ของไฟล์ Startup.cs ดังนี้

[code lang=”csharp”]
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new Info { Title = "My API", Version = "v1" });

var basePath = AppContext.BaseDirectory;
var xmlPath = Path.Combine(basePath, "MyApi.xml");
c.IncludeXmlComments(xmlPath);
});
[/code]

จากนั้นให้ใส่ using package ไว้ด้วย (โดยปกติ Editor จะเตือนให้เพิ่มด้วย) ดังนี้

[code lang=”csharp”]using Swashbuckle.AspNetCore.Swagger;[/code]

จะได้ดังภาพนี้

ซึ่ง Title คือชื่อของหน้าเอกสาร ในที่นี้ผมใช้ชื่อ “My API” ส่วนกลุ่มบรรทัดล่างเป็นการขอเปิดใช้งาน Customize ข้อความในรูปแบบของเราเอง ด้วยการระบุข้อมูลเป็น Comment ลงไปในโค้ด (และ Swagger จะทำการเก็บข้อความเหล่านั้นตามไฟล์ XML ที่เราระบุไว้)

จากนั้น เพิ่มโค้ดเข้าไปใน Configure() ของไฟล์ Startup.cs ดังนี้

[code lang=”csharp”]
app.UseSwagger();
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1");
});
[/code]

จะได้ดังภาพนี้

เป็นอันเสร็จ ให้ทำการ build และ run ใหม่อีกครั้ง เพื่อลองใช้งาน

ทดลองใช้งาน Swagger

ให้เราเปิด browser เข้าไปที่ (แก้ url/port ตามที่คุณตั้งไว้ด้วยนะ)

http://<localhost:port>/swagger/v1/swagger.json

จะเจอข้อความ JSON ที่เป็นชุดคำสั่งของ Swagger

แต่ถ้าต้องการดูสวยงามด้วย Swagger UI ให้เข้าไปที่

http://<localhost:port>/swagger/

จะได้หน้าตาสวยงามแบบนี้ครับ

มันจะแสดงรายการ API ของเราออกมาทั้งหมด ตาม Controller/Method/Route ที่เราได้เขียนไปในโค้ดเลยครับ
และเมื่อเรากดเข้าไปดูในรายละเอียดของแต่ละ API มันก็จะแสดงวิธีการ Access, Data Type, Respond Status, Respond Data, Respond Type ครบถ้วน ดังรูป

หรืออีกตัวอย่างหนึ่ง ผมลองดึงข้อมูลสมาชิกหมายเลข 2 ออกมา ซึ่งในโค้ดผมบอกว่าต้องระบุ Parameter ให้ด้วย ดังนั้น ตัว Swagger มันก็ได้สร้าง Input ให้ผมได้กรอก Parameter นั้นให้อัตโนมัติเลย

คราวนี้ลองมาดูการส่งข้อมูลแบบ HTTP Post บ้าง ซึ่งมันจะไปดึง Data Structure ของ Model ออกมาให้เราเป็นตัวอย่าง (ตามรูปด้านล่าง กล่องสีเหลืองด้านซ้าย) เมื่อกดที่ตัวอย่าง มันจะมากรอกให้ในช่อง Input ซ้ายมือ เราก็ทำการแก้ไขข้อมูลที่ต้องการใช้งาน ซึ่งในที่นี้ผมทดสอบการเพิ่มข้อมูลสมาชิก เมื่อกรอกเสร็จและกดปุ่ม “Tyr it out!” มันก็จะแสดงผลการทำงานออกมาให้เราดังรูปด้านล่าง

การ Customize Document

ถ้าสังเกตดีๆ มี API ตัวหนึ่งที่มีข้อความโผล่มา ว่า “Get Member information from id” ซึ่งอันนี้ผมทำการ Customize เขียนเพิ่มคำอธิบายเข้าไป

ซึ่งในโค้ด API ที่เราต้องการอธิบายเพิ่มเติม ใส่แค่ /// (triple slash) และระบุ  tag <summary> พร้อมข้อความอธิบายสั้นๆว่า API นี้ทำอะไร (ตามภาพ) เท่านั้นเอง, ถ้าอยากยกตัวอย่างหรืออธิบายเพิ่ม สามารถใส่ <remarks> ได้ และยังมี tag อื่นๆ ที่คุณสามารถไปดูได้ที่ Customize & extend

สรุป

Swagger เป็นเครื่องมืออำนวยความสะดวกในการสร้าง API Document เพื่อลดเวลาการเขียนเอง แต่ทั้งนี้ มีเรื่องของ Security ที่ต้องป้องกันไม่ให้คนอื่นเข้ามาได้ หรือให้ดูได้เฉพาะ Development Environment เท่านั้น รวมถึง ถ้าจะให้ Document สมบูรณ์ เราก็ควรต้องเขียนโค้ดให้ถูกต้องโดยเฉพาะเรื่องของการตั้งชื่อตัวแปร ชื่อฟังก์ชั่น โมเดล ฯลฯ เพราะข้อมูลใน Document จะอ่านง่ายแค่ไหน มันสะท้อนจากโค้ดของเรานั่นเอง

—

Reference: Microsoft.com