มอนิเตอร์ Apache Kafka เพื่อลดต้นทุนบนคลาวด์

Apache Kafka เป็นเสาหลักของระบบโครงสร้างพื้นฐานบนคลาวด์หลายๆ ระบบ โดยนิยมใช้ในการเคลื่อนย้ายข้อมูลขนาดใหญ่จากจุดหนึ่งไปยังอีกจุดหนึ่ง เนื่องจาก Kafka มีประสิทธิภาพสูง เชื่อถือได้ และรับประกันความทนทานการประมวลผลข้อมูลจำนวนมากบนคลาวด์ อาจกลายเป็นค่าใช้จ่ายที่แพงที่สุดในบิลค่าบริการจากผู้ให้บริการคลาวด์ของคุณ Apache Kafka มีตัวเลือกการกำหนดค่ามากมายเพื่อลดต้นทุน ทั้งระดับคลัสเตอร์และระดับไคลเอ็นต์ อย่างไรก็ตาม การค้นหาค่าและการปรับแต่งที่เหมาะสมอาจเป็นเรื่องที่ทำได้ยากNew Relic เป็นผู้ใช้งาน Apache Kafka อย่างหนัก และเคยเผยแพร่บล็อกมากมาย เช่น 20 Best Practices for Apache Kafka

at scale บทความนี้ เราจะขยายความรอบรู้เหล่านั้นโดยใช้การตรวจสอบเพื่อเน้นวิธีปรับแต่ง Apache Kafka และลดต้นทุนบนคลาวด์

ถ้าวัดไม่ได้ ก็ปรับปรุงไม่ได้

ก้าวแรกของการปรับลดต้นทุนคือ ‘การเข้าใจต้นทุน’ วิธีการแสดงข้อมูลต้นทุนของ Apache Kafka จะแตกต่างกันไป ขึ้นอยู่กับวิธีการปรับใช้และผู้ให้บริการคลาวด์ที่เลือกใช้ Confluent Cloud เป็นบริการจัดการ Kafka แบบ managed service ที่มีให้บริการในผู้ให้บริการคลาวด์หลักๆ พวกเขาเสนอ Billing API ที่ให้ข้อมูลค่าใช้จ่ายแบบรวบรวมรายวันแม้ว่าการใช้ API จะเป็นก้าวแรกที่ดีในการติดตามค่าใช้จ่าย แต่การนำข้อมูลนั้นเข้าไปใน New Relic นั้นมีประโยชน์มากกว่านั้นเยอะ

New Relic Flex เป็นเครื่องมือยอดนิยมในการส่งข้อมูลไปยัง New Relic เครื่องมือนี้ไม่จำกัดเฉพาะแอปพลิเคชัน มีคุณสมบัติครบครัน ช่วยให้คุณรวบรวมข้อมูลเมตริกจากบริการที่หลากหลาย และรวมอยู่ในตัวแทนโครงสร้างพื้นฐานของ New RelicNew Relic Flex สามารถดึงข้อมูล Billing API ของ Confluent ทุกๆ 24 ชั่วโมง และส่งข้อมูลไปยัง New Relic โดยใช้ไฟล์ YAML ที่มีการกำหนดค่าไว้ หลังจากนั้น คุณสามารถใช้ฟีเจอร์ทั้งหมดของ New Relic เพื่อสำรวจค่าใช้จ่าย Apache Kafka ของคุณในระบบคลาวด์

ภาพด้านล่างแสดงแดชบอร์ด ConfluentCloud ใน New Relic

หากคุณใช้ผู้ให้บริการรายอื่น กระบวนการจะคล้ายกันแต่ใช้ API ต่างกัน หากคุณใช้ Kafka ที่จัดการด้วยตนเองในระบบคลาวด์ อาจต้องมีการผสานรวมที่เหมาะสมและการติดแท็กทรัพยากรเพื่อแยกความแตกต่างของต้นทุน Kafka จากบริการอื่นๆ ไม่ว่าในกรณีใด มีความคล้ายคลึงกันมากมายระหว่างแนวทางต่างๆ การปรับปรุงหลายอย่างมีผลกับการปรับปรุงทั้งหมด ต้นทุน Apache Kafka

