Blacksmith ได้บรรลุการปรับปรุงประสิทธิภาพอย่างมากสำหรับ GitHub Actions cache โดยการ reverse engineering โปรโตคอลภายในของแพลตฟอร์มและการใช้งาน transparent network proxying วิธีการนี้ให้ประสิทธิภาพ cache ที่เร็วขึ้นถึง 10 เท่าโดยไม่ต้องให้ผู้ใช้เปลี่ยนแปลงโค้ดใดๆ
ความท้าทายเริ่มต้นขึ้นเมื่อ GitHub ยกเลิกระบบ cache แบบเดิมเพื่อใช้บริการใหม่ที่ใช้ Twirp-based ด้วย Azure Blob Storage SDK แทนที่จะรักษา fork ของ action ยอดนิยม วิศวกรของ Blacksmith ตัดสินใจที่จะดักจับและเปลี่ยนเส้นทางคำขอ cache ในระดับเครือข่ายในขณะที่ทำให้ดูเหมือนว่ายังคงเข้าถึงเซิร์ฟเวอร์ของ GitHub
การปรับปรุงประสิทธิภาพ:
- ความเร็วแคช: เร็วกว่า GitHub Actions มาตรฐานถึง 10 เท่า
- ความเข้ากันได้: รองรับ workflow ที่มีอยู่ 100%
- การเปลี่ยนแปลงโค้ดที่ต้องการ: ศูนย์
- สถาปัตยกรรม: ระบบ proxy หลายชั้นพร้อม NGINX ระดับ VM และการจัดเส้นทางระดับโฮสต์
 |
