Cloud Computing: เข้าใจคลาวด์ตั้งแต่พื้นฐานสู่การออกแบบระบบ

• 1. ทำความเข้าใจด้วยตัวอย่างใกล้ตัว
• 2. คุณลักษณะหลัก 5 ประการ
• 3. IaaS, PaaS และ SaaS ต่างกันอย่างไร
  • เลือกใช้กับระบบส่งงานอย่างไร
• 4. รูปแบบการติดตั้งคลาวด์
• 5. องค์ประกอบที่พบในการออกแบบระบบ
  • Storage ไม่ได้มีรูปแบบเดียว
• 6. Serverless, Container และ Kubernetes เกี่ยวข้องอย่างไร
• 7. ตัวอย่างสถาปัตยกรรมระบบส่งงานนักศึกษา
  • การทดสอบที่ควรวางแผน
• 8. Scalability และ Elasticity
• 9. ความปลอดภัยเป็นความรับผิดชอบร่วมกัน
• 10. ค่าใช้จ่าย: คิดให้ครบทั้งระบบ
  • ตัวอย่างสมมติสำหรับฝึกประมาณงบ
• 11. ความเข้าใจผิดที่พบบ่อย
• 12. กิจกรรมฝึกออกแบบโดยไม่ต้องเปิดบัญชีคลาวด์
• 13. แนวทางนำความรู้ไปใช้
• แหล่งอ้างอิง

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

#1. ทำความเข้าใจด้วยตัวอย่างใกล้ตัว

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

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

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

#2. คุณลักษณะหลัก 5 ประการ

NIST อธิบายคุณลักษณะสำคัญของคลาวด์ไว้ 5 ข้อ [1][2]

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

#3. IaaS, PaaS และ SaaS ต่างกันอย่างไร

การแบ่งรูปแบบบริการช่วยตอบคำถามว่า “ทีมของเราจะดูแลอะไรเอง” [3]

ขอบเขตจริงต้องตรวจสอบตามบริการ เพราะชื่อประเภทเพียงอย่างเดียวไม่ได้บอกหน้าที่ทั้งหมด

#เลือกใช้กับระบบส่งงานอย่างไร

• IaaS: เหมาะกับกิจกรรมที่ต้องเรียนรู้การติดตั้ง Linux เว็บเซิร์ฟเวอร์ และระบบฐานข้อมูลด้วยตนเอง
• PaaS: เหมาะกับทีมที่พัฒนาเว็บเองและต้องการใช้เวลาส่วนใหญ่กับฟังก์ชันส่งงานและตรวจงาน
• SaaS: เหมาะกับกรณีที่ระบบสำเร็จรูปตอบโจทย์ และไม่ต้องพัฒนากระบวนการเฉพาะจำนวนมาก

ทั้งสามรูปแบบสามารถอยู่ร่วมกันในองค์กรเดียว เช่น ใช้ SaaS สำหรับอีเมล ใช้ PaaS สำหรับเว็บ และใช้ IaaS สำหรับห้องปฏิบัติการ

#4. รูปแบบการติดตั้งคลาวด์

NIST แบ่งรูปแบบการติดตั้งออกเป็น 4 ประเภท [1]

Multi-cloud หมายถึงการใช้บริการจากผู้ให้บริการคลาวด์หลายราย เป็นอีกมิติหนึ่งในการออกแบบระบบ เช่น เว็บอยู่กับผู้ให้บริการ A และบริการวิเคราะห์ข้อมูลอยู่กับผู้ให้บริการ B

Public Cloud ไม่ได้หมายความว่าข้อมูลต้องเป็นสาธารณะ ส่วนการมีเซิร์ฟเวอร์ภายในองค์กรเพียงอย่างเดียวก็ยังไม่เพียงพอที่จะเรียกว่า Private Cloud หากไม่มีความสามารถในการจัดสรรและจัดการบริการแบบคลาวด์

#5. องค์ประกอบที่พบในการออกแบบระบบ

รายการต่อไปนี้เป็นกรอบสำหรับวิเคราะห์ความต้องการของแอป ไม่ใช่รายการที่ต้องซื้อหรือเปิดใช้ทั้งหมด

#Storage ไม่ได้มีรูปแบบเดียว

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

ต้องเลือกจากวิธีเข้าถึงข้อมูล ประสิทธิภาพ ความทนทาน และข้อจำกัดของแอป ไม่ใช่ดูเฉพาะราคาต่อพื้นที่

#6. Serverless, Container และ Kubernetes เกี่ยวข้องอย่างไร

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

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

Kubernetes เป็นระบบจัดการแอปที่ทำงานในคอนเทนเนอร์ สามารถใช้ได้ทั้งในศูนย์ข้อมูลขององค์กรและบนคลาวด์ การใช้คลาวด์จึงไม่จำเป็นต้องเริ่มด้วย Kubernetes

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

#7. ตัวอย่างสถาปัตยกรรมระบบส่งงานนักศึกษา

ตัวอย่างนี้เป็นแบบจำลองเพื่อการสอน ไม่ใช่สถาปัตยกรรมที่เหมาะกับทุกระบบ