แบ่งออกเป็นประเภทต่างๆ ดังต่อไปนี้

• Networking: ปริมาณการรับส่งข้อมูลระหว่างโบรกเกอร์หรือระหว่างโบรกเกอร์กับลูกค้า
• Storage: ขนาด ปริมาณงาน I/O และจำนวนดิสก์ที่ต้องใช้ในการดำเนินการ
• Server hardware: CPU/RAM หรือการแสดงระดับสูง เช่น จำนวนและประเภทของอินสแตนซ์

การสร้างเครือข่ายในระบบคลาวด์: มีผลกระทบสูงแต่มักจะถูกลืมไป

เครือข่ายไม่ใช่สาเหตุหลักของความล่าช้าของ Kafka ในสภาพแวดล้อมคลาวด์ อย่างไรวิศวกรหลายคนไม่ค่อยปรับแต่งบริการของพวกเขาเพื่อลดการใช้เครือข่าย นี่เป็นความผิดพลาดเพราะมันส่งผลต่อค่าใช้จ่ายอย่างมาก

ก้าวแรกในการปรับแต่งเครือข่าย Kafka คือการทำความเข้าใจวิธีการเชื่อมต่อของบริการต่างๆ กับคลัสเตอร์ Kafka New Relic มีฟีเจอร์ตรวจสอบประสิทธิภาพเครือข่าย ซึ่งช่วยระบุจุดเชื่อมต่อ (hops) ทั้งหมดที่จำเป็นสำหรับการเชื่อมต่อกับ Kafkaบางส่วนประกอบของระบบอาจส่งผลต่อค่าใช้จ่ายจากผู้ให้บริการคลาวด์อย่างมาก ค่าใช้จ่ายในการเชื่อมต่อกับบริการภายในเครือข่ายเดียวกัน กับการเชื่อมต่อกับบริการในเครือข่าย (หรือภูมิภาค) อื่น แตกต่างกันมาก ด้วยความสามารถในการรับส่งข้อมูลสูงของ Apache Kafka ค่าใช้จ่ายด้านนี้จึงกลายเป็นค่าใช้จ่ายหลักในการรันบริการได้อย่างง่ายดาย

เป็นเรื่องปกติที่จะเรียกใช้ Kafka ใน Availability Zone ต่างๆ เพื่อให้มีความพร้อมใช้งานสูง หากเกิดการขัดข้องใน Availability Zone หนึ่ง บริการควรทำงานโดยไม่มีการหยุดชะงัก เนื่องจากยังมีโหนด Kafka (โบรกเกอร์) ที่มีสำเนาของข้อมูลในอีกสองรายการน่าเสียดายที่การรับส่งข้อมูลจากโซนความพร้อมใช้งานหนึ่งไปยังอีกโซนหนึ่งนั้นมีราคาแพง มีการเพิ่มประสิทธิภาพในฝั่งไคลเอ็นต์ที่ New Relic ใช้และประสบความสำเร็จอย่างมากด้วยรสชาติที่แตกต่างกันของ Kafka: ดึงข้อมูลจากแบบจำลองที่ใกล้เคียงที่สุด

แนวคิดก็คือการกำหนดค่าบริการที่อ่านข้อมูลเพื่อเชื่อมต่อกับโหมด Kafka ในโซนความพร้อมใช้งานเดียวกันหากเป็นไปได้ ซึ่งช่วยลดการรับส่งข้อมูลข้าม AZ และต้นทุนที่เกี่ยวข้องได้อย่างมาก จะเพิ่มเวลาแฝงโดยรวมในระบบท่อส่งข้อมูล จึงเป็นเรื่องสำคัญที่จะต้องวัดผลกระทบต่อความหน่วงเวลาดังกล่าว ตัวแทน Java ของ New Relic รองรับการติดตามแบบกระจายกับ Kafka รวมถึงเมตริก Kafka อื่นๆ อีกมากมายเพื่อวัดผลกระทบของการเปลี่ยนแปลงดังกล่าว

รูปภาพด้านล่างแสดงการติดตามแบบกระจายสำหรับ Kafka ด้วย Java Agent

