마이크로서비스 배포 : Spring Cloud와 Kubernetes 비교(해외 포스팅 번역)

Spring Cloud for Microservices Compared to Kubernetes 글을 번역한 것입니다. 2016년 글로 꽤 오래전 글이나, 상당한 인사이트를 제공해 번역했습니다.

목차

🐳배경
🐳마이크로서비스 문제
🐳기술 매핑
🐳마이크로서비스요건
🐳강점과 약점
🐳두 세계의 최적 조합

🐳배경

확장성있고 탄력있는 수 십 또는 수 백 개의 마이크로서비스로 구성된 시스템을 구축하기 위해, 시스템을 중앙 관리하고 광범위한 빌드와 실행 시간에 대한 능력을 가진 툴의 도움을 받아야 한다. 스프링 클라우드는 기능 서비스와 인프라 서비스(eg. 로그 분석, 설정 서버, 서비스 디스커버리, 인증/인가 서비스 등) 모두 제공한다. 스프링 클라우드를 활용한 MSA를 표현한 그림은 아래와 같다. 위 그림은 시스템의 실행시간 관점을 보여준다. 하지만 MSA에서 중요한 패키징, 지속적 통합(Continuous Integration), 스케일링, 고가용성, 자가치유 등은 보이지 않는다. 이러한 추가적인 고려사항들을 살펴보면서 Spring Cloud 와 Kubernetes가 어떠한 관계에 있는지 살펴볼 것이다.

🐳마이크로서비스 관심사

각각의 기능별 비교보다는 마이크로서비스의 관심사를 중심으로 스프링 클라우드와 쿠버네티스가 어떻게 접근하는지를 살펴보고자 한다. 마이크로서비스는 독립적인 배포와 기술적인 다양성을 통해 모듈간의 뚜렷한 경계를 가능케 한다. 하지만 이러한 구조는 분산 시스템 개발에 대한 비용과 상당한 운영상의 과두화를 일으킨다. MSA의 성공적인 구축을 위해 중요한 요소는 가능한 MSA 고려사항들에 대해 도움을 줄 수 있는 툴을 활용하는 것이다. 빠르고 쉽게 시작 프로세스를 만드는 것이 중요하지만, production에 이르기까지의 여정은 길고 멀기만 하다.

위의 그림에서, 우리는 MSA과 관련한 가장 흔한 기술적 고려사항들을 볼 수 있다. (여기서 우리는 조직 구조, 문화 등의 비기술적인 고려사항들은 다루지 않을 것이다.)

🐳기술 매핑

스프링 클라우드와 쿠버네티스 두 플랫폼은 매우 다르고, 직접적으로 대칭되는 특징이 없다. 각각의 MSA 고려사항들에 대한 두 플랫폼에 대한 매핑은 아래와 같다.

위 테이블의 핵심은 아래와 같다.

• 스프링 클라우드는 다수의 통합된 자바 라이브러리를 제공한다. 다양한 라이브러리들은 어플리케이션 스택의 부분으로서 모든 실행시간의 고려사항들에 대해 다룬다. 결과적으로, 마이크로서비스들은 클라이언트 사이드 서비스 디스커버리, 로드 밸런싱, 설정 업데이트 등을 행하는 라이브러리와 실행시간의 행위자를 가진다. 싱글톤과 같은 패턴과 배치 잡들은 JVM에서 관리된다.

Spring Cloud (Bryce 요약)  
 - Java 라이브러리 다수 존재
 - JVM 환경에 적합한 기능 제공
 - runtime
 - application stack의 일부로써 기능

• 쿠버네티스는 자바 플랫폼만을 위한 것이 아닌 다양한 언어를 지원한다. 그리고 모든 언어에 대해 보편적인 방식으로 분산 컴퓨팅 문제들에 대한 답을 제시한다. 쿠버네티스는 설정 관리, 서비스 디스커버리, 로드 밸런싱, 추적, 매트릭스, 싱글톤, 스케쥴 잡을 위한 서비스를 플랫폼 레벨에서, 어플리케이션 스택의 외부에서 제공한다. 어플리케이션은 클라이언트 사이드의 로직을 위한 어떠한 라이브러리와 agent가 필요하지 않다. 그리고 어떠한 언어에서도 적용될 수 있다.

