LG CNS 부트캠프 학습일지 47일차

학습 내용

• Spring Config Server에서 갱신된 설정값을 가져오는 방법
• RabbitMQ를 사용해서 갱신된 설정값을 일괄적으로 가져오는 방법

Spring Config Server에서 갱신된 설정값을 가져오는 방법

마이크로서비스가 많아지면 한 가지 문제가 발생한다. 각 서버의 설정값을 관리하기가 어렵다는 것이다. 그리고 만약에 서버의 설정값을 변경하게되면 서버를 재부팅해야 하고 서비스를 중단해야 한다. 이 문제를 해결하기 위해서 Spring Config Server를 사용한다. Spring Config Server의 application.yml에 아래 내용을 추가해주어야 했다.

management:
  endpoints:
    web:
      exposure:
        include:
          - refresh
          - health
          - beans
          - info
          - httpexchanges
          - busrefresh

Spring Config Server의 /actuator/refresh 엔드포인트에 접근해서 업데이트된 설정값을 가져올 수 있다.

curl.exe --% --request POST http://localhost:8083/actuator/refresh

RabbitMQ를 사용해서 갱신된 설정값을 일괄적으로 가져오는 방법

Spring Config Server를 사용하는 것은 좋지만 문제가 하나 더 있었다. 서버를 재시작하지 않고 설정값을 업데이트할 수 있게 되었지만, 각 서버에서 Spring Config Server의 /actuator/refresh 엔드포인트에 접근해서 새로운 설정값을 받아와야 한다는 것이다. 서버의 갯수가 많아지면 설정값을 업데이트하는 것도 꽤 번거로운 일이다.

이를 위해서 메세지 브로커를 사용한다. RabbitMQ와 Kafka라는 것이 있다. 이것 말고도 다양한 솔루션이 있다. 메세지 브로커라는 것은 MSA 안에서 각 서버들이 통신을 하기위해 각자의 엔드포인트에 접근하는 것이 아니라, 하나의 중재자를 두는 것이다. 사람들이 서로에게 직접적으로 편지를 보내는 것이 아니라 우체국을 통해서 편지를 보내는 것으로 비유할 수 있겠다. RabbitMQ는 Kafka와 비교했을 때 같은 시간에 보낼 수 있는 메세지의 갯수는 적지만 보낸 메세지가 상대방에게 도달하는 것을 보장한다. 반대로 Kafka는 대역폭이 크지만 메세지가 도달하였는지 여부에 대한 검증을 하지 않는다. Kafka는 상대적으로 더 많은 자원을 필요로 한다.

사실 직접 사용해보고 정리하는 것이 아니라, 수업시간에 들었던 내용을 요약하는 것이기 때문에 정확하게 설명했다고 생각하지는 않는다. 한 가지 확실한 것은 두 솔루션 중에서 적당한 것을 선택할 수 있어야 한다는 것이다.

Spring Config Server에서 클라이언트에게 갱신된 설정값을 일괄적으로 보내기 위해서 RabbitMQ를 사용했다. 도커 컨테이너를 사용했다. 개인 서버에 RabbitMQ 서버를 올렸는데, 이것 때문에 실습을 할 때 문제가 있었던 것 같다. 아직 문제를 해결하지는 못했는데, 내일 수업 시작하기 전에는 해결할 수 있으면 좋겠다. 아무튼 강사님이 하시는 것을 보니, 설정값을 가지고 있는 깃 저장소를 업데이트하고, Spring Config Server의 /actuator/busrefresh 엔드포인트로 접근하면 RabbitMQ를 통해 클라이언트의 설정값을 일괄적으로 업데이트할 수 있는 것 같다.