[Spring] 13주차+: 마이크로서비스 아키텍처(MSA) 입문

13주차+: 마이크로서비스 아키텍처(MSA) 입문

목표: 지금까지 학습한 모놀리식(Monolithic) 아키텍처의 한계를 이해하고, 현대적인 클라우드 네이티브 애플리케이션의 표준으로 자리 잡은 마이크로서비스 아키텍처(MSA)의 기본 개념을 학습합니다. MSA를 구축할 때 마주치는 여러 문제점과 이를 스프링 클라우드(Spring Cloud) 생태계가 어떻게 해결하는지 맛보는 것을 목표로 합니다.

주의: 이 파트는 실제 코드를 깊게 파고들기보다는, MSA의 개념적 이해와 앞으로 학습해 나갈 방향을 잡는 데 중점을 둡니다.

---

1. 모놀리식 아키텍처의 한계

지금까지 우리가 만든 "할 일(Todo) 애플리케이션"은 모놀리식(Monolithic) 아키텍처입니다. '모놀리식'은 '하나의 거대한 돌'이라는 뜻으로, 애플리케이션의 모든 기능(사용자 관리, 할 일 관리, 알림 등)이 하나의 프로젝트, 하나의 프로세스로 묶여 개발되고 배포되는 구조를 의미합니다.

1.1 모놀리식의 장점

• 단순함: 개발 초기에는 모든 코드가 한 곳에 있어 개발 및 테스트, 배포가 비교적 단순합니다.
• 쉬운 데이터 관리: 단일 데이터베이스를 사용하므로 데이터 일관성을 유지하기 쉽습니다.

1.2 모놀리식의 단점 (애플리케이션이 거대해질수록)

• 낮은 빌드/배포 생산성: 코드베이스가 커질수록 빌드 및 테스트 시간이 기하급수적으로 늘어납니다. 작은 수정사항 하나를 배포하기 위해 전체 애플리케이션을 다시 빌드하고 배포해야 합니다.
• 유연성 부족: 전체가 강하게 결합되어 있어, 새로운 기술이나 프레임워크를 도입하기 어렵습니다. (e.g., 일부 기능만 Node.js로 바꾸고 싶어도 불가능)
• 확장성 한계: 특정 기능(e.g., 할 일 조회)에만 트래픽이 몰려도, 해당 기능만 독립적으로 확장(scale-out)할 수 없고 전체 애플리케이션을 통째로 복제해야 하므로 비효율적입니다.
• 장애 전파: 특정 기능의 장애(e.g., 알림 기능의 메모리 누수)가 전체 애플리케이션의 장애로 이어질 수 있습니다.

2. 마이크로서비스 아키텍처 (MSA)

MSA는 이러한 모놀리식의 한계를 극복하기 위해 등장했습니다. 하나의 거대한 애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 조합으로 나누어 설계하는 아키텍처 스타일입니다.

예를 들어, 우리 애플리케이션을 MSA로 전환한다면 다음과 같이 나눌 수 있습니다.

• 사용자 서비스 (User-Service): 회원가입, 로그인 등 사용자 관련 기능만 담당
• 할 일 서비스 (Todo-Service): 할 일 CRUD 기능만 담당
• 알림 서비스 (Notification-Service): 이메일, SMS 등 알림 기능만 담당

각 서비스는 자신만의 데이터베이스를 가질 수 있으며, 다른 서비스와는 오직 API(주로 REST API 또는 메시지 큐)를 통해서만 통신합니다.

2.1 MSA의 장점

• 독립적인 개발 및 배포: 각 팀은 자신들이 맡은 서비스를 다른 팀에 영향을 주지 않고 독립적으로 개발, 테스트, 배포할 수 있습니다. (Agile, CI/CD에 최적화)
• 기술 다양성 (Polyglot): 각 서비스에 가장 적합한 기술(언어, 프레임워크, DB)을 자유롭게 선택하여 적용할 수 있습니다.
• 탄력적인 확장성: 트래픽이 몰리는 특정 서비스만 독립적으로 확장(scale-out)할 수 있어 자원을 효율적으로 사용할 수 있습니다.
• 장애 격리: 하나의 서비스에 장애가 발생하더라도, 다른 서비스에 장애가 전파되는 것을 막을 수 있습니다. (장애 격리 패턴 적용 시)

2.2 MSA의 어려움 (공짜 점심은 없다)

MSA는 많은 장점을 제공하지만, 모놀리식에서는 겪지 못했던 새로운 복잡성을 야기합니다.

• 통신의 복잡성: 서비스 간 호출이 네트워크를 통해 이루어지므로, 지연 시간(latency)과 실패 가능성을 항상 고려해야 합니다.
• 데이터 분산: 각 서비스가 자신만의 DB를 가지므로, 여러 서비스에 걸친 데이터의 일관성을 유지하기가 매우 어렵습니다. (분산 트랜잭션 문제)
• 서비스 탐색 (Service Discovery): 수많은 서비스들이 동적으로 늘어나고 줄어드는 환경에서, 서비스 A가 서비스 B의 IP 주소와 포트 번호를 어떻게 알고 호출할 수 있을까요?
• 중앙화된 설정 관리: 각 서비스에 흩어져 있는 설정(DB 정보, 타임아웃 값 등)을 어떻게 효율적으로 관리하고, 변경 사항을 어떻게 전파할 수 있을까요?
• 단일 진입점 (API Gateway): 클라이언트는 수많은 서비스들의 주소를 모두 알아야 할까요? 인증/인가, 로깅 등 공통 기능을 어떻게 처리해야 할까요?
• 분산 추적 및 모니터링: 요청 하나가 여러 서비스를 거쳐 처리될 때, 어디서 병목이 발생하고 어디서 오류가 났는지 어떻게 추적할 수 있을까요?

