[Project] Spring cloud

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

---

Spring Cloud란?

이번에 내가 스프링 클라우드를 공부하면서 느낀 점들을 정리해봤다. 사실 처음엔 복잡해 보였는데, 차근차근 정리하니까 생각보다 개념이 명확해져서 정리하면서 한 번 더 되새길 수 있었다.😂😂

스프링 클라우드는 마이크로서비스 아키텍처(MSA)를 구축할 때 유용한 툴과 라이브러리들을 제공해주는 프레임워크다. 여기서 각 서비스들은 서로 독립적으로 개발되고 배포되지만, 그들 간의 통신, 확장성, 장애 처리 등을 효과적으로 관리하기 위해 다양한 기능들을 제공하는데, 대표적으로 서비스 디스커버리, API Gateway, 분산 추적 등이 있다.

1. Eureka: 전화번호부 역할을 하는 컴포넌트

Eureka는 서비스 디스커버리의 중심이라고 보면 된다. 쉽게 말하면, 각 서비스가 어디에 있는지 알려주는 ‘전화번호부’ 역할을 하는 컴포넌트다. 각 마이크로서비스는 Eureka 서버에 자신을 등록하고, 다른 서비스들은 필요한 때에 이 Eureka 서버에서 그 위치 정보를 얻는다. 이렇게 함으로써 서비스 간 통신이 훨씬 수월해진다.

여기서 기억해야 할 건, 각 서비스가 Eureka 클라이언트로 설정돼 있으면, 주기적으로 자신의 상태와 위치(IP, 포트)를 Eureka 서버에 등록하고 갱신한다는 점이다.

---

2. API Gateway: 외부 트래픽의 관문

API Gateway는 외부에서 들어오는 모든 트래픽의 입구다. 흔히 North-South 트래픽을 제어한다고 표현하는데, 이는 외부에서 내부로, 혹은 내부에서 외부로 가는 트래픽을 말한다. 이와 반대로 서비스 간의 통신, 즉 East-West 트래픽은 주로 서비스 메쉬가 담당한다. 이 차이를 알고 있으면 헷갈리지 않을 수 있다.

---

3. API Gateway와 Service Mesh의 공통 기능

API Gateway와 서비스 메쉬는 몇 가지 공통된 기능을 제공한다

• Distributed Tracing
• Service Discovery
• Load Balancing
• TLS Termination
• JWT Validation
• Request Routing
• Traffic Splitting
• Canary Deployment
• Traffic Mirroring
• Rate Limiting

이처럼 여러 기능에서 겹치지만, 각각의 용도는 다르니까 상황에 맞게 선택해야 한다.

---

4. API Gateway만이 제공하는 기능

1. Edge Decoupling

   Edge Decoupling은 외부 요청과 내부 API 사이의 완충 역할을 한다고 보면 된다.

   여기서 API Gateway가 할 수 있는 일은 다음과 같다:

   • 요청/응답 변환
     • 외부로부터 오는 요청을 수정해서 백엔드의 세부 사항을 감출 수 있다. 예를 들어, 헤더를 추가하거나 제거하고, 페이로드 변환 등을 할 수 있다.
   • 애플리케이션 프로토콜 변환
     • XML, JSON 같은 서로 다른 프로토콜을 API Gateway가 알아서 변환해줄 수 있다.
   • 오류/속도 제한에 따른 응답 사용자 지정
     • 특정 에러가 발생했을 때나 트래픽이 너무 많아 속도 제한이 걸렸을 때, 게이트웨이가 자체적으로 응답을 커스터마이징할 수 있다.
   • 직접 응답
     • 클라이언트가 비정상적인 요청을 할 때, 백엔드에 가지 않고 API Gateway 자체에서 바로 응답을 줄 수 있다.
   • 프록시 파이프라인 제어
     • 요청 처리 순서를 바꾸거나, 디버깅 도구를 제공해서 복잡한 로직을 처리할 수 있다.
2. Request Control (요청 제어)
   • API Gateway는 클러스터로 들어오는 트래픽을 단순히 허용하는 게 아니라, 어떤 데이터와 요청/응답이 허용되는지를 세밀하게 제어한다.
   • 예를 들어, SQL Injection과 같은 공격을 막을 수 있다. 이걸 위해 API Gateway는 아키텍처에 들어오는 트래픽에 대한 깊은 이해가 필요하다.
