วันนี้เพิ่งสังเกตเห็นการเปลี่ยนแปลงใน Robot framework และ Selenium Library 6
ซึ่งช่วยให้การพัฒนาง่ายขึ้น ดังนี้

• การจัดการ driver ของ web browser ต่าง ๆ ให้เลยแบบอัตโนมัติ
• การ close browser และคืน resource หรือจัดการลบ process ของ driver ไปให้เองแบบอัตโนมัติ

ดังนั้นแนะนำให้ทำการ upgrade กันได้แล้ว

ปล. เพอ่งเห็นการเปลี่ยนแปลง แต่แาจจะเปลี่ยนมาก่อนหน้านี้แล้วก็ได้

สำหรับการจัดการ browser driver ดูเพิ่มเติมได้

จาก blog เรื่อง Note :: การเปลี่ยนแปลงเรื่อง driver ของ Web browser ใน Robot framework + selenium นั้น
มีข้อสงสัยว่ามันทำงานอย่างไร ?
ก็เลยลองไปดูเอกสาร และ source code พบว่า
ใน Selenium 4.6 นั้นจะมีการจัดการ Browser Driver แบบใหม่เพิ่มเข้ามา
นั่นก็คือ Selenium Manager ซึ่งเป็น version beta

โดยที่ตัว Selenium Manager (beta) ช่วยให้จัดการ browser ได้ง่ายขึ้น
แต่ยังเป็น beta 1 เท่านั้น หมายความว่า ทดลองใช้ก่อนนะ
อาจจะมีการเปลี่ยนแปลงอีกมาก หรือ ไม่ stable เท่าไร
จะทำการจัดการ driver ของ Google Chrome, Firefox และ Edge ให้แบบอัตโนมัติ
ถ้าไม่เจอ driver ใน $PATH ของระบบที่ run test

ต่อไปจะทำการ download ให้เองอีกด้วย
เพื่อช่วยให้การจัดการ driver กับ browser ให้ตรงกันอีกด้วย

อีกอย่างมี Selenium Manager CLI ให้ใช้งานอีกด้วย

มาถึงตรงนี้จึงช่วยคลายข้อสงสัยไปได้เยอะ

อ่านไปเจอเรื่อง Path to Production
พบว่าน่าสนใจมาก ๆ
โดยเป็น workshop หรือ แนวทางในการทำงานร่วมกัน
ที่ทำงานเป็นแบบ cross functional team/people
นั่นคือ เป็นการทำงานข้ามแผนกหรือส่วนการทำงานมากมาย

เพื่อช่วยทำให้เข้าใจว่า
ขั้นตอนการทำงานตั้งแต่การออกแบบ พัฒนา ทดสอบ deploy และ release
ตลอดจนการ operate ต่าง ๆ ของระบบหนึ่ง ๆ เป็นอย่างไรบ้าง

Path to Production

• process หรือขั้นตอนเป็นอย่างไร เรียงตามลำดับที่เกิดขึ้น ในส่วนการทำงานของคนในแต่ละกลุ่ม
• ตั้งแต่การออกแบบ ไปถึงการส่งมอบที่ production environment

จะเห็นได้ว่า มันคล้าย ๆ กับการออกแบบ pipeline ของ CI/CD นั่นเอง
แต่ในส่วนนี้จะเน้นกับคนหลากหลายกลุ่มที่เกี่ยวข้อง
มาออกแบบ หรือ สรุป ขั้นตอนต่าง ๆ หรือ การทำงานต่าง ๆ ที่เกิดขึ้น
สำหรับการส่งมอบระบบหนึ่ง ๆ นั่นเอง

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

ในการแบ่งปันเรื่อง Microservices Design ที่ Skooldio นั้น
มีการถามตอบเรื่องของระบบที่พัฒนาด้วย NodeJS
ซึ่งโดยปกติจะทำการแบบ single thread, non-blocking I/O
ทำงานได้ดีอยู่แล้ว แต่เมื่อเจอ concurrent สูง ๆ ขึ้นมา
กลับทำงานได้ไม่ดีเลย
ยิ่งลองไปเทียบกับ Go แล้ว คนละเรื่องกันเลย

ดังนั้นจึงสรุปเรื่องของการ scale NodeJS บน production แบบง่าย ๆ ไว้ดังนี้

ทำการเพิ่ม process บนเครื่องเดียวกัน

• แนะนำให้ใช้ Cluster mode ของ NodeJS สำหรับการเพิ่ม process มารับงานเยอะ ๆ
• ใช้งานร่วมกับ PM2 ซึ่งเป็น process manager ที่ทำงานแบบ cluster หรือ multi-process ได้ รวมทั้งยังช่วยจัดการเรื่อง process ให้อีกด้วย

ทำการแยกเครื่อง

