GitHub Actions หรือ CircleCI: งาน Docker 40 นาทีอาจเหลือ 18 นาที

สำหรับทีมที่เก็บโค้ดบน GitHub อยู่แล้ว GitHub Actions เป็นตัวเลือกเริ่มต้นที่ดูแลได้ในระบบเดิม ส่วน CircleCI น่าสนใจเมื่อเวลารอผลทดสอบเป็นคอขวด: บันทึกการทดลองของ Kunal Ganglani ระบุว่าชุดทดสอบใน monorepo ที่มีงานสร้าง Docker image ใช้เวลาลดจาก 40 เหลือ 18 นาที หลังใช้การแบ่งชุดทดสอบร่วมกับ Docker Layer Caching บน CircleCI ตัวเลขนี้เป็นผลของงานและการตั้งค่าที่ผู้เขียนรายงาน ไม่ใช่เวลาที่ทุกทีมจะได้รับ

การเลือกจึงต้องแยกเวลาที่ผู้พัฒนารอผลจากนาทีประมวลผลรวมที่ถูกคิดเงิน งานทดสอบที่รันพร้อมกันอาจเสร็จเร็วขึ้นสำหรับคนรอ แต่ใช้ทรัพยากรหลายชุดในเวลาเดียวกัน ส่วนแคชอาจลดเวลาสร้าง image ได้เมื่อชั้นเดิมนำกลับมาใช้ได้ และมีค่าเครดิตเพิ่มบน CircleCI ทีมที่ pipeline ยังเสร็จทันจังหวะรวมโค้ดอาจได้ประโยชน์จากความสะดวกของ GitHub Actions มากกว่าความเร็วที่ต้องจ่ายเพิ่ม

นาทีของสองระบบมีราคาไม่เท่ากัน

สำหรับ repository ส่วนตัวขององค์กรบน GitHub Free เอกสารคิดเงินของ GitHub Actions ระบุโควตา runner มาตรฐาน 2,000 นาทีต่อเดือน และอัตราเมื่อเกินโควตา 0.006 ดอลลาร์ต่อนาทีสำหรับ Linux แบบ 2 คอร์ หรือ 0.010 ดอลลาร์ต่อนาทีสำหรับ Windows แบบ 2 คอร์ ค่าใช้งานตกกับเจ้าของ repository ไม่ได้แยกตามคนที่สั่งรัน งานบน repository สาธารณะที่ใช้ runner มาตรฐานมีเงื่อนไขใช้ฟรีต่างจากตัวอย่าง repository ส่วนตัวในบทความนี้

โควตาของ GitHub ผูกกับแผนบัญชีหรือองค์กร จึงต้องระบุแผนก่อนนำตัวเลขไปทำงบ อีกทั้งบิลอาจมีค่าพื้นที่เก็บ artifact และ cache เมื่อใช้เกินสิทธิ์ที่รวมมา การคิดเฉพาะค่านาที runner เหมาะกับการแยกผลของเครื่องประมวลผล แต่ยังไม่ใช่ยอดรวมของบริการทั้งหมด โดยเฉพาะ pipeline ที่เก็บผลทดสอบหรือไฟล์สำหรับ deploy จำนวนมาก

CircleCI ใช้เครดิตเป็นหน่วยกลาง หน้าราคาของ CircleCI ระบุเครดิตฟรี 30,000 เครดิตต่อเดือน ผู้ใช้งานจริงที่รวมอยู่ 5 คน และตัวอย่าง Linux Medium ที่ใช้ 10 เครดิตต่อนาที ดังนั้นเครดิตฟรีจำนวนนี้เท่ากับ 3,000 นาทีบนทรัพยากรดังกล่าว เครดิตเพิ่มขายเป็นชุดละ 25,000 เครดิตในราคา 15 ดอลลาร์ แต่ขนาดเครื่องและคุณสมบัติที่เปิดใช้ทำให้อัตราใช้เครดิตเปลี่ยนได้

ตัวเลขเวลาฟรีที่เห็นบนหน้าราคาอาจอ้างถึงเครื่องคนละขนาด เช่น นาทีของ Docker ขนาด Small จึงใช้แทน Linux Medium ในสมการเดียวกันไม่ได้ สำหรับทีมในไทย ตัวอย่างต่อไปนี้ใช้ดอลลาร์ตามราคาที่ประกาศ และไม่สมมติอัตราแลกเปลี่ยนเงินบาทหรือภาษี เพราะทั้งสองรายการขึ้นกับวิธีชำระเงินและช่วงเวลาที่ออกบิล

