การสร้างเว็บเซอร์วิสที่มีความพร้อมใช้งานสูงโดยไม่ใช้ฐานข้อมูล

การสร้างเว็บเซอร์วิสที่มีความพร้อมใช้งานสูงโดยไม่ใช้ฐานข้อมูล

การสำรวจ

• สำหรับสตาร์ตอัปใหม่ โดยทั่วไปมักเลือกเว็บเฟรมเวิร์กอย่าง Rails, Django, Node และฐานข้อมูลอย่าง MySQL, PostgreSQL, MongoDB
• แต่ถ้าสามารถรวมเว็บเซอร์วิสและอินสแตนซ์ฐานข้อมูลให้เป็นหนึ่งเดียวได้ล่ะ? สามารถใช้แนวทางที่เก็บข้อมูลทั้งหมดไว้ใน RAM
• เมื่อใช้ RAM เป็นฐานข้อมูล ก็ไม่จำเป็นต้องซีเรียลไลซ์ข้อมูลด้วย SQL query
• ดัชนีสามารถทำได้ด้วย hash table ในหน่วยความจำ
• งานเบื้องหลังสามารถประมวลผลเป็น thread ภายในโปรเซสขนาดใหญ่ได้
• หากโปรเซสล่ม สามารถกู้คืนได้โดยถ่าย snapshot ของ RAM เป็นระยะและบันทึกการเปลี่ยนแปลงลงดิสก์

การขยาย

• เมื่อลูกค้าต้องการความพร้อมใช้งานสูง สามารถทำสำเนาเซิร์ฟเวอร์ด้วยอัลกอริทึมฉันทามติ Raft
• หากเซิร์ฟเวอร์ผู้นำล่ม จะมีการเลือกผู้นำใหม่ขึ้นมารับคำขอแทน
• ด้วยวิธีนี้จึงทำ rolling deployment ได้โดยไม่ต้องรีสตาร์ตเซิร์ฟเวอร์

การแยกออก

• เมื่อมีลูกค้ารายใหญ่จำนวนมากขึ้น สามารถแบ่งเว็บเซอร์วิสด้วย sharding เพื่อรองรับการทำงาน
• ให้คลัสเตอร์เฉพาะสำหรับลูกค้าองค์กรแต่ละราย
• คอขวดหลักอาจเป็นประสิทธิภาพของ commit thread

สแตกของเรา

• ใช้ Common Lisp: รองรับมัลติเธรดได้ดีมาก และเหมาะกับการทำ hot reloading ของโค้ด
• ใช้ bknr.datastore และ bknr.cluster: ใช้ไลบรารี Braft ของ Baidu สำหรับการติดตั้งใช้งาน Raft
• ใช้ EFS สำหรับจัดเก็บไฟล์ภาพ: จัดการข้อผิดพลาดและทดสอบได้ง่ายกว่า S3

สรุป

• สถาปัตยกรรมนี้เหมาะกับสตาร์ตอัปใหม่ และเมื่อใช้ Common Lisp ก็มีเครื่องมือจำนวนมากพร้อมใช้งานอยู่แล้ว
• ขอขอบคุณผู้มีส่วนร่วมของ bknr.datastore, Braft และ Raft

สรุปโดย GN⁺

• บทความนี้นำเสนอสถาปัตยกรรมแบบใหม่สำหรับการสร้างเว็บเซอร์วิสที่มีความพร้อมใช้งานสูงโดยไม่ใช้ฐานข้อมูล
• ใช้ RAM เป็นฐานข้อมูล และรับประกันความพร้อมใช้งานสูงผ่านอัลกอริทึมฉันทามติ Raft
• ใช้ Common Lisp เพื่อรองรับมัลติเธรดและการทำ hot reloading ของโค้ด
• สถาปัตยกรรมนี้เหมาะกับสตาร์ตอัปใหม่ และช่วยให้พัฒนาและดีบักได้รวดเร็ว
• โปรเจ็กต์ที่มีความสามารถคล้ายกัน ได้แก่ Redis และ Memcached

