Shipyard: บันทึกการสร้างแพลตฟอร์ม EC2 รุ่นถัดไปของ Slack

 (slack.engineering)
2 คะแนน โดย GN⁺ 1 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • Slack เปลี่ยนจากแนวทางเดิมที่คอยแก้ไข EC2 ที่รันระยะยาวอย่างต่อเนื่อง มาเป็น การดีพลอยแบบแทนที่บนพื้นฐาน AMI ที่ไม่เปลี่ยนรูป ทำให้ใช้วิธีดีพลอยสมัยใหม่กับเวิร์กโหลดที่ย้ายไปคอนเทนเนอร์ได้ยาก
  • สร้างอิมเมจเฉพาะบริการซ้อนบน slack-zero ซึ่งเป็นอิมเมจฐานร่วม โดยจัดการคอนฟิกที่หนักในขั้นตอน bake อิมเมจ และใช้เฉพาะข้อมูลลับกับเมตาดาต้าตามสภาพแวดล้อมตอนบูต
  • ตัว orchestrator การดีพลอย Gondola จัดการ AMI และอาร์ติแฟกต์ Chef ที่ระบุเวอร์ชันเป็นหน่วยดีพลอยเดียวกัน และทำการดีพลอยแบบเป็นขั้นตามเมตริก การหยุด และการ rollback อัตโนมัติ
  • Peekaboo ให้ inventory ของ EC2 ทั้งหมดแบบเกือบเรียลไทม์ และ The Reaper แทนที่อินสแตนซ์ที่ปนเปื้อนหรือหมดอายุ ภายใต้การจำกัดอัตราและกลไก pause
  • แนวทางนี้ได้ผลกับบริการอายุสั้น แต่สำหรับ อินสแตนซ์ระยะยาว ที่แทนที่อย่างรวดเร็วไม่ได้ เช่น data node, GitHub Enterprise และ Atlassian JIRA ยังต้องมีวิธี patch และตัวรันการดีพลอยแยกต่างหาก

ข้อจำกัดของโมเดล EC2 ที่แก้ไขอย่างต่อเนื่อง

  • Slack เปลี่ยนสแต็ก Chef เดี่ยวเดิมให้เป็นโครงสร้างหลายสแต็กที่ทนทานกว่า และนำการดีพลอย cookbook แบบระบุเวอร์ชันกับขั้นตอนเลื่อนระดับอย่างปลอดภัยมาใช้ เพื่อเพิ่มความน่าเชื่อถือและการควบคุมการปฏิบัติการสำหรับอินสแตนซ์ EC2 หลายหมื่นตัว
  • จากนั้นได้นำสภาพแวดล้อม production ที่แบ่งส่วน การรัน Chef ตามสัญญาณ และวิธี rollout ที่ปรับปรุงแล้วมาใช้ ทำให้ทีมลด ขอบเขตผลกระทบ ของเหตุขัดข้องได้มากโดยไม่ต้องเขียน cookbook ใหม่
    • ในขั้น Safety Without Disruption ทีมมีเวลาวางแผนสถาปัตยกรรมในอนาคตไปพร้อมกับรักษาแพลตฟอร์ม legacy ให้เสถียร
  • อย่างไรก็ตาม โมเดลที่อัปเดตอินสแตนซ์ระยะยาวต่อเนื่องทำให้การดีพลอยรายบริการทำได้ยาก หลีกเลี่ยง infrastructure drift ไม่ได้ และยิ่งต้องประสานการเปลี่ยนแปลงหลายชั้นก็ยิ่งซับซ้อน
  • คอนเทนเนอร์ช่วยแก้ปัญหาของบางเวิร์กโหลดได้ แต่ไม่ใช่ทุกระบบที่ย้ายได้ง่าย จึงต้องมีแพลตฟอร์มที่นำความไม่เปลี่ยนรูป การดีพลอยแบบเป็นขั้น และกลไกความปลอดภัยอัตโนมัติมาใช้กับ EC2 โดยตรง

