การประชุมการถ่ายโอนข้อมูล | grep 'แบ็กเอนด์ | devops'

สัปดาห์ที่แล้ว ฉันไปเข้าร่วมการประชุม DUMP IT (https://dump-ekb.ru/) ในเยคาเตรินเบิร์ก และฉันต้องการบอกคุณถึงสิ่งที่พูดคุยกันในส่วน Backend และ Devops และการประชุมด้าน IT ระดับภูมิภาคคุ้มค่าแก่ความสนใจหรือไม่

Nikolay Sverchkov จาก Evil Martians เกี่ยวกับ Serverless

มีอะไรอยู่แล้ว?

โดยรวมแล้ว การประชุมมี 8 ส่วน ได้แก่ แบ็กเอนด์ ฟรอนต์เอนด์ อุปกรณ์เคลื่อนที่ การทดสอบและ QA การพัฒนา การออกแบบ วิทยาศาสตร์ และการจัดการ

ห้องโถงที่ใหญ่ที่สุดคือห้องวิทยาศาสตร์และการจัดการ)) สำหรับห้องละประมาณ 350 คน แบ็กเอนด์และฟรอนต์เอนด์ไม่ได้เล็กกว่ามากนัก ห้อง Devops มีขนาดเล็กที่สุดแต่มีความกระตือรือร้น

ฉันฟังรายงานในส่วน Devops และ Backend และพูดคุยกับวิทยากรเล็กน้อย ฉันอยากจะพูดคุยเกี่ยวกับหัวข้อที่ครอบคลุมและทบทวนหัวข้อเหล่านี้ในการประชุม

ตัวแทนของ SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) พูดในส่วน Devops และ Backend หัวข้อครอบคลุม CI/CD การทำงานกับบริการคิว การบันทึก หัวข้อแบบไร้เซิร์ฟเวอร์และการทำงานกับ PostgreSQL ใน Go ได้รับการครอบคลุมอย่างดี

นอกจากนี้ยังมีรายงานของ Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank แต่ฉันไม่มีเวลาเข้าร่วมด้วยตนเอง (ยังไม่มีการบันทึกวิดีโอและสไลด์ของรายงานพวกเขาสัญญาว่าจะโพสต์ภายใน 2 สัปดาห์ บน dump-ekb.ru)

ส่วนดีวอปส์

สิ่งที่น่าแปลกใจคือส่วนนี้จัดอยู่ในห้องโถงเล็กที่สุด ประมาณ 50 ที่นั่ง ผู้คนยังยืนอยู่ตามทางเดิน :) ฉันจะบอกคุณเกี่ยวกับรายงานที่ฉันจัดการเพื่อฟัง

ยางยืดชั่งน้ำหนักเพตะไบต์

ส่วนนี้เริ่มต้นด้วยรายงานโดย Vladimir Lil (SKB-Kontur) เกี่ยวกับ Elasticsearch ใน Kontur มี Elastic ที่ค่อนข้างใหญ่และโหลดได้ (ข้อมูลประมาณ 800 TB, ประมาณ 1.3 เพตาไบต์โดยคำนึงถึงความซ้ำซ้อน) Elasticsearch สำหรับบริการ Kontur ทั้งหมดเป็นแบบเดี่ยว ประกอบด้วย 2 คลัสเตอร์ (จากเซิร์ฟเวอร์ 7 และ 9 เครื่อง) และมีความสำคัญมากที่ Kontur จะต้องมีวิศวกร Elasticsearch พิเศษ (อันที่จริงคือ Vladimir เอง)

Vladimir ยังแบ่งปันความคิดของเขาเกี่ยวกับประโยชน์ของ Elasticsearch และปัญหาที่เกิดขึ้น

ดี:

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

ปัญหา:

• นายหน้าข้อความเป็นสิ่งที่ต้องมี (สำหรับ Kontur บทบาทของ Kafka)
• คุณสมบัติการทำงานกับ Elasticsearch Curator (สร้างภาระสูงเป็นระยะจากงานปกติใน Curator)
• ไม่มีการอนุญาตในตัว (เฉพาะสำหรับแยกต่างหาก เงินค่อนข้างมาก หรือเป็นปลั๊กอินโอเพ่นซอร์สที่มีระดับความพร้อมในการผลิตที่แตกต่างกัน)

มีเพียงบทวิจารณ์เชิงบวกเกี่ยวกับ Open Distro สำหรับ Elasticsearch :) ปัญหาการอนุญาตเดียวกันได้รับการแก้ไขที่นั่น

