우리네 장

Spring Cloud Config 를 사용하면서, 액추에이터를 같이 쓰면, 설정 정보를 사용하는 서비스를 재기동하지 않아도 되지만, 서비스마다 /actuator/refresh를 호출해야 하는 번거로움이 있었습니다. 매 서비스마다 호출이 아닌, 한 번의 호출로 변경된 설정정보를 가져오는 방법을 알아보도록 하겠습니다. Spring Cloud Bus는 RabbitMQ / Kafka 같은 메세지 브로커와 함께 사용합니다. 실제 버스의 역할은 메시지 브로커처럼, 구독자에게 데이터를 전달하는 역할 보다는, 메세지 브로커에게 RefreshRemoteApplicationEvent를 broadcast 하게 publish 해주는 역할을 수행한다고 보면 됩니다. ( 이름이 버스라서 처음에 역할이 많이 혼돈스러웠습니다 😱 ..

전 게시글에서 spring cloud config 서버에 대한 설정과 config 서버를 사용하는 서비스들에 대한 설정을 끝냈습니다. config서버를 사용하는 이유가 서비스를 재기동 하지 않고 변경된 설정 내용을 반영하기 위함인데, 사용자 서비스를 다시 재기동을 했었죠...ㅠ-ㅠ config 서버의 변경 사항을 서비스가 알아차리는 데는 3가지 방법이 있습니다. 재기동 < actuator 사용 < spring cloud bus 사용 자동화 순서로 정리해봤습니다. 가장 간편한 bus를 사용하기 전에, actuator 사용에 대해 먼저 알아보겠습니다. Actuator란? spring에서 제공해주는 api로, 어플리케이션의 상태나 표준 지표, Metrics 정보를 제공하여 줍니다. 다양한 endpoint를 제..

Spring Cloud Config는 각 MSA 서비스에서 사용되는 설정 정보들을 하나의 서버에서 일괄적으로 관리할 수 있게 해줍니다. 즉, 어플리케이션의 설정 정보를 어플리케이션 내부가 아닌 외부에서 관리하는 것인데요, 이렇게 Config 서버를 따로 구축하여 관리하였을 때, 설정 정보가 변경되어도 각 서비스들에 변경된 정보를 반영하기 위해 재빌드/배포를 하지 않아도 된다는 장점이 있습니다. ( 단순히 Config 서버만 사용하는 것이 아니라, Actuator API를 사용하거나, Spring Cloud Bus를 사용해야 하긴 합니다. ) Config 서버가 참조하는 스토리지는 보통 로컬 디렉토리나, 깃 로컬 혹은 깃 리모트 저장소를 많이 사용합니다. 물론 svn과 같은 형상 관리 도구도 Config ..

전 게시글에서, spring cloud gateway에서 기본으로 제공하는 필터가 있다고 설명하였습니다. AddRequestHeader / RemoveRequestHeader / AddResponseHeader / RemoveResponseHeader / RewritePath 해당 필터들 외에도, 사용자가 커스텀 필터를 정의하여 게이트웨이에게 로깅이나 인증등의 역할을 수행할 수 있도록 할 수 있습니다. 단일 지점에서 로깅이나 인증, 캐싱, 접근 제한등의 기능을 수행하면, 각 서비스에서 수행하는 것보다 관리면에서 훨씬 수월할 것입니다. 아래는 로깅 작업을 수행하는 필터를 만들어 보았습니다. @Component @Slf4j public class LoggingCopyFilter extends Abstract..

이전, 라우팅 할 서비스의 uri를 하드코딩으로 설정할 경우, 고정 IP로 설정되어 있지 않은 auto-scaling 으로 서버의 인스턴스를 증가시키게 되면, 정상적으로 요청을 전달할 수 없다고 설명하였습니다. 유레카와 같이 사용하게 되면, 라우팅 정보를 고정된 uri가 아닌, 어플리케이션 이름으로 하여 변경되는 서비스 진입정보를 알아낼 수 있습니다. 유레카와 연동하여 사용하기 위해 변경한 설정 정보입니다. 물론 이렇게 사용하기 위해서는 대상이 되는 사용자 서비스와 게이트웨이 모두 유레카가 인식할 수 있도록 네이밍 서버에 등록해 주어야 합니다. 변경된 설정정보를 보시면, uri 부분에 http 프로토콜 대신, lb라는 프로토콜을 사용한 것을 볼 수 있습니다. - uri : lb://USERSERVICE ..

공부하다 보면, 너무 많은 로깅 패키지 설정이 있는데 패키지 경로와 역할이 비슷해서 정리해 두려고 한다. 새로운 로깅 경로가 생길 때마다 update 할 예정이다! 미래에 사용할 나를 위해.. DB 관련 logging: level: org.hibernate.SQL = DEBUG //jpa에서 나가는 SQL을 보기 위해 org.hibernate.type = TRACE //SQL에 사용되는 param 값을 확인하기 위해 org.springframework.transaction.interceptor = DEBUG //단순 트랜잭션 획득/반납을 보기 위해 org.springframework.jdbc.datasource.DatasourceTransactionManager = DEBUG // jdbcTemplate..

처음 팀에 들어왔을 때부터, 담당했던 프로젝트가 수 년간 유지보수 작업을 거치면서 점점 거대해지게 되었습니다. 그 동안 한 사람만이 프로젝트를 담당했던 것이 아니어서 코드 스타일이 모두 달랐고, 의미 없는 변수 명들이 넘쳤으며, 하나의 기능 흐름을 파악하는데, 대체 이 코드가 왜 쓰인 것인지에 대해서 정말 많이 고민을 하면서 이해하였습니다. 온프라미스 환경에서 클라우드 환경으로의 이관을 준비하면서, 이후 다른 팀원들과 함께 할 유지보수 작업을 위해, 과감하게 리팩토링을 진행하기로 하였습니다! 😂😂 작업을 하기 전, 지향했던 바는 계층형 아키텍쳐에 클린 아키텍쳐를 조금 묻혀보자! 였습니다. 작업 환경 Springframework 4.3.25 Mybatis 3.5 기존 프로젝트의 문제, 원래 프로젝트의 구조..

클라이언트 코드에서 임의의 기능을 호출하기 할 때, 보다 단순한 인터페이스를 제공함으로써 클라이언트 코드에 부담을 줄여줄 수 있고, 결합도를 낮추어, 퍼사드 클래스가 사용하는 서브 시스템 클래스들의 기능이 수정되더라도, 클라이언트 코드를 수정하지 않아도 된다. Facade 디자인 패턴은 서브 시스템 클래스를 캡슐화 하는 것이 목적이 아니고 그저 단순한 인터페이스를 제공하는 것이 목적이기 때문에, 클라이언트 코드에서 각 서브 시스템 클래스의 기능을 직접 호출해도 무관하다. 단점은 Wrapper 클래스가 많아져 그 개수가 많아질 경우 메모리 용량을 차지할 수 있다는 점이다. 이 디자인 패턴을 스프링에 적용한 예시를 살펴보자. Facade 패턴 in Spring ! 😎 위와 같이 구성된 서비스 클래스가 있다고..