Azure Kubernetes Service

컨테이너를 하나둘 실행하는 건 어렵지 않습니다. 하지만 서비스가 10개, 20개로 늘어나면 문제가 달라집니다. 어떤 컨테이너를 어느 서버에 배치할지, 서버가 죽으면 컨테이너를 어디로 옮길지, 트래픽이 몰리면 몇 개를 더 띄울지를 수동으로 결정하면 운영이 곧 병목이 됩니다. 배포마다 다운타임 없이 새 버전으로 교체하고, 문제가 생기면 이전 버전으로 돌려야 하는데, 컨테이너 수가 많아질수록 이 조율 작업의 복잡도는 선형이 아니라 기하급수적으로 올라갑니다. 여기에 Kubernetes를 직접 설치하면 컨트롤 플레인 자체의 가용성, etcd 백업, 인증서 갱신까지 관리해야 해서 '컨테이너 운영을 편하게 하려고 도입한 도구'가 또 하나의 운영 부담이 됩니다.

컨테이너는 환경 차이 문제를 해결했지만, 컨테이너가 많아지면서 '이걸 누가 관리하느냐'라는 새로운 문제가 운영 현장에서 커졌습니다. 초기에는 Docker Compose나 수동 스크립트로 배포했지만, 서비스 수가 늘고 롤링 배포, 자동 복구, 로드 밸런싱을 요구하면 곧 한계에 부딪혔습니다. Kubernetes가 이 오케스트레이션 문제의 사실상 표준이 됐지만, Kubernetes 자체를 설치하고 운영하는 비용이 높았습니다. 컨트롤 플레인의 고가용성 확보, etcd 클러스터 관리, 인증서 로테이션, 버전 업그레이드 — 이 모든 작업이 본래 목적인 '애플리케이션 운영'과 무관한 인프라 관리에 해당했습니다. AKS는 이 관리 부담을 Azure가 대신 떠안으면서, 팀이 워크로드 배포와 스케일링이라는 본래 목적에 집중할 수 있게 한 서비스입니다.

AKS는 Kubernetes 클러스터를 컨트롤 플레인과 노드 풀 두 층으로 나눕니다. 컨트롤 플레인에는 API Server, Scheduler, etcd가 있고 Azure가 이 부분을 완전히 관리합니다. 사용자는 kubectl이나 CI/CD를 통해 API Server에 배포 요청을 보내고, Scheduler가 어떤 노드에 Pod를 배치할지 결정합니다. 노드 풀은 실제 컨테이너가 실행되는 VM 그룹으로, 워크로드 성격에 따라 CPU 집약적 풀, 메모리 집약적 풀, GPU 풀을 분리해 구성할 수 있습니다. 트래픽이 증가하면 HPA(Horizontal Pod Autoscaler)가 Pod 수를 늘리고, Pod가 더 이상 기존 노드에 배치되지 않으면 클러스터 오토스케일러가 노드 자체를 추가합니다. 배포 시에는 롤링 업데이트로 Pod를 순차 교체하므로 다운타임 없이 새 버전을 올릴 수 있고, 문제가 생기면 이전 버전으로 롤백합니다.

AKS와 App Service는 둘 다 Azure에서 애플리케이션을 실행하지만, 제어 수준과 운영 복잡도가 다릅니다. App Service는 코드나 컨테이너 이미지를 올리면 플랫폼이 라우팅, 스케일링, TLS를 대부분 처리하는 PaaS로, 운영 오버헤드가 낮은 대신 인프라 수준의 세밀한 제어가 제한됩니다. AKS는 네트워크 정책, 사이드카 패턴, 커스텀 스케줄링, 노드 풀 분리 같은 인프라 수준 제어가 가능하지만, Kubernetes 자체의 학습 곡선과 운영 복잡도를 감수해야 합니다. 서비스가 소수이고 표준적인 웹 앱이라면 App Service로 충분하고, 수십 개 마이크로서비스를 독립 배포·스케일링하거나 인프라 레벨에서 세밀하게 제어해야 한다면 AKS가 맞습니다.

마이크로서비스 아키텍처를 운영하면서 서비스별로 독립적인 배포 주기, 스케일링 정책, 리소스 제한이 필요한 팀에서 AKS가 자연스럽게 등장합니다. CI/CD 파이프라인에서 컨테이너 이미지를 빌드하고 클러스터에 자동 배포하는 흐름이 잡히면 배포 속도와 안정성이 동시에 올라갑니다. GPU가 필요한 ML 워크로드와 일반 웹 서비스를 같은 클러스터 안에서 노드 풀로 분리해 운영하는 것도 가능합니다. 반면 서비스가 한두 개이고 표준 웹 앱 패턴이라면 Kubernetes의 학습 곡선과 운영 비용이 실제 이득보다 클 수 있습니다. 클러스터 관리, 네트워크 정책, RBAC 설정에 투자할 팀 역량이 있는지도 도입 판단의 중요한 기준입니다.

다음에 볼 개념

함께 보면 좋은 개념