• ใช้งานร่วมกับ Load balance เพื่อกระจาย load ไปทำงานอีกด้วย เช่น NGINX และ HA Proxy เป็นต้น
• ถ้าระบบงานมีขนาดใหญ่ แนะนำให้แยกตาม usage การใช้งาน ถ้าส่วนไหนใช้งานเยอะ ๆ น่าจะแยกออกมาสร้างเป็น service และ run/deploy แยกกันไป
• ด้านข้อมูลที่จัดเก็บหรือต้องใช้งาน ก็ให้ทำการ split ออกไป เช่น sharding หรือ partitoning เป็นต้น

เพิ่งเห็นว่าทาง Docker ได้ปล่อย Docker+Wasm Technical Preview ออกมาให้เล่น
ซึ่งอยู่ในสถานะ beta นั่นคือ ไม่เหมาะในการใช้งานบน production นะ
เป็นอีกทางเลือกสำหรับการจัดการ container ด้วย Docker
ที่เบาและรวดเร็วขึ้นอย่างมาก

คำเตือนก่อนใช้งาน

• อาจจะเกิดปัญหาต่าง ๆ ที่ไม่คาดหวังเยอะ
• เปิดใช้งาน containerd image store (beta) โดย default และไม่สามารปิดได้

โครงสร้างการทำงานเป็นดังรูป

ลอง Download มาใช้งานเล่นกันดูครับ
ในหน้าเอกสารเต็มไปด้วย beta, warning และ important ลองอ่านก่อนนะครับ
ขอให้โชคดี

ปัญหา

จากการใช้งาน Logstash 8 นั้น พบว่าไม่สามารถใช้งานได้
เนื่องจากตัวมันเอง พยายามจะทำการตรวจสอบ licence จาก elasticsearch เสมอ
ซึ่งจากที่ไปดูเป็นค่า default ด้วย
ดังนั้น ถ้าไม่ติดตั้ง elasticsearch ด้วย จะทำให้ Logstash มัน start ไม่ขึ้น

การแก้ไขปัญหามีดังนี้

• วิธีที่ 1 ง่าย ๆ ก็ติด ตั้ง Elasticsearch แต่ไม่เอา เพราะว่าเปลือง resource และไม่ได้ใช้งานด้วย
• วิธีที่ 2 ทำการ disable การตรวจสอบ licence ไป ซึ่งเลือกใช้วิธีการนี้
• วิธีที่ 3 ไปใช้ตัวอื่น

ให้ทำการเพิ่ม config นี้เข้าไปใช้ไฟล์ logstash.conf ไป

เพียงเท่านี้ก็ใช้งานได้แล้ว

เพิ่งเห็นว่า Spring Boot 3 GA นั้นถูกปล่อยออกมาให้ใช้แล้ว
นั่นหมายความว่า ได้เวลาเปลี่ยนมาใช้กันจริง ๆ
หลังจากที่ปล่อยให้เตรียมตัวอยู่นาน
ซึ่งเป็นเวลากว่า 5 ปีที่ Spring Bppt 2 ปล่อยออกมา

โดยที่ feature ที่สำคัญ ๆ ประกอบไปด้วย

• Spring Framework 6
• ทำการสร้าง native image ด้วย GraalVM
• Java 17 ขึ้นไปเท่านั้น
• ปรับปรุงเรื่องของ Observability นั่นคือ Micrometer และ Micrometer Tracing
• สนับสนุน Jakarta EE 10 (พวก package javax จะเปลี่ยนชื่อทั้งหมด)

ดังนั้นทำการ upgrade หรือไปสร้าง project จาก Spring Initializr ได้เลย

ทาง Cockroach Labs นั้น ได้แจกฟรีหนังสือ Foundations of Scalable Systems
ตั้งแต่บทที่ 1 - 3 ประกอบไปด้วย

• Introduction to scalable systems
• Distributed system architecture
• Distributed system essentials

ในบทที่ 1 ทำการอธิบายเรื่องของการ scale ของระบบงาน

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

ปัญหาที่มักเจอในระบบเมื่อมีผู้ใช้งานมากขึ้น

• database ทำงานช้า
• webserver ทำงานช้า
• แต่ละ request มีการใช้งาน database จำนวนมาก ดังนั้นยิ่งมี request มาก ๆ แล้ว database ก็ยิ่งทำงานหนัก เป็นการออกแบบที่ไม่ดี
• เลือกเครื่องมือ และ เทคโนโลยีในการพัฒนาแต่สนใจแต่ความง่าย หรือ productivity แต่ไม่ได้สนใจเรื่อง scalability ซึ่งต้องให้สมดุลทั้งสองฝั่ง

ในการออกแบบระบบ ล้วนมี trade-offs เสมอ ซึ่งต้องเข้าใจ และ วางแผนไว้เสมอ

• Performance
• Availability
• Security
• Manageability

ในบทที่ 2 และ 3 ว่าด้วยเรื่องของ Distributed architecture

