ฐานข้อมูลอยู่ใน Kubernetes หรือไม่

ในอดีต อุตสาหกรรมไอทีถูกแบ่งออกเป็นสองค่ายที่มีเงื่อนไขไม่ว่าด้วยเหตุผลใดก็ตาม: พวกที่ "เพื่อ" และพวกที่ "ต่อต้าน" นอกจากนี้ เรื่องของข้อพิพาทสามารถเป็นไปตามอำเภอใจได้อย่างสมบูรณ์ ระบบปฏิบัติการไหนดีกว่า: Win หรือ Linux บนสมาร์ทโฟน Android หรือ iOS? คุณควรเก็บทุกอย่างไว้บนคลาวด์หรือวางไว้บนที่จัดเก็บข้อมูล RAID แบบเย็นแล้วใส่สกรูไว้ในตู้นิรภัยหรือไม่? ชาว PHP มีสิทธิ์ถูกเรียกว่าโปรแกรมเมอร์หรือไม่? ในบางครั้งข้อพิพาทเหล่านี้มีอยู่แต่เพียงผู้เดียวและไม่มีพื้นฐานอื่นใดนอกจากผลประโยชน์ด้านกีฬา

มันเกิดขึ้นกับการถือกำเนิดของคอนเทนเนอร์และอาหารอันเป็นที่รักทั้งหมดนี้ด้วยนักเทียบท่าและ k8 แบบมีเงื่อนไข การถกเถียง "เพื่อ" และ "ต่อต้าน" การใช้ความสามารถใหม่ในด้านต่างๆ ของแบ็กเอนด์ก็เริ่มต้นขึ้น (โปรดจองล่วงหน้าว่าแม้ว่า Kubernetes มักจะถูกระบุว่าเป็นผู้เรียบเรียงในการสนทนานี้ แต่การเลือกเครื่องมือเฉพาะนี้ไม่มีความสำคัญพื้นฐาน แต่คุณสามารถใช้ทดแทนเครื่องมืออื่นที่ดูสะดวกและคุ้นเคยที่สุดสำหรับคุณ .)

และดูเหมือนว่านี่จะเป็นข้อโต้แย้งง่ายๆ ระหว่างสองด้านของเหรียญเดียวกัน ไร้สติและไร้ความปราณีพอๆ กับการเผชิญหน้าชั่วนิรันดร์ระหว่าง Win และ Linux ซึ่งมีผู้คนเพียงพออยู่ตรงกลาง แต่ในกรณีของการบรรจุลงภาชนะ ไม่ใช่ทุกอย่างจะง่ายนัก โดยปกติแล้วในข้อพิพาทดังกล่าวจะไม่มีฝ่ายขวา แต่ในกรณีของคอนเทนเนอร์ "ใช้" หรือ "ไม่ใช้" ในการจัดเก็บฐานข้อมูลทุกอย่างจะกลับหัวกลับหาง เพราะในแง่หนึ่งทั้งผู้สนับสนุนและฝ่ายตรงข้ามของแนวทางนี้ล้วนถูกต้อง

ด้านสว่าง

ข้อโต้แย้งของ Light Side สามารถอธิบายสั้นๆ ได้ด้วยวลีเดียว: “สวัสดี 2k19 อยู่นอกหน้าต่าง!” ฟังดูเหมือนประชานิยมแน่นอน แต่ถ้าคุณเจาะลึกสถานการณ์โดยละเอียด มันก็มีข้อดีอยู่ มาจัดเรียงกันตอนนี้

สมมติว่าคุณมีโครงการเว็บขนาดใหญ่ ในตอนแรกมันสามารถถูกสร้างขึ้นบนพื้นฐานของแนวทางไมโครเซอร์วิสหรือเมื่อถึงจุดหนึ่งมันก็มาถึงมันผ่านเส้นทางวิวัฒนาการ - นี่ไม่ได้สำคัญมากในความเป็นจริง คุณกระจายโปรเจ็กต์ของเราออกเป็นไมโครเซอร์วิสที่แยกจากกัน ตั้งค่าการเรียบเรียง โหลดบาลานซ์ และการปรับขนาด และตอนนี้ ด้วยมโนธรรมที่ชัดเจน คุณจิบโมฮิโต้ในเปลญวนระหว่างเอฟเฟกต์ฮาบรา แทนที่จะยกเซิร์ฟเวอร์ที่พัง แต่ในทุกการกระทำคุณต้องมีความสม่ำเสมอ บ่อยครั้ง เฉพาะแอปพลิเคชันเท่านั้น—โค้ด—เท่านั้นที่ถูกบรรจุ เรามีอะไรอีกนอกจากโค้ด?