สูตรเปรียบเทียบเบื้องต้นคือ GitHub: นาที Linux รวมลบโควตาที่รวมในแผน แล้วคูณอัตราต่อนาที ส่วน CircleCI: นาทีประมวลผลคูณเครดิตต่อนาที บวกเครดิตผู้ใช้งานจริงและคุณสมบัติเสริม จากนั้นหักเครดิตฟรี หากต้องซื้อเครดิตเพิ่มเป็นชุด ค่าใช้จ่ายที่ชำระในเดือนนั้นอาจสูงกว่ามูลค่าเครดิตที่ใช้จริง เพราะเครดิตที่ซื้อแต่ยังไม่ใช้คงเหลือไว้สำหรับรอบต่อไปได้ภายใต้เงื่อนไขของแผน

ค่าผู้ใช้กับแคชเปลี่ยนจุดคุ้มทุน

คู่มือเครดิตของ CircleCI ระบุค่าผู้ใช้งานจริงส่วนเพิ่ม 25,000 เครดิตต่อคนต่อเดือน และค่า Docker Layer Caching 200 เครดิตต่อ job ที่รัน ผู้ใช้งานจริงหมายถึงคนที่กระตุ้นการใช้ทรัพยากรในโครงการส่วนตัว เช่น commit ที่เริ่ม build หรือสั่งรัน job ซ้ำ จึงไม่ควรใช้เพียงจำนวนบัญชีที่ได้รับเชิญมาคิดค่าที่นั่ง

การเปิดแคชให้ทุก job ที่สร้าง image ไม่ได้แปลว่าทุก job จะประหยัดเวลาเท่ากัน ผลขึ้นกับว่ามีชั้น image ที่ไม่เปลี่ยนและนำกลับมาใช้ได้มากเพียงใด หากขั้นตอนต้นของ Dockerfile เปลี่ยนบ่อย งานอาจต้องสร้างชั้นถัดไปใหม่เกือบทั้งหมด ในทางกลับกัน งานที่ใช้ dependency ชุดเดิมซ้ำและแก้เฉพาะโค้ดช่วงท้ายมีโอกาสได้ประโยชน์จากแคชมากกว่า

เครดิตค่าแคชคิดตามจำนวนครั้งที่ job รัน ไม่ใช่ตามจำนวนนาทีที่แคชช่วยประหยัด ถ้างานหนึ่งถูกแยกออกเป็นหลาย job หรือรันซ้ำหลายครั้ง จำนวนครั้งที่เสียเครดิตส่วนนี้ก็เพิ่มขึ้นด้วย ต้นทุนของ pipeline จึงต้องนับทั้งจำนวน build และรูปแบบการแบ่งงาน ไม่ใช่ดูเวลารอของการรันครั้งเดียว

จำลองทีม 1, 5 และ 20 คน

ตัวเลขต่อไปนี้เป็นกรณีสมมติเพื่อแยกผลของขนาดทีมกับสัดส่วนงาน Docker ทุกทีมใช้ repository ส่วนตัวบน GitHub Free กับ Linux runner แบบ 2 คอร์ และสมมติว่า CircleCI ใช้ Linux Medium นาทีประมวลผลเริ่มต้นของสองระบบเท่ากันก่อนปรับแคชหรือแบ่งงาน โดย job สร้าง Docker image แต่ละครั้งใช้เวลาเฉลี่ย 20 นาที สมาชิกทุกคนในแต่ละทีมถือเป็นผู้ใช้งานจริง ตัวอย่างยังไม่รวมภาษี พื้นที่เก็บข้อมูล และค่าทรัพยากรประเภทอื่น

• ทีม 1 คนใช้ 1,200 นาทีต่อเดือน โดยงาน Docker เป็น 10% หรือ 120 นาที เทียบได้กับ 6 job ตามสมมติฐาน GitHub ยังอยู่ในโควตา ส่วน CircleCI ใช้เครดิตประมวลผล 12,000 เครดิต จึงอยู่ในเครดิตฟรีเช่นกัน ค่า runner ตามแบบจำลองเป็นศูนย์ทั้งคู่
• ทีม 5 คนใช้ 6,000 นาที โดยงาน Docker เป็น 30% หรือ 1,800 นาที เทียบได้กับ 90 job GitHub เกินโควตา 4,000 นาที คิดเป็น 24 ดอลลาร์ CircleCI ใช้ 60,000 เครดิต เกินเครดิตฟรี 30,000 เครดิต จึงต้องซื้อเพิ่ม 2 ชุด รวม 30 ดอลลาร์ แม้เครดิตส่วนหนึ่งในชุดที่สองจะยังไม่ได้ใช้
• ทีม 20 คนใช้ 30,000 นาที โดยงาน Docker เป็น 60% หรือ 18,000 นาที เทียบได้กับ 900 job GitHub มีค่า runner 168 ดอลลาร์ CircleCI ใช้เครดิตประมวลผล 300,000 เครดิต บวกเครดิตผู้ใช้งานจริงส่วนเกินอีก 375,000 เครดิต หลังหักเครดิตฟรีต้องซื้อ 26 ชุด รวม 390 ดอลลาร์