ว่าจะทำการ scale อย่างไรบ้าง
ทั้งการ scale out และ scale up
รวมทั้งการนำ caching data มาใช้งาน เพื่อลดการใช้งาน database
และการใช้งาน distributed database เพื่อกระจายข้อมูลและใช้งานออกไป
หรือกระจาย process การทำงานออกไปแต่ละส่วน

เพื่อช่วยให้ระบบทำงานและตอบสนองได้รวดเร็วยิ่งขึ้น
สามารถ scale แยกกันทั้ง hardware และ software ได้สะดวกขึ้น
แต่ก็ตามมาด้วยความซับซ้อนมากยิ่งขึ้น
นั่นคือการดูแลรักษาก็ไม่ง่ายตามไปด้วย

ในระบบแบบกระจายนั้น ปัญหาหรือสิ่งที่ต้องเข้าใจ เพื่อจัดการไว้
ประกอบไปด้วย

• การติดต่อสื่อสารระหว่างส่วนงานที่แยกออกจากกัน
• ปัญหาเมื่อส่วนใดส่วนหนึ่งเกิดปัญหา จะลดผลกระทบต่อระบบโดยรวมอย่างไร
• การจัดการเรื่องเวลาของแต่ละระบบ จะจัดการอย่างให้ให้ตรงกัน

และมีอีกหลาย ๆ เรื่องที่น่าสนใจ

ดังนั้น Download มาอ่านกันในช่วงวันหยุดได้เลย

วันนี้นั่งอ่านบทความเรื่อง Postgres: a better message queue than Kafka?
ทำการอธิบายการสร้างระบบ logging
ซึ่งทำงานอยู่บน PostgreSQL
ว่ามีข้อดีและข้อเสียอย่างไร รวมทั้งการปรับปรุงในอนาคต
ทำไมถึงใช้งาน PostgreSQL แทนที่จะเป็น Apache Kafka สำหรับ message queue

สิ่งหนึ่งที่น่าสนใจคือ การเลือกใช้เครื่องมือกับงาน

โดยสิ่งที่ใช้ในการตัดสินใจอันดับแรกคือ เครื่องค่าใช้จ่าย
ยิ่งเป็นบริษัทขนาดเล็ก มีเงินทุนไม่มาก
การเพิ่ม infrastructure เข้ามาใหม่ ยิ่งเพิ่มต้นทุนให้มากขึ้น
ดังนั้นสิ่งที่ต้องดูก่อนคือ infrastructure เดิม
สามารถแก้ไขหรือจัดการปัญหาที่เราต้องการได้หรือไม่

ค่าใช้จ่ายที่สูงขึ้น ประกอบไปด้วย

• เวลาในการประเมินเทคโนโลยีใหม่ ๆ
• เวลาในการเรียนรู้
• การ monitor
• การ debug เพื่อหาปัญหาบน production
• การดู ecosystem ของสิ่งที่นำมาใช้
• ความเชี่ยวชาญ เพื่อให้การปรับไปใช้เป็นไปอย่างถูกต้อง

ดังนั้นในการสร้าง feature แรก ๆ
จึงเลือกใช้สิ่งที่ทีมมีความรู้ความเข้าใจ มีประสบการณ์ ก่อน
แน่นอนว่า มันต้องตอบโจทย์ในสิ่งที่เราต้องการก่อนด้วย
ทั้งค่าใช้จ่าย ประสิทธิภาพ และมีความปลอดภัย

หลังจากทำการสร้างเรียบร้อย ก็ต้องมีดูว่ามีข้อดีและข้อเสียอะไรบ้าง
ด้วยการ minitoring ระบบการทำงาน
เพื่อทำการปรับปรุงให้เหมาะสมต่อไป

ยกตัวอย่างของปัญหาที่เจอ

• ID overflow จากการใช้งาน primary key เป็นแบบ auto increment 32 bit ซึ่งปัญหาเกิดขึ้นไปเมื่อผ่านไป 2 เดือน จึงทำการเปลี่ยนไปใช้ 64 bit
• จัดการปัญหา traffic ที่สูงด้วย rate limit
• การขยายขนาดของ DB server ซึ่งทำให้ระบบ down ลงไป เมื่อต้องทำการ scale ในช่วง peak time ซึ่งมีค่าใช้จ่ายที่สูงอีกด้วย

ต่อไปในอนาคตเมื่อขยายการทำงานมากขึ้น
ก็อาจจะต้องมีการเปลี่ยนแปลงต่อไป ทั้ง
การใช้งาน Sharding ใน PostgreSQL
หรือไปใช้งาน messaging server อื่น ๆ เช่น Apache Kafka เป็นต้น
หรืออาจจะไปใช้ database อื่น ๆ ก็ได้ เช่น Neon, CockroachDB และ DynamoDB เป็นต้น