เพตะไบต์มาจากไหน?โหนดประกอบด้วยเซิร์ฟเวอร์ที่มี 12*8 Tb SATA + 2*2 Tb SSD การจัดเก็บความเย็นบน SATA, SSD สำหรับแคชร้อนเท่านั้น (ที่เก็บข้อมูลร้อน)
เซิร์ฟเวอร์ 7+9 (7 + 9) * 12 * 8 = 1536 Tb
ส่วนหนึ่งของพื้นที่ถูกสงวนไว้ จัดสรรไว้เพื่อความซ้ำซ้อน ฯลฯ
บันทึกจากแอปพลิเคชันประมาณ 90 รายการจะถูกส่งไปยัง Elasticsearch รวมถึงบริการรายงานทั้งหมดของ Kontur, Elba ฯลฯ

คุณสมบัติของการพัฒนาบน Serverless

ถัดไปคือรายงานโดย Ruslan Serkin จาก DataArt เกี่ยวกับ Serverless

Ruslan พูดคุยเกี่ยวกับการพัฒนาแนวทาง Serverless โดยทั่วไป และคุณสมบัติของมันคืออะไร

Serverless เป็นแนวทางในการพัฒนาที่นักพัฒนาไม่ได้แตะต้องโครงสร้างพื้นฐานแต่อย่างใด ตัวอย่าง - AWS Lambda Serverless, Kubeless.io (ไร้เซิร์ฟเวอร์ภายใน Kubernetes), ฟังก์ชัน Google Cloud

แอปพลิเคชันแบบไร้เซิร์ฟเวอร์ในอุดมคติเป็นเพียงฟังก์ชันที่ส่งคำขอไปยังผู้ให้บริการแบบไร้เซิร์ฟเวอร์ผ่านเกตเวย์ API พิเศษ ไมโครเซอร์วิสในอุดมคติ ในขณะที่ AWS Lambda ยังรองรับภาษาการเขียนโปรแกรมสมัยใหม่จำนวนมากอีกด้วย ค่าใช้จ่ายในการบำรุงรักษาและปรับใช้โครงสร้างพื้นฐานจะกลายเป็นศูนย์ในกรณีของผู้ให้บริการคลาวด์ การรองรับแอปพลิเคชันขนาดเล็กก็มีราคาถูกมากเช่นกัน (AWS Lambda - 0.2 USD / 1 ล้านคำขอธรรมดา)

ความสามารถในการปรับขนาดของระบบดังกล่าวเกือบจะสมบูรณ์แบบ - ผู้ให้บริการคลาวด์จะดูแลเรื่องนี้เอง ส่วน Kubeless จะปรับขนาดภายในคลัสเตอร์ Kubernetes โดยอัตโนมัติ

มีข้อเสีย:

• การพัฒนาแอพพลิเคชั่นขนาดใหญ่กลายเป็นเรื่องยากมากขึ้น
• มีปัญหากับแอปพลิเคชันการทำโปรไฟล์ (คุณสามารถเข้าถึงบันทึกเท่านั้น แต่ไม่สามารถทำโปรไฟล์ได้ตามปกติ)
• ไม่มีเวอร์ชัน

พูดตามตรง ฉันได้ยินเกี่ยวกับ Serverless เมื่อไม่กี่ปีก่อน แต่ตลอดหลายปีที่ผ่านมา ฉันไม่ชัดเจนว่าจะใช้มันอย่างถูกต้องได้อย่างไร หลังจากรายงานของ Ruslan ความเข้าใจก็ปรากฏขึ้น และหลังจากรายงานของ Nikolai Sverchkov (Evil Martians) จากส่วน Backend ก็ถูกรวมเข้าด้วยกัน มันไม่ไร้ประโยชน์ที่ฉันไปประชุม :)

CI มีไว้สำหรับคนยากจน หรือคุ้มค่าที่จะเขียน CI ของคุณเองสำหรับเว็บสตูดิโอ?

Mikhail Radionov หัวหน้าสตูดิโอเว็บ Flag จาก Yekaterinburg พูดถึง CI/CD ที่เขียนขึ้นเอง

สตูดิโอของเขาเปลี่ยนจาก “manual CI/CD” (เข้าสู่ระบบเซิร์ฟเวอร์ผ่าน SSH, ทำการ git pull, ทำซ้ำ 100 ครั้งต่อวัน) มาเป็น Jenkins และเป็นเครื่องมือที่เขียนขึ้นเองที่ช่วยให้คุณสามารถตรวจสอบโค้ดและดำเนินการเผยแพร่ที่เรียกว่า Pullkins .