[GN⁺]

ความคิดเห็นจาก Hacker News

• การทำ transaction log เองแทนที่จะใช้ SQLite เป็นเรื่องแปลก

  • ถ้าข้อมูลอยู่ได้ในเซิร์ฟเวอร์เครื่องเดียว ก็ควรรันฐานข้อมูลบนเซิร์ฟเวอร์นั้นไปเลย
  • ถ้าข้อมูลอยู่ได้ใน RAM การใช้ ramdisk แล้วทำสำเนาไปยัง persistent storage ด้วยเครื่องมือมาตรฐานจะง่ายกว่า

• การสร้างฐานข้อมูล in-memory เองโดยไม่ใช้ MySQL, Postgres, Redis, MongoDB ฯลฯ เป็นเรื่องซับซ้อน

  • ต้อง serialize ธุรกรรมและเขียนลงดิสก์
  • ต้องซิงก์ transaction log ระหว่างเว็บเซิร์ฟเวอร์และอัปเดตฐานข้อมูล in-memory
  • ต้องเขียนอัลกอริทึมแก้ปัญหาความขัดแย้ง
  • ต้อง shard เว็บเซิร์ฟเวอร์ตาม tenant และเขียนเลเยอร์ load balancing

• การไม่ยอมเรียนรู้พื้นฐานของ MySQL หรือ Postgres เป็นการเสียเวลา

  • เมื่อรันบนผู้ให้บริการ public cloud การจูนพื้นฐานก็ช่วยแก้ปัญหา concurrency ได้
  • การเพิ่มข้อมูล 10 ล้านแถวไม่ใช่ปัญหาใหญ่
  • รอให้เจอสถานการณ์ที่แย่กว่านี้ก่อนแล้วค่อยแก้จะฉลาดกว่า

• เป็นสถาปัตยกรรมที่คล้ายกับ Nomad, Consul และ Vault ของ HashiCorp

  • ประสบการณ์ของนักพัฒนาดี
  • สามารถกำหนดสถานะแบบ in-memory ได้ตามต้องการ
  • ไม่เหมาะกับสตาร์ทอัปใหม่
  • การอัปเกรดนั้นยากเป็นพิเศษ

• มีความเข้าใจผิดว่า RAM ถูกมาก

  • SSD และประสิทธิภาพของ vCPU ดีขึ้นมาก แต่ราคา RAM ไม่ได้ลดลงมากนัก
  • ราคา DRAM ผันผวนเป็นรอบ ๆ และเพิ่งจะถูกลงเล็กน้อยเมื่อไม่นานนี้

• เคยเห็นโปรเจ็กต์ที่ใช้ไดเรกทอรีของไฟล์ซิสเต็มเป็นตาราง และใช้ไฟล์ JSON เป็นแถวข้อมูล

  • เคยพิจารณา Redis, Mongo, Postgres แต่สุดท้ายสร้างฐานข้อมูลเอง
  • การเอาโทเค็นแนวใหม่ไปใช้กับการสร้างฐานข้อมูลเป็นเรื่องไม่มีประสิทธิภาพ

• การใช้ฐานข้อมูลเชิงสัมพันธ์มีความมั่นคงกว่ามาก

  • มี redundancy, transaction log, backup และความสามารถในการกู้คืนในตัว
  • ในกรณีส่วนใหญ่ การใช้ฐานข้อมูลเป็นทางเลือกที่ดีกว่า

• มีการทำชั้น consensus แบบ Raft เองเพื่อหลีกเลี่ยงความซับซ้อน

  • การใช้ Redis อาจง่ายกว่า

• แอปเดสก์ท็อปและแอปมือถือสมัยใหม่มักใช้ฐานข้อมูลอย่าง SQLite

  • การเก็บและ query ข้อมูลเชิงสัมพันธ์นั้นมีประโยชน์

• การสร้างฐานข้อมูล in-memory เองไม่ได้ง่ายกว่าการติดตั้ง Postgres หรือ SQLite

  • การเขียน SQL ง่ายกว่าการเขียนโค้ด concurrency