สวัสดีทุกคน ฉันชื่ออเล็กซานเดอร์ ฉันทำงานที่ CIAN ในตำแหน่งวิศวกรและเกี่ยวข้องกับการบริหารระบบและระบบอัตโนมัติของกระบวนการโครงสร้างพื้นฐาน ในความคิดเห็นในบทความก่อนหน้านี้ เราถูกขอให้บอกว่าเราได้รับบันทึก 4 TB ต่อวันจากที่ใด และเราทำอะไรกับบันทึกเหล่านี้ ใช่ เรามีบันทึกจำนวนมาก และมีการสร้างคลัสเตอร์โครงสร้างพื้นฐานแยกต่างหากเพื่อประมวลผล ซึ่งช่วยให้เราสามารถแก้ไขปัญหาได้อย่างรวดเร็ว ในบทความนี้ ฉันจะพูดถึงวิธีที่เราปรับเปลี่ยนในช่วงเวลาหนึ่งปีเพื่อทำงานกับกระแสข้อมูลที่เพิ่มมากขึ้นเรื่อยๆ
เราเริ่มต้นที่ไหน?
ในช่วงไม่กี่ปีที่ผ่านมา ปริมาณการใช้งานบน cian.ru เพิ่มขึ้นอย่างรวดเร็ว และภายในไตรมาสที่สามของปี 2018 ปริมาณการใช้ทรัพยากรก็สูงถึง 11.2 ล้านรายต่อเดือน ในเวลานั้น ในช่วงเวลาสำคัญ เราสูญเสียบันทึกถึง 40% ซึ่งเป็นสาเหตุที่เราไม่สามารถจัดการกับเหตุการณ์ได้อย่างรวดเร็ว และใช้เวลาและความพยายามอย่างมากในการแก้ไขปัญหาเหล่านั้น เรามักจะไม่พบสาเหตุของปัญหา และมันจะเกิดขึ้นอีกในภายหลัง มันเป็นนรกและต้องทำอะไรสักอย่างกับมัน
ในเวลานั้น เราใช้คลัสเตอร์ที่มีโหนดข้อมูล 10 โหนดที่มี ElasticSearch เวอร์ชัน 5.5.2 พร้อมการตั้งค่าดัชนีมาตรฐานเพื่อจัดเก็บบันทึก มีการเปิดตัวมากกว่าหนึ่งปีที่ผ่านมาในฐานะโซลูชันที่ได้รับความนิยมและราคาไม่แพง: จากนั้นกระแสของบันทึกก็มีไม่มากนัก จึงไม่มีประโยชน์ที่จะเกิดการกำหนดค่าที่ไม่ได้มาตรฐาน
การประมวลผลบันทึกขาเข้าจัดทำโดย Logstash บนพอร์ตต่างๆ บนผู้ประสานงาน ElasticSearch ห้าราย หนึ่งดัชนีโดยไม่คำนึงถึงขนาดประกอบด้วยห้าส่วน มีการจัดการหมุนเวียนรายชั่วโมงและรายวัน เป็นผลให้มีชิ้นส่วนใหม่ประมาณ 100 ชิ้นปรากฏขึ้นในคลัสเตอร์ทุก ๆ ชั่วโมง แม้ว่าจะมีบันทึกไม่มากนัก แต่คลัสเตอร์ก็สามารถจัดการได้ดีและไม่มีใครใส่ใจกับการตั้งค่าของมัน
ความท้าทายของการเติบโตอย่างรวดเร็ว
ปริมาณบันทึกที่สร้างขึ้นเพิ่มขึ้นอย่างรวดเร็ว เนื่องจากกระบวนการทั้งสองซ้อนทับกัน ในด้านหนึ่ง จำนวนผู้ใช้บริการเพิ่มขึ้น ในทางกลับกัน เราเริ่มที่จะเปลี่ยนไปใช้สถาปัตยกรรมไมโครเซอร์วิสอย่างจริงจัง โดยมองเห็นโครงสร้างแบบเก่าของเราใน C# และ Python ไมโครเซอร์วิสใหม่หลายสิบรายการที่มาแทนที่ชิ้นส่วนของเสาหินขนาดใหญ่นี้สร้างบันทึกเพิ่มเติมสำหรับคลัสเตอร์โครงสร้างพื้นฐานอย่างมีนัยสำคัญ
การปรับขนาดทำให้เรามาถึงจุดที่คลัสเตอร์ไม่สามารถจัดการได้ในทางปฏิบัติ เมื่อบันทึกเริ่มมาถึงอัตรา 20 ข้อความต่อวินาที การหมุนเวียนที่ไม่มีประโยชน์บ่อยครั้งทำให้จำนวนชาร์ดเพิ่มขึ้นเป็น 6 และมีจำนวนชาร์ดมากกว่า 600 ชิ้นต่อโหนด
สิ่งนี้นำไปสู่ปัญหาในการจัดสรร RAM และเมื่อโหนดเกิดข้อขัดข้อง ชิ้นส่วนทั้งหมดก็เริ่มเคลื่อนที่ไปพร้อม ๆ กัน ทำให้การรับส่งข้อมูลเพิ่มขึ้นและโหลดโหนดอื่น ๆ ซึ่งทำให้แทบเป็นไปไม่ได้เลยที่จะเขียนข้อมูลไปยังคลัสเตอร์ และในช่วงเวลานี้ เราก็ถูกทิ้งไว้โดยไม่มีท่อนไม้ และหากเกิดปัญหากับเซิร์ฟเวอร์ โดยทั่วไปแล้วเราจะสูญเสียคลัสเตอร์ไป 1/10 ดัชนีขนาดเล็กจำนวนมากเพิ่มความซับซ้อน
หากไม่มีบันทึก เราก็ไม่เข้าใจสาเหตุของเหตุการณ์ดังกล่าว และไม่ช้าก็เร็วก็สามารถเหยียบคราดแบบเดิมอีกครั้งได้ และในอุดมการณ์ของทีมของเรา สิ่งนี้เป็นสิ่งที่ยอมรับไม่ได้ เนื่องจากกลไกการทำงานทั้งหมดของเราได้รับการออกแบบมาให้ทำสิ่งที่ตรงกันข้าม - อย่าทำซ้ำอีก ปัญหาเดียวกัน ในการดำเนินการนี้ เราจำเป็นต้องมีบันทึกทั้งหมดและการจัดส่งเกือบแบบเรียลไทม์ เนื่องจากทีมวิศวกรที่ปฏิบัติหน้าที่ตรวจสอบการแจ้งเตือนไม่เพียงแต่จากตัววัดเท่านั้น แต่ยังจากบันทึกด้วย เพื่อให้เข้าใจถึงระดับของปัญหา ปริมาณบันทึกทั้งหมดในขณะนั้นอยู่ที่ประมาณ 2 TB ต่อวัน
เราตั้งเป้าหมายที่จะกำจัดการสูญเสียบันทึกโดยสิ้นเชิง และลดเวลาในการจัดส่งไปยังคลัสเตอร์ ELK ให้เหลือสูงสุด 15 นาทีในระหว่างเหตุสุดวิสัย (ต่อมาเราอาศัยตัวเลขนี้เป็น KPI ภายใน)
กลไกการหมุนใหม่และโหนดร้อน-อุ่น
เราเริ่มต้นการแปลงคลัสเตอร์โดยอัปเดตเวอร์ชัน ElasticSearch จาก 5.5.2 เป็น 6.4.3 เป็นอีกครั้งที่คลัสเตอร์เวอร์ชัน 5 ของเราเสียชีวิต และเราตัดสินใจปิดและอัปเดตอย่างสมบูรณ์ - ยังไม่มีบันทึก ดังนั้นเราจึงทำการเปลี่ยนแปลงนี้ภายในเวลาเพียงไม่กี่ชั่วโมง
การเปลี่ยนแปลงครั้งใหญ่ที่สุดในขั้นตอนนี้คือการนำ Apache Kafka ไปใช้งานบนโหนดสามโหนดโดยมีผู้ประสานงานเป็นบัฟเฟอร์ระดับกลาง นายหน้าข้อความช่วยให้เราไม่สูญเสียบันทึกระหว่างเกิดปัญหากับ ElasticSearch ในเวลาเดียวกัน เราได้เพิ่ม 2 โหนดในคลัสเตอร์และเปลี่ยนไปใช้สถาปัตยกรรมแบบ hot-warm โดยมีโหนด "ร้อน" สามโหนดที่อยู่ในชั้นวางที่แตกต่างกันในศูนย์ข้อมูล เราเปลี่ยนเส้นทางบันทึกไปยังพวกเขาโดยใช้มาสก์ที่ไม่ควรสูญหายไม่ว่าในกรณีใด ๆ - nginx รวมถึงบันทึกข้อผิดพลาดของแอปพลิเคชัน บันทึกรองจะถูกส่งไปยังโหนดที่เหลือ เช่น การแก้ไขจุดบกพร่อง คำเตือน ฯลฯ และหลังจาก 24 ชั่วโมง บันทึก "สำคัญ" จากโหนด "ร้อน" จะถูกถ่ายโอน
เพื่อไม่ให้เพิ่มจำนวนดัชนีเล็กๆ เราจึงเปลี่ยนจากการหมุนเวียนเวลาเป็นกลไกแบบโรลโอเวอร์ มีข้อมูลจำนวนมากในฟอรัมว่าการหมุนเวียนตามขนาดดัชนีนั้นไม่น่าเชื่อถืออย่างยิ่ง ดังนั้นเราจึงตัดสินใจใช้การหมุนเวียนตามจำนวนเอกสารในดัชนี เราวิเคราะห์แต่ละดัชนีและบันทึกจำนวนเอกสารที่ควรหมุนเวียนหลังจากนี้ ดังนั้นเราจึงได้ขนาดชาร์ดที่เหมาะสมที่สุด - ไม่เกิน 50 GB
การเพิ่มประสิทธิภาพคลัสเตอร์
อย่างไรก็ตาม เรายังไม่สามารถกำจัดปัญหาได้ทั้งหมด น่าเสียดายที่ดัชนีเล็กๆ ยังคงปรากฏอยู่: ไม่ถึงปริมาณที่ระบุ ไม่ได้หมุน และถูกลบออกโดยการล้างดัชนีทั่วโลกที่เก่ากว่าสามวัน เนื่องจากเราลบการหมุนเวียนตามวันที่ สิ่งนี้นำไปสู่การสูญเสียข้อมูลเนื่องจากดัชนีจากคลัสเตอร์หายไปโดยสิ้นเชิง และการพยายามเขียนไปยังดัชนีที่ไม่มีอยู่จริงทำให้ตรรกะของผู้ดูแลที่เราใช้สำหรับการจัดการเสียหาย นามแฝงสำหรับการเขียนถูกแปลงเป็นดัชนีและทำลายลอจิกแบบโรลโอเวอร์ ส่งผลให้ดัชนีบางตัวมีการเติบโตที่ไม่สามารถควบคุมได้สูงถึง 600 GB
ตัวอย่างเช่น สำหรับการกำหนดค่าการหมุน:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
หากไม่มีนามแฝงแบบโรลโอเวอร์ แสดงว่าเกิดข้อผิดพลาด:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
เราทิ้งวิธีแก้ปัญหานี้ไว้สำหรับการวนซ้ำครั้งถัดไปและหยิบยกประเด็นอื่นขึ้นมา: เราเปลี่ยนไปใช้ลอจิกการดึงของ Logstash ซึ่งประมวลผลบันทึกที่เข้ามา (ลบข้อมูลที่ไม่จำเป็นออกและเพิ่มคุณค่า) เราวางมันไว้ใน docker ซึ่งเราเปิดใช้งานผ่าน docker-compose และเรายังวาง logstash-exporter ไว้ที่นั่น ซึ่งจะส่งตัววัดไปยัง Prometheus เพื่อตรวจสอบการปฏิบัติงานของสตรีมบันทึก วิธีนี้ทำให้เรามีโอกาสเปลี่ยนจำนวนอินสแตนซ์ logstash ที่รับผิดชอบในการประมวลผลบันทึกแต่ละประเภทได้อย่างราบรื่น
ในขณะที่เรากำลังปรับปรุงคลัสเตอร์ ปริมาณการใช้งานของ cian.ru เพิ่มขึ้นเป็น 12,8 ล้านรายต่อเดือน เป็นผลให้ปรากฎว่าการเปลี่ยนแปลงของเราช้ากว่าการเปลี่ยนแปลงในการผลิตเล็กน้อยและเราต้องเผชิญกับความจริงที่ว่าโหนด "อุ่น" ไม่สามารถรับมือกับโหลดได้และทำให้การส่งมอบบันทึกทั้งหมดช้าลง เราได้รับข้อมูล "ยอดนิยม" โดยไม่มีข้อผิดพลาด แต่เราต้องแทรกแซงในการส่งมอบส่วนที่เหลือและทำการโรลโอเวอร์ด้วยตนเองเพื่อกระจายดัชนีอย่างเท่าเทียมกัน
ในเวลาเดียวกัน การปรับขนาดและการเปลี่ยนแปลงการตั้งค่าของอินสแตนซ์ logstash ในคลัสเตอร์นั้นมีความซับซ้อนเนื่องจากเป็นการสร้างนักเทียบท่าในเครื่องและการดำเนินการทั้งหมดดำเนินการด้วยตนเอง (หากต้องการเพิ่มจุดสิ้นสุดใหม่ จำเป็นต้องดำเนินการทั้งหมดด้วยตนเอง เซิร์ฟเวอร์และทำ docker-compose up -d ทุกที่)
บันทึกการแจกจ่ายซ้ำ
ในเดือนกันยายนของปีนี้ เรายังคงลดขนาดเสาหินลง โหลดบนคลัสเตอร์เพิ่มขึ้น และโฟลว์ของบันทึกเข้าใกล้ 30 ข้อความต่อวินาที
เราเริ่มต้นการทำซ้ำครั้งถัดไปด้วยการอัปเดตฮาร์ดแวร์ เราเปลี่ยนจากผู้ประสานงานห้าคนเป็นสามคน แทนที่โหนดข้อมูล และชนะในแง่ของเงินและพื้นที่เก็บข้อมูล สำหรับโหนดเราใช้การกำหนดค่าสองแบบ:
- สำหรับโหนด "ร้อน": E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 สำหรับ Hot1 และ 3 สำหรับ Hot2)
- สำหรับโหนด "อุ่น": E3-1230 v6 / 4Tb SSD / 32 Gb x 4
ในการทำซ้ำนี้ เราได้ย้ายดัชนีที่มีบันทึกการเข้าถึงของไมโครเซอร์วิส ซึ่งใช้พื้นที่เดียวกันกับบันทึก nginx แนวหน้า ไปยังกลุ่มที่สองจากสามโหนด "ร้อน" ตอนนี้เราจัดเก็บข้อมูลบนโหนด "ร้อน" เป็นเวลา 20 ชั่วโมง จากนั้นจึงถ่ายโอนข้อมูลไปยังโหนด "อุ่น" ไปยังบันทึกที่เหลือ
เราแก้ไขปัญหาดัชนีขนาดเล็กที่หายไปโดยการกำหนดค่าการหมุนใหม่ ตอนนี้ดัชนีจะหมุนเวียนทุกๆ 23 ชั่วโมง แม้ว่าจะมีข้อมูลเพียงเล็กน้อยก็ตาม สิ่งนี้ทำให้จำนวนชิ้นส่วนเพิ่มขึ้นเล็กน้อย (มีประมาณ 800 ชิ้น) แต่จากมุมมองของประสิทธิภาพของคลัสเตอร์ก็ยอมรับได้
เป็นผลให้มีโหนด "ร้อน" หกโหนดและโหนด "อุ่น" เพียงสี่โหนดในคลัสเตอร์ สิ่งนี้ทำให้เกิดความล่าช้าเล็กน้อยในการร้องขอในช่วงเวลาที่ยาวนาน แต่การเพิ่มจำนวนโหนดในอนาคตจะช่วยแก้ปัญหานี้ได้
การทำซ้ำนี้ยังแก้ไขปัญหาการขาดการปรับขนาดแบบกึ่งอัตโนมัติอีกด้วย ในการดำเนินการนี้ เราได้ปรับใช้คลัสเตอร์ Nomad ที่มีโครงสร้างพื้นฐาน ซึ่งคล้ายกับที่เราได้ปรับใช้ในการใช้งานจริงแล้ว ในตอนนี้จำนวน Logstash จะไม่เปลี่ยนแปลงโดยอัตโนมัติขึ้นอยู่กับโหลด แต่เราจะมาพูดถึงเรื่องนี้
แผนสำหรับอนาคต
การกำหนดค่าที่นำไปใช้นั้นปรับขนาดได้อย่างสมบูรณ์แบบ และตอนนี้เราจัดเก็บข้อมูลได้ 13,3 TB - บันทึกทั้งหมดเป็นเวลา 4 วัน ซึ่งจำเป็นสำหรับการวิเคราะห์การแจ้งเตือนในกรณีฉุกเฉิน เราแปลงบันทึกบางส่วนเป็นหน่วยเมตริก ซึ่งเราเพิ่มลงในกราไฟท์ เพื่อให้การทำงานของวิศวกรง่ายขึ้น เรามีตัววัดสำหรับคลัสเตอร์โครงสร้างพื้นฐานและสคริปต์สำหรับการซ่อมแซมปัญหาทั่วไปแบบกึ่งอัตโนมัติ หลังจากเพิ่มจำนวนโหนดข้อมูลซึ่งวางแผนไว้สำหรับปีหน้า เราจะเปลี่ยนไปใช้การจัดเก็บข้อมูลจาก 4 เป็น 7 วัน นี่จะเพียงพอสำหรับการปฏิบัติงาน เนื่องจากเราพยายามตรวจสอบเหตุการณ์ต่างๆ โดยเร็วที่สุดเสมอ และสำหรับการตรวจสอบในระยะยาวก็มีข้อมูลการวัดทางไกล
ในเดือนตุลาคม 2019 ปริมาณการเข้าชม cian.ru ได้เพิ่มขึ้นเป็น 15,3 ล้านรายต่อเดือน นี่เป็นการทดสอบโซลูชันทางสถาปัตยกรรมในการส่งมอบบันทึกอย่างจริงจัง
ตอนนี้เรากำลังเตรียมที่จะอัปเดต ElasticSearch เป็นเวอร์ชัน 7 อย่างไรก็ตาม สำหรับสิ่งนี้ เราจะต้องอัปเดตการแมปของดัชนีจำนวนมากใน ElasticSearch เนื่องจากพวกมันย้ายจากเวอร์ชัน 5.5 และได้รับการประกาศว่าเลิกใช้แล้วในเวอร์ชัน 6 (ไม่มีอยู่ในเวอร์ชัน 7) 7). ซึ่งหมายความว่าในระหว่างกระบวนการอัปเดตจะเกิดเหตุสุดวิสัยบางประการซึ่งจะทำให้เราไม่บันทึกข้อมูลในขณะที่ปัญหาได้รับการแก้ไข จากเวอร์ชัน XNUMX เราตั้งตารอ Kibana มากที่สุดด้วยอินเทอร์เฟซที่ได้รับการปรับปรุงและตัวกรองใหม่
เราบรรลุเป้าหมายหลัก: เราหยุดการสูญเสียบันทึกและลดเวลาหยุดทำงานของคลัสเตอร์โครงสร้างพื้นฐานจากข้อขัดข้อง 2-3 ครั้งต่อสัปดาห์เป็นงานบำรุงรักษาสองสามชั่วโมงต่อเดือน งานทั้งหมดนี้ในการผลิตแทบจะมองไม่เห็น อย่างไรก็ตาม ขณะนี้เราสามารถระบุได้อย่างชัดเจนว่าเกิดอะไรขึ้นกับบริการของเรา เราสามารถทำได้อย่างรวดเร็วในโหมดเงียบ และไม่ต้องกังวลว่าบันทึกจะสูญหาย โดยทั่วไปแล้วเราพอใจ มีความสุข และเตรียมพร้อมสำหรับการหาประโยชน์ใหม่ ๆ ซึ่งเราจะพูดถึงในภายหลัง
ที่มา: will.com