Cloud Computing & Virtualization

1Hardware Virtualization: ก่อนจะมี Cloud ต้องมีสิ่งนี้ก่อน

RAID: ความน่าเชื่อถือของ Storage ระดับล่าง

2วิวัฒนาการสู่ Cloud: จาก Grid สู่ Utility Computing

Build vs. Buy vs. Lease

3สามชั้นบริการ Cloud: IaaS / PaaS / SaaS

4จาก Virtual Machine ไปสู่ Container และ Serverless

5Virtualization แยกภาพที่ผู้ใช้เห็นออกจากเครื่องจริง

Virtualization สร้าง abstraction ของ CPU, memory, storage และ network ให้ guest เห็นเหมือนมีเครื่องของตน ทั้งที่ทรัพยากรจริงถูกแชร์และจัดสรรใหม่ได้ ประโยชน์คือ isolation, consolidation, portability และการจัดการ lifecycle

6Type 1 และ Type 2 Hypervisor

Hardware-assisted virtualization ช่วย trap privileged operations และจัด memory translation ผ่าน nested page tables ลดต้นทุนเมื่อเทียบกับ software emulation แต่ VM exit, virtual I/O และ TLB behavior ยังมีผลต่อ workload

7CPU Virtualization และ Scheduling

vCPU คือหน่วยประมวลผลที่ guest เห็น ไม่จำเป็นต้องผูก physical core ถาวร Hypervisor schedule vCPUs ลง cores หาก provision vCPU มากกว่าที่มีจริงเกิด oversubscription ซึ่งคุ้มเมื่อ workloads ไม่ peak พร้อมกัน แต่สร้าง steal time เมื่อแย่งกัน

• CPU-bound workload ต้องดู vCPU-to-core ratio และ ready/steal time
• NUMA VM ใหญ่ควรวาง vCPU กับ memory ให้สอดคล้อง topology
• Pinning ช่วย latency predictability แต่ลด flexibility ของ scheduler
• Noisy neighbor อาจแย่ง cache และ memory bandwidth แม้ CPU quota แยกแล้ว

8Memory Virtualization

Guest virtual address แปลเป็น guest physical แล้วต่อเป็น host physical การแปลสองชั้นเพิ่ม TLB pressure Huge pages ช่วยลดจำนวน entries แต่ใช้ memory หยาบขึ้นและ compaction ยาก

Ballooning และ memory overcommit ให้ host reclaim memory จาก VM แต่ถ้า working sets รวมเกิน RAM ระบบ swap และ performance อาจทรุดแบบหน้าผา การขาย memory มากกว่าที่มีจริงจึงพึ่งสมมติฐานว่าผู้เช่าไม่ใช้พร้อมกัน

9I/O Virtualization

Device emulation เข้าใจง่ายแต่ overhead สูง Paravirtual drivers เช่น virtio ให้ guest คุยกับ hypervisor ผ่าน interface ที่ออกแบบเพื่อ virtualization ส่วน device passthrough/SR-IOV ให้ VM เข้าถึง hardware ใกล้ตรงมากขึ้น

10Container ไม่ใช่ VM ขนาดเล็ก

Container แชร์ kernel ของ host แต่แยกมุมมองผ่าน namespaces และจำกัดทรัพยากรด้วย cgroups จึงเริ่มเร็วและใช้พื้นที่น้อยกว่า VM แต่ isolation boundary ต่างกันและไม่สามารถใช้ kernel คนละตระกูลโดยตรง

11Container Image และ Layer

Image ประกอบด้วย immutable filesystem layers หลาย images แชร์ layers ได้ ทำให้แจกจ่ายเร็วขึ้น แต่ layer เก่าที่มีไฟล์ใหญ่ยังอยู่แม้ลบใน layer ถัดไป จึงควรใช้ multi-stage build และจัดลำดับคำสั่งให้ cache มีประโยชน์

• Pin base image ด้วย version/digest เพื่อ reproducibility
• ลด packages ที่ไม่ใช้และสแกนช่องโหว่
• แยก build tools ออกจาก runtime image
• ไม่เก็บ secret ใน image history
• สร้าง Software Bill of Materials และลงนาม artifact