|---|
| การแสดงภาพของการเพิ่มประสิทธิภาพและความมีประสิทธิผลทางเทคโนโลยีในประสิทธิภาพ cache ของ GitHub Actions |
Reverse Engineering โปรโตคอล Cache ใหม่ของ GitHub
ทีมงานใช้ความช่วยเหลือจาก AI เพื่อวิเคราะห์ network traffic และสร้างคำจำกัดความของโปรโตคอลสำหรับบริการ cache ใหม่ของ GitHub ขึ้นมาใหม่ พวกเขาค้นพบว่า GitHub ได้เปลี่ยนจากระบบที่ใช้ REST เป็นระบบที่ใช้ Protocol Buffers และ TWIRP สำหรับการสื่อสาร พร้อมกับการจัดเก็บข้อมูลโดยตรงไปยัง Azure Blob Storage ผ่าน signed URL
สมาชิกชุมชนคนหนึ่งที่ทำงานเกี่ยวกับ reverse engineering ที่คล้ายกันได้กล่าวถึงความซับซ้อนที่เกี่ยวข้อง โดยระบุว่าพวกเขาต้องสร้างไฟล์ protobuf จากโค้ดที่สร้างขึ้นจนกว่าจะได้ผลลัพธ์ที่ตรงกับข้อกำหนดต้นฉบับทุกไบต์ สิ่งนี้เน้นย้ำถึงความลึกทางเทคนิคที่จำเป็นสำหรับโปรเจ็กต์เช่นนี้
สถาปัตยกรรม Multi-Layer Network Proxying
Blacksmith ได้ใช้งานระบบ proxying ที่ซับซ้อนด้วยหลายชั้น ภายในแต่ละ virtual machine พวกเขาได้กำหนดค่าเซิร์ฟเวอร์ NGINX เพื่อส่งคำขอไปยัง host-level proxy การออกแบบนี้ช่วยให้พวกเขาสามารถรักษาสถานะสำหรับการอัปโหลดและดาวน์โหลดในขณะที่รับประกันการควบคุมการเข้าถึงที่เหมาะสม
Azure SDK นำเสนอความท้าทายที่ไม่คาดคิด เมื่อชื่อโฮสต์ไม่ตรงกับรูปแบบ blob.core.windows.net ของ Azure SDK จะปิดการใช้งานการปรับปรุงประสิทธิภาพแบบ concurrency หลายอย่าง ทำให้ประสิทธิภาพลดลงอย่างมาก ทีมงานต้องสร้าง URL ที่เข้ากันได้กับ Azure ขึ้นใหม่และใช้งานการจัดเส้นทาง traffic แบบกำหนดเองเพื่อรักษาประสิทธิภาพ
ส่วนประกอบของสถาปัตยกรรมทางเทคนิค:
- โปรโตคอล: บริการใหม่ของ GitHub ที่ใช้ Twirp พร้อม Protocol Buffers
- การจัดเก็บข้อมูล: Azure Blob Storage SDK พร้อม signed URLs
- การทำ Proxy: NGINX (ระดับ VM) → Host-level proxy → Custom S3-compatible backend
- การกรองแพ็กเก็ต: nftables (แทนที่ iptables เพื่อความเสถียรที่ดีกว่า)
- Backend: Self-hosted MinIO cluster (รองรับ S3-compatible)
จากความวุ่นวายของ iptables สู่ความแม่นยำของ nftables
ความพยายามเริ่มแรกในการใช้ iptables สำหรับการกรอง packet สร้างฝันร้ายในการดำเนินงาน ด้วย VM ชั่วคราวหลายตัวที่เพิ่มและลบกฎอย่างต่อเนื่อง ระบบกลายเป็นไม่เสถียรและยากต่อการจัดการ การอภิปรายในชุมชนเผยให้เห็นว่านี่เป็นปัญหาทั่วไป นักพัฒนาคนหนึ่งอธิบายว่า iptables ไม่มี programmatic interface ที่เสถียรและเป็นฝันร้ายของ race condition
วิธีแก้ไขมาจาก nftables ซึ่งเสนอการเปลี่ยนแปลงการกำหนดค่าแบบ atomic และความสามารถในการจัดกลุม namespace ที่ดีกว่า สิ่งนี้ช่วยให้ Blacksmith สามารถจัดการกฎต่อ VM โดยไม่มีความขัดแย้ง ทำให้ระบบเชื่อถือได้มากขึ้นในระดับขนาดใหญ่
ความท้าทายทางเทคนิคหลักที่ได้รับการแก้ไข:
- การจดจำ hostname ของ Azure SDK เพื่อการปรับปรุงประสิทธิภาพการทำงานพร้อมกัน
- ความไม่เสถียรของ iptables กับ ephemeral VMs ในระดับขนาดใหญ่
- การสร้าง Protocol buffer ใหม่จากโค้ดที่สร้างขึ้นของ GitHub
- การจัดการกฎแบบอะตอมิกด้วย nftables namespacing
- การทำ proxy สองทางระหว่างโปรโตคอล Azure Blob Storage และ AWS S3
ผลลัพธ์ด้านประสิทธิภาพและการตอบสนองของอุตสาหกรรม
การปรับปรุงมีความสำคัญมาก ลูกค้าเห็นความเร็วของ cache เร็วขึ้นถึง 10 เท่าด้วย throughput ที่สูงกว่ามากเมื่อเปรียบเทียบกับ GitHub Actions มาตรฐาน ที่น่าสังเกตคือสิ่งนี้ทำงานได้กับ workflow ที่มีอยู่ 100% โดยไม่ต้องแก้ไขโค้ดใดๆ
วิธีการนี้ได้รับความสนใจจากคู่แข่งในพื้นที่การเร่งความเร็ว CI/CD บริษัทบางแห่งได้ใช้งานกลยุทธ์การปรับปรุง cache ที่คล้ายกัน ในขณะที่บริษัทอื่นๆ เลือกที่จะสร้างแพลตฟอร์ม CI ใหม่ทั้งหมดแทนที่จะทำงานภายใต้ข้อจำกัดของ GitHub Actions
ที่ RWX เราเบื่อหน่ายกับการพยายามหาทางแก้ไขข้อจำกัดของแพลตฟอร์มด้วย self-hosted runner อย่างต่อเนื่อง เราจึงสร้างแพลตฟอร์ม CI ใหม่ทั้งหมดบนโมเดลการทำงานใหม่
ความสำเร็จทางเทคนิคนี้แสดงให้เห็นว่าความรู้เชิงลึกเกี่ยวกับระบบและ network engineering ที่สร้างสรรค์สามารถปรับปรุงประสิทธิภาพอย่างมากในสภาพแวดล้อม cloud CI/CD แม้ในขณะที่ทำงานภายใต้ข้อจำกัดของแพลตฟอร์มที่มีอยู่
อ้างอิง: Reverse engineering GitHub Actions cache to make it fast