Ch.10 Spring Cloud

Spring Cloud

Spring Cloud Project란?

프로젝트 살펴보기

Service Registry: 서비스들에 대한 정보가 적재되어 있는 레지스트리. 일반적으로 소프트웨어 형태로 제공됨

Client가 어떤 서비스로 요청을 보내야 하는데, 어디로 요청을 보내야 하는지 알아내는 방법이 크게 2가지 있음

• 어디로 가야 하는지를 서비스 레지스트리에 물어보는 형태
  • 서비스 레지스트리에 요청을 보내고, 그에 따라서 어떤 서비스로 요청 보내야 할지를 판단하는 방식
  • client side service discovery
• 클라이언트와 서비스 사이에 로드 밸런서가 존재해서, 클라이언트가 로드밸런서로 요청을 보냄
  • 로드밸런서가 서비스 레지스트리에 실제 요청을 보내고자 하는 서비스의 위치를 파악한 후
  • 요청에 따라 해당 서비스로 요청을 분산시켜줌
  • server side service discovery

클라이언트 브라우저가 모든 서비스들에 따로 요청하고 정리해서 페이지를 작성하는 것은 데이터 관리가 어렵고, 위치 관리를 하기 위해 클라이언트에서 계속 수정이 필요함

이를 보완(?)하기 위해 API Gateway Pattern 개념이 등장

클라이언트에서는 API Gateway에만 요청을 보내고, 정확히 어디(어느 엔드포인트)에 요청을 보내야 할지 알 필요가 없음. (하나의 endpoint(API Gateway)만 기억하고 있어도 됨)

Spring Cloud에서는 API Gateway Pattern을 Spring Cloud Gateway라는 라이브러리에서 지원

Spring Boot 어플리케이션을 실행할 때 실행 인자로 설정 파일을 전달하거나 환경변수를 설정하거나 파일 위치를 지정해줌으로써 실행 당시에 바로 (여러개의 설정 파일 중 원하는) 설정을 새로 로드할 수 있는 좋은(효율적인) 기능이 있으나, 클라우드 환경에서는 문제가 발생할 수 있음

클라우드 환경에서는 설정이 변동될 가능성이 있는 서비스가 많으며, 각 서비스의 위치가 별개로 존재하기 때문에 이 때마다 설정이 바뀌어야 한다는 문제가 있음.

이를 보완하기 위해 Spring Cloud Project의 하위 프로젝트 중 하나는 설정 관리자 서버를 두는 것을 제안함.

설정 관리자가 어플리케이션과 다른 여러 스프링부트 어플리케이션에서 사용할 설정 파일들을 관리하는 서버의 역할을 하고, 해당 설정 관리자가 존재하는 한 클라우드 환경에서 새로운 어플리케이션이 실행되었을 때, 설정 관리자에게서 자신이 어떤 설정을 사용해야하는지에 대한 질의를 통해 설정을 받아오는 기능을 제공.

 

 

---

Microservice Architecture

MSA 개요

1~4: 전통적인 개발 (Monolithic Architecture)의 장점

산출물이 한가지: jar파일 하나라는 뜻

4. 사용자의 증가에 따른 사용량 허용치의 증가가 편리 - 확장성 편리

Microservice Architecture: 큰 서비스가 아닌, 서로 다른 작은 서비스들이 상호작용을 할 수 있도록 만드는 것

 

MSA를 하는 이유

하지 말아야 할 이유

• 분산된 시스템이기 때문에 여러개의 컴퓨터가 네트워크를 통해 상호작용함 -> 서로 분리된 서비스이기 때문에 네트워크의 영향을 받음 (딜레이, 통신 두절로 인한 데이터 손실 등)
• 서로 다른 서비스의 기능을 요구할 때, 기능 구현 및 테스트가 어려움
  • 예시) 버스 노선 서비스와 지하철 노선 서비스를 기반으로 한 길 찾기 서비스를 만들 경우, 버스 노선 서비스와 지하철 노선 서비스가 모두 정상적으로 작동하고 있는 상태에서만 길 찾기 서비스가 정상적으로 작동하는 지 확인 가능
  • 서로 상호작용하는 부분부터 구현해야 하기 때문에 구현의 난이도가 올라감