ทำไมเจนกินส์ไม่ทำงาน? โดยค่าเริ่มต้นไม่ได้ให้ความยืดหยุ่นเพียงพอและปรับแต่งได้ยากเกินไป

“Flag” พัฒนาใน Laravel (เฟรมเวิร์ก PHP) เมื่อพัฒนาเซิร์ฟเวอร์ CI/CD มิคาอิลและเพื่อนร่วมงานของเขาใช้กลไกในตัวของ Laravel ที่เรียกว่า Telescope และ Envoy ผลลัพธ์คือเซิร์ฟเวอร์ใน PHP (โปรดทราบ) ที่ประมวลผลคำขอเว็บฮุคที่เข้ามา สามารถสร้างส่วนหน้าและส่วนหลัง ปรับใช้กับเซิร์ฟเวอร์อื่น และรายงานไปยัง Slack

จากนั้น เพื่อให้สามารถปรับใช้สีน้ำเงิน/เขียวได้และมีการตั้งค่าที่เหมือนกันในสภาพแวดล้อม dev-stage-prod พวกเขาจึงเปลี่ยนมาใช้ Docker ข้อดียังคงเหมือนเดิม มีการเพิ่มความเป็นไปได้ของการทำให้สภาพแวดล้อมเป็นเนื้อเดียวกันและการปรับใช้ที่ราบรื่น และเพิ่มความจำเป็นในการเรียนรู้ Docker เพื่อทำงานอย่างถูกต้อง

โครงการอยู่บน Github

วิธีที่เราลดจำนวนการย้อนกลับการเปิดตัวเซิร์ฟเวอร์ลง 99%

รายงานล่าสุดในส่วน Devops มาจาก Viktor Eremchenko หัวหน้าวิศวกร Devops ที่ Miro.com (เดิมชื่อ RealTimeBoard)

RealTimeBoard ซึ่งเป็นผลิตภัณฑ์หลักของทีม Miro มีพื้นฐานมาจากแอปพลิเคชัน Java ขนาดใหญ่ การรวบรวม การทดสอบ และการใช้งานโดยไม่ต้องหยุดทำงานถือเป็นงานที่ยาก ในกรณีนี้ สิ่งสำคัญคือต้องปรับใช้เวอร์ชันของโค้ดดังกล่าว เพื่อจะได้ไม่ต้องย้อนกลับ (เป็นเวอร์ชันที่ใหญ่โตมาก)

ระหว่างทางสร้างระบบที่ช่วยให้คุณทำสิ่งนี้ได้ Miro ได้ผ่านเส้นทางที่รวมถึงการทำงานด้านสถาปัตยกรรม เครื่องมือที่ใช้ (Atlassian Bamboo, Ansible ฯลฯ) และการทำงานเกี่ยวกับโครงสร้างของทีม (ตอนนี้พวกเขามี ทีม Devops เฉพาะ + ทีม Scrum แยกจากนักพัฒนาโปรไฟล์ที่แตกต่างกัน)

เส้นทางกลายเป็นเส้นทางที่ยากลำบากและยุ่งยาก และวิกเตอร์ก็ร่วมแบ่งปันความเจ็บปวดและการมองโลกในแง่ดีที่สะสมมาซึ่งไม่ได้จบเพียงแค่นั้น

ได้รับรางวัลหนังสือถามคำถาม

ส่วนแบ็กเอนด์

ฉันจัดการเพื่อเข้าร่วมรายงาน 2 ฉบับ - จาก Nikolay Sverchkov (Evil Martians) เกี่ยวกับ Serverless และจาก Grigory Koshelev (บริษัท Kontur) เกี่ยวกับ telemetry

ไร้เซิร์ฟเวอร์สำหรับมนุษย์ธรรมดา

หาก Ruslan Sirkin พูดถึงว่า Serverless คืออะไร Nikolay ก็แสดงแอปพลิเคชันง่ายๆ ที่ใช้ Serverless และพูดคุยเกี่ยวกับรายละเอียดที่ส่งผลต่อต้นทุนและความเร็วของแอปพลิเคชันใน AWS Lambda

รายละเอียดที่น่าสนใจ: องค์ประกอบที่ต้องชำระขั้นต่ำคือหน่วยความจำ 128 Mb และ CPU 100 ms ราคา 0,000000208 ดอลลาร์ ยิ่งไปกว่านั้น 1 ล้านคำขอดังกล่าวต่อเดือนนั้นฟรี

