[MSA] Kubernetes vs. Spring Cloud + Netflix Eureka

개요

마이크로 서비스 아키텍처로 서비스의 구조를 가져갈 때 많이 선택하는 두 가지 기술 스택 선택지가 있다. 가장 대중적이자 많이 선택하는 것이 쿠버네티스이다. 하지만 Spirng을 사용하는 서비스라는 조건이 있다면 Spring Cloud도 좋은 선택지가 될 수 있다고 한다. 일반적으로는 언어나 프레임워크에 종속되지 않고 확장성도 넓은 k8s가 유리한 경우가 많겠지만 "Spring을 사용한다" 라는 조건 하에 두 기술 스택을 비교해보도록 한다.

 

Kubernetes

마이크로 서비스 구조를 구현할 때 가장 많이 사용하는 기술 스택으로 컨테이너 오케스트레이션 서비스이다. 여러 개의 컨테이너를 한 곳에서 관리하고 통제할 수 있게 해주며 로드 밸런싱, 자동 스케일링 등 다양한 기능을 제공해주기에 가장 일반적인 선택지가 되고 있다. 하지만 k8s의 가장 큰 단점은 역시 러닝 커브이다. k8s에 대한 독립적인 학습이 필요하다. Ingress, Pod, Deployment 등 기본적으로 새로운 개념이 많이 등장한다. 구조이자 오케스트레이션 도구인 만큼 "개발"이 아닌 "인프라"에 가까운 도구이기에 일반적인 개발자에겐 많이 생소한 개념들이 존재한다. 쿠버네티스의 장단점을 정리하면 아래와 같다.

 

장점

1. 각 서비스의 독립성이 높다.

마이크로 서비스 구조는 서로 다른 서비스 사이의 의존성이 거의 없다시피 만들어진다. 그렇기에 각 서비스를 구현할 때 기능마다 언어가 달라도 상관 없다. 이런 측면에서 k8s는 특정 프레임워크나 언어에 종속적이지 않은 독립적인 도구이기 때문에 서비스를 구현할 때 그 어떠한 제약도 받지 않는다. AI를 사용하는 챗봇 서비스에는 Python을 사용하고 채팅 서비스에는 Node.js를 사용하며 사용자 인증 로직에는 Java를 사용하는 등 각 서비스에 맞게 유리한 언어를 선택해서 개발할 수 있다.

 

2. 자동 스케일링이 적용된다.

설정만 해둔다면 모든 서비스에 자동으로 스케일링이 적용된다. 이 스케일링도 설정과 상황에 따라 수직 스케일링을 적용할 수도, 수평 스케일링을 적용할 수도 있다. 수직 스케일링이란 해당 서비스를 구동하는 장치의 스펙을 올려 Scale-Up을 하는 방법이며 수평 스케일링은 동일한 스펙을 가진 장치에 동일한 서비스를 구동하는 Pod를 n개 더 생성새 Scale-Up을 하는 방법이다. 특정 기능의 사용자가 갑작스럽게 많아지는, 비교적 간단한 연산을 수행하는 횟수가 많아지는 경우 수평 스케일링을 통해 처리하는 장치의 수를 늘릴 수 있고 어떤 기능이 데이터를 처리하는데 특출나게 큰 데이터가 들어와 한 번에 많은 양의 연산을 요구한다면 수직 스케일링을 통해 속도를 올릴 수 있는 것이다.

 

3. 생태계가 넓다.

대중적이고 일반적인 MSA 도구로 자리 잡은 만큼 다양한 도구들이 호환되며 이런 도구들과 통합하는데 굉장히 용이하다. 모니터링을 위해 Grafana와 Prometheus를 사용하고, 데이터 처리를 위해 Kafka를 사용하고, Servie Mesh 영역을 위해 Istio를 사용하는 등 다양한 도구들과 통합하는데 굉장히 유리하다. 

 

4. 클라우드 서비스에 독립적이다.

대중적인 클라우드 서비스 제공자( AWS, Azure, GCP 등 )에서 대부분 k8s를 다루고 있다. k8s는 클라우드와 완전히 독립적인 도구이기 때문에 클라우드 서비스 제공자에 종속적이지 않고 어디서든 동일하게 작동한다. 물론 EKS와 같은 완전 관리형 쿠버네티스를 사용한다면 말이 달라지겠지만 단순히 k8s만 놓고 본다면 클라우드에 종속적이지 않다는 것은 사실이다.

 

단점

1. 높은 학습 곡선이 요구된다.

