การจัดการสคีมาด้วย Skeema

หมายเหตุ: โพสต์นี้มาจากทีมวิศวกรรมของ SendGrid สำหรับบทความด้านเทคนิคเพิ่มเติมเช่นนี้ โปรดดูบล็อกทางเทคนิคของเรา

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

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

ก่อนหน้านี้ ผู้ดูแลฐานข้อมูล (DBA) ได้กลายมาเป็นผู้รักษาประตูของฐานข้อมูล เพื่อปกป้องฐานข้อมูลจากสิ่งเลวร้ายที่เกิดขึ้น แต่การมี DBA แบบเก่าอยู่ระหว่างนักพัฒนาและฐานข้อมูลของแอปพลิเคชันอาจทำให้วงจรการพัฒนาแอปพลิเคชันช้าลงอย่างมาก สร้างไซโลของการพัฒนาและการดำเนินงาน และสร้างความขัดแย้งระหว่างทีม

ในโลกของ micro service dev-ops ที่มุ่งเน้นในปัจจุบัน นักพัฒนาจำเป็นต้องสามารถจัดการการเปลี่ยนแปลง schema ของฐานข้อมูลได้ด้วยตนเอง เนื่องจากเป็นข้อมูลของพวกเขา และท้ายที่สุดแล้วพวกเขาจะรับผิดชอบต่อประสิทธิภาพการทำงานและเวลาทำงานของแอปพลิเคชัน ทีม DBA และทีมปฏิบัติการจำเป็นต้องจัดเตรียมเครื่องมือและคำแนะนำที่เหมาะสมเพื่อช่วยให้ทีมพัฒนากลายเป็นเจ้าของฐานข้อมูลของพวกเขา

วิธีที่เราจัดการสคีมา

กระบวนการจัดการสคีมาปัจจุบันของเราใช้ที่เก็บ Git เดียวเพื่อจัดเก็บสคีมาเริ่มต้นสำหรับคลัสเตอร์ฐานข้อมูลทั้งหมดของเรา และประกอบด้วยการเปลี่ยนแปลงที่ตามมาทั้งหมดกับสคีมานั้นเมื่อมีการปรับเปลี่ยน/สร้างและดร็อปตารางแต่ละรายการ:

• นักพัฒนาทำการเปลี่ยนแปลงสคีมาในเครื่องและสร้างคำสั่ง alter/create/drop และเพิ่มเป็นคำขอดึงไปยังสาขาการรวม
• ชุดตั๋ว Jira สำหรับทีม Data Operations ถูกสร้างขึ้นเพื่อตรวจสอบและนำการเปลี่ยนแปลงสคีมาไปใช้กับสภาพแวดล้อมการทดสอบ/การจัดเตรียมและการใช้งานจริงของเรา
• สมาชิกของทีม Data Operations ตรวจสอบการเปลี่ยนแปลงที่ร้องขอ และใช้การเปลี่ยนแปลงกับสภาพแวดล้อมการทดสอบ/การจัดเตรียม และรวม PR เข้ากับสาขาการรวม
• นักพัฒนาที่ร้องขอจะทดสอบการเปลี่ยนแปลงในสภาพแวดล้อมการทดสอบ/การจัดเตรียมของเรา และอนุมัติการเปลี่ยนแปลงที่จะนำไปใช้กับการผลิต
• สุดท้าย Data Operations จะผสานสาขาการรวมเข้ากับต้นแบบ และใช้การเปลี่ยนแปลงสคีมากับสภาพแวดล้อมการผลิต

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

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

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

เข้าสู่ Skeema (และผู้ช่วยไม่กี่คน)

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

เราใช้การเปลี่ยนแปลงสคีมาโดยอัตโนมัติจากการพัฒนาในพื้นที่ไปจนถึงการผลิตโดยใช้เครื่องมือที่มีอยู่ของเรา Git, Buildkite CI และ pt-online-schema-change ด้วยการเพิ่ม Skeema อีกหนึ่งรายการ

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

Skeema เป็นเครื่องมือ CLI ที่จัดการ MySQL schema ในรูปแบบการประกาศโดยใช้ SQL

สามารถสร้างภาษากำหนดข้อมูล (DDL) สำหรับแต่ละตารางในฐานข้อมูลและส่งออก DDL ไปยังระบบไฟล์ในเครื่องเพื่อรวมเข้ากับที่เก็บการติดตามผ่าน Git Skeema สามารถเปรียบเทียบไฟล์ SQL ในที่เก็บ Git กับฐานข้อมูล MySQL แบบสด และส่งออกความแตกต่างเหล่านั้นเป็นคำสั่ง DDL