3. Custom Security/Bridging Trust Domains
   • API Gateway의 꽃이라 할 수 있는 기능 중 하나가 바로 엣지 보안, 즉 인증과 인가 관리다.
   • 여기서 중요한 건 인증(Authentication)과 인가(Authorization)를 구분하는 것.

Service discovery

✔️ Service discovery는 MicroService Architecture에서 개별 서비스가 동적으로 위치한 주소나 포트 등을 찾을 수 있도록 하는 매커니즘

✔️ 마이크로서비스에서는 각 서비스가 독립적으로 배포되고 확장되기 때문에 서비스 간 통신을 위해서 서로의 위치를 알아야 하고, 이런 동적 환경에서 서비스가 어디에 위치하는지 알기 위해 서비스 디스커버리가 필요하다.

✔️ 주요 기능

1. Service Registry
   • Service Registry는 각 서비스의 위치 정보를 저장하고 관리하는 데이터베이스와 같은 역할을 한다.
   • Eureka, Consul, Zookeeper 같은 툴이 대표적인 서비스 레지스트리 역할을 수행
   • 서비스가 시작되면 자신을 서비스 레지스트리에 등록하고, 종료되면 제거 된다.
2. 서비스 등록
   • 서비스가 시작될 때, 서비스 레지스트리에 자신의 IP와 포트 정보를 등록하는 과정
   • 서비스 등록은 서비스가 직접 할 수도 있고, 이를 대신하는 로드 밸런서나 프록시가 처리할 수도 있다.
3. 서비스 조회
   • 클라이언트가 다른 서비스에 요청을 보내기 전에, 서비스 레지스트리에서 해당 서비스의 위치 정보를 조회하는 과정
   • 서비스 레지스트리는 서비스가 동작 중인지 여부와 관련된 상태 정보를 관리하며, 서비스가 중단되면 서비스 목록에서 제거한다.

✔️ 장점

• 동적 확장성
  • 서비스가 동적으로 생성되거나 종료될 때, 서비스 레지스트리가 이를 자동으로 반영하므로, 클러스터 내에서 쉽게 확장하거나 축소할 수 있다.
• 장애 복구
  • 서비스가 다운되거나 중단되면, 서비스 레지스트리가 해당 서비스를 목록에서 제거하여 요청이 실패하는 것을 방지할 수 있다.
• 유연한 로드 밸런싱
  • 클라이언트 또는 로드 밸런서가 여러 인스턴스 간에 로드를 분배하여 트래픽을 고르게 분산할 수 있다.
• 중앙화된 서비스 관리
  • 서비스 레지스트리를 통해 서비스 위치와 상태를 중앙에서 관리할 수 있어, 네트워크 환경이 동적이거나 복잡한 경우에도 효율적인 통신이 가능

✔️ Service Discovery tool

• Netflix Eureka: Netflix가 개발한 오픈 소스 서비스 레지스트리로, Spring Cloud에서 널리 사용
• HashiCorp Consul: 서비스 레지스트리와 함께 서비스 구성 관리, 보안 기능을 제공하는 툴.
• Apache Zookeeper: 분산 시스템을 위한 중앙화된 서비스 관리 툴로, 서비스 디스커버리에도 사용됨.

✔️ 서비스 디스커버리는 두 가지 패턴이 있는데 Client-side discovery와 Server-side discovery가 있다. 이건 아래에 따로 정리할 예정

Client-side discovery vs Server-side discovery

Service discovery 기능을 구현하는 방법으로는 크게 client discovery 방식과 server side discovery 방식이 있다.

Client-Side Discovery

• Client-Side Discovery에서는 클라이언트가 직접 서비스 레지스트리에서 서비스의 위치를 조회한 후, 해당 서비스로 요청을 보낸다.
• 서비스 레지스트리는 각 서비스의 인스턴스와 그 위치(IP 주소와 포트)를 알고 있는 역할을 한다.

---

1. 동작 방식:
   1. 서비스 인스턴스가 시작되면 서비스 레지스트리에 자신의 위치(IP, 포트)를 등록.
   2. 클라이언트가 서비스에 요청을 보내려고 할 때, 서비스 레지스트리에서 해당 서비스 인스턴스의 위치를 조회.
   3. 클라이언트가 선택한 서비스 인스턴스에 직접 요청을 전송.
   4. 클라이언트가 로드 밸런싱과 서비스 위치 조회를 자체적으로 처리.
