- สรุปเนื้อหาการสัมภาษณ์ Roberta Arcoverde ผู้อำนวยการฝ่ายวิศวกรรมของ Stack Overflow ในพอดแคสต์ของ Scott Hanselman
- เธอเข้าร่วมงานเมื่อ 8 ปีก่อนในตำแหน่งวิศวกรซอฟต์แวร์ จากนั้นเติบโตเป็น Staff Engineer (Tech Lead) และเมื่อต้นปีนี้ได้เปลี่ยนบทบาทไปเป็นผู้จัดการ
S: อะไรเปลี่ยนไปบ้างหลังจากได้เป็นผู้อำนวยการฝ่ายวิศวกรรม?
- R: ต้องมาบริหารคน ดูแลเส้นทางอาชีพและช่วยให้พวกเขาเติบโต รวมถึงมีวิสัยทัศน์เชิงกลยุทธ์ว่าเราควรจะมุ่งไปทางไหน
คอยดูว่าสถาปัตยกรรมซอฟต์แวร์เป็นอย่างไร กำลังเดินหน้าไปในทิศทางที่เอื้อต่อการเติบโตหรือไม่ และ PR นี้กำลังพาเราไปยังจุดที่ต้องการในอีก 3 ปีข้างหน้าหรือเปล่า ไม่ใช่ดูแค่ตอนนี้
- S: แปลว่าต้องวางแผนและลงมือทำในระยะยาวมากขึ้น เพื่อไม่ให้ตกใจกับการเปลี่ยนแปลงของเทคโนโลยี
- R: ใช่เลย และมีการประชุม 1-on-1 มากขึ้นด้วย
- S: ตอนนี้ที่ Microsoft ก็เป็นช่วงรีวิวเหมือนกัน หลายวันมีแต่ 1-on-1 กับการประเมินต่อเนื่อง น่าเบื่อเพราะมีแต่ประชุม คุณยังเข้าไปดูโค้ดเพื่อรีเฟรชตัวเองบ้างไหม?
- R: ดูค่ะ ฉันเชื่ออย่างแรงกล้าว่าแม้แต่ผู้จัดการสายงานที่อยู่หน้างานอย่างฉันก็ควรเขียนโค้ดทุกวัน นั่นช่วยให้ยังรักษาทักษะทางเทคนิคของตัวเองไว้ได้
มันยังช่วยในการเมนเทอร์วิศวกรจูเนียร์ และช่วยประเมินผลกระทบของการเปลี่ยนแปลงที่วิศวกรอาวุโสเสนอด้วย
ถ้ายังเขียนโค้ดต่อเนื่องและมองเห็นว่าซอฟต์แวร์กำลังมุ่งไปทางไหน เวลามีการออกแบบใหม่ครั้งใหญ่ ก็จะสามารถตั้ง “คำถามที่ถูกต้อง” เพื่อช่วยให้พวกเขาได้ผลลัพธ์ที่ดีที่สุด
S: สถาปัตยกรรมของ Stack Overflow เป็นอย่างไร?
- R: Stack Overflow ค่อนข้างแปลกทีเดียว โดยเฉพาะเมื่อเทียบกับไซต์ใหญ่เจ้าอื่นที่เริ่มต้นในปี 2008
- ตอนนี้เรามีโค้ดเบสที่มีอายุ 14 ปีแล้ว
- รันบนเครื่อง on-prem ในดาต้าเซ็นเตอร์ของเราเอง
- ไม่เคยย้ายขึ้นคลาวด์เลย
- เป็นแอปพลิเคชันแบบ monolithic ด้วย ไม่ได้แยกเป็น service หรือ microservices
- เรายังมีเว็บแอปแบบ multi-tenant ด้วย สร้างบน .NET และรันเป็นแอปเดียวบนเว็บเซิร์ฟเวอร์ 9 เครื่อง
- รันบน IIS โดยเซิร์ฟเวอร์หนึ่งเครื่องรองรับได้ 6,000 requests ต่อวินาที (2 พันล้าน PV ต่อเดือน)
- S: ช่วงหลัง IIS หายไปเยอะเพราะ Apache, NGINX, Kubernetes ฯลฯ ได้รับความนิยม คุณก็สามารถไปทางนั้นได้เหมือนกัน มีอะไรที่จงใจมองข้ามไปไหม? แล้วมีอะไรที่คิดว่า “อันนี้ Stack Overflow ต้องมี” บ้างไหม?
- R: เรามองข้ามหลายอย่างในนั้น สิ่งล่าสุดคือทุกอย่างที่เกี่ยวกับ microservices และ Kubernetes
เหตุผลใหญ่ที่สุดที่มองข้าม เพราะปรัชญาการพัฒนาที่แข็งแรงที่สุดของ SO
เราเริ่มจากคำถามนี้เสมอ “คุณกำลังพยายามแก้ปัญหาอะไรอยู่?”
ปัญหาที่เครื่องมือเหล่านั้นพยายามแก้ ไม่ใช่ปัญหาที่เราเผชิญอยู่
ตัวอย่างเช่น การย้ายจาก monolithic ไปเป็น microservices หรือ services มีไว้เพื่อขยายขนาดด้วยการแบ่งทีม
เพื่อให้หลายทีมทำงานบนโปรเจ็กต์เดียวกันได้โดยไม่ชนกัน และเพื่อ deploy ได้เร็วขึ้น
การ deploy เร็วก็ไม่ใช่ปัญหาของเรา SO deploy ได้วันละหลายครั้ง ใช้เวลา 4 นาที และถ้ามีปัญหาก็ rollback กลับได้ในไม่กี่นาที
ตอนนี้ lead time ของเรา หรือเวลาที่ใช้ในการ merge ก็ดีมาก และไม่ใช่เรื่องที่สร้างความเจ็บปวด
มีวิศวกรราว 50 คนกำลังพัฒนาแพลตฟอร์ม Q&A อยู่
- R: ในปี 2014 เรามีอยู่ 10 คน และทุกคนเข้าใจโค้ดเบสทั้งหมดได้ไม่ยาก
ตอนนี้การ onboarding วิศวกรใหม่เริ่มยากขึ้นแล้ว
สักวันหนึ่งเราอาจแยกบางโมดูลออกมา และให้ทีมเฉพาะดูแลโดยไม่จำเป็นต้องเข้าใจโค้ดทั้งหมด
แต่เรายังไปไม่ถึงจุดนั้น เรายังไม่ได้เจอปัญหานั้น และเราเป็นพวกปฏิบัตินิยม
สถาปัตยกรรมอื่น ๆ
- แคช 2 ชั้น (หน่วยความจำและเว็บเซิร์ฟเวอร์)
- มี SQL Server หลายเครื่องด้วย: RAM 1.5TB ทำให้เข้าถึงฐานข้อมูลทั้งก้อนได้ 1/3 จากใน RAM อย่างรวดเร็ว
→ คิดว่านี่เป็นโครงสร้างที่แพงมากและใช้บนคลาวด์ให้คุ้มต้นทุนได้ยาก
- หน้า question ไม่ได้ cache แม้จะเป็นหน้าที่ hit สูงสุดและกินทราฟฟิก 80% ก็ตาม
→ ก่อนหน้านี้เคยพยายาม cache ด้วย Redis แต่ hit/miss cache rate ไม่ค่อยดี
- เวลาการเรนเดอร์หน้าเพจตอนนี้อยู่ที่ราว 20ms
- StackExchange ก็รันแบบ multi-tenant อยู่บนเซิร์ฟเวอร์เดียวกัน แอปพลิเคชันเดียวรองรับทั้ง 200 ไซต์
→ หมายความว่า deploy แอปเพียงตัวเดียวก็มีผลกับทั้งหมด
- ทำ rolling build ใต้ HAProxy
7 ความคิดเห็น
โอ้โห.... ส่วนที่บอกว่าใช้
haproxyทำ rolling build นี่น่าประทับใจมาก แต่ก็สงสัยเหมือนกันว่าเขาทำกันอย่างไรฉันลองอ่านสคริปต์พอดแคสต์ดูแล้ว รู้สึกว่าส่วนที่ใช้ haproxy ถูกพูดถึงสั้น ๆ แล้วก็ผ่านไปนะครับ ดูจากที่บทสนทนาเชื่อมไปเรื่อง health check กับคุยกันว่าทำ monitoring กันเยอะมาก ก็น่าจะประมาณว่าเขาทำขึ้นมาเองและจัดการกันได้ดีอยู่แล้ว… ประมาณนั้นครับ ^^;
ผมสงสัยว่าเขาทำ "deploy ภายใน 4 นาที" กันอย่างไร
ผมก็เคยดูแลเซิร์ฟเวอร์แรม 4TB / เซิร์ฟเวอร์แรม 8TB ที่บริษัทก่อนเหมือนกัน ค่าติดตั้งเริ่มต้นแน่นอนว่ามหาศาลมาก แต่ก็รู้สึกชัดเจนว่าไม่น่าจะเอาสเปกแบบนั้นไปแทนด้วยคลาวด์ได้จริง ๆ
ก็คงเป็นแบบนั้นแหละ
ขอบคุณสำหรับสรุปครับ
มีหลายจุดที่น่าประทับใจมาก
เป็นบทสัมภาษณ์ที่ค่อนข้างยาว เลยสรุปไว้เป็นช่วง ๆ ครับ ลองฟังฉบับเต็มไปพร้อมกับดูสคริปต์ประกอบได้เลย!
สคริปต์: https://app.podscribe.ai/episode/83433649