개발자 하민아빠의 Dev & Money

시리즈 첫 글에서 제가 MSA를 선택한 이유로 "리포트 기능이 죽어도 결제는 되어야 한다"는 '장애 격리'를 꼽았던 것, 기억하시나요?하지만 단순히 서비스를 쪼갠다고 해서 저절로 격리가 되는 건 아닙니다. 주문 서비스가 재고 서비스를 호출했는데, 재고 서비스가 응답이 없고 무한 로딩에 걸리면 어떻게 될까요?주문 서비스의 스레드도 응답을 기다리다 다 소진되어, 결국 두 서비스가 같이 죽게 됩니다.오늘은 이 끔찍한 연쇄 장애를 막아주는 두꺼비집, Resilience4j (Circuit Breaker)를 우리 프로젝트에 달아보겠습니다.1. 서킷 브레이커(Circuit Breaker)란?집에 있는 '두꺼비집'을 생각하면 쉽습니다.전기를 너무 많이 쓰거나 누전되면 두꺼비집이 딱! 내려가서 전기를 끊어버리죠? 덕분..

"DB 비밀번호가 변경되었습니다. 각 서비스 담당자분들은 application.yml 수정해서 배포해주세요."서비스가 3개일 땐 괜찮았습니다.그런데 MSA 전환 후 서비스가 10개가 넘어가니, 저 메신저 알림이 공포로 다가왔습니다.10개 프로젝트의 코드를 다 수정하고, 빌드하고, 배포하는 데만 반나절이 걸리니까요.실수로 하나라도 빼먹으면 장애로 이어집니다."설정 파일만 따로 모아서 관리할 수는 없을까?"이런 고민을 해결해 주는 것이 Spring Cloud Config입니다.모든 마이크로서비스의 설정(yml)을 Git 저장소 한곳에서 관리하고, 서버 재시작 없이 설정을 변경하는 마법 같은 방법을 공유합니다.1. Spring Cloud Config의 핵심 원리구조는 생각보다 단순합니다.Git Reposito..

지난 시간까지 우리는 Eureka(전화번호부)를 만들고, Gateway(정문)를 세웠습니다.이제 외부에서 들어오는 요청은 잘 처리할 수 있습니다.그런데 내부 사정은 어떨까요?MSA 환경에서는 '주문 서비스'가 '재고 서비스'에게 "재고 남았어?"라고 물어보는 등, 서비스 간의 통신이 빈번하게 일어납니다. 과거에는 이를 위해 RestTemplate이 표준이었지만, 지금은 선택지가 너무 많아졌습니다.비동기 처리에 강한 WebClientSpring Boot 3.2에 등장한 신성 RestClient그리고 Spring Cloud의 터줏대감 OpenFeign"요즘 RestClient가 나왔다던데 갈아타야 하나?" 고민하시는 분들도 계실 겁니다. 하지만 저는 4년 차 실무 개발자로서, 복잡한 비즈니스 로직을 다루는 ..

지난 글에서 우리는 모놀리식을 쪼개어 MSA로 가기로 결심했습니다.그런데 막상 서비스를 A, B, C로 나누고 나니 황당한 문제가 생깁니다. "A 서비스가 B 서비스를 호출해야 하는데, B 서비스 IP가 뭐지?"로컬(localhost:8080)에서야 포트만 외우면 되지만, AWS나 Docker/K8s 환경에서는 배포할 때마다 IP가 동적으로 바뀝니다.그때마다 소스 코드에 박힌 IP(192.168.x.x)를 수정해서 재배포할 수는 없겠죠.이럴 때 필요한 것이 바로 Service Discovery입니다.오늘은 MSA의 '전화번호부' 역할을 하는 Netflix Eureka를 구축하고, 흩어진 서비스들을 하나로 묶어보겠습니다.1. Service Discovery가 왜 필요한가요?쉽게 비유하자면 '114 전화번호..

"개발자라면 MSA(Microservices Architecture) 정도는 해봐야지."제가 지금 다니는 회사에 입사 지원서를 냈던 가장 큰 이유도 사실 이것이었습니다."제대로 된 대규모 MSA 환경을 경험해보고 싶다"는 열망이었죠.입사 후 2년 동안은 기존에 구축된 MSA 프로젝트를 운영하며 트래픽을 감당했고, 작년에는 아예 새로운 프로젝트를 처음부터 끝까지 MSA 환경으로 직접 구축해 보는 귀중한 경험을 했습니다. 이 과정에서 느낀 건, MSA와 모놀리식(Monolithic)은 단순히 '옛날 기술 vs 최신 기술'의 대결이 아니라는 점입니다.오늘은 4년 차 개발자의 시선에서 두 아키텍처의 차이를 비교해 보고, 왜 여기는 복잡한 MSA를 선택할 수밖에 없었는지, 그리고 현실적으로 언제 도입해야 하는지 ..