หลังจากที่พูดคุยเรื่องการนำ Redis มาใช้งาน
ทั้งการจัดเก็บข้อมูลชั่วคราว (caching data)
ทั้งการใช้งาน pub/sub สำหรับ messaging system
ซึ่งมีการสรุปเรื่อง architecture ของ Redis ที่เหมาะสมต่องาน
มีรูปแบบต่าง ๆ ดังนี้

รูปแบบที่ 1 สำหรับคนจริง พังได้ คือ Single Redis Instance

ติดตั้งง่ายสุด ๆ
แต่พังแล้วพังเลย ต้องติดตั้งหรือ restart ใหม่
ใช้สำหรับการจัดการ service ที่มีขนาดเล็ก รับความเสี่ยงได้
แต่ถ้าทำการ persistence ข้อมูลลง disk ได้ดี
ทั้ง RDB และ AOF ก็ลดความเสีายงเรื่องข้อมูลหายได้

รูปแบบที่ 2 Redis High Availability (HA)

สำหรับระบบที่ต้องการความเสถียรมากขึ้น
ให้ทำการ replicate ข้อมูลไปยัง instance/server อื่น ๆ ซะ
เหมือนกับ master/slave นั่นเอง
เขียนข้อมูลที่ master หรือ primary instance
อ่านข้อมูลที่ slave หรือ secondary ซึ่งมีได้มากกว่า 1 instance
แต่มาพร้อมกับความซับซ้อนในการ deploy

รูปแบบที่ 3 Redis Sentinel

จะมีกลุ่มของ instance ที่เรียกว่า sentinel
สำหรับการจัดการ instance ต่าง ๆ ใน redis HA หรือ cluster
ช่วยทำให้แต่ละ instance ทำงานร่วมกันได้ดี
นั่นคือเมื่อมีเครื่องใดเครื่องหนึ่งแล้ว
sentinel จะจัดการให้ cluster ทำงานได้
เช่นเครื่อง master พังแล้ว sentinel จะเลือกเครื่องอื่น ๆ มาเป็น master ต่อไป
และ sentinel จะทำการ monitor และ ส่งข้อมูลของ cluster
ไปยัง client ที่ติดต่อมาอีกด้วย
ปัญหาหลัก ๆ ของ sentinel คือ ความซับซ้อน จำนวน instance
รวมทั้งเรื่อง network ระหว่าง instance ต้องเร็วและเสถียร

รูปแบบที่ 4 Redis Cluster

เป็นรูปแบบที่ได้รับความนิยม
ทำมาสำหรับการ scale แบบ horizontal คือการเพิ่มเครื่องเข้ามา
แถมสามารถกระจายข้อมูลแบบ shading ได้อีก
แต่ก็ซับซ้อนมาก ๆ

ดังนั้นจากทั้ง 4 รูปแบบนั้น ต้องเลือกจากความต้องการทาง business
รวมทั้งความสามารถของทีมอีกด้วย
เพื่อเลือกให้เหมาะสมกับงานต่อไป

เห็นมีคนลองใช้งานกันเยอะ สำหรับ OpenGPT
จึงลองใช้งานดูบ้าง โดยสิ่งที่ต้องการประกอบไปด้วย

• สร้าง REST API ด้วยภาษา Go และใช้ Echo framework
• ทำการทดสอบในส่วนของ API

มาลองใช้งานกันดู

ขั้นตอนที่ 1 เริ่มด้วยการออกแบบ API ที่ต้องการก่อน

ถ้า input ดีแล้ว ก็จะทำให้ได้ผลลัพธืที่ดีขึ้น
โดยสิ่งที่ออกแบบและบอกให้ทำ เป็นดังนี้

ทาง ChatGPT จะตอบกลับมาด้วย code พร้อมคำอธิบาย ดังนี้

จะเห็นได้ว่ามีการเรียกใช้ function doRegister() แต่ไม่มีการประกาศ
จึงต้องสั่งเพิ่มเติม ด้วยการให้สร้าง function นี้ด้วยการบันทึกข้อมูลลง MySQL database ก็แล้วกัน

จะได้ code อีกชุดมาดังนี้

ขั้นตอนที่ 2 อยากให้เปลี่ยน web framework ไปใช้งาน Echo framework

ทาง ChatGPT ก็จัด code ให้และอธิบายเป็นขั้นตอนดังนี้

• ติดตั้ง library
• การใช้งาน middleware
• การเขียนในส่วน routing

ขั้นตอนที่ 3 ต้องทำ API testing ด้วย Echo framework ด้วยสิ ถึงจะครบสูตร

ก็จะได้ code ออกมา โดยแนะนำให้ใช้งาน testify library สำหรับการทดสอบอีกด้วย

จากนั้นก็ถามไปว่า เราจะแยก database ออกจาก testing อย่างไร (isolate)
ก็แนะนำมาเยอะเลย

มาถึงตอนนี้ได้โครงสร้าง code ทำงานเกิน 50% เข้าไปแล้ว

