รายการอ่านด้านระบบกระจาย (2014)
(dancres.github.io)- แก่นสำคัญของการเรียนรู้ระบบกระจายอยู่ที่ การเปลี่ยนกรอบความคิด มากกว่าการยึดติดกับเทคโนโลยีใดเทคโนโลยีหนึ่ง และรายการนี้จะพาไล่ตามประเด็นปัญหาตามหัวข้อที่ต้องเผชิญเมื่อออกแบบระบบระดับอินเทอร์เน็ต
- เนื้อหาถูกแบ่งเป็นปรัชญาการออกแบบ, latency, กรณีศึกษาระบบขนาดใหญ่ของ Amazon และ Google, โมเดลความสอดคล้อง, ทฤษฎี, เครื่องมือ, โครงสร้างพื้นฐาน, ที่เก็บข้อมูล, อัลกอริทึมฉันทามติ, gossip protocol และ P2P
- CAP, การหลีกเลี่ยง 2PC, eventual consistency และ optimistic replication แสดงให้เห็น trade-off เชิงปฏิบัติการ ว่าเป็นเรื่องยากที่จะได้ทั้งความสอดคล้องและความพร้อมใช้งานสูงสุดพร้อมกัน
- ชุดบทความของ Google ให้ตัวอย่างการใช้งานจริงของ ระบบกระจายขนาดใหญ่ เช่น MapReduce, Chubby, GFS, BigTable, Dremel, Spanner, Photon และ Mesa ส่วนเนื้อหาของ Amazon ก็ครอบคลุมทั้งการเปลี่ยนผ่านสู่สถาปัตยกรรมแบบบริการและวัฒนธรรมองค์กร
- หากอ่านต่อเนื่องตั้งแต่ Paxos, Raft, FLP, Lamport Clock, Byzantine Generals, Chord, Kademlia จนถึง Pastry ก็จะช่วยจัดระเบียบประเด็นเรื่อง ฉันทามติ เวลา การทำสำเนา และการกำหนดเส้นทาง ให้เห็นเป็นภาพเดียวกัน
กรอบความคิดและมุมมองการออกแบบ
- ส่วนที่ยากที่สุดของระบบกระจายคือการ เปลี่ยนวิธีคิด และรายการนี้เริ่มต้นด้วยบทความและงานวิจัยที่ช่วยให้เกิดการเปลี่ยนมุมมองนั้น
- “Thought Provokers” กล่าวถึงมุมมองที่ว่าเซิร์ฟเวอร์ขนาดใหญ่ ฐานข้อมูล และทรานแซกชัน เพียงอย่างเดียวไม่สามารถแก้ทุกปัญหาได้
- Harvest, Yield and Scalable Tolerant Systems: ว่าด้วยการประยุกต์ใช้ CAP ในโลกจริง
- On Designing and Deploying Internet Scale Services: เอกสารของ James Hamilton ว่าด้วยการออกแบบและปรับใช้บริการระดับอินเทอร์เน็ต
- The Perils of Good Abstractions: กล่าวถึงความยากของการสร้าง API และอินเทอร์เฟซที่สมบูรณ์แบบ
- Chaotic Perspectives: เน้นความคาดเดาไม่ได้ ความไร้ระเบียบ และความขนานของระบบขนาดใหญ่
- รวมถึง Data on the Outside versus Data on the Inside, Memories, Guesses and Apologies, Building on Quicksand ของ Pat Helland
- และยังมี Why Distributed Computing? ของ Jim Waldo กับ A Note on Distributed Computing ของ Waldo, Wollrath และคณะ ให้อ่านคู่กัน
Latency และบริการระดับอินเทอร์เน็ต
- “Latency” พูดถึงผลกระทบต่อสถาปัตยกรรมภายใต้สมมติฐานว่า latency มีอยู่เสมอ
- Latency Exists, Cope!: ว่าด้วยวิธีรับมือกับ latency และผลกระทบต่อสถาปัตยกรรม
- Latency - the new web performance bottleneck: ว่าด้วย latency ในฐานะคอขวดของประสิทธิภาพเว็บ
- The Tail At Scale: ว่าด้วยปัญหา latency ในระบบขนาดใหญ่ โดยเฉพาะ tail latency
- เนื้อหาของ Amazon ไม่ได้มองแค่ตัวเลือกทางเทคนิค แต่ยังพาไปดู วัฒนธรรมและองค์กร ที่ก่อตัวขึ้นระหว่างการเปลี่ยนผ่านสู่สถาปัตยกรรมแบบบริการ
- A Conversation with Werner Vogels: ว่าด้วยการเปลี่ยนผ่านของ Amazon ไปสู่สถาปัตยกรรมแบบบริการ
- Discipline and Focus: กล่าวถึงการเปลี่ยนผ่านของ Amazon ไปสู่สถาปัตยกรรมแบบบริการเพิ่มเติม
- รวมถึง Vogels on Scalability และ SOA creates order out of chaos @ Amazon
งานวิจัยระบบของ Google และโมเดลความสอดคล้อง
- ชุดของ Google รวบรวม งานวิจัยระบบขนาดใหญ่ ที่เรียกได้ว่าเป็น “rocket science” ของระบบกระจายไว้ในที่เดียว ตั้งแต่ MapReduce จนถึง Mesa
- MapReduce
- Chubby Lock Manager
- Google File System
- BigTable
- Dremel: การวิเคราะห์เชิงโต้ตอบสำหรับชุดข้อมูลขนาดระดับเว็บ
- Megastore: การออกแบบสำหรับการใช้งาน Paxos แบบ latency ต่ำข้ามดาต้าเซ็นเตอร์
- Spanner: ฐานข้อมูลของ Google ที่ขยายได้ เป็นแบบหลายเวอร์ชัน กระจายทั่วโลก และทำสำเนาแบบ synchronous
- Photon: การ join สตรีมข้อมูลต่อเนื่องที่ทนทานต่อความล้มเหลวและขยายได้
- Mesa: data warehouse แบบ replicated ตามภูมิภาค กึ่งเรียลไทม์ และขยายได้ สำหรับเก็บข้อมูลการวัดผลสำคัญของธุรกิจโฆษณาอินเทอร์เน็ตของ Google
- “Consistency Models” ประกอบด้วยแหล่งข้อมูลที่ใช้ค้นหาจุด ประนีประนอมระหว่างความสอดคล้องกับความพร้อมใช้งาน ให้เหมาะกับสภาพแวดล้อมของระบบ
- CAP Conjecture: กล่าวถึงแนวคิดที่ว่าไม่สามารถทำให้ Consistency, Availability และ Partition Tolerance เป็นจริงพร้อมกันทั้งหมดได้
- CAP Twelve Years Later: Eric Brewer ขยายคำอธิบายเดิมเรื่อง trade-off นี้
- รวม Consistency and Availability และ Eventual Consistency ของ Werner Vogels
- Avoiding Two-Phase Commit และ 2PC or not 2PC, Wherefore Art Thou XA?: ว่าด้วยการหลีกเลี่ยง two-phase commit และข้อจำกัดของมัน
- Starbucks doesn't do two phase commit: ว่าด้วยกลไกแบบ asynchronous
- Optimistic Replication: ว่าด้วยแนวทางความสอดคล้องแบบผ่อนปรนสำหรับการทำสำเนาข้อมูล
ทฤษฎี ภาษา โครงสร้างพื้นฐาน และที่เก็บข้อมูล
- “Theory” รวบรวมแหล่งข้อมูลที่จำเป็นต่อการทำความเข้าใจเรื่อง เศรษฐศาสตร์ สมมติฐานความล้มเหลว เวลา และข้อจำกัดของฉันทามติ ซึ่งปรากฏซ้ำแล้วซ้ำอีกในการออกแบบระบบกระจาย
- Distributed Computing Economics: Jim Gray
- Rules of Thumb in Data Engineering: Jim Gray และ Prashant Shenoy
- Fallacies of Distributed Computing: Peter Deutsch
- Impossibility of distributed consensus with one faulty process: งานวิจัยที่รู้จักกันในชื่อ FLP และการเข้าถึงอาจต้องมีบัญชีหรือชำระเงิน โดยมีลิงก์เวอร์ชันฟรีให้ด้วย
- Unreliable Failure Detectors for Reliable Distributed Systems: ว่าด้วยแนวทางรับมือกับความยากแบบ FLP
- Lamport Clocks: ปัญหาการสร้างมุมมองเรื่องเวลาแบบทั่วทั้งระบบเมื่อแต่ละคอมพิวเตอร์มีนาฬิกาเป็นอิสระจากกัน
- The Byzantine Generals Problem
- แหล่งข้อมูลด้านภาษาและเครื่องมือแสดงให้เห็นว่า การเลือกเทคโนโลยีเฉพาะอย่างเดียวไม่ได้ทำให้ปัญหาความน่าเชื่อถือหายไป
- Programming Distributed Erlang Applications: Pitfalls and Recipes: การเลือก Erlang และ OTP เพียงอย่างเดียวไม่ได้ทำให้การสร้างแอปพลิเคชันแบบกระจายที่เชื่อถือได้กลายเป็นเรื่องง่าย
- เนื้อหาด้านโครงสร้างพื้นฐานกล่าวถึงความสำคัญของ การจัดการนาฬิกา ซึ่งจำเป็นแม้แต่กับงานพื้นฐานอย่างการดีบัก
- แหล่งข้อมูลด้านที่เก็บข้อมูลต่อยอดไปสู่การออกแบบ distributed caching และระบบจัดเก็บอย่าง Dynamo
ฉันทามติ Gossip และ P2P
- ชุด Paxos เริ่มจากข้อเท็จจริงที่ว่า Paxos เองก็ทำความเข้าใจได้ยาก และแนะนำให้เริ่มจาก Paxos Made Simple ก่อน จากนั้นค่อยกลับมาอ่านอีกครั้งหลังอ่านงานอื่นแล้ว
- The Part-Time Parliament: Leslie Lamport
- Paxos Made Simple: Leslie Lamport
- Paxos Made Live - An Engineering Perspective: Chandra และคณะ
- Revisiting the Paxos Algorithm: Lynch และคณะ
- How to build a highly available system with consensus: Butler Lampson
- Reconfiguring a State Machine: การเปลี่ยนสมาชิกของคลัสเตอร์
- Implementing Fault-Tolerant Services Using the State Machine Approach: บทสอนของ Fred Schneider
- งานวิจัยฉันทามติอื่น ๆ ยังครอบคลุมทั้งสภาพแวดล้อม WAN และทางเลือกอื่นนอกเหนือจาก Paxos
- Mencius: อัลกอริทึมฉันทามติสำหรับเครือข่ายวงกว้าง
- In Search of an Understandable Consensus Algorithm: เวอร์ชันขยายของงานวิจัย Raft และเป็นทางเลือกแทน Paxos
- แหล่งข้อมูลด้าน gossip protocol รวบรวมโปรโตคอลการสื่อสาร การมอนิเตอร์ และการจัดการสมาชิกที่มี พฤติกรรมแบบการแพร่ระบาด
- How robust are gossip-based communication protocols?
- Astrolabe: เทคโนโลยีที่ทนทานและขยายได้สำหรับการมอนิเตอร์ การจัดการ และการทำเหมืองข้อมูลในระบบกระจาย
- SWIM: โปรโตคอล membership ของ process group แบบ infection-style ที่ขยายได้และมีความสอดคล้องแบบอ่อน
- แหล่งข้อมูลด้าน P2P พาไล่ตามเรื่องการค้นหาแบบกระจาย การกำหนดเส้นทาง ที่เก็บข้อมูล และ multicast ระดับแอปพลิเคชัน
- Chord: โปรโตคอล P2P สำหรับการค้นหาระดับอินเทอร์เน็ตที่ขยายได้
- Kademlia: ระบบข้อมูล P2P ที่อิงบน XOR metric
- Pastry: การระบุตำแหน่งวัตถุและการกำหนดเส้นทางแบบกระจายที่ขยายได้สำหรับระบบ P2P ขนาดใหญ่
- PAST: ยูทิลิตีที่เก็บข้อมูล P2P แบบถาวรขนาดใหญ่บน Pastry
- SCRIBE: โครงสร้างพื้นฐาน multicast ระดับแอปพลิเคชันแบบกระจายขนาดใหญ่สำหรับการส่งข้อความแบบวงกว้างบน Pastry
1 ความคิดเห็น
ความเห็นจาก Hacker News
รายการนี้ดูค่อนข้างเก่า และขอแนะนำ รายการอ่านเรื่อง distributed consensus ของ Heidi Howard
https://github.com/heidihoward/distributed-consensus-reading...
รู้สึกแปลก ๆ ที่ยก MapReduce ของ Google ขึ้นมาเป็น “วิทยาการระดับจรวด” ของสายนี้
พอตรวจดูแล้วพบว่ารายการนี้เป็นข้อมูลจากปี 2014 [1] ดังนั้นตอนนี้สถานการณ์เปลี่ยนไปมากแล้ว จึงควรระวัง
[1] https://news.ycombinator.com/from?site=dancres.github.io
มี เมตารายการของรายการอ่านด้านระบบกระจาย ที่ทำไว้เมื่อราว 10 ปีก่อน
รายการนี้ก็ถูกเพิ่มเข้ามาช้าราว 10 ปีเช่นกัน และมีแต่ฟ้าที่รู้ว่าจากรายการที่ฉันรวบรวมไว้ ยังเหลือรายการไหนที่ยังใช้งานได้อยู่บ้างในตอนนี้
https://gist.github.com/macintux/6227368
https://ferd.ca/a-distributed-systems-reading-list.html ซึ่งพูดถึงรายการต้นฉบับก็น่าอ่านควบคู่กันไป
มันอาจมีประโยชน์สำหรับคนที่ต้องการผลักขีดจำกัดหรือมองหาแนวทางใหม่ ๆ แต่สำหรับคนอื่น ๆ มันเหมือนกับถามวิธีแก้สมการกำลังสองแล้วได้รับงานวิจัยทฤษฎีหมวดหมู่มา 100 ฉบับ
รายการของ Fred Herbert ใหม่กว่าต้นฉบับ แต่เจ้าตัวก็บอกเองว่าไม่ได้ครบถ้วนสมบูรณ์ เขายก “Designing Data-Intensive Applications” เป็นหนังสือที่ต้องอ่าน แต่ก็พูดในทำนองว่าถ้าอยากเข้าใจจริงก็ต้องอ่านงานวิจัยจำนวนมากก่อน
เมื่อรายการแบบนี้ถูกนำเสนอราวกับเป็นเงื่อนไขเบื้องต้นของความเข้าใจ ก็อาจให้ความรู้สึกเหมือน ตั้งกำแพงให้เข้าถึงยาก
ด้วยผลงานของคนอื่นที่สั่งสมกันมาหลายสิบปี คุณไม่จำเป็นต้องอ่านงานวิจัยนาโนเคอร์เนล 100 ฉบับเพื่อจะเป็นผู้ใช้ Linux ที่มีประสิทธิภาพได้ แม้ว่าการสร้างระบบปฏิบัติการที่ดีตั้งแต่ศูนย์จะยังคงยากอยู่ แต่ 99% ของคนส่วนใหญ่ไม่จำเป็นต้องทำแบบนั้น และแค่ใช้เครื่องมือที่มีอยู่ให้ชำนาญก็พอ
ระบบกระจายก็เช่นกัน ถ้าคุณไม่ได้พยายามผลักดันแนวหน้า มันไม่จำเป็นต้องยากขนาดนั้น
ถ้าคุณเป็นวิศวกรซอฟต์แวร์ที่อยากได้ประสบการณ์ภาคปฏิบัติมากกว่าการขุดลึกด้านงานวิจัย ลองสร้างอะไรบางอย่างด้วย NATS [1] หรือ YugaByte [2] หรือทำแบบฝึกปฏิบัติตามทutorial อย่าง [3] ก็น่าจะดีกว่า
“Designing Data-Intensive Applications” ก็น่าอ่านเช่นกัน มันเป็นหนึ่งในหนังสือที่ยิ่งอ่านซ้ำก็ยิ่งดี ต่อให้คุณยังไม่ได้อ่านงานวิจัย 100 ฉบับก็อ่านไปได้เลย ถ้าเจอส่วนที่ไม่เข้าใจก็ค่อยถามและขอความช่วยเหลือได้ และไม่จำเป็นต้องฝืนอ่านรายการอ่านขนาดมหึมาพวกนั้น
1: https://nats.io/
2: https://www.yugabyte.com/
3: https://pragprog.com/titles/tjgo/distributed-services-with-g...
แต่ถึงอย่างนั้นก็ยังไม่มีการพูดถึง เทคโนโลยี CRDT เลยหรือ?