[Tanzu] Spring, Springboot, Spring-Cloud 소개

Tanzu Portfolio 포스팅을 보고 오셨나요? 아니라면 , 아래 링크를 통해 Tanzu Portfolio에 대해 궁금하신 분들은 확인 해봐요! 

Tanzu portfolio를 보면 알겠지만 VMware의 시장전략에는 Spring에 대한 영향력을 최대한 활용하겠다는 느낌을 받을수 있다. 그래서 Spring과 Tanzu가 어떻게 서로 상호보완 관계를 가지는지 알아보고자 이번 포스팅을 작성 하게 되었다.

 

개발자가 아닌 엔지니어에게 Spring과 Springboot를 설명하기는 쉽지 않을것이다. 어디서부터 어떻게 설명을 해야할까? 라는 생각을 하다 이번 포스팅을 작성하기로 마음먹었다. 

• 엔지니어들과 이야기 하다 보면 Go언어, 파이썬에는 다들 관심이 많다. 하지만 자바에 대해서는 다들 관심이 없다.
• Go언어로 쿠버네티스를 만들었고 파이썬이 배우기 쉬운 언어인것은 맞지만 국내 가장 많이 쓰인 언어는 누가 뭐래도 JAVA다.
• 대한민국이 자바 공화국이기 때문에 국내 개발자의 70% 이상이 JAVA를 사용하고 있다.
• Java는 한국, 중국 및 독일에서 가장 많이 사용되는 언어이며, 한국의 Java 점유율은 53%, 중국은 47%, 독일은 33%이다.
• Java와 Spring은 뗄수 없는 관계이다.

Spring이란 자바를 기반으로 만들어진 애플리케이션 프레임워크를 의미합니다

 

스프링에 대해서 조금더 알아봅시다.

왜 스프링을 쓰는지

Springboot는 대체 무엇인지

Spring-cloud는 대체 무엇인지 

 

1.  What is Spring?  

---

Java 기반으로 만들어진 애플리케이션 프레임워크

프레임워크 ?

프레임워크란 뼈대나 근간을 이루는 코드들의 묶음을 의미  개발자는 프레임워크를 이용하여 프로그램의 기본흐름이나 구조를 정하고, 팀원들은 이 위에 자신의 코드를 추가하는 방식으로 개발 가능

애플리케이션 프레임워크는 애플리케이션 개발을 빠르고 효율적이게 하기 위한 틀입니다. 특히 웹개발에 있어서는 스프링 프레임워크의 무구한 기능들을 무시할수 없습니다. 국내 개발 기업들의 웹개발에 대한 사랑(?) 때문인지 그 편한 node.js / python 등 더 활용도 높고 빠른 언어들을 압도하고 있는 추세가 꺽이지 않고 있습니다.

 

 

 

 

스프링 어떻게 사용하는 걸까요?

 

스프링 프로젝트 을 시작 하는 방법에 대해서는 구글링을 통해 쉽게 확인해 볼수 있습니다.

하지만 최근에는 Springboot가 나오면서 회사에서 스프링 Legacy 개발을 하고 있는 경우가 아니라면, 대부분의 개발자들이 Springboot를 사용 할 것입니다.

 

그 이유는 Spring으로 프로젝트를 시작할때

 

• 개발환경을 세팅하는 시간이 굉장히 오래걸립니다.

 xml 파일설정을 통해 의존성 주입을 개인이 직접 해주어야 하기 때문에 개발환경을 세팅 하는데 굉장히 시간이 오래 걸립니다.

또한 개인 로컬 pc에 톰캣was 서버나 데이터베이스를 설치 해야 함으로 꽤 좋은 노트북을 가지고 있지 않다면 개발환경 준비 조차도 어려울수 있습니다.

 

• 개발 속도도 굉장히 느립니다.

xml 파일설정을 통해 의존성 주입을 개인이 직접 해주어야 하기 때문에 개발 과정 역시 불필요한 작업이 너무 많아서 복잡합니다.. 