ถูกต้องแล้วข้อมูล หัวใจของโครงการใดๆ ก็ตามคือข้อมูล ซึ่งอาจเป็นได้ทั้ง DBMS ทั่วไป - MySQL, Postgre, MongoDB หรือพื้นที่เก็บข้อมูลที่ใช้สำหรับการค้นหา (ElasticSearch) พื้นที่จัดเก็บคีย์-ค่าสำหรับการแคช - เช่น Redis เป็นต้น ในปัจจุบัน เราไม่ได้ เราจะพูดถึงตัวเลือกการใช้งานแบ็กเอนด์ที่คดเคี้ยวเมื่อฐานข้อมูลล่มเนื่องจากการสืบค้นที่เขียนไม่ดี และเราจะพูดถึงการรับรองความทนทานต่อข้อบกพร่องของฐานข้อมูลนี้ภายใต้โหลดของไคลเอ็นต์แทน ท้ายที่สุดแล้ว เมื่อเราจัดคอนเทนเนอร์แอปพลิเคชันของเราและปล่อยให้แอปพลิเคชันปรับขนาดได้อย่างอิสระเพื่อประมวลผลคำขอที่เข้ามาจำนวนเท่าใดก็ได้ สิ่งนี้จะเพิ่มภาระในฐานข้อมูลโดยธรรมชาติ

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

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

คุณรู้สึกถึงการจับหรือไม่? เราใช้ k8s หรือ Swarm เพื่อกระจายโหลดและหลีกเลี่ยงการหยุดทำงานของเว็บเซิร์ฟเวอร์หลัก แต่เราไม่ทำเช่นนี้กับฐานข้อมูล แต่หากฐานข้อมูลล่ม โครงสร้างพื้นฐานแบบคลัสเตอร์ทั้งหมดของเราก็ไม่สมเหตุสมผล - หน้าเว็บว่างเปล่าที่ส่งกลับข้อผิดพลาดในการเข้าถึงฐานข้อมูลมีข้อดีอย่างไร

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

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

นอกจากนี้ คอนเทนเนอร์ของฐานข้อมูลยังช่วยให้คุณสร้างองค์ประกอบทั้งหมดของระบบในระดับนามธรรมเดียวกัน ซึ่งในทางกลับกันทำให้สามารถจัดการระบบนี้ได้โดยตรงจากโค้ดโดยนักพัฒนา โดยไม่ต้องมีส่วนร่วมของผู้ดูแลระบบ นักพัฒนาคิดว่าจำเป็นต้องมี DBMS แยกต่างหากสำหรับโครงการย่อยใหม่ - ง่ายมาก! เขียนไฟล์ yaml อัปโหลดไปยังคลัสเตอร์ เท่านี้ก็เสร็จเรียบร้อย

และแน่นอนว่าการดำเนินงานภายในนั้นง่ายขึ้นมาก บอกฉันกี่ครั้งแล้วที่คุณหลับตาเมื่อสมาชิกในทีมใหม่ยื่นมือเข้าไปในฐานข้อมูลการต่อสู้เพื่อทำงาน? อันไหนอันที่จริงเป็นอันเดียวที่คุณมีและกำลังหมุนอยู่ตอนนี้? แน่นอนว่าเราทุกคนเป็นผู้ใหญ่ที่นี่ และที่ไหนสักแห่งที่เรามีการสำรองข้อมูลใหม่และยิ่งห่างไกลออกไป - หลังชั้นวางที่มีแตงกวาของคุณยายและสกีเก่า - การสำรองข้อมูลอีกครั้ง บางทีอาจจะอยู่ในห้องเย็นด้วยซ้ำ เพราะสำนักงานของคุณถูกไฟไหม้ไปแล้วครั้งหนึ่ง แต่ถึงกระนั้น การแนะนำสมาชิกในทีมใหม่ทุกครั้งด้วยการเข้าถึงโครงสร้างพื้นฐานการต่อสู้ และแน่นอนว่า ฐานข้อมูลการต่อสู้นั้นเปรียบได้กับทุกคนที่อยู่รอบตัว ใครจะรู้จักเขา เป็นมือใหม่ บางทีเขาอาจจะเป็นมือครอสก็ได้? มันน่ากลัวคุณจะเห็นด้วย

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