เพิ่มเติมนิดหน่อย คือ การ isolate ระหว่าง routing กับ database ออกจากกันด้วย
interface และ struct เลยสั่งให้ช่วยทำหน่อย
ก็ได้ code ดังนี้มี

แล้ว test อย่างไร ก็เลย ถามต่ออีก

สบายละงานนี้ !!!

ขั้นตอนที่ 4 ทำการสร้าง Dockerfile สำหรับ project นี้

จากที่บอกตรง ๆ ไปว่าให้สร้าง Dockerfile
จะใช้งาน go 1.16 มาให้
จึงต้องบอกแบบเฉพาะเจาะจงไปด้วย
ทั้ง version ของ go
และวิธีการสร้าง Dockerfile แบบ multi-stage build ด้วย
จะได้ตามที่ต้องการมากยิ่งขึ้น

สิ่งที่ได้เป็นดังนี้ พร้อมทั้งคำอธิบาย และ ขั้นตอนการ run ด้วย

ยังไม่พอ ขอให้สร้าง docker-compose.yml สำหรับ project นี้ และ mysql database
และของ mysql database แบบ master-slave ด้วย
จะได้ดังนี้

มาถึงตรงนี้ deploy ระบบงานดีกว่านะ

ขั้นตอนที่ 5 ทำการ deploy ไปยัง Digital Ocean เล่น

โดยจะทำการ provisioning server ขึ้นมาใหม่
และทำการ deploy ทั้ง app และ database ด้วย Terraform

เมื่ออธิบายไปให้ ก็จะทำการบอกขั้นตอนตั้งแต่การติดตั้ง การเขียน main.tf และ deploy กันเลย

เพียงเท่านี้เราก็ได้ code ที่พอจะทำงานและ deploy ได้แล้ว
ช่วยลดเวลาไปได้เยอะเลย
แต่จำเป็นต้องมีความรู้พื้นฐาน รวมทั้งความต้องการที่ชัดเจน
จะช่วยเราได้อย่างมาก

ตัวอย่าง code และ instruction

เพิ่งเห็นว่าทาง Docker เพิ่งจัดงาน Docker Community All-Hands แบบ online ขึ้นมา
ตั้งแต่วันที่ 15-16 ธันวาคมที่ผ่านมา
เป็นการ update technology ต่าง ๆ ใน community ของ Docker ทั้งโลก
โดยมี session ต่าง ๆ ที่น่าสนใจเพียบเลย

ยกตัวอย่างเช่น

• DART project ของ NASA
• How to create a great local Python development environment with Docker
• Best practices for production-ready .NET Docker images
• Cloud Native WebAssembly. What's all the hype?
• WebAssembly, Docker, Containerd, and K8s in 10 Minutes
• Latest and greatest on Docker Extensions

โดย VDO ทั้ง 2 วันเข้าไปดูใน youtube ได้เลย

• VDO วันที่ 1
• VDO วันที่ 2
  

ปัญหาที่พบเจอ เกี่ยวกับเรื่องของ caching data
เมื่อระบบมีคนใช้งานจำนวนมาก ๆ
แล้วระหว่างนั้น เหตุการณ์ที่ไม่คาดฝันก็เกิดขึ้น
นั่นคือ caching data นั้น มีอายุ และดันหมดอายุพร้อม ๆ กัน
ทำให้แต่ละ request ไม่เจอข้อมูลใน caching เลย
ผลที่ตามมาคือ ทุก ๆ request ต้องไปดึงข้อมูลจาก database/data store หลัก
ทำให้ระบบช้า หรือ ล่มไปง่าย ๆ เลย

ดังนั้นมาดูแนวทางในการแก้ไขปัญหากันก่อน
ว่ามีอะไรบ้าง ?

• caching data ไม่มีอายุ (มันดีใช่ไหม ? ตรงนี้น่าคิด)
• ทำการ warm caching data ขึ้นมาใหม่ ว่าแต่ตอนนั้นระบบก็ถูกใช้งานเยอะนะ ถึงแม้จะแยก process ออกไป จะทำงานได้ดีจริง ๆ หรือ ?
• ทำการต่อ expire time ให้แบบอัตโนมัติเลย เช่น ต่อเวลาทุกครั้งเมื่อมีการเข้าถึง หรือ ถ้าหมดอายุก็ต่ออายุให้ ปัญหาคือ ถ้ามีคนเข้าถึงข้อมูลที่จะ expire พร้อม ๆ กันละ ก็ไม่ช่วยลดหรือแก้ไขปัญหาไหมนะ ? แต่ว่าจะเกิดกรณีนี้เยอะไหม คิดเป็นกี่ % ? (ในกรณีหลัก ๆ ช่วยลดหรือแก้ไขปัญหาได้ และ ง่าย)
• จากวิธีการก่อนหน้า ทำการ lock เข้ามาช่วยดีไหม สำหรับการเข้าถึงข้อมูลเดียวกันแบบพร้อม ๆ กัน ทำให้ไม่เกิดเหตุการณ์แบบก่อนหน้านี้ แต่ว่าจะลด performance ลง เนื่องจากจะต้องเข้าถึงแบบ sequencial นั่นเอง แต่ช่วยลดได้ (ดูซับซ้อนขึ้น แต่แก้ไขปัญหาได้) เช่น RedLock ของ Redis เป็นต้น