12Orchestration: Container หนึ่งตัวง่าย Cluster ของ Container ไม่ง่าย

Orchestrator รับ desired state เช่นต้องการ replicas 5 ตัว แล้ว schedule, restart และ rollout ให้ state จริงเข้าใกล้เป้าหมาย มันจัด lifecycle แต่ application ยังต้องพร้อมรับ termination, retry และ state migration

• Scheduler เลือก node ตาม request, constraint, affinity และ topology
• Controller เปรียบเทียบ desired กับ observed state
• Service abstraction ให้ stable discovery เหนือ pods ที่เปลี่ยน
• Rolling update เปลี่ยนเวอร์ชันทีละส่วน
• Persistent volume แยก lifecycle ข้อมูลจาก container

13Resource Request, Limit และ QoS

Request ใช้ในการ schedule ว่า node มี capacity พอหรือไม่ Limit กำหนดเพดาน หากตั้ง request ต่ำกว่าการใช้จริงมาก cluster จะ pack แน่นและเกิด contention หาก limit CPU ต่ำอาจถูก throttle ส่วน memory เกิน limit มักถูก kill แทนชะลอ

14Cloud Region, Availability Zone และ Fault Domain

Region เป็นพื้นที่ภูมิศาสตร์กว้าง Availability zones แยกโครงสร้างไฟและเครือข่ายระดับหนึ่ง แต่ไม่ได้แปลว่า failure อิสระทุกชนิด การวาง replicas หลาย zones ช่วยทน zone failure แต่เพิ่ม network latency และ cost

ต้องถามว่าระบบต้องทนอะไร: process crash, node loss, rack failure, zone outage หรือ region outage แต่ละระดับต้องใช้ topology และ data replication ต่างกัน การกระจายทุกอย่างข้าม region เพื่อ “ปลอดภัยที่สุด” อาจทำ latency และ consistency cost สูงเกินความต้องการ

15Elasticity ต่างจาก Scalability

Scalability คือระบบใช้ทรัพยากรเพิ่มแล้วรองรับงานเพิ่มได้ดีเพียงใด Elasticity คือความสามารถเพิ่มและลดทรัพยากรตามโหลดในเวลาที่เหมาะ ระบบอาจ scale ได้เมื่อเตรียมล่วงหน้า แต่ไม่ elastic หากเปิด node ใช้ 30 นาที

16Autoscaling หลายระดับ

• Horizontal เพิ่มจำนวน instances/pods
• Vertical ปรับ CPU/memory ต่อ instance
• Cluster autoscaling เพิ่ม nodes เมื่อ pods วางไม่ได้
• Queue-based scale consumers ตาม backlog หรือ queue age
• Predictive/scheduled เตรียม capacity ก่อนโหลดที่คาดไว้

การ autoscale ซ้อนหลายชั้นอาจตอบสนองช้า: application ขอ pods เพิ่ม แต่ cluster ต้องเปิด VM ก่อน จากนั้น image pull และ warm cache จึงพร้อม ต้องวัดเวลาทั้งสายและมี buffer capacity

17Serverless และ Function as a Service

Serverless ไม่ได้ไม่มี server แต่ผู้ใช้ไม่จัดการ server lifecycle โดยตรง Platform scale functions ตาม event และคิดราคาตามการใช้ เหมาะกับ burst, event processing และงานสั้น stateless แต่มีข้อจำกัดเรื่อง cold start, execution duration, concurrency, network และ state ภายนอก

18Cloud Storage: Block, File และ Object

การแยก compute จาก object storage ช่วย elasticity แต่ latency สูงกว่า local disk และ small-file requests แพง การเลือก storage ต้องดู access pattern, consistency, durability และ data transfer cost

19Cloud Network และ Egress Cost

Virtual network, subnet, routing, security group และ load balancer สร้าง topology เชิงตรรกะ แต่ packet ยังวิ่งผ่าน physical infrastructure Traffic ข้าม zone/region อาจมีทั้ง latency และค่าใช้จ่าย

