วิธีจัดการ Kubernetes บน Amazon EKS

ตัว Amazon EKS (Amazon Elastic Kubernetes Service) มีวิธีการจัดการสองแบบ คือ

• eksctl – ที่เป็น CLI tool ของ Amazon เอง ในการจัดการ Amazon EKS โดยเฉพาะ
• AWS CLI – ที่เป็น CLI tool ของ Amazon ที่ไว้จัดการ Service ต่างๆ ของ Amazon รวมถึง Amazon EKS ด้วย

จากที่ลองทดสอบเล่นทั้งสองแบบ eksctl ใช้งานง่ายกว่ามาก เรียกว่าเป็น Automated Tool สำหรับ shortcut คำสั่งในการจัดการ EKS เลย แต่ก่อนจะไปต่อ เราควรต้องมีความรู้ในสามเรื่องนี้ก่อน เพื่อจะได้ไม่ไป งง กลางทาง

1. AWS Service
2. Docker
3. Kubernetes

เริ่มต้นใช้งาน Amazon EKS

ไม่ว่าจะเลือกวิธีการใดก็ตาม สิ่งที่ต้องทำ มีดังนี้

• ติดตั้ง AWS CLI , สร้าง Access Key ID และ Configure AWS CLI – เพื่อให้เครื่องเราสามารถเชื่อมต่อและควบคุม Account AWS ของเราได้
• ติดตั้ง kubectl – เป็นตัว Core เพื่อใช้ควบคุม Kubernetes Clusters
• ติดตั้ง eksctl – เพื่อไปใช้ร่วมกับ kubectl อีกที ในการควบคุม Kubernetes Clusters บน Amazon EKS
• AWS IAM Permissions – โดย Account AWS เราจะต้องได้รับสิทธิ์ที่เกี่ยวข้องทั้งหมดสำหรับการควบคุม Amazon EKS ทั้งหมด รวมไปถึง ECR, Network, EC2 ด้วยครับ

โครงสร้าง Kubernetes และสิ่งที่จะต้องทำบน EKS

ในรายละเอียด สามารถอ่านจากบล็อกต่างๆ ได้เลยครับ ผมขอสรุปไวๆ ดังนี้

1. Kubernetes Cluster – จำเป็นต้องสร้างก่อนเลย เพื่อใช้เป็น Cluster ของชุด Server เช่น ควบคุม (Control) กระจาย (Distribution) ตั้งกำหนดการ (Scheduling)
2. Control Plane หรือ Master Node – ตัวนี้ก็จะเป็นต้องมี แต่ EKS จะสร้างให้อัตโนมัติ โดยอิงจาก Config ที่เรากำหนดในไฟล์ yml หรือใน AWS Console เช่น Min/Max Node, Min/Max Pod ใช้เพื่อควบคุมสิ่งต่างๆ ใน Cluster
3. Node – ตัวนี้จำเป็นต้องสร้าง เสมือนเครื่อง Server ของเรา สามารถปั๊มเพิ่ม ลด ได้ตามจำนวนที่กำหนด
4. Pod – ตัวนี้จำเป็นต้องสร้าง คือกลุ่มของ Container ของเรา

สร้าง Kubernetes Cluster

ให้รันคำสั่งตามนี้ครับ

eksctl create cluster --name=test-php-web --region ap-southeast-1 --managed --nodes=2 --node-type=t2.micro --with-oidc --ssh-access --ssh-public-key ifew_orm_macbook --profile few_orm

คำอธิบาย

• –name=test-php-web คือ ชื่อ Cluster
• –region ap-southeast-1 คือ Zone ทวีป AWS ที่เราจะใช้งาน ในที่นี้คือสิงคโปร์
• –nodes=2 คือ จำนวน node หรือจำนวนเครื่อง ec2 ที่จะถูกเปิดขึ้นมา (Optional)
• –node-type=t2.micro คือ type class ของเครื่อง ec2 ที่จะถูกเปิดขึ้นมา (Optional)
• –managed คือ บอกว่าจะสร้างแบบ Managed nodes ไม่ใช่แบบ Fargate
• –with-oidc คือ เปิดให้ใช้ OIDC ใน cluster นี้ได้ (Optional)
• –ssh-access คือ เปิดให้ใช้ SSH Access ใน cluster นี้ได้ (Optional)
• –ssh-public-key ifew_orm_macbook คือ ระบุ Public Key สำหรับ SSH Access (Optional)
• –profile few_orm คือ บอกว่าใช้ AWS Profile ไหนในการรันคำสั่งนี้ (Optional)

สร้าง Namespace

ในที่นี้ ผมขอเสริมเรื่องการสร้าง namespace นิดนึง ไว้จำกัดขอบเขตการทำงาน และเพื่อความปลอดภัย กันพลาดพลั้งไปลบอะไรออก

kubectl create namespace myweb

• myweb คือ ชื่อของ namespace ที่จะใช้

จะได้หน้าตาแบบนี้

สร้าง YML File สำหรับ Deployment

