Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

สรุปจากการอ่านบทความเรื่อง Redesigning Pinterest’s Ad Serving Systems with Zero Downtime

$
0
0

หลังจากการอ่านบทความเรื่อง Redesigning Pinterest’s Ad Serving Systems with Zero Downtime
เป็นการ redesign และ rewrite ระบบ Ads-serving platform ของ Pinterest
เป็นระบบที่สร้างรายได้ให้บริษัทอย่างมาก
แต่ระบบที่ใช้งานมี technical debt เยอะ และ ซับซ้อนสูงมาก ๆ
ทำให้ระบบมีปัญหาต่อการ scale อย่างมาก ล่มบ่อย
รวมทั้ง business goal ที่เยอะขึ้น

ปัญหาหลัก ๆ ของระบบ ประกอบไปด้วย

  • Infrastructure และ business logic ผูกมัดกันอย่างมาก ดังนั้นยากต่อการเปลี่ยนแปลง
  • การจัดการโครงสร้างของระบบไม่ดี ไม่มีการจัดการ module ที่ดี ทำให้เกิด conflict ในการแก้ไข รวมทั้งการก่อให้เกิด bug ได้ง่าย ๆ
  • ไม่การันตีเรื่องความถูกต้องของข้อมูล
  • มีปัญหาในการทำงานแบบ multi-thread เพราะว่าไม่มี framework ที่ชัดเจน ทั้งเรื่อง error handling และ race condition เมื่อเกิดปัญหาทำให้ยากต่อการจัดการ

ดังนั้นจึงตัดสินใจที่จะทำการเขียนระบบขึ้นมาใหม่ !!
โดยมี working group เข้ามาช่วยกันคิด และ ตัดสินใจว่า

  • ทำการเขียนใหม่ด้วย Java ดีกว่าการ refactor code เดิม
  • ใช้ Java เนื่องจากระบบส่วนใหญ่ก็ใช้

ในการพัฒนาระบบใหม่นั้นมีสิ่งที่น่าสนใจคือ Engineering Design Principles

เพื่อสร้างระบบที่ช่วยให้ business โตอย่างรวดเร็ว
และลดปัญหาที่เกิดขึ้นบน production
ซึ่งมีแนวทางดังนี้

  • ง่ายต่อการเพิ่มส่วนขยาย (Extensible) และง่ายต่อการ deprecated หรือเอาส่วนที่ไม่ใช้งานออกไป (Design-for-deprecation)
  • Separation of Concern ทำการแยก infrastructure กับ business logic ออกจากกัน ด้วยการกำหนด high level abstraction ขึ้นมา รวมทั้งแยกแต่ละส่วนเป็น module ให้แต่ละทีมดูแล แยกกันอย่างชัดเจน
  • Safe-by-design การออกแบบต้องปลอดภัยจากเรื่องของการทำงานแบบ concurrency และ ความถูกต้องของข้อมูลเป็นหลัก ทำให้มั่นใจว่าจะไม่เกิด race condition รวมทั้งการจัดการ log ของการทำงาน
  • Development velocity กอบการทำงานใหม่ต้องสนับสนุนการพัฒนา มี environment ที่ดีต่อการพัฒนา รวมทั้งมีเครื่องมือในการ debug และ analyze การทำงานและปัญหาแบบง่ายๆ อีกด้วย (สำคัญมาก ๆ)

ต่อการเรื่องของ Design Decision มีการวางแนวทางไว้ดังนี้

เริ่มด้วยการตอบ 2 คำถามนี้ก่อนคือ

  • จัดการ code ของแต่ละทีมอย่างไร ไม่ให้กระทบทีมอื่น ๆ
  • จัดการข้อมูลอย่างไร ให้ข้อมูลยังคงความถูกต้อง

ถ้าจะตองคำถามเหล่านี้ได้ จำเป็นต้องรู้และเข้าใจ
ในเรื่องของ business logic ของระบบ
ในเรื่องการจัดการข้อมูลที่จำเป็นต่อการใช้งาน
รวมทั้ง high level ของ abstraction layer เพื่อลดผลกระทบต่าง ๆ ลงไป
จึงทำให้เกิด design decision ขึ้นมา 2 ข้อคือ

  • Code ของระบบจะมีการสร้าง Directed Acyclic Graph (DAG) จาก graph framework ที่สร้างขึ้นมา เพื่อแสดงความสัมพันธ์ของ code เพื่อแสดงความสัมพันธ์ของ code ซึ่งช่วยในการตัดสินใจอย่างมาก และเห็นผลกระทบที่ชัดเจน
  • ทำการสร้าง data model เพื่อส่งเข้าไปยังระบบ graph ที่ทำงานแบบ thread-safe (อ่านแล้วไม่แน่ใจว่าเป็นแบบไหน)

ผลจากการ rewrite ระบบใหม่นั้น พบว่า

  • สามารถ deliver product ได้รวดเร็วขึ้น และ ปลอดภัยมากยิ่งขึ้น
  • ความพึงพอใจของทีมพัฒนาดีขึ้นอย่างมาก
  • ระบบงานสามารถ run บน infrastructure ที่ดี ซึ่งช่วยลดค่าใช้จ่ายไปได้เยอะ

การกำหนดข้อตกลงร่วมกัน และ การมีเป้าหมายที่ชัดเจน
จะนำไปสู่การลงมือทำที่ดี เพื่อให้ผลลัพธ์ตรงกับที่ต้องการ


Viewing all articles
Browse latest Browse all 1997

Trending Articles