โมเดลปฏิบัติการ EC2 ที่ Shipyard มอบให้

  • Shipyard คือแพลตฟอร์ม EC2 รุ่นถัดไปของ Slack ที่มอง infrastructure เป็นอาร์ติแฟกต์ที่ดีพลอยได้ ไม่ใช่อินสแตนซ์ที่ต้องคอยแก้ไขต่อเนื่อง
  • ผสานความสามารถในการดีพลอยรายบริการเข้ากับระบบ build และ orchestration เพื่อนำความปลอดภัยและความคาดการณ์ได้ในระดับเดียวกับแพลตฟอร์มดีพลอยแอปพลิเคชันมาใช้กับการอัปเดต EC2

  • รองรับหลายสถาปัตยกรรมและระบบปฏิบัติการ

    • รองรับสถาปัตยกรรม CPU หลายแบบ รวมถึง AMD64 และ Graviton บน ARM และใช้ Ubuntu, RHEL, Amazon Linux ได้
    • ทีมสามารถเลือกอินสแตนซ์และระบบปฏิบัติการตามต้นทุน ประสิทธิภาพ และความเข้ากันได้ โดยไม่ต้องทำแพลตฟอร์มแยก
    • เหมาะเป็นพิเศษกับ คอมโพเนนต์ infrastructure, worker node ของ Kubernetes และสแต็กเครือข่าย egress ที่ย้ายไปคอนเทนเนอร์ได้ยาก

  • การดีพลอยที่ปลอดภัยตามเมตริก

  • provisioning ที่รวดเร็วและคาดการณ์ได้

    • ใช้โครงสร้าง อิมเมจแบบเป็นชั้น คล้ายคอนเทนเนอร์ เพื่อสร้างอิมเมจเฉพาะบริการบน golden base image ร่วม
    • ลดงานที่ต้องทำตอนรัน ทำให้อินสแตนซ์ในหลาย region เริ่มทำงานได้รวดเร็วและสม่ำเสมอ

  • การจัดการคอนฟิกที่ง่ายขึ้น

    • ในอดีต งาน Chef ตามตารางจะตรวจสอบและนำคอนฟิกกลับมาใช้ซ้ำเป็นระยะ เพื่อย้อนการเปลี่ยนแปลงด้วยมือหรือการเปลี่ยนแปลงที่ไม่คาดคิดกลับสู่สถานะที่ต้องการ
    • ใน Shipyard จะใช้คอนฟิกเฉพาะในช่วง lifecycle ที่ชัดเจน เช่น image baking และ initial provisioning
    • เครื่องมือจัดการคอนฟิกถูกใช้เป็นหลักเพื่อดีพลอยบริการ แทนที่จะคอยแก้ไขทั้งระบบต่อเนื่อง
    • ส่งผลให้โหลดเบื้องหลังและการเขียนทับที่ไม่ได้ตั้งใจลดลง และเพราะอินสแตนซ์ไม่เปลี่ยนไปเรื่อยๆ ตามเวลา จึงคาดเหตุผลพฤติกรรมได้ง่ายขึ้น

  • อินสแตนซ์ที่มีอายุจำกัด

    • กำหนด อายุจำกัด ให้แต่ละอินสแตนซ์และแทนที่อัตโนมัติเป็นระยะ
    • ลดเวลาที่ช่องโหว่แฝงอาจก่อปัญหา และผลักดันให้ทีมแทนที่อินสแตนซ์แทนการแก้ไขอินสแตนซ์ที่กำลังรัน

Inventory Peekaboo และการมองเห็นทั้ง fleet

  • Peekaboo คือระบบ inventory ที่ใช้ cloud event และเมตาดาต้าอินสแตนซ์แทน Chef Server เพื่อแสดงสถานะ fleet EC2 แบบเกือบเรียลไทม์
  • ติดตามอินสแตนซ์ที่ดีพลอยนอก Shipyard ด้วย ทำให้เห็น fleet ทั้งหมดได้ในที่เดียว
  • สร้างด้วย AWS EventBridge, OpenSearch และ Lambda พร้อมอินเทอร์เฟซต่อไปนี้
    • UI สำหรับสำรวจ fleet
    • API สำหรับการผสานระบบ
    • CLI สำหรับตรวจสอบผ่าน command line อย่างรวดเร็ว
  • รวมศูนย์ข้อมูล EC2 เพื่อทำให้ telemetry และจุดจัดการทั่วทั้งสภาพแวดล้อมเป็นหนึ่งเดียว