하지만 , 스프링 부트는 @EnableAutoConfiguration 어노테이션을 선언해서 스프링에서 자주 사용했던 설정들을 알아서 등록해준다. 이 기능이 스프링 부트의 마법이라고 불리는 기능입니다.

 

xml을 통한 스프링의 의존성 주입

 

 

 

 

 

• WAS 서버를 별도로 설치하여야 한다. (apache-tomcat) 스프링 부트는 내장 Tomcat 사용 가능!

Apache tomcat을 다운받는 페이지

 

 

 

 

 

• WAR 사용하기 때문에 무겁다

Web Application Archive : 프로젝트의 산출물을 저장하고 있는 압축된 파일이며 웹 애플리케이션의 내용을 담아놓은 파일이라는 말이다

WAR 안에는 JAR 파일이 들어가 있다.

Jar 확장자 파일에는 Class와 같은 Java 리소스와 속성 파일,  라이브러리 및 액세서리 파일이 포함되어 있습니다. 
쉽게 JAVA 어플리케이션이 동작할 수 있도록 자바 프로젝트를 압축한 파일로 생각하시면 되겠네요. 실제로 JAR 파일은 플랫폼에 귀속되는 점만 제외하면 WIN ZIP파일과 동일한 구조입니다.

JAR 파일은 원하는 구조로 구성이 가능하며 JDK(Java Development Kit)에 포함하고 있는 JRE(Java Runtime Environment)만 가지고도 실행이 가능합니다.

 

 

2.  What is Springboot ? 

 

 

 

---

스프링의 경량화 버전 

하지만 훨씬 기능과 사용 방법은 더 좋음 

• 사용자가 일일히 모든 설정을 직접 하지 않도록, 많이 쓰이는 dependency설정을 최초 빌드시 UI로 제공해준다.( 빌드 후 필요시 설정들을 직접 바꿔 줄 수 있다.)

 

해당 https://start.spring.io/ 링크에 접속하여 project를 빌드한다. Dependency를 UI에서 바로 세팅이 가능하다.

• 기존 스프링의 개발환경 세팅이 복잡하였던것과 비교하여 세팅이 굉장히 간편하여 진입장벽을 최소화 하는 역할을 한다.
• 의존성 주입이 간편하다. @Autowired 어노테이션을 사용해 Bean 등록 절차가 없다. ( 이 부분을 스프링부트의 마법이라 부른다.)

##application.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
    <context:component-scan base-package="com.springstudy.springapplicationcontext"/>
    <!--Spring 2.5부터 가능했던 기능으로 bask-package에서부터 @Component 혹은 Component를 상속받은 -->
    <!--Repository, Service 등의 어노테이션을 찾아 빈으로 등록한다.-->
</beans>

• 독립적으로 실행가능 ( JAR )
  웹 프로젝트라면 war파일로 패키징 해야하는데 스프링 부트는 내장 톰캣을 지원하기 때문에 jar 파일로 패키징해서 웹 애플리케이션을 실행시킬 수 있다 , 다시 말하면 JDK만 설치되면 WAS 서버 설치 필요없이 구동시킬수 있다

 

---

3. Kubernetes , Spring-Cloud

 

이제 Spring cloud에 대해서 알아보도록 하겠다.

 

 물론 파이썬의 장고, Flask 프레임워크를 이용해서 MSA 아키텍처를 구현할수 있다. 아래링크를 참고하길 바란다. 하지만, 국내 개발자의 70% 이상이 자바 스프링 개발자이고, MSA 아키텍처 중 가장 발달된 아키텍처가 스프링에서 만든 아키텍처라면 당신은 어떤 프레임워크를 사용하겠는가?

https://themapisto.tistory.com/167

[MSA 1.0] 컨테이너를 활용한 MSA 개발

 

