01.Spring Cloud
Spring Cloud
- Spring Cloud는 MSA에 필요한 여러가지 기능들을 스프링부트의 dependency를 통해 제공한다.
- 서비스 Discovery(Eureka)
- 클라우드에서 애플리케이션은 항상 다른 서비스의 정확한 위치를 알 수 없다
- 컨테이너는 지속적으로 생성되고 사라지기 때문에 동일한 엔드포인트를 유지하고 있지 않기 때문이다.
- Eureka 서버는 Eureka Client들의 접속정보를 지속적으로 전달 받는다
- Eureka 서버에 접속정보를 저장하는 것이 아니라, Client 서버들에 dependency를 통해 지속적으로 자신의 위치를 Eureka 서버에 전달한다.
- 이것을 Heartbeat라고 하고 유레카 서버는 이것을 일정 시간마다 수신하여 클라이언트들이 작동 중임을 알게 된다.
- Heartbeat가 오지 않는 경우 서버는 클라이언트가 죽었다고 판단하고, 해당 클라이언트의 정보를 삭제한다
- Config 서버(Spring Cloud Config)
- 클라우데엇 config는 단순히 애플리케이션 내부에 내장될 수 없다
- config는 다운타임 없이 동적 변경을 처리할 수 있을 만큼 충분히 유연해야 한다
- Git과 같은 버전 제어 시스템과의 통합을 제공하여 구성을 안전하게 유지하는데 도움을 줄 수 있다
- Spring Cloud Config
- Spring initializer를 통해 Config server을 배포한다
- Config server에는 config를 저장해둘 git repository 경로를 적어주는 것 말고는 설정이 따로 없다
- Config server로 부터 config를 받을 client 서버를 준비한다.
- 해당 서버에는 profile만 설정해주면 간편하게 설정이 가능하다.(git에 저장해둔 yml 파일의 제목을 보고 profile과 application name을 인식한다)
- 동적 config 수정이 가능하게 @Refreshscope 어노테이션을 이용한다
- localhost:8089/actuator/refresh로 post 요청을 통해 서버 재기동 없이 config를 refresh 할수 있다.
- API Gateway(Spring Cloud Gateway)
- API Gateway는 외부에서 들어오는 트래픽에 대한 제어를 한다(North-South 트래픽 제어)
- 서비스 메쉬는 서비스 간의 통신을 제어한다(East-West 트랙픽 제어)
- API Gateway와 서비스 메쉬가 하는 일이 중복되기도 한다
- 분산추적
- 서비스 검색
- 부하분산
- TS termination
- JWT 유효성 검사
- 요청 라우팅
- 트래픽 분할
- 카나리 배포
- 트래픽 미러링
- Rate limiting
- API Gateway만이 하는 일
- Edge Decoupling
- 요청/응답 변환
- 실제 백엔드 API가 구현되어 있는 세부 정보가 노출되지 않게 하기 위해 Request를 변경, 헤더 제거/추가, 헤더를 페이로드로 옮기거나 등등을 할 수 있다. 보안상검토 시 자주 나오는 요구사항이다.
- REST/SOAP/XSLT와 같은 프로토콜 변환
- 많은 어플리케이션들은 XML, JSON 등 다양한 방식으로 소통한다. 상호운용성을 확보하기 위해 프로토콜 변환 과정이 필요 할 수 있다. 보안상검토 시 자주 나오는 요구사항이다.
- 오류/속도 제한에 따른 응답 사용자 지정
- 게이트웨이 자체에서 응답을 보내는 경우 이를 커스터마이즈 할 수 있어야 한다
- 자체적으로 직접 응답
- 클라이언트가 이용이 불가능한 자원을 요청하거나 어떤 이유로 업스트림이 차단된 경우, 프록시를 종료하고 사전 통제된 응답으로 대응할 수 있어야 한다
- 프록시 파이프라인에 대한 제어
- API GW는 세부 기능이 적용되는 순서(Rate limit, Auth, 라우팅, 요청 변환 등)를 변경할 수 있어야 한다. 또한 상황이 잘못되었을 경우 디버깅할 수 있는 방법을 제공할 수 있어야 한다
- API 그룹화
- 여러 API를 단일 API로 마스킹해야 하는 경우도 생긴다.
- 요청/응답 변환
- Request Control
- 어떤 데이터와 요청, 응답이 허용되는지 관리하는 것 역시 API GW의 큰 역할이다. GW는 아키텍처에 들어오는 요청이나 나가는 응답을 깊이 이해할 필요가 있다
- SQL Injection 같은 것이 예가 될 수 있다
- 이런 기능은 단순히 클러스터에 HTTP 트래픽을 허용하는 것과는 다르다
- Custom security / bridging trust domains
- 마지막으로 API gateway의 꽃은 edge security, 즉 어플리케이션에 대한 인증, 인가 관리에 대한 포인트이다