Architecture ที่ compute ถูกแต่ส่งข้อมูลออกมากอาจแพงกว่าเดิม ต้องรวม egress, NAT gateway, load balancer processing และ inter-zone transfer ใน cost model Data gravity ทำให้ย้าย compute ไปใกล้ข้อมูลมักคุ้มกว่าย้ายข้อมูลจำนวนมาก

20Shared Responsibility และ Cloud Security

ผู้ให้บริการดูแลความปลอดภัย “ของ cloud” เช่น physical facilities และบางชั้น infrastructure ผู้ใช้ยังดูแล configuration, identity, data, network policy และ application การใช้ managed service ลดงานบางส่วนแต่ไม่ย้ายความรับผิดชอบทั้งหมด

• ใช้ least-privilege identity และ short-lived credentials
• แยก accounts/projects ตาม environment และ blast radius
• เข้ารหัสข้อมูลและจัดการ key lifecycle
• บันทึก audit trail และแจ้งเตือน configuration drift
• สำรองข้อมูลข้าม failure domain และทดลอง restore

21Infrastructure as Code

IaC ทำให้ infrastructure เป็น versioned desired state ตรวจ review, ทำซ้ำ และ rollback ได้ แต่ code ที่ผิดสามารถสร้างความเสียหายขนาดใหญ่ได้เร็ว จึงต้อง validate, plan และแบ่ง rollout

State ของ IaC ต้องปกป้องเพราะอาจมี identifiers และข้อมูลสำคัญ Environment ที่แก้ด้วยมือเกิด drift ทำให้ deployment ถัดไปคาดเดายาก หลัก GitOps ขยายแนวคิดโดยให้ repository เป็นแหล่ง desired state และ controller reconcile ระบบ

22Cloud Cost ไม่ได้เป็นเพียงราคาต่อชั่วโมง

23Spot/Preemptible Instance และ Fault-Tolerant Work

Instance ราคาต่ำอาจถูกเรียกคืน เหมาะกับงานแบ่งได้, checkpoint ได้ และ retry ได้ เช่น batch rendering หรือ distributed training ที่บันทึก state เป็นระยะ ไม่เหมาะกับ stateful singleton ที่ย้ายยาก

ต้นทุนจริงรวมงานที่สูญเมื่อ interruption หาก checkpoint ถี่เกิน overhead สูง หากห่างเกินเสีย work มาก ต้องเลือกระยะตาม checkpoint cost และ failure rate

24Accelerator ใน Cloud

GPU/TPU instances ให้ compute สูงแต่ราคาและ availability ต่างตาม region การใช้ multi-GPU ต้องดู interconnect ภายในเครื่องและ network ระหว่างเครื่อง Instance สองแบบที่มี GPU รุ่นเดียวกันอาจ performance ต่างเพราะ CPU, memory, PCIe และ NIC

Scheduler ต้องรวม resource shape เช่น GPU memory และ topology งาน inference อาจใช้ batching หรือ fractional sharing ส่วน training ต้องการ gang scheduling ให้ workers พร้อมกัน ไม่เช่นนั้นจ่ายค่าเครื่องบางส่วนที่รอ quorum ของงาน

25Resilience และ Disaster Recovery

Multi-zone ไม่แทน backup และ backup ที่ไม่เคย restore เป็นเพียงความหวัง การออกแบบ DR ต้องมี runbook, ownership, credential และการซ้อมภายใต้เวลาจริง

26กรณีศึกษา: ย้ายบริการ Batch ไป Cloud

1. Containerize application และแยก input/output ไป object storage
2. กำหนด resource request จาก profiling ไม่ใช่เดา
3. แบ่งงานเป็น idempotent chunks และ queue
4. ใช้ autoscaled workers และ spot instances สำหรับงาน retry ได้
5. บันทึก checkpoint/manifest เพื่อ resume
6. วัด cost per job, queue age และ failure recovery