필자는 kubernetes와 docker를 3년전에 제일 먼저 배웠다. 그리고 작년까지만 해도 Spring Cloud라는 개념에 대해서 들어본적이 없었다. 당시 매체와 유명 CSP 에서는 쿠버네티스에 대해서만 항상 다뤘다. 그렇지만 작년에 Tanzu Application Service(TAS)를 유지보수 하면서 처음으로 Spring Cloud에 대해서 듣게 되었다.  TAS에는 spring cloud 의 흔적들이 굉장히 많이 남겨져 있다. Eureka, Config 서버를 포함하고 있는 Spring Cloud Services for VMware Tanzu 부터 Spring Cloud Gateway 등 MSA에 필요한 구성요소들이 TAS 내부에 녹아들어져 있는것을 확인할수 있다.

 

 

TAS에 녹아들어있던 Spring Cloud를 쿠버네티스에서도 사용할수 있다. 아래 링크를 확인해보길 바란다.

https://themapisto.tistory.com/171

Spring Cloud는 MSA에 필요한 여러가지 기능들을 스프링부트의 dependency를 통해 제공한다. 핵심 기능을 위주로 살펴보도록 하자.

 

---

 

3-1. 서비스 Discovery ( Eureka)

 

서비스 Discovery ( Eureka )

클라우드에서 애플리케이션은 항상 다른 서비스의 정확한 위치를 알 수 없습니다.  컨테이너는 지속적으로 생성되고 사라지며 동일한 엔드포인트를 유지하고 있지 않기 때문입니다. Eureka 서버는 Eureka Client들의 접속정보를 지속적으로 전달 받습니다. Eureka 서버에 접속정보를 저장하는 것이 아니라, Client 서버들에 dependency를 통해 지속적으로 자신의 위치를 Eureka 서버에 전달합니다. Eureka는 일종의 전화번호부 역할을 하는 컴포넌트 입니다. 디테일한 내용은 다음 포스팅을 참고해주시기 바랍니다. https://themapisto.tistory.com/171

 

유레카 서버에 service1, service31, gateway서버등이 등록되어 있는것을 확인할수 있다.

 

---

3-2. Config 서버 (Spring Cloud Config)

 

• 클라우드에서 config는  단순히 애플리케이션 내부에 내장될 수 없습니다. 
• config 는 다운타임 없이 동적 변경을 처리할 수 있을 만큼 충분히 유연해야 합니다.
• Git과 같은 버전 제어 시스템과의 통합을 제공하여 구성을 안전하게 유지하는 데 도움이 됩니다.

 

 

Spring Cloud Config 서버 어떻게 사용할까?

1. Spring initialzr을 통해 Config server을 배포한다. 2. Config server에는 config를 저장해둘 git repository 경로를 적어주는 것 말고는 설정이 따로 없다. 3. Config server로 부터 config를 받을 client 서버를 준비한다. 4. 해당 서버에는 profile만 설정해주면 간편하게 설정이 가능하다. ( 깃에 저장해둔 yml 파일의 제목을 보고 profile과 application name을 인식한다.) 5. 동적 config 수정이 가능하게 @Refreshscope 어노테이션을 이용한다. 6. localhost:8089/actuator/refresh로 post 요청을 통해 서버 재기동 없이 config를 refresh 할수 있다.

 

---

3-3. API Gateway ( Spring Cloud Gateway )

누군가가 이런 이야기를 한적이 있다. 진정한 MSA는 API Gateway를 쓰지 않는것이라고. 
또 누군가는 이런 이야기를 한다. API Gateway와 Ingress gateway가 똑같은것이라고.
참 멍청한 이야기를 자신 있게도 한다. 무식하면 용감하다.

 

2년전에 이런 블로그를 본적이 있다.  (https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/) 

이 블로그를 보고 Istio in action이라는 책을 사서 읽어보았다.

