ซีรีส์ "สัมภาษณ์คนไทยในซิลิคอนวัลเลย์" ตอนที่เจ็ด ก่อนหน้านี้เราเคยคุยกับ คุณวิโรจน์ จิรพัฒนกุล Data Scientist คนไทยใน Facebook ไปแล้ว คราวนี้มาคุยกับคุณธาวัน คูบุรัตถ์ วิศวกรคนไทยอีกคนที่รับผิดชอบงานด้าน infrastructure สถาปัตยกรรมระบบของ Facebook ที่ต้องรองรับผู้ใช้งานจำนวน 1.5 พันล้านคนกันบ้าง
เนื่องจากคุณธาวันเคยให้สัมภาษณ์กับ Droidsans ในประเด็นเรื่องสภาพแวดล้อม-วัฒนธรรมการทำงานของ Facebook ไปแล้ว บทสัมภาษณ์นี้จึงเจาะลงลึกด้านเทคนิคแบบสุดๆ ในงานที่คุณธาวันทำอยู่ ทั้งเรื่องระบบเซิร์ฟเวอร์-กริด-คลัสเตอร์ ภาษาโปรแกรมที่ใช้ภายในบริษัท แนวคิดเรื่องการสร้างซอฟต์แวร์ใช้ภายใน และการทำงานร่วมกับโครงการโอเพนซอร์สนอกบริษัทด้วย
สวัสดีครับ ผมชื่อ โต้ ธาวัน คูบุรัตถ์ เรียนจบตรี-โทจากวิศวะกรรมคอมพิวเตอร์จุฬาฯ ตอนเรียนโททำวิจัยด้าน Grid Computing จากนั้นออกมาทำงานกับ Accenture หนึ่งปี ก่อนไปเรียนต่อ ป.เอก ด้าน Computer Sciences ที่ University of Wisconsin–Madison ที่เลือกมหาวิทยาลัยนี้ก็เพราะมีอาจารย์ทำงานอยู่ในด้านที่ตัวเองสนใจคือ Grid Computing และ Cloud Computing
บริษัทใหญ่ๆ จะไปสอบสัมภาษณ์เด็กตามมหาวิทยาลัยดังๆ อยู่แล้ว เช่น MIT, Harvard และมหาวิทยาลัยอื่นที่อันดับรองลงมาแต่มีชื่อเสียงในสายงานที่ Facebook สนใจ นอกจากนี้การที่ศิษย์เก่าจากสถาบันใด เข้ามาทำงานใน Facebook ได้ดี ก็จะมีส่วนให้ทางบริษัทเข้าไปดึงเด็กจากสถาบันนั้นมากขึ้นในปีถัดไป ซึ่งหลายปีที่ผ่านมานี้ Facebook ถึงกับส่งคนไปสัมภาษณ์นักศึกษาที่มหาวิทยาลัยในจีนหรืออินเดียโดยตรงเลย
ระหว่างที่เรียนอยู่ที่ UW-Madison (ภาควิชา Computer Sciences ของที่นี่มีชื่อด้าน Systems) มีโอกาสได้สัมภาษณ์กับ Facebook เพราะทางบริษัทส่งพนักงานเข้ามาที่งาน Career Fair ของมหาวิทยาลัย และเรียกสัมภาษณ์เด็กในมหาวิทยาลัยเลยโดยไม่ต้องบินไปที่สำนักงานใหญ่ ผมเลยมีโอกาสได้เข้ามาฝึกงานกับ Facebook ด้วย
ตอนเริ่มฝึกงาน บริษัทจะมีสายงานให้เราเลือกว่าจะทำอะไร เช่น ทำหน้าเว็บ หรือ ระบบหลังบ้าน จากนั้นจะมีคนมาดูประวัติผลงานของเรา แล้วส่งไปยังทีมที่เหมาะสม
ผมได้เข้าไปทำงานกับทีมที่ทำระบบ Cluster Management ชื่อว่า Tupperware เนื่องจากเป็นนักศึกษา ป.เอก ทางทีมงานจึงให้โอกาสผมเลือกงานภายในทีมที่สนใจ จุดนี้ทำให้ผมรู้สึกว่าได้มีบทบาทในการกำหนดทิศทางของงาน ข้อดีที่สำคัญอย่างหนึ่งของ Facebook คืองานของเด็กฝึกงานส่วนใหญ่จะถูกนำไปใช้งานจริง เมื่อทำเสร็จยิ่งทำให้เรารู้สึกภูมิใจในงาน นอกจากเรายังสามารถใช้เวทีงาน Hackathon เป็นโอกาสในการทำงานที่เราสนใจหรือแสดงความสามารถนอกเหนือจากงานหลักอีกด้วย
พอทำผลงานได้ดีทั้งงานหลัก และงานเสริมที่ทำในงาน Hackathon พอฝึกงานเสร็จ ผมเลยได้รับข้อเสนอให้เข้าเป็นพนักงานประจำทันที ตอนนั้นยังเรียน ป.เอก ไม่จบ เลยกลับมาคุยกับอาจารย์ที่ปรึกษา เขาเข้าใจว่านี่เป็นโอกาสทางวิชาชีพที่ดี ผมเลยเลือกเรียนต่อให้จบแค่ ป.โท แล้วมาทำงานให้ Facebook ซึ่งปัจจุบันทำมาได้สามปีกว่าแล้ว
เนื่องจาก Facebook เป็น Internet Company ระบบต่างๆ ภายในจึงมีขนาดใหญ่และมีความซับซ้อนสูง
แผนกที่ผมทำงานอยู่ชื่อว่า Core Systems มีหน้าที่สร้างและดูแลระบบโครงสร้างพื้นฐานที่ใช้สนับสนุนการทำงานของระบบอื่นๆ ของ Facebook อีกที เช่น Configuration Management, Cluster Management เป็นต้น
แนวคิดของทีม Core Systems คือทำระบบพื้นฐานให้ดี เพื่อให้ทีมอื่นนำของเหล่านี้ไปสร้างบริการใหม่ๆ ให้ Facebook ได้อย่างรวดเร็ว โดยไม่ต้องมาคอยพะวงหรือแก้ปัญหาซ้ำๆ เดิมทุกรอบ ดังนั้นงานของ Core Systems คล้ายกับการทำตัวเป็น Amazon EC2 ที่เราสามารถนำบริการเสริมต่างๆ มาใช้ในการสร้างระบบของเราเองได้ เพียงแต่ใช้ภายในบริษัท Facebook อย่างเดียวเท่านั้น
นอกจากนี้ การที่ระบบภายในทั้งหมดใช้โครงสร้างพื้นฐานเดียวกัน ทำให้บริษัทสามารถลงทุนพัฒนาและสร้างนวัตกรรมให้กับระบบพื้นฐานเหล่านี้ได้มาก เพราะทีมผลิตภัณฑ์อื่นๆ ของบริษัทย่อมได้ประโยชน์ทางอ้อมจากการพัฒนาโครงสร้างพื้นฐานด้วย
ปัจจุบันผมเป็นหัวหน้าด้านเทคนิค (Tech Lead) ในทีม Configuration Management คำว่า Tech Lead ใน Facebook มีหน้าที่ดูแลการทำงานของระบบที่ได้รับมอบหมายให้มีประสิทธิภาพ ในขณะที่ Engineering Manager มีหน้าที่ดูแลบุคคลากรและทิศทางของทีมว่าทำงานได้ดีมีประสิทธิภาพหรือไม่
งานที่ทำคือระบบการจัดการ "ค่าคอนฟิก" ต่างๆ ทั้งหมดที่ใช้ใน Facebook ตั้งแต่หน้าเว็บ, ระบบหลังบ้าน หรือแม้กระทั่งโปรแกรมมือถือ เนื่องจากระบบทั้งหมดของ Facebook ใหญ่มาก แค่การดูแลคอนฟิกของระบบก็ยุ่งยากและซับซ้อนแล้ว ไม่สามารถใช้คนดูแลได้ทั้งหมด ต้องสร้างซอฟต์แวร์มาช่วยจัดการไฟล์คอนฟิกอีกทีหนึ่ง งานของทีมนี้คือพัฒนาและดูแลระบบแบบ end-to-end ตั้งแต่ตัวจัดเก็บข้อมูล (repository) ระบบจัดส่งข้อมูล (distribution) ไปจนถึง Client API ในแต่ละภาษา เช่น C++, PHP หรือ Java เป็นต้น โดยตัวระบบจัดส่งข้อมูลใช้ซอฟต์แวร์โอเพนซอร์ส Apache Zookeeper เป็นโครงสร้างหลัก
แนวคิดการใช้งานระบบคอนฟิกของ Facebook คือพยายามทำให้แต่ละทีมสามารถนำบริการใหม่ๆ ออกสู่ผู้ใช้ได้รวดเร็ว ตามความต้องการของแต่ละทีม ในขณะเดียวกันก็พยายามลดข้อผิดพลาดที่อาจเกิดขึ้นให้น้อยที่สุด
ภายใต้แนวคิดนี้ พนักงานสามารถใช้ค่าคอนฟิกในการเปิดบริการใหม่แก่ผู้ใช้ เมื่อทีมตัวเองคิดว่าพร้อม โดยไม่ต้องรอให้ทีมอื่นมาช่วยดำเนินการให้ ตรงนี้ช่วยให้เปิดบริการใหม่ได้เร็ว แต่ในอีกด้าน ตัวระบบจัดส่งก็จะทดลองค่าคอนฟิกใหม่กับผู้ใช้แค่บางส่วนก่อน หากพบว่ามีปัญหาร้ายแรงเกิดขึ้นก็ยกเลิกโดยอัตโนมัติ เพื่อไม่ให้ความผิดพลาดส่งผลต่อทั้งระบบ
บริษัททั่วไปมักเน้นซื้อซอฟต์แวร์สำเร็จรูปที่มีขายอยู่ในตลาด แต่บริษัทอย่าง Facebook หรือ Google ที่เป็น Internet Company ใช้วิธีสร้างซอฟต์แวร์ขึ้นมาใช้เองเป็นหลัก
เหตุผลที่หนึ่งคือต้นทุนถูกกว่าเมื่อต้องนำไปใช้งานกับเครื่องเป็นจำนวนมาก ไม่ต้องเสียค่าไลเซนส์ตามจำนวนเครื่อง เหตุผลที่สองเป็นเพราะสามารถปรับแต่งซอฟต์แวร์ให้เข้ากับระบบที่มีอยู่แล้วได้ง่ายและรวดเร็วกว่า ถ้าใช้วิธีจ้างหรือใช้ซอฟต์แวร์ของบริษัทอื่น อาจมีปัญหาว่าบริษัทนั้นไม่สามารถพัฒนาซอฟต์แวร์ได้รวดเร็วตามการเติบโตของ Facebook ได้
Google เป็นบริษัทแรกๆ ที่ใช้แนวทางนี้ แต่แนวทางของกูเกิลมักใช้วิธีเผยแพร่ผลงานผ่านการตีพิมพ์งานวิชาการ เช่น MapReduce แต่ไม่ค่อยเปิดเผยซอร์สโค้ดเท่าไร ในขณะที่บริษัทรุ่นหลังจาก Google จะพยายามผลักดันเป็นโครงการโอเพนซอร์สควบคู่ไปด้วย เพราะหวังให้บริษัทอื่นๆ เข้ามาร่วมสนับสนุนในการพัฒนาซอฟต์แวร์ตัวนั้นมากขึ้น ตัวอย่างเช่น โครงการ OpenCompute ของ Facebook ที่ภายหลังก็มีผู้ร่วมสนับสนุนเป็นจำนวนมาก
อย่างไรก็ตาม แม้ว่าทางบริษัทจะเห็นประโยชน์ของการโอเพนซอร์ส แต่ในทางปฏิบัติก็ไม่ใช่เรื่องง่าย เพราะซอฟต์แวร์หลายตัวมักเขียนเพื่อใช้กับระบบโครงสร้างภายในของบริษัทเอง ซึ่งระบบพวกนี้อาจไม่ได้เป็นโอเพนซอร์ส ดังนั้นเราจึงไม่สามารถทำแค่เปิดซอร์สโค้ดเพียงอย่างเดียวแล้วหวังว่าซอฟต์แวร์พวกนี้จะใช้งานกับระบบภายนอกบริษัทได้ทันที ต้องมีกระบวนการปรับปรุงซอฟต์แวร์ให้พร้อมทำงานกับระบบที่หลากหลายมากขึ้นด้วย
ถ้าให้เปรียบเทียบแนวทางการสร้างระบบหลังบ้านของ Google และ Facebook สิ่งหนึ่งที่ผมมักได้ยินบ่อยๆ คือ Facebook มักสร้างสิ่งต่างๆ ขึ้นจากความต้องการของตัวเองในการสร้างบริการใหม่ และด้วยระยะเวลาที่ค่อนข้างจำกัด ทีมงานจึงเน้นแนวทาง practical คือออกแบบเพื่อให้มีใช้ภายในก่อน เอาให้ทำงานได้จริงแล้วค่อยขยับขยายในภายหลัง
ตัวอย่างที่เห็นได้ชัดคือวิวัฒนาการของระบบจัดเก็บรูปภาพของ Facebook ที่ชื่อว่า Haystack ที่เริ่มแรกใช้ระบบไฟล์ NFS เก็บรูปภาพ เพื่อให้สามารถนำบริการใหม่ออกสู่ผู้ใช้ได้อย่างรวดเร็ว ภายหลังถึงค่อยพัฒนาระบบจัดเก็บรูปโดยเฉพาะขึ้นมาอีกที เนื่อง NFS ใช้ทรัพยากรได้ไม่เต็มประสิทธิภาพ และไม่สามารถขยายระบบให้ทันการเติบโตของผู้ใช้ได้ในราคาที่เหมาะสม
ส่วน Google มักให้เวลากับงานสร้างระบบมากกว่า การทำงานของ Google จะให้ความสำคัญกับการวิเคราะห์ปัญหา และสร้างแนวทางใหม่ๆ ขึ้นมาแก้ปัญหาอย่างมีแบบแผน มีทฤษฎีเป็นเรื่องเป็นราว ตัวอย่างที่ชัดเจนคือ MapReduce ที่มีแนวคิดเชิงทฤษฎีมาเป็นชุด ทั้งนี้ส่วนหนึ่งก็เพราะ Google มีพนักงานที่เรียนจบการศึกษาระดับสูง (ป.โท-เอก) หรือคนที่มีประสบการณ์สูงอยู่เป็นจำนวนมากด้วย
Facebook เลือกใช้ภาษาตามความเหมาะสมของงาน
งานระบบหน้าบ้าน (Frontend) เริ่มจากการใช้ PHP เป็นหลัก ซึ่งบริษัทเองก็เพิ่มความสามารถให้กับ PHP เรื่อยมา ไม่ว่าจะเป็น XHP, Async, type annotation ฟีเจอร์ที่เพิ่มมาพวกนี้ เดิมทีใช้กันอยู่แต่ภายในบริษัท ก่อนจะถูกเรียกรวมเป็นภาษา Hack แล้วเผยแพร่ออกมาสู่คนภายนอก
เหตุที่ต้องเพิ่มความสามารถเหล่านี้ให้กับภาษา PHP ก็เพื่อให้การเขียนโค้ดมีประสิทธิภาพมากขึ้นบน codebase ที่มีความซับซ้อนขึ้นตลอดเวลา นอกจากนี้ Facebook ยังสร้าง compiler/runtime ของตัวเองเรียกว่า HHVM เพื่อให้โค้ด PHP ทำงานเร็วขึ้นและมีประสิทธิภาพสูงขึ้น
งานส่วนที่เป็น Web UI ช่วงหลังเริ่มใช้เครื่องมือที่บริษัทพัฒนาขึ้นเองอย่าง React มากขึ้นเพราะเขียนง่าย (เนื่องจากเป็นการเขียนแบบ declarative) และสะดวกที่จะนำส่วนต่างๆ มาประกอบกัน
React ยังเริ่มเข้ามามีบทบาทในการสร้างแอพพลิเคชันบนมือถือผ่าน React Native ด้วย จุดเด่นของ React Native คือการใช้ภาษา JavaScript ควบคุมการแสดงผล ไม่ต้องเสียเวลาคอมไพล์ แต่ประสิทธิภาพกลับเทียบเท่าภาษาเนทีฟของแพลตฟอร์มนั้นๆ ผลดีโดยรวมคือประหยัดเวลาพัฒนาลงมาก
งานระบบหลังบ้าน (Backend) ส่วนใหญ่มักใช้ C++ เพื่อรีดประสิทธิภาพของฮาร์ดแวร์ให้มากที่สุด เพราะระบบของ Facebook ต้องตอบสนองรวดเร็ว มีอัตรา latency ต่ำที่สุดเท่าที่เป็นไปได้ การใช้ Java จะมีปัญหาเรื่อง Garbage collection pause ทำให้อัตรา latency ไม่คงที่ ถ้าหากไม่มีการจูนระบบที่ดีพอ ดังนั้นการใช้ C++ จึงสมเหตุสมผลมากกว่า นอกจากนี้แถบซิลิคอนวัลเลย์หาคนเก่ง C++ ไม่ยากด้วย
Facebook ยังมีใช้ภาษา Java ในงานหลังบ้านอยู่บ้าง ในส่วนที่เกี่ยวข้องกับ Hadoop/Hive นอกจากนี้ยังใช้ Python ในส่วนที่เป็น Scripting/Automation เพราะสามารถเขียนได้เร็วและง่ายกว่า C++/Java สรุปง่ายๆ ว่าเลือกภาษาให้เหมาะสมกับความต้องการของงานจะดีกว่า
ปัจจุบัน ภาษา C++ เริ่มถูกนำมาใช้ในการสร้างแอพมือถือมากขึ้น โดยนำไปใช้ในส่วนของ logic ภายในที่ซับซ้อน ที่สามารถเขียนครั้งเดียวแล้วใช้ได้กับทั้ง iOS และ Android ไม่ต้องเขียนใหม่ ส่วนตัว UI ค่อยไปใช้เครื่องมือเฉพาะของแพลตฟอร์มนั้นอีกที
อย่างแอพแชร์รูปภาพ Moments (ข่าวเก่า) ของ Facebook เองก็ใช้แนวทางนี้ เนื่องจากต้องการสร้าง Configuration Framework ตัวเดียวที่สามารถใช้ร่วมกันบนทั้งสองแพลตฟอร์ม จึงเลือกใช้ภาษา C++ นั่นเอง
ในภาพรวมแล้ว Facebook ให้ความสำคัญกับ "ประสิทธิภาพ" ในการทำงานของพนักงานเป็นอย่างมาก เครื่องมืออะไรที่เพิ่มประสิทธิภาพของการทำงานให้ดีขึ้นได้ Facebook จะลงทุนสร้างมันขึ้นมา ผลคือพนักงานสามารถนำเสนอบริการใหม่ๆ ได้อย่างรวดเร็ว และเป็นองค์ประกอบสำคัญที่ทำให้ Facebook ประสบความสำเร็จถึงทุกวันนี้
โปรเจคแรกที่ทำตอนเริ่มเป็นพนักงานของ Facebook คือทำหน้าที่พัฒนาและดูแล Zookeeper ที่ใช้ภายในบริษัท
Zookeeper เป็นระบบที่สร้างขึ้นตามแนวคิดของ Chubby lock service ที่สร้างขึ้นโดย Google เช่นเดียวกันกับ Hadoop ที่สร้างขึ้นจาก MapReduce
หน้าที่ของ Zookeeper คือเป็นระบบที่ใช้ทำกระบวนการ Distributed Coordination ซึ่งจำเป็นสำหรับการประมวผลแบบกระจายศูนย์ เช่น Leader Election (เลือกโพรเซสที่เป็นผู้นำ), Distributed Locking (ล็อคทรัพยากรเพื่อประมวลผล) ซึ่งเป็นสิ่งจำเป็นต่อการสร้างระบบที่อาศัยการทำงานร่วมกันของคอมพิวเตอร์หลายเครื่อง แม้แต่ระบบเช่น Hadoop หรือ HBase ก็พึ่งพา Zookeeper เช่นกัน
การนำซอฟต์แวร์โอเพนซอร์สมาใช้ภายในบริษัทแบบ Facebook ก็มีข้อดีข้อเสียที่ต้องคำนึงถึง ข้อดีคือสามารถนำของที่มีอยู่แล้วมาใช้ได้เลย ไม่ต่องเริ่มเขียนใหม่ นอกจากนี้ยังมีชุมชนนักพัฒนาที่คอยพัฒนาความสามารถใหม่ๆ หรือซ่อมบั๊กที่มีผู้ใช้อื่นแจ้งเข้ามา
ส่วนข้อเสียมาจากการที่ Facebook มีความต้องการที่เฉพาะเจาะจง เช่น ต้องการให้ระบบมีสมรรถนะสูง บางครั้งจึงต้องพยายามโน้มน้าวให้ชุมชนเห็นด้วยว่าฟีเจอร์นี้เป็นสิ่งจำเป็น ไม่เช่นนั้นแล้ว ฟีเจอร์ที่เราสร้างขึ้นมาอาจไม่ถูกนำเข้าไปผนวกรวมในโค้ดของโครงการด้วย เพราะชุมชนเองไม่อยากดูแลฟีเจอร์ที่ซับซ้อนและไม่มีคนใช้งานนอกจาก Facebook และถ้าฟีเจอร์ที่สร้างขึ้นใช้ภายในไม่ถูกผนวกกลับเข้าต้นน้ำ ก็จะเป็นอุปสรรคต่อการทำงานของเราในอนาคต เพราะจะนำแพตช์จากชุมชนมาใช้ทำได้ยากขึ้น เกิดปัญหา merge conflict ระหว่างโค้ดภายในกับโค้ดของโครงการที่เผยแพร่ต่อสาธารณะ
ถึงกระนั้น ฟีเจอร์จาก Facebook ส่วนใหญ่มักได้รับความไว้วางใจจากชุมชน เพราะเราบอกได้ว่าผ่านการทดสอบและใช้งานจริงจากระบบภายในของ Facebook ที่มีขนาดใหญ่มากๆ มาเรียบร้อยแล้ว อีกอย่างทีมที่เขียนโค้ดและดูแลระบบของ Facebook คือทีมเดียวกัน ข้อนี้ทำให้ชุมชนนักพัฒนาภายนอกเชื่อมั่นในโค้ดของเรามากขึ้น เพราะสร้างจากประสบการณ์ดูแลระบบโดยตรง ในขณะที่โค้ดของบริษัทอื่นนั้น นักพัฒนาอาจจะไม่ได้จับระบบที่ใช้งานจริงโดยตรง
ผมเองเคยส่งฟีเจอร์หลายอันที่เขียนสำหรับ Facebook เข้าโครงการ Zookeeper และเมื่อมีโอกาสก็เข้าไปร่วมตอบปัญหาทางเทคนิคใน mailing list ของชุมชนด้วย สิ่งเหล่านี้ทำให้ผมได้รับความเชื่อถือจากคนในโครงการ และได้ถูกเสนอชื่อเป็น committer ในตอนหลัง นอกจากนี้ผู้ก่อตั้งโครงการ Zookeeper ก็เคยส่งต้นฉบับหนังสือมาให้ช่วยอ่านก่อนตีพิมพ์ด้วย
ผมมองว่าข้อดีของการทำงานกับโครงการโอเพนซอร์ส คือเราได้พัฒนาความสามารถของตัวเอง และมีชื่อเสียงติดตัวที่คนภายนอกมองเห็นได้ จึงเป็นการเพิ่มโอกาสด้านอาชีพงานให้กับตัวเราเอง ทุกวันนี้ผมมักได้รับจดหมายมาเสนองานจากบริษัทอื่นอยู่เรื่อยๆ ซึ่งเหตุที่บริษัทเหล่านี้สนใจเราก็เป็นเพราะว่าเขาใช้ Zookeeper แล้วเห็นชื่อเราเข้าร่วมพัฒนาโครงการนั่นเอง