ทุกๆ คนต่างอยากจะ scale ระบบ website/app ให้รองรับคนได้จำนวนมหาศาล อยากใช้เครื่องมือดังๆ เท่ห์ๆ แต่คุณจะเริ่มวางแผนยังไงให้อนาคตก็สามารถ scale ได้ง่ายโดยใช้ cost ให้น้อยที่สุดและใช้เวลาสร้างให้เร็วที่สุดในวันแรกที่คุณสร้าง? session นี้จะสอนให้คุณเตรียมระบบให้พร้อมด้วยค่าใช้จ่ายที่ถูกที่สุดแม้ว่าคุณจะยังไม่รู้ว่า web ของคุณจะมีคนเข้าแค่ 1 คนหรืออาจจะเข้ามากถึง 1 ล้านคนก็ตาม คุณควรจะใช้ Cloud Server หรือ Physical Server ดี? คุณควรจะศึกษา Cloud Server หรือ Kubernates ไหม? ทำอย่างไรจึงจะไม่ Over Design และออกแบบระบบเผื่อมากเกินไปจนค่าใช้จ่ายเกินตัวและใช้เวลาเตรียมตัวนานเกินไปจนไม่ตอบโจทย์ภาคธุรกิจ? session นี้มีคำตอบ

1. How to maintain the cost and scale up plan
from 1 user to 1 million users
Paiboon Panusbordee
paiboon@codekit.co
facebook.com/paiboonpa
1

2. ประวัติผู้สอน
• Co-founder, CTO, บริษัท เลเวลอัพ สตูดิโอ จํากัด 7 ปี
• Co-founder, CTO, บริษัท เลเวลอัพพลัส จํากัด 4 ปี
• ได้รับเงินลงทุนจากบริษัท แกแล็คซี่ เวนเจอร์ส จํากัด
• Co-founder, CTO, บริษัท โค้ดคิท อินโนเวชั่น จํากัด
• IT Consultant / Agile Coach บริษัท Any I
• กรรมการสมาคมโปรแกรมเมอร์ไทย
• Program Director Software Park Thailand Code Camp
2

3. What have I done?
• Cybermon - Facebook Game 300,000 Monthly active users 2,000,000
Installed
• Pokdeng - Facebook Game + Android + iOS 500,000 Monthly active users
4,000,000 Downloads and Installed
Created on : 2012

6. Peak Time
Daily Active User
100,000 คน
Con-Current user (CCU)
3,500 คนใช้งานพร้อมกัน

7. Session นี้จะพาคุณไปไหน?
• การเดินทางจากการ start project ใหม่ที่ 1 user จนโตไปถึง 1 million users
• Business + Cost control 50%, technical 50%
• โฟกัสที่ค่าใช้จ่าย และในแต่ละ stage ต้องเตรียมตัวอย่างไร
• สไลด์นี้ถูกเขียนในรูปแบบ Startup Mindset แต่ Corporate ก็สามารถประยุกต์ใช้กับ
โปรเจคใหม่ได้เช่นกัน
• กรุณาทําเฉพาะสิ่งที่จําเป็นต้องทํา ไม่ใช่ทั้งหมด!!

8. Technology underline
Stud

9. Lua call Redis example
9

10. Note
• Haproxy, stud ปัจจุบันสามารถใช้ nginx แทนได้ทั้งหมด
• PHP ปัจจุบันไม่แนะนําให้ใช้ start project ใหม่อีกแล้ว
• หัวใจของการ Scale และป้องกันปัญหา Race Condition อยู่ที่ Redis / Lua

11. Physical Server (On-Premise)
• Dell R210 E3-1240v2, 3.4 Ghz
Ram 32 GB
SSD 480 GB x2
HDD 1TB x2
• ใช้เหมือนกันทั้งหมด 3 เครื่อง
• ต้นทุนค่าเครื่อง (ปี 2012) 185,000 บาท
• ค่า Colocation 3u เป็นเงินเดือนละ 9,000 บาท

12. Server Architecture
PHP
Codeignitor
Stud
(TLS/SSL )
Haproxy
(Load Balancer)
Request
Redis
(Main)
MySQL
Master
MongoDB
Master
Redis
(Session)
Redis
(Other Data)
Redis
(Room)
MySQL
Slave
MongoDB
Slave
Node.JS
Socket.IO
Socket.IO
ClusterNode.JS
Socket.IO
Node.JS
Socket.IO
Node.JS
Socket.IO
Node.JS
Socket.IO
Node.JS
Socket.IO

13. Things to consider in each level
• Price per month
• Skilled DevOps / Infrastructure person
• Requirement Management
• Maintenance cost
• Time to finish

14. Stage
• Product development Stage
• Initial launch Stage
• Scale Stage

15. Product Development Stage

