- "Up: Portable Microservices Ready for the Cloud"
- Uber มีวิศวกร 4,500 คนและระบบอัตโนมัติจำนวนมากที่ปรับใช้ Stateless microservices จำนวน 4,500 บริการมากกว่า 4,000 ครั้งต่อสัปดาห์
- บริการเหล่านี้ถูกพัฒนา ปรับใช้ และดูแลโดยทีมจำนวนหลายร้อยทีมที่ทำงานอย่างอิสระทั่วโลก
- บริการมีขนาด รูปแบบ และหน้าที่หลากหลาย บางส่วนมีขนาดเล็กและใช้สำหรับงานภายใน ขณะที่บางส่วนมีขนาดใหญ่และใช้สำหรับการประมวลผลแบบเรียลไทม์ขนาดใหญ่
ประวัติของบริการ Stateless ของ Uber
- ในปี 2014 Uber ใช้ Monolith ที่เขียนด้วย Python และจัดเก็บข้อมูลไว้ในฐานข้อมูล PostgreSQL เพียงเครื่องเดียว
- เมื่อเติบโตขึ้นก็เพิ่มจำนวนวิศวกรและเปลี่ยนไปใช้สถาปัตยกรรม Microservice
- เมื่อจำนวนบริการเพิ่มขึ้น Uber จึงสร้างเครื่องมือชื่อ µDeploy เพื่อปรับใช้โค้ดจากศูนย์กลางในระดับใหญ่
- ทำให้บริการ Stateless ทั้งหมดอยู่ในรูปแบบคอนเทนเนอร์ และซ่อนความซับซ้อนของการจัดการโฮสต์และการจัดวาง
- ทำให้กลุ่มโครงสร้างพื้นฐานสามารถจัดการโฮสต์ฟลีตได้อย่างอิสระจากไมโครเซอร์วิสของแต่ละหน่วยธุรกิจ
- แต่การจัดการและการจัดวางบริการยังคงทำด้วยมือ
- โครงสร้างพื้นฐานของ Uber ใช้โมเดลที่กลุ่มของโซน (Zone) รวมกันเป็นรีเจียน (Region)
- ค่า latency ระหว่างโซนภายในรีเจียนสั้นพอ ทำให้การสื่อสารแบบ synchronous ระหว่างบริการในภูมิภาคเดียวกันมีประสิทธิภาพ
- แต่ละโซนอาจเป็นคลัสเตอร์ของเครื่องที่ Uber เป็นเจ้าของหรือเป็นของผู้ให้บริการคลาวด์สาธารณะก็ได้ แต่แต่ละโซนจะเป็นของผู้ให้บริการเพียงรายเดียวเสมอ
- โดยทั่วไป ไมโครเซอร์วิสทั้งหมดควรสามารถเรียกใช้บริการอื่นได้โดยไม่มีปัญหาเรื่อง latency ตราบใดที่อยู่ในรีเจียนเดียวกัน
- µDeploy ไม่ได้รวมศูนย์การจัดวางเชิงภูมิศาสตร์ของ workload ไว้ในระบบ เพราะวิศวกรยังต้องจัดการการวางทางกายภาพในระดับ Availability Zone เอง
- กล่าวคือ วิศวกรบริการยังคงต้องตัดสินใจเองว่าควรรันบริการในโซน on-premises หรือไม่ รวมถึงต้องเลือกว่าจะรันในโซนใดโดยเฉพาะ
- การดูแลดาต้าเซ็นเตอร์แบบ on-premises ทำให้เกิด lead time ที่ยาวนานจากปัญหาการขาดแคลนชิปและซัพพลายเชน
- เมื่อวันที่ 13 กุมภาพันธ์ 2023 Uber ได้จับมือเป็นพาร์ตเนอร์กับ Oracle และ Google เพื่อลดการพึ่งพาและกระจายความเสี่ยงจากปัญหาซัพพลายเชน
- สำหรับวิศวกร Uber หลายพันคนที่พัฒนาบริการหลายร้อยประเภทเพื่อรองรับธุรกิจ กลยุทธ์นี้ไม่สามารถทำได้เลยหากไม่มี "ระบบที่สามารถซ่อนความซับซ้อนของโครงสร้างพื้นฐานพื้นฐาน"
การเตรียมพร้อมเพื่อย้าย Uber ขึ้นคลาวด์
- การย้ายบริการแบบไร้สถานะจำนวน 4,500 บริการขึ้นคลาวด์ในขณะที่ยังต้องดำเนินธุรกิจต่อไป ต้องอาศัยการประสานงานและความพยายามมหาศาล
- ตั้งแต่ต้นก็ชัดเจนว่างานนี้มีโอกาสผิดพลาดสูง และแทบเป็นไปไม่ได้ที่จะบริหารด้วยความพยายามที่ประสานกันด้วยมือ
- เพื่อดูแลและจัดการ Stateless microservices ในระดับใหญ่ Uber จำเป็นต้องยกระดับบริการให้สามารถถูกจัดการอัตโนมัติจากระบบ deployment แบบรวมศูนย์โดยไม่ต้องพึ่งการแทรกแซงจากมนุษย์
- จาก Stateless ไปสู่ Portability
- บนพื้นฐานของโมเดล Region และ Zone จึงเกิดแนวคิดเรื่อง "Portability"
- Portability หมายถึงบริการที่สามารถรันได้ในทุกโซนภายในรีเจียน และสามารถถูกย้ายไปยังโซนใหม่โดยอัตโนมัติจากแพลตฟอร์มโครงสร้างพื้นฐานโดยไม่ต้องมีคนเข้ามายุ่ง
- ครอบคลุมทั้งการย้ายระหว่างผู้ให้บริการ public cloud และการย้ายเข้าออกโซน on-premises
- เดิมบริการบางตัวไม่มี portability เพราะขึ้นอยู่กับการตั้งค่าโซนและความต้องการทรัพยากรของโซน
- เพื่อให้สามารถทำ automated migration ไปยังคลาวด์ได้ ทุกบริการจึงต้องมี portability
การทำให้ Uber เป็น Portable
- ตลอดปี 2021 และ 2022 Uber ดำเนินโครงการทั่วทั้งองค์กรวิศวกรรมเพื่อให้แน่ใจว่าทุกบริการมี portability
- ในหลายกรณี เพียงตรวจสอบโค้ดเพื่อดูการใช้ string constant และชื่อไฟล์ ก็สามารถตรวจพบการละเมิด portability ได้
- สำหรับกรณีง่าย ๆ Uber เขียนกฎ linter เพื่อเน้นโค้ดที่ดูเหมือน hardcode ให้รันในตำแหน่งทางกายภาพเฉพาะ
- เพื่อทดสอบว่าบริการ portable จริงหรือไม่ จำเป็นต้องลองย้ายบริการข้ามหลายโซนจริง ๆ โดยไม่มีการแทรกแซงจากมนุษย์
- จึงสร้างชุดเครื่องมือทดสอบที่ช่วยให้เจ้าของบริการสามารถเริ่มการย้ายครั้งแรกของบริการตนเองได้
- เพราะอิงจากเครื่องมือเดิมที่ใช้สำหรับ rollout โค้ดอย่างปลอดภัยและค่อยเป็นค่อยไป เจ้าของบริการจึงสามารถย้อน deployment กลับไปยังโซนเดิมได้ทุกเมื่อ และแก้ปัญหาได้หากพบข้อผิดพลาด
- เมื่อการย้ายสำเร็จ บริการนั้นจะถูกทำเครื่องหมายให้ย้ายโดยอัตโนมัติในอนาคต
- ในช่วงหลายปีถัดมา Uber ทำกระบวนการนี้ซ้ำกับบริการทั้งหมด และในที่สุดก็ทำเสร็จครบทุกบริการ
- หลังงานนี้เสร็จ Uber จึงสามารถเปลี่ยน topology ของโซนได้โดยไม่ต้องให้วิศวกรบริการเข้ามาเกี่ยวข้อง
- เพื่อให้บริการยังคงรักษา portability ได้ในระยะยาว Uber จะย้ายบริการทั้งหมดข้ามโซนอย่างต่อเนื่องทุกไม่กี่สัปดาห์เพื่อทดสอบความสามารถในการย้ายเป็นประจำ
- วิธีนี้ช่วยให้ตรวจพบ regression ของบริการได้ง่าย และเมื่อเวลาผ่านไป วิศวกรก็เริ่มคุ้นเคยกับการไม่สมมติว่าบริการจะถูกวางอยู่ในโซนใดโซนหนึ่งเสมอ
Up: Multi-Cloud Multi-Tenant Federation Control Plane
- ได้กำหนดเป้าหมายเริ่มต้นของระบบดังนี้
- มอบจุดเข้าใช้งานเพียงจุดเดียว (Single Point of Entry) ให้แก่วิศวกรในการโต้ตอบกับระบบโครงสร้างพื้นฐาน
- จัดการและบังคับใช้ best practice สำหรับบริการที่ deploy ตรงกับระบบ เพื่อให้มีความปลอดภัยสูงระหว่างการ rollout โค้ด
- ทำ deployment placement ของบริการบน Availability Zone แบบอัตโนมัติ ซึ่งรวมถึงการประสาน placement จากศูนย์กลางเพื่อรองรับความพร้อมใช้งานสูงของ Uber โดยทั่วไป เมื่อมี Availability Zone ใหม่พร้อมใช้งานก็ย้ายการวางไปยังโซนใหม่นั้น
- ทำให้การย้ายโครงสร้างพื้นฐานระดับล่างที่ยุ่งยากเป็นอัตโนมัติ เพื่อให้วิศวกรบริการไม่จำเป็นต้องมีส่วนร่วมกับการย้าย
- สถาปัตยกรรมระดับสูง
- Experience Layer:
- ทำหน้าที่รองรับวิธีต่าง ๆ ที่วิศวกรใช้โต้ตอบกับระบบ
- เช่น UI, Continuous Delivery และบอตที่ช่วยให้ระบบอยู่ในสภาพดี
- Balancer ที่ย้าย workload ไปยังคลัสเตอร์และโซนที่มีการใช้งานต่ำกว่าอย่างต่อเนื่อง
- Auto Scaler ที่ปรับ allocation ของ capacity สำหรับแต่ละ workload ให้เหมาะสมอย่างต่อเนื่อง
- Platform Layer:
- ทำหน้าที่สร้าง abstraction ที่ Experience layer ใช้ในการโต้ตอบกับบริการ
- ประกอบด้วย abstraction ของ service และ service environment ที่เป็นโมเดลเชิงแนวคิดของการปฏิบัติการบริการ รวมถึง service-level API เอง
- ใน platform layer ข้อจำกัดของบริการจะถูกแสดงเป็นสถานะเป้าหมายระดับสูงที่อธิบายคุณสมบัติที่ต้องการของการจัดวางบริการจริง
- อาจรวมถึงข้อจำกัดด้านสมรรถนะของเครื่องที่จะใช้รัน และข้อจำกัดด้านความจุการประมวลผลรวมสำหรับบริการในแต่ละภูมิภาค
- Federation Layer:
- ทำหน้าที่เชื่อมรวมกับคลัสเตอร์คอมพิวต์
- จัดระเบียบคลัสเตอร์ทั้งหมดตามความสามารถและตำแหน่งทางกายภาพ เพื่อให้เกิด abstraction ของรีเจียนและโซนที่เลเยอร์บนใช้งาน
- รับสถานะเป้าหมายของบริการในระดับสูงจากแพลตฟอร์ม แล้วแปลงเป็นการจัดวางในระดับโซนและคลัสเตอร์ โดยอิงจากข้อจำกัดของสถานะเป้าหมายและสถานะจริงของคลัสเตอร์ เช่น capacity ที่มีอยู่ในขณะนั้น และคลัสเตอร์ที่สามารถตอบโจทย์ข้อจำกัดรองต่าง ๆ ได้
- ผลลัพธ์ของการแปลงนี้สามารถเปลี่ยนแปลงได้ตามเวลา และในภายหลังอาจมีการจัดวางในโซนและคลัสเตอร์อื่นที่เหมาะสมกว่า
- ทุกการเรียกของ balancer และงานอื่นที่เริ่มจาก experience layer ก็อาจทำให้การจัดวางนี้ถูกคำนวณใหม่และเปลี่ยนแปลงได้
- เพื่อให้ระบบยังคงปลอดภัยและบริการอยู่ในสถานะที่ดี องค์ประกอบจัดการการเปลี่ยนแปลงจะทำ rollout flow ที่ค่อย ๆ เปลี่ยนสถานะรวมทีละน้อยผ่านการเชื่อมรวมกับทุกระบบที่ใช้ติดตามสถานะบริการ
- กระบวนการ rollout มีทั้ง canarying ทั่วทั้งระบบและการติดตามสัญญาณสุขภาพ หากพบปัญหา ระบบจะ rollback บริการกลับไปยังการตั้งค่าและการจัดวางก่อนเริ่มการเปลี่ยนแปลงอย่างรวดเร็ว
- Regions
- รีเจียนประกอบด้วยอินสแตนซ์คลัสเตอร์จริง
- รวมถึงคลัสเตอร์ Peloton และ Kubernetes®
- สิ่งเหล่านี้อยู่นอกตัว Up เอง แต่เป็นปลายทางของการจัดวาง capacity จริง และทำหน้าที่จัดการการวางคอนเทนเนอร์บนโฮสต์จริง
ผลลัพธ์
- Uber เริ่มทำงานกับ Up ในปี 2018 มีโปรโตไทป์ที่ใช้งานได้ในต้นปี 2019 และเปิดตัวแพลตฟอร์มอย่างเป็นทางการในช่วงกลางปี 2020
- หลังจากนั้นได้ย้ายบริการมากกว่า 4,000 รายการจากแพลตฟอร์ม deployment เดิมมายัง Up ครอบคลุมทุกสายธุรกิจของ Uber
- การย้ายส่วนใหญ่เป็นแบบอัตโนมัติ ทำให้ทีมสามารถโฟกัสกับกรณีใช้งานที่ซับซ้อนที่สุด และช่วยสนับสนุนการย้ายของทีมอื่นได้ด้วย
- ตลอดช่วงเวลานี้ Uber ให้ความสำคัญกับเสถียรภาพของแพลตฟอร์มเป็นอันดับแรก จึงสามารถเดินหน้าธุรกิจได้อย่างมั่นคงในขณะที่มีผู้ใช้นับล้านใช้งานระบบ Uber ทุกวัน
- การย้ายทั้งหมดของคอร์ประมวลผลราว 2,000,000 คอร์ไปยังแพลตฟอร์มใหม่ใช้เวลาประมาณ 2 ปี และเสร็จสมบูรณ์อย่างสำเร็จในปี 2022
- การย้ายครั้งนี้ช่วยคืน capacity มูลค่าหลายสิบล้านดอลลาร์ให้ธุรกิจผ่านความพยายามด้าน autoscaling และการเพิ่มประสิทธิภาพ
- ช่วยประหยัดเวลาเชิงวิศวกรรมหลายหมื่นชั่วโมงที่เดิมต้องใช้ไปกับการอัปเดตบริการด้วยมือ การตั้งค่าและเติมโซนใหม่ และการเรียนรู้เพื่อรับมือกับสภาพแวดล้อมโครงสร้างพื้นฐานอันซับซ้อนของ Uber จึงลดต้นทุนด้านการเงินได้อย่างมาก
สิ่งที่จะทำต่อไป
- หลังจากย้ายจาก µDeploy มายัง Up เสร็จแล้ว ทีมจึงสามารถโฟกัสกับการสร้างโซลูชันที่นำไปใช้กับบริการทั้งหมดได้ในรูปแบบอัตโนมัติจากศูนย์กลาง รวมถึงสร้างประสบการณ์ผู้ใช้รอบความสามารถเหล่านี้ได้
- Cloud migration
- Uber กำลังย้ายฟลีตส่วนสำคัญขึ้นคลาวด์
- ด้วยระบบอัตโนมัติขนาดใหญ่และชั้น abstraction ที่ Up มอบให้ ทีมบริการจึงแทบไม่ต้องยุ่งกับรายละเอียดโครงสร้างพื้นฐานที่จำเป็นต่อการเปลี่ยนผ่านนี้
- Automated Continuous Delivery
- ตั้งเป้าทำให้การ deploy โค้ดไปถึง production เป็นอัตโนมัติทั้งหมด โดยใช้ pipeline อัตโนมัติในการรันการตรวจสอบและการทดสอบหลายรูปแบบก่อนโค้ดจะถูก deploy ขึ้น production
- ส่วนสำคัญที่ทีมวางแผนจะโฟกัสในปี 2023 คือการทำให้บริการ "ทันสมัยอยู่เสมอ" เพื่อให้โค้ดทั้งหมดที่รันใน production เป็นเวอร์ชันล่าสุด พร้อมอัปเดตด้านความปลอดภัยและไลบรารีล่าสุด
- Deployment Safety
- ข้อมูลที่มีอยู่แสดงให้เห็นว่า incident จำนวนมากที่สังเกตพบเกี่ยวข้องกับการเปลี่ยนแปลงโค้ดและการตั้งค่า
- เป้าหมายคือทำให้ด้านที่เดิมต้องทำด้วยมือในวงจรชีวิตบริการเป็นอัตโนมัติ เช่น การรันทดสอบก่อน production หรือการตั้งนโยบาย gradual rollout เพื่อให้สัดส่วนของข้อบกพร่องที่หลุดไปถึง production ลดลงอย่างมาก
- Platform
- การจัดรวมฟลีตบริการ Stateless ทั้งหมดของ Uber ไว้ใต้แพลตฟอร์ม umbrella เดียว ช่วยให้สามารถจำลองการพึ่งพาและปฏิสัมพันธ์ระหว่างผลิตภัณฑ์แพลตฟอร์มโครงสร้างพื้นฐานได้ชัดเจนขึ้น
- สิ่งนี้ไม่เพียงทำให้มีโมเดลแบบรวมศูนย์ในโค้ด แต่ยังมอบประสบการณ์ผู้ใช้ที่บูรณาการเต็มรูปแบบให้กับองค์กรวิศวกรรมส่วนที่เหลืออีกด้วย
- เป้าหมายใหญ่ถัดไปของทีมคือการสังเกตการณ์และปฏิบัติการโครงสร้างพื้นฐานทั้งหมดได้จากที่เดียว
บทสรุป
- ความพยายามในการสร้างแพลตฟอร์ม Up สะท้อนการเปลี่ยนแปลงทางวัฒนธรรมอย่างมีนัยสำคัญ เพราะปัจจุบันบริการ Stateless ทั้งหมดถูก rollout แบบค่อยเป็นค่อยไปโดยใช้ best practice และระบบอัตโนมัติชุดเดียวกัน
- งานที่ก่อนหน้านี้ต้องใช้เวลาหลายเดือน เช่น การเปลี่ยนนโยบาย rollout หรือการสร้างระบบอัตโนมัติสำหรับ rollout ไลบรารีในวงกว้าง ตอนนี้สามารถทำได้จากศูนย์กลาง
- Uber ตั้งตาร่วมมือกับผู้มีส่วนได้ส่วนเสียของ Up และเจ้าของบริการอย่างต่อเนื่อง เพื่อไปให้ถึงวิสัยทัศน์ที่ทำให้วิศวกร Uber โฟกัสกับโค้ดได้โดยไม่ต้องกังวลเรื่องโครงสร้างพื้นฐาน
ยังไม่มีความคิดเห็น