การ Scale บน AWS สำหรับผู้ใช้ 10 ล้านคนแรก

[PlAwAnSaI]

Transcript of AWS re:Invent 2024 - Scaling on AWS for the first 10 million users (ARC201) - YouTubeToTranscript.com

Read the full transcript of AWS re:Invent 2024 - Scaling on AWS for the first 10 million users (ARC201) by AWS Events available in 2 language(s).

youtubetotranscript.com

️ Scaling on AWS — EP.1
“เริ่มจากศูนย์ วางสถาปัตยกรรมให้ไปถึง 10 ล้านผู้ใช้”

วันนี้เริ่ม EP.1 ของ Series ที่ AWS Startup Team มาเล่าแบบจับมือทำ ว่าเราควรคิดเรื่อง Scale ตั้งแต่วันแรกยังไง ถ้าเป้าหมายคืออยากให้ App โตได้จนถึงระดับ 10 ล้านผู้ใช้

วิทยากรคือ
Christine – Senior Startup Solutions Architect
Skye – Manager จากทีม Startup Solutions Architect

สองคนนี้คุยกับ Startup มาเยอะมากก จนเห็น Pattern ชัด ๆ ว่า Startup ส่วนใหญ่ไม่ได้ติดเรื่องเขียน Code แต่ติดเรื่อง สถาปัตยกรรมที่ไม่พร้อม Scale แบบไว ๆ มากกว่า

เลยกลายเป็นสาเหตุให้ต้อง Refactor บ่อย หรือบางทีต้องรื้อสถาปัตยกรรมใหม่ทั้งชุดเมื่อผู้ใช้โตขึ้น ซึ่งเสียเวลาและเสียเงินมาก

EP. แรกนี้คือการปูพื้นเพื่อเข้าใจ Mindset ก่อนลงลึกใน Technique การ Scale ใน EP ถัด ๆ ไป

1. ก่อนออกแบบ ต้องตอบให้ได้ก่อนว่า “Application” ของเราคืออะไร?

Christine เริ่มต้นด้วยการตั้งคำถามง่าย ๆ แต่สำคัญมากว่า

จริง ๆ แล้ว “Application” ของเราหมายถึงอะไร?

เพราะคำนิยามนี้มันกว้างมาก

• บางบริษัทใหญ่ ๆ App = แค่ 1 Feature ใน Ecosystem ขนาดใหญ่
• บาง Team ใช้คำว่า App = ระบบหลังบ้าน + ระบบหน้าบ้าน + API + Mobile + Service
• Startup บางแห่ง = App คือ "ตัวบริษัททั้งบริษัท"

ดังนั้น เวลาเราคุยเรื่อง “Scale App” ถ้าเราไม่ Clear ว่า “App ของเรา” คือหน้าตาแบบไหน เราจะคุยกันคนละแบบทันที

เพื่อให้ทุกคนเห็นภาพตรงกัน Christine เลยตั้งสมมติฐานว่า
Session นี้จะใช้ 3-tier Web Application เป็น Model กลาง ได้แก่

1) Frontend

UI ที่ผู้ใช้เห็น เช่น Web / Mobile / SPA

2) Backend

Business Logic ทั้งหมด
API / Authentication / Function ต่าง ๆ

3) Data Store

ส่วนเก็บข้อมูล เช่น Database, Cache, Storage

แม้ App จริง ๆ ของแต่ละคนจะต่างกัน แต่ Pattern 3-tier นี้ใช้เป็นกรอบอธิบายการ Scale ได้ดีมาก เพราะเป็นพื้นฐานของเกือบทุก Project

2. Landscape ตอนนี้เปลี่ยนเร็วแบบไม่ปรานีใคร

Christine ย้ำว่า สิ่งที่เราสร้างวันนี้ จะไม่เหมือนของเมื่อ 5 ปีก่อนแล้ว เพราะ Technology มันเปลี่ยนเร็วมากกก

Frontend

จาก HTML+PHP → กลายเป็น JavaScript Framework เต็มรูปแบบ
React, Next.js, Vue, Nuxt, Astro ฯลฯ

Full-stack Framework

มีตัวช่วย Build แบบ End-to-end
เร็วขึ้น
Deploy ง่ายขึ้น
หรือแยกเป็น Microservices ตั้งแต่แรกแบบ Effortless

Cloud Mindset