16. Situation
• ทีมเล็ก
• เงินน้อย
• Requirement / Business Logic เปลี่ยนแปลงตลอด
• ไม่รู้ว่าลูกค้าจะชอบ Product ของเราไหม
• ไม่รู้ว่า Product จะอยู่ได้อีกนานแค่ไหน
• ไม่รู้ว่า Feature ไหนคนชอบใช้มากที่สุด
• ไม่รู้ว่าจะมี user กี่คนเข้ามาใช้งานเว็บหรือแอพเราพร้อมก้น

17. Don’t
• ซื้อ hardware เทพ
• Setup kubernates / Cloud cluster
• Setup Load test ทุกอย่าง ทุกหน้า
• Optimize ทุกอย่างทุกหน้า
• Setup automation system ให้ทุกระบบ
• Design Microservice

18. Do
• ลองถามฝ่าย business หรือ marketing team ว่าจะมีลูกค้าในวันเปิดตัวประมาณกี่คน
• โดยทั่วไปมักจะเป็นการทดสอบแค่วงใน หรือกลุ่มเล็กๆ (ยังไม่ลงโฆษณา)
• ผู้ใช้น้อยมาก
• Setup Analytic Tools
• Setup Monitoring System
• Deploy ลง cloud ราคาถูกเช่น Digital ocean/Vultr
• Deploy ลง AWS/Google Cloud/Azure ถ้ามีเงินเยอะ
• Log data การใช้งานของ User

19. Lesson #1
อย่า over design เผื่อในสิ่งที่คุณยังไม่
ได้ใช้งานในขณะนั้น!!

20. Lesson #2
Monitoring คือกุญแจสู่การ scale!

21. Initial launch Stage

22. Situation
• เริ่มมีข้อมูลจริงจาก analytic และ monitoring system
• Requirement / Business Logic เปลี่ยนน้อยลง
• ไม่รู้ว่า Product จะอยู่ได้อีกนานแค่ไหน
• รู้ว่าลูกค้าอาจจะชอบ Product ของเรา
• รู้ว่า Feature ไหนคนชอบใช้มากที่สุด
• รู้ปริมาณ user ตั้งต้น
• มี growth rate ที่คาดการณ์ไม่ได้
• สิ่งสําคัญที่สุดคือการ scale ให้ตรงกับ growth rate ห้ามทึกทักไปเองเพราะมันเท่ห์!!

23. Don’t
• ซื้อ hardware เทพ
• Optimize ทุกอย่าง ทุกหน้า
• Setup automation system ให้ทุกระบบ

24. Do
• ดูข้อมูล user จาก analytic และตัดสินใจว่าจะทําต่อ หรือจะปิดตัวเพื่อ Cut Loss
• ตัด feature ที่ไม่ดังทิ้ง,
เพิ่ม feature ใหม่ที่ลูกค้าน่าจะอยากได้ ใช้ข้อมูลจากการใช้งานจริงที่ผ่านมา
• ถ้าเล็งเห็นว่า growth rate เริ่มคาดการณ์ได้ และพุ่งไม่หยุด ให้ setup kubernates /
cloud cluster โฟกัสที่ feature ที่ดังที่สุด
• ถ้า I/O หรืออัตราการใช้อ่าน/เขียน disk สูงมาก ให้ setup database cluster

25. Do (2)
• Setup Load test บน staged environment เพื่อทดสอบ Web Server
Cluster/Database Cluster ตัวใหม่ที่สร้างขึ้น
• Optimize feature ที่ใช้งานมากที่สุดเพื่อลด workload และค่าใช้จ่ายในอนาคต
(ถ้าคุณมีเวลา)
• Setup automation ให้กับ workflow ที่ใช้งานบ่อยๆ และเริ่มไม่มีการเปลี่ยนแปลง
• Setup auto scale / fail over system
• ถ้าทุกอย่างไปได้สวยให้ของบเพิ่มและขอขยายทีมทําระบบเพิ่มจากฝ่าย business หรือหาทาง
Raise Fund

26. Lesson #3
Cluster มักมี maintenance cost
มากกว่าปกติทั้งในแง่ของคนและเวลา

27. Lesson #4
อย่า Optimize ทุกอย่าง
จง optimize เฉพาะสิ่งที่
เห็นผลชัดเจนที่สุดเท่านั้น!!

28. Scale Stage

29. Situation
• มี report เต็มไปหมด
• Requirement / Business Logic ไม่เปลี่ยนแล้ว
• Growth rate เติบโตตลอด คาดเดาได้ง่ายมาก
• แทบไม่มีสิ่ง Unknown อีกแล้ว
• Product นี้ดังแล้ว!
• Feature ที่ดังที่สุดทําให้คุณเสียค่าใช้จ่ายไปจํานวนมหาศาล
• ทีมเริ่มใหญ่ขึ้น

30. Don’t
• ไม่มี

31. Do
• Optimize feature ที่ใช้บ่อยที่สุดเพื่อลด cost (คุ้มค่าที่จะทํามาก)
• ถ้าการใช้งานแทบไม่มีการพุ่งของ Traffic สูงกว่าปกติเลย หรือพุ่งน้อยมาก ให้พิจารณาย้าย
Server ไปเป็น On Premise เพื่อประหยัดงบประมาณ