가장 큰 단점이자 가장 먼저 떠오르는 단점이다. 기본적으로 지금까지 도구들과는 전혀 다른 개념들이 많이 등장한다. Ingress, Deployment, Service, Pod 등등 지금까지 사용하지 않는 새로운 개념이 등장한다. 인프라를 많이 만져본 사람이면 그나마 좀 나을 수 있지만 그렇지 않은 개발자들이 마주하면 처음엔 많이 어려움을 겪는다. 기본적인 개념을 다 배운다고 끝이 아니라 이를 쉽게 사용하기 위한 Helm Chart, 배포를 쉽게 하기 위한 ArgoCD 등 자연스레 함께 따라오는 다른 도구들도 생각하면 학습 곡선이 절대 낮지 않다.

 

2. 로컬 개발이 어렵다.

일반적으로 개발하던 방법과 달리 k8s를 통해 개발하고 테스트를 하기 위한 로컬 개발 환경을 만들기 위해 추가적인 노력이 필요하다. 단순히 개발하고 빌드하고 실행만 하는 것이 아닌 로컬에서 실제 테스트를 위해서도 로컬에 배포하는 등 작업이 필요하다. 한 번 틀을 만들어두면 수월하겠지만 이 과정이 다른 방법에 비해 시간을 꽤 가져가기 때문에 비교적으로 로컬 개발에 난이도가 좀 있는 편이다.

 

3. 최소 리소스가 적지 않다.

서비스 초기 단계에는 대부분 높은 양의 리소스를 요구하지 않는다. 하지만 k8s 자체가 구동하기 위한 최소 요구 환경이 낮은 편이 아니다. 특히 컨트롤 플레인 구동을 위해 요구하는 리소스가 생각보다 많은 편이다. 그렇기에 소규모 서비스나 초기 단계에서는 서비스 규모에 비해 리소스가 많이 소모되는 현상이 나타난다.

 

Spring Cloud

Spring을 사용하는 서비스로 마이크로 서비스 구조를 구현할 때 많이 선택되는 프레임워크이다. 이름에 Spring이 붙어 있듯 Spring 프레임워크에 굉장히 종속적이라는 것만 빼면 k8s에 비해 구현도 쉽고 사용하기도 쉽기 때문에 많이 선택된다고 한다. 

Netflix Eureka

MSA를 도입하고 큰 성공을 거둔 것으로 유명한 Netflix에서 제공하는 서비스이다. 여러 개의 서비스들을 하나의 서버에서 관리할 수 있게 만들어주는 도구로 Eureka 서버라는 하나의 서버에서 n개의 서비스들을 Eureka 클라이언트로 관리해 서비스 간의 통신을 도와주고 하나의 서버에서 관리할 수 있도록 해주는 도구이다. 

 

장점

1. Spring과 통합되어 있다.

Rest API 서버를 구현할 때 Spring Boot를 많이 사용하는데 이런 Spring Boot와 통합이 굉장히 잘 되어 있다. 완벽하게 통합되어 있기 때문에 설정도 간단하고 쉽게 시작할 수 있다는 점이 가장 큰 특징이다. Spring Cloud는 물론이고 Netflix Eureka 또한 통합이 잘 되어 있기 때문에 간단한 설정만 해줘도 쉽고 빠르게 개발을 시작할 수 있다.

 

2. 개발자 친화적이다.

k8s는 인프라에 가까웠다면 Spring Cloud + Eureka는 개발에 가까운 느낌이다. Java 개발자, Spring 개발자에게는 굉장히 환경이 익숙하며 어노테이션 및 yaml 설정을 사용하기 때문에 굉장히 익숙하고 어렵지 않게 접하고 사용할 수 있다는 특징이 있다.

 

3. 로컬 개발이 가능하다.

따로 도구를 설치해야 했던 k8s와 달리 이 구조는 사용하고 있는 IDE에서 바로 실행해볼 수 있다. 개발자에게 있어 개발 과정에 들어가는 시간을 줄여주고 러닝 커브를 낮춰주기 때문에 이는 굉장히 큰 장점으로 다가온다.

 

단점

1. Spring에 종속적이다.

가장 큰 단점이자 어쩔 수 없는 단점이다. 말 그대로 Spring Cloud이기 때문에 Spring에 종속적인 것은 피할 수 없다. 물론 다른 언어를 사용할 수는 있지만 그 과정이 비교적 복잡하다. 어떤 언어라도 상관없이 일반 서비스 개발할 때처럼 개발해도 되는 k8s와 달리 Spring은 Java 외 언어로 개발을 하게 되면 이런 저런 복잡한 과정을 거쳐서 연결해야 한다. 

 

2. 확장성에 한계가 있다.

하나의 외부 도구가 아닌 라이브러리를 활용하는 만큼 확장성에 한계가 있다. 그렇기에 확장 가능성이 높거나 다양하게 뻗어 나갈 수 있는 경우라면 언젠가 제약에 걸릴 수 있다는 특징이 있다.

 

 

마이크로 서비스 구조 구현을 공부하고 연습할 때 k8s도 사용해보고 이번에 Spring Cloud와 Eureka를 사용해보았는데 서로서로 장단점이 있었다. 

