พื้นฐานระบบ & 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 กลับไปให้เบราว์เซอร์แสดงผล

FIG 1.1 — เส้นทาง request ในระบบ single server: DNS แปลงโดเมนเป็น IP จากนั้นเบราว์เซอร์คุยกับเซิร์ฟเวอร์ตรง ๆ

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):

FIG 1.2 — Cache-Aside: แอปเช็ก cache ก่อนเสมอ ถ้าไม่เจอ (miss) จึงอ่านจาก DB แล้วเก็บผลลัพธ์เข้า cache ไว้ตอบครั้งถัดไป

สิ่งที่ต้องตัดสินใจเสมอเมื่อใช้ 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)

FIG 1.3 — CDN: ผู้ใช้แต่ละภูมิภาคโหลดไฟล์จาก edge ที่ใกล้ที่สุด edge จะวิ่งกลับ origin เฉพาะตอนยังไม่มีสำเนา

🧭 มุมมองการออกแบบ — Cache กับ CDN คือหลักการเดียวกันคนละสเกล — "เก็บสำเนาไว้ใกล้จุดที่ใช้" Cache ลดระยะทางระหว่างแอปกับข้อมูล ส่วน CDN ลดระยะทางระหว่างผู้ใช้กับเนื้อหา เวลาออกแบบให้ถามเสมอว่า "ข้อมูลชิ้นนี้ ใครอ่านบ่อย และมันอยู่ใกล้คนอ่านพอหรือยัง"

✅ สรุปบทที่ 1 — เริ่มจากเครื่องเดียวเสมอ → แยก database ออกเป็นก้าวแรก → ใส่ cache (Redis) หน้า DB สำหรับข้อมูลอ่านบ่อย → ใช้ CDN กับ static content ทุกครั้งที่มีผู้ใช้กระจายตามภูมิศาสตร์ และจำไว้ว่าทุกชั้นที่เพิ่ม = ความซับซ้อนที่เพิ่ม ใส่เมื่อมีเหตุผลเท่านั้น

อ่านแบบเต็มเล่ม