요약하면, API gateway는 외부에서 들어오는 트래픽에 대한 제어, 즉 North-South 트래픽 제어를 담당한다. 반면 서비스 메쉬는 서비스 간의 통신, East-West 트래픽을 위한 것이다.

하지만 ServiceMesh중 더러 ingress gateway를 포함하고 있는 녀석들이 종종 있다. (  like istio ) 그래서 사람들이 굉장히 헷갈려 한다. 둘이 같은건가? 반은 맞고 반은 틀렸다. 

사실 서비스메시가 외부의 트래픽에 대한 제어를 일부 담당하긴 한다. 공통적으로 API gateway와 Service Mesh가 하는 일들이 중복되기 때문에 사람들은 왜 API gateway가 필요한지 모른다. 하지만 책에는 중복되는 기능들이 있지만, 전혀 다른일을 하는 영역도 있다고 한다.

공통적으로 하는 일

분산추적 서비스 검색 부하분산 TLS termination JWT 유효성 검사 요청 라우팅 트래픽 분할 카나리 배포 트래픽 미러링 Rate limiting

 

API gateway 만이 하는 일

1.  Edge Decoupling  요청/응답 변환, REST/SOAP/XSLT와 같은 프로토콜 변환, 오류/속도 제한에 따른 응답 사용자 지정, 자체적으로 직접 응답, API 그룹화 등이 여기에 포함된다. 요청/응답 변환: 실제 백엔드 API가 구현되어 있는 세부 정보가 노출되지 않게 하기 위해 Request를 변경, 헤더 제거/추가, 헤더를 페이로드로 옮기거나 등등을 할 수 있다. 애플리케이션 프로토콜 변환: 많은 어플리케이션들은 XML, JSON 등 다양한 방식으로 소통한다. 상호운용성을 확보하기 위해 프로토콜 변환 과정이 필요할 수 있다. 오류/속도 제한에 대한 응답 사용자 지정: 게이트웨이 자체에서 응답을 보내는 경우 이를 커스터마이즈 할 수 있어야 한다.  직접 응답: 클라이언트가 이용이 불가능한 자원을 요청하거나 어떤 이유로 업스트림이 차단된 경우, 프록시를 종료하고 사전 통제된 응답으로 대응할 수 있어야 한다. 프록시 파이프라인에 대한 제어: API GW는 세부 기능이 적용되는 순서 (Rate limit, Auth, 라우팅, 요청 변환 등)를 변경할 수 있어야 한다. 또한 상황이 잘못되었을 경우 디버깅할 수 있는 방법을 제공할 수 있어야 한다. API 구성/그룹화: 여러 API를 단일 API로 마스킹해야 하는 경우도 생긴다. GraphQL 같은 것들이 그 예가 될 수 있다. 실제로 1,2번은 현업에서 보안성검토 할 때 굉장히 자주 나오는 요구사항이다. 헤더 값을 200으로 통일해달라는 https://themapisto.tistory.com/37 과 같은 요구사항이 있을수 있다. 2. request Control 어떤 데이터와 요청, 응답이 허용되는지 관리하는 것 역시 API GW의 큰 역할이다. 게이트웨이는 아키텍처에 들어오는 요청이나 나가는 응답을 깊이 이해할 필요가 있다. SQL Injection 같은 것이 예가 될 수 있다. https://themapisto.tistory.com/23 이런 기능은 단순히 클러스터에 HTTP 트래픽을 허용하는 것과는 다르다. 3. Custom security / bridging trust domains 마지막으로 API gateway의 꽃은 edge security , 즉 어플리케이션에 대한 인증,인가 관리에 대한 포인트이다. 제발, istio에도 인증,인가가 있다고 박박 우기지 말라. 그것은 시스템에 들어오는 트래픽에 대한 권한에 대한 이야기다. RBAC과 어플리케이션 레벨의 인증,인가 관리에 대해 헷갈리지 말자. 또한, 이러한 인증,인가에 대한 관리는 OpenID Connect를 포함한 OAuth/SSO와의 통합이 얼마나 잘되어있냐의 문제이다. 이러한 인증, 인가 관리를 자체 개발하는 회사는 크게 많지 않다. 이미 유려하게 개발해논 인증 인가 관리 솔루션들이 Google,Naver,KaKao 와 같은 회사들의 로그인 알고리즘을 사용하는 경우가 더 많다. API GW는 자체로 사용자 정의를 할 수 있는 것 뿐 ( 직접 회사에서 로그인 알고리즘을 개발 ) 아니라 이런 환경에 유연하게 적응할 수 있는 방법(Spring Security와 같은 인증인가 솔루션 )을 갖추고 있어야 한다.