쿠버네티스를 활용한 간단한 서비스 구현

쿠버네티스의 경우, 초기 지식이 전혀 없는 무에서 하나의 정상적으로 작동하는 클러스터를 구성할 수 있는 데까지 공부하는 시간이 꽤 오래 걸렸다. 구조를 이해하는 것부터 각 개념들이 담당하는 역할, 작성해주어야 하는 설정, 명령어 등 모든 것이 처음이었기 때문에 굉장히 시간을 많이 잡아먹었다. 공부했다고 바로 적용했을 때 구축이 항상 원활하게 되는 것도 아니었다. 다양한 이유로 에러와 마주쳤기 때문에 공부하는데 굉장히 어려움을 겪었다. 최종적으로 무에서 클러스터 구축 후 간단한 서비스 구현 및 배포 자동화까지 약 한 달이 넘게 걸렸던 것 같다. 이렇게 만들어진 클러스터도 보안, 인증, 데이터 동기화 등을 생각하지 않은 것이다. 다른 도구들과 통합이 잘 되지만 해당 도구들에 대한 기본 지식이 없으면 결국 그 도구들도 추가적으로 공부해야 한다. 데이터 정합성을 위해 RabbitMQ나 Kafka를 사용하며 이 도구들과 통합이 잘 되어 있다고 하지만 이 도구들을 모르면 공부해야 하고, 모니터링을 위해 Grafana와 Prometheus를 사용하기 위한 통합이 잘 되어 있다지만 이 도구들을 사용해보지 않았다면 이 도구들을 공부해야 한다. 확장성을 생각하면 공부할 것이 끝도 없으며 생각보다 실습하는 과정에서 많은 에러들을 마주하게 된다. 

하지만 한번 틀이 완성되면 정말 편한 것도 사실이다. 특히 언어 제한이 없고 기능을 구현할 때 아무 제약 없이 프로젝트를 만들어도 된다는 것은 큰 장점으로 다가온다. 기능 하나하나에 대한 세부적으로 효율적인 개발을 할 수 있다는 것이 큰 장점으로 다가왔다.

 

Spring Cloud + Netflix Eureka를 사용한 MSA

 이후 Spirng Cloud와 Eureka를 활용한 MSA 구현도 진행해봤는데 확실히 난이도 차이를 체감할 수 있었다. MSA에 대한 기본적인 이해가 있었기 때문에 당연히 학습 기간이 짧을 거라고 생각했지만 그걸 감안해서도 차이가 많이 났다. 무엇보다 너무 간단하게 구현할 수 있었다. 의존성 추가하고 yml 파일에 설정 추가하고 어노테이션만 넣으면 완성이다. Deployment 파일을 작성하고 이를 구현하기 위한 Service 파일도 작성하며 배포를 위해 ArgoCD에 등록하고 서비스 간 통신을 할 수 있게 만들기 위해 Ingress 설정하고 등등 서비스 하나 만드는데 수많은 yaml 파일을 작성했던 k8s와 달리 몇 줄 넣어주는걸로 구현이 되니 너무 빠르고 쉽게 사용할 수 있었다. 처음 개발을 배울 때부터 지금까지 Java을 주 언어로 사용하고 있었던 지라 더욱 쉽게 다가왔다. 실무가 아닌 토이 프로젝트나 사이드 프로젝트에서 적용하기 너무 좋았다. 오버 엔지니어링이 되지도 않고 리소스도 많이 사용하지 않기 때문에 지금 위치에서 MSA를 구현할 때 가장 적합한 선택지가 아닐까 생각했다.

 

모놀리식 구조로 되어 있는 서비스들을 많은 기업들이 MSA로 바꾸려는 시도를 하고 있고 바꾸고 있다. MSA가 가져오는 이점이 그만큼 의미있기 때문이다. 하지만 모놀리식 구조에서 MSA로 바꾸는데 굉장히 많은 자원이 소비되는 것도 사실이다. 인프라 구축부터 달라지며 모놀리식한 구조를 모두 분할해야 하고 이 과정에서 생기는 데이터 정합성도 고려해야 하며 기존에 돌아가는 모든 코드들이 바뀌고도 잘 돌아가는지 확인해야 하는등 보통 일이 아니라는 것은 누구나 알 수 있다. 하지만 앞으로 MSA는 꼭 알고 있어야 하는 구조라고 생각한다. 무엇보다 다양한 서비스 구조가 존재하며 다양한 형태가 있다는 것을 처음 알게 해준 것이 마이크로 서비스 구조이기 때문에 더더욱 관심을 갖고 있다. 

그렇기에 k8s가 어렵다면 Spring Cloud와 Eureka로 처음 입문해 MSA를 경험하고 k8s까지 나아가 다룰 줄 아는 개발자가 되면 추후 나에게 큰 무기가 될 것이라고 생각한다.