ทำระบบซื้อสลากกินแบ่งรัฐบาลบนแอพเป๋าตังค์ยังไงให้ไม่ล่ม

และมั่นใจได้ยังไง ว่าระบบของเราไม่ down ทำ performance test สิ

กลับมาอีก 1 session จากงาน #Technologista : International Women’s Day Bangkok 2025 กับ session "Breaking the Limits: Performance Testing for Scale" โดยคุณแอม Thanyamon Nisamaneewong

.

หลาย ๆ คนคงเคยซื้อสลากกินแบ่งบนแอพเป๋าตังค์กันมาบ้างแล้วเนอะ เขามีการโปรโมตผ่านสื่อชั้นนำ ทำให้คนเข้ามาเยอะ มี traffic เยอะ ถ้าเรา handle ไม่ดี เกิดอะไรขึ้น โดนลูกค้าด่าพร้อมติด hashtag

.

คุณแอมมองว่า performance test ไม่ใช่แค่การเทส แต่เป็นกลยุทธ์ด้วย ระบบดราทำดีได้แค่ไหนนะ ใช้ NFPs (Non-Functional Requirement) ดูว่าระบบรองรับได้เท่าไหร่ เป็นการช่วยกำหนด ออกแบบ ทดสอบ ควบคุม ซึ่งมันก็เป็นกลยุทธ์ของธุรกิจ ระบบต้องรองรับให้ได้

.

⭐️ แล้วเริ่ม focus จากอะไร?

- peak users: business คิดว่าคนเข้ามาจำนานเท่าไหร่

- peak period: ระบบของเรามีระยะเวลาที่คนเข้ามาใช้มากสุด เป็นเวลาไหนบ้าง

.

⭐️ expected TPS

มาจาก peak users หารด้วย peak period (seconds) ใช้ในประเมินสถานการณ์ ดูว่าระบบเรารองรับ transaction เท่าไหร่ เป็นกี่ TPS (Transaction per Second) เป็นอย่างตํ่า ให้ระบบยังเสถียรอยู่

.

⭐️ NFRs Key:

- Feature Usage Ratio: ประเมิน traffic ในแต่ละจุด ว่าตรงไหนที่คนใช้เยอะ

- Spike rate: คำขอที่เพิ่มขึ้นอย่างกระทันหัน

- Response time: คนรอได้นานแค่ไหน

- Data Size: ขนาดของ data ที่เกิดขึ้นจริง

- Infrastructure Constraints: ข้อจำกัดการ scaling บน cloud ดังนั้นจะ test เพื่อตอบคำถามนี้ให้ได้

strategy เช่น ตรวจสอบ gateway ว่ารองรับ traffic ได้จริงไหม แต่ละจุดทดสอบ ไม่สามารถทดสอบในเงื่อนไขเดียวกันได้ เพราะมันมีหลายปัจจัยที่ส่งผล

.

⭐️ การทำ Performance Test มีหลายแบบ เช่น

- Load test: ให้ได้ผลตามต้องการ embedded result กับ visual user

- Stress test: ดูจุดที่ระบบล้มเหลวที่จุดไหน และมีการกู้คืนกลับมาไหม เกิดอะไรขึ้นใน service บ้าง เพื่อดูว่าระบบเราเกิดอะไร

- Soak Test: ใน 5 นาที ได้ embedded ที่โอเคแล้ว ถ้านานกว่านั้นล่ะ? เช่น คืน memory กลับคืนไปไม่มากพอ

- Volumn test: มีข้อมูลทื่เกิดขึ้นจริงบน production ล้าน record แต่ test ไม่ก็ record จะไม่ expect กับการขึ้น production จริง

- Spike test: เริ่มจาก user พุ่งขึ้นไปอย่างรวดเร็วในเวลาอันสั้น ระบบเรารองรับได้ไหม เช่น ซื้อบัตรคอนเสิร์ต

.

หลังจากทำ Performance Test ก็ทำ End-to-end Test ด้วย รวมทุกอย่างมา test ใหม่ เพื่อ make sure ว่าของขึ้น production แล้วระบบของเราทำงานได้จนจบ และถ้ามีเวลา อยากให้ test ทุกประเภทก่อนขึ้น production

.

⭐️ Investigate system และ scale

bottlenecks ใส่ user ไปแล้วยังไม่ไปไหน มีคอขวดอะไรบ้าง เช่น

- เข้าไปดู resource use ก่อน เช่น encryption data ลูกค้าก่อนเก็บ แล้วใช้ CPU เยอะ ดูว่าทำงานอะไรผิดพลาด, config 2 limit

- memory leak ทำงานแล้วไม่ดันของกลับไป

- database ดู query insight ว่าอันไหนไม่น่าถูกต้อง หรือใช้กราฟมากเกินไป การใส่ index เยอะอาจจะทำให้การ query ช้าได้

- network performance: หาทุกอันไม่เจอ ไม่มีอะไรเพิ่ม เคยไปเจอว่า bandwidth เต็ม เลยรับ request เพิ่มไม่ได้

.

เริ่ม scale ได้ เป็นเรื่องง่ายในยุคนี้ที่มีทั้ง cloud และ docker ทำให้เราสามารถประเมินสถานการณ์เป็นช่วง ๆ ไป และถ้าไม่มี test result ที่ครอบคลุม และ scale ไม่ถูกจุด ก็จะไม่สามารถ scale ให้ตรงจุดได้

.

⭐️ Scalability

แล้วเลือก scale แบบไหน ขึ้นอยู่กับ business และ system

- Vertical Scaling (Scaling up): เพิ่ม RAM และ CPU แต่เพิ่มในระดับนึงจะตัน

- Horizontal Scaling (Scaling out): พวก Microservices ต่าง ๆ

📌 ทำแล้วอย่าลืม scale down ลงมาด้วย เพราะมีผลต่อรายจ่าย ซึ่งจะลงมาเมื่อไหร่ก็พิจารณาจาก test อีกเช่นกัน

.

การ monitor ช่วยบอกเราได้ว่าเป็นไปตามสถานการณ์ที่เราวางไว้ไหม รู้ insight ของระบบ และวางแผนกันใหม่ ให้ดีขึ้นไปเรื่อย ๆ

.

⭐️ สรุป

Performance Testing ไม่ใช่แค่การ test แต่เป็น strategy ในการสร้างระบบที่ scale ได้ มีความยืนหยุ่น และพร้อมสำหรับทุก ๆ สิ่ง #siamstr