Startup ยุคนี้ใช้ Managed Services เยอะมาก เพราะมันลดภาระ DevOps
ลดเวลา Setup
ลดความเสี่ยงจาก Human Error
และเพิ่มความเร็วในการออก Feature ได้เต็มที่

Viral Growth

ยุค Social ทำให้ “Load พุ่งในชั่วโมงเดียว” เป็นเรื่องปกติ
เมื่อก่อนเติบโตแบบเป็นสัปดาห์
ตอนนี้ Clip เดียวพา Load พุ่งหลายล้าน Request ได้ทันที

เพราะงี้คำว่า “Scale ง่าย ๆ ไว้ก่อน” ไม่ใช่เรื่องไกลตัวอีกต่อไป แต่เป็น Survival Skill ของทุก Team

3. Mindset สำคัญที่สุด: “ระบบ Version แรก ไม่ใช่ระบบ Version สุดท้าย”

ประโยคนี้ดีมากและจริงมาก

No architecture is designed for hyper-scale on day one.

ถ้าเริ่มต้นโดยพยายามออกแบบทุกอย่างให้รองรับ 10 ล้านผู้ใช้ตั้งแต่วันแรก คุณจะไม่เสร็จอะไรเลย
เพราะคุณจะเสียเวลาคิดสถาปัตยกรรมมากกว่าเปิด Product ให้ User ใช้จริง

AWS แนะนำ Mindset ว่า

Build → Measure → Learn → Improve

คือ

1. Build: สร้างแบบ Simple ก่อน
2. Measure: ดูว่า Bottleneck อยู่ตรงไหน
3. Learn: วิเคราะห์ว่าเกิดจากอะไร
4. Improve: ปรับสถาปัตยกรรมเฉพาะจุด

ข้อดีคือ

• เราปรับตามผู้ใช้จริง ไม่ใช่ตามจินตนาการ
• ทำให้ไม่เสียเวลาไปกับการ Optimize สิ่งที่ยังไม่เกิด
• ระบบ Evolve ตามธุรกิจได้อย่างเป็นธรรมชาติ

4. Day 1 – ผู้ใช้มีไม่กี่คน แต่ต้องออกแบบให้ “โตได้”

Christine สมมติว่า Day 1

• มีแค่ Founder ใช้ 2-3 คน
• มี Beta Tester นิดหน่อย
  Load ไม่เท่าไหร่ แต่ สิ่งสำคัญคือโครงสร้างต้องขยายได้

สิ่งที่ Startup มักทำผิดคือ เอา Frontend + Backend + Database ยัดลง Server เดียว (เพราะเหมือนจะง่ายและเร็ว)

แต่พอ Load ขึ้นปุ๊บ ทุกอย่างคอขวดทันที- ต้องย้าย ต้องแยก ต้องรื้อ ต้องปวดหัว

AWS เลยแนะนำว่าอย่างน้อยที่สุด

แยก Frontend ออกจาก Backend

แม้ผู้ใช้จะมีน้อยก็ตาม
เพราะมันเป็น Foundation ให้ Scale ได้ในอนาคต

5. วิธีที่คน "สมัยก่อน" เริ่มกัน

Christine แอบเล่าว่าเมื่อก่อน Team ส่วนใหญ่เริ่มจาก

• Run Web Server บน EC2
• ใส่ Auto Scaling Group
• ทำ Load Balancer
• ใช้ Shared Storage
• Database แยกอยู่ข้างนอก

มันใช้งานได้จริง แต่ค่อนข้าง Manual และพอมี Load เยอะ ๆ จะเจอปัญหา Scaling หรือ Ops เยอะมาก

EP ต่อ ๆ ไป Christine จะเล่าให้ฟังว่าปัจจุบันมีอะไรที่ดีกว่า ง่ายกว่า และยืดหยุ่นกว่า

สรุป EP.1:

EP. นี้ยังไม่ลงลึกเรื่อง Scale แต่ปูพื้นด้วยความคิดสำคัญมาก ๆ เสียก่อนว่า:

1. ก่อนสร้าง ต้องนิยามให้ชัดว่า “App คืออะไร” เพื่อไม่ให้คุยกันคนละแบบ

2. Landscape วันนี้เปลี่ยนเร็วมาก ต้องเลือกเครื่องมือที่เหมาะกับยุคนี้ ไม่ใช่ของเมื่อ 10 ปีก่อน