slack-zero golden base image

  • slack-zero คือ machine image ร่วมที่ Compute Platform Team สร้างและดูแลร่วมกับทีม security และ monitoring
  • เป็นฐานมาตรฐานและเชื่อถือได้ที่ทุกบริการสืบทอด โดยทีมบริการกำหนด runtime environment ของตนเองบนฐานนี้
  • อิมเมจประกอบด้วยองค์ประกอบต่อไปนี้
    • baseline ของระบบปฏิบัติการและการตั้งค่า hardening ด้านความปลอดภัย
    • คอนฟิก networking และ service discovery
    • monitoring agent และ security agent
    • เครื่องมือร่วมและคอนฟิกระบบพื้นฐาน
  • base image ถูกมองเป็นสิ่งที่ ไม่เปลี่ยนรูปและชั่วคราว
    • หากต้องมี security patch, monitoring update หรือการปรับปรุง networking จะสร้างอิมเมจ slack-zero ใหม่
    • อิมเมจบริการชั้นล่างจะ build ใหม่บนฐานใหม่เพื่อรับการแก้ไขเหล่านั้น

  • เหตุผลที่เลือก AWS Image Builder

    • slack-zero สร้างด้วย AWS Image Builder แทน Packer แบบเดิม
    • lifecycle policy ล้าง AMI เก่าอัตโนมัติ ลดต้นทุน storage
    • เมื่อสร้างอิมเมจใหม่ จะอัปเดตพารามิเตอร์ AWS Systems Manager (SSM) ที่ชี้ไปยัง AMI ล่าสุดของแต่ละบัญชี และ pipeline ของบริการจะอ่านค่านี้เพื่อใช้ฐานล่าสุด
    • เมื่อ image baking สำเร็จ EventBridge และ Lambda จะเริ่ม sub-pipeline ในบัญชีของเจ้าของบริการโดยอัตโนมัติ
    • รัน validation test บนอินสแตนซ์ชั่วคราวก่อน publish AMI เพื่อลดความเสี่ยงของ rollout ไป production

การ bake และ provisioning อิมเมจบริการ

  • แต่ละทีมบริการสร้าง AMI ของตนเองบนฐาน slack-zero โดยสืบทอดคอมโพเนนต์แพลตฟอร์มร่วม และยังควบคุม runtime environment ได้
  • pipeline อิมเมจบริการกำหนดรายการต่อไปนี้
    • ซอฟต์แวร์ที่จะติดตั้ง
    • วิธีคอนฟิกบริการ
    • ขั้นตอน initialization ของอินสแตนซ์สำหรับบริการนั้น
  • รวมคอนฟิกส่วนใหญ่ไว้ในอิมเมจเพื่อเพิ่มความเร็วและความสม่ำเสมอในการรัน และลด configuration drift ให้เหลือน้อยที่สุด

  • แยกบทบาทเป็นสองขั้น

    • ใน ขั้นตอน baking จะติดตั้งแพ็กเกจและคอนฟิกที่ใช้ร่วมกันข้ามสภาพแวดล้อม เพื่อให้อินสแตนซ์มีสถานะพร้อมใช้งานเป็นส่วนใหญ่ก่อนเริ่มรัน
    • ใน ขั้นตอน provisioning จะใช้เฉพาะการตั้งค่าที่ขึ้นกับสภาพแวดล้อมตอนบูต เช่น ข้อมูลลับ คอนฟิกตาม region และเมตาดาต้าการดีพลอย
    • โดยทั่วไปทำเพียงวางไฟล์คอนฟิก ดึงข้อมูลลับ และเริ่มบริการ
    • ย้ายงานหนักอย่างการติดตั้งแพ็กเกจไปไว้ใน baking ทำให้อินสแตนซ์ พร้อมทำงานภายในไม่กี่วินาที แทนที่จะใช้หลายนาที
    • การเริ่มต้นเร็วสำคัญต่อเหตุการณ์ scaling, sequential deployment และการแทนที่อินสแตนซ์อัตโนมัติ ส่วน provisioning ที่น้อยที่สุดช่วยยับยั้ง drift ที่เกิดระหว่างกระบวนการปรับตัวตอน runtime

