Compute (Server, Container, and Auto Scaling)
Domain 2 - Compute (Server, Container, and Auto Scaling). Expect questions on choosing VM versus container versus serverless, sizing, bootstrapping, and how scaling policies actually behave.
Server essentials
- A Server is a VM in one zone: image (OS), spec family (Standard, High-CPU, High-Memory, GPU), Block Storage, ACG, and optionally a Public IP - the IP is a separate resource.
- Init Script or User Data runs at first boot: install agents, pull packages, apply configuration. Never bake secrets into an image.
- Changing spec requires stop and start, so plan downtime; Block Storage can be expanded and snapshotted.
- Bare Metal Server for licensing or performance needs; GPU Server for training and inference.
Containers
NKS (NAVER Kubernetes Service) is managed Kubernetes: managed control plane, node pools with autoscaling, integration with Load Balancer, Block and NAS persistent volumes, and Container Registry for images.
Auto Scaling
- Launch Configuration is the template: image, spec, ACG, init script.
- Auto Scaling Group holds minimum, maximum and desired capacity and spans zones.
- Policies: scheduled (known peaks), manual capacity change, and metric-driven scale-out and scale-in triggered by Cloud Insight alarms.
- Scale-in needs a cooldown and a Load Balancer deregistration delay to drain connections.
Worked example
An API tier scales on load. Reasoning: Launch Configuration with the app image and an ACG opening 8080 only; group minimum 2 (one per zone), maximum 8; scale out one server when average CPU exceeds 60% for 5 minutes; scale in when it stays below 30% for 15 minutes.
Traps
- Editing a Launch Configuration and expecting running servers to change.
- Setting a minimum capacity that lives in one zone only.
- Believing a stopped server costs nothing - disk and Public IP still bill.
- Assuming scale-in drains traffic without a deregistration delay.