포스트

01.Spring Cloud

Spring Cloud

  • Spring Cloud는 MSA에 필요한 여러가지 기능들을 스프링부트의 dependency를 통해 제공한다.
  1. 서비스 Discovery(Eureka)
    • 클라우드에서 애플리케이션은 항상 다른 서비스의 정확한 위치를 알 수 없다
    • 컨테이너는 지속적으로 생성되고 사라지기 때문에 동일한 엔드포인트를 유지하고 있지 않기 때문이다.
    • Eureka 서버는 Eureka Client들의 접속정보를 지속적으로 전달 받는다
    • Eureka 서버에 접속정보를 저장하는 것이 아니라, Client 서버들에 dependency를 통해 지속적으로 자신의 위치를 Eureka 서버에 전달한다.
    • 이것을 Heartbeat라고 하고 유레카 서버는 이것을 일정 시간마다 수신하여 클라이언트들이 작동 중임을 알게 된다.
    • Heartbeat가 오지 않는 경우 서버는 클라이언트가 죽었다고 판단하고, 해당 클라이언트의 정보를 삭제한다
  2. Config 서버(Spring Cloud Config)
    • 클라우데엇 config는 단순히 애플리케이션 내부에 내장될 수 없다
    • config는 다운타임 없이 동적 변경을 처리할 수 있을 만큼 충분히 유연해야 한다
    • Git과 같은 버전 제어 시스템과의 통합을 제공하여 구성을 안전하게 유지하는데 도움을 줄 수 있다
  3. 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 할수 있다.
  4. API Gateway(Spring Cloud Gateway)
    • API Gateway는 외부에서 들어오는 트래픽에 대한 제어를 한다(North-South 트래픽 제어)
    • 서비스 메쉬는 서비스 간의 통신을 제어한다(East-West 트랙픽 제어)
    • API Gateway와 서비스 메쉬가 하는 일이 중복되기도 한다
      • 분산추적
      • 서비스 검색
      • 부하분산
      • TS termination
      • JWT 유효성 검사
      • 요청 라우팅
      • 트래픽 분할
      • 카나리 배포
      • 트래픽 미러링
      • Rate limiting


  • API Gateway만이 하는 일
  1. Edge Decoupling
    • 요청/응답 변환
      • 실제 백엔드 API가 구현되어 있는 세부 정보가 노출되지 않게 하기 위해 Request를 변경, 헤더 제거/추가, 헤더를 페이로드로 옮기거나 등등을 할 수 있다. 보안상검토 시 자주 나오는 요구사항이다.
    • REST/SOAP/XSLT와 같은 프로토콜 변환
      • 많은 어플리케이션들은 XML, JSON 등 다양한 방식으로 소통한다. 상호운용성을 확보하기 위해 프로토콜 변환 과정이 필요 할 수 있다. 보안상검토 시 자주 나오는 요구사항이다.
    • 오류/속도 제한에 따른 응답 사용자 지정
      • 게이트웨이 자체에서 응답을 보내는 경우 이를 커스터마이즈 할 수 있어야 한다
    • 자체적으로 직접 응답
      • 클라이언트가 이용이 불가능한 자원을 요청하거나 어떤 이유로 업스트림이 차단된 경우, 프록시를 종료하고 사전 통제된 응답으로 대응할 수 있어야 한다
    • 프록시 파이프라인에 대한 제어
      • API GW는 세부 기능이 적용되는 순서(Rate limit, Auth, 라우팅, 요청 변환 등)를 변경할 수 있어야 한다. 또한 상황이 잘못되었을 경우 디버깅할 수 있는 방법을 제공할 수 있어야 한다
    • API 그룹화
      • 여러 API를 단일 API로 마스킹해야 하는 경우도 생긴다.
  2. Request Control
    • 어떤 데이터와 요청, 응답이 허용되는지 관리하는 것 역시 API GW의 큰 역할이다. GW는 아키텍처에 들어오는 요청이나 나가는 응답을 깊이 이해할 필요가 있다
    • SQL Injection 같은 것이 예가 될 수 있다
    • 이런 기능은 단순히 클러스터에 HTTP 트래픽을 허용하는 것과는 다르다
  3. Custom security / bridging trust domains
    • 마지막으로 API gateway의 꽃은 edge security, 즉 어플리케이션에 대한 인증, 인가 관리에 대한 포인트이다