ในการใช้งานแอปพลิเคชันที่ส่งข้อมูลไปยัง Apache Kafka ยังมีอีกวิธีหนึ่งที่สามารถเพิ่มประสิทธิภาพได้อย่างมาก นั่นคือ การบีบอัดข้อมูล โดยผู้ผลิตข้อมูล (Kafka producers) จะส่งข้อมูลไปยัง Kafka เป็นกลุ่มๆ แทนการส่งเป็นข้อความเดี่ยวๆ ซึ่งเราสามารถใช้การบีบอัดข้อมูลกับกลุ่มข้อมูลเหล่านี้ได้ก่อนทำการส่ง Apache Kafka จะเก็บข้อมูลเหล่านี้ไว้ในรูปแบบบีบอัด และแอปพลิเคชันที่ใช้งานข้อมูลจะทำการแตกไฟล์บีบอัดเพื่อประมวลผลข้อความ ทำให้ไม่เพียงแต่ลดปริมาณการรับส่งข้อมูลผ่านเครือข่าย แต่ยังช่วยลดปริมาณพื้นที่จัดเก็บข้อมูลที่จำเป็นในโหนดของ Kafka ด้วย แม้ว่าการบีบอัดข้อมูลจะช่วยลดปริมาณการรับส่งข้อมูลและพื้นที่จัดเก็บ แต่ก็ส่งผลให้ทั้งบริการผู้ผลิต (producer) และผู้บริโภค (consumer) ของ Kafka ต้องใช้ CPU มากขึ้น อย่างไรก็ตาม โดยทั่วไปแล้วถือว่าเป็นการแลกเปลี่ยนที่คุ้มค่า

ข้อสำคัญคือ การวัดผลกระทบของการบีบอัดต่อเวลาแฝง (latency) และปริมาณงาน (throughput) ของระบบท่อส่งข้อมูลของคุณ ตัวแทน Java ของ New Relic (New Relic Java agent) มีเมตริกหลายอย่างที่ช่วยทำความเข้าใจพฤติกรรมของการบีบอัดข้อมูล โดยเมตริก “outgoing-byte-rate” จะแสดงการเปลี่ยนแปลงในปริมาณงาน (throughput) ในขณะที่เมตริก “request latency avg” จะแสดงการเปลี่ยนแปลงในเวลาแฝง (latency)Apache Kafka รองรับอัลกอริทึมการบีบอัดข้อมูลหลายแบบ ซึ่งแต่ละแบบจะทำงานแตกต่างกันไปขึ้นอยู่กับประเภทของข้อมูลที่แอปพลิเคชันส่งไป แนะนำให้ทดสอบด้วยอัลกอริทึมที่แตกต่างกันเพื่อหาว่าแบบไหนเหมาะสมที่สุดสำหรับแต่ละกรณีการใช้งาน

compression rate avg ไม่เพียงพอ จำเป็นต้องวิเคราะห์ผลกระทบต่อ latency, throughput, และ CPU usage ควบคู่ไปด้วย เพื่อค้นหาจุดสมดุลที่เหมาะสมที่สุดสำหรับระบบของคุณตัวอย่าง: อาจจะคุ้มค่าที่จะยอมให้ compression rate avg ลดลงเล็กน้อย เพื่อแลกกับ latency และ throughput ที่ดีขึ้น ในขณะเดียวกันต้องติดตามการใช้ CPU ของระบบเพื่อให้แน่ใจว่าไม่เกินขีดจำกัดเครื่องมืออย่าง New Relic Java agent สามารถช่วยคุณติดตามเมตริกเหล่านี้และวิเคราะห์ผลกระทบของการบีบอัดข้อมูลได้อย่างมีประสิทธิภาพ

พื้นที่เก็บข้อมูล : วิธีง่ายๆ ในการเพิ่มปริมาณการรับส่งข้อมูลโดยมีการเปลี่ยนแปลงเพียงเล็กน้อย

