ในโลกของแอปพลิเคชันคลาวด์เนทีฟ Kubernetes ได้กลายเป็นมาตรฐานโดยพฤตินัยสำหรับการออร์เคสเทรตคอนเทนเนอร์ อย่างไรก็ตาม ความท้าทายอย่างหนึ่งที่ยังคงมีอยู่คือความไม่สามารถของตัวจัดตารางเวลา (scheduler) ในการเข้าใจโทโพโลยีเครือข่ายนอกคลัสเตอร์ ข้อจำกัดนี้กลายเป็นปัญหาอย่างยิ่งเมื่อแอปพลิเคชันจำเป็นต้องสื่อสารกับบริการภายนอก เช่น ฐานข้อมูล ซึ่งความล่าช้าระหว่างโซนสามารถส่งผลกระทบอย่างมีนัยสำคัญต่อประสิทธิภาพและค่าใช้จ่าย โซลูชันใหม่ชื่อ Automatic Zone Placement กำลังสร้างความฮือฮาในชุมชน Kubernetes โดยการแก้ไขปัญหานี้โดยตรง
ปัญหาประสิทธิภาพข้ามโซน
เมื่อ Kubernetes จัดตารางการทำงานให้พอด (pods) โดยไม่ตระหนักถึงตำแหน่งของทรัพยากรภายนอก แอปพลิเคชันอาจลงเอยด้วยการสื่อสารข้ามโซนความพร้อมใช้งาน (availability zones) โดยไม่จำเป็น สิ่งนี้สร้างปัญหาหลักสองประการ: ความล่าช้าที่เพิ่มขึ้นและค่าใช้จ่ายในการถ่ายโอนข้อมูลที่สูงขึ้น การรับส่งข้อมูลเครือข่ายข้าม AZ ในสภาพแวดล้อมคลาวด์อย่าง AWS จะมีค่าใช้จ่าย และความล่าช้าระหว่างโซน ถึงแม้จะดูเหมือนน้อย แต่สามารถสะสมได้อย่างมีนัยสำคัญในแอปพลิเคชันที่ทำการเรียกเครือข่ายจำนวนมาก
การอภิปรายในชุมชนเปิดเผยว่านี่ไม่ใช่แค่ความกังวลทางทฤษฎี ผู้แสดงความคิดเห็นหนึ่งคนระบุว่า การรับส่งข้อมูลระหว่างโซนเป็นค่าใช้จ่ายที่ใหญ่เป็นอันดับสองในบิล AWS ของเรา มากกว่าค่าใช้จ่าย EC2/EKS ของเราเสียอีก โดยรวมแล้วเป็นตัวเลขหกหลักกลางในแต่ละปี ผู้ร่วมอภิปรายอีกคนสังเกตว่าความล่าช้าข้าม AZ โดยทั่วไปจะวัดได้ประมาณ 0.7ms แต่สามารถพุ่งสูงถึง 3-4ms ในบางกรณี ซึ่งเป็นความแตกต่างในระดับที่สำคัญเมื่อแอปพลิเคชันทำการเรียก RPCs หลายสิบครั้งเพื่อให้บริการคำขอเดียว
คนส่วนใหญ่ยอมรับความล่าช้าเพิ่มขึ้นเล็กน้อยเพื่อความพร้อมใช้งานที่สูงขึ้น แต่ผม猜想ในกรณีนี้ มันเป็นสิ่งที่ยอมรับไม่ได้
การเปรียบเทียบผลกระทบต่อประสิทธิภาพ
- เลเทนซีภายใน AZ เดียวกัน: 0.119-0.187ms
- เลเทนซีข้าม AZ: 0.548-0.658ms
- การปรับปรุงประสิทธิภาพ: TPS เพิ่มขึ้น 175-375%
- ค่าใช้จ่ายในการถ่ายโอนข้อมูล: ~$0.01/GB ระหว่าง AZ ใน AWS
วิธีการทำงานของ Automatic Zone Placement
โซลูชันนี้ใช้สถาปัตยกรรมสองส่วนที่ชาญฉลาดซึ่งทำงานภายในโครงสร้างพื้นฐาน Kubernetes ที่มีอยู่ บริการค้นหา (lookup service) ขนาดเล็กทำหน้าที่เป็นสมอง รับชื่อโดเมนและแมปพวกมันไปยังโซนความพร้อมใช้งานเฉพาะตามช่วงที่อยู่ IP บริการนี้จากนั้นจะรวมเข้ากับ Kubernetes ผ่านทางเว็บฮุกที่เปลี่ยนแปลง (mutating webhook) ซึ่งใช้พลังจาก Kyverno โดยจะสกัดคำขอการสร้างพอดและฉีดกฎความสัมพันธ์โหนด (node affinity rules) เข้าไปโดยอัตโนมัติ
สิ่งที่ทำให้แนวทางนี้สง่างามเป็นพิเศษคือความเรียบง่ายและระบบอัตโนมัติ แทนที่จะต้องการให้นักพัฒนาต้องกำหนดค่ากฎความสัมพันธ์โหนดด้วยตนเองซึ่งอาจล้าสมัยเมื่อทรัพยากรภายนอกย้าย位置ระหว่างเหตุการณ์การบำรุงรักษา ระบบจะกำหนดตำแหน่งที่เหมาะสมที่สุดแบบไดนามิกในเวลาที่สร้างพอด โซลูชันนี้ใช้กฎความสัมพันธ์แบบ preferredDuringSchedulingIgnoredDuringExecution ซึ่งหมายความว่าพอดจะพยายามจัดตารางในโซนที่เหมาะสมที่สุดแต่ยังสามารถรันที่อื่นได้หากจำเป็น
ส่วนประกอบของโซลูชัน
- Lookup Service: API ที่พัฒนาด้วย Python สำหรับแมป IP ไปยังโซน
- Mutating Webhook: เครื่องมือจัดการนโยบายที่ใช้ Kyverno
- Affinity Type: preferredDuringSchedulingIgnoredDuringExecution
- ข้อกำหนด: FQDN ที่มี A record เดียว และการแมป subnet ที่ทราบแน่ชัด
คำถามและข้อพิจารณาจากชุมชน
การอภิปรายรอบๆ เครื่องมือนี้เปิดเผยข้อพิจารณาสำคัญหลายประการสำหรับการใช้งานในสภาพแวดล้อมการผลิต คำถามสำคัญข้อหนึ่งที่ถูกหยิบยกขึ้นมาคือเกี่ยวกับการจัดการสถานการณ์ฟาลโอเวอร์: คุณจัดการกับ RDS failover อย่างไร? Mutating Webhook จะถูกเรียกก็ต่อเมื่อ Pods ถูกสร้างขึ้นเท่านั้น ดังนั้นหาก AZ zone ไม่ล้มเหลว ก็จะไม่มีพอดถูกสร้างขึ้นและไม่มีกฎความสัมพันธ์ที่จะเปลี่ยนแปลง
ผู้สร้างเครื่องมือยอมรับข้อจำกัดนี้ในการใช้งานปัจจุบัน และแนะนำว่าอาจเพิ่มนโยบายการสแกนพื้นหลัง (background scanning policies) เพื่อตรวจสอบเป็นระยะและอัปเดตการปรับใช้ (deployments) เมื่อตำแหน่งของทรัพยากรภายนอกเปลี่ยนแปลง สิ่งนี้เน้นย้ำถึงลักษณะไดนามิกของสภาพแวดล้อมคลาวด์ซึ่งตำแหน่งของทรัพยากรไม่คงที่
ผู้แสดงความคิดเห็นอีกคนตั้งคำถามถึงความจำเป็นพื้นฐานของเครื่องมือดังกล่าว โดยแนะนำว่าการปรับใช้โซนเดียว (single-zone deployments) อาจเพียงพอสำหรับหลายองค์กร อย่างไรก็ตาม ข้อมูลประสิทธิภาพที่นำเสนอเล่าเรื่องที่น่าสนใจ - เกณฑ์มาตรฐานแสดงให้เห็นการปรับปรุง 175% ถึง 375% ในจำนวนธุรกรรมต่อวินาทีเมื่อพอดถูกวางตำแหน่งร่วมกับฐานข้อมูลของพวกเขาในโซนความพร้อมใช้งานเดียวกัน
ผลกระทบในวงกว้างและทิศทางในอนาคต
แนวคิดเบื้องหลัง Automatic Zone Placement มีผลกระทบเกินกว่าแค่สถานการณ์ AWS RDS ผู้แสดงความคิดเห็นระบุว่าแนวทางที่คล้ายกันสามารถทำงานได้สำหรับการปรับใช้ในองค์กร (on-premise deployments) ซึ่งเวิร์กโหลดสามารถถูกจัดตารางตามความใกล้ชิดทางกายภาพกับทรัพยากรในแร็ก แถว หรือศูนย์ข้อมูลเฉพาะ ผู้สร้างเครื่องมือกล่าวถึงการทำงานบนส่วนขยายสำหรับบริการหลาย AZ และการเพิ่มประสิทธิภาพการกำหนดเส้นทาง traffic
สมาชิกชุมชนหนึ่งคนชี้ให้เห็นว่าโซลูชันปัจจุบันต้องการการแมปข้อมูลซับเน็ตแบบคงที่ (static mapping) และแนะนำว่าเวอร์ชันในอนาคตอาจรวบรวมข้อมูลนี้โดยอัตโนมัติผ่าน cloud provider APIs ซึ่งจะทำให้เครื่องมือปรับตัวได้ดีขึ้นกับสภาพแวดล้อมแบบไดนามิกที่การกำหนดค่าเครือข่ายเปลี่ยนแปลงบ่อย
เมตริกความหน่วงของ AWS (ภูมิภาค eu-central-1)
- AZ เดียวกัน: 0.164ms (az1), 0.119ms (az2), 0.187ms (az3)
- ข้าม AZ: 0.556ms (az1-az2), 0.548ms (az1-az3), 0.658ms (az2-az3)
สรุป
Automatic Zone Placement เป็นตัวแทนของก้าวสำคัญในการทำให้ Kubernetes ฉลาดขึ้นเกี่ยวกับการตระหนักรู้ในโครงสร้างพื้นฐาน โดยการเชื่อมช่องว่างระหว่างการจัดตารางเวลาคลัสเตอร์และตำแหน่งทรัพยากรภายนอก มันแก้ไขความกังวลเกี่ยวกับประสิทธิภาพและค่าใช้จ่ายในโลกจริงที่หลายองค์กรเผชิญในสภาพแวดล้อมการผลิต แม้ว่าโซลูชันจะมีข้อจำกัดเกี่ยวกับการจัดการฟาลโอเวอร์และต้องการการกำหนดค่าด้วยตนเองบางส่วน แต่แนวคิดนี้แสดงให้เห็นว่า Kubernetes สามารถพัฒนาอย่างไรเพื่อให้เข้าใจและเพิ่มประสิทธิภาพสำหรับระบบนิเวศโครงสร้างพื้นฐานที่กว้างขึ้นซึ่งมันทำงานอยู่ภายใน เมื่อเทคโนโลยีคลาวด์เนทีวเติบโตเต็มที่ เครื่องมือเช่นนี้เน้นย้ำถึงความต้องการอย่างต่อเนื่องสำหรับการจัดวางทรัพยากรที่ชาญฉลาดยิ่งขึ้นและการเพิ่มประสิทธิภาพเครือข่ายในระบบแบบกระจาย
อ้างอิง: Automatic zone placement service