험난한 Kubernetes 전환기 (4) - 못다 한 이야기들
지난 몇 개월간 Azure Kubernetes Service, Amazon EKS, 그리고 기존 서비스 전환까지 진행하며 주요 서비스를 Kubernetes 환경으로 이전했습니다.
지금도 계속 다른 작업을 진행하고 있지만, 지금까지 작업을 하면서 느꼈던 내용과 차마 이야기하지 못했던 내용들을 돌아보려고 합니다.
K8s로 전환하고 얻은 것
기존 환경이 Docker Compose 기반이었고 이로 인한 구조적 한계가 많았기 때문에,
단순히 K8s로 전환하는 것만으로도 많은 개선점이 있었습니다.
기본적인 안정성
확실히 안정성이나 유지보수 측면에서는 발전했다고 생각합니다.
기존 Docker Compose 환경은 컨테이너에 문제가 생겼을 때 복구도 어려웠고, 네트워크 순단 등 여러 문제가 있었습니다.
K8s에서 기본 기능으로 Pod 재시작이나 Graceful shutdown 등을 지원하기 때문에, 기존 환경에서 복잡하게 구현하거나 포기했던 부분들이 간단하게 구현되었습니다.
로그를 보기도 편했고, 환경이나 리소스를 바꾸어야 할 때도 다운타임을 최소화하면서 진행할 수 있었습니다.
Auto-scaling
K8s를 전환하면서 가장 많이 신경 썼던 부분이 바로 Auto-scaling이었던 것 같네요.
Azure에서는 Cluster Autoscaler를 사용했고, EKS에서는 Karpenter를 도입했습니다.
Docker Compose 환경에서는 Scaling 작업을 수동으로 해야 했지만 K8s는 그렇지 않아도 되었고, 트래픽 상황에 따라 리소스 조정을 유연하게 할 수 있게 되었습니다.
B2B 서비스의 특성상 특정 시간대에 트래픽이 몰리거나, 반대로 특정 시간대에 사용자가 적어 리소스 낭비가 생길 때도 있기 때문에 더더욱 큰 효 과가 나온다고 생각합니다.
배포 프로세스의 개선
Argo CD와 Helm을 활용한 GitOps 방식으로 배포 프로세스를 표준화하고 있습니다.
아직 진행 중이지만 각 서비스마다 제각각이었던 배포 방식을 통일하면서 유지보수에 들어가는 리소스를 줄이고 있습니다.
수많은 오픈소스 도구
K8s도 이제는 10년이 된 오픈소스 프로젝트이기 때문에 수많은 오픈소스 도구들이 있습니다.
Argo CD, ExternalDNS 등 수많은 도구들이 리소스 관리 면에서 편의성을 높여주고, 지금도 계속 새로운 도구들이 나오거나 안정화되고 있습니다.
실제로 몇 가지 도구를 도입하여 효과를 직접적으로 느끼기도 했고, 앞으로도 이러한 도구를 활용하면서 더 나은 환경을 만들어 갈 수 있게 되었습니다.
K8s는 모든 것을 해결해 주지 않는다
Kubernetes는 분명히 좋은 기술이 맞습니다.
하지만 Kubernetes로 전환한다고 해서 모든 문제가 해결되는 것은 아니었습니다.
애플리케이션 레벨의 문제를 DevOps 기술만으로는 근본적인 해결이 어렵다는 것을 진행하면서 여러 번 느꼈습니다.
애플리케이션의 한계
현재 주력 서비스의 경우, MSA 구조와는 거리가 먼 거대한 단일 이미지와 웹소켓이 문제가 되었습니다.
단일 이미지가 매우 무겁기 때문에 Image Pull부터 시동, 종료까지 모두 오래 걸렸고,
팀에서 HPA와 PreStop 이벤트, Graceful shutdown 등 수많은 최적화 작업을 했지만 네트워크 순단 문제를 완전히 해결할 수 없었습니다.
이를 해결하기 위해서는 Application 자체를 가볍게 만들어야 합니다.
웹소켓의 경우 Pod가 종료될 때 연결이 끊어지기 때문에 Auto-scaling 과정에서 Pod를 늘리면 오히려 502 에러가 늘어나는 문제가 있었습니다.
웹소켓을 분리하거나 다른 대안을 찾는 것도 고려해야 하지만, 회사 사정상 어려운 부분이 많았습니다.
그 외에도 성능상의 이유로 Supervisor를 통한 멀티 프로세스 구조를 유지해야 했는데, 이는 Kubernetes의 Single Process 원칙과는 맞지 않는 부분이었고 이로 인해 Pod 1개당 소비하는 리소스가 과도하게 책정되었습니다.
이 외에도 기술 부채로 인해 원하는 구조를 적용할 수 없는 경우가 많았습니다.
Kubernetes 전환은 회사 전체가 하는 것
위에서 이야기한 것처럼 Kubernetes 도입을 힘들게 하는 요소는 Kubernetes 그 자체가 아닌 경우도 많습니다. 따라서 팀뿐만 아니라 회사 전체가 Kubernetes를 도입하기 위한 준비가 필요합니다.
하지만 Kubernetes만 도입하면 모든 게 해결된다고 생각하고, 모든 문제를 Kubernetes와 DevOps 팀에게 떠넘기는 경우도 정말 많은 것 같습니다. 여타 다른 기술처럼 Kubernetes도 Silver Bullet이 될 수는 없는데 말이죠.
제가 가장 중요하게 생각하는 것은 다음과 같습니다.
- Kubernetes 친화적인 구조와 도구를 적극 권장하고 활용할 수 있어야 합니다.
- 꼭 이상적인 MSA가 아니더라도, 분리가 필요한 서비스는 과감히 분리하는 등 구조 개선이 이루어져야 K8s를 100% 활용할 수 있습니다.
- 이 모든 과정에서, 조직 전체가 Kubernetes의 핵심 가치에 공감하고 참여하며, 서로 도와야 합니다.
실제로 K8s를 도입하면서 많은 경험을 쌓았고 개인적으로 성장도 많이 했다고 생각하지만, 그만큼 힘든 점도 많았습니다. 위에서 말했듯이 기술 부채로 인해 표준적인 구조를 포기해야 할 때도 있었고, 새로운 방안을 제시했지만 적용할 수 없었던 경우도 있었 습니다. 이 글에 모두 적을 수는 없지만, 과도기라고 생각하고 이후에는 더 나은 환경이 되었으면 좋겠네요.
마치며
Kubernetes 전환을 통해 확실히 인프라의 안정성과 효율성은 크게 향상되었습니다.
Auto-scaling, 무중단 배포, 리소스 활용률 개선 등 목표했던 것들을 많이 달성했다고 생각합니다.
하지만 DevOps 기술만으로는 해결할 수 없는 애플리케이션 레벨의 문제들도 명확히 드러났습니다.
이러한 부분에서는 다른 부서와의 협업과 지원도 필수적이라고 생각합니다. 그 과정에서 많은 아쉬움이 있었습니다.
1년 전에 어떤 개발자 커뮤니티에서 다른 개발자 분이 Kubernetes 전환에 대한 질문을 올렸는데,
그때 다른 회사의 DevOps 팀 리더 분이 이런 역질문을 한 적이 있습니다.
"그 조직이 얼마나 준비가 되어 있나요??"
그 당시에는 역시 날카롭다고 생각한 정도였지만, 직접 경험해 보고 곱씹어 볼수록 맞는 말이라고 느낍니다. 물론 이러한 것들을 조정하는 것도 DevOps 엔지니어의 역할이기 때문에 다른 의미로 어렵지 않나 하는 생각도 조금 드네요.
그래도 처음을 생각해 보면 많은 것이 나아졌다고 느낍니다.
당분간은 주어진 자리에서 계속 제가 할 수 있는 일을 해 보려고 합니다.