Kubernetes (Bryce 요약)  
 - Java 한정 X, 모든 언어 적용 가능
 - 분산 컴퓨팅 문제 해결을 위한 전반적인 기능 제공
 - platform 수준
 - application 외부에서 기능

• 일부 두 플랫폼 모두 의존하는 비슷한 서드 파티 도구들이 존재한다. 예를 들어 ELK과 EFK 스택들, 추적 라이브러리 등.

• Hystrix, Spring Boot와 같은 몇몇 라이브러리들은 두 환경에 모두 유용하다. 두 플랫폼 간에 상호 보완적인 영역이 존재한다. 또한 두 플랫폼이 결합되어 강력한 솔루션이 되기도 한다.(eg. KubeFlix, Spring Cloud Kubernetes)

🐳마이크로서비스 요건

하드웨어에서부터 데브옵스에 이르기까지의 단계를 통해 스프링 클라우드와 쿠버네티스가 어떤한 관계에 있는지 아래 테이블을 통해 확인할 수 있다. 일부 경우에 두 프로젝트는 서로 다른 방식으로 접근법을 사용해 동일한 요구사항들에 대해 다룬다. 그리고 또 다른 일부에 있어서는 한 프로젝트가 다른 것보다 강점을 가지기도 한다. 또한 굉장한 마이크로서비스 경험을 위해 두 플랫폼이 상호보완적이고 결합할 수 있는 지점이 존재한다.
예를 들어, 스프링 부트는 Jar 패키징을 위한 메이븐 플러그인을 제공한다. 도커와 쿠버네티스의 배포와 스케쥴링 기능과 결합될 경우 마이크로서비스 실행은 식은 죽 먹기와 같다. 비슷한 경우로, 스프링 클라우드는 Hystrix와 Ribbon을 활용해 탄력적이고 장애 허용 마이크로서비스를 위한 어플리케이션 내부 라이브러리들을 가진다. 하지만 그것들만으로는 충분하지 않다. 쿠버네티스의 health check, 프로세스 재시작, 오토 스케일링 기능들과 결합할 때 마이크로서비스는 실질적으로 깨지기 어려운 시스템을 만들 수 있다.

<<Bryce 요약>>  
서로 상호보완적인 영역에 있어서는 함께 적용하는 것이 마이크로서비스 구축을 더욱 견고하게 만들어 준다.  

예시1. Spring Boot Maven플러그인의 Jar packaging + Docker & Kubernetes의 Deployment, Scheduling

예시2. Spring Cloud의 Hystrix & Ribbon + Kubernetes의 health check, process restart, auto-scailing

🐳강점과 약점

두 플랫폼은 기능 별로 비교하기 애매하기 때문에 각 플랫폼이 가지는 강점과 약점을 기준으로 판단하는 것이 필요하다.

🐬Spring Cloud

스프링 클라우드는 분산 환경에서의 공통적인 패턴을 빠르게 구축하도록 도와주는 도구를 제공한다. 예를 들어 설정관리, 서비스 디스커버리, 서킷 브레이커, 라우팅 등. Neflix OSS 라이브러리 기반으로 만들어졌으며, Java 개발자를 위해 만들어졌다.

🦈강점

• 스프링 플랫폼과 스프링 부트의 빠른 어플리케이션 생성 능력에 의해 제공되는 통합 프로그래밍 모델은 개발자에게 훌륭한 마이크로서비스 개발 경험을 제공한다. 예를 들어, 적은 어노테이션만으로 당신은 설정 서버를 만들 수 있다. 약간의 어노테이션을 추가하면 당신의 서비스들을 설정하기 위한 클라이언트 라이브러리들을 얻을 수 있다.

• 실행시간의 주요한 것들을 다룰 수 있는 다양한 선택지의 라이브러리들이 있다. 모든 라이브러리들은 자바로 쓰여져있기 때문에 다양한 기능, 훌륭한 제어, 잘 튜닝된 선택들을 제공해준다.

