กูเกิลเล่าประสบการณ์ แปลงโค้ดภายในจาก x86 เป็น Arm จำนวนหลายหมื่นแอพ
Body
กูเกิลเปิดเผยเบื้องหลังการแปลงโค้ดของตัวเอง จากเดิมที่รันบน x86 อย่างเดียว ไปสู่สถาปัตยกรรมแบบ Arm ด้วย
แนวทางการใช้ซีพียู Arm ฝั่งเซิร์ฟเวอร์เป็นสิ่งที่ชัดเจนขึ้นเรื่อยๆ ด้วยเหตุผลเรื่องประสิทธิภาพต่อพลังงานที่ดีกว่า x86 ฝั่งกูเกิลมีซีพียู Axion ที่ออกแบบเองมาตั้งแต่ปี 2024 และ ภายหลังเปิดให้คนนอกเช่าใช้งานผ่าน Google Cloud
กูเกิลบอกว่าอนาคตคือการรองรับหลายสถาปัตยกรรมซีพียู (multiarch) ดังนั้นการพอร์ตโค้ดจาก x86 ให้รองรับ Arm ด้วยเป็นสิ่งจำเป็น แต่ด้วยสเกลของกูเกิลที่มีแอพพลิเคชันภายในมากกว่า 100,000 ตัว การพอร์ตโค้ดจึงไม่ใช่เรื่องง่ายเท่าไรนัก (ตอนนี้พอร์ตไปได้แล้วประมาณ 30,000 ตัว เลยมาเขียนเป็นเปเปอร์วิชาการเล่าว่าทำอย่างไร)
ในช่วงแรก กูเกิลเลือกย้ายแอพพลิเคชันยอดนิยมที่มีปริมาณการใช้งานสูง เช่น ฐานข้อมูล F1, ฐานข้อมูล Spanner, ฐานข้อมูล Bigtable ด้วยวิธีการแบบดั้งเดิม คือ ใช้ทีมวิศวกรเฉพาะมานั่งแปลงโค้ด มีการประชุมประจำสัปดาห์ เพื่อเรียนรู้ปัญหาและข้อจำกัดต่างๆ สิ่งที่กูเกิลพบคือ คอมไพเลอร์และเครื่องมือแปลงโค้ดทำงานได้ค่อนข้างดีกว่าที่คาด แต่ต้องมาเสียเวลากับการแก้ระบบ test, ปรับปรุงระบบ build ที่โบราณ, แก้ปัญหาคอนฟิก และสุดท้ายก็สามารถนำโค้ดเหล่านี้รันบนเครื่อง Arm ในระบบ Borg (พ่อของ Kubernetes) ได้สำเร็จ
ปัญหาถัดมาคือ แอพพลิเคชันยอดนิยม top 50 คิดเป็นสัดส่วน 60% ของการประมวลผลทั้งหมด แม้สัดส่วนของกลุ่ม top 50 มีเยอะ แต่สุดท้ายแล้ว กูเกิลจำเป็นต้องพอร์ตโค้ดของแอพที่เหลืออีกหลัก 100,000 ตัวให้เป็น Arm อยู่ดี วิธีการนัดทีมเจ้าของแอพมาคุยคงไม่เวิร์ค เพราะต้องนัดประชุมอย่างน้อย 100,000 ครั้ง กูเกิลจึงหาระบบอัตโนมัติมาช่วยแก้ปัญหานี้
กูเกิลมีระบบช่วยแปลงโค้ดอยู่แล้วหลายตัว เช่น Rosie, Sanitizers และสร้างเครื่องมือขึ้นใหม่อีกหลายตัว เช่น Continuous Health Monitoring Platform (CHAMP) ระบบมอนิเตอร์งาน multiarch และ CogniPort ระบบ agent ที่ช่วยทดสอบการ build และ test หากพบปัญหาข้อผิดพลาดขึ้น จะมี agnt อีกตัวมาช่วยแก้โค้ดให้อัตโนมัติ ตามภาพ
อีกเทคนิคที่ใช้คือการนำโค้ดที่ระบบอัตโนมัติสร้างขึ้น (จำนวน 38,156 commits) มาให้ Gemini วิเคราะห์ว่าโค้ดแต่ละส่วนทำอะไร จัดเป็นหมวดหมู่การแก้ปัญหา แล้วแปลงเป็นชาร์ทออกมาดูว่าทำอะไรไปบ้าง ซึ่งพบว่างานส่วนใหญ่ในช่วงแรกเป็นการพัฒนาเครื่องมือและระบบทดสอบ (สีฟ้าอ่อน) ก่อนค่อยๆ เปลี่ยนเป็นการแปลงโค้ด
กูเกิลบอกว่าตอนนี้ยังมีแอพพลิเคชันอีกหลายหมื่นตัวรอแปลงโค้ดต่อ ซึ่งจะใช้แนวทางอัตโนมัติทำงานต่อไปเรื่อยๆ ส่วนโค้ดใหม่ที่ถูกเขียนขึ้นในอนาคตจะเป็น multiarch โดยดีฟอลต์ทั้งหมดแล้ว
ที่มา - Google Cloud Blog
mk Tue, 28/10/2025 - 08:24
Continue reading...
Body
กูเกิลเปิดเผยเบื้องหลังการแปลงโค้ดของตัวเอง จากเดิมที่รันบน x86 อย่างเดียว ไปสู่สถาปัตยกรรมแบบ Arm ด้วย
แนวทางการใช้ซีพียู Arm ฝั่งเซิร์ฟเวอร์เป็นสิ่งที่ชัดเจนขึ้นเรื่อยๆ ด้วยเหตุผลเรื่องประสิทธิภาพต่อพลังงานที่ดีกว่า x86 ฝั่งกูเกิลมีซีพียู Axion ที่ออกแบบเองมาตั้งแต่ปี 2024 และ ภายหลังเปิดให้คนนอกเช่าใช้งานผ่าน Google Cloud
กูเกิลบอกว่าอนาคตคือการรองรับหลายสถาปัตยกรรมซีพียู (multiarch) ดังนั้นการพอร์ตโค้ดจาก x86 ให้รองรับ Arm ด้วยเป็นสิ่งจำเป็น แต่ด้วยสเกลของกูเกิลที่มีแอพพลิเคชันภายในมากกว่า 100,000 ตัว การพอร์ตโค้ดจึงไม่ใช่เรื่องง่ายเท่าไรนัก (ตอนนี้พอร์ตไปได้แล้วประมาณ 30,000 ตัว เลยมาเขียนเป็นเปเปอร์วิชาการเล่าว่าทำอย่างไร)
ในช่วงแรก กูเกิลเลือกย้ายแอพพลิเคชันยอดนิยมที่มีปริมาณการใช้งานสูง เช่น ฐานข้อมูล F1, ฐานข้อมูล Spanner, ฐานข้อมูล Bigtable ด้วยวิธีการแบบดั้งเดิม คือ ใช้ทีมวิศวกรเฉพาะมานั่งแปลงโค้ด มีการประชุมประจำสัปดาห์ เพื่อเรียนรู้ปัญหาและข้อจำกัดต่างๆ สิ่งที่กูเกิลพบคือ คอมไพเลอร์และเครื่องมือแปลงโค้ดทำงานได้ค่อนข้างดีกว่าที่คาด แต่ต้องมาเสียเวลากับการแก้ระบบ test, ปรับปรุงระบบ build ที่โบราณ, แก้ปัญหาคอนฟิก และสุดท้ายก็สามารถนำโค้ดเหล่านี้รันบนเครื่อง Arm ในระบบ Borg (พ่อของ Kubernetes) ได้สำเร็จ
ปัญหาถัดมาคือ แอพพลิเคชันยอดนิยม top 50 คิดเป็นสัดส่วน 60% ของการประมวลผลทั้งหมด แม้สัดส่วนของกลุ่ม top 50 มีเยอะ แต่สุดท้ายแล้ว กูเกิลจำเป็นต้องพอร์ตโค้ดของแอพที่เหลืออีกหลัก 100,000 ตัวให้เป็น Arm อยู่ดี วิธีการนัดทีมเจ้าของแอพมาคุยคงไม่เวิร์ค เพราะต้องนัดประชุมอย่างน้อย 100,000 ครั้ง กูเกิลจึงหาระบบอัตโนมัติมาช่วยแก้ปัญหานี้
กูเกิลมีระบบช่วยแปลงโค้ดอยู่แล้วหลายตัว เช่น Rosie, Sanitizers และสร้างเครื่องมือขึ้นใหม่อีกหลายตัว เช่น Continuous Health Monitoring Platform (CHAMP) ระบบมอนิเตอร์งาน multiarch และ CogniPort ระบบ agent ที่ช่วยทดสอบการ build และ test หากพบปัญหาข้อผิดพลาดขึ้น จะมี agnt อีกตัวมาช่วยแก้โค้ดให้อัตโนมัติ ตามภาพ
อีกเทคนิคที่ใช้คือการนำโค้ดที่ระบบอัตโนมัติสร้างขึ้น (จำนวน 38,156 commits) มาให้ Gemini วิเคราะห์ว่าโค้ดแต่ละส่วนทำอะไร จัดเป็นหมวดหมู่การแก้ปัญหา แล้วแปลงเป็นชาร์ทออกมาดูว่าทำอะไรไปบ้าง ซึ่งพบว่างานส่วนใหญ่ในช่วงแรกเป็นการพัฒนาเครื่องมือและระบบทดสอบ (สีฟ้าอ่อน) ก่อนค่อยๆ เปลี่ยนเป็นการแปลงโค้ด
กูเกิลบอกว่าตอนนี้ยังมีแอพพลิเคชันอีกหลายหมื่นตัวรอแปลงโค้ดต่อ ซึ่งจะใช้แนวทางอัตโนมัติทำงานต่อไปเรื่อยๆ ส่วนโค้ดใหม่ที่ถูกเขียนขึ้นในอนาคตจะเป็น multiarch โดยดีฟอลต์ทั้งหมดแล้ว
ที่มา - Google Cloud Blog
mk Tue, 28/10/2025 - 08:24
Continue reading...