วันนี้ได้ลองใช้งาน Ddosify เป็นเครื่องมือสำหรับการทำ performance testing ระบบงาน
ซึ่งพัฒนาด้วยภาษา Go และยังมี Docker image
รวมทั้ง Docker extension ให้ใช้งานกันแบบง่าย ๆ
โดยจะสนับสนุน HTTP protocol ทั้ง 1 และ 2
สามารถเขียน scenario การทดสอบได้ด้วย JSON file

แต่สิ่งที่สนใจมาก ๆ คือ การสร้าง virtual user ที่สูงดี ไม่รู้ว่าถูกไหม แต่ชอบ
รวมทั้งการใส่ parameter เข้าไป แบบ สั่งให้ random ได้ด้วย
ซึ่งจะเรียกว่า Parameterization

ยกตัวอย่างการใช้งาน

ใช้งานง่ายดี ไว้ลองไปใช้งานจริง ๆ กัน

ส่วนถ้าใครอยากทำอะไรที่มากกว่า ก็ไปใช้บน Cloud ได้
มีความสามารถเยอะขึ้น
ทั้ง distributed testing
ทั้ง latency testing
ทั้ง report สวย ๆ
ทั้ง User Interface การ config การทำ performance testing ประเภทต่าง ๆ

เช้านี้เจอปัญหาจากระบบหนึ่งที่พัฒนาด้วยภาษา Go
ซึ่งพบเจอ error ว่า "Error 1040: Too many connections"
ตั้งแต่เปิดระบบให้บริการมา ยังไม่เคยเจอ error นี้เลย
แต่เมื่อไปดูเรื่องของ traffic การใช้งาน พบว่าใช้งานสูงขึ้นอย่างมาก
ซึ่งคิด ๆ ดูแล้ว ก็เป็นเรื่องที่ดีเลย ที่เจอ error นี้
ดังนั้นไปดูปัญหา และ re-produce ปัญหากันหน่อย
เพื่อจะได้แก้ไขปัญหาได้ง่าย และ ถูกต้องมากขึ้น

เริ่มจากการทำ load test แบบง่าย ๆ ด้วย Ddosify นิดหน่อย

ยิงไปสัก 5,000 request ก็พังตามนี้

error มาเพียบ

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

ก็เลยทำการเปลี่ยนไปใช้ Go routine และ channel นิดหน่อย
สำหรับการ insert ข้อมูล เพื่อช่วยให้จัดการ resource ได้ดีขึ้น
โดยที่ยังไม่เปลี่ยนแปลง config อะไร

ตัวอย่าง code แบบง่าย ๆ ก็แจ้งแนวทางการแก้ไขกลับไป
เพื่อปรับปรุงการทำงานของ code และระบบให้ดีขึ้น

จากนั้นเพื่อให้แน่ใจ ลองยิง load test กันอีกหน่อย
จะได้ผลเป็นที่น่าพอใจ
คือ ไม่มี error อีกแล้ว
ส่วนการทำงานก็ผ่านฉลุย
รวมทั้งเพิ่มจำนวนการยิงให้สูงขึ้นไปอีก 2 เท่าตัว ก็ผ่าน เช่นกัน

สุดท้าย ยังมีวิธีแก้ไขอีกหลายอย่างเลย
ไว้ค่อย ๆ ปรับปรุงกันไป ตามรูปแบบของ traffic ที่เกิดขึ้นต่อไป
ทั้ง code และ database

ปัญหาที่มักพบเจอบ่อยมาก ๆ ของระบบงานคือ
การแย่งใช้งาน resource ต่าง ๆ ที่มีจำกัด พร้อมกัน
ผลที่ตามมาคือ ระบบงานทำงานไม่ถูกต้อง
เช่น เกิดการทำงานซ้ำ เป็นต้น
หรือเราจะเรียกว่า race condition

ว่าแต่ถ้าเกิดปัญหาแบบนี้ เราจะแก้ไขอย่างไรดี ?

ก่อนอื่นก็ต้องไปดูที่ use case และต้นเหตุของปัญหาก่อน
เพื่อที่จะแก้ไขได้ตรงจุดมากยิ่งขึ้น

การทำงานช้า ทำให้ฝั่ง UI รอนาน หรือ กดซ้ำได้