• 다른 스프링 클라우드 라이브러리들은 다른 라이브러리완 쉽게 통합된다. 예를 들어, FeignClient는 서킷 브레이커 라이브러리인 Hystrix, 로드 밸런싱 라이브러리인 Ribbon과 함께 사용할 수 있다. 모든 것들은 어노테이션 기반이다. 이것은 자바 개발자가 쉽게 개발하도록 해준다.

🦈약점

• 자바에 한정적이다. MSA의 강력한 동기 중에 하나가 기술 스택, 라이브러리, 심지어 언어까지도 필요하면 전환할 수 있는 능력이다. 스프링 클라우드는 불가능한 일이다. 만약 설정 관리, 서비스 디스커버리 또는 로드 밸런싱에 있어 스프링 클라우드/Netflix OSS를 사용하기 원한다면, 그 선택은 훌륭하다고 보기 힘들 것이다. Netflix Prana프로젝트가 JVM환경 밖에서 Neflix OSS 환경을 사용할 수 있도록 구현한다. 하지만 범용성이 떨어진다.

• 개발자및 자바 어플리케이션에 너무 많은 책임이 주어진다. 개발자가 관리할 것들이 많아지며 개발자의 공수가 많이 들어간다.
  각 마이크로서비스에 대한 환경 및 의존성을 관리해야 하며, 빌드하는 시간을 필요로 한다. 또한 설정 서버를 만들 경우 설정 서버가 이미 실행되어 있어야 한다. 서비스 디스커버리에 있어서도 유레카 서버가 실행되고 있어야 한다.

• 스프링 클라우드는 MSA 세계에 있어서 일부분의 기능만을 제공한다. 개발자들은 완벽한 마이크로서비스를 위해 자동 배포, 스케쥴링, 리소스 관리, 프로세스 분리, 자가복구, 빌드 파이프라인 등을 추가적으로 고려해야 할 것이다. 이러한 점에서, 스프링 클라우드와 쿠버네티스 자체에 대한 비교는 부적합하다고 나는 생각한다. 스프링 클라우드 + 클라우드 파운드리(또는 Docker Swarm)과 Kubernetes 간에 비교하는 것이 적합할 것이다. 이는 또한 완벽한 마이크로서비스 경험을 위해 쿠버네티스와 같은 것들로 보완되어야 함을 의미한다.

🐬Kubernetes

쿠버네티스는 자동 배포, 스케일링, 컨테이너 관리를 위한 오픈 소스 시스템이다. 다양한 언어를 지원하며 프로비져닝, 실행, 스케일링, 분산 시스템 관리를 위한 기술을 제공한다.
Container Orchestration

🦈강점

• 쿠버네티스는 다양한 언어를 지원하고, 클라우드 네이티브와 전통적인 컨테이너 어플리케이션 모두 사용할 수 있는 일반적인 컨테이너 관리 플랫폼이다. 설정 관리, 서비스 디스커버리, 로드 밸런싱, 매트릭스 수집, 로그 통합 등의 기능을 제공하는 쿠버네티스는 다양한 언어들에서 사용이 가능하다. 다양한 팀들이 사용할 수 있는 하나의 플랫폼이다. 그리고 다양한 목적을 지원한다 : 어플리케이션 개발, 테스트 환경, 빌드 환경(소스 제어 시스템, 빌드 서버, 아티팩트 저장소*) 등등.

*아티팩트 저장소?
아티팩트와 메타 데이터를 저장하고 관리하는 장소를 의미. 스프링 프레임워크나 jdbc 구현체, 아파치 재단 산하의 오픈 소스 프로젝트 등 외부에서 개발된 라이브러리를 저장하기도 하지만 내부에서 개발되었거나 또는 개발하고 있는 라이브러리를 다른 개발자나 프로젝트와 공유하기 위한 배포 용도로도 사용한다.
서브 버전이나 git 등의 버전 관리 시스템은 소스의 이력 및 공유 용도로 사용하지만 저장소는 아티팩트를 공유하기 위한 용도로 사용되는게 다른 점이다.