หากเปิด Docker Layer Caching ให้ทุก job ที่สร้าง image โดยยังไม่สมมติว่างานเร็วขึ้น เครดิตค่าแคชเพิ่ม 1,200, 18,000 และ 180,000 เครดิตตามลำดับ ทีม 1 คนยังอยู่ในสิทธิ์ฟรี ทีม 5 คนยังซื้อ 2 ชุด ส่วนทีม 20 คนต้องซื้อ 33 ชุด หรือ 495 ดอลลาร์ ตัวเลขชุดหลังเป็นราคาของการเปิดคุณสมบัติก่อนหักนาทีประมวลผลที่อาจประหยัดได้ ไม่ใช่คำทำนายบิลหลังใช้แคชจริง

สัดส่วน Docker มีผลต่อโอกาสลดนาทีรวม แต่จำนวนสมาชิกมีผลต่อเครดิตผู้ใช้แยกต่างหาก ทีมที่มี Docker เพียงส่วนน้อยอาจลดค่าเครื่องได้ไม่มาก แม้ build บางครั้งจะเร็วขึ้นชัดเจน สำหรับทีมขนาดใหญ่ที่ทุกคนกระตุ้น pipeline ค่าใช้จ่ายส่วนผู้ใช้อาจกลายเป็นรายการหลักก่อนเริ่มคิดเรื่องแคชด้วยซ้ำ

เวลารอสั้นลงเมื่อไรจึงชดเชยเครดิต

ในกรณีศึกษาข้างต้น Docker build ที่ได้ warm cache ลดจาก 14 เหลือ 3 นาที หรือประหยัดเวลา 11 นาทีต่อ build ที่เข้าเงื่อนไข หากใช้ตัวเลขนั้นเป็นเพียงตัวอย่างคำนวณบน Linux Medium ของ CircleCI งานสั้นลงเหลือเครดิตประมวลผล 30 เครดิต แต่ต้องบวกค่าแคช 200 เครดิต รวม 230 เครดิต คิดเป็น 0.138 ดอลลาร์ตามราคาชุดเครดิต ขณะที่งาน Linux ของ GitHub ที่ใช้ 14 นาทีมีมูลค่าตามอัตราเกินโควตา 0.084 ดอลลาร์ ความเร็วที่ดีขึ้นในตัวอย่างนี้จึงมีราคาต่อ build สูงขึ้น

ค่าใช้จ่ายส่วนเพิ่มไม่ได้หมายความว่าแคชไม่คุ้ม ทีมที่รอผลก่อนรวมโค้ดอาจให้ค่ากับเวลาที่คืนมา แต่ต้องตีมูลค่านั้นแยกจากบิล CI หาก build เดิมใช้เครดิตประมวลผล 140 เครดิต การลดเวลาไป 11 นาทีประหยัดได้ 110 เครดิต ซึ่งยังน้อยกว่าค่าแคช 200 เครดิตต่อ job ภายใต้เงื่อนไขเดียวกัน จุดคุ้มค่าจึงขึ้นกับทั้งอัตราเครดิตของเครื่อง ระยะเวลาที่ลดได้ และผลกระทบของการรอต่อการทำงานของทีม

ผลชุดทดสอบที่ลดจาก 40 เหลือ 18 นาทีต้องอ่านต่างจากผล Docker build สมมติแบ่งชุดทดสอบ 40 นาทีออกเป็นงานขนานสองส่วนที่ใช้เวลาส่วนละ 20 นาที คนรอผลประมาณ 20 นาที แต่ runner สองตัวทำงานรวมกันยังราว 40 นาที การแบ่งงานอาจลดเวลารอมากโดยแทบไม่ลดนาทีที่ถูกคิดเงิน ส่วนผลในกรณีศึกษาผสมการแบ่งชุดทดสอบกับการใช้แคช จึงไม่สามารถยกผลต่างทั้งหมดให้คุณสมบัติอย่างใดอย่างหนึ่ง

