반응형 Spring/Cloud10 [Spring Cloud] Resilience4J와 Zipkin을 활용한 로깅 및 분산 추적 1. 도입부: 마이크로서비스의 숙명, '연쇄 장애(Cascading Failure)'마이크로서비스 아키텍처(MSA)에서 서비스 간의 네트워크 호출은 시스템을 움직이는 혈관과 같다. 우리 프로젝트에서도 user-service는 사용자의 전체 정보를 구성하기 위해 order-service로부터 주문 목록을 가져온다.하지만 네트워크 너머의 서비스는 언제든 실패할 수 있다. 만약 주문 서비스가 응답 불능 상태에 빠지면, 사용자 서비스의 스레드는 응답을 기다리며 계속 점유되고, 결국 사용자 서비스의 모든 자원(Thread Pool)이 고갈되어 시스템 전체가 마비된다. 이것이 바로 연쇄 장애다. 사용자는 단순히 "주문 조회"만 안 되는 것을 넘어, 시스템 전체가 응답하지 않는 최악의 경험(500 에러)을 하게 된다.. 2026. 5. 6. [Spring Cloud] Kafka를 활용한 이벤트 기반 아키텍처(EDA) 설계 패턴 마이크로서비스 아키텍처(MSA)에서 각 서비스는 독립적인 데이터베이스를 가진다. 이로 인해 발생하는 가장 큰 고민은 "어떻게 서비스 간 데이터 일관성을 유지할 것인가?"이다. 주문이 들어왔을 때 상품의 재고를 줄여야 하고, 사용자의 포인트를 적립해야 한다. 이를 단순히 HTTP API 호출로 해결하려 하면 서비스 간 결합도가 높아지고 시스템 전체의 가용성이 떨어진다. 오늘은 이 문제를 해결하는 만능 열쇠, Apache Kafka와 Kafka Connect에 대해 심층적으로 정리해 본다. 1. Kafka Client: 애플리케이션의 목소리와 귀Kafka Client는 Java 애플리케이션이 Kafka 브로커와 대화하기 위해 사용하는 필수 라이브러리다. 단순히 데이터를 보내고 받는 것을 넘어, 시스템 관리와.. 2026. 5. 4. [Spring] MSA 서비스 간 통신의 진화: RestTemplate에서 FeignClient까지 단일 서비스(Monolith) 환경과 달리, MSA 환경에서는 서비스들이 각자의 성벽 안에서 독립적으로 존재한다. 따라서 '사용자 서비스'가 '주문 서비스'의 데이터를 필요로 할 때, 직접 메모리를 참조할 수 없고 반드시 네트워크라는 다리를 건너야 한다.오늘은 이 다리를 놓는 다양한 방법과 그 과정에서 발생하는 예외를 어떻게 스마트하게 처리할지 정리해 본다. 1. Communication Types: 서비스들이 대화하는 방식 (분류와 원리)이 프로젝트에서 마이크로서비스들은 역할과 상황에 따라 서로 다른 언어와 경로를 선택한다. 크게 동기(Synchronous)와 비동기(Asynchronous), 그리고 외부와 내부로 나눌 수 있다.외부 통신클라이언트 → API Gateway → 내부 서비스HTTP/RES.. 2026. 4. 29. [Spring] 안전한 MSA 운영을 위한 필수 전략: 설정 정보 암호화 및 복호화 흐름 정리 마이크로서비스 아키텍처(MSA)에서 설정을 중앙화하면 운영의 유연성이 비약적으로 상승한다. 하지만 중앙 저장소(Git 등)에 데이터베이스 비밀번호, API 토큰, 클라우드 접근 키(Secret Key) 등을 평문으로 저장하는 것은 보안 측면에서 매우 치명적인 행위다. 누군가 저장소 권한을 얻거나 실수로 코드가 노출될 경우 시스템 전체가 마비될 위험이 있기 때문이다. 이를 해결하기 위해 Spring Cloud Config는 {cipher} 키워드를 기반으로 한 강력한 암복호화 기능을 제공한다. 설정값은 저장소에 암호화된 상태로 보관되며, 애플리케이션이 이를 사용할 때만 복호화되어 주입되는 시스템을 구축하는 것이 이번 학습의 핵심 목표다. 1 . 주요 특징 및 핵심 로직Spring Cloud Config의 .. 2026. 4. 24. [Spring] Spring Cloud Bus: 수동 refresh의 고통에서 벗어나는 법 마이크로서비스 아키텍처(MSA)에서 설정 중앙화를 구현한 뒤 마주하는 가장 큰 고민은 "변경사항을 어떻게 모든 인스턴스에 즉시 반영할 것인가"이다. 인스턴스가 단 몇 개라면 각 서비스의 /actuator/refresh를 일일이 호출할 수 있겠지만, 수십 개로 늘어나는 순간 이는 운영상의 재앙이 된다. 호출 누락이 발생하면 어떤 인스턴스는 구버전 설정을, 어떤 인스턴스는 신버전 설정을 사용하는 불일치 현상이 발생하기 때문이다. 이러한 수동 작업의 한계를 극복하고, 단 한 번의 이벤트로 전체 시스템의 설정을 동기화하기 위해 도입하는 것이 바로 Spring Cloud Bus다. 1. 주요 특징 및 핵심 로직Spring Cloud Bus의 핵심은 메시지 브로커를 활용한 '이벤트 브로드캐스트' 구조에 있다. 특정.. 2026. 4. 23. [Spring] MSA 설정 중앙화: Spring Cloud Config와 다중 프로필 전략 마이크로서비스 아키텍처(MSA)를 운영하다 보면 소스 코드 자체보다 토큰 만료 시간, API 주소, 게이트웨이 정책 같은 설정값이 훨씬 자주 바뀐다는 것을 실감하게 된다. 하지만 서비스가 수십 개로 쪼개진 환경에서 각 서비스마다 application.yml을 따로 관리하는 것은 운영상의 큰 리스크를 동반한다. 똑같은 DB 주소를 여러 곳에 복사해두었다가 누락이 발생하거나, 환경(dev/prod) 분리가 시작되면서 파일 관리의 복잡도가 제어 불능 상태에 빠지기 때문이다. 오늘은 이러한 문제를 해결하고 설정을 '운영 자산'으로 다루게 해주는 Spring Cloud Config의 핵심 메커니즘과 실무 전략을 상세히 정리해 보았다. 1. Spring Cloud Config를 사용하는 이유Spring Cloud .. 2026. 4. 23. 이전 1 2 다음 반응형
