สำรองข้อมูล 39 สินค้าและ CSV บนเซิร์ฟเวอร์จิ๋ว 2 GB
เรียนรู้วิธีสำรองข้อมูลแคตตาล็อกสินค้าดิจิทัล 39 รายการ และไฟล์ CSV บนเซิร์ฟเวอร์ 1 vCPU RAM 2 GB หลังจากเคยพลาดทำข้อมูลหายเมื่อเดือนมีนาคมที่ผ่านมา
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ความผิดพลาดจากการคิดว่าโฮสต์สำรองข้อมูลให้ ทำให้ต้องเสียเวลาแก้งานหนึ่งคืนเต็มเมื่อเดือนมีนาคม
- แบ่งแคตตาล็อก 39 สินค้า (ขนาด 856 MB) ออกเป็น 3 ระดับ เพื่อกำหนดตารางและระยะเวลาเก็บรักษาที่เหมาะสม
- ไฟล์ CSV และระบบติดตามการอัปโหลด (upload_tracker.py) มีความสำคัญไม่แพ้ไฟล์งาน เพราะเก็บบันทึกการตัดสินใจและป้องกันการอัปโหลดซ้ำ
- เซิร์ฟเวอร์ขนาด 1 vCPU และ RAM 2 GB มีข้อจำกัดด้านทรัพยากร จึงต้องจัดการงานประมวลผลและบีบอัดข้อมูลไม่ให้ชนกันเพื่อป้องกันปัญหาหน่วยความจำเต็ม
เมื่อเดือนมีนาคมที่ผ่านมา ผมต้องเสียเวลาไปหนึ่งคืนเต็มเพราะคิดไปเองว่าโฮสต์ได้จัดการเรื่องการสำรองข้อมูลไว้ให้แล้ว แต่ความจริงไม่ใช่เช่นนั้น ระบบสแนปชอตรายวันบนกล่องเซิร์ฟเวอร์ขนาด 1 vCPU และ RAM 2 GB ของผมเก็ยข้อมูลย้อนหลังไว้เพียง 7 วันเท่านั้น ในขณะที่ผมจำเป็นต้องใช้ไฟล์ CSV ย้อนหลังไป 11 วัน ซึ่งเป็นไฟล์อัปโหลดแบบ 5 คอลัมน์ของ Adobe สำหรับชุดผลงาน 40 ชิ้นที่ส่งไปแล้ว การจะสร้างไฟล์นั้นขึ้นมาใหม่หมายความว่าต้องรันสคริปต์ make_metadata.py ซ้ำอีกครั้งกับโฟลเดอร์ไฟล์ที่ถูกเปลี่ยนชื่อไปแล้ว เหตุการณ์ครั้งนั้นทำให้การสำรองข้อมูลกลายเป็นส่วนหนึ่งในกระบวนการทำงานหลัก ไม่ใช่แค่เรื่องที่ทำทีหลัง
แคตตาล็อกของผมประกอบด้วยผลิตภัณฑ์ที่เสร็จสมบูรณ์แล้ว 39 รายการ คิดเป็นขนาดข้อมูลที่อัดแน่นรวมกัน 856 MB ตัวเลขนี้มีความสำคัญเพราะเป็นตัวกำหนดกลยุทธ์การจัดการ ขนาด 856 MB นั้นเล็กพอที่จะทำเวอร์ชันหรือซิงก์ได้ แต่ทรัพยากรตั้งต้นเบื้องหลังนั้นไม่ใช่ โครงการหลักมีโค้ดไปป์ไลน์ประมาณ 19,000 บรรทัด และบันทึกการวิจัยอีกกว่า 300 หน้า หากสำรองเฉพาะไฟล์ซิป คุณจะสูญเสียความสามารถในการสร้างหรือแพ็กเกจสินค้าใหม่ทั้งหมด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ผมจึงแบ่งแคตตาล็อกออกเป็น 3 ระดับ ดังนี้:
- ระดับที่หนึ่ง: โฟลเดอร์งานวิจัยและบันทึกข้อมูล
- ระดับที่สอง: โค้ดสคริปต์และไปป์ไลน์
- ระดับที่สาม: ไฟล์ผลลัพธ์และชุดผลิตภัณฑ์ที่จัดทำเสร็จแล้ว
ความผิดพลาดที่ผมเคยทำคือการปฏิบัติกับข้อมูลทุกส่วนเหมือนกันหมดแล้วไม่สำรองข้อมูลส่วนไหนให้ถูกวิธีเลย ผู้คนมักจะสำรองไฟล์ผลงานศิลปะแต่ลืมข้อมูลเมตาดาตา ซึ่งเป็นแนวคิดที่ผิดพลาด เพราะไฟล์งานศิลปะมีอยู่แล้วบนดิสก์ แต่เมตาดาตานั้นเข้ารหัสการตัดสินใจทั้งหมด เช่น ชื่อเรื่อง คีย์บอร์ด หรือลำดับที่ แพลตฟอร์มต่างๆ จะปฏิเสธหัวตาราง CSV ที่ไม่ถูกต้องทันที Adobe ต้องการหัวตาราง 5 คอลัมน์ Vecteezy ต้องการ 4 คอลัมน์ และ Dreamstime ต้องการ 15 คอลัมน์ สคริปต์ make_metadata.py จะเขียนหัวตารางที่แต่ละแพลตฟอร์มต้องการอย่างแม่นยำ
การบริหารจัดการเซิร์ฟเวอร์ขนาดเล็กที่มีข้อจำกัดด้านฮาร์ดแวร์อย่าง 1 vCPU และ RAM 2 GB สะท้อนให้เห็นว่า นักพัฒนาเดี่ยว (Solo Developer) หรือผู้สร้างผลิตภัณฑ์ดิจิทัลจำเป็นต้องออกแบบสคริปต์และระบบอัตโนมัติที่มีน้ำหนักเบาและพึ่งพาไลบรารีภายนอกให้น้อยที่สุด การทำความเข้าใจขีดจำกัดของระบบช่วยป้องกันปัญหา OOM (Out of Memory) ที่อาจทำให้เซิร์ฟเวอร์ล่มกลางคันระหว่างการประมวลผลไฟล์ขนาดใหญ่
ข้อจำกัดที่กำหนดรูปแบบการเรนเดอร์ก็เป็นสิ่งเดียวกับที่กำหนดการสำรองข้อมูลเช่นกัน การมี vCPU เพียงตัวเดียวหมายความว่าระบบต้องรันทีละกระบวนการ รวมถึงงานเก็บรักษาข้อมูล การรันคำสั่ง tar หรือ rsync ในขณะที่กำลังเรนเดอร์งานอยู่จะทำให้เกิดปัญหาหน่วยความจำหมดและไฟล์เก็บถาวรเสียหายได้ ผมจึงตั้งตารางงานสำรองไว้ 3 รูปแบบ ได้แก่ การคอมมิตตัวติดตามและ CSV รายวัน การซิงก์แพ็กเกจรายสัปดาห์ และการกู้คืนข้อมูลที่ตรวจสอบแล้วรายเดือน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สิ่งที่ผมไม่มีคือเว็บไซต์กู้คืนหายนะ (DR Site) ที่สามารถรันไปป์ไลน์ทั้งหมดได้ หากเซิร์ฟเวอร์หลักพัง ผมสามารถกู้คืนทุกผลิตภัณฑ์และทุก CSV เพื่อขายต่อได้ แต่การสร้างสภาพแวดล้อมรันไทม์ 1 vCPU ขึ้นมาใหม่จะต้องใช้เวลาตั้งค่าช่วงบ่ายครึ่งวัน สำหรับการดำเนินงานคนเดียวที่มี 39 ผลิตภัณฑ์ การแลกเปลี่ยนนี้มีความคุ้มค่าและยอมรับได้ ผมได้รวบรวมชุดเครื่องมือทั้งหมดนี้ในชื่อ compliance metadata kit ซึ่งประกอบด้วยสคริปต์ Python 4 ตัว โครงสร้างโฟลเดอร์ และบันทึกการใช้งาน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น