ฟังก์ชันบางอย่างของ Nikolai มักจะเกินขีดจำกัด 100 มิลลิวินาที (แอปพลิเคชันหลักเขียนด้วยภาษา Ruby) ดังนั้นการเขียนใหม่ใน Go จึงช่วยประหยัดได้ดีเยี่ยม

Vostok Hercules — ทำให้การวัดและส่งข้อมูลทางไกลกลับมายอดเยี่ยมอีกครั้ง!

รายงานล่าสุดของส่วนแบ็กเอนด์จาก Grigory Koshelev (บริษัท Kontur) เกี่ยวกับการวัดและส่งข้อมูลทางไกล การวัดและส่งข้อมูลทางไกลหมายถึงบันทึก ตัวชี้วัด การติดตามแอปพลิเคชัน

เพื่อจุดประสงค์นี้ Contour ใช้เครื่องมือที่เขียนขึ้นเองซึ่งโพสต์บน Github เครื่องมือจากรายงาน - Hercules github.com/vostok/herculesใช้เพื่อส่งข้อมูลการวัดและส่งข้อมูลทางไกล

รายงานของ Vladimir Lila ในส่วน Devops กล่าวถึงการจัดเก็บและการประมวลผลบันทึกใน Elasticsearch แต่ยังคงมีงานในการส่งบันทึกจากอุปกรณ์และแอปพลิเคชันหลายพันรายการ และเครื่องมืออย่าง Vostok Hercules ก็ช่วยแก้ไขได้

วงจรนี้เดินตามเส้นทางที่หลายๆ คนรู้จัก ตั้งแต่ RabbitMQ ไปจนถึง Apache Kafka แต่ไม่ใช่ทุกอย่างจะง่ายนัก)) พวกเขาต้องเพิ่ม Zookeeper, Cassandra และ Graphite เข้าไปในวงจร ฉันจะไม่เปิดเผยข้อมูลในรายงานนี้โดยครบถ้วน (ไม่ใช่โปรไฟล์ของฉัน) หากคุณสนใจสามารถรอชมสไลด์และวิดีโอบนเว็บไซต์การประชุมได้

เปรียบเทียบกับการประชุมอื่น ๆ เป็นอย่างไร?

ฉันไม่สามารถเปรียบเทียบกับการประชุมในมอสโกวและเซนต์ปีเตอร์สเบิร์กได้ ฉันสามารถเปรียบเทียบกับงานอื่น ๆ ใน Urals และกับ 404fest ใน Samara ได้

DAMP จัดขึ้นใน 8 ส่วนซึ่งเป็นบันทึกสำหรับการประชุมอูราล ส่วนวิทยาศาสตร์และการจัดการที่ใหญ่มากนี่ก็ผิดปกติเช่นกัน ผู้ชมในเยคาเตรินเบิร์กมีโครงสร้างค่อนข้างดี - เมืองนี้มีแผนกพัฒนาขนาดใหญ่สำหรับ Yandex, Kontur, Tinkoff และสิ่งนี้ทิ้งร่องรอยไว้ในรายงาน

จุดที่น่าสนใจอีกจุดหนึ่งคือ หลายบริษัทมีวิทยากร 3-4 คนในการประชุมพร้อมกัน (ซึ่งเป็นกรณีของ Kontur, Evil Martians, Tinkoff) หลายคนเป็นผู้สนับสนุน แต่รายงานค่อนข้างเทียบเท่ากับรายงานอื่นๆ ซึ่งไม่ใช่รายงานการโฆษณา

จะไปหรือไม่ไป? หากคุณอาศัยอยู่ในเทือกเขาอูราลหรือใกล้เคียง แสดงว่าคุณมีโอกาสและสนใจหัวข้อนี้ - ใช่แน่นอน หากคุณกำลังคิดจะเดินทางไกลฉันจะดูหัวข้อรายงานและวิดีโอรายงานจากปีก่อน ๆ www.youtube.com/user/videoitpeople/videos และได้ตัดสินใจ
ข้อดีอีกประการของการประชุมในภูมิภาคตามกฎก็คือสามารถสื่อสารกับวิทยากรได้ง่ายหลังจากรายงาน มีผู้สมัครสำหรับการสื่อสารดังกล่าวน้อยลง

ขอบคุณ Dump และ Ekaterinburg! )

ที่มา: will.com