พื้นฐานระบบ & Single Server Setup
Foundations · Web Server · Database · Cache · CDN · ▶ ในคลิป 0:02:13 – 0:06:20
ทุกระบบใหญ่ในโลก ไม่ว่าจะเป็น Netflix หรือ Shopee ล้วนเริ่มจากจุดเดียวกัน: เซิร์ฟเวอร์หนึ่งเครื่องที่รันทุกอย่าง การเข้าใจว่า request หนึ่งครั้งเดินทางอย่างไรในระบบที่เล็กที่สุด คือรากฐานของการออกแบบระบบที่ซับซ้อนทั้งหมด เพราะเมื่อระบบโต เราไม่ได้ "เปลี่ยน" สถาปัตยกรรม — เราแค่ แยกส่วนประกอบเดิมออกจากกัน ทีละชิ้น
1.1 เส้นทางของ Request หนึ่งครั้ง
เมื่อผู้ใช้พิมพ์ www.myapp.com ในเบราว์เซอร์ สิ่งที่เกิดขึ้นตามลำดับคือ:
- DNS Lookup — เบราว์เซอร์ถาม DNS server ว่าโดเมนนี้ชี้ไปที่ IP อะไร (เช่น
203.0.113.10) - HTTP Request — เบราว์เซอร์เปิด connection ไปที่ IP นั้น แล้วส่งคำขอ เช่น
GET /home - Server ประมวลผล — เว็บเซิร์ฟเวอร์รับคำขอ, รันโค้ดแอป, อ่าน/เขียนฐานข้อมูล
- Response กลับ — ส่ง HTML/JSON กลับไปให้เบราว์เซอร์แสดงผล
1.2 จุดแข็งและขีดจำกัดของ Single Server
ระบบเครื่องเดียวมีข้อดีที่มักถูกมองข้าม: deploy ง่าย, debug ง่าย, ไม่มี network ระหว่างส่วนประกอบ, ค่าใช้จ่ายต่ำ สำหรับ MVP หรือระบบภายในองค์กร นี่อาจเป็นคำตอบที่ถูกต้องที่สุดแล้ว แต่ขีดจำกัดจะมาถึงเมื่อ:
- ทรัพยากรชนกัน — ฐานข้อมูลกับโค้ดแอปแย่ง CPU/RAM/Disk I/O กันเอง
- สเกลแยกกันไม่ได้ — อยากเพิ่มกำลังเฉพาะฐานข้อมูล ก็ต้องอัปเกรดทั้งเครื่อง
- Single Point of Failure (SPOF) — เครื่องเดียวล่ม = ระบบล่มทั้งหมด (เจาะลึกในบทที่ 3)
ก้าวแรกของการขยายระบบจึงเป็นการ แยกฐานข้อมูลออกไปอยู่เครื่องของตัวเอง — web tier กับ data tier โตอิสระจากกันได้ทันที
1.3 Cache — ความเร็วที่ซื้อด้วยหน่วยความจำ
การอ่านจากฐานข้อมูลคือต้นทุนที่แพงที่สุดของ request ส่วนใหญ่ Cache คือชั้นเก็บข้อมูลในหน่วยความจำ (in-memory เช่น Redis, Memcached) ที่ตอบได้เร็วกว่าฐานข้อมูลหลายสิบเท่า เพราะไม่ต้องอ่านดิสก์และไม่ต้องประมวลผล query
รูปแบบที่ใช้บ่อยที่สุดคือ Cache-Aside (Lazy Loading):
สิ่งที่ต้องตัดสินใจเสมอเมื่อใช้ cache:
- TTL (Time-To-Live) — ข้อมูลใน cache อยู่ได้นานแค่ไหนก่อนหมดอายุ สั้นไป = cache แทบไม่ช่วย, นานไป = ผู้ใช้เห็นข้อมูลเก่า (stale data)
- Cache Invalidation — เมื่อข้อมูลต้นทางเปลี่ยน จะลบ/อัปเดต cache อย่างไร นี่คือหนึ่งใน "ปัญหายากที่สุดในวงการ" เพราะพลาดแล้วผู้ใช้เห็นข้อมูลผิด
- Eviction Policy — เมื่อหน่วยความจำเต็ม จะทิ้งตัวไหนก่อน ที่นิยมคือ LRU (Least Recently Used — ทิ้งตัวที่ไม่ถูกใช้นานที่สุด)
1.4 CDN — เอาเนื้อหาไปวางใกล้ผู้ใช้
CDN (Content Delivery Network) คือเครือข่ายเซิร์ฟเวอร์ที่กระจายอยู่ทั่วโลก (เรียกว่า edge server) ทำหน้าที่เก็บสำเนาของ static content — รูปภาพ, วิดีโอ, ไฟล์ JS/CSS — ไว้ใกล้ผู้ใช้ที่สุด ผู้ใช้ในกรุงเทพฯ โหลดรูปจาก edge ในสิงคโปร์ (~30ms) แทนที่จะวิ่งไปถึง origin server ที่อเมริกา (~250ms)
🧭 มุมมองการออกแบบ — Cache กับ CDN คือหลักการเดียวกันคนละสเกล — "เก็บสำเนาไว้ใกล้จุดที่ใช้" Cache ลดระยะทางระหว่างแอปกับข้อมูล ส่วน CDN ลดระยะทางระหว่างผู้ใช้กับเนื้อหา เวลาออกแบบให้ถามเสมอว่า "ข้อมูลชิ้นนี้ ใครอ่านบ่อย และมันอยู่ใกล้คนอ่านพอหรือยัง"
✅ สรุปบทที่ 1 — เริ่มจากเครื่องเดียวเสมอ → แยก database ออกเป็นก้าวแรก → ใส่ cache (Redis) หน้า DB สำหรับข้อมูลอ่านบ่อย → ใช้ CDN กับ static content ทุกครั้งที่มีผู้ใช้กระจายตามภูมิศาสตร์ และจำไว้ว่าทุกชั้นที่เพิ่ม = ความซับซ้อนที่เพิ่ม ใส่เมื่อมีเหตุผลเท่านั้น