728x90
팀 내에서 한 달에 한 번 팀원들이 돌아가면서 발표를 하는 테크톡을 진행한다
테크톡의 컨셉은 우아한형제들의 테코톡!
간단한 주제로 20분 내로 발표하고 큰 주제라면 마중물을 떠주는 느낌, 작은 주제라면 세부적인 스펙을 설명하는 느낌이다
올해는 나도 테크톡에 참여하여 발표를 하게 되었다!
이번 테크톡의 개략적인 주제는 JDK 버전별 특징, 스프링 생태계 요런 느낌!
그래서 나는 Spring Cloud로 주제를 잡았고 꽤나 큰 주제라 마중물을 뜨는 느낌으로 주요 아키텍처의 특징만 살펴보려고 한다
🧐 들어가기 전에..
클라우드 네이티브 애플리케이션
- 클라우드 컴퓨팅 환경에 최적화되어 설계, 개발, 배포되는 소프트웨어 애플리케이션
- 주요 특징
- 마이크로서비스 아키텍처 : 애플리케이션을 작은 단위의 마이크로서비스로 분리하여 개발하고 각각의 서비스는 독립적인 배포 및 확장이 가능하다
- 컨테이너화 : 애플리케이션을 컨테이너에 담아 배포하면 환경에 관계없이 동일한 동작을 보장할 수 있다. 또한 컨테이너는 가볍고 빠르게 배포가 가능하며 확장성도 높다
- 자동화 : 애플리케이션의 배포, 확장, 관리 등의 과정을 자동화하여 인프라 운영 비용을 줄이고 안정적인 서비스 운영이 가능하다
- 가상화 : 애플리케이션과 인프라를 분리하고 필요에 따라 자원을 할당 및 회수가 가능하다
- 12-Factors : SaaS 앱을 만들기 위한 방법론
- Codebase - 애플리케이션의 1개의 코드 베이스(git, svn)을 통해 관리되어야 하며, 동일한 코드로 운영/개발에 배포하여야 한다
- Dependencies - 애플리케이션의 모든 종속성을 명시적으로 선언하여 사용한다
- config - 모든 설정 정보는 코드로부터 분리된 공간에 저장되어야 하고, 런타임에서 코드에 의해 읽혀야 한다
- backing services - 백엔드 서비스를 연결된 리소스로 취급한다
- build, release, run - 코드 베이스는 build → release→ run 의 단계를 거쳐 배포되며, 각 단계는 엄격하게 분리되어야 한다
- processes - 실행 환경에서 앱은 하나 이상의 프로세스로 실행되며, 각 프로세스는 stateless로 아무것도 공유하지 않아야 한다
- port binding - 배포된 SaaS 애플리케이션을 타 애플리케이션에서 접근할 수 있도록 포트 바인딩을 통해 서비스를 공개한다
- concurrency - 앱은 수평으로 확장할 수 있어야 하고, process에 의해 동시성을 높일 수 있다
- disposability - 프로세스는 shut down 신호를 받았을 때 graceful shut down 해야 한다
- dev/prod parity - 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지한다
- logs - 로그를 이벤트 스트림으로 취급하여 로그를 로컬에 저장하지 않는다
- admin processes - admin/maintenance 작업을 일회성 프로세스로 실행해야 한다
Monolith vs MSA
| Monolith | MSA | |
| 설명 | 모든 서비스를 단일 애플리케이션에 통합 | 서비스를 작은 단위로 분리하여 독립적으로 배포하고 운영 |
| 배포 | 전체 배포 | 부분 배포 |
| 확장성 | 수직 확장(Scale-Up) | 수평 확장(Scale-Out) |
| 개발 방식 | 단일 코드 베이스 | 독립적인 코드 베이스 |
| 유지보수 | 전체 애플리케이션 수정 필요 | 각 서비스를 독립적으로 수정 가능 |
| 복잡성 | 쉬움 | 분산 시스템으로 인한 복잡성 |
| 데이터 관리 | 중앙 집중식 데이터 관리 | 서비스 간 데이터 공유의 어려움 |
| 장애 처리 | 전체 시스템 장애로 이어질 수 있다 | 일부 서비스만 영향을 받아 장애 전파 최소화 가능 |
전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환 | GeekNews
"Monolith > apps > services > microservices"첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음둘
news.hada.io
(재밌는 글이라 한번 퍼왔습니다ㅎㅎ)
Spring Boot vs Spring Cloud
- 둘 다 Spring framework 기반으로 개발되어 있지만 목적 및 기능 부분에 대해서 차이가 있다
- Spring Boot : 단일 어플리케이션 개발
- Spring Cloud : 분산 시스템의 개발 및 운영
- 즉, Spring Cloud 환경 아래 각각의 단일 어플리케이션은 Spring Boot를 이용하여 개발한다
| Spring Boot | Spring Cloud | |
| 장점 | 단일 서비스 개발을 위한 프레임워크 | 분산 시스템 개발을 위한 프레임워크 |
| 단점 | - 빠른 개발과 배포 - 간단한 설정 - Spring 기반으로 다양한 라이브러리 지원 |
- 분산 시스템 개발에 필요한 다양한 기능 제공 - 클라우드 네이티브 애플리케이션 개발에 적합 |
| 주요 모듈 | Spring MVC, Spring Data, Spring security, Spring Boot Actuator | Spring Cloud, Config, Discovery, Routing, Circuit Breaker, Messaging |
☁️ Spring Cloud
- Spring 기반의 클라우드 네이티브 어플리케이션을 개발하기 위한 프로젝트
- 분산 시스템에서 필요한 기능들을 추상화하여 제공하고 있으며, 마이크로서비스 아키텍처 구현 시에도 유용하게 사용된다
- Netflix OSS 프로젝트에서 시작되어 Eureka, Ribbon, Hystrix, Zuul 등 다양한 서비스를 포함하고 있다
1) Spring Cloud Config
- 설정 관리를 중앙에서 효과적으로 관리할 수 있게 해주는 서버
- 외부 구성 서버를 통한 설정의 중앙 집중 관리를 가능하게 하여 애플리케이션의 설정 및 버전 관리를 수행한다
- 각 마이크로서비스는 Config Server를 통해 자체적인 설정을 동적으로 가져올 수 있어 설정이 변경되어도 서버 재시작 없이 런타임 중에 적용할 수 있다 (= stateless)
- 설정 파일은 git, svn, 파일 시스템 등 다양한 저장소에 저장될 수 있다
- 동적으로 config 변경을 적용하기 위해서 Message Queue Handler인 Spring Cloud Bus를 이용한다
2) Service Discovery
- MSA에서 서비스들이 서로의 위치를 찾고 통신할 수 있도록 도와주는 서버
- 서비스 인스턴스의 등록과 검색을 담당하는 Service Registry를 구축하고 각 서비스의 위치를 동적으로 발견한다
- 클라이언트 요청이 Gateway로 들어오면, Gateway는 Service Discovery를 통해 요청의 실제 주소값을 반환받아 요청을 보낸다
- ex) Netflix Eureka, HashiCorp Consul, Zookeeper
주요 기능
- 각 마이크로서비스는 서비스 디스커버리에 자신의 정보(포트, 상태 정보 등)을 등록하고 이후 서비스에 인스턴스가 추가/제거될 때마다 자동으로 업데이트된다
- 마이크로서비스는 서비스 디스커버리를 통해 다른 서비스의 위치를 동적으로 검색할 수 있다
- 서비스 디스커버리는 서비스 인스턴스의 상태를 health check를 통해 확인하고, 비정상적인 인스턴스는 자동으로 등록 해제한다
3) API Gateway
- 클라이언트의 단일 진입점 역할을 하는 서버
- 클라이언트 요청을 수신하고 이를 적절한 마이크로서비스로 라우팅한다
- 이외에도 인증, 권한 부여, 로깅, 로드밸런싱, 캐싱 등 다양한 기능을 제공하여 클라이언트와 마이크로서비스 간의 통신을 단순화하고 보호한다
- Spring Cloud LoadBalancer와 통합되어 요청을 여러 인스턴스에 분산할 수 있다
- Spring Security와 통합되어 인증 및 인가를 처리하고, OAuth2.0과 같은 인증 프로토콜 적용도 가능하다
- ex) Spring Cloud Gateway, Netflix Zuul
4) Circuit Breaker
- 마이크로서비스 간 통신에서 실패를 방지하기 위해 서킷 브레이커 패턴을 사용한다
- 서비스 간 장애를 격리하고 서비스의 탄력성을 높여준다
- 문제가 있는 마이크로서비스로의 트래픽을 차단하여 전체 서비스가 느려지거나 중단되는 것을 미리 방지한다
- Consumer 서비스와 Producer 서비스 사이에 Circuit Breaker를 통해 통신하도록 연결하고, Producer가 일정 횟수 이상 비정상적인 응답을 주면 Circuit Breaker의 상태 변경을 통해 대상 서비스로의 통신을 차단한다
- ex) Hystrix, Resilience4J
5) Load Balancer
- 로드밸런서를 통해 서비스 요청을 여러 인스턴스에 분산하여 로드밸런싱을 수행한다
- API Gateway를 통해 들어온 요청을 Load Balancer를 통해 로드밸런싱 하거나 API Gateway 없이 대상 어플리케이션을 직접 로드밸런싱을 연결할 수 있다
- ex) Netflix Ribbon, Spring Cloud LoadBalancer
6) Distributed Tracing
- 분산 시스템에서의 트랜잭션 추적을 위한 기능
- MSA에서는 요청이 여러 서비스에 걸쳐 분산될 수 있는데, 각 요청의 트랙잭션을 추적하여 성능 문제를 분석하고 디버깅할 수 있다
- 추적 방법
- Sleuth를 적용하면 동일한 트랜잭션에 해당하는 트래픽들에 동일한 TraceID를 부여하여 로그에 자동으로 Trace 정보가 주입된다
- 이를 Zipkin과 같은 분산 트랜잭션 추적 시스템으로 송부하면 트래픽의 흐름을 볼 수 있다
- ex) Spring Cloud Sleuth, Zipkin
7) Testing
- MSA 환경에서 테스트를 위해 모든 마이크로서비스들을 배포하여 end-to-end 로 진행하려면 쉽지 않다
- 이를 위해 소비자의 요구사항을 중심으로 테스트를 하는 Contract-based testing을 지원한다
- producer에서 테스트 후에 생성된 Stub을 통해 테스트를 하기 때문에 Mock에 비해 정확하고 안정적이다
- 또한 Stub을 통해 테스트를 하기 때문에 서비스를 구동하지 않아도 가볍고 빠른 테스트가 가능하다
- 검증 과정
- consumer가 contract를 정의하고 producer에 제공하면 이를 바탕으로 API를 구현한다
- producer의 contract 구현이 완성되면 결과 stub을 저장소에 업로드한다
- consumer는 자신이 요청한 contract 기반으로 API를 개발하고 producer가 업로드한 stub을 기반으로 테스트를 진행한다
- 이를 통해 서비스 간의 계약(contract)을 정의하고 이를 기반으로 각 서비스의 요청과 응답을 검증할 수 있다
- Spring Cloud Contract는 Groovy, Java, Kotilin으로 작성된 메시지 기반의 REST API에 대해 contract-based 테스팅을 지원한다
😎 참고하면 좋은 내용
MSA <-> Spring Cloud 기술
| MSA | Spring Cloud & Netflix OSS |
| Configuration Management | Spring Config Server |
| Service Discovery | Netflix Eureka |
| Load Balancing | Netflix Ribbon, Spring Cloud LoadBalancer |
| API Gateway | Netflix Zuul, Spring Cloud Gateway |
| Service Security | Spring Cloud Security |
| Resilience & Fault Tolerance | Netflix Hystrix, Turbine & Ribbon |
- MSA 기능에 대응하는 Spring Cloud 기술들이다
Spring Cloud Netflix EOS (End Of Service)
| Current | Replacement |
| Hystrix | Resillience4j |
| Hystrix Dashboard / Turbine | Micrometer + Monitoring System |
| Ribbon | Spring Cloud LoadBalancer |
| Zuul1 | Spring Cloud Gateway |
| Archaius 1 | Spring Boot External Config + Spring Cloud Config |
- 2018년 12월부터 위의 컴포넌트들은 Maintenance 모드(기능 업그레이드 없이 유지)로 돌입
- 위는 Spring에서 제시한 EOS 컴포넌트에 대한 대체 도구들이다
- 참고) https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now
Spring Cloud Greenwich.RC1 available now
On behalf of the community, I am pleased to announce that the Release Candidate 1 (RC1) of the Spring Cloud Greenwich Release Train is available today. The release can be found in Spring Milestone repository. You can check out the Greenwich release notes f
spring.io
📚 Reference.
- https://spring.io/cloud
- https://djlife.tistory.com/10
- https://github.com/spring-cloud
- https://spring.io/projects/spring-cloud
- https://www.samsungsds.com/kr/insights/spring_cloud.html
- https://startupcloudplatform.github.io/cloud4dev-docs/msaspringcloud.html#%EC%8A%A4%ED%94%84%EB%A7%81%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%A0%81%EC%9A%A9-%EA%B0%80%EC%9D%B4%EB%93%9C
- https://happycloud-lee.tistory.com/216
- https://sjh9708.tistory.com/157#google_vignette
- https://spring.io/cloud
- https://adjh54.tistory.com/207
- https://clack2933.tistory.com/51
728x90
'야미스터디 > Spring' 카테고리의 다른 글
| 나는야 다국어 전문가(호소인)! - feat. Locale (3) | 2024.10.28 |
|---|---|
| [Spring] IoC, DI, AOP 📌 - 작성중 (0) | 2022.11.29 |
| [Spring] Swagger 📌 (0) | 2022.10.06 |
| [Spring] Dispatcher Servlet 📌 (0) | 2022.09.20 |
| [Spring] Spring vs EJB 📌 (1) | 2022.09.20 |
댓글