การย้ายสำเร็จไม่ได้วัดจากโปรแกรมรันได้บน VM แต่ดูว่าระบบใช้ elasticity, failure model และ pricing ของ cloud อย่างเข้าใจหรือยัง

27แล็บและแบบฝึกที่แนะนำ

28VM, Container หรือ Serverless

คำตอบอาจผสมกัน Database อยู่ managed service, API อยู่ containers และ event บางชนิดใช้ functions สิ่งสำคัญคือให้แต่ละ model แก้ปัญหาที่มี ไม่ใช่ใช้ให้ครบทุกชนิด

29Lift-and-Shift กับ Re-Architecture

Lift-and-shift ย้าย VM เดิมขึ้น cloud เร็วและเปลี่ยน application น้อย แต่ยังคง topology เดิม Re-platform ปรับบางชิ้นเป็น managed service ส่วน re-architecture เปลี่ยน boundary และ data flow เพื่อใช้ elasticity กับ failure model ใหม่

30Noisy Neighbor และ Performance Interference

Tenant แย่ง cache, memory bandwidth, I/O queue และ network แม้ CPU quota ดูไม่ชนกัน Benchmark บน shared instance จึงมี variance การใช้ dedicated host, placement group หรือ isolation สูงขึ้นช่วย predictability แต่ราคาเพิ่ม

ควรวัด steal time, throttling, I/O latency และ network variance หาก workload ต้อง p99 ต่ำ การซื้อ headroom อาจคุ้มกว่าการ optimize codeบนทรัพยากรที่ไม่แน่นอน

31Energy และ Carbon Awareness

งาน batch ที่ deadline ยืดหยุ่นอาจย้ายไปเวลาหรือ region ที่พลังงานสะอาดกว่า การเพิ่ม utilization ลด idle cost ต่อผล แต่การย้ายข้อมูลข้าม region ก็ใช้พลังงานและเงิน ต้องวัด energy/carbon ต่อ job คู่กับเวลา คุณภาพ และ data residency

32Checklist ก่อนขึ้น Production

• Resource request/limit มาจากการวัดและมี headroom
• Readiness, draining และ shutdown path ทำงานจริง
• State อยู่ที่ใด Backup/restore ผ่านการทดสอบ
• Autoscaling รวม startup delay
• IAM, secrets, network policy และ image provenance ครบ
• Cost alert รวม egress และ request charges
• Zone/region failure ตรง RTO/RPO
• Logs, metrics, traces และ ownership พร้อม

คำถามก่อนเพิ่มบริการ Cloud อีกหนึ่งชนิด

บริการใหม่นี้ลดงานส่วนใด ใครเป็นเจ้าของเมื่อเกิด incident มีข้อจำกัดด้าน region, quota และ data portability อย่างไร และถ้าต้องย้ายออกจะนำข้อมูลกับ configuration กลับได้หรือไม่ Managed service ลดภาระการดูแลบางชั้น แต่เพิ่ม dependency ต่อ API, pricing และ lifecycle ของผู้ให้บริการ จึงควรเลือกจากต้นทุนรวม ไม่ใช่เพียงความเร็วในการเริ่มต้นครับ

33สรุปและขั้นตอนถัดไป

Virtualization และ cloud แยกทรัพยากรตรรกะออกจาก hardware ทำให้ provision, isolate และย้าย workload ง่ายขึ้น VM ให้ kernel isolation ที่แข็งกว่า Container แชร์ kernel และเริ่มเร็ว Orchestration จัด desired state ส่วน serverless ซ่อน lifecycle มากขึ้น แต่ไม่มีแบบใดลบ CPU, memory, network และ data movement ออกจากระบบ

บทถัดไปจะโฟกัสบริการข้อมูล ซึ่งมักเป็นส่วนที่ scale ยากที่สุด เพราะ state ไม่สามารถสร้างและทิ้งได้เหมือน stateless container เราต้องจัด partition, replication, consistency, cache และ storage semantics ให้รองรับทั้งความเร็วและความถูกต้องครับ