3. Version แรก ไม่ใช่ Version สุดท้าย ต้อง Iterate เสมอ

4. แม้มี User น้อย ก็ต้องเริ่มด้วยการ “แยกส่วน” เพื่อให้โตได้โดยไม่ต้องรื้อระบบทีหลัง

---

Scaling on AWS – EP.2: จากการเร่ง Web ให้ไวขึ้น → สู่การเลือก Backend ที่ไม่ทำให้ระบบพังตอนโต

พอเริ่มทำระบบสักพัก ทุก Team จะเจอคำถามเดิมเสมอว่า “Web ทำไม Load ช้าลง?”

จริง ๆ แล้วมันไม่ใช่เพราะ Code แย่อย่างเดียว แต่เพราะผู้ใช้เริ่มเยอะขึ้น File เริ่มใหญ่ขึ้น และปริมาณ Asset (รูป / JS / CSS) ที่ต้อง Load เริ่มบวมขึ้นเรื่อย ๆ

สิ่งที่แก้ได้ง่ายที่สุด และให้ผลชัดที่สุดคือ ใช้ CDN (เช่น CloudFront)
CDN คืองานง่าย ๆ ที่หลาย Startup ไม่รู้ว่าช่วยได้เยอะมาก เพราะมัน Cache File ไว้ใกล้ผู้ใช้ ทำให้เปิด Web เร็วกว่าเดิมหลายเท่าโดยไม่ต้องเพิ่มเครื่อง ไม่ต้องคิดโครงสร้างอะไรเลย

แต่โลก Frontend มันไปไกลกว่านั้นแล้ว

ทุกวันนี้ Framework พัฒนาเร็วมาก ทั้ง React, Next.js, Remix, Astro ฯลฯ
ปัญหาจริง ๆ สำหรับ Team Dev ไม่ใช่แค่ “Web Load ช้า” แต่คือ

“ฉันอยากพัฒนาให้เร็ว และ Deploy ให้เร็ว โดยไม่ปวดหัวกับ Infrastructure”

เพราะถ้ายังใช้ S3 + CloudFront แบบเดิม ๆ
– Dev ต้องจัด Build Pipeline เอง
– ต้อง Config เองทุกอย่าง
– อยาก Deploy แยก Branch ก็ไม่ได้
– Rollback ยาก
– Preview ไม่สะดวก
– ไม่มีการ Integrate ลึกกับ Framework สมัยใหม่

ตอนนี้โลกมันเลยเปลี่ยนไปสู่ “Purpose-built Frontend Hosting” หรือบริการ Host Web ที่ออกแบบมาเพื่อ Frontend Framework โดยเฉพาะ

และนี่คือจุดที่ AWS Amplify Hosting เข้ามาแก้ปัญหาแบบเต็มรูปแบบ

Amplify Hosting — Host Web แบบ Serverless ที่ Dev ชอบมาก

Amplify เป็นบริการที่ Dev เขียน Code อย่างเดียว แล้วโยง GitHub ส่วนเรื่อง Deploy–Build–Scale ทั้งหมด AWS จัดการให้แบบอัตโนมัติ

จุดเด่นที่ทำให้หลาย Startup เลือก Amplify

✔ ไม่ต้องดูแล Infrastructure
✔ Build อัตโนมัติทุกครั้งที่ Push Code
✔ มี Atomic Deployment (พัง = Rollback เอง)
✔ มี Branch Deployment (สร้าง URL Preview ทุก Branch ได้)
✔ Integrate ลึกกับ Next.js, React, SSG ทุกตัว
✔ ไม่ต้องผูก S3 + CloudFront เองให้ยุ่งยาก
✔ ไม่ต้องมี DevOps เต็ม Team ตอนเริ่มต้น
✔ Scale อัตโนมัติทันทีเวลา Web โต

ถ้าทำ Web แบบ Next.js + SSR จะรู้เลยว่า ถ้า Host บน S3 ทำแทบไม่ได้ แต่ Amplify ทำได้ครบหมด ทั้ง SSR, ISR, Static Export, Image Optimization

นี่คือเหตุผลว่าทำไม Early-stage Startup ใช้ Amplify เยอะมาก

