Azure Kubernetes Service

컨테이너를 서너 개 띄우는 것은 쉽습니다. 문제는 서비스가 수십 개로 늘어날 때입니다. 어떤 컨테이너를 어느 서버에 올릴지, 서버 한 대가 죽으면 거기서 돌던 컨테이너를 어디로 옮길지, 트래픽이 몰리면 몇 개를 더 띄울지, 이 결정들을 사람이 수동으로 내리기 시작하면 배포 하나에 담당자가 붙어 있어야 합니다. 거기에 Kubernetes를 직접 설치하면 컨트롤 플레인 고가용성, etcd 백업, 인증서 갱신, 버전 업그레이드가 새로운 운영 과제로 쌓입니다. 컨테이너 운영을 단순화하려고 도입한 도구 자체가 또 하나의 운영 부담이 되는 상황입니다.

컨테이너가 환경 차이 문제를 해결하면서, 이번에는 '수십 개의 컨테이너를 누가 어떻게 관리하느냐'는 문제가 현장에서 커졌습니다. 처음에는 Docker Compose나 간단한 배포 스크립트로 버텼지만, 롤링 배포, 자동 복구, 서비스 간 로드 밸런싱이 요구되는 순간 한계가 드러났습니다. Kubernetes가 이 오케스트레이션 문제의 표준으로 자리잡았지만, Kubernetes 자체를 설치하고 운영하는 비용이 만만치 않았습니다. 컨트롤 플레인을 고가용으로 구성하고, etcd를 백업하고, 인증서를 주기적으로 갱신하고, 버전을 업그레이드하는 작업들은 모두 애플리케이션 운영과 무관한 인프라 관리였습니다. AKS는 그 관리 부담을 Azure가 대신 맡으면서, 팀이 워크로드 배포와 스케일링에 집중할 수 있는 환경을 제공합니다.

AKS는 항공사 운항 시스템과 비슷하게 볼 수 있습니다. 관제탑(컨트롤 플레인)이 어떤 항공기(Pod)를 어느 게이트(노드)에 배치할지 결정하고, 승객은 그 결정 과정을 몰라도 됩니다. 구체적으로는 두 층으로 나뉩니다. 컨트롤 플레인에는 API Server, Scheduler, etcd가 있고 Azure가 이 부분을 완전히 관리합니다. 사용자는 kubectl이나 CI/CD 파이프라인에서 API Server에 배포 명세를 보내고, Scheduler가 어느 노드에 Pod를 올릴지 결정합니다. 노드 풀은 실제 컨테이너가 실행되는 VM 그룹으로, CPU 집약 워크로드, 메모리 집약 워크로드, GPU 워크로드를 별도 풀로 분리해 구성할 수 있습니다. 스케일링도 두 단계로 자동화됩니다. 트래픽이 늘면 HPA(Horizontal Pod Autoscaler)가 Pod 수를 늘리고, Pod가 기존 노드에 더 이상 배치될 수 없으면 클러스터 오토스케일러가 노드 자체를 추가합니다. 배포 시에는 롤링 업데이트로 Pod를 순차 교체하므로 다운타임 없이 새 버전을 올릴 수 있고, 문제가 생기면 이전 상태로 롤백합니다.

컨테이너 기반 애플리케이션을 Azure에서 실행한다는 점에서 AKS와 관리형 웹 앱 호스팅 서비스는 비슷해 보입니다. 둘 다 컨테이너 이미지를 배포하고, 스케일링을 지원하고, Azure의 다른 서비스와 연결됩니다. 차이는 제어 수준과 그에 따른 책임입니다. 관리형 플랫폼은 라우팅, TLS, 스케일링을 Azure가 처리하는 대신 네트워크 정책, 사이드카 패턴, 커스텀 스케줄링 같은 인프라 수준 설정은 손댈 수 없습니다. AKS는 그 설정을 직접 다룰 수 있지만, Kubernetes 자체의 학습 곡선과 클러스터 운영 복잡도를 감수해야 합니다. 서비스 수가 적고 표준 웹 앱 패턴이라면 관리형 플랫폼이 더 빠른 선택입니다. 수십 개 마이크로서비스를 독립 배포·스케일링하거나, 서비스 메시나 커스텀 어드미션 웹훅처럼 인프라 레벨 제어가 필요하다면 AKS가 맞습니다. AKS도 완전 자유는 아닙니다. 컨트롤 플레인은 Azure가 관리하므로, etcd에 직접 접근하거나 Kubernetes API Server 설정을 바꾸는 것은 지원되지 않습니다.

여러 팀이 독립적으로 서비스를 개발·배포하는 조직에서 AKS가 등장합니다. 각 팀이 자신의 컨테이너 이미지를 CI/CD 파이프라인에서 빌드해 클러스터에 올리고, 네임스페이스와 RBAC으로 팀 간 접근을 분리하는 구성이 대표적입니다. 어떤 신호가 보이면 AKS를 고려하게 됩니다. 서비스가 10개를 넘어가면서 배포 주기가 서비스마다 달라지거나, 특정 서비스만 수평 확장해야 하거나, GPU 풀과 일반 풀을 같은 클러스터 안에서 분리 운영해야 할 때입니다. 반면 팀 규모가 작고 Kubernetes 운영 경험이 없는 상태에서 서비스가 한두 개라면, 클러스터 관리와 네트워크 정책 설정에 드는 시간이 실제 이득보다 클 수 있습니다.