สร้างไฟล์ yml ขึ้นมา เพื่อ config pod และการ deployment ในที่นี้ผมใช้ไฟล์ชื่อ eks-myweb-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deployment
  namespace: myweb
  labels:
    app: myweb
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
      - name: phpfpm
        image: xxxxx.dkr.ecr.ap-southeast-1.amazonaws.com/test:v1
        ports:
        - containerPort: 80
        env:
        - name: MYSQL_DB_HOST
          value: mydb.host.com
        - name: MYSQL_DATABASE
          value: test
        - name: MYSQL_USER
          value: ifew 
        - name: MYSQL_PASSWORD
          value: password1234
        - name: MYSQL_ROOT_PASSWORD
          value: password1234
        - name: TEST
          value: test

จากนั้นทำการรันคำสั่ง

kubectl apply -f eks-myweb-deploy.yml

จะได้หน้าตาแบบนี้

ถ้าอยากรู้ว่าสร้างจริงไหม มีอะไรใน namespace เราแล้วบ้าง ให้ใช้คำสั่งนี้ครับ

kubectl get all -n myweb

myweb คือ ระบุชื่อ namespace

จากนั้นจะได้ข้อมูลดังนี้

ใน config ผมสร้างไว้ 2 pod ดังนั้น และถ้าใช้งานได้ ตรง Status จะขึ้นว่า Running

ลองไปดูใน AWS Console โดยเข้าไปที่เมนู EKS > เลือกชื่อ Cluster ที่เราสร้าง > เลือก Node ที่เราสร้าง > Pods จะแสดงรายการสองกลุ่ม คือ กลุ่ม Node Processes กับกลุ่ม Pod ที่เราสร้างขึ้นมา

ตอนนี้แอพเราขึ้นไปรันรอไว้แล้ว แต่ยังไม่มีช่องทางเข้านะครับ เราต้องสร้าง Service ขึ้นมาก่อน

สร้าง YML File สำหรับ Service

สร้างไฟล์ yml ขึ้นมา เพื่อ กำหนด Service และให้มีช่องทางเข้าไป Pod ที่เราสร้าง โดยผมจะสร้างแบบมี Load Balance ด้วย และตั้งไฟล์ชื่อ eks-myweb-service.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-service
  namespace: myweb
  labels:
    app: myweb
spec:
  selector:
    app: myweb
  ports:
  - name: http
    port: 80
    targetPort: 80
  type: LoadBalancer

จากนั้นทำการรันคำสั่ง

kubectl apply -f eks-myweb-service.yml

จะได้หน้าตาแบบนี้

ลองดูสิ่งที่อยู่ใน namespace อีกครั้ง

จะเห็นว่า มี Service เพิ่มเข้ามาแล้ว โดย Type เป็น LoadBalancer ตามที่ได้ config ใน yml ของเรา
ส่วน URL ที่ใช้เข้า App เรา อยู่ตรง External-IP นั้นเอง

ลองเข้า App ที่สร้างขึ้นมา

เปิด Brower และเข้า URL จาก External-IP ที่แสดงในขั้นตอนก่อนหน้านี้ ก็สามารถใช้งานได้แล้วครับ

Tip: ใช้งาน HTTPS ผ่าน ACM Certificate

โดยให้สร้าง ACM certificate ขึ้นมา และใน yml ไฟล์ของ service ให้เพิ่มสองส่วนตามภาพด้านล่าง

โดยรายละเอียดวิธีติดตั้ง ให้ดูได้ที่ https://aws.amazon.com/premiumsupport/knowledge-center/terminate-https-traffic-eks-acm/

สรุป

สำหรับ Kubernetes ผมเองเรียกว่าเบสิกมากๆ เป็นมือใหม่เลย ได้ลองเรียนรู้ใช้งานมาสักพัก เลยอยากสรุปไว้ให้ผู้อ่าน ที่กำลังริเริ่มอยากทดลองใช้ Kubernetes มาได้ใช้ด้วยกันครับ ผ่านบริการของ Amazon EKS ก็หวังว่าจะช่วยให้การเริ่มต้นได้ง่ายขึ้น และเอาไปต่อยอดเพื่อใช้งานระดับ Advance ต่อไป

หากใครอยากได้สรุปคำสั่งต่างๆ รวมถึงโค้ดตัวอย่าง ทั้งหมดในโพสต์นี้
สามารถไปดูได้ที่ https://github.com/ifew/eks-test-php

Reference

• https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html

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

bref คืออะไร

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

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

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

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

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

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

npm install -g serverless

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

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

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

mkdir php-bref-function

Install bref

composer require bref/bref

ทำ PHP Function Serverless ตัวแรก

Create PHP Lambda

vendor/bin/bref init

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

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

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

Config PHP Lambda

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

โดย

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

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

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

ทดสอบ PHP Function Serverless บน localhost

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

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

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

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

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

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

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

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

serverless deploy

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

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

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

serverless invoke -f <function-name>

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

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

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

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

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

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

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

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

php -S localhost:8000 index.php

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

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

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

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

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

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

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

serverless remove

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

สรุป

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

ข้อสังเกต

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

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

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

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

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

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

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

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

1.Amazon API Gateway

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ข้อจำกัด

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

สรุป

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

อ้างอิง

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

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

Serverless คืออะไร?

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

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

iFew

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

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

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

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

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

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

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

AWS Lambda คืออะไร?

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

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

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

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

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

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

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

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

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

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

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

iFew

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iFew

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

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

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

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

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

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

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

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

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

สรุป

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

Slide

• Introduce AWS Lambda for newbie and Non-IT

อ้างอิง

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

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