3. 스프링 클라우드 (Spring Cloud)

스프링 클라우드는 MSA를 구축할 때 발생하는 위와 같은 문제들을 해결하기 위한 다양한 프로젝트들의 집합입니다. 스프링 부트 기반으로 개발되어 있어, 스프링 개발자들이 MSA 환경을 쉽게 구축할 수 있도록 도와줍니다.

3.1 주요 스프링 클라우드 프로젝트

• API Gateway: Spring Cloud Gateway

  • 모든 클라이언트 요청의 단일 진입점(Single Point of Entry) 역할을 합니다.
  • 요청을 적절한 마이크로서비스로 라우팅(routing)하고, 인증/인가, 로깅, 속도 제한(Rate Limiting) 등 공통 기능을 처리합니다.

• Service Discovery: Spring Cloud Netflix Eureka / Spring Cloud Consul

  • 각 서비스가 시작될 때 자신의 위치(IP, 포트)를 서비스 레지스트리(Eureka 서버 등)에 등록합니다.
  • 다른 서비스를 호출하고 싶을 때, 서비스 레지스트리에 해당 서비스의 이름을 물어보고 실제 위치를 받아와 통신합니다. 이를 통해 서비스의 IP가 바뀌어도 유연하게 대처할 수 있습니다.

• Centralized Configuration: Spring Cloud Config

  • 모든 마이크로서비스의 설정을 Git 리포지토리와 같은 중앙화된 저장소에서 관리합니다.
  • 애플리케이션 재시작 없이도 변경된 설정을 동적으로 반영할 수 있습니다.

• Declarative REST Client: Spring Cloud OpenFeign

  • 마치 스프링 데이터 JPA가 Repository 인터페이스만으로 구현체를 만들어주듯이, Feign은 인터페이스와 어노테이션만으로 다른 마이크로서비스를 호출하는 REST 클라이언트 코드를 자동으로 생성해줍니다.

  @FeignClient(name = "user-service") // 호출할 서비스의 이름을 지정
  public interface UserServiceClient {
      @GetMapping("/api/users/{userId}")
      UserResponse getUserById(@PathVariable Long userId);
  }

• Circuit Breaker: Spring Cloud Circuit Breaker (Resilience4j)

  • 특정 서비스에 장애가 발생하여 응답이 없을 때, 해당 서비스로의 요청을 일시적으로 차단하고(회로를 열고), 장애가 전파되는 것을 막습니다. 대신 미리 정의된 기본값(Fallback)을 반환하여 서비스의 안정성을 높입니다.

• Distributed Tracing: Spring Cloud Sleuth (Micrometer Tracing)

  • 클라이언트의 요청이 여러 마이크로서비스를 거쳐갈 때, 각 요청에 고유한 추적 ID(Trace ID)를 부여하여 전체 호출 흐름을 추적하고 시각화할 수 있도록 도와줍니다. (Zipkin, Jaeger 같은 도구와 연동)

---

🚀 앞으로의 학습 방향

12주간의 로드맵을 통해 여러분은 견고한 모놀리식 애플리케이션을 만들 수 있는 충분한 역량을 갖추게 되었습니다. 이제 MSA라는 새로운 세계로 나아갈 준비가 되었습니다.

1. Docker와 Container 기본 학습: MSA 환경에서 각 서비스는 독립적인 컨테이너로 패키징되고 배포됩니다. Docker의 기본 개념과 사용법을 반드시 익혀야 합니다.

2. 스프링 클라우드 프로젝트 실습:

   • Spring Cloud Gateway를 사용하여 API 게이트웨이를 구축해봅니다.
   • Eureka 서버를 띄우고, 여러 개의 스프링 부트 애플리케이션(마이크로서비스)을 Eureka 클라이언트로 등록하여 서비스 디스커버리를 구현해봅니다.
   • OpenFeign을 사용하여 서비스 간 통신을 간편하게 처리해봅니다.

3. 메시지 큐 학습: 서비스 간의 비동기 통신과 데이터 정합성을 위해 RabbitMQ나 Kafka와 같은 메시지 큐 시스템을 학습하는 것이 좋습니다.

4. Kubernetes 입문: 수많은 컨테이너들을 효율적으로 관리하고 오케스트레이션하기 위한 사실상의 표준 도구인 쿠버네티스의 기본 개념을 학습합니다.

---

📝 13주차 요약

• 마이크로서비스 아키텍처(MSA) 는 하나의 큰 애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 조합으로 나누는 설계 방식이다.
• MSA는 독립적인 개발/배포, 기술 다양성, 탄력적 확장성 등의 장점을 가지지만, 통신, 데이터 분산, 설정 관리 등 새로운 복잡성을 야기한다.
• 스프링 클라우드는 MSA 환경의 복잡한 문제들을 해결하기 위한 다양한 프로젝트들의 집합이다.
• Gateway(API 게이트웨이), Eureka(서비스 탐색), Config(설정 관리), OpenFeign(선언적 REST 클라이언트), Circuit Breaker(장애 격리) 등은 MSA 구축의 핵심 요소이다.
• 성공적인 MSA 전환을 위해서는 Docker, Kubernetes, 메시지 큐와 같은 클라우드 네이티브 기술에 대한 이해가 필수적이다.

축하합니다! 13주간의 긴 여정을 통해 여러분은 스프링 부트 전문가로 가는 단단한 초석을 다졌습니다. 여기서 멈추지 말고, MSA와 클라우드 네이티브의 세계로 계속해서 나아가시길 바랍니다.