นอกจากนี้ยังสามารถกำหนดค่าให้ใช้เครื่องมือ pt-online-schema-change ของ Percona และจัดรูปแบบคำสั่ง pt-online-schema-change ที่จำเป็นเพื่อให้ตรงกับสคีมาของฐานข้อมูล MySQL ที่รันอยู่กับสคีมาที่กำหนดไว้ในที่เก็บ Git

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

การสร้างที่เก็บสคีมาฐานข้อมูล MySQL แต่ละรายการจะทำลายที่เก็บ db-schema Git แบบเสาหินในปัจจุบันของเรา และอนุญาตให้นักพัฒนาในทีมที่แยกจากกันจัดการ MySQL schema ของแอปพลิเคชันในที่เก็บของตนเองแทนที่เก็บที่ใช้ร่วมกัน (db-schema)

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

องค์ประกอบที่สำคัญของการทำให้กระบวนการนี้เป็นแบบอัตโนมัติคือไปป์ไลน์ CI ของ Buildkite เราได้สร้างไปป์ไลน์ที่:

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

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

หากความแตกต่างคือการเปลี่ยนแปลงที่คาดหวังจาก PR นักพัฒนาสามารถปลดบล็อกขั้นตอนสุดท้ายนี้ และ Skeema จะใช้การเปลี่ยนแปลงกับคลัสเตอร์ฐานข้อมูล MySQL ที่ใช้งานจริง แต่ละขั้นตอนเหล่านี้เป็นขั้นตอนการบล็อกที่ต้องได้รับการอนุมัติจากทีมวิศวกรที่รับผิดชอบการเปลี่ยนแปลงที่ร้องขอก่อนที่จะไปยังขั้นตอนถัดไป

เท่าที่เกี่ยวข้องกับรั้วกั้น เราได้กำหนดค่า Skeema ไม่ให้เปลี่ยนแปลงสคีมาที่เป็นอันตรายในการผลิตเป็นค่าเริ่มต้น

อนุญาตให้ทำการเปลี่ยนแปลงแบบทำลายล้างในสภาพแวดล้อมการทดสอบและการจัดเตรียมของเรา

นอกจากนี้เรายังกำหนดค่า Skeema ให้ใช้ pt-online-schema-change เพื่อทำการเปลี่ยนแปลงสคีมา นี่เป็นเครื่องมือเปลี่ยนสคีมาแบบเดียวกับที่ทีม DataOps คุ้นเคยและใช้งานที่ SendGrid มาหลายปีแล้ว เราได้พัฒนาชุดตัวเลือกที่เหมาะสมสำหรับ pt-online-schema-change เพื่อย้อนกลับการเปลี่ยนแปลงหากการจำลองแบบล้มเหลวหรือเธรดที่ใช้งานอยู่ในฐานข้อมูลมีมากเกินไป

การกำหนดค่า Skeema ด้วยวิธีนี้จะช่วยขจัดข้อผิดพลาดที่อาจเกิดขึ้นจากการมีขั้นตอนด้วยตนเองสำหรับแอปพลิเคชันและการเข้ารหัสด้วยมือของคำสั่ง pt-online-schema-change โดยสมาชิกในทีม DataOps

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

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

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

การรวม Git, pt-online-schema-change, Skeema และไปป์ไลน์ Buildkite CI นำกระบวนการทางโปรแกรมที่เชื่อถือได้ ทำซ้ำได้ มาสู่การเปลี่ยนแปลงสคีมาฐานข้อมูล MySQL ช่วยให้นักพัฒนาสามารถจัดการสคีมาของฐานข้อมูลได้อย่างปลอดภัย และควบคุมความเร็วของฟีเจอร์และการแก้ไขต่างๆ ที่จะนำไปใช้ในการผลิตจริง

การรวมรั้วกั้นที่เหมาะสมในไฟล์การกำหนดค่าสำหรับการเปลี่ยนแปลง Skeema และ pt-online-schema จะเป็นการวัดความมั่นใจสำหรับนักพัฒนาที่นำการเปลี่ยนแปลงสคีมาไปใช้และให้ข้อเสนอแนะอันมีค่าเกี่ยวกับวิธีการที่เป็นไปได้ในการดำเนินการเปลี่ยนสคีมาหากรั้วดังกล่าวถูกกระแทก

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