- ดูแลคลาวด์รีซอร์สมากกว่า 165,000 รายการ บน 625 Terraform workspaces และ 38 AWS accounts
- จากวิศวกร 170 คน มี 40 คนที่เป็นผู้เชี่ยวชาญด้านโครงสร้างพื้นฐาน
- ทำการปล่อยโครงสร้างพื้นฐาน (
terraform apply) 225 ครั้งต่อวัน และรันแผน (terraform plan) 723 ครั้งต่อวัน
- เพื่อรองรับสิ่งนี้ จึงนำ Terraform Cloud มาใช้เพื่อทำให้กระบวนการปล่อยโครงสร้างพื้นฐานเป็นอัตโนมัติ และลดงานแมนนวลกับความผิดพลาดของนักพัฒนา
ปัญหาก่อนนำ Terraform Cloud มาใช้
- ต้องใช้สิทธิ์เข้าถึง AWS ระดับสูง : ทีมโครงสร้างพื้นฐานจำเป็นต้องมีสิทธิ์เข้าถึง AWS ในระดับสูง
- งานที่กินเวลา : ต้องรัน
terraform apply ในแต่ละไดเรกทอรี พร้อมทำการตรวจสอบและอนุมัติซ้ำไปมา และการเปลี่ยนแปลงเพียงครั้งเดียวอาจส่งผลต่อ workspace มากกว่า 120 แห่ง
- เกิด infrastructure drift : มีการเปลี่ยนแปลงที่ไม่คาดคิดสะสม ทำให้เมื่อ apply ต้องมีการตรวจสอบและจัดการเพิ่มเติม
การนำ Terraform Cloud มาใช้และผลลัพธ์
- กำจัด drift → กำจัด infrastructure drift เพื่อลดความเสี่ยงและภาระของนักพัฒนา
- ประหยัดเวลานักพัฒนา → ประหยัดเวลานักพัฒนาได้ ประมาณ 8,000 ชั่วโมงต่อปี (เทียบเท่าปริมาณงานของนักพัฒนา 4 คน)
- ติดตามการเปลี่ยนแปลงได้ → สามารถติดตามการเปลี่ยนแปลงผ่าน audit logs และดีบักได้ง่าย
- รองรับ speculative plans → ทดสอบการเปลี่ยนแปลงอัตโนมัติ และดูผลได้โดยตรงจาก GitHub CI
แนวทางการใช้งาน Terraform Cloud ในปัจจุบัน
- โฮสต์เอง : ติดตั้ง Terraform Cloud for Business เอง และรัน TFC agents บน ECS cluster ภายใน AWS account
- การจัด agent pools : ใช้งานเอเจนต์ 120 ตัว โดยแยกเป็น สภาพแวดล้อมพัฒนา (40 ตัว) และสภาพแวดล้อมโปรดักชัน (80 ตัว) เพื่อรักษาความสามารถในการประมวลผลพร้อมกันในระดับสูง
สิ่งที่เฝ้าติดตามเป็นหลัก
- เอเจนต์หมดและข้อจำกัดด้าน concurrency → หากเอเจนต์ไม่พอ จะมีการแจ้งเตือนผู้รับผิดชอบ on-call
- เวลาในการรัน plan → หากเวลา plan ในสภาพแวดล้อมพัฒนาเกิน 4 นาที จะมีการแจ้งเตือนไปยังทีม
- infrastructure drift → ปัจจุบันไม่ได้วัด (เพราะแทบไม่เกิด drift แล้ว)
การปรับแต่งเพื่อยกระดับคุณภาพ
- พัฒนา TFC CLI : เพื่อให้สามารถตรวจสอบและอนุมัติการเปลี่ยนแปลงในหลาย workspaces แบบอัตโนมัติผ่าน CLI
- สร้างระบบแจ้งเตือน : ทำระบบอัตโนมัติผ่านการแจ้งเตือนใน Slack เพื่อไม่ให้พลาดการ apply ของ Terraform
- จัดการ workspaces อัตโนมัติ : ใช้ Terraform ดูแล 625 workspaces และติดแท็กเพื่อแยกทีมเจ้าของ
- วิเคราะห์การใช้งาน Terraform Cloud : ใช้ TFC API เก็บข้อมูล state versions เพื่อดูการใช้รีซอร์สและแนวโน้มการเติบโต
- สำรอง Terraform State : สำรองไฟล์ state ไปยัง S3 bucket โดยอัตโนมัติ เพื่อให้กู้คืนได้เมื่อเกิดปัญหา
- จัดการ dependencies ของ workspaces : สร้าง module dependency tree เพื่อกำหนดไดเรกทอรีที่ workspace ต้องเฝ้าดูโดยอัตโนมัติ
- ทำ provider upgrades แบบอัตโนมัติ : ใช้ Dependabot อัปเกรด providers เป็นรายเดือน และลดภาระการดูแลด้วยระบบอัตโนมัติ
สิ่งที่จะปรับปรุงต่อไป
- ทยอย rollout เป็นลำดับขั้น : เปลี่ยนจากการปล่อยแบบอิง
main branch ไปเป็น การดีพลอยหลายขั้น (พัฒนา → staging → production)
- แยก workspace ขนาดใหญ่ออก : วางแผนแยก 625 workspaces ปัจจุบันให้ละเอียดเป็นมากกว่า 1500 แห่ง เพื่อ ลดเวลา plan และ apply และ ลดขอบเขตผลกระทบของการเปลี่ยนแปลง
- ปรับปรุงระบบแจ้งเตือน : เพิ่ม ความสามารถในการมอบหมายต่อ ในการแจ้งเตือน Slack และเพิ่มฟีเจอร์สร้างคำสั่ง
tfc review อัตโนมัติ
- auto scaling ของเอเจนต์ : มีแผนนำ ระบบ auto scaling บน EKS มาใช้เพื่อรองรับเวิร์กโหลดที่เปลี่ยนแปลงได้อย่างมีประสิทธิภาพ
- เปิดซอร์สเครื่องมือที่พัฒนาขึ้นเอง : วางแผนเปิดซอร์สเครื่องมือต่าง ๆ ที่พัฒนาภายใน เพื่อให้ทีมอื่นสามารถนำไปใช้ได้
ยังไม่มีความคิดเห็น