Team เล็ก 3–5 คน ไม่อยากเสียเวลาทำ Infra อยาก Focus ที่ Product + Go-to-market ก่อน Amplify ตอบโจทย์เลยเต็ม ๆ

Amplify Hosting รองรับ 3 ประเภท App หลัก:
1) Client-Side Rendered (CSR) เช่น React SPA ที่ Load Code ทั้งหมดไป Render บน Browser เหมาะกับ Web ทั่วไปที่ไม่ต้อง SEO หนัก
2) Server-Side Rendered (SSR) เช่น Next.js ที่ Render HTML บน Server ก่อนส่งให้ผู้ใช้ เหมาะกับ Web ที่ต้อง SEO, ใช้ Dynamic Content, ต้อง Load เร็ว
3) Static Site Generator (SSG) เช่น Astro, Hugo หรือ Next.js Static Export เหมาะกับ Web ที่เป็น Content เยอะ ๆ แต่คงที่ > เร็วที่สุด + ค่าใช้จ่ายต่ำที่สุด

ไม่ว่าทำ Web แบบไหน Amplify ก็รองรับทั้งหมดแบบ Out-of-the-box

แล้ว Backend ล่ะ? ควรเลือกอะไรให้ดีตั้งแต่วันแรก?

พอคุยเรื่อง Frontend แล้ว สิ่งต่อไปที่ทุก Team ถาม คือ “Backend จะใช้ EC2, Container หรือ Serverless?”

เลือกผิดตั้งแต่ต้น แก้ทีหลังเหนื่อยมาก, ค่าใช้จ่ายบาน, Scale ไม่ได้, Load ไม่ Balance, Maintain ยุ่งกว่าเดิม 10 เท่า

 

[PlAwAnSaI]

ตัวเลือกของ AWS มี 3 กลุ่มใหญ่:

1) EC2 — เริ่มง่าย แต่อย่าอยู่นาน หลาย Team เริ่มด้วย EC2 เพราะ

– ง่าย
– ติดตั้งอะไรก็ได้
– คุมทุกอย่างได้เอง

แต่ปัญหามันจะมาเมื่อเริ่มโต:
Redundancy ยากมาก
ถ้าเอาทุกอย่างไป Run ใน Instance เดียว = ไข่ทุกใบในตะกร้าเดียว
ถ้าดึง CPU 100% = ทั้งระบบล่มพร้อมกัน
Database กับ Backend แยกกัน Scale ไม่ได้
Upgrade แล้วต้องเปลี่ยน Instance Size (Vertical Scaling)
Downtime เกิดง่าย
ต้อง Patch OS เอง

เหมาะสำหรับ MVP / PoC แต่ไม่เหมาะสำหรับ Scale

2) Containers — ECS / EKS / Fargate เหมาะถ้า Backend มีหลาย Service หรือมีงาน Background, Scheduled Job, Worker Queue ฯลฯ

✔ Scale แต่ละ Service แยกกัน
✔ จัดระเบียบ Microservices ได้ดี
✔ ใช้ Fargate = ไม่ต้องจัดการ Node

ใช้ได้ทั้ง Project เล็ก–ใหญ่ โตแบบมั่นคง

3) Serverless – AWS Lambda เหมาะกับงานแบบ:

– API ที่ Load แต่ละช่วงไม่เท่ากัน
– Event-driven
– Webhook
– Image Processing
– IoT
– Backend ที่ต้อง Scale ทันทีภายในไม่กี่วินาที

ข้อดีคือ:
✔ ไม่มีเครื่องให้ดูแลเลย
✔ จ่ายตามใช้จริง
✔ Scale ได้ทันทีแบบไร้ Limit
✔ Integrate ลึกกับ API Gateway, SQS, Dynamo, EventBridge

สำหรับ Early-stage Startup ที่อยากไปเร็ว–ประหยัด–Scale ได้ Lambda คือของที่ “คุ้มสุด”

คำแนะนำจาก AWS แบบชัดที่สุด

ใช้ Managed Compute + Managed Database เพราะมันช่วยให้คุณ:
– หมดปัญหา Redundancy
– Auto Scale ได้ตั้งแต่วันแรก
– ไม่ต้องทำ Patching
– ไม่ต้องดูแล OS
– ลด Technical Debt ในอนาคตอย่างมหาศาล

ให้ Team Dev เอาเวลาไปลงกับ Product และ Customer ไม่ใช่ Infra
3,305x2