9/18

🔹 로드밸런싱이란?

• 네트워크 트래픽을 여러 서버로 분산시켜서 서버의 부하를 줄이는 역할을 한다
  → 시스템의 성능과 가용성을 높이는 기술

• 종류:

  • 클라이언트 사이드 로드 밸런싱
  • 서버 사이드 로드 밸런싱

이 중에서 나는 클라이언트 사이드의 로드 밸런싱을 해볼 것인데,

클라이언트 사이드 로드 밸런싱은 클라이언트가 직접 여러 서버 중 하나를 선택하여 요청을 보내는 방식을 말한다

---

🔹 Ribbon이란?

• 넷플릭스가 개발한 클라이언트 사이드 로드 밸런서
• 마이크로서비스 아키텍처에서 서비스 인스턴스 간의 부하를 분산하는 역할을 한다
• 다양한 로드 밸런싱 알고리즘을 지원한다
• Eureka와 같은 서비스 디스커버리와 연동하여 사용한다

🔸 Ribbon의 주요 동작 흐름

1. Eureka 등으로부터 서비스 인스턴스 리스트를 제공 받아 로드 밸런싱에 사용
2. 라운드 로빈, 가중치 기반 등의 다양한 로드 밸런싱 알고리즘을 지원
   (라운드 로빈: 각 서버에 순차적으로 요청을 분배하는 방식,
   가중치 기반: 각 서버에 가중치를 부여하고, 가중치에 비례하여 요청을 분배하는 방식)
3. 요청 실패 시 다른 인스턴스로 자동 전환 (Failover)

---

🔹 Spring Boot에서 FeignClient와 Ribbon 설정

• 필요 의존성 (build.gradle):

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
    implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
}

• Spring Boot 애플리케이션 설정 (@EnableFeignClients 어노테이션 필요):

@SpringBootApplication
@EnableFeignClients
public class MyServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyServiceApplication.class, args);
    }
}

---

🔹 동작 흐름 이해하기

FeignClient와 Ribbon의 동작 흐름을 이해하기 위한 예시:

1. 손님(클라이언트) → 콜센터(Eureka 등록된 서비스 목록 조회):

   손님이 “택시 불러줘”라고 요청한다.
   콜센터는 자기네 회사 소속 기사들 위치를 이미 알고 있다. (Eureka에 등록된 인스턴스 목록)

2. 콜센터 직원(FeignClient) → 기사 호출:

   손님이 말한 목적지를 기사에게 전달하려면 직원이 전화를 걸어야 한다.
   이때 직원이 바로 특정 기사에게 전화하는 게 아니라, “우리 시스템에 등록된 택시 기사 중 한 명을 골라서 연락해”라는 규칙(FeignClient)을 사용한다.

3. 콜센터 내 배차 시스템(Ribbon: 로드 밸런싱):

   직원은 “오늘은 1번 기사, 다음은 2번 기사, 그다음은 3번 기사…” 식으로 순차적으로 배차하는 규칙을 따른다. (라운드 로빈 알고리즘)
   만약 택시가 3대라면, 1번 → 2번 → 3번 → 다시 1번 이런 식으로 계속 반복된다.

4. 기사(서비스 인스턴스) → 손님 응답:

   선택된 기사가 손님을 태우러 간다.
   결과적으로 손님은 “택시가 왔다!”라는 응답을 받는다. (Order 서비스가 Product 서비스 응답을 받고 최종 클라이언트에 반환)

---

🔹 서킷브레이커란?

분산 시스템에서 특정 서비스가 계속 실패하면 호출을 차단하고, 일정 시간 동안 재시도를 멈추는 패턴을 말한다

• 왜 필요한가?
  MSA에서는 서비스들이 서로 네트워크를 통해 통신한다.
  그렇기 때문에 어떤 서비스가 장애가 나면, 그 서비스로 들어가는 요청이 계속 실패하면서 다른 서비스까지 연쇄적으로 장애를 일으킬 수 있다.

  예)

  • Order 서비스 → Payment 서비스 호출
  • Payment 서비스가 다운됨 → Order 서비스 요청 계속 대기
  • 결국 Order 서비스도 느려지고, API Gateway까지 병목 현상 발생
    ➡️ 결과적으로 전체 시스템 장애

이러한 연쇄 장애를 막기 위해 서킷브레이커를 쓴다.

• 서킷브레이커의 동작 원리 (3가지 상태):

1. Closed:
   정상 상태. 요청이 그대로 전달됨
   실패율이 낮으면 계속 Closed 유지
   
   
2. Open:
   실패율이 임계치 이상이면 차단기 열림
   요청이 바로 실패처리됨 (Fallback 로직 실행)
   장애 전파 차단
   
   
3. Half-Open:
   일정 시간 후 일부 요청만 보내서 테스트
   테스트 성공 시 → 다시 Closed로 전환
   테스트 실패 시 → 다시 Open 유지

---

🔹 API Gateway란?

• 클라이언트와 여러 개의 마이크로서비스(MSA) 사이에서 중간 진입점 (Front Door) 역할을 하는 서버나 서비스를 말한다.

쉽게 말해, 클라이언트가 각각의 서비스에 직접 접근하지 않고 API Gateway를 통해서만 접근하도록 만들어준다

• 주요 역할:

1. 단일 진입점 (Single Entry Point):

   클라이언트는 여러 서비스 주소를 몰라도 됨
   (/user, /order, /payment 요청을 모두 Gateway가 받아서 해당 서비스로 라우팅)

2. 요청 라우팅 (Routing):

   들어온 요청을 적절한 마이크로서비스로 전달
   URL 패턴, HTTP Method, 헤더 조건 등에 따라 분기

3. 인증/인가 (Authentication/Authorization):

   모든 요청을 Gateway에서 인증 처리 → 각 서비스는 인증 로직 단순화
   (JWT 토큰 검증, OAuth2 처리)

4. 부하 분산 (Load Balancing):

   특정 서비스에 인스턴스가 여러 개 있을 경우, 트래픽을 분산
   Ribbon, Spring Cloud LoadBalancer 같은 컴포넌트와 함께 동작

5. 보안 (Security):

   SSL/TLS 종단점 → 내부 서비스는 HTTPS 설정 없이도 안전
   Rate limiting(요청 제한), IP 차단 등도 적용 가능

6. 기타 기능:

   로깅 및 모니터링
   캐싱 (자주 요청되는 데이터 미리 저장)
   응답 변환 (JSON ↔ XML 변환 등)
   장애 처리 (Fallback, Circuit Breaker와 연계)

   
   

🔸 SSL/TLS란?

• SSL(Secure Sockets Layer) = 옛날 이름, TLS(Transport Layer Security) = 현재 표준
• SSL/TLS : 인터넷 통신을 암호화해서 안전하게 만드는 프로토콜
• 우리가 흔히 아는 http:// vs https:// 차이가 바로 TLS 적용 여부를 말한다.

HTTP + TLS = HTTPS

• HTTPS를 쓰면:
  • 암호화 (Encryption) → 주고받는 데이터가 노출되지 않음 (예: 비밀번호, 카드번호)
  • 무결성 (Integrity) → 중간에 데이터가 변조되지 않았음을 보장
  • 인증 (Authentication) → 접속한 서버가 진짜 서버인지(가짜 사이트 아님) 확인

🔸 Spring Cloud Gateway 예시

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://USER-SERVICE
          predicates:
            - Path=/users/**
        - id: order-service
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/orders/**

• /users/** 요청 → User Service로 전달
• /order/** 요청 → Order Service로 전달