섹션 8 : Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)

이 글은 인프런 Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의를 듣고 쓴 글입니다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4/dashboard

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

---

Spring Cloud Bus

이전 섹션에서 설정 정보 변경 시 refresh 하는 법을 다음의 3가지로 소개했다.

1. 서버 재기동
2. Actuator refresh
3. Spring cloud bus 사용

이 중, 1은 쓰면 안되고, 2는 모든 서비스마다 refresh 해줘야 하는 번거로움이 있었다.

이것의 해결방법인 Spring Cloud Bus 를 이번 섹션에서 사용할 것이다.

 

이것은 각 마이크로서비스를 경량 메시지 브로커와 연결해서 상태 및 구성에 대한 변경 사항을 연결된 마이크로서비스들에게 broadcasta 로 보낸다. 경량 메시지 브로커로는 RabbitMQ 를 사용할 것이다.

서비스끼리 직접 통신하지 않고, 미들웨어를 통해서 전달하므로 안정적이고 상대 서비스에 신경을 쓰지 않도록, 즉 종속성을 떨어뜨린다.

 

configuration server에 Spring Cloud Bus 의존성을 추가하고, 변경이 일어나면 연결된 마이크로서비스들 중 아무에게나 refresh를 해줄 것이다. 그러면 Bus가 마이크로 서비스들에게 AMQP (Advanced Message Queuing Protocol) 이라는 프로토콜을 이용해서 서비스들에게 push 해 줄 것이다.

 

AMQP 란 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜이다. 큐잉, 라우팅 등을 위해 사용하고 신뢰성, 보안 측면에서도 좋다. RabbitMQ 에서 많이 사용한다. 다음 게시글을 참고하자.

https://velog.io/@gjrjr4545/AMQP

AMQP

 

관련된 것으로 Apache Kafka 프로젝트가 있다. RabbitMQ 와 같은 메시지 브로커 인데, 분산형 스트리밍 플랫폼으로도 쓰인다. RabbitMQ 보다 대용량의 데이터를 처리할 수 있는 메시징 시스템이다.

이것은 RabbitMQ 와는 달리 Pub/Sub 방식이다. Pub(lisher) 가 Topic에 메시지를 전달하면 해당 Topic 을 구독하는 Sub(scribber) 가 메시지를 받아가는 것이다. 따라서 Ack 을 기다리지 않아도 되고, 따라서 초당 10만개 이상의 이벤트를 처리하는 대용량 시스템이 가능하다.

---

RabbitMQ 설치 (Mac)

RabbitMQ에 들어가서 하라는대로 하면 된다...

https://www.rabbitmq.com/

RabbitMQ: easy to use, flexible messaging and streaming — RabbitMQ

우선 homebrew 를 깔고, rabbitmq를 깐다. 다운로드된 경로는 설치하면서 나온다. 필자는

/opt/homebrew/opt/rabbitmq/sbin/rabbitmq-server 경로에 있었다. 여기로 들어가서 ./rabbitmq-server 를 실행하면 실행된다. 127.0.0.1:15672 에 접속해서 기본 아이디/비밀번호 guest 를 입력하면 잘 작동된다.

---

AMPQ 사용

user-service, apigateway-service, config-server 3개의 서버를 모두 rabbitmq에 연결시켜서 위에서 말한 것들을 동작시켜보자.

우선 3개의 서비스 모두에 다음과 같은 의존성이 있어야 한다. 없는 서비스에는 추가하자.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

그 다음, RabbitMQ와 연결하기 위해서 application.yml 파일에 다음을 추가한다.

spring:
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    username: guest
    password: guest

(근데 포트 15672 아니었나...? 왜 5672로 해야 하는 거지...? 알아봐야겠다)

그 다음, actuator에서 busrefresh 를 사용하기 위해 다음을 추가한다. 그냥 refresh가 아니라, RabbitMQ 를 통한 전체의 변경에 필요한 refresh가 busrefresh이다.

management:
  endpoints:
    web:
      exposure:
        include: busrefresh

 

이제 3개의 서버를 모두 기동하자.

누가봐도 성공인 것 같은 메시지가 나온다.

---

테스트

지금까지 한 것들을 테스트해보자. 설정파일들 중에 application.yml 로 실습하려 한다. 이 경우, 서비스들의 bootstrap.yml 파일에 있는 name 속성에 application 이 아니라, configuration server의 이름을 써줘야 한다. 그게 application이니까...

즉, user-service와 apigateway-service의 bootstrap.yml 파일을 다음과 같이 변경한다.

spring:
  cloud:
    config:
      uri: http://127.0.0.1:8888
      name: config-service

현재 token.secret 은 다음과 같다.

user_token_native_application

이제 모든 서버를 디버깅모드로 실행하고, 회원가입 로그인을 진행한 후에 프로그램 실행 도중 토큰 값을 보자.

user-service에 보낸 요청 결과, token.secret 값이 잘 들어있는 것을 확인했다.

 

이제 뭐할까? 바꿔봐야지!

token.secret을 다음과 같이 바꾼다.

user_token_native_application_changed_#1

이제 busrefresh 를 하면 된다! 위에서 봤듯이 연결된 어느 서비스에다가 요청을 보내도 상관없다.

User Service에 busrefresh

우선 user-service에 요청을 보내보자.

204 라는 성공 코드가 반환된다. 설레는 마음으로 다시 아무 GET 요청이나 보내서 값이 잘 바뀌었는지 확인하자.

GET 요청의 필터 처리를 하는 곳은 API Gateway 이다. 즉, user-service에 요청을 보냈는데 Gateway도 반영이 된 것이다.

Gateway에 busrefresh

이제 Gateway 에도 요청을 보내보자.

token.secret을 다음과 같이 바꾸고 저장한다.

user_token_native_application_changed_#2

이제 Gateway에 요청을 보낸다. 아까는 user-service/** 에 보냈지만, 지금은 그게 없으니까 Gateway의 actuator 가 동작하는 것이다.

역시나 성공했단다. 이제 로그인 요청을 보내보자.

왐마. 로그인 요청은 user-service에서 처리하는 로직이다. 그니까 busrefresh 요청을 Gateway에 보냈는데도 user-service에까지 설정변경이 이루어진 것이다.