쿠버네티스가 정말 우리 서비스에 필요할까?

쿠버네티스라는 환상

새로운 기술을 배우거나 도입할 때, 우리는 종종 그 기술이 가진 거대한 가능성에 매료됩니다. 쿠버네티스는 구글 같은 거대 IT 기업이 전 세계적인 규모의 서비스를 안정적으로 운영하기 위해 만든 복잡하고 강력한 도구입니다.

많은 개발팀과 비개발자들이 "쿠버네티스를 쓰면 무중단 배포도 자동으로 되고, 트래픽이 몰려도 알아서 서버가 늘어난대!"라는 환상을 가지고 시스템을 전환하려 합니다. 하지만 그 이면에는 가파른 학습 곡선과 막대한 유지보수 비용이 숨어 있습니다.

오버엔지니어링의 덫

오버엔지니어링(Over-engineering)이란 해결하려는 문제보다 너무 크고 복잡한 도구나 설계를 사용하는 것을 말합니다.

하루에 수십 명의 사용자가 방문하는 간단한 사내 게시판이나, 트래픽 변화가 거의 없는 단순한 API 서버에 쿠버네티스를 도입하는 것은 마치 동네 마트에 장을 보러 가는데 덤프트럭을 몰고 가는 것과 같습니다. 트럭을 운전하는 법을 배워야 하고, 주차 공간도 찾아야 하며, 기름값도 훨씬 많이 듭니다.

언제 쿠버네티스가 필요할까?

그렇다면 쿠버네티스는 언제 도입해야 할까요? 모든 기술은 특정 문제 상황을 해결하기 위해 존재합니다. 쿠버네티스 역시 예외가 아닙니다.

다음과 같은 상황에 직면했다면, 쿠버네티스 도입을 진지하게 고려해 볼 수 있습니다.

수많은 서버의 관리 한계

서비스가 성장하여 여러 대의 서버(Node)를 운영하게 되면, 개발자가 일일이 서버에 접속하여 컨테이너를 띄우고 상태를 모니터링하는 것이 불가능해집니다. 어떤 서버는 여유롭고 어떤 서버는 과부하가 걸려도, 이를 수동으로 조절하기는 매우 어렵습니다.

이때 쿠버네티스는 여러 대의 서버를 하나처럼 묶어서, 비어있는 서버에 알아서 컨테이너를 배치해 주는 역할을 합니다.

복잡한 마이크로서비스 아키텍처 (MSA)

하나의 거대한 프로그램 대신, 여러 개의 작은 서비스로 쪼개어 개발하는 마이크로서비스 아키텍처에서는 수십, 수백 개의 다양한 컨테이너들이 서로 통신해야 합니다.

결제 서비스, 회원 서비스, 장바구니 서비스가 각기 다른 개수로 실행되고 있을 때, 이들 간의 네트워크 연결을 수동으로 관리하는 것은 지옥에 가깝습니다. 쿠버네티스는 이런 복잡한 서비스 간의 통신과 서비스 디스커버리(Service Discovery)를 체계적으로 관리해 줍니다.

무작정 도입하기 전 체크리스트

쿠버네티스의 강력함 뒤에는 그것을 유지하고 관리하기 위한 전담 인력과 비용이 필요하다는 사실을 잊지 말아야 합니다.

만약 위 질문들에 자신 있게 "예"라고 대답하기 어렵다면, 아직은 더 단순하고 직관적인 도커 기반의 배포나 클라우드 제공자가 관리해 주는 서버리스(Serverless) 서비스를 사용하는 것이 현명한 선택입니다.