ผมใช้งาน AWS มาตั้งแต่ปี 2013 แต่เมื่อไม่นานมานี้ได้สร้างเซิร์ฟเวอร์ของตัวเองขึ้นมาเพื่อประหยัดค่าใช้จ่ายและทำให้คาดการณ์ต้นทุนได้มากขึ้น ขอนำมาแบ่งปันถึงเหตุผลในการย้ายไปใช้เซิร์ฟเวอร์ภายในองค์กร กระบวนการย้าย มาตรการด้านความปลอดภัย และกรณีการนำการยืนยันตัวตนหลายขั้นตอน (MFA) มาใช้
เหตุผลในการย้าย
• ลดต้นทุน: เมื่อใช้ AWS คาดการณ์ค่าใช้จ่ายได้ยาก และยังมีภาระจากอัตราแลกเปลี่ยนดอลลาร์ที่เพิ่มสูงขึ้น
• ลักษณะของบริการ B2B: มีโอกาสที่จำนวนผู้ใช้จะเพิ่มขึ้นอย่างรวดเร็วไม่มากนัก และสามารถควบคุมจำนวนสัญญาได้ จึงไม่มีปัญหาเรื่องการขยายระบบ
กระบวนการย้ายและความท้าทาย
• งานย้ายระบบ: ย้ายฐานข้อมูล เซิร์ฟเวอร์สเตจจิง และบริการใหม่ที่กำลังพัฒนา ไปยังเซิร์ฟเวอร์ภายใน
• การแก้ปัญหาในช่วงแรก: แก้ไขปัญหาความเข้ากันได้ระหว่างการตั้งค่าเซิร์ฟเวอร์ และความจำเป็นในการอัปเกรดฮาร์ดแวร์
ข้อดีระยะยาว
• ลดต้นทุน: ใช้ทรัพยากรของเซิร์ฟเวอร์จริงให้คุ้มค่าที่สุดเพื่อลดค่าใช้จ่าย
• เสริมความปลอดภัย: เพิ่มความปลอดภัยด้วยการนำการยืนยันตัวตนหลายขั้นตอน (MFA) ที่ใช้ GPT มาปรับใช้
มาตรการด้านความปลอดภัย
• การจัดการสิทธิ์การเข้าถึง: ตั้งค่าช่วง IP จัดการ ID และรหัสผ่าน และนำการยืนยันตัวตนหลายขั้นตอนมาใช้
• ความปลอดภัยทางกายภาพ: ระบบควบคุมการเข้าออกและระบบเฝ้าระวังของดาต้าเซ็นเตอร์
• การตรวจสอบเป็นประจำ: ตรวจสอบความปลอดภัยและวิเคราะห์ช่องโหว่ สำรองข้อมูลเป็นประจำ และจัดเก็บไว้ในสตอเรจภายนอก
การนำการยืนยันตัวตนหลายขั้นตอน (MFA) มาใช้
• การเลือกโซลูชัน MFA: Google Authenticator, Authy, Yubikey เป็นต้น
• การพัฒนา: เพิ่มขั้นตอน MFA ในโฟลว์การยืนยันตัวตนของผู้ใช้ เชื่อมต่อ API และปรับปรุงส่วนติดต่อผู้ใช้
• โค้ดตัวอย่าง: มีตัวอย่างการใช้งาน MFA ด้วย Python Flask และ Ruby on Rails
คำตอบสำหรับคำถามเพิ่มเติม
Q1: จัดการการดูแลให้ฟิสิคัลเซิร์ฟเวอร์ทำงานได้อย่างเสถียรท่ามกลางสภาพอากาศร้อนจัดในหน้าร้อนของเกาหลีและฝุ่นได้อย่างไร?
• การจัดการสภาพแวดล้อมในห้องเซิร์ฟเวอร์: ใช้เครื่องปรับอากาศและเครื่องลดความชื้น ติดตั้งเครื่องฟอกอากาศ และทำความสะอาดเป็นประจำ
• ระบบมอนิเตอร์: ตรวจสอบอุณหภูมิและความชื้นแบบเรียลไทม์
• การบำรุงรักษาฮาร์ดแวร์: ตรวจสอบและบำรุงรักษาเป็นประจำ
Q2: มีแผนสำรองอย่างไรหากเกิดไฟฟ้าดับหรือใช้อินเทอร์เน็ตไม่ได้โดยไม่คาดคิด?
• การเดินระบบเซิร์ฟเวอร์แบบซ้ำซ้อน: กระจายติดตั้งเซิร์ฟเวอร์ไปยังหลายพื้นที่ทางกายภาพ
• ระบบ UPS: ติดตั้งอุปกรณ์จ่ายไฟสำรองแบบไม่สะดุด
• การทำอินเทอร์เน็ตแบบสองเส้นทาง: ใช้การเชื่อมต่ออินเทอร์เน็ตตั้งแต่สองชุดขึ้นไป
• แผนสำรองและกู้คืนข้อมูล: สำรองข้อมูลเป็นประจำและเตรียมแผนกู้คืนอย่างรวดเร็ว
8 ความคิดเห็น
จากการหนีออกจาก AWS ที่ใช้มานาน 10 ปี ปลายทางกลับกลายเป็น Mac mini M1, M2.... นี่ไม่ใช่ไวรัลของ Apple ใช่ไหม?
ถึงองค์ประกอบอินฟราสตรักเจอร์อื่น ๆ จะดูออกแบบมาอย่างดีแค่ไหน แต่ตรงนี้มันทรงอิมแพกต์เกินไปจริง ๆ
ดูเหมือนว่าจะมีประเด็นด้านการปฏิบัติการสะสมอยู่ไม่น้อยมากกว่าด้านการพัฒนา เช่น การตั้งค่าเครือข่ายรวมถึงไฟร์วอลล์และการกำหนดเส้นทาง การสำรองข้อมูลแบบ off-site การจัดทำฉันทามติด้านความปลอดภัย เป็นต้น (ถ้าเป็น B2B ก็รวมถึงข้อกำหนดด้านความปลอดภัยที่ลูกค้าองค์กรร้องขอด้วย) เลยสงสัยว่าเคยรู้สึกถึงความจำเป็นที่จะต้องตั้งองค์กรแยกต่างหากขึ้นมารับผิดชอบหรือไม่ครับ
เป็นคำถามนอกเรื่องนิดหน่อย แต่อยากรู้ว่า หมายถึงเอา GPT มาเชื่อมเพื่อสร้าง MFA เหรอ? หรือหมายถึงใช้ GPT ช่วยเขียนโค้ด? สงสัยน่ะครับ ว่านี่เป็นเคสที่ ChatGPT กลายเป็นผู้ดูแลความปลอดภัยหรือเปล่า?
ดูจากเนื้อหาแล้ว น่าจะประมาณว่าไปถาม ChatGPT เพื่อขอคำแนะนำ แล้วก็ดำเนินมาตรการต่าง ๆ นะครับ
ในแง่ของ H/W ก็พอเข้าใจได้ว่าทำไมถึงแนะนำ mac mini แต่..
ถ้าใช้ docker บน Mac สุดท้ายก็ต้องรัน VM แล้วให้ docker ทำงานอยู่บนชั้นนั้นอยู่ดี...
สำหรับสภาพแวดล้อมโปรดักชัน การใช้ docker บน Mac ก็ทำให้ต้องเอียงคอสงสัยนิดหน่อยเหมือนกันครับ
ผมก็ยังรู้สึกแปลกใจกับส่วนนั้นเหมือนกัน ในสภาพแวดล้อม Docker ฝั่ง ARM ยังมีทางให้ไปอีกพอสมควร ยิ่งไปกว่านั้น ถ้าเป็น OSX อย่างที่คุณพูด ก็ต้องรันบน VM อย่าง qemu ซึ่งความสูญเสียด้านประสิทธิภาพก็ค่อนข้างมาก ดังนั้นการแนะนำชุดผสมแบบนี้เลยดูแปลกนิดหน่อยนะครับ
หมายความว่าสามารถรันได้ถึงขั้นเป็นสภาพแวดล้อมโปรดักชันบน Apple Mac เลยหรือครับ?
ทั้งพาวเวอร์และดิสก์ก็คงไม่ได้ทำ Redundancy ไว้ เลยสงสัยว่าถ้าเกิดปัญหาฮาร์ดแวร์ขึ้นมาจะจัดการอย่างไรครับ
พอนึกถึงค่าเช่าอสังหาริมทรัพย์หรือค่าเช่าพื้นที่ใน IDC ก็พอจะเข้าใจได้บ้างว่าทำไมคลาวด์ถึงแพง ดูเหมือนว่าเป้าหมายที่ยากที่สุดคือการเดินระบบเซิร์ฟเวอร์แบบซ้ำซ้อน