열심히 만들었지만 아무도 안쓰는 😭 서비스인, Crowddeer 는 쿠버네티스로 운영되는 서비스입니다. 크라우드디어를 오픈할 당시 환경구성을 VM 을 몇 개 받아서 CI/CD 를 구성할까도 고민해봤으나 노드 관리를 해줘야하는 불편함, 무중단 배포에대한 고민들 때문에 쿠버네티스를 이용하여 배포하기로 했습니다. 게다가 아무래도 회사에서 사용하고 있는 기술 스택이 쿠버네티스다 보니 이쪽이 좀 더 편하기도 했고요. scale 을 편리하게 해주고 문제 발생시 auto restart 도 알아서 해준다는 점도 너무 매력적이었습니다.
하지만 크라우드디어를 약 1년정도 운영해본 지금. 아무도 찾지 않는 빈 집을 운영하는데 생각보다 돈이 너무 많이 나간다는 생각이 들었습니다. 오늘은 서비스 운영을 할 때 발생할 수 있는 현실적인(비용) 고민에 대해 글을 작성해보려합니다. 그리고 사실 VKE 영입 글이기도 합니다.
개인 프로젝트에 쿠버네티스를 사용할 경우
쿠버네티스를 이용하여 서비스를 띄우겠다 마음먹으셨다면, 사용할만한 솔루션은 크게 EKS (아마존), GKE (구글) 정도일겁니다. 네이버에서 운영하는 NKS 도 있는 것으로 아는데, EKS 보다도 비쌌거나 비슷한 가격이었던 것같아서 굳이 NKS 를 써야할 이유가 뭐지?? 라는 생각이 들었던 것 같습니다.
그럼 일단 쿠버네티스로 서비스를 구성하겠다 칩시다. 그렇다면 보통 아래와 같은 구성으로 노드를 배치합니다. (일반 노드를 2대로 잡은 이유는 다운타임을 없애기 위한 최소한의 개수이기 때문에)
minikube: 마스터 = 일반 = ingress
테스트용 클러스터: 마스터 노드 1대, 일반 노드 2대, ingress 노드 1대
개발용 클러스터: 마스터 노드 3대, 일반 노드 2대, ingress 노드 1대
배포용 클러스터: 마스터 노드 5대, 일반 노드 2대, ingress 노드 n대
물론 개인 개발자들이 프로덕션 클러스터를 운영하기 위해 마스터 노드에 5대를 투자한다는 것은 어지간히 큰 서비스가 아니고서야 미친 짓일 겁니다. 진짜 보수적으로 잡아 마스터 노드의 스펙을 1 cpu / 2gb mem 을 사용한다 쳐도, 노드 한대당 월 10달러씩은 깨질테니까요. 그럼 클러스터 관리에 사용되는 마스터 노드에만 월 50달러씩 나가겠네요.
결국 개인 프로젝트를 하는 개발자 입장에서 서비스를 배포하려면 일반적인 개발용 클러스터 스펙에 맞춰 마스터 노드를 3대는 사용해야 한다는 건데, 이것도 정말 호사스러운 사치가 아닐 수 없습니다. 다시 말하지만 마스터 노드는 클러스터를 관리하는 용도일 뿐이기 때문입니다. 그렇다고 마스터 노드를 1대로 유지하자니? 마스터 노드가 SPOF 가 될 수도 있습니다. "나중에 서비스가 확장하면 마스터 노드를 증설해야지"라는 생각으로 접근하기에는, 이미 생성된 클러스터 환경에 마스터 노드 증설은 어려운 것으로 알고 있고요. 그렇게 되면 나중에 서비스 확장을 할 때 클러스터를 새로 파줘야할 텐데 여간 귀찮지 않을 수 없습니다.
EKS, GKE 어떤 서비스를 택하든 k8s 클러스터를 직접 관리하겠다면 마스터 노드로 발생하는 유지비를 생각하지 않을 수 없습니다. 그러던 와중에, GKE 의 autopilot 모드라는 것이 있다는 것을 발견합니다. autopilot 모드는 모든 k8s 노드 관리를 구글에 맡기고 사용자는 pod 에만 집중하여 사용할 수 있도록 하는 서비스입니다. 사용자별로 autopilot 모드 1대에는 마스터 노드로 발생하는 관리비용을 면제해주기 때문에 노드 관리에 부담을 느끼고 있고, 비용 부담도 느끼고 있다면 꽤나 괜찮은 선택지이지요.
사실 계산기 두드려보면 쿠버네티스를 이용하여 서비스를 배포하겠다는 개인 개발자 입장에서 제일 저렴했던 것은 GKE 의 autopilot 모드입니다. 혹시나 서비스가 잘됬을 때 확장하기도 용이하고요. (우리 모두 서비스가 잘되는 것을 생각하고 개발하잖아요?)
그렇게 서비스를 1년정도 운영해보니...
대략 월별 8~9만원 정도 나왔던 것 같습니다. vultr 에 띄워서 운영중인 mongo 서버 + github container registry 비용까지 합산하면 crowddeer 를 운영하기위해 월 10만원 정도는 사용하고 있었던 것 같네요.
처음에는 안일하게 "취미 생활하는데 10만원정도야." 라는 생각이었습니다. 그런데, 1년이 지나 회고하니 이 금액이 여간 아까운 금액이 아닐 수 없었습니다. 서비스가 어느정도 굴러가고 있기라도 하면 모르겠는데, pod 는 항상 idle 상태인데 이 정도 금액이 발생하고 있으니까요. 😭
심지어 k8s 에 띄운 pod 의 스펙이 좋았던 것도 아닙니다. FE pod 는 0.5cpu / 0.5 gb mem, BE pod 는 1 cpu / 1.5 gb mem 이었고, 이중화 구성도 아니었습니다. 결과적으로 1.5 cpu / 2 gb mem 노드를 운영하는데 대략 월 10만원 정도가 깨지고 있었던 것입니다. 이 정도 스펙을 VM 으로 띄운다면 월 2만원정도일 텐데 말이죠.
이럴거면 쿠버네티스를 직접 설치해서 운영할까도 잠깐 고민했었습니다. 그런데 애초에 노드 관리 같은걸 하기 싫어서 k8s 를 선택한 것인데, 이렇게되면 배보다 배꼽이 클게 너무나 명확했고요. 결국 마스터 노드까지 고려해서 직접 설치해서 써봤자 얼추 비슷하게 10만원 정도나올 것 같더라구요. 그러한 탓에 마땅한 대안도 없는 상태였습니다.
이 와중에 도메인 만료 기간도 1년을 거의 다 채워가고 있었습니다. 결국 이번달에 결정을 내려야했습니다. 도메인 만료 날짜에 맞춰 서비스를 내리거나, 일반 VM 에 서비스를 다시 띄우거나.
이런 저런 고민끝에 그래도 개발자인데 본인이 직접 개발한 서비스 하나 정도는 갖고 있어야지, 라는 생각이 들어서 일반 vm 에 서비스를 다시 띄우는 쪽으로 생각을 굳혔습니다. 계획은 github action 을 이용하여 CI/CD 환경을 구성하는 것이었는데, github action 도 잠깐 접해봤던 경험으론 상당히 괜찮았었거든요.
그렇게 노드를 생성하러 vultr 에 들어갔는데.... (참고: vm 사업을 하는 클라우드 솔루션중 vultr 가 제일 싼 것 같습니다. UI 도 제일 직관적이고요.)
세상에 어느샌가부터 vultr 에서도 kubernetes engine 을 지원하고 있었습니다. 심지어 가격도 너무 착합니다. 게다가 앞서 주구장창 이야기했던 k8s 에 서비스를 띄울 때 발생할 수 있는 마스터 노드로인한 금액을 요구하질 않습니다. 👍 사용자는 오직 worker 노드에서 발생하는 금액만 지불하면 됩니다. vke 를 통해 crowddeer 의 스펙에 맞춰 노드를 발급받는다면?
월 20달러! 심지어 노드 한대당 가격도 비싸게 요구하는 것도 아니고 그냥 정가를 받고 있는 것 같습니다.
물론 이 금액이 ingress 노드 비용까지 포함한 것은 아닙니다. ingress 노드의 금액까지 포함하여 계산하면 대략 월 30달러인데, 다른 쿠버네티스 엔진 솔루션에 비하면 선녀이지 않나요? 그리고 GKE 에서도 ingress 노드 비용이 사실 노골적으로 드러나지 않았을 뿐이지, HTTP load balancing 이라는 명목으로 계속 발생하고 있었습니다.
그렇게 어제 보자마자 느낌이 너무 좋아서 하루동안 GKE 에서 굴러가던 서비스를 VKE 로 옮겼습니다. 오래 써본 것은 아니지만 확신에 차서 말할 수 있습니다. 쿠버네티스 엔진을 고민하고 계신분들께 정말 VKE 강력 추천드립니다. 단점이라면 seoul region 을 지원하지 않는다는 점 정도네요.
GKE vs VKE
1. local 에 클러스터를 등록하는 방식
gke 에서는 최초에 kubectl 로 클러스터에 접속하기위해 gcloud 라는 cli 도구를 이용해야 했던 것으로 압니다. 개인적으로 클라우드를 이용하기 위해 사용자에게 독자적인 cli 도구를 이용하도록 하는 방식은 굉장히 별로고 직관적이지 못하다고 생각합니다. 커맨드를 입력하니 클러스터가 등록 되긴 하는데 너무 블랙박스라고 할까요? 이 명령어를 입력해서 왜 클러스터가 등록됬고, 나중에 문제가 생기면 어떻게 수정해야하는지 감이 오질 않습니다. 이에 반해 vke 는 클러스터 등록을 위해 kubernetes 에서 공식적으로 가이드하는 방식을 그대로 따르고 있습니다.(https://kubernetes.io/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
혹시 모르시는 분들이 계실까봐 여기에 잠깐 서술하자면
vultr kubernetes manage 페이지에서 설정을 다운 받습니다.
파일을 ~/.kube 디렉토리 아래로 옮깁니다. (ex. ~/.kube/crowddeer.yaml)
쉘 설정에 들어가서 환경변수 확장을 해줍니다. (iterm 을 이용하고 계시다면 ~/.zshrc 파일에 설정해주시면 됩니다.) # Kubernetes profile export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config:$HOME/.kube/crowddeer.yaml
cli 에서 `kubectl config use-context {CONTEXT_NAME}` 를 입력하여 클러스터를 이동합니다. context name 은 다운받은 파일의 contexts[0].name 에서 확인하실 수 있습니다. ex. $ kubectl config use-contextvke-aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
2. SSL 인증서 발급
GKE 의 SSL 인증서는 ManagedCertificate 을 이용하여 ingress 노드에 등록해줍니다. 가이드는 이쪽을 이용하면 되는데, 개인적으로 GKE 를 구성하면서 이 부분은 정말 편리했던 것 같습니다. VKE 에서는 SSL 인증서 등록을 따로 해줘야겠지? 라는 생각이 들어서 무료 SSL 인증 기관을 찾던 중, Vultr 가이드에서 이 글을 발견했습니다. cert-manager 와 letsencrypt 를 이용하여 ssl 인증서를 발급하는 방식인 것 같은데, 이것도 상당히 편리하고 좋았습니다. 그리고 오히려 이 방식이 GKE 와 달리 동작 방식이 더 투명해서 좋았던 것 같습니다. 글을 쓰면서 느끼는 건데 개인적으로 GKE 를 사용하면서 너무 모든 것이 블랙박스였다는 점이 불만이었나봅니다.
결국 GKE 가 제공하는 SSL 인증서 방식 말고도 VKE 를 이용해도 SSL 인증서 발급을 자동화 할 수 있습니다. VKE 인증서 발급 과정은 위 글에서 너무 상세하고 잘 설명되어있는 관계로 패스하겠습니다.
기타
GKE, VKE 관계없이 GKE 를 사용하면서도 했던 작업들인데 잊어버리고 삽질했던 것이 몇개 있어 히스토리 차원에서 적습니다.
github container registry 를 사용할 경우 k8s 가 ghcr 에 접근하기 위한 인증을 하는 방법
3. deployment spec 의 image pull secret 에 위에 등록한 이름의 secret 을 입력해줍니다.
spec:
imagePullSecrets:
- name: ghcr-pat
GKE 환경 구성시 pod 가 뜨지 않을 경우
이건 과거에 GKE 를 구성하면서 했던 삽질중 하나인데, GKE 에서는 자체적인 health_check 엔드포인트를 하나 더 등록하여 관리하도록 하고 있습니다. 만약 readinessProbe 나 livenessProbe 가 절대 실패할 수 없는데도 왜안뜨지? 싶다면 프로젝트의 상태 점검 페이지에서 별도로 등록된 헬스 체크로직이 readinessProbe 나 livenessProbe 와 다른지 확인해주세요. GKE 의 서비스 헬스 체크로직이 실패한다면 ingress 는 service 가 broken 된 것으로 간주합니다.
글을 쓰다보니 내용 전달도 아니고, 추천 글도 아닌, 너무 두서없는 글이 된 것 같습니다. 정리하자면 그냥 vultr 클라우드를 강력히 추천하는 글입니다. 국내에는 vultr 사용자가 많이 없는 듯 보여 아쉽습니다. 이렇게 훌륭하고 합리적인 솔루션이 있는데, 꼭 aws 나 gcp 만 고려하지 마시고 vultr 도 사용을 고민해보시길 바랍니다.
