휴먼, Spring cloud를 왜 씁니까?

Notice

Recent Posts

Recent Comments

Link

« 2024/07 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Tags more

Archives

Today

Total

관리 메뉴

져니의 개발 정원 가꾸기

휴먼, Spring cloud를 왜 씁니까? 본문

개발노트/Spring Cloud

휴먼, Spring cloud를 왜 씁니까?

전전쪄니 2023. 1. 15. 02:35

spring cloud? 이게 무엇일까?

밸덩 블로그와 spring.io에 명시된 설명에 의하면

spring cloud는 강력한 클라우드 기반 애플리케이션을 구축하는 스프링 모듈이다.

하지만 스프링 부트 혹은 스프링 프레임워크를 처음 배워서 배포했던 그 날을 떠올려보자.

spring cloud 사용하셨나요? 👀

고개를 끄덕이는 사람도 있겠지만, 내가 글을 쓰는 이 시대에서는 대부분의 사람은 NO 라고 대답할 것이다.

(도커나 쿠버네티스를 사용하는 것과는 상관없이) spring cloud 같은 거 설정한 기억도 없고...대개 .jar 파일로 말아 배포하면 뭐...잘 되던데?

그럼 이 녀석을 대체 왜 쓰는 것인가? 분명 강력한 클라우드 기반 애플리케이션을 구축해준다고 했는데, 없어도 문제없이 서비스 했던 것 같은데 말이다.

스프링 클라우드가 무엇인지에 대한 말 뜻 자체에서 스프링 클리우드 사용을 사용하는 이유를 알 수 있다.

1. 클라우드 네이티브 앱을 만드는데 필요한 기능들을 제공받을 수 있다.

클라우드의 시대가 오면서 클라우드에서 잘 동작하는 서비스를 만드는 것 역시 관심의 대상이 되었다.

이에 Heroku의 개발자들이 SaaS를 잘 만들기 위해 새로운 애플리케이션 방법론을 만들어 제시했는데, 이 방법론을 Twelve-Factor App 이라고 한다.

(많이 알려진 이 방법론을 여기서 얘기를 하기엔 셋길로 세는 것 같아, 여기서는 설명을 패스하겠다.)

그리고 이 Twelve-Factor App의 원칙들이 클라우드 네이티브 앱의 기반 요소로서 작용하고 있다.

잘 만든 SaaS의 원칙들을 일부 지키고 있는 클라우드 네이티브 앱... 너무 말이 어렵다.

한마디로 클라우드 네이티브 앱은, 그냥 클라우드 환경에서 동작하는 앱을 지칭하는 것이 아니라 클라우드의 이점을 활용할 수 있는 앱을 말하는 것이다.

다소 추상적인 정의일 수 있으나, CNCF(Cloud Native Computing Foundation)에 따르면 클라우드 네이티브 앱 다음과 같은 개념을 포괄해야한다고 한다.

퍼블릭, 프라이빗, 하이브리드 클라우드 환경에서 확장가능한 애플리케이션을 만들고 운영할 수 있다.
(e.g - 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API)
회복성, 관리 편의성을, 가시성을 제공하며 느슨하게 결합된 시스템을 가능하게 한다.
견고한 자동화와 함께 사용하면, 엔지니어는 최소한의 수고로 영향력이 크고 예측 가능한 변경을 할 수 있다.

이를 바탕으로 처음 AWS에 배포한 스프링 부트 앱을 보자.

클라우드의 이점을 온전히 사용한 앱이라고 할 수 있을까? 도커와 젠킨스를 붙여 자동화까지 해놓을 수도 있지만, 클라우드에서 확장 가능한 애플리케이션을 만들었을까?

spring.io 공식문서에서는 스프링 클라우드에 대해 다음과 같이 설명한다.

스프링 클라우드는 개발자들이 분산시스템에서 몇몇의 공통 패턴(eg. 컨피규레이션 관리, 서비스 디스커버리, 서킷브레이커, 로드밸런싱, 클러스터 상태 등등)을 빠르게 만들 수 있도록 도와주는 툴을 제공한다. 각 환경들이 조화롭게 구성된 분산시스템은 보일러 플레이트 패턴들로 이어지게 되는데, 이는 보일러 플레이트 패턴을 구현하는 애플리케이션이나 서비스를 빠르게 구축할 수 있게 한다.이러한 분산시스템 속에서 개발자들은 어떠한 분산 환경에서도(심지어 개인 PC이건 온프렘이건) 용이한 개발을 할 수 있다.