스프링 시큐리티는 스프링 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크입니다

 

결론적으로 모든 아키텍처가 그러하지만, 사용자의 요구사항에 따라 API GW를 사용할 것인지, Ingress Controller을 사용할 것인지 선택 하는 것이다. 그러나 역할 자체는 상당히 다르기 때문에 함께 사용을 고려해봐야 할수도 있다. 서론이 너무 길었다.

다시 본론으로 돌아와, Spring Cloud Gateway에 대한 설명으로 돌아가보자.

API Gateway는 사실상 관문과 같은 역할을 한다. 

따라서 모든 어플리케이션으로 가는 경로에는 관문을 거치고 가지 않는 경우가 없다. 따라서 인증과 인가와 같은 항상 공통적으로 처리해야 되는 로직들을 관문에 준비한다. 또한 추가적으로, 

속도제어, 서킷브레이커, 모니터링등 여러 공동 모듈 및 관리포인트들을 추가하여 모든 API들의 관문(GATEWAY)의 역할을 할수 있다.

실제적인 사용사례

각각의 서버들에 Request를 보낼 때 인증을 거쳐야 하는데, 마이크로서비스가 늘어날수록 서비스의 수 만큼 인증을 받아야 하는 번거로움이 있다 , 인증을 위해 반복되는 작업을 줄여주고, 한번의 인증으로 여러서비스를 한번에 사용 할 수 있도록 도와주는 역할을 한다. URI에 따라 서비스 엔드포인트를 다르게 가져가는 동적 라우팅이 가능해진다. 예를 들면 도메인 변경없이 레거시 시스템을 신규 시스템으로 점진적으로 마이그레이션 해나가는 작업을 쉽게 진행할 수 있다.  모든 트래픽이 통하기 때문에 모니터링 시스템 구성이 편리하다. 또한 Spring Cloud에서 제공하는 Zipkin, Sleuth를 dependency로 추가하여 사용할수 있다.  동적 라우팅이 가능하므로 신규 기능을 서비스 일부에만 적용하거나 트래픽을 점진적으로 늘려나가는 테스트를 수행하기에 수월해진다.

 

https://themapisto.tistory.com/180 다음 포스팅을 통해 구현하는 디테일한 모습을 확인해 볼수 있다.

---

결론:  Spring Cloud 없이 MSA 개발은 쉽지 않을것 같다.

이렇게 Spring / Springboot / Spring cloud 에 대해서 요약 정리 해보았다. 
개인적으로 MSA 아키텍처로 어플리케이션을 개발 할때 파이썬도 해보고 Spring Cloud도 사용해 봤지만 역시 익숙한게 훨씬 이해도 잘되고 재미도 있었던것 같다. 
개발에 대해서 잘 모르는 나도 이정도로 느꼈는데,, 실제 Spring 개발을 하고 있는 개발자들에게 Python으로 개발하는게 훨씬 좋으니 이걸로 개발하세요 라고 강요할수 있을까? 
절대 아니라고 본다. 그래서 국내 정서상 스프링을 탈피 한다는 것은 내 인생에서는 없을것 같다.
물론, 나는 여러 언어를 공부해서 비교해보겠지만~