ผลที่ตามมาคือ เกิดการ submit ข้อมูลมาซ้ำได้
ส่วนใหญ่ก็แก้ไขด้วย ให้ทางฝั่ง UI ไม่ให้กดซ้ำนั่นเอง
เพราะว่า ง่ายสุด ๆ
คำถามคือ ปัญหาลดลงไหม ถ้าลดถือว่า ok นะ
แต่มันแก้ไขได้หมดไหม ?
ตรงนี้น่าคิด

ทางฝั่ง Backend ต้องแก้ไขไหม ?

เช่น ต้องทำงานแบบ idempotence ไหม ?
คือ ถ้าเป็น request เหมือนกันหรือตัวเดิม จะไม่ทำซ้ำ

เช่น ต้องให้ทำงานได้เร็วขึ้น
ด้วยการเปลี่ยน logic การทำงาน
หรือ scale ในส่วนการทำงานต่าง ๆ เพื่อรองรับ

หรือต้องเอาระบบ Queue หรือ First-In First-Out มาช่วยจัดการ
เพื่อการันตีการทำงานครั้งเดียวแน่ ๆ ไม่ซ้ำ

หรือจะเอาแนวคิดเรื่องของการจองมาใช้งานดี ? (Reservation pattern)

ขั้นตอนการทำงานก็ไม่ยากไม่ง่าย
แต่เพิ่มขั้นตอนการทำงานมาหน่อย ดังนี้

จากเดิมก่อนจะใช้งาน เช่น การใช้งานระบบส่วนลด
จะต้องทำการตรวจสอบว่า สามารถใช้งานได้หรือไม่
โดยปกติตอนที่เราทดสอบเพียงคนเดียว ก็ผ่านตลอด
แต่เมื่อ deploy ขึ้น production แล้ว
จะพบว่า ทำไมมีปัญหาทุกครั้ง
เช่น ทำไมมีคนใช้ promotion เกินกว่าที่กำหนดนะ !!

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

ก่อนที่จะใช้งานใด ๆ ก็ตาม จะให้ทำการจองก่อน (Reservation)

ดังนั้นจึงต้องมีการกำหนด status ของการใช้งาน เช่น

• จอง
• ใช้งานสำเร็จ
• ใช้งานไม่สำเร็จ

โดยในการจองก่อนใช้งาน จะมีเวลากำหนดให้ด้วยเช่น 5-10 นาทีเป็นต้น
แล้วแต่จะกำหนดให้เข้ากับการใช้งาน

ดังนั้นก่อนจะใช้งานจะได้ id หรือ code หรือ token ของการจองก่อน
จากนั้นให้ทำการส่งสิ่งที่ได้มาด้วย ตอนการใช้งานส่วนลด
จะช่วยให้เราตรวจสอบ race condition ได้ง่าย
ถ้าใครใช้งาน โดยไม่มีการจอง ก็ reject ไป
หรือถ้าใช้งาน โดยที่การจองหมดอายุ ก็ reject ไป

ทำให้เราสามารถแยกการทำงานหรือพัฒนาระบบเป็น 2 ขั้นตอนได้เลย
ทำให้เราสามารถ scale ระบบงานได้ตามส่วนงานได้ง่ายขึ้นอีก
แน่นอนว่า มีข้อดี ย่มมีข้อเสียเสมอ

อย่าง database สำหรับการจอง สามารถเป็น database ต่างจากระบบส่วนลดได้อีก
เพราะว่าการจองต้องเร็ว !!
ส่วน process การใช้ส่วนลดสามารถช้าได้ เพราะว่าต้องการความถูกต้องมาก

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

ลองคิดดูสิว่า
ถ้าเก็บลงใน RDBMS จะทำการตรวจสอบอย่างไร ?
ต้องมี batch process ที่ต้องมีลบ หรือ update ข้อมูลทุก xx นาทีไหม ?
แต่ถ้าใช้ database ที่จัดการเรื่องนี้ให้เองจะดีกว่าไหม ?
สิ่งต่าง ๆ เหล่านี้ เราต้องเลือกให้เหมาะสม
ทั้ง skill และ business ด้วยเสมอ

สุดท้าย ถ้าเราเจอปัญหาแบบนี้ จะแก้ไขกันอย่างไรบ้าง ?

เช้านี้เห็นในกลุ่ม Go กำลังพูดคุยเกี่ยวกับ Go 1.20 ว่า
ในการแปลงค่าจาก array ไปเป็น string นั้นเร็วขึ้นอย่างมาก
และลดการจองพื้นที่ในหน่วยความจำลงไปอย่างมาก
โดยใช้ function ชื่อว่า String() ใน package unsafe
มาดูตัวอย่างการใช้งานกัน

อย่างแรกทำการ update Go มาใช้ Go 1.20 rc1 ก่อน

จากนั้นทำการเขียน code ในรูปแบบเก่าใช้ string() ปกติ
และใช้ String() จาก package unsafe ดังนี้

เขียนชุดการทดสอบ เพื่อ benchmark ผลการทำงาน