• 스프링 클라우드와 비교해서 쿠버네티스는 더 광범위한 MSA 문제를 해결한다. 런타임 서비스를 제공할 뿐만 아니라 쿠버네티스는 당신이 환경을 프로비져닝하도록 하며, 자원 제약을 세팅하고, 어플리케이션 생애주기를 관리하고, 오토 스케일링과 자가치유를 가능하게 한다.(사실상 거의 antifragile 플랫폼으로 기능한다.)

• 쿠버네티스 기술은 구글의 R&D에서 15년 이상의 근간을 두고 있으며, 컨테이너 관리 경험을 가지고 있다. 또한, 1000 여명의 커밋터가 있을 정도로, 깃허브에서 가장 활발한 오픈 소스 커뮤니티 중의 하나이다.

🦈약점

• 쿠버네티스는 다양한 언어를 지원하므로 서비스와 구성요소는 일반적이나 JVM을 위한 Spring Cloud와 같은 다른 플랫폼에 최적화 되어 있지 않다. 예를 들어, 설정은 환경 변수 또는 마운팅된 파일 시스템으로서 애플리케이션에 전달된다. 스프링 클라우드 Config에서 제공하는 훌륭한 설정 업데이트 기능이 없다.

• 쿠버네티스는 개발자 친화적인 플랫폼이 아니다. 쿠베네티스는 데브옵스 관련 IT 직원이 사용하기 위한 것이다. 따라서 자바 개발자는 새로운 개념을 배우고 문제를 해결하기 위한 방법을 배우는 데 열려 있어야 한다. 미니큐브를 사용해 쿠버네티스를 개발자가 시작하는 것은 쉬울지라도, 고가용성 쿠버네티스 클러스터를 직접 설치해야 하는 작업상의 상당한 오버헤드가 존재한다.

• 쿠버네티스는 비교적 새로운 플랫폼(2016년 기준, 2년 경과)이며, 여전히 활발하게 개발되고 성장중이다. 그래서 많은 기능이 추가되고 이를 따라잡는 것은 쉽지 않을 것입니다. 좋은 소식은 API가 확장 가능하고 이전 버전과 호환된다는 것이다.

🐳두 세계의 최적 조합

보다시피 두 플랫폼 모두 특정 영역에 강점을 가지고, 다른 부분에서는 개선할 점이 존재한다. 스프링 클라우드는 빠르게 시작할 수 있고, 개발자 친화적인 플랫폼인 반면에, 쿠버네티스는 데브옵스 친화적이며, 학습 곡선이 더 가파르지만, 마이크로서비스 문제에 있어서 더 많은 문제를 다루고 있다. 아래는 요점들을 요약한 것이다.

두 프레임워크는 서로다른 범위의 MSA문제에 관해 근본적으로 서로 다른 방식으로 처리하고 있다. 스프링 클라우드는 모든 MSA 문제를 JVM 안에서 해결하려고 한다. 반면에, 쿠버네티스의 접근 방식은 문제를 플랫폼 수준에서 해결해 개발자에게 문제가 없도록 한다. 스프링 클라우드는 JVM 내부에서 강력하며, 쿠버네티스는 이러한 JVM을 관리하는 데 강점을 가진다. 따라서 그들을 조합하고 두 프로젝트의 가장 좋은 을 활용하는 것은 당연한 것으로 느껴진다. 이러한 조합으로 스프링은 어플리케이션 패키징을 제공하고, 도커와 쿠버네티스는 배포와 스케쥴링을 제공한다. 스프링은 Hystrix 스레드 풀을 통해 애플리케이션 내부 벌크헤딩을 제공하고, 쿠버네티스는 자원, 프로세스, 네임스페이스 격리를 통해 벌크헤딩을 제공한다. 스프링은 모든 마이크로서비스를 위해 상태 엔드 포인트를 제공하고, 쿠버네티스는 상태 확인(health check) 및 정상적인 서비스로의 트래픽 라우팅을 제공한다. 스프링은 설정을 외부화하고 업데이트 하며, 쿠버네티스는 설정을 모든 마이크로서비스에 배포한다.

🐳참조

• Spring Cloud for Microservices Compared to Kubernetes : https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes