spring cloud MSA?
국비지원에서 'MSA를 위한 Full-stack 개발자 양성과정'을 들은 적이 있다.
기본 교육과정으로 html, css, js / java와 더 나아가 servlet/jsp, spring boot를 수강할 수 있었다. 그 때에는 MSA에 대한 이해도 너무 낮았고, 이것을 Spring boot와 어떻게 연결시키는지에 대한 의문을 갖고 있었다. 프로젝트를 어떻게 해야 쪼갤 수 있는건지, 사실 하나로만 프로젝트를 제작하는 것도 큰 무리가 없어보이기는 했다.
기본적으로 내가 가지고 있는 생각은
모놀리식 아키텍처라고 한다.
모든 코드를 하나의 프로젝트에서 실행시키는 것을 의미한다. localhost에서 개발하거나 규모가 작은 프로젝트에서는 굳이 쪼갤 필요 없이하나의 프로젝트에서 하는 것이 훠얼-씬 편하다.
그러나 여기서 자주 등장하는 예시인 Netflix가 등장한다. Netflix에서는 데이터베이스 시스템이 손상되어 그 이후로 모놀리식에서 교체하여 마이크로 서비스를 선도하고 있다고 한다.
만약 이 아키텍처의 프로젝트라면, 작은 수정 하나에도 전체를 빌드해야 한다.
손에 먼지묻었다고 샤워를 하는 셈이다..🛀🧽
모놀리식 아키텍처는 참 좋지만, 프로젝트의 규모가 점차 커질수록 개발이 더욱 복잡해지고 속도도 느려지는 단점 이 있다. 뿐만 아니라 안정성, 확장성, 유연성에서도 문제가 있다. 예를 들면, 메뉴에 한 글자가 빠져서 수정을 하고 다시 배포해야 하는데 하나의 프로젝트라고 한다면 결국 통으로 배포를 다시해야한다. 이러한 부분에서는 점차 높은 트래픽을 요구하게 될 때에는 부담이 될 수 밖에 없는 아키텍처이긴 하다.
마치 대학교 팀플에서 한 사람이 4명분을 다 맡아서 하게 되는 느낌과 비슷하다. 오류가 있으면 오류를 잡아야 하고, CS에 문제 생기면 CS를 들여다 봐야 하고, 발표도 해야하고,, 결국 모놀리식 아키텍처는 프로젝트가 거대해질수록 점차 어려워진다.
MSA는 마이크로서비스를 의미하는데 서비스를 잘개 쪼개어 독립적으로 유닛이 실행될 수 있도록 각 서비스를 개발하는 것이다. A가 주문을 개발하고, B가 결제를 담당한다고 했을 때 A, B가 합심하여 서로 규약을 세워 하나의 프로젝트를 만드는 것은 모놀리식이라고 할 수 있다.
마이크로서비스는 서로 개발만 하고 각각의 통신 규약만 정해주면 이루어질 수 있는 서비스를 생각하면 된다. 즉, 하나의 서비스는 다른 서비스에 영향을 미치는 일이 많이 없으며 이후에도 개발, 업데이트 및 배포 모두 독립적으로 이루어진다고 할 수 있다. 확실히 확장성에서도 유용하고, 유연하며 안정성 있게 흘러갈 수 있다고 생각된다.
그러나 마이크로서비스도 장점만 있는 것은 아니다. 인프라 비용이나 공동작업 부분, 무분별한 개발(-> 복잡해질 수 있음) 등의 문제가 있다. 특히나 과거로부터 내려온 전통적인 코드, 플랫폼 등을 레거시라고 하는데 이 레거시를 해결하기 위해 마이크로서비스로 이전하는 비용도 만만치 않다. 결국은 어떤 것을 가져갈 것인가 끝없이 고민해야 하는 부분이긴 하다.
근데 왜 Spring일까?
Spring cloud
다음은 spring cloud의 사이트에 기재되어 있는 설명을 그대로 가져왔다.
(https://spring.io/projects/spring-cloud)
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
스프링 클라우드에서 제공하는 핵심 가치는 분산 시스템에서의 공동 패턴을 가질 수 있도록 하는 부분인 것이다. e.g. 이후의 밑줄은 스프링 클라우드에서 실제로 제공해주는 서비스를 의미하는데 앞으로 살펴보아야 할 녀석들이다.
https://spring.io/microservices
Spring에서는 마이크로서비스를 위한 다양한 기술을 제공해준다. 위의 사이트에 접속하면 스프링 클라우드에 대해 지원하고 있는 문서를 읽어볼 수 있는데 해당 사이트에서 Spring Cloud의 각 메뉴의 OVERVIEW, LEARN을 참조한다. 또한 오른쪽의 Reference Doc.을 클릭하면 상세 문서를 볼 수 있다.
CURRENT : 현재 버전
GA(General Availability) : 테스트를 마친 안정적인 버전
SNAPSHOT : 개발 단계, 백업 시점
살펴볼 기술이 너무나도 많기 때문에 이를 흐름도로 그려보았다.
온달의 해피클라우드님 블로그에서 흐름도를 가장 잘 나타내었다고 생각하여 나는 이 위에 스스로 공부한 부분을 입혀 흐름도를 제작해보았다.
ver 0.1 (2022. 01. 17) : 초기 이미지 작업
ver 0.2 (2022. 01. 21) : client 추가
이 외에도 Spring cloud에는 정말 많은 기능이 있다. 여기서 소개하지 않은(ver 0.2 기준으로) Zookeeper도 있고, security kubernetes도 이후에 충분히 다루어볼 예정이다. 지금은 위의 그림에 나와있는 라이브러리를 직접 제작해보면서 어떻게 사용되는지 확인해 볼 예정이다.
결국 마이크로서비스는 하나의 모놀리식 서비스를 여러 개로 분산하면서 생기는 문제점들을 보완하며, 분산된 서비스를 효율적으로 활용하기 위해 장점을 극대화하는 하나의 아키텍처이다. 다수의 서비스가 서로 협력할 수 있도록 각 client 서버의 주소를 알고 있는 eureka 서버, 오류의 근원지를 찾기 위해 사용하는 sleuth, 서버를 증설하는 것이 아닌 소프트웨어에서 로드밸런서를 활용할 수 있도록 해주는 ribbon등 하나 같이 없어서는 안 될 라이브러리이다.
모든 개발을 Spring Cloud에 적용할 필요는 아직까지 없다고 생각한다. Netflix에서도 모놀리식에서 마이크로서비스로 바꾸는데 7년이 걸렸다곤 하지만(물론 그 개념이 없던 것이기도 했고, 실제 서비스를 운영하고 있는 상태에서 구조체를 바꾸기는 힘들겠지만 감안해보자) 작은 규모의 프로젝트나 서비스를 나눌 필요가 없는 개발에서는 초기부터 spring cloud 전체를 적용해볼 필요는 없을 것이다. 또한 해당 기술에 대한 이해와 적용이 필요하기 때문에 상황마다 다를 것이다.
또한 Spring Cloud를 제외하고도 Jenkins나 Nexus, elasticsearch와 같은 다른 인프라도 직접 구성해보며 어느 상황에 어떤 기술이 필요할지에 대해 더 고민해보고 적용해보는 것이 필요하다고 생각한다.
Spring Cloud 참고자료
spring cloud git : https://github.com/spring-cloud
spring cloud 한국어 가이드 : https://coe.gitbook.io/guide/circuit-breaker/hystrix
해피클라우드님 Tistory 블로그 : https://happycloud-lee.tistory.com/207
chapter별 학습 : https://github.com/forezp/SpringCloudLearning