• 자신이 필요로 하는 서비스의 상태를 확인하기 어려움
  • 1번 단점의 연장선
  • 기본적으로 서비스 자기 자신에 대해서만 신경쓰기 때문에, 다른 서비스의 상태를 알기 어려움
  • 이로 인해 등장한 개념이 Service Discovery
• 배포 과정이 더 복잡함
  • 여러 개의 컴퓨터에 걸쳐 여러 개의 서비스를 배포할 때, 작은 서비스들이 늘어날수록 서로 다른 배포 방법, 배포 지역, 같은 컴퓨터 내에서 배포했을 때 충돌하지 않아야 하는 점 등 하나의 큰 서비스에 비해 배포 과정이 복잡함

MSA를 하는 이유

기술의 혼재성: 서비스들간의 통신을 통해 서비스를 제공하기 때문에 여러가지 기술들을 섞어서 사용하더라도 문제가 없음

기능이 개별적으로 발전, 개별 배포 용이

개별 서비스의 복잡성이 적어짐

---

Spring Cloud Gateway

Gateway 기능

Routing: API Gateway가 클라이언트의 요청을 다른 하위 microservice로 요청을 전달하는 것

Routing을 잘 하면 클라이언트는 게이트웨이와만 소통하므로, 뒤쪽은 고려할 필요가 없음

AOP는 횡단 관점에서 생기는 문제를 처리하기 위한 기술 스택 중 하나 (AOP, Interceptor, Filter)

microservice architecture에서도 위 예시의 로깅, 인증과 같은 횡단 관점을 각각의 서비스에서 공유함

서비스들 간의 횡단 관점(관심사)를 API Gateway에서 Filter를 통해 구현

 

1급함수?

predicate: 자바에서 함수형 프로그래밍을 할 때 참/거짓을 돌려주는 함수. 예제의 경우 요청을 받은 경로가 내가 루팅을 진행해야 하는 경로인지 아닌지를 정의해야 함.

 

 

---

Spring Cloud Config

Config 기능

설정 파일을 외부, 중앙에서 관리

Config-Server: 스프링부트의 설정파일들을 실행할 때 중앙에서 설정 파일들을 모아놓고, 클라이언트가 필요로 하는 설정 파일들을 가져갈 수 있도록 도와주는 것

설정 파일을 보관하는 방법: 서버 안에 저장 (특정 폴더에 설정 파일 보관), Git 원격 저장소에 저장 등

Config-Server와 Actuator의 도움이 있으면 실시간으로 살아 있는 어플리케이션의 설정 파일을 바꿀 수 있음

설정 파일이 바뀌었을 경우 Config-Server는 이 사실을 알고 있음. gateway server는 아직 이 사실을 알지 못하지만, 새로운 설정이 존재하는지에 대해 요청을 보낼 수 있음 (/actuator/refresh로 post요청이 들어가면 gateway가 그 시점에서 config 서버에 새로운 파일이 존재하는지 질의하고, config server는 새로운 설정파일을 gateway에 돌려줌. gateway는 그 시점에서 새로운 설정 파일을 자신에게 적용함)

config-server가 설정 파일이 변하는 시점을 언제 알게 되는가? 새로운 요청이 들어왔을 때 (설정 파일이 바뀌자 마자 알게 되는 것이 아님)

완전 자동화 가능

1. 새로운 설정 파일을 깃헙에 푸시

2. 깃헙 내부에서 WebHook으로 config-server에 요청을 보냄

3. config-server에서 요청을 받고, 메시지큐를 사용해서 이벤트에 대해 모든 서비스들에 동시 다발적으로 메시지를 보냄

4. 서비스들이 config-server로 새로운 설정 파일을 달라는 요청을 보냄

 

자신의 local directory에 있는 설정 파일들을 모아서 가져오는 방법 2가지

1. Native profile

• 이미 설정되어 있는 프로파일.
• 내부적으로 설정되어 있어서 네이티브 프로파일을 사용하면 파일 시스템 (컴퓨터 안에 있는 파일) 을 가지고 config-server 구성 가능
• search-locations: 기본적으로는 classpath가 들어감(resource 폴더부터 시작). 수동으로 어떤 경로에 있는 파일들을 읽을지 정의 가능

2. Git으로 관리되는 local directory 설정