บริษัท URUS ลองใช้ Kubernetes ในรูปแบบต่างๆ: การใช้งานอิสระบน Bare Metal ใน Google Cloud จากนั้นจึงโอนแพลตฟอร์มไปยังระบบคลาวด์ Mail.ru Cloud Solutions (MCS) Igor Shishkin เล่าถึงวิธีที่พวกเขาเลือกผู้ให้บริการระบบคลาวด์รายใหม่ และวิธีที่พวกเขาจัดการโยกย้ายไปยังผู้ให้บริการนั้นภายในระยะเวลาสองชั่วโมงเป็นประวัติการณ์ () ผู้ดูแลระบบอาวุโสของ URUS
ยูรัสทำอะไร?
มีหลายวิธีในการปรับปรุงคุณภาพของสภาพแวดล้อมในเมือง และหนึ่งในนั้นคือการทำให้เป็นมิตรกับสิ่งแวดล้อม นี่คือสิ่งที่บริษัท URUS - Smart Digital Services กำลังดำเนินการอยู่ ที่นี่พวกเขาใช้โซลูชันที่ช่วยให้องค์กรต่างๆ ติดตามตัวชี้วัดด้านสิ่งแวดล้อมที่สำคัญ และลดผลกระทบด้านลบต่อสิ่งแวดล้อม เซ็นเซอร์รวบรวมข้อมูลเกี่ยวกับองค์ประกอบของอากาศ ระดับเสียง และพารามิเตอร์อื่นๆ จากนั้นส่งไปยังแพลตฟอร์ม URUS-Ekomon แบบรวมศูนย์เพื่อทำการวิเคราะห์และให้คำแนะนำ
URUS ทำงานจากภายในอย่างไร
ลูกค้าทั่วไปของ URUS คือบริษัทที่ตั้งอยู่ในหรือใกล้กับย่านที่อยู่อาศัย นี่อาจเป็นโรงงาน ท่าเรือ สถานีรถไฟ หรือสิ่งอำนวยความสะดวกอื่นๆ หากลูกค้าของเราได้รับคำเตือน ถูกปรับเนื่องจากมลภาวะต่อสิ่งแวดล้อม หรือต้องการส่งเสียงดังน้อยลง ลดปริมาณการปล่อยก๊าซที่เป็นอันตราย เขามาหาเรา และเราได้เสนอโซลูชันสำเร็จรูปสำหรับการตรวจสอบด้านสิ่งแวดล้อมให้เขาแล้ว
กราฟการตรวจสอบความเข้มข้นของ H2S แสดงการปล่อยก๊าซเรือนกระจกในเวลากลางคืนเป็นประจำจากโรงงานใกล้เคียง
อุปกรณ์ที่เราใช้ที่ URUS มีเซ็นเซอร์หลายตัวที่รวบรวมข้อมูลเกี่ยวกับเนื้อหาของก๊าซ ระดับเสียง และข้อมูลอื่น ๆ เพื่อประเมินสถานการณ์ด้านสิ่งแวดล้อม จำนวนเซ็นเซอร์ที่แน่นอนจะถูกกำหนดโดยงานเฉพาะเสมอ
อุปกรณ์ที่มีเซ็นเซอร์สามารถวางบนผนังอาคารเสาและสถานที่อื่น ๆ ได้ตามต้องการทั้งนี้ขึ้นอยู่กับลักษณะเฉพาะของการวัด อุปกรณ์ดังกล่าวแต่ละเครื่องจะรวบรวมข้อมูล รวบรวม และส่งไปยังเกตเวย์การรับข้อมูล ที่นั่นเราจะบันทึกข้อมูลเพื่อจัดเก็บข้อมูลระยะยาวและประมวลผลล่วงหน้าเพื่อการวิเคราะห์ในภายหลัง ตัวอย่างที่ง่ายที่สุดของสิ่งที่เราได้รับจากการวิเคราะห์คือดัชนีคุณภาพอากาศหรือที่เรียกว่า AQI
ในขณะเดียวกัน บริการอื่นๆ มากมายดำเนินการบนแพลตฟอร์มของเรา แต่บริการเหล่านี้ส่วนใหญ่เป็นลักษณะของบริการ ตัวอย่างเช่น บริการแจ้งเตือนจะส่งการแจ้งเตือนไปยังไคลเอนต์หากพารามิเตอร์ที่ได้รับการตรวจสอบ (เช่น เนื้อหา CO2) เกินค่าที่อนุญาต
เราจัดเก็บข้อมูลอย่างไร เรื่องราวของ Kubernetes บน Bare Metal
โครงการติดตามตรวจสอบด้านสิ่งแวดล้อมของ URUS มีคลังข้อมูลหลายแห่ง ในที่เดียวเราเก็บข้อมูล "ดิบ" ซึ่งเป็นสิ่งที่เราได้รับโดยตรงจากอุปกรณ์โดยตรง ที่เก็บข้อมูลนี้เป็นเทป "แม่เหล็ก" เช่นเดียวกับเทปคาสเซ็ตเก่าที่มีประวัติตัวบ่งชี้ทั้งหมด พื้นที่เก็บข้อมูลประเภทที่สองใช้สำหรับข้อมูลที่ประมวลผลล่วงหน้า - ข้อมูลจากอุปกรณ์ที่เสริมด้วยเมทาดาทาเกี่ยวกับการเชื่อมต่อระหว่างเซ็นเซอร์และการอ่านของอุปกรณ์ ความเกี่ยวข้องกับองค์กร สถานที่ ฯลฯ ข้อมูลนี้ช่วยให้คุณประเมินแบบไดนามิกว่าตัวบ่งชี้เฉพาะมีได้อย่างไร เปลี่ยนแปลงไปในช่วงระยะเวลาหนึ่ง เราใช้ที่จัดเก็บข้อมูล "ดิบ" เหนือสิ่งอื่นใดในการสำรองข้อมูลและกู้คืนข้อมูลที่ประมวลผลล่วงหน้า หากมีความจำเป็นเกิดขึ้น
เมื่อเราต้องการแก้ไขปัญหาพื้นที่จัดเก็บข้อมูลเมื่อหลายปีก่อน เรามีแพลตฟอร์มให้เลือก XNUMX แบบ ได้แก่ Kubernetes และ OpenStack แต่เนื่องจากอย่างหลังดูค่อนข้างน่ากลัว (เพียงแค่ดูสถาปัตยกรรมของมันเพื่อที่จะมั่นใจในสิ่งนี้) เราจึงตัดสินใจเลือก Kubernetes ข้อโต้แย้งอีกประการหนึ่งที่สนับสนุนคือการควบคุมซอฟต์แวร์ที่ค่อนข้างง่าย ความสามารถในการตัดแม้แต่โหนดฮาร์ดแวร์ตามทรัพยากรได้อย่างยืดหยุ่นมากขึ้น
ควบคู่ไปกับการเรียนรู้ Kubernetes อย่างเชี่ยวชาญ เรายังศึกษาวิธีการจัดเก็บข้อมูล ในขณะที่เราเก็บข้อมูลทั้งหมดไว้ใน Kubernetes บนฮาร์ดแวร์ของเราเอง เราก็ได้รับความเชี่ยวชาญที่ยอดเยี่ยม ทุกสิ่งที่เราเคยมีบน Kubernetes: พื้นที่จัดเก็บแบบมีสถานะ ระบบตรวจสอบ CI/CD Kubernetes กลายเป็นแพลตฟอร์มครบวงจรสำหรับเรา
แต่เราต้องการทำงานร่วมกับ Kubernetes ในรูปแบบบริการ และไม่มีส่วนร่วมในการสนับสนุนและการพัฒนา นอกจากนี้เรายังไม่ชอบค่าใช้จ่ายเท่าไรในการดูแลรักษา Bare Metal และเราต้องการการพัฒนาอย่างต่อเนื่อง! ตัวอย่างเช่น งานแรกๆ อย่างหนึ่งคือการรวมตัวควบคุม Kubernetes Ingress เข้ากับโครงสร้างพื้นฐานเครือข่ายขององค์กรของเรา นี่เป็นงานที่ยุ่งยาก โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าในขณะนั้นยังไม่มีสิ่งใดที่พร้อมสำหรับการจัดการทรัพยากรเชิงโปรแกรม เช่น บันทึก DNS หรือการจัดสรรที่อยู่ IP ต่อมาเราเริ่มทดลองกับการจัดเก็บข้อมูลภายนอก เราไม่เคยลองใช้ตัวควบคุม PVC เลย แต่ถึงอย่างนั้นก็ชัดเจนว่านี่เป็นงานขนาดใหญ่ที่ต้องใช้ผู้เชี่ยวชาญเฉพาะทาง
การเปลี่ยนมาใช้ Google Cloud Platform เป็นวิธีแก้ปัญหาชั่วคราว
เราตระหนักว่าสิ่งนี้ไม่สามารถดำเนินต่อไปได้ และย้ายข้อมูลจาก Bare Metal ไปยัง Google Cloud Platform ในความเป็นจริง ในเวลานั้นบริษัทรัสเซียมีตัวเลือกที่น่าสนใจไม่มากนัก นอกจากแพลตฟอร์ม Google Cloud แล้ว มีเพียง Amazon เท่านั้นที่เสนอบริการที่คล้ายกัน แต่เรายังคงตัดสินใจเลือกโซลูชันจาก Google ดูเหมือนว่าเราจะทำกำไรได้ในเชิงเศรษฐกิจมากกว่า ใกล้กับ Upstream ไม่ต้องพูดถึงความจริงที่ว่า Google เองก็เป็น PoC Kubernetes ชนิดหนึ่งในการผลิต
ปัญหาสำคัญประการแรกปรากฏบนขอบฟ้าเมื่อฐานลูกค้าของเราเติบโตขึ้น เมื่อเราต้องการจัดเก็บข้อมูลส่วนบุคคล เราต้องเผชิญกับทางเลือก: เราจะทำงานร่วมกับ Google และละเมิดกฎหมายรัสเซีย หรือกำลังมองหาทางเลือกอื่นในสหพันธรัฐรัสเซีย ทางเลือกโดยรวมสามารถคาดเดาได้ 🙂
เราเห็นบริการคลาวด์ในอุดมคติได้อย่างไร
เมื่อเริ่มต้นการค้นหา เรารู้อยู่แล้วว่าเราต้องการได้อะไรจากผู้ให้บริการคลาวด์ในอนาคต เรากำลังมองหาบริการอะไร:
- รวดเร็วและยืดหยุ่น. เพื่อให้เราสามารถเพิ่มโหนดใหม่หรือปรับใช้บางอย่างได้อย่างรวดเร็วตลอดเวลา
- ราคาไม่แพง. เรามีความกังวลอย่างมากเกี่ยวกับปัญหาทางการเงิน เนื่องจากเรามีทรัพยากรที่จำกัด เรารู้อยู่แล้วว่าเราต้องการทำงานร่วมกับ Kubernetes และตอนนี้งานคือการลดต้นทุนให้เหลือน้อยที่สุดเพื่อเพิ่มหรืออย่างน้อยก็รักษาประสิทธิภาพของการใช้โซลูชันนี้
- อัตโนมัติ. เราวางแผนที่จะทำงานกับบริการผ่าน API โดยไม่มีผู้จัดการและการโทรศัพท์หรือสถานการณ์ที่เราต้องยกโหนดหลายสิบโหนดในโหมดฉุกเฉินด้วยตนเอง เนื่องจากกระบวนการส่วนใหญ่ของเราเป็นแบบอัตโนมัติ เราจึงคาดหวังสิ่งเดียวกันนี้จากบริการคลาวด์
- ด้วยเซิร์ฟเวอร์ในสหพันธรัฐรัสเซีย. แน่นอนว่าเราวางแผนที่จะปฏิบัติตามกฎหมายของรัสเซียและ 152-FZ เดียวกันนั้น
ในเวลานั้น มีผู้ให้บริการ Kubernetes aaS เพียงไม่กี่รายในรัสเซีย และเมื่อเลือกผู้ให้บริการ เป็นสิ่งสำคัญสำหรับเราที่จะไม่ประนีประนอมกับลำดับความสำคัญของเรา ทีมงาน Mail.ru Cloud Solutions ซึ่งเราเริ่มทำงานด้วยและยังคงทำงานร่วมกันอยู่ได้ให้บริการอัตโนมัติเต็มรูปแบบแก่เรา พร้อมการรองรับ API และแผงควบคุมที่สะดวกสบายซึ่งรวมถึง Horizon - ด้วยสิ่งนี้ เราจึงสามารถเพิ่มจำนวนโหนดตามอำเภอใจได้อย่างรวดเร็ว
เราจัดการโยกย้ายไปยัง MCS ได้อย่างไรภายในสองชั่วโมง
ในการเคลื่อนไหวดังกล่าว บริษัทหลายแห่งเผชิญกับความยากลำบากและความพ่ายแพ้ แต่ในกรณีของเราไม่พบเลย เราโชคดี เนื่องจากเราได้ทำงานกับ Kubernetes ก่อนการโยกย้ายจะเริ่มขึ้น เราเพียงแค่แก้ไขไฟล์สามไฟล์และเปิดตัวบริการของเราบนแพลตฟอร์มระบบคลาวด์ใหม่ MCS ฉันขอเตือนคุณว่าเมื่อถึงเวลานั้น ในที่สุดเราก็ออกจาก Bare Metal และอาศัยอยู่บนแพลตฟอร์ม Google Cloud ดังนั้นการย้ายจึงใช้เวลาไม่เกินสองชั่วโมง บวกกับเวลาอีกเล็กน้อย (ประมาณหนึ่งชั่วโมง) ในการคัดลอกข้อมูลจากอุปกรณ์ของเรา ย้อนกลับไปตอนนั้นเราใช้ Spinnaker อยู่แล้ว (บริการซีดีหลายคลาวด์สำหรับการจัดส่งแบบต่อเนื่อง) นอกจากนี้เรายังเพิ่มมันลงในคลัสเตอร์ใหม่อย่างรวดเร็วและทำงานต่อไปตามปกติ
ด้วยระบบอัตโนมัติของกระบวนการพัฒนาและ CI/CD ทำให้ Kubernetes ที่ URUS ได้รับการจัดการโดยผู้เชี่ยวชาญหนึ่งคน (และนั่นคือฉันเอง) ในบางขั้นตอน ผู้ดูแลระบบอีกคนทำงานร่วมกับฉัน แต่ปรากฏว่าเราได้ทำรูทีนหลักทั้งหมดโดยอัตโนมัติแล้ว และมีงานในส่วนของผลิตภัณฑ์หลักของเรามากขึ้นเรื่อยๆ และเป็นเรื่องสมเหตุสมผลที่จะกำหนดทิศทางทรัพยากรให้กับสิ่งนี้
เราได้รับสิ่งที่เราคาดหวังจากผู้ให้บริการคลาวด์ เนื่องจากเราเริ่มต้นความร่วมมือโดยไม่มีภาพลวงตา หากมีเหตุการณ์ใดๆ เกิดขึ้น ส่วนใหญ่เป็นเหตุการณ์ทางเทคนิคและสามารถอธิบายได้ง่ายด้วยความสดใหม่ของบริการ สิ่งสำคัญคือทีม MCS กำจัดข้อบกพร่องอย่างรวดเร็วและตอบคำถามในผู้ส่งสารอย่างรวดเร็ว
ถ้าฉันเปรียบเทียบประสบการณ์ของฉันกับ Google Cloud Platform ในกรณีของพวกเขา ฉันไม่รู้ด้วยซ้ำว่าปุ่มคำติชมอยู่ที่ไหน เนื่องจากไม่จำเป็นต้องใช้เลย และหากเกิดปัญหา Google เองก็ส่งการแจ้งเตือนเพียงฝ่ายเดียว แต่ในกรณีของ MCS ฉันคิดว่าข้อได้เปรียบที่สำคัญคือพวกเขาใกล้ชิดกับลูกค้าชาวรัสเซียมากที่สุด - ทั้งในด้านภูมิศาสตร์และจิตใจ
เราเห็นการทำงานกับคลาวด์อย่างไรในอนาคต
ตอนนี้งานของเราเชื่อมโยงอย่างใกล้ชิดกับ Kubernetes และเหมาะกับเราอย่างยิ่งในแง่ของงานด้านโครงสร้างพื้นฐาน ดังนั้นเราจึงไม่ได้วางแผนที่จะย้ายจากที่ใด แม้ว่าเราจะแนะนำแนวทางปฏิบัติและบริการใหม่ ๆ อย่างต่อเนื่องเพื่อลดความซับซ้อนของงานประจำและทำให้งานใหม่เป็นอัตโนมัติ เพิ่มความเสถียรและความน่าเชื่อถือของบริการ... ขณะนี้เรากำลังเปิดตัวบริการ Chaos Monkey (โดยเฉพาะ เราใช้ chaoskube แต่สิ่งนี้ไม่ได้เปลี่ยนแนวคิด: ) ซึ่งสร้างสรรค์โดย Netflix ในตอนแรก Chaos Monkey ทำสิ่งง่ายๆ อย่างหนึ่ง: มันจะลบพ็อด Kubernetes แบบสุ่มในเวลาสุ่ม นี่เป็นสิ่งจำเป็นสำหรับบริการของเราให้ใช้งานได้ตามปกติโดยมีจำนวนอินสแตนซ์ n–1 ดังนั้นเราจึงฝึกฝนตนเองให้เตรียมพร้อมสำหรับปัญหาใดๆ
ตอนนี้ฉันเห็นการใช้โซลูชันของบริษัทอื่น ซึ่งเป็นแพลตฟอร์มคลาวด์เดียวกัน เป็นสิ่งเดียวที่เหมาะสมสำหรับบริษัทเล็กๆ โดยปกติแล้ว ในช่วงเริ่มต้นของการเดินทาง พวกเขาจะถูกจำกัดในด้านทรัพยากร ทั้งด้านมนุษย์และการเงิน และการสร้างและบำรุงรักษาระบบคลาวด์หรือศูนย์ข้อมูลของตนเองนั้นมีราคาแพงเกินไปและใช้แรงงานมาก ผู้ให้บริการคลาวด์ช่วยให้คุณลดต้นทุนเหล่านี้ได้ คุณสามารถรับทรัพยากรที่จำเป็นสำหรับการดำเนินงานบริการได้อย่างรวดเร็วจากพวกเขาที่นี่และเดี๋ยวนี้ และชำระค่าทรัพยากรเหล่านี้หลังจากนั้น ในส่วนของบริษัท URUS เราจะยังคงซื่อสัตย์ต่อ Kubernetes ในระบบคลาวด์ในตอนนี้ แต่ใครจะรู้ เราอาจต้องขยายพื้นที่ทางภูมิศาสตร์ หรือใช้โซลูชันโดยอิงจากอุปกรณ์เฉพาะบางอย่าง หรือบางทีปริมาณทรัพยากรที่ใช้ไปอาจพิสูจน์ได้ว่า Kubernetes ของตัวเองบน Bare-Metal เหมือนกับในสมัยก่อน 🙂
สิ่งที่เราเรียนรู้จากการทำงานกับบริการคลาวด์
เราเริ่มใช้ Kubernetes บน Bare Metal และถึงแม้จะมีข้อดีในแบบของตัวเองก็ตาม แต่จุดแข็งของมันถูกเปิดเผยอย่างแม่นยำในฐานะองค์ประกอบ aaS ในระบบคลาวด์ หากคุณตั้งเป้าหมายและทำให้ทุกอย่างเป็นแบบอัตโนมัติมากที่สุดเท่าที่จะเป็นไปได้ คุณจะสามารถหลีกเลี่ยงการผูกมัดของผู้ขายได้ และการย้ายระหว่างผู้ให้บริการคลาวด์จะใช้เวลาสองสามชั่วโมง และเซลล์ประสาทก็จะยังคงอยู่กับเรา เราสามารถให้คำแนะนำแก่บริษัทอื่นๆ ได้: หากคุณต้องการเปิดตัวบริการ (คลาวด์) ของคุณเอง โดยมีทรัพยากรที่จำกัดและมีความเร็วสูงสุดในการพัฒนา ให้เริ่มตั้งแต่ตอนนี้ด้วยการเช่าทรัพยากรบนคลาวด์ และสร้างศูนย์ข้อมูลของคุณหลังจากที่ Forbes เขียนถึงคุณ
ที่มา: will.com