ทำการ benchmark ดู ผลท่ีได้เป็นดังนี้

ได้ผลเร็วขึ้นอย่างมาก น่าใช้มาก ๆ
และสามารถไปดูความสามารถอื่น ๆ ได้ที่ Release note 1.20

เห็นว่ามีคนสรุป link ต่าง ๆ ที่เกี่ยวการนำ ChatGPT มาใช้งาน
ที่ Awesome ChatGPT
ประกอบไปด้วย

• Library ในการใช้งานของภาษาโปรแกรมต่าง ๆ
• Browser extension ทั้ง Chrome และ Firefox
• การ integrateเข้ากับระบบต่าง ๆ เช่น Editor, IDE และ communication tool ต่าง ๆ
• Desktop app

รวมทั้งยังมีบทความอื่น ๆ ที่นำ ChatGPT มาประยุกต์ใช้งาน เช่น

• 20 Entertaining Uses of ChatGPT You Never Knew Were Possible

น่าจะเพิ่ม idea ได้ดีมาก ๆ

อ่านเจอ tweet เรื่อง under-engineering และ over-engineering
ในการพัฒนาระบบงานว่ามีอะไรบ้าง
จึงนำมาจดไว้กันลืมหน่อย
มาดูกันว่า เรานั้นทำกันอยู่ไหม ?

กลุ่มแรก Under-engineering

• ไม่มี CI/CD
• ทำ manual deploy
• ทำ manual testing
• ไม่มีการ review หรือ review ไม่บ่อย
• ขาดการทำการตรวจสอบต่าง ๆ ด้วย automation
• ทำ hard code
• ระบบงานเป็นแบบ tight coupling
• ทำการ copy and paste บ่อย ๆ

กลุ่มสอง Over-engineering

• เริ่มต้นมาก็จะ microservices หรือ microfrontend
• ทำการ optimized ในทุก ๆ จุด ตั้งแต่เริ่ม
• ต้อง 100% test coverage นะ สำหรับการทดสอบแบบอัตโนมัติ
• สร้างทุกอย่างตั้งแต่เริ่มต้น ทั้ง ๆ ที่มีของให้ใช้อยู่แล้ว (แต่ต้องเข้าใจก่อนใช้นะ)
• feature มั่วไปหมด ไร้ซึ่งเป้าหมาย มีให้เยอะ ๆ เข้าไว้

ใครมีเรื่องอะไรเพิ่มเติม บอกได้นะครับ

จากบทความเรื่อง How We Improved Application’s Resiliency by Uncovering Our Hidden Issues Using Chaos Testing
ทำการอธิบายเกี่ยวกับ Chaos Testing ว่าเป็นอย่างไร มีที่มาอย่างไร
มีข้อดีข้อเสียอะไรบ้าง
เหตุใดถึงต้องทำด้วย
ไม่ใช่ความรู้ใหม่ แต่ทำไม่เยอะเท่านั้นเอง

Chaos Testing เกิดจากระบบที่มีความซับซ้อน

ต้องทำงานร่วมกันหลาย ๆ ส่วนงาน (integration system)
ยิ่งแยก service ออกมาจำนวนมาก
หรือมี server จำนวนมากขึ้น
ก็ต้องทำให้มั่นใจว่าระบบจะสามารถทำงานได้
และสิ่งที่ต้องคิดไว้เสมอคือ เรื่องของ resiliency
เพื่อเพิ่มความเชื่อมั่นให้กับระบบ
ว่าเมื่อเกิดปัญหาขึ้นมาแล้วระบบยังคงทำงานได้ปกติ
หรือสามารถ recovery กลับมาได้เอง

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

บ่อยครั้งการทดสอบประเภทนี้ จะพบเจอได้บน production เท่านั้น
เพราะว่ามีการใช้งานที่หลายหลายกว่า และตรงกว่า
ดังนั้นจึงต้องระมัดระวัง และต้องมีระบบ monitoring และ observability ที่ดีด้วย

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

ในบทความสรุปเรื่อง Principles of chaos testing

ประกอบไปด้วย

• Identify a steady state
• Hypothesize that the system will hold its steady state
• Ensure minimal impact to your users ตรงนี้สำคัญมาก ๆ เป็นเป้าหมายหลักเลย
• Introduce chaos
• Monitor and repeat ขาดไม่ได้ !! ถ้าขาดทั้ง monitoring และ observability อย่าทำเด็ดขาด

ความยากของการทำ Chaos testing คือการทำความเข้าใจว่าทำไมต้องทำ !!

ดังนั้นจำเป็นต้องอธิบายให้เข้าใจ ว่าทำไม อะไร อย่างไร ต่อไป
หรือเราจำเป็นต้องทำไหม
กระทบต่อ business มากน้อยเพียงใด

Reference Websites

• Chaos Engineering on a Budget
• Step by step guide to chaos testing using Litmus Chaos toolkit