ทำไมเราต้องใช้ Redis? เจาะลึกพื้นฐานแคชและสถาปัตยกรรม
เรียนรู้พื้นฐาน CPU, RAM, SSD, ปัญหาการจัดการแคชในหน่วยความจำเครื่อง และเหตุผลที่ระบบเซิร์ฟเวอร์ยุคใหม่ต้องพึ่งพา Redis
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- CPU เป็นตัวประมวลผลคำสั่ง RAM เป็นหน่วยความจำชั่วคราว และ SSD เป็นที่เก็บข้อมูลถาวร
- แฮชแม็ปในเครื่องทำงานได้ดีบนแลปท็อป แต่พังเมื่อเจอการทำงานแบบคอนเคอร์เรนซีในระบบโปรดักชัน
- การเขียนแคชเองต้องจัดการปัญหาเรื่อง Mutex, การลบข้อมูลเก่า (LRU) และหมดอายุ (TTL) ซึ่งซับซ้อนมาก
- การใช้ RAM แยกกันในแต่ละเซิร์ฟเวอร์ทำให้เกิดปัญหาแคชไม่ตรงกันและข้อมูลซ้ำซ้อน
การทำความเข้าใจเรื่องระบบแคช (Caching) จำเป็นต้องเริ่มจากสถาปัตยกรรมพื้นฐานของคอมพิวเตอร์อย่าง CPU (Central Processing Unit) ซึ่งเปรียบเสมือนมันสมองในการประมวลผลคำสั่งและคำนวณโค้ด ขณะที่ RAM (Random Access Memory) คือหน่วยความจำชั่วคราวความเร็วสูงที่โปรแกรมใช้งานอยู่ตอนนี้ เช่น ตัวแปรและอาร์เรย์ในโค้ด ส่วน SSD (Solid State Drive) เป็นพื้นที่จัดเก็บถาวรไม่มีชิ้นส่วนเคลื่อนไหวสำหรับเก็บไฟล์และฐานข้อมูล โดยมีความแตกต่างสำคัญคือ RAM เป็นแบบ Volatile (ข้อมูลหายเมื่อปิดเครื่อง) ส่วน SSD เป็นแบบ Persistent (ข้อมูลคงอยู่ตลอดไป)
ในแง่ของความหน่วงเวลา (Latency) แต่ละส่วนใช้เวลาแตกต่างกันอย่างสิ้นเชิง เช่น การอ่านจาก RAM ใช้เวลาประมาณ 100 นาโนวินาที, การอ่านจาก SSD ใช้เวลาประมาณ 100 ไมโครวินาที, การเรียกเครือข่ายไปยัง Redis ใช้เวลาประมาณ 0.5 ถึง 1 มิลลิวินาที และการคิวรีฐานข้อมูลใช้เวลาตั้งแต่ 5 ถึง 50 มิลลิวินาที โดยกำหนดให้ 1 มิลลิวินาทีเท่ากับ 1,000 ไมโครวินาทีหรือ 1,000,000 นาโนวินาที ซึ่งอุปกรณ์อย่างแลปท็อป เซิร์ฟเวอร์ EC2 และฐานข้อมูลล้วนมีส่วนประกอบเหล่านี้ทั้งสิ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อพัฒนาโปรแกรมบนแลปท็อป การใช้แฮชแม็ป (Hash map) หรือดิกชันนารีเพื่อเก็บข้อมูลคีย์-แวลูมักไม่มีปัญหา แต่ระบบโปรดักชันมีความซับซ้อนกว่ามากเนื่องจากคอนเคอร์เรนซี (Concurrency) หรือการมีหลายงานทำงานพร้อมกัน เช่น ผู้ใช้ 100 คนส่งคำขอเข้ามาในเสี้ยววินาทีเดียวกัน ระบบเซิร์ฟเวอร์จะใช้เธรด (Thread) หรือโกรูทีน (Goroutine ในภาษา Go) หลายตัวจัดการคำขอเหล่านั้น ซึ่งอาจนำไปสู่ปัญหาเรซคอนดิชัน (Race condition) หรือข้อผิดพลาดเมื่อหลายเธรดเข้าถึงข้อมูลชุดเดียวกันพร้อมกัน
ภาษา Go จะเกิดข้อผิดพลาดร้ายแรงและเซิร์ฟเวอร์ล่มทันทีหากมีการเขียนข้อมูลลงในแม็ปพร้อมกันจากหลายโกรูทีน การแก้ปัญหาต้องใช้ Mutex (Mutual Exclusion lock) เพื่อจำกัดให้เข้าถึงโค้ดทีละหนึ่งโกรูทีน นอกจากนี้ แม็ปทั่วไปไม่มีการจำกัดขนาด ทำให้หน่วยความจำโตขึ้นเรื่อย ๆ จนเกิดปัญหา OOM (Out Of Memory) ที่ระบบปฏิบัติการจะฆ่ากระบวนการทำงานทิ้ง หรือเกิดภาวะหน่วยความจำรั่วไหล (Memory leak)
"A fast storage layer that keeps copies of frequently used data so you don't have to fetch it from the slow source again."
พื้นฐานระบบแคช
เพื่อรับมือกับปัญหาหน่วยความจำล้น ระบบแคชจึงต้องมีกลไกการคัดทิ้งข้อมูลเก่า (Eviction) เช่น LRU (Least Recently Used) ที่จะลบทิ้งรายการที่ไม่ได้ใช้งานนานที่สุด รวมถึงการตั้งค่า TTL (Time To Live) เพื่อกำหนดเวลาหมดอายุของคีย์อัตโนมัติ ป้องกันปัญหาข้อมูลเก่าล้าสมัย (Stale data) การสร้างระบบแคชขึ้นมาใช้เองโดยต้องประกอบด้วย Mutex, ระบบ LRU และ TTL นั้นยากและเสี่ยงต่อบั๊กสูงมาก
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
คำถามถัดมาคือทำไมจึงไม่ใช้ RAM ของเซิร์ฟเวอร์ EC2 หรือ RDS เป็นแคชโดยตรง ในสถาปัตยกรรมระบบจริงที่มีการใช้ตัวกระจายโหลด (Load balancer) เพื่อกระจายคำขอไปยังเซิร์ฟเวอร์หลายเครื่อง เซิร์ฟเวอร์แต่ละตัวจะมี RAM แยกขาดจากกันโดยสิ้นเชิง ทำให้เกิดปัญหาใหญ่สองประการ ประการแรกคือข้อมูลของผู้ใช้ถูกแคชแยกกันหลายเครื่อง เซิร์ฟเวอร์ตัวที่สองอาจไม่พบข้อมูลเดิม (Cache miss) จนต้องไปดึงจากฐานข้อมูลซ้ำซ้อน และข้อมูลในแต่ละเครื่องอาจไม่ตรงกัน ประการที่สองคือ เมื่อมีการรีสตาร์ทเซิร์ฟเวอร์หรืออัปเดตระบบ ข้อมูลในแคชทั้งหมดจะหายไปทันที
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น