สำหรับทีม 5 คนในแบบจำลอง หากยังไม่เปิดแคช CircleCI ต้องลดนาทีประมวลผลจาก 6,000 เหลือไม่เกิน 5,500 นาที จึงซื้อเครดิตเพิ่มเพียงชุดเดียวและจ่าย 15 ดอลลาร์ ต่ำกว่า GitHub ที่ 24 ดอลลาร์ แต่ถ้าเปิดแคชครบ 90 job เพดานนาทีประมวลผลเพื่อจ่ายเพียงชุดเดียวจะลดเหลือ 3,700 นาที งานที่ไม่ใช่ Docker ในสมมติฐานนี้ใช้ไปแล้ว 4,200 นาที การเร่งเฉพาะ Docker จึงพาทีมไปไม่ถึงเพดานนั้น

ทีม 20 คนมีข้อจำกัดต่างออกไป: เครดิตผู้ใช้งานจริงส่วนเกิน 375,000 เครดิต หักเครดิตฟรี 30,000 เครดิตแล้ว ยังต้องซื้ออย่างน้อย 14 ชุด หรือ 210 ดอลลาร์ แม้สมมติให้เวลาประมวลผลเป็นศูนย์ ยอดขั้นต่ำนี้ก็สูงกว่าค่า runner 168 ดอลลาร์ของ GitHub ในแบบจำลอง การเลือก CircleCI สำหรับทีมลักษณะนี้จึงต้องอาศัยมูลค่าของเวลารอที่ลดลงหรือความสามารถอื่นที่ทีมใช้จริง มากกว่าหวังว่าค่า CI รายเดือนจะต่ำกว่าเอง

ภาระย้ายงานมีทางเลือกเพิ่ม แต่ยังต้องนับ

ทีมที่ใช้ GitHub Actions สามารถปรับโครงสร้างงานเดิมก่อนเปลี่ยนบริการได้ เช่น แยกชุดทดสอบที่ไม่พึ่งพากัน ลดขั้นตอนที่รันซ้ำ และดูว่าการสร้าง image ใช้ชั้นเดิมได้มากเพียงใด หากการปรับเหล่านี้แก้เวลารอได้เพียงพอ ทีมก็ยังได้ความสะดวกจาก workflow ที่ผูกกับ repository และขั้นตอนรวมโค้ดเดิม การเทียบความเร็วควรใช้ชนิด runner และปริมาณงานใกล้เคียงกัน เพราะเครื่องที่ใหญ่กว่าย่อมเปลี่ยนทั้งเวลาและราคา

การย้ายไป CircleCI ไม่จำเป็นต้องเริ่มด้วยการเขียนไฟล์กำหนดค่าใหม่เสมอไป: คู่มือการใช้ไฟล์ GitHub Actions บน CircleCI ระบุว่ามีความสามารถนี้ในสถานะ Preview สำหรับ workflow บน Linux และรองรับคุณสมบัติของ GitHub Actions เพียงบางส่วน ทีมจึงต้องตรวจความเข้ากันได้ของ workflow ที่ใช้อยู่ โดยเฉพาะขั้นตอน build, ความลับ, เงื่อนไขเริ่มงาน และการส่งสถานะกลับไปยัง pull request

แม้ไฟล์ workflow เดิมจะรันได้ งานเชื่อมบัญชี ตั้งค่าโครงการ ตรวจผลทดสอบ และดูแลระบบ CI อีกแห่งยังใช้แรงทีมอยู่ หากเลือกแปลงเป็นรูปแบบของ CircleCI โดยตรง ภาระจะเพิ่มตามจำนวน job และเงื่อนไข deploy ที่สะสมไว้ ความต่างของบิลเพียงเล็กน้อยต่อเดือนจึงอาจไม่ชดเชยเวลาที่ต้องใช้ย้ายและดูแล โดยเฉพาะทีมเล็กที่งานเดิมยังเสร็จเร็วพอ

เกณฑ์เลือกที่มีความหมายคือเวลาจากเริ่ม pipeline จนได้ผลทดสอบ ผลรวมนาทีของทุก job เครดิตแคช จำนวนผู้ใช้งานจริง และภาระดูแล workflow ทีมที่ติดคอขวดจาก Docker build ซึ่งใช้ชั้นเดิมซ้ำบ่อยและแบ่งชุดทดสอบได้จริงมีเหตุผลจะพิจารณา CircleCI มากขึ้น ส่วนทีมที่เวลารอรับได้และใช้ GitHub เป็นศูนย์กลางอยู่แล้วอาจได้ประโยชน์มากกว่าจากการปรับ pipeline เดิมก่อน

อ่านเพิ่มเติม:

• GitHub Actions หรือ GitLab CI: นาทีถูกกว่าอาจสร้างเสร็จช้ากว่า
• ต่อ GitHub Actions เข้า AWS ด้วย OIDC: จำกัดสิทธิ์ถึง repo และ branch
• Cursor หรือ GitHub Copilot: ค่ารายเดือนต่ำไม่ได้ล็อกค่าเอเจนต์