การวางแผนความจุสำหรับ Apache Kafka ไม่ใช่เรื่องง่าย มีหลายปัจจัยที่เกี่ยวข้อง หนึ่งในนั้นคือปริมาณงานการจัดเก็บข้อมูล หรือที่เรียกว่าดิสก์ I/O ในไปป์ไลน์ที่มีปริมาณงานสูง ปริมาณงานการจัดเก็บข้อมูลอาจกลายเป็นปัญหาคอขวดได้อย่างง่ายดาย การเพิ่มโบรกเกอร์มากขึ้นจะช่วยบรรเทาปัญหานี้แต่ยังเพิ่มต้นทุนอีกด้วย ข่าวดีก็คือว่าโดยปกติแล้วการใช้ดิสก์ที่เร็วขึ้นในระบบคลาวด์มักจะง่ายและราคาไม่แพง

หากคุณจัดการ Kafka ด้วยตนเอง เอเจนต์โครงสร้างพื้นฐานจะจัดเตรียมตัววัดเพื่อทำความเข้าใจว่า Kafka กำลังทำงานใกล้ถึงขีดจำกัดของดิสก์เพียงใด หากคุณใช้บริการที่มีการจัดการ มักจะให้เมตริกบางอย่างแก่คุณ ตัวอย่างเช่น ลองใช้ Amazon Managed Streaming สำหรับ Apache Kafka (Amazon MSK) ซึ่งเป็นบริการ Kafka ยอดนิยมอีกบริการหนึ่ง New Relic มีการผสานรวมสำหรับ Amazon MSK ที่พร้อมใช้งานโดยใช้การผสานรวม AWS CloudWatch Metric Streams

Amazon MSK มีตัววัดเช่น VolumeQueueLength, VolumeTotalWriteTime, VolumeWriteOps, VolumeWriteBytes และค่าที่เทียบเท่าสำหรับ Read ซึ่งแสดงให้เห็นว่าดิสก์อิ่มตัวเพียงใด หากเป็นเช่นนั้น Amazon MSK จะช่วยให้คุณเพิ่มปริมาณการประมวลผลของพื้นที่จัดเก็บที่จัดเตรียมไว้ได้อย่างง่ายดาย โดยไม่ต้องสร้างคลัสเตอร์ใหม่หรือส่งผลกระทบต่อการรับส่งข้อมูลปัจจุบัน การเปลี่ยนแปลงนี้จะปรับปรุงความน่าเชื่อถือ ลดเวลาในการกู้คืน และความจำเป็นในการเพิ่มนายหน้า ซึ่งจะช่วยลดต้นทุนโดยรวมของไปป์ไลน์ของคุณ หลักการเดียวกันนี้ใช้กับคลัสเตอร์ที่จัดการด้วยตนเอง

การเพิ่มประสิทธิภาพประเภทนี้ประสบความสำเร็จอย่างมากสำหรับ New Relic ในอดีต การเพิ่ม I/O ของดิสก์ช่วยให้ประมวลผลการรับส่งข้อมูลได้มากขึ้น 20% ต่อคลัสเตอร์ ดังนั้น New Relic จึงสามารถเลิกใช้งานคลัสเตอร์ Kafka ในจำนวนที่เท่ากันได้ ต้นทุนของการเพิ่ม I/O ของดิสก์นั้นต่ำกว่าต้นทุนรวมของการรันทั้งคลัสเตอร์อย่างมาก ซึ่งส่งผลให้ประหยัดได้มาก

ประสิทธิภาพฮาร์ดแวร์เซิร์ฟเวอร์

หลังจากปรับเครือข่ายและปริมาณงานแล้ว ขั้นตอนถัดไปในการลดต้นทุน Cloud สำหรับ Kafka คือการลดจำนวนโหมด (brokers) ซึ่งมักถูกจำกัดด้วยการใช้ CPU ในเครื่องที่รัน Kafka มีหลายวิธีในการเพิ่มประสิทธิภาพการใช้งาน CPU: เลือกประเภทเครื่องที่เหมาะสมที่สุด ลดการสร้างหัวข้อที่กระชับ (ต้องทำงานเพิ่มเติมในฝั่งเซิร์ฟเวอร์) ลดปัจจัยการจำลอง (สำเนาของข้อมูลน้อยลง) ฯลฯ