และตอนนี้ก็ถึงเวลาที่จะเปลี่ยนเป็นฝ่ายตรงข้ามของการจัดกลุ่มฐานข้อมูล

ด้านมืด

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

เห็นด้วย โครงการที่จำเป็นต้องมีฐานในภาชนะจริงๆ สามารถนับได้ด้วยนิ้วมือข้างเดียวโดยไม่ใช่ผู้ปฏิบัติงานเครื่องกัดที่เก่งที่สุด โดยส่วนใหญ่แม้แต่การใช้ k8s หรือ Docker Swarm เองก็ซ้ำซ้อน - บ่อยครั้งที่เครื่องมือเหล่านี้ถูกนำมาใช้เนื่องจากเทคโนโลยีทั่วไปที่แพร่หลายและทัศนคติของ "ผู้ทรงอำนาจ" ในบุคคลของเพศที่จะผลักดันทุกอย่างเข้าสู่ เมฆและตู้คอนเทนเนอร์ เพราะตอนนี้มันทันสมัยและใครๆ ก็ทำกัน

อย่างน้อยครึ่งหนึ่งของกรณี การใช้ Kubernetis หรือเพียงแค่ Docker ในโปรเจ็กต์นั้นซ้ำซ้อน ปัญหาก็คือไม่ใช่ทุกทีมหรือบริษัทเอาท์ซอร์สที่ได้รับการว่าจ้างให้ดูแลโครงสร้างพื้นฐานของลูกค้าจะตระหนักถึงเรื่องนี้ จะแย่กว่านั้นเมื่อมีการบังคับใช้คอนเทนเนอร์ เนื่องจากจะต้องเสียเหรียญจำนวนหนึ่งให้กับลูกค้า

โดยทั่วไปมีความเห็นว่ามาเฟียนักเทียบท่า/คิวบ์กำลังบดขยี้ลูกค้าที่จ้างบุคคลภายนอกเพื่อแก้ไขปัญหาโครงสร้างพื้นฐานเหล่านี้อย่างโง่เขลา ท้ายที่สุดแล้ว เพื่อที่จะทำงานร่วมกับคลัสเตอร์ได้ เราต้องการวิศวกรที่มีความสามารถและเข้าใจสถาปัตยกรรมของโซลูชันที่นำมาใช้โดยทั่วไป ครั้งหนึ่งเราได้อธิบายกรณีของเรากับสิ่งพิมพ์ของ Republic แล้ว - ที่นั่นเราได้ฝึกอบรมทีมลูกค้าให้ทำงานในความเป็นจริงของ Kubernetis และทุกคนก็พอใจ และมันก็เหมาะสม บ่อยครั้งที่ “ผู้ปรับใช้” ของ k8 ยึดโครงสร้างพื้นฐานของลูกค้าเป็นตัวประกัน - เพราะตอนนี้มีเพียงพวกเขาเท่านั้นที่เข้าใจว่าทุกอย่างทำงานอย่างไร ฝั่งไคลเอ็นต์ไม่มีผู้เชี่ยวชาญ

ทีนี้ ลองจินตนาการว่าด้วยวิธีนี้ เราไม่เพียงแต่จ้างบุคคลภายนอกในส่วนของเว็บเซิร์ฟเวอร์เท่านั้น แต่ยังรวมถึงการบำรุงรักษาฐานข้อมูลด้วย เราบอกว่า BD คือหัวใจ และการสูญเสียหัวใจนั้นเป็นอันตรายถึงชีวิตสำหรับสิ่งมีชีวิตทุกชนิด กล่าวโดยสรุป แนวโน้มไม่ได้ดีที่สุด ดังนั้น แทนที่จะเป็นโฆษณาเกินจริง Kubernetis หลายโครงการไม่ควรกังวลกับอัตราค่าไฟฟ้าปกติสำหรับ AWS ซึ่งจะแก้ปัญหาทั้งหมดเกี่ยวกับโหลดบนไซต์/โครงการของตน แต่ AWS ไม่ทันสมัยอีกต่อไป และการจัดแสดงก็คุ้มค่ามากกว่าเงิน น่าเสียดายในสภาพแวดล้อมด้านไอทีเช่นกัน

