[2주차] 내일배움캠프 Spring Java 심화 부트캠프 3기 - MSA

1. MSA(Microservices Architecture)

모놀리틱 아키텍처와의 비교

• 모놀리틱 아키텍처:
  • 모든 기능이 하나의 애플리케이션 내에 통합되어 있어, 간단한 배포가 가능하다.
  • 단점:
    • 확장성의 제한: 특정 기능만 확장하기 어렵다. 예를 들어, 사용자 인터페이스가 많이 사용되는 경우, 해당 부분만을 독립적으로 확장할 수 없다.
    • 긴 개발 주기: 모든 기능이 통합되어 있어 작은 변경 사항도 전체를 재배포해야 한다.
• MSA:
  • 독립적으로 운영되는 서비스의 집합으로 구성되며, 각 서비스는 특정 비즈니스 기능을 수행한다.
  • 장점:
    • 독립적인 배포: 서비스가 독립적으로 배포되어, 다른 서비스에 영향을 주지 않는다.
    • 기술 다양성: 각 서비스에서 최적의 기술 스택을 선택할 수 있다.
  • 단점:
    • 복잡성 증가: 서비스 간의 통신과 데이터 일관성 관리가 복잡해진다.
    • 운영 비용 증가: 각 서비스 별로 모니터링과 로깅을 따로 관리해야 한다.

신규 서비스를 작성한다면 초반에는 모놀리틱으로 개발하되, 서비스 사이즈가 커지면 MSA로 전환하는 방향으로 가는 것이 좋다고 한다.

 

MSA를 도입한 기업 사례를 찾아보니 다음과 같다.

1. Amazon - 초기에 모놀리틱 아키텍처를 사용했으나, 서비스 확장성과 유지 관리의 어려움 때문에 MSA로 전환했다. 각 서비스가 독립적으로 배포되고 확장될 수 있게 되면서, 전체 시스템의 안정성과 기능 배포 속도가 향상되었다. (3 Companies Using an MRP System - Unleashed Software)
2. Netflix - 대규모 사용자 기반과 데이터를 효율적으로 관리하기 위해 MSA를 채택했다. 이를 통해 각 서비스가 독립적으로 운영되어 실패 지점이 한 부분에 국한되지 않고, 빠르게 새로운 기능을 시장에 출시할 수 있게 되었다. (Successful Change Management Companies Examples)
3. Uber - 초기의 모놀리틱 구조에서 MSA로 전환했다. 이로 인해 다양한 지역에서 다양한 요구 사항과 법규에 맞춤화된 서비스를 제공할 수 있게 되었고, 시스템 전체의 부하 분산 및 장애 대응 능력이 향상되었다. (3 Companies Using an MRP System - Unleashed Software)

2. Spring Cloud

서비스 등록 및 디스커버리(Eureka)

• Eureka는 서비스의 등록 및 발견을 위한 REST 기반 서버이다.
• 서버 예제 코드

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

  이 코드는 Eureka 서버를 설정하고 실행하는 역할을 한다. @EnableEurekaServer 어노테이션을 통해 해당 애플리케이션을 Eureka 서버로 활성화한다.
• 클라이언트 예제 코드

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

  이 코드는 Eureka 클라이언트를 설정하고 실행하는 역할을 한다. @EnableEurekaClient 어노테이션을 통해 해당 애플리케이션을 Eureka 클라이언트로 활성화하여, Eureka 서버에 자동으로 등록된다.

로드 밸런싱(Ribbon)

• Ribbon은 클라이언트 측 로드 밸런싱 도구로, 서비스 인스턴스 간의 부하를 분산시킨다.
• 예제 코드

  @Configuration
  public class RibbonConfiguration {
      @Bean
      public IRule ribbonRule() {
          return new RoundRobinRule(); // 라운드 로빈 방식 사용
      }
  }
  

  이 코드는 로드 밸런싱 전략을 라운드 로빈 방식으로 설정한다. Ribbon을 사용하여 클라이언트가 요청을 여러 서버에 균등하게 분배하도록 한다.

서킷 브레이커(Hystrix)

• Hystrix는 장애 격리 및 복원력을 제공하여 시스템의 전체적인 안정성을 유지한다.
• 예제 코드

  @Service
  public class BookService {
      @HystrixCommand(fallbackMethod = "reliable")
      public String readingList() {
          URI uri = URI.create("http://localhost:8090/recommended");
          return new RestTemplate().getForObject(uri, String.class);
      }
  
      public String reliable() {
          return "Cloud Native Java (O'Reilly)";
      }
  }
  

  이 코드는 외부 서비스 호출 실패 시 reliable() 메소드를 대체 실행하여 복원력을 제공한다. @HystrixCommand 어노테이션은 해당 메소드 호출에 장애 발생 시 fallbackMethod로 지정된 메소드를 호출하도록 한다.

API 게이트웨이(Zuul, Spring Cloud Gateway)

• Spring Cloud Gateway 예제 코드

  @SpringBootApplication
  public class GatewayApplication {
      public static void main(String[] args) {
          SpringApplication.run(GatewayApplication.class, args);
      }
  
      @Bean
      public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
          return builder.routes()
                  .route(r -> r.path("/get")
                          .uri("http://httpbin.org"))
                  .build();
      }
  }
  

  이 코드는 Spring Cloud Gateway를 사용하여 특정 경로로 들어오는 요청을 다른 URI로 라우팅한다. 여기서 /get 경로의 요청을 http://httpbin.org으로 라우팅한다.

분산 추적(Spring Cloud Sleuth, Zipkin)

• Spring Cloud Sleuth는 요청 추적 정보를 제공하여, Zipkin과 통합하여 시스템의 트랜잭션을 시각적으로 모니터링 할 수 있다.
• 설정 예제

  spring:
    zipkin:
      baseUrl: http://localhost:9411
    sleuth:
      sampler:
        probability: 1.0
  

  이 설정은 Spring Cloud Sleuth와 Zipkin을 사용하여 서비스 간 요청 추적을 활성화한다. probability: 1.0은 모든 요청을 추적하겠다는 의미이다.

 

MSA에 대해서는 들어본 적은 있지만 자세히 알지는 못했다. 처음에는 복잡하고 어렵다고 생각했는데, 실제로 적용해보면 큰 규모의 시스템에서 유지보수와 확장성 면에서 도움이 될 것 같다. 당장은 그런 큰 규모의 프로젝트에 참여할 기회가 없기 때문에 기회가 생기면 실제 프로젝트에 활용해보고 싶다.