สิ่งที่น่าสนใจคือหนึ่งในการกำหนดค่าที่มีผลกระทบสำคัญต่อต้นทุนคลาวด์ New Relic ไม่ใช่การกำหนดค่าคลัสเตอร์ แต่ในไคลเอนต์ Apache Kafka มักจะไม่ส่งข้อความส่วนตัวไปยังเซิร์ฟเวอร์ แต่จะจัดกลุ่มเป็นกลุ่ม สิ่งนี้ทำให้เกิดเวลาแฝง แต่จะมีประสิทธิภาพมากกว่าในระดับเครือข่าย นอกจากนี้ การบีบอัดยังทำงานได้ดีกว่าเป็นชุดมากกว่าข้อความเดี่ยวๆ

ตามค่าเริ่มต้น การกำหนดค่าไคลเอ็นต์ Apache Kafka จะไม่มีประสิทธิภาพในการแบทช์ แบทช์จำนวนมากมีจำนวนข้อความน้อยและมีขนาดเล็ก ด้วยเหตุนี้แอปพลิเคชันที่ส่งข้อมูลไปยัง Kafka จึงส่งคำขอเพิ่มเติมอีกมากมาย ยิ่งโบรกเกอร์ Kafka ได้รับคำขอมากเท่าใด CPU ที่จำเป็นในการประมวลผลก็จะยิ่งสูงขึ้นเท่านั้นหากผู้ผลิตใช้เอเจนต์ New Relic Java ตัววัดไคลเอ็นต์ Kafka ขนาดแบตช์-เฉลี่ยจะแสดงขนาดเฉลี่ยของแบตช์ และตัววัดอัตราคำขอจะแสดงจำนวนคำขอโดยเฉลี่ยต่อวินาทีคุณสามารถกำหนดค่าแอปพลิเคชันให้ส่งชุดที่ใหญ่กว่าได้ ตัวอย่างเช่น New Relic แนะนำให้ภายในใช้ linger.ms ที่มีค่า 100 ms สิ่งนี้ทำให้ผู้ผลิตรอ 100 มิลลิวินาทีเพื่อส่งแบตช์ไปยังคลัสเตอร์ ส่งผลให้แบตช์มีขนาดใหญ่ขึ้นและคำขอไปยังนายหน้าน้อยลงการเปลี่ยนแปลงในแอปพลิเคชันเดียวใน New Relic นี้ลดการใช้งาน CPU ในคลัสเตอร์ลง 15% สิ่งนี้ช่วยให้เราลดขนาดคลัสเตอร์ลงเหลือโบรกเกอร์น้อยลงโดยประหยัดต้นทุนคลาวด์ได้มาก

การแสดงของKafka

Apache Kafka เป็นซอฟต์แวร์ที่น่าทึ่งในแง่ของประสิทธิภาพ ส่วนหนึ่งของความสำเร็จคือการมอบความรับผิดชอบให้กับแอปพลิเคชันที่ใช้งานมากขึ้น วิธีนี้ใช้ได้ผลดีมาก แต่ยังทำให้การวางแผนกำลังการผลิตและการกำกับดูแลทำได้ยากขึ้นอีกด้วยกรณีก่อนหน้าที่มีขนาดของชุดงานเป็นตัวอย่างที่ดี ไม่มีวิธีง่ายๆ ที่จะบังคับให้ผู้ใช้ทำสิ่งที่ถูกต้องและปรับแต่งแอปพลิเคชันของตนเพื่อการใช้งาน CPU ที่เหมาะสมที่สุดในคลัสเตอร์

ในวงกว้าง สิ่งนี้สามารถนำไปสู่ต้นทุนระบบคลาวด์ที่หลีกเลี่ยงได้ง่าย แนวทางที่น่าสนใจในการแก้ปัญหานี้คือการใช้การปฏิเสธการชำระเงินหรือการปฏิเสธการชำระเงิน ขั้นตอนแรกคือการมีการติดตามอย่างเหมาะสมในสามระดับที่แตกต่างกัน:

• Billing/costs: เช่น การใช้ New Relic Flex
• Kafka clusters: การใช้ตัวแทนโครงสร้างพื้นฐานและการบูรณาการบนโฮสต์สำหรับ Kafka สำหรับคลัสเตอร์ Kafka ที่จัดการด้วยตนเองการบูรณาการ Relic ใหม่สำหรับบริการที่ได้รับการจัดการของ Kafka เช่น การบูรณาการ New Relic สำหรับ Amazon MSK หรือการบูรณาการ New Relic สำหรับ Confluent Cloud
• Kafka ตัวอย่างเอเจนต์ New Relic Java ตรวจสอบแนวคิดก็คือการกำหนดต้นทุนของส่วนประกอบทั้งหมด (เครือข่ายและเซิร์ฟเวอร์เซิร์ฟเวอร์) ให้กับทีมที่ใช้ Kafka และตัวอย่างการใช้งาน:
• ต้นทุนของเครือข่าย: มอบหมายให้กับทีมโดยพิจารณาจากปริมาณงานที่ใช้/การผลิตให้กับ Kafka
• ต้นทุนพื้นที่จัดเก็บ: กำหนดให้กับทีมตามการกำหนดค่าการเก็บรักษาและปริมาณงานของไคลเอ็นต์ จำเป็นต้องใช้พื้นที่เก็บข้อมูลที่ไม่ได้ใช้เพื่อจัดการกับปริมาณการรับส่งข้อมูลที่พุ่งสูงขึ้น จำนวนพื้นที่จัดเก็บข้อมูลที่ไม่ได้ใช้จะถูกกำหนดโดยทีมที่เป็นเจ้าของคลัสเตอร์ ควรมอบหมายให้กับทีมนั้นเพื่อให้แน่ใจว่ามีขนาดเพียงพอ
• ฮาร์ดแวร์เซิร์ฟเวอร์ (CPU): มอบหมายให้กับทีมตามจำนวนคำขอที่ทำกับโบรกเกอร์ Kafka ไม่ควรมอบหมาย CPU ที่ไม่ได้ใช้ให้กับทีม ดังนั้นจึงสามารถระบุปัญหาการวางแผนความจุได้

ด้วยแนวทางนี้ จึงเป็นเรื่องง่ายที่จะบังคับใช้แนวปฏิบัติที่ดีและให้แน่ใจว่าทีมต่างๆ ใช้ทรัพยากรของ Kafka อย่างมีประสิทธิภาพ ทีมสามารถตรวจสอบการแสดงของ Kafka เป็นระยะๆ เพื่อระบุความผิดปกติหรือการปรับปรุงประสิทธิภาพที่เป็นไปได้ นอกจากนี้ยังสามารถใช้การตรวจจับความผิดปกติด้วยระบบอัจฉริยะที่ประยุกต์พร้อมการแจ้งเตือนที่เหมาะสม และการติดตามการเปลี่ยนแปลงเพื่อระบุว่าการพัฒนาใหม่ส่งผลต่อต้นทุนคลาวด์อย่างไร

สรุป

Apache Kafka เป็นเทคโนโลยีที่ยอดเยี่ยมในการย้ายข้อมูลจำนวนมากด้วยวิธีที่รวดเร็วและเชื่อถือได้ ช่วยให้สามารถกำหนดค่าได้หลายอย่างเพื่อปรับปรุงประสิทธิภาพและลดต้นทุนระบบคลาวด์แม้ว่าการระบุการเพิ่มประสิทธิภาพเหล่านั้นอาจเป็นเรื่องยากและวัดผลว่าจะส่งผลต่อบริการและไปป์ไลน์ที่มีอยู่อย่างไร การเพิ่มการตรวจสอบที่เหมาะสมในเซิร์ฟเวอร์และไคลเอนต์ของ Kafka จะช่วยให้กระบวนการนั้นราบรื่นการทำให้ความสัมพันธ์ระหว่างข้อมูลการเรียกเก็บเงิน ตัวชี้วัด Kafka และผู้ใช้เป็นแบบอัตโนมัติ จะสร้างกลยุทธ์การคืนสินค้า/การปฏิเสธการชำระเงิน เพื่อให้แน่ใจถึงการเพิ่มประสิทธิภาพต้นทุนระบบคลาวด์ในระยะยาว

ข้อมูลจาก : https://newrelic.com/blog/how-to-relic/monitoring-apache-kafka-for-cloud-cost-reduction