2. 클라이언트 사이드 디스커버리의 구성 요소
   • Service Registry : Eureka, Consul, Zookeeper와 같은 시스템이 서비스 등록 및 조회를 담당.
   • 클라이언트: 직접 서비스 레지스트리에서 필요한 서비스를 찾고, 그 정보로 요청을 보냄.
   • Load Balancer: 클라이언트에서 로드 밸런싱을 수행 (예: Ribbon 라이브러리).
3. 예
   • Spring Cloud에서 Netflix Eureka를 사용한 클라이언트 사이드 디스커버리가 대표적

   • 클라이언트가 Eureka 서버에서 다른 서비스의 위치를 조회하고, 직접 선택한 인스턴스에 요청을 보내는 방식

       # 클라이언트는 서비스 레지스트리(Eureka)에서 서비스 위치를 조회 후 요청 전송
       Client --> Service Registry --> Selected Service
     

4. 장점
   • 단순한 인프라
     • 추가적인 로드 밸런서를 구축할 필요가 없다.
   • 클라이언트가 로드 밸런싱을 직접 처리
     • 클라이언트가 어떤 서비스 인스턴스에 요청할지 결정하므로, 로드 밸런싱 전략을 유연하게 적용 가능.
5. 단점
   • 클라이언트 복잡성 증가
     • 클라이언트가 서비스 위치 조회와 로드 밸런싱을 직접 처리해야 하기 때문에 클라이언트 로직이 복잡해질 수 있다.
   • 클라이언트 변경 필요
     • 서비스 디스커버리나 로드 밸런싱에 변화가 생기면 모든 클라이언트에 업데이트가 필요

Server-Side Discovery

• 서버 사이드 디스커버리에서는 클라이언트가 서비스에 요청을 보낼 때 로드 밸런서가 중간에서 요청을 받아 서비스 레지스트리를 조회하고, 적절한 서비스 인스턴스에 요청을 전달한다.
• 클라이언트는 로드 밸런서를 통해 모든 통신을 하고, 직접 서비스 위치를 찾지 않아도 된다.

---

1. 동작 방식
   1. 서비스 인스턴스가 시작되면 서비스 레지스트리에 자신의 위치를 등록.
   2. 클라이언트가 서비스에 요청을 보내면, 요청이 로드 밸런서로 전달.
   3. 로드 밸런서는 서비스 레지스트리에서 서비스 위치를 조회한 후, 적절한 서비스 인스턴스에 요청을 포워딩.
   4. 클라이언트는 실제 서비스 위치를 알지 못한 채 로드 밸런서를 통해 통신.
2. 서버 사이드 디스커버리의 구성 요소
   • Service Registry
     • Eureka, Consul, Zookeeper 등과 같은 레지스트리가 각 서비스의 위치 정보를 관리.
   • Load Balancer
     • HAProxy, AWS Elastic Load Balancer, NGINX 등과 같은 로드 밸런서가 클라이언트 요청을 받아 적절한 서비스로 전달.
3. 예
   • AWS에서 제공하는 Elastic Load Balancer (ELB)나 NGINX는 서버 사이드 디스커버리의 대표적인 사례

   • 클라이언트가 로드 밸런서로 요청을 보내면, 로드 밸런서가 서비스 레지스트리에서 서비스를 조회하고 적절한 서비스 인스턴스에 요청을 전달하는 방식

       # 클라이언트는 로드 밸런서에 요청을 보내고, 로드 밸런서가 서비스 레지스트리에서 조회
       Client --> Load Balancer --> Service Registry --> Selected Service
     

4. 장점
   • 클라이언트 단순화
     • 클라이언트는 로드 밸런서에게 요청만 보내면 되므로, 서비스 위치 조회와 로드 밸런싱에 대해 신경 쓸 필요가 없다
   • 로드 밸런서에서 중앙화된 관리
     • 로드 밸런서가 모든 서비스 위치 조회와 로드 밸런싱을 관리하므로, 변경 사항을 쉽게 적용 가능.
   • 확장성: 여러 클라이언트가 있을 때 로드 밸런서에서 일관되게 요청을 처리할 수 있다.
5. 단점
   • 로드 밸런서 추가 필요
     • 로드 밸런서를 별도로 설정하고 관리해야 하므로 인프라가 복잡해질 수 있어.
   • 추가 네트워크 홉
     • 클라이언트 요청이 로드 밸런서를 거쳐야 하므로, 네트워크 지연이 생길 수 있어.

---

참고 사이트

https://themapisto.tistory.com/23

https://themapisto.tistory.com/186

Project 카테고리 내 다른 글 보러가기