ตกลง. บางทีโปรเจ็กต์จำเป็นต้องมีการทำคลัสเตอร์จริงๆ แต่ถ้าทุกอย่างชัดเจนกับแอปพลิเคชันไร้สัญชาติ แล้วเราจะจัดระเบียบการเชื่อมต่อเครือข่ายที่เหมาะสมสำหรับฐานข้อมูลแบบคลัสเตอร์ได้อย่างไร

หากเรากำลังพูดถึงโซลูชันทางวิศวกรรมที่ราบรื่น ซึ่งเป็นสิ่งที่การเปลี่ยนมาใช้ k8s ปัญหาหลักของเราคือการจำลองข้อมูลในฐานข้อมูลแบบคลัสเตอร์ ในตอนแรก DBMS บางตัวค่อนข้างภักดีต่อการกระจายข้อมูลระหว่างแต่ละอินสแตนซ์ อีกหลายคนไม่ค่อยต้อนรับ และบ่อยครั้งที่ข้อโต้แย้งหลักในการเลือก DBMS สำหรับโครงการของเราไม่ใช่ความสามารถในการทำซ้ำโดยใช้ทรัพยากรและต้นทุนทางวิศวกรรมน้อยที่สุด โดยเฉพาะอย่างยิ่งหากโครงการไม่ได้ถูกวางแผนไว้ในตอนแรกว่าเป็นไมโครเซอร์วิส แต่เพียงพัฒนาไปในทิศทางนี้

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

ดำเนินการต่อในหัวข้อของระบบไฟล์เสมือน: Docker Volumes น่าเสียดายที่ไม่ใช่ปัญหา โดยทั่วไป ในเรื่องของการจัดเก็บข้อมูลที่เชื่อถือได้ในระยะยาว ฉันต้องการดำเนินการตามรูปแบบทางเทคนิคที่เรียบง่ายที่สุด และการเพิ่มเลเยอร์นามธรรมใหม่จาก FS ของคอนเทนเนอร์ไปยัง FS ของโฮสต์หลักถือเป็นความเสี่ยงในตัวเอง แต่เมื่อการทำงานของระบบสนับสนุนคอนเทนเนอร์ประสบปัญหาในการส่งข้อมูลระหว่างเลเยอร์เหล่านี้ ก็ถือเป็นหายนะจริงๆ ในขณะนี้ ปัญหาส่วนใหญ่ที่มนุษยชาติยุคก้าวหน้าทราบกันดีดูเหมือนจะหมดสิ้นไปแล้ว แต่คุณเข้าใจว่ายิ่งกลไกซับซ้อนมากเท่าไหร่ก็ยิ่งพังได้ง่ายขึ้นเท่านั้น

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

เรากำลังนำไปสู่อะไร? นอกจากนี้ การจัดคอนเทนเนอร์ฐานข้อมูลยังเหมาะสมในกรณีที่มีความจำเป็นอย่างแท้จริง คุณไม่สามารถยัดฐานข้อมูลแอปแบบเต็มและหมุนราวกับว่าคุณมีไมโครเซอร์วิสสองโหล - มันไม่ได้ผลเช่นนั้น และสิ่งนี้จะต้องเข้าใจให้ชัดเจน

แทนการส่งออก

หากคุณกำลังรอข้อสรุปที่ชัดเจนว่า "จะจำลองฐานข้อมูลหรือไม่" เราจะทำให้คุณผิดหวัง: มันจะไม่อยู่ที่นี่ เพราะเมื่อสร้างโซลูชันโครงสร้างพื้นฐานใดๆ เราจะต้องได้รับคำแนะนำไม่ใช่จากแฟชั่นและความก้าวหน้า แต่ก่อนอื่นเลย ต้องคำนึงถึงสามัญสำนึก

มีโครงการหลายโครงการที่หลักการและเครื่องมือที่มาพร้อมกับ Kubernetis เข้ากันได้อย่างลงตัว และในโครงการดังกล่าว อย่างน้อยก็จะมีความสงบสุขในส่วนแบ็กเอนด์ และมีโปรเจ็กต์ที่ไม่ต้องการคอนเทนเนอร์ แต่เป็นโครงสร้างพื้นฐานของเซิร์ฟเวอร์ปกติ เนื่องจากโดยพื้นฐานแล้วไม่สามารถขายต่อเป็นโมเดลคลัสเตอร์ไมโครเซอร์วิสได้ เนื่องจากโปรเจ็กต์จะล้มเหลว

ที่มา: will.com