การอัปเดต fleet โดยเน้นการแทนที่ AMI

  • การเปลี่ยนแปลงจะสร้าง AMI ใหม่แล้ว rollout ผ่าน deployment pipeline โดยอัปเดต fleet ด้วย การแทนที่ที่ควบคุมได้ แทนการ patch อินสแตนซ์เดิม
  • Auto Scaling Group (ASG) ใช้ AWS Instance Refresh ส่วน fleet worker ของ Kubernetes ใช้ Karpenter
  • บริการที่มีข้อกำหนดการดีพลอยพิเศษสามารถเพิ่ม executor แยกได้ และ Gondola รวมแพตเทิร์นต่างๆ ให้เป็นประสบการณ์การดีพลอยที่สม่ำเสมอ

  • เส้นทางแก้ไขฉุกเฉิน

    • ในสถานการณ์ฉุกเฉิน สามารถใช้การเปลี่ยนคอนฟิกแบบจำกัดกับอินสแตนซ์ที่กำลังรันได้ แต่หลังจากนั้นต้องแทนที่อินสแตนซ์ดังกล่าวผ่าน deployment pipeline ปกติ
    • ใช้เอกสารที่กำหนดไว้ล่วงหน้าของ AWS Systems Manager เพื่อรัน Chef recipe ที่เลือกและใช้ การแก้ไขฉุกเฉิน
    • เมื่อระบบเสถียรแล้ว จะหมุนเวียนอินสแตนซ์กลับสู่สถานะ immutable ที่ตั้งใจไว้

การดีพลอยแบบเป็นขั้นของ Gondola

  • pipeline ของลูกค้าสามารถประกอบด้วยหลายขั้นตามข้อกำหนดของบริการและการปฏิบัติการ
  • แต่ละขั้นของ Gondola แทนหน่วยดีพลอยหนึ่งหน่วย เช่น ASG, Kubernetes cluster หรือกลุ่มอินสแตนซ์ EC2
  • Egress Team วาง canary และ production ASG แยกกันในแต่ละ availability zone และจัดขั้นให้การอัปเดตไหลไปตามลำดับ
  • Gondola เฝ้าดูเมตริกสำคัญระหว่างอัปเดตแต่ละขั้น และหากพบปัญหาจะ rollback อัตโนมัติเพื่อป้องกันการลุกลามของเหตุขัดข้อง

  • อาร์ติแฟกต์การดีพลอยและ executor

    • แพ็กเกจการดีพลอยที่ Gondola สร้างประกอบด้วยสองส่วน
      • AMI ที่จะดีพลอยไปยัง fleet
      • Chef artifact ที่มี recipe ระบุเวอร์ชันเชื่อมกับ Git commit
    • ถือสององค์ประกอบนี้เป็นหน่วยดีพลอยเดียวกัน และแต่ละขั้น rollout ผ่าน executor ที่บริการกำหนด
    • ในการดีพลอย ASG executor จะอัปเดต launch template ด้วย AMI และคอนฟิกใหม่
    • โค้ด Chef ถูกแพ็กเกจไว้ใน Amazon S3
    • bootstrapper ในตัวของอินสแตนซ์ใหม่จะดึง artifact ที่ถูกต้องและรัน recipe ที่เกี่ยวข้อง
    • ใช้เมตาดาต้าคอนฟิกเพื่อใช้เฉพาะการตั้งค่าที่เหมาะกับ role นั้น
    • ใน fleet worker ของ Kubernetes executor จะส่ง AMI ที่จะใช้กับ Karpenter และเมตาดาต้าคอนฟิกเดียวกัน โดย node จะ bootstrap ด้วยวิธีเดียวกัน
    • แม้เพิ่ม executor สำหรับการดีพลอยเฉพาะทาง รูปแบบ AMI, artifact คอนฟิกระบุเวอร์ชัน และ bootstrap ตามเมตาดาต้าจะยังคงเดิม

การแบ่งความรับผิดชอบระหว่างทีมแพลตฟอร์มและทีมบริการ

  • ทีม Compute, Security และ Monitoring จัดการคอมโพเนนต์ infrastructure ทั่วโลกของชั้นฐาน, security patch และการตั้งค่าที่จำเป็น
  • ทีมบริการสร้าง AMI ที่เพิ่มซอฟต์แวร์ของตนเองและการตั้งค่าเฉพาะบริการบนฐานนั้น
  • เมื่อทีม Compute ดีพลอย security patch, monitoring agent หรือการเปลี่ยนแปลง networking ทีมบริการต้องนำ base image ที่อัปเดตแล้วไปสะท้อนใน AMI ของตนเอง
  • โมเดลความรับผิดชอบร่วม นี้รักษา autonomy ของแต่ละบริการไปพร้อมกับปรับ fleet ให้มีความสม่ำเสมอ ความปลอดภัย และความน่าเชื่อถือ

ไม่ได้ immutable อย่างสมบูรณ์: ข้อยกเว้นเรื่องข้อมูลลับ

  • แพ็กเกจและคอนฟิกของอินสแตนซ์ Shipyard ส่วนใหญ่ถูกตรึงตอน baking แต่ ข้อมูลลับ เป็นข้อยกเว้น
  • บริการ Consul Template ของแต่ละอินสแตนซ์เผยแพร่ข้อมูลลับใหม่จาก Vault โดยไม่ต้องแทนที่ fleet
  • เพราะ credential หรือ certificate สามารถอัปเดตแบบไดนามิกได้ Shipyard จึงเป็น semi-immutable infrastructure ที่ตรึงเฉพาะระบบหลักและชั้นบริการ
  • ยังคงรักษาเสถียรภาพและความคาดการณ์ได้ พร้อมกับอัปเดตข้อมูลลับสำคัญใน runtime ได้เมื่อจำเป็น

นโยบายการแทนที่ของ The Reaper

  • The Reaper ตัดสินใจเป้าหมายการแทนที่จาก input สองประเภท
    • สัญญาณปนเปื้อนจากระบบภายนอก เช่น เครื่องมือความปลอดภัยหรือ event ของ AWS EC2 ที่แจ้งว่าอินสแตนซ์หลุดจากสถานะที่ต้องการ
    • การตรวจสอบตามรอบว่าอินสแตนซ์รันนานเกินอายุสูงสุดที่อนุญาตหรือไม่
  • หากเข้าเงื่อนไขใดเงื่อนไขหนึ่ง จะกำหนดเวลาการแทนที่อินสแตนซ์ตามนโยบายของบริการ
  • อนุญาตการเข้าถึง remote ด้วยมือสำหรับกรณีฉุกเฉิน แต่หากเชื่อมต่อโดยตรงไปยัง node ระดับ production จะเกิดสัญญาณและทำเครื่องหมายอินสแตนซ์นั้นเป็นเป้าหมายแทนที่ในอนาคต
  • ผสานกับ Peekaboo เพื่อติดตามอายุอินสแตนซ์ทั่วทั้ง fleet และ node ที่ถึงอายุสูงสุดจะทำตามขั้นตอน graceful shutdown และแทนที่เดียวกัน
  • ในอนาคตมีแผนเพิ่มความสามารถรู้บริบท เพื่อให้เฉพาะ การเปลี่ยนแปลงที่มีความหมาย เช่น software update หรือ configuration drift เท่านั้นที่ทำให้เกิดการแทนที่ ส่วนงาน read-only หรือความเสี่ยงต่ำจะไม่สร้างการหมุนเวียนที่ไม่จำเป็น

  • ความเร็วในการแทนที่และการควบคุมฉุกเฉิน

    • rate limit ในตัวกำหนดจำนวนอินสแตนซ์ที่แทนที่ได้ในครั้งเดียวตามบริการ region และ availability zone เพื่อป้องกันผลกระทบต่อ capacity แบบฉับพลัน
    • มี “big red button” ซึ่งเป็นกลไก pause ระดับ global โดยวาง control object ใน S3 เพื่อหยุดกิจกรรมทั้งหมดของ Reaper ในช่วงเกิดเหตุขัดข้องหรือช่วงที่มีความเสี่ยงสูง
    • ใช้ CLI จัดการ rate limit ตรวจสอบคอนฟิก และเปิดหรือปิด global pause
    • ในสถานการณ์ break-glass ที่ต้องตรวจสอบเชิงลึก สามารถใช้วิธีเข้าถึงที่ควบคุมได้ เช่น SSH certificate อายุสั้น

การทดสอบ infrastructure จริงด้วย Ship Quick

  • Ship Quick คือ workflow สำหรับนักพัฒนาที่ให้ทีมแพลตฟอร์มและเจ้าของบริการรันทดสอบ baking และ provisioning ที่สมจริงบน infrastructure จริง ก่อน merge pull request
  • นักพัฒนารันคำสั่ง CLI ใน repository cookbook และกำหนด test case ด้วยไฟล์ YAML
  • Ship Quick ทำงานตามลำดับต่อไปนี้
    • แพ็กเกจ cookbook และอัปโหลดไป S3
    • ส่งข้อความ workflow ไปยัง queue
    • worker instance ที่ Longshoremen จัดการรับงาน
    • worker ถูกแยกออกจาก Auto Scaling Group แล้วรัน workflow Chef
    • สตรีม log ไปยัง CLI แล้วจึงสิ้นสุด หรือ developer อาจเลือกเก็บไว้เพื่อ debugging

  • fleet worker ตามชั้นฐาน

    • เนื่องจากโครงสร้าง bootstrap จึงต้องรัน fleet worker แยกสองชุด
    • fleet Ubuntu พื้นฐาน ใช้ bake และทดสอบ base image จาก Ubuntu AMI ที่สะอาด เพราะ slack-zero ไม่สามารถ build ตัวเองบนตัวเองได้
    • fleet slack-zero ใช้ทดสอบ cookbook ของทีมบริการที่พึ่งพา slack-zero ที่ bake ไว้ล่วงหน้า
    • ตรวจสอบ provisioning บนฐานเดียวกับ production
    • อัปเดตเป็นอิมเมจล่าสุดอย่างต่อเนื่องเพื่อสะท้อนสภาพแวดล้อม production ปัจจุบัน
    • ทั้งสอง fleet auto scale ตาม demand
    • ทีมที่สร้างอิมเมจในบัญชี AWS ของตนเองสามารถตั้งค่า fleet worker เฉพาะและส่งงาน Ship Quick ไปยัง fleet นั้นเพื่อรักษาการแยกส่วน

การขยายไปยังเวิร์กโหลดระยะยาว

  • ปัจจุบัน Shipyard ทำงานได้อย่างมีประสิทธิภาพกับ บริการอายุสั้น และยังคง onboarding ทีมจากแพลตฟอร์ม EC2 legacy ต่อไป
  • ความท้าทายถัดไปคืออินสแตนซ์ระยะยาวที่หมุนเวียนอย่างรวดเร็วไม่ได้
    • data node ของ Slack
    • บริการ singleton อย่าง GitHub Enterprise
    • อินสแตนซ์เทคโนโลยีธุรกิจของบุคคลที่สามอย่าง Atlassian JIRA
  • เวิร์กโหลดเหล่านี้ต้องมีวิธี patch และ update ที่ปลอดภัย รวมถึง lifecycle policy ที่ The Reaper จัดการได้อย่างถูกต้อง
  • กำลังร่วมมือกับทีมบริการเพื่อพัฒนา executor สำหรับเวิร์กโหลดระยะยาว ของ Gondola และเมื่อการใช้งานขยายวง จะปรับปรุงเครื่องมือ workflow นักพัฒนา และประสบการณ์ดีพลอยอย่างต่อเนื่อง
  • ในอนาคตมีแผนกล่าวถึงองค์ประกอบของ Shipyard API, image pipeline, workflow นักพัฒนา, inventory system และปัญหาที่เกิดขึ้นระหว่างการขยายแพลตฟอร์มแยกต่างหาก

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น