flowchart TD
    U["นักศึกษาและอาจารย์"] --> G["จุดรับคำขอ HTTPS"]
    G --> A["เว็บและ API"]
    A --> D["ฐานข้อมูลรายวิชาและการส่งงาน"]
    A --> S["พื้นที่เก็บไฟล์แบบส่วนตัว"]
    A --> Q["คิวงานเบื้องหลัง"]
    Q --> W["ตัวประมวลผลงาน"]
    W --> D
    W --> S

การทำงานที่คาดหวังมีดังนี้

1. นักศึกษาเข้าสู่ระบบและเลือกงานที่ต้องส่ง
2. API ตรวจสอบสิทธิ์และวันกำหนดส่ง
3. ระบบเก็บไฟล์และบันทึกข้อมูลการส่งงาน โดยออกแบบให้ตรวจสอบความสอดคล้องของทั้งสองส่วนได้
4. งานที่ใช้เวลานาน เช่น สแกนไฟล์หรือสร้างภาพตัวอย่าง ถูกส่งเข้าคิว
5. ตัวประมวลผลงานอัปเดตสถานะเมื่อทำงานเสร็จ
6. อาจารย์ดูรายการส่งงานและเข้าถึงไฟล์ตามสิทธิ์

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

#การทดสอบที่ควรวางแผน

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

#8. Scalability และ Elasticity

Scalability คือความสามารถในการรองรับงานที่เพิ่มขึ้น เช่น เพิ่ม CPU ให้เครื่องเดิม หรือเพิ่มจำนวนแอปหลายชุด

Elasticity เน้นการปรับทรัพยากรขึ้นและลงตามภาระงาน เช่น เพิ่มแอปช่วงก่อนหมดเขตส่งงาน แล้วลดลงเมื่อคำขอน้อยลง

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

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

#9. ความปลอดภัยเป็นความรับผิดชอบร่วมกัน

ผู้ให้บริการและลูกค้ามีหน้าที่ร่วมกัน โดยขอบเขตขึ้นอยู่กับบริการ ตัวอย่างเช่น เมื่อเช่า VM ลูกค้ายังต้องดูแลระบบปฏิบัติการภายในเครื่อง แอป และการตั้งค่าการเข้าถึงที่เกี่ยวข้อง [4]

สำหรับระบบส่งงาน ทีมควรกำหนดให้ชัดว่าใครรับผิดชอบเรื่องต่อไปนี้

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

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

#10. ค่าใช้จ่าย: คิดให้ครบทั้งระบบ

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

#ตัวอย่างสมมติสำหรับฝึกประมาณงบ

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

หากเครื่องในตัวอย่างทำงาน 720 ชั่วโมง ค่าเครื่องจะเพิ่มเป็น 720 หน่วย และยอดรวมสามรายการจะเป็น 840 หน่วย แม้จำนวนไฟล์และฐานข้อมูลไม่เปลี่ยน

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

#11. ความเข้าใจผิดที่พบบ่อย

#12. กิจกรรมฝึกออกแบบโดยไม่ต้องเปิดบัญชีคลาวด์

โจทย์: ออกแบบระบบส่งงานสำหรับนักศึกษา 300 คน มีช่วงใช้งานหนาแน่นก่อนหมดเขตส่งงาน และเก็บไฟล์หนึ่งภาคการศึกษา

1. ระบุผู้ใช้ บทบาท และข้อมูลที่ระบบต้องเก็บ
2. เลือก IaaS, PaaS หรือ SaaS พร้อมอธิบายภาระดูแลของทีม
3. วาดแผนผังแอป ฐานข้อมูล และพื้นที่เก็บไฟล์
4. กำหนดว่าทรัพยากรใดเข้าถึงได้จากภายนอก
5. ประมาณพื้นที่จากจำนวนคน × จำนวนงาน × ขนาดไฟล์เฉลี่ย
6. ออกแบบการรับคำขอจำนวนมากและการจัดการเมื่อบริการบางส่วนล้มเหลว
7. กำหนดเกณฑ์เวลาตอบสนองและแผนทดสอบโหลด
8. กำหนดเวลาที่รับได้ในการกู้ระบบและช่วงข้อมูลที่ยอมสูญเสียได้
9. ประเมินต้นทุนอย่างน้อย 2 สถานการณ์: การใช้งานปกติและช่วงพีก
10. อธิบายขั้นตอนส่งออกข้อมูลและยกเลิกทรัพยากรเมื่อจบภาคเรียน

สิ่งส่งมอบ: แผนภาพสถาปัตยกรรมหนึ่งหน้า ตารางความรับผิดชอบ ตารางประมาณค่าใช้จ่าย และรายการทดสอบสำคัญ

#13. แนวทางนำความรู้ไปใช้

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

#แหล่งอ้างอิง

1. NIST. SP 800-145: The NIST Definition of Cloud Computing
2. NIST. Final Version of NIST Cloud Computing Definition Published
3. Microsoft Azure. What is cloud computing?
4. Amazon Web Services. Shared Responsibility Model