[버티] 버티 서비스를 위한 Spring Boot MSA 구현 방식 조사

in ProjectDiary

Spring Boot MSA 구현 방식 조사

현재 버티 서비스는 백엔드 서버의 도메인이 2개로 되어있다. 프론트와 연동을 하기 직전 과정에서 CORS 문제 해결과 이 과정에서 Render배포의 리소스 제약 문제를 어떤 식으로 해결하는 것이 좋은지 아래 내용과 같이 조사해보았다.

1. 현재 버티 서비스 상황 분석

  • 서버 구조: 서버 도메인 URL이 2개 (회원 정보는 한쪽에만 존재)
  • 프론트엔드: 도메인 URL이 1개
  • 인증 방식: JWT 기반 인증 구현 중
  • 문제점:
    • 사용자 프로필 업데이트 기능이 있어 JWT에 프로필 정보 포함 어려움
    • 프론트엔드와 백엔드 간 CORS 이슈 발생 가능
    • Render 프리티어 환경으로 리소스 제약 존재

2. MSA 구현 방안

2.1 API Gateway 패턴 도입

  • 목적: 프론트엔드에 단일 진입점 제공, CORS 문제 해결
  • 구현 방식: Spring Cloud Gateway 활용
  • 장점:
    • 단일 도메인으로 프론트엔드 요청 처리
    • 중앙화된 인증/인가 처리
    • 요청 라우팅 관리 용이

2.2 회원 정보 공유 방식

현재 버티 서비스는 JWT에 프로필 정보를 포함하기 어려운 상황이므로: (로그인 후 사용자 프로필을 업데이트 하기 때문)

서비스 간 직접 통신 방식

  • 기본 개념: 회원 정보가 필요할 때 회원 서비스의 API를 직접 호출하여 최신 정보를 가져오는 방식
  • 구현 내용:
    • 회원 서비스에 내부용 API 엔드포인트 추가 (예: /api/internal/users/{userId})
    • 이 API는 외부 접근이 아닌 서비스 간 통신용으로만 사용
    • 기능 서비스에서 특정 사용자 정보가 필요할 때 이 API를 호출하여 최신 정보 획득
    • 내부 API 키를 사용해 인증 (서비스 간 통신이 안전하게 이루어지도록)

캐싱 전략 적용

  • 문제점: 매번 API를 호출하면 Render 프리티어 환경에서 성능 저하 발생
  • 해결책:
    • 자주 조회되는 회원 정보를 메모리에 임시 저장(캐싱)
    • 첫 번째 조회 시에만 API 호출, 이후에는 캐시에서 빠르게 조회
    • 정해진 시간(예: 15분) 후 캐시 만료하여 일정 주기로 최신 정보 반영
    • 사용자가 프로필을 업데이트하면 해당 사용자의 캐시만 즉시 무효화하는 API 호출

장애 대응 방안

  • 문제점: 회원 서비스가 일시적으로 장애가 발생하면 기능 서비스도 영향 받음
  • 해결책:
    • Circuit Breaker 패턴: 회원 서비스 장애 감지 시 API 호출을 일시 중단하고 기본 정보 반환
    • 예를 들어, 회원 이름을 조회할 수 없으면 “Guest”와 같은 기본값 사용
    • 재시도 제한 및 타임아웃 설정으로 불필요한 대기 시간 방지

이 방식을 통해 JWT에 모든 회원 정보를 담지 않아도 최신 정보를 안전하게 공유하고, 성능과 안정성을 확보할 수 있습니다.

3. Render 프리티어 환경 최적화 방안

리소스 제약이 있는 Render 프리티어 환경에 맞춘 최적화 전략:

  • 경량화된 MSA 구조:

    • 필수적인 도메인만 분리 (회원 서비스 + 기능 서비스)
    • 최소한의 서비스 디스커버리 구조 사용

  • 성능 최적화:

    • 데이터베이스 커넥션 풀 크기 제한 (5-10개)
    • API 요청 타임아웃 짧게 설정 (3초 내외)
    • 캐시 크기 제한 (500 항목 이내)
    • Lazy Loading 적용하여 필요한 데이터만 로딩

  • 에러 처리 강화:

    • 서비스 간 통신 실패 시 폴백(fallback) 메커니즘 구현
    • 재시도 횟수 제한 (최대 3회)

4. 단계적 구현 전략

Burty 서비스에 MSA를 점진적으로 도입하기 위한 단계:

4.1 1단계: API Gateway 구현

  • Spring Cloud Gateway 기반 게이트웨이 서비스 구축
  • 라우팅 규칙 설정 (회원/기능 서비스 분리)
  • JWT 토큰 검증 필터 구현
  • CORS 설정 적용

4.2 2단계: 서비스 간 통신 구현

  • 회원 서비스에 내부 API 엔드포인트 추가
  • 기능 서비스에 RestTemplate 설정
  • 서비스 간 인증 메커니즘 적용

4.3 3단계: 캐싱 적용

  • 인메모리 캐시 설정
  • 회원 정보 캐싱 서비스 구현
  • 캐시 무효화 API 구현

4.4 4단계: 장애 대응 패턴 적용

  • Circuit Breaker 패턴 구현
  • 재시도 메커니즘 추가
  • 로깅 및 모니터링 강화

5. 결론

Burty 서비스의 현재 상황과 Render 프리티어 환경을 고려할 때:

  1. JWT만으로는 회원 정보 공유에 한계가 있으므로, 서비스 간 API 통신과 캐싱을 조합하는 것이 적합

  2. API Gateway 패턴을 통해 프론트엔드의 CORS 문제 해결 및 단일 진입점 제공

  3. 리소스 제약을 고려한 경량화된 MSA 구조와 성능 최적화 필요

  4. 단계적 구현을 통해 점진적으로 MSA 아키텍처로 전환