[내일배움캠프 사전캠프] 6회차 TIL(6/29 월) - Spring Cloud 핵심 인프라 구축 (Config, 분산추적(Zipkin), 이벤트 드리븐)

1. 오늘 학습 키워드

• Spring Cloud Config: 분산 환경에서의 중앙 집중식 설정 관리 및 동적 반영 (@RefreshScope, Actuator)
• 분산 추적 (Distributed Tracing): MSA 환경에서의 복잡한 요청 흐름 추적 및 시각화 (Zipkin, Trace, Span)
• 이벤트 드리븐 아키텍처 (EDA): 메시지 브로커를 활용한 비동기 시스템 전환 (Kafka/RabbitMQ, 느슨한 결합)

2. 오늘 학습 한 내용을 나만의 언어로 정리하기

1) Spring Cloud Config & Bus

• 개념: 모든 마이크로서비스의 환경 설정(yml)을 개별 서버가 아닌 중앙 저장소(Git, 파일 시스템 등)에서 한 곳으로 통제하는 프레임워크입니다.
• 실시간 구성 갱신: 설정 변경 시 서버를 재시작하지 않고도, 각 클라이언트의 /actuator/refresh 엔드포인트(수동)나 Spring Cloud Bus(자동)를 통해 변경사항을 실시간으로 애플리케이션에 동적 주입할 수 있습니다.
• 실행 순서: 인프라의 뼈대가 되는 Eureka Server가 가장 먼저 켜지고, 설정 원본을 제공하는 Config Server가 구동된 후, 이를 참조하는 일반 마이크로서비스(Product 등) 순으로 실행되어야 정상적으로 설정을 읽어옵니다.

2) 분산 추적 (Zipkin)

• 개념: 사용자 요청 하나가 여러 마이크로서비스를 체인처럼 거쳐 갈 때, 어느 구간에서 병목이 생기고 에러가 났는지 원인을 찾아 시각화해 주는 모니터링 기법입니다.
• 핵심 용어:
  • 트레이스(Trace): 한 개의 외부 요청이 시작되어 완료될 때까지 거쳐 가는 전체 이동 경로 및 흐름
  • 스팬(Span): 그 경로 안에서 일어나는 개별 마이크로서비스 단위의 단일 작업 (작업명, 소요 시간, ID 등 포함)
• 각 서비스 호출 시 트레이스와 스팬 데이터가 자동 생성되어 Zipkin 서버로 전송되며, 개발자는 대시보드를 통해 성능 병목을 직관적으로 진단할 수 있습니다.

3) 이벤트 드리븐 아키텍처 (Event-Driven Architecture)

• 기존 동기식(Request-Response)의 한계: 주문이 들어왔을 때 결제 -> 배송 -> 알림을 순차적으로 직접 호출(체인 구조)하면 강한 결합도가 생깁니다. 이 경우 한 곳이 터지면 전체가 마비되는 연쇄 장애가 발생하고, 모든 처리 시간이 누적되어 응답 속도가 현저히 느려집니다.
• 이벤트 기반 구조로의 전환: 주문 서비스는 다른 서버를 직접 호출하지 않고 메시지 브로커(Kafka, RabbitMQ)에 "주문 완료!"라는 이벤트만 발행하고 자기 일을 끝냅니다. 이후 결제, 배송, 알림 서비스가 브로커로부터 이벤트를 비동기로 수신하여 각자 로직을 처리합니다.
• 개선점: 서버 간 느슨한 결합이 완성되며, 특정 서버가 다운되어도 메시지가 브로커에 보존되므로 장애 고립(탄력성)이 확보됩니다. 또한 비동기 처리 덕분에 압도적인 응답 속도 향상을 기대할 수 있습니다.

3. 학습하며 겪었던 문제점 & 에러

문제&에러에 대한 정의

• 상황: Config Server에서 관리하는 공통 yml 설정 파일의 내용(예: message)을 변경했음에도 불구하고, 이미 구동 중인 클라이언트 애플리케이션(Product Service)에 변경된 설정값이 실시간으로 반영되지 않고 기존 값을 그대로 유지하는 현상 발생.

내가 한 시도

1. Config Server 내부의 원격 저장소 혹은 로컬 search-locations 경로 내부의 파일 내용이 제대로 수정되었는지 우선 검증함.
2. 클라이언트 프로젝트(Product)의 의존성 및 기본적인 연동 상태에 문제가 없는지 환경 설정을 재점검함.

해결 방법

1. 클라이언트 애플리케이션(Product)이 실시간 새로고침 엔드포인트를 노출할 수 있도록 application.yml에 Actuator 설정을 추가함.
2. .yml
   

    

   management:
     endpoints:
       web:
         exposure:
           include: refresh
   

3. 변경된 설정을 런타임에 동적으로 주입받아야 하는 컨트롤러 클래스(ProductController) 상단에 @RefreshScope 어노테이션을 부여함.
4. 설정 파일 변경 후, 외부에서 각 클라이언트 서버로 POST http://localhost:<port>/actuator/refresh 요청을 강제로 호출하여 정상적으로 구성이 갱신됨을 확인(수동 구성 갱신).

새롭게 알게 된 점

• Config Server의 파일이 바뀐다고 해서 클라이언트가 실시간으로 이를 감지하여 가져오는 것은 아니며, 빈(Bean)을 새로 갱신해 주는 @RefreshScope와 새로고침 신호를 유발하는 Actuator의 /refresh 호출이 삼위일체로 맞물려야 비로소 동적 변경이 완료된다는 메커니즘을 명확히 이해함.

이 문제&에러를 다시 만나게 되었다면?

• @RefreshScope가 클래스에 누락되었는지 가장 먼저 스캔하고, Actuator 웹 엔드포인트 오픈 상태를 체크할 것입니다. 나아가 서버가 수십 대로 늘어나는 실무 환경이라면 수동으로 일일이 누르는 대신 Spring Cloud Bus를 도입하여 한 번에 브로드캐스팅하는 구조를 설계할 것입니다.

4. 내일 학습 할 것

• MSA 강의 마무리하기
• 코드카타
• TIL 작성