32. Physical Server Price (Servermania)

33. Physical Server Price (Servermania)

34. Physical Server Dual Processors

35. • CPU (EC2 t2.2xlarge) 1 เดือน = $267.26
• EBS (480 GB IOPS SSD (io1)) 1 เดือน = $60
Cloud Price

36. • AWS Price - 8 vCPU Ram 32GB, SSD 480 GB, ไม่รวมค่า bandwidth
$327.26
• Physical Price - 4 Core 8 Thread, Ram 32 GB, SSD 480 GB, 20TB Bandwidth
$109
• AWS Price - 16 vCPU Ram 64GB, SSD 300 GB
$650
• Physical Price - 8 Core 16 Thread, Ram 64 GB, SSD 480 GB, 20TB Bandwidth
$215
Compare Cloud vs Physical per month

37. Management Choice
• ใช้ cloud เพื่อลดงาน system admin การสร้างเครื่องตามสเปคต่างๆ ถ้าทีมของคุณไม่มีคน
เก่งทาง Infrastucture มากนัก
• จ้าง Outsource Pro-Infrastructure เป็นบุคคลหรือบริษัทมาช่วยดูระบบให้แทนเพื่อลด
ความยุ่งยากของการดูแลระบบ (pantip.com ใช้ว ิธีนี้)
• คํานวณค่าเช่า หรือค่าซื้อเครื่องรวมค่าจ้างบุคคลหรือบริษัทช่วยดูแลรวมกับค่า
maintenance อื่นๆ เทียบกับค่าใช้ cloud ทั้งหมดว่าแบบใดราคาถูกกว่า คุ้มค่า migrate
หรือไม่
• หาก server มีการใช้งานหนักมากๆ ตลอดเวลา และไม่มี Traffic พุ่งขึ้นๆ ลงๆ ไม่แน่นอน
On-premise มักจะมีราคาถูกกว่าในระยะยาว
• จะตัดสินใจแบบไหนก็แล้วแต่คุณ!

38. Monitoring

39. Why monitoring?
• อีเมล์/sms แจ้งเตือน cpu, ram, I/O เมื่อเกินค่า threshold ที่กําหนด
• ตรวจสอบได้ง่ายว่าเกิดอะไรขึ้นในอดีตพร้อมหาทางแก้ไขหลังจากที่ server กลับคืนเป็นปกติ
แล้วหลังจากล่ม
• ค้นหาว่า code หรือ database ส่วนไหนช้าได้โดยอ้างอิงจากข้อมูลการใช้งานจร ิงเพื่อให้ไม่
ต้อง optimize ในส่วนที่ไม่มีใครใช้
• ในบางภาษาคุณจะรู้ด้วยว่า query ช้าที่ไหน Function อะไรช้า รวมไปถึง function ย่อยๆ
ทั้งหมด

40. How does the monitoring system help you
to scale?
• มีข้อมูลจริงเพื่อใช้คาดการณ์การประเมิน growth rate อย่างชัดเจน
• ข้อมูลเพื่อประเมินว่าระบบไหนมี workload สูงสุด
• ข้อมูลว่ามีการใช้งาน I/O read/write มากน้อยเพียงใด ที่เครื่องไหน เวลาเท่าไร
• ข้อมูลเพื่อนําไป design Micro Service

41. อย่าทําทั้งหมด
ให้ทําเฉพาะสิ่งที่ข้อมูลบอกคุณ
ว่าต้องทําเท่านั้น!!

42. Monitoring option
• Open source - Grafana + Prometheus
• Cloud service - New Relic

43. New Relic Application Monitoring

44. New Relic - Transaction

45. Database Monitoring

46. หาขอขวดให้เจอ!

47. Page inspection

48. สิ่งที่คุณต้องรู้
• Scale Database ยากกว่า scale web server เสมอ!
• อย่าใช้ database ใน Block Storage, GlusterFS, Ephemeral storage ของ Cloud
• สําหรับ database การ scale write ยากกว่าการ scale read เสมอ
• SSD คือสิ่งจําเป็นสําหรับ database เร็วกว่า HDD มากกว่า 10 เท่า ไม่มีเหตุผลจะไม่ใช้อีกแล้ว
• ค่าใช้จ่ายที่แพงที่สุดของ cloud คือค่า Bandwidth
• ประสิทธิภาพการทํางานของ database บน cloud มักด้อยกว่า on-premise เสมอ
• Cloud เหมาะมากสําหรับงานที่มี workload ที่คาดการณ์ไม่ได้ เปลี่ยนแปลงบ่อย แต่ไร้
ประโยชน์หากเป็น workload ที่คาดการณ์ได้และทํางานหนักตลอดเวลา

49. Q & A
TrainingSlide