즉, 스프링 클라우드를 사용하면 클라우드의 근간인 분산 환경에서 개발과 운영을 빠르고 쉽게 할 수 있다는 것이다.

클라우드 환경에 우리가 애플리케이션을 올렸다고 해보자. 우리는 스프링 클라우드의 핵심 컴포넌트(아래표 참고)들을 사용하여 클라우드 이점들을 누릴 수 있다. 가령, Circuit Breakers는 애플리케이션의 회복성도 높일 수 있고, Configuration을 통해 (설정 정보가 바뀔 때마다)애플리케이션을 매번 다시 빌드하지 않고 컨피그 서버로부터 프로퍼티들을 주입할 수 있다. 그리고 Tracing을 통해 분산 되어있는 모든 서버들이 어떻게 통신을 하고 있는지를 확인 할 수 있다.

출처 - The Beginner’s Guide To Spring Cloud - Ryan Baxter

스프링 클라우드를 사용했을 때, 클라우드에 스프링 클라우드 없이 .jar로 배포된 애플리케이션보다 더 클라우드 환경을 제대로 활용할 수 있다는 말이고, 클라우드 네이티브 앱을 만들기 위한 기능들을 사용할 수 있다.

2. 분산환경(eg. MSA)으로 프로젝트를 이관할 때 마주칠 수 있는 문제들에 대한 솔루션들을 사용할 수 있다.

사실 이 부분은 앞에 1번과 굉장히~~~비슷한 말들이 나올 것이다.

그러나 신규 구축과 이관은 엄연히 다른 것이기 때문에 주제를 나누었다.

작은 토이 프로젝트부터 회사에서 운용하는 큰 프로젝트까지 많은 프로젝트가 클라우드에 있지는 않다.

특히나 과거 레거시 프로젝트가 새로운 프로젝트로 등장했을 당시에는 클라우드는 무슨... 오히려 온프레미스 환경에서 프로젝트를 시작했을 것이다.

문제는 이렇게 과거에 삐까뻔쩍하게 등장한 온프레미스의 모놀리식 서비스가 현재 너무 큰 낡은 덩어리가 되어버렸을 때이다.

(정말 심각하게는 사소한 장애 하나가 발생했을 뿐인데 이게 전체 덩어리, 즉 전체 서비스의 장애로 이어지는 대참사가 발생하는 경우도 있다.)

이럴 때 우리는 클라우드 기반 MSA를 생각한다.

기존 모놀리식을 MSA로 전환할 때 신경써야 할 부분은 다양한데, 어쩌면 처음부터 클라우드에 애플리케이션을 구축하는 것보다 어려울 때도 있다.

그러나 한 번에 MSA로 잘 이관되면 좋으련만, 이관시 100% 장애없이 똑같이 동작한다는 것은 개발자가 장담할 수 없는 부분이다.

잘개 쪼개진 서비스들의 property들이 바뀔 때마다 다 빌드를 한다면 관리 포인트가 늘어나고 인스턴스 사용율이 높아지지는 않는지, 서비스 중 하나가 통신 실패가 일어났을 때 전체 장애로 이어지지 않도록 어떻게 대처할 것인지, 많은 서비스들 중에서 장애가 발생하는 케이스들에 대해 어떻게 관리를 할 것인지, 서비스들의 통신 관리는 어떻게 해야할지 등 고려해야될 많은 문제들이 기다리고 있다.

Spring cloud를 이용하면 MSA로 전환하여 직면할 수 있는 문제들을 처리하기 위한 아주 다양하고 용이한 솔루션들을 이용할 수 있다.

config 서버를 두어 설정 정보들을 관리할 수 있고, 쪼개진 서비스들을 사용할 수 있도록 service discovery와 API gateway를 둘 수도 있다. 또한 circuit breaker기능을 통해 임계치를 넘어서는 장애 상황에서 대처할 수 있도록 하게 하며, 서비스 통신 실패에 대한 fallback도 지원한다.

모놀리식 구조에서 spring cloud 기반 MSA 전환을 한 대표적인 사례는 무엇이 있을까?

11번가가 있다. ㅎㅎ

전 11번가 담당님이 2018년에 네이버 d2에서

"11번가 Spring cloud 기반 MSA로 전환" 발표를 하신 적이 있는데, 스프링 클라우드를 도입하게 된 배경부터 실제 적용기, 회고까지 잘 나와있다.

백문이불여일견이라고, 영상을 보면 MSA에서 마주칠 수 있는 문제들을 어떠한 솔루션들을 통해 해결해갔는지를 체감할 수 있을 것이다.