วิธีที่ย้ายไปใช้ K8s ภายใน 12 เดือน

 (figma.com)
1 คะแนน โดย GN⁺ 2024-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การตั้งค่าคุกกี้และการสมัครรับจดหมายข่าว

  • เว็บไซต์นี้ใช้คุกกี้, พิกเซลแท็ก และ local storage เพื่อวัตถุประสงค์ด้านประสิทธิภาพ การปรับแต่งเฉพาะบุคคล และการตลาด
  • คุกกี้ที่จำเป็นเท่านั้นที่เปิดใช้งานเป็นค่าเริ่มต้น
  • สามารถสมัครรับจดหมายข่าวได้

การย้ายของ Figma ไปสู่ Kubernetes

  • ผู้เขียน: Ian VonSeggern, Engineering Manager ฝ่ายซอฟต์แวร์ของ Figma
  • หัวข้อ: กระบวนการและเหตุผลที่ Figma ย้ายไปใช้ Kubernetes ภายใน 12 เดือน

แพลตฟอร์มคอมพิวติ้งของ Figma

  • ต้นปี 2023 ได้ทำงานย้ายให้ทุกบริการรันอยู่ในคอนเทนเนอร์เสร็จสิ้น
  • ใช้ AWS Elastic Container Service (ECS) เพื่อเริ่มต้นงานแบบคอนเทนเนอร์ได้อย่างรวดเร็ว
  • ในมุมมองระยะยาว จึงเริ่มพิจารณาแพลตฟอร์มคอมพิวติ้งเวอร์ชันถัดไป

ข้อจำกัดด้านความสามารถของ Kubernetes ที่ขาดหายไป

  • ข้อจำกัดบางประการของ ECS ทำให้ต้องใช้เวลาเชิงวิศวกรรมจำนวนมาก
  • ECS ไม่มีความสามารถ StatefulSets ของ Kubernetes จึงทำให้รันคลัสเตอร์ etcd ได้ยาก
  • ขาดการรองรับการกำหนดบริการผ่าน Helm chart
  • เมื่อต้องรัน EC2 บน ECS การยุติเครื่อง EC2 เพียงเครื่องเดียวทำได้ยาก

การเข้าถึงระบบนิเวศของ Cloud Native Computing Foundation

  • เมื่อใช้ ECS จะไม่สามารถใช้เทคโนโลยีโอเพนซอร์สในระบบนิเวศ CNCF ได้
  • ระบบนิเวศของ Kubernetes มีความสามารถด้าน autoscaling ที่ยอดเยี่ยม
  • มีการพิจารณาความเป็นไปได้ในการนำ service mesh มาใช้

ข้อดีของแพลตฟอร์มยอดนิยม

  • Kubernetes ถูกใช้งานโดยองค์กรขนาดใหญ่จำนวนมาก จึงผ่านการพิสูจน์ด้านเสถียรภาพแล้ว
  • สามารถหลีกเลี่ยง vendor lock-in ได้
  • จ้างวิศวกรที่มีประสบการณ์กับ Kubernetes ได้ง่ายกว่า

การกำหนดขอบเขตของการย้ายระบบ

  • เพื่อลดความเสี่ยงของการย้ายระบบ ได้ลดการเปลี่ยนแปลงระบบแกนกลางให้น้อยที่สุด
  • ตั้งเป้าย้ายไปยัง EKS
  • ได้นำการปรับปรุงบางส่วนรวมไว้ในขอบเขตการย้ายระบบด้วย

การปรับปรุงที่รวมอยู่ในการย้ายระบบ

  • ประสบการณ์นักพัฒนา: ทำให้การกำหนดบริการและกระบวนการดีพลอยง่ายขึ้น
  • ความน่าเชื่อถือที่ดีขึ้น: ใช้ EKS สามคลัสเตอร์เพื่อเพิ่มความน่าเชื่อถือของบริการ
  • ความคุ้มค่าด้านต้นทุน: รองรับการขยายโหนดอัตโนมัติเพื่อลดค่าใช้จ่าย

งานที่ไม่รวมอยู่ในขอบเขต

  • ไม่รวมงานแก้ปัญหาความซับซ้อนของล็อกไปป์ไลน์
  • ไม่รวมงาน autoscaling ระดับพ็อด

การย้ายระบบอย่างปลอดภัย

  • การทดสอบโหลด: ทำ load test เพื่อทำความเข้าใจประสิทธิภาพของคลัสเตอร์
  • กลไก rollout แบบค่อยเป็นค่อยไป: ใช้รายการ DNS แบบถ่วงน้ำหนักเพื่อย้ายทราฟฟิกทีละน้อย
  • การรันบริการจริง: รันบริการจริงในสภาพแวดล้อม staging เพื่อค้นหาปัญหาได้ตั้งแต่เนิ่น ๆ
  • ลดการใช้ YAML แบบกำหนดเองให้น้อยที่สุด: ลดการนิยาม YAML ที่อาจทำให้ผู้ใช้สับสน
  • ทำงานใกล้ชิดกับเจ้าของบริการ: ร่วมมือกับเจ้าของบริการเพื่ออัปเดตการมอนิเตอร์และการแจ้งเตือน
  • การจัดสรรบุคลากรที่เหมาะสม: จัดทีมที่สามารถแก้ปัญหาที่ไม่คาดคิดได้

ผลลัพธ์ของการย้ายระบบ

  • ภายในเดือนมกราคม 2024 ได้ย้ายบริการหลักไปยังคลัสเตอร์ EKS
  • ได้ประโยชน์ทั้งด้านการลดต้นทุน ความน่าเชื่อถือที่ดีขึ้น และประสบการณ์นักพัฒนาที่ดีขึ้น

ช่วงหลังเปิดใช้งาน

  • ปรับปรุงเครื่องมือการเข้าถึงของผู้ใช้ผ่านการอนุมานคลัสเตอร์และบทบาทโดยอัตโนมัติ
  • มีแผนทำงานต่อในด้านการทำให้ล็อกไปป์ไลน์ง่ายขึ้น การรองรับ horizontal pod autoscaling และการย้ายไปใช้โปรเซสเซอร์ Graviton

สรุปโดย GN⁺

  • Figma บรรลุการลดต้นทุน เพิ่มความน่าเชื่อถือ และปรับปรุงประสบการณ์นักพัฒนา จากการย้ายจาก ECS ไปยัง Kubernetes
  • ใช้เทคโนโลยีโอเพนซอร์สในระบบนิเวศ CNCF เพื่อเพิ่มความเป็นไปได้ในการทำ autoscaling และนำ service mesh มาใช้
  • ระหว่างกระบวนการย้ายระบบ ได้ใช้วิธีที่ปลอดภัย เช่น load test, rollout แบบค่อยเป็นค่อยไป และการรันบริการจริง
  • หลังเปิดใช้งาน ได้ปรับปรุงเครื่องมือการเข้าถึงของผู้ใช้ และวางแผนงานเพิ่มเพื่อการเพิ่มประสิทธิภาพต่อไป

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

1 ความคิดเห็น

 
GN⁺ 2024-08-10
ความคิดเห็นจาก Hacker News

  • มีผู้ใช้ที่ชอบ k8s

    • ดูแลร้านอีคอมเมิร์ซแบบคัสตอมขนาดเล็กที่ซับซ้อนหลายร้าน
    • จัดการทั้งการตลาด การเงิน และบริการลูกค้า
    • ก่อนหน้านี้ใช้เซิร์ฟเวอร์เฉพาะ แต่การดีพลอยเป็นฝันร้าย
    • ใช้เวลาหนึ่งเดือนในการย้ายไป k8s
    • รันบริการที่หลากหลาย 25 ตัว
    • รวมการตั้งค่าคลัสเตอร์ไว้ในที่เดียว ทำให้รู้สถานะของบริการได้อย่างแม่นยำ
    • สามารถทำ rolling deploy ได้โดยไม่มี downtime
    • มันซับซ้อน แต่ในฐานะโปรแกรมเมอร์ก็คุ้นเคยกับความซับซ้อน
    • ถ้าเข้าใจสถาปัตยกรรม k8s ก็จะเรียนรู้อะไรได้มากขึ้น
    • high availability (HA) มีประโยชน์มาก
    • ค่าโฮสติ้งอยู่ที่ราว 400 ดอลลาร์ต่อเดือน

  • การย้ายระบบเพื่อปรับปรุงอินฟราสตรักเจอร์เป็นเรื่องที่ดี

    • น่าแปลกใจที่ไม่ได้แปลงเป็น Terraform เพื่อใช้ Helm chart
    • การใช้ Helm chart โดยไม่แก้ไขอะไรเลยดูไม่ค่อยสอดคล้องกัน
    • Helm เป็นเครื่องมือที่ดูแลรักษายาก
    • เขียนใหม่ด้วย Terraform จะดีกว่า
    • สงสัยว่าปัญหาของ Helm ได้รับการแก้ไขหรือยัง

  • รู้สึกแปลกใจที่ใน HN มีความเห็นต่อต้าน k8s เยอะมาก

    • ผู้แสดงความเห็นหลายคนน่าจะใช้บริการอย่าง Heroku, Fly.io, Render.com หรือรันแอปบน VM

  • การจัดการการดีพลอยด้วย Terraform และ ECS ซับซ้อนเกินไป

    • แค่เพิ่ม environment variable ก็ยังซับซ้อน
    • เข้าใจในส่วนของการสร้างเทมเพลต แต่โดยรวมแล้วซับซ้อน

  • ตั้งคำถามกับความเห็นที่บอกว่าการย้ายไป Kubernetes ใช้เวลาหลายปี

    • ไม่เข้าใจว่าทำไมบริษัทต่าง ๆ ถึงพยายามย้ายแบบนี้
    • สงสัยว่าลูกค้าจะได้ประโยชน์อะไร
    • สงสัยว่าการตัดสินใจที่ตั้งอยู่บนความอยากทางเทคนิคมีความหมายกับผู้ใช้หรือไม่

  • รู้สึกว่าการตัดสินใจขององค์กรขนาดใหญ่ไม่ได้ตั้งอยู่บนความต้องการของผู้ใช้หรือบริษัท

    • จากโพสต์ก่อนหน้าเกี่ยวกับฐานข้อมูลของ Figma ก็ให้ความรู้สึกคล้ายกัน
    • สงสัยว่าการตัดสินใจที่ตั้งอยู่บนความอยากทางเทคนิคมีความหมายกับผู้ใช้หรือไม่

  • สงสัยว่ามีระบบหรือบริการสมัยใหม่อะไรบ้างที่น่าภูมิใจเรื่องการย้ายระบบให้เสร็จภายใน 1 ปี

  • ชอบอ่านรายงานจากภาคสนาม

    • ได้เรียนรู้อะไรใหม่ ๆ อยู่เสมอ
    • ขอบคุณที่แชร์

  • บทความนี้อธิบายข้อดีของ Kubernetes ได้อย่างชัดเจน

    • หลายคนเปลี่ยนไปใช้ Kubernetes โดยไม่รู้ข้อดีของมัน
    • เหตุผลที่ยกมาในที่นี้ดีมาก

  • สงสัยว่าจะใช้เวลานานแค่ไหนกว่าจะเลิกใช้การย้ายระบบ