Service Discovery 패턴배경MSA의 분산 환경은 서비스 간 원격 통신으로 동작한다. 아래와 같은 이유로 다른 서비스의 정확한 위치(IP와 포트)를 직접 알고 있지 않고도 서비스 간 통신을 할 필요가 생겼다.cloud 환경에서 가상화/컨테이너화되어 동작하며, 인스턴스의 개수와 위치는 동적으로 변화한다. 또 각 인스턴스는 언제든지 제거/중지될 수도 있다.예를 들어 오토 스케일링에 따라 인스턴스가 계속 바뀌기 때문에 서비스에서 매번 각 인스턴스의 위치와, 어느 인스턴스가 살아있는지를 직접 알고 있을 순 없다.이렇게 언제든 바뀔 수 있는 서비스 위치들을 각 서비스들이 직접 알아야 한다면, 이는 클라우드 환경의 방향성과 도 맞지 않고 유지보수하기 어려운 시스템 구조가 될 것이다. 정의이러한 배경에서 ..
Spring RetryDB, 네트워크 문제, 동시성 등 일시적인 수행 실패로 인해 재수행 처리를 해야 하는 경우가 있다.이 때 try catch문과 반복문을 사용해서 직접 재시도 로직을 구현할 수도 있겠지만, 비즈니스 로직과의 관심사 분리가 어렵게 될 것이다.그런 문제는 AOP로 구현하면 해결되겠지만.. 귀찮을 것이다이러한 재처리 로직을 AOP를 통해 쉽게 적용할 수 있는 Spring 라이브러리가 있다는 것을 최근 업무 중 알게 되었다.Spring Retry 라이브러리는 Spring 어플리케이션에서의 재시도 기능을 제공한다.선언적으로도, 명령형으로도 설정할 수 있다.https://github.com/spring-projects/spring-retry GitHub - spring-projects/sprin..
많은 일들이 있었던 만큼 회고하는 데에도 오랜 시간이 걸렸다. 그래도 너무 늦지 않은 시점에 마무리하고자 한다. 길고 장황하고 너무 솔직한가 싶기도 하다. 그치만 더는 미룰 수 없다. 2023년의 목표 새로운 한 해마다, 목표는 최대한 단순하고 간단하게 정리하는 편이었다. 매일 해야 할일들을 잔뜩 나열하는 편이기에, 오히려 한 해 목표는 꼭 이루고 싶은 것만, 장황하지 않게 가져가는 편이 오히려 뭐든 해볼 수 있을 것 같은, 산뜻한 시작에 도움이 되기 때문이다. 2023년을 시작하며 적었던 그 단순한 목표는 두 개였더라. 취업하기와 건강 유지하기. 첫 번째, 취업으로는 가장 원하던 목표를 이루었다. 너무 감사하게도.. 그 다음 두 번째 목표였던 건강 유지하기는, “졌지만 잘 싸웠다” 정도로 이루었다. “..
Spring Event Spring’s eventing mechanism is designed for simple communication between Spring beans within the same application context. However, for more sophisticated enterprise integration needs, the separately maintained Spring Integration project provides complete support for building lightweight, pattern-oriented, event-driven architectures that build upon the well-known Spring programming ..
배경 프로젝트에서 쿼리 개선을 위해 JdbcTemplate를 통해 bulk insert를 구현하게 되었다. 우리는 MySql의 기본키 전략 중 Identity를 사용하고 있어 JPA의 saveAll 메서드로는 bulk insert가 되지 않기 때문이다. 그런데 bulk insert 해야 할 엔티티가 하나가 아니고, 해당 엔티티의 Id를 FK로 가지는 엔티티도 bulk insert해주어야 하는 상황이었다. 따라서 첫 번째 bulk insert의 결과인 Id들을 얻어와야 했고, 그 방법으로 last_insert_id() 함수를 사용할 수 있었다. insert를 한 뒤, Id를 조회해 계산하는 아이디어 자체는 이전에도 생각했다. 하지만 가장 최근 Id를 조회한다면, 의존하는 엔티티의 저장을 마치기 전까지는 테..
배경 지난 추석 연휴, 우리 프로젝트가 드디어 사용자 유치를 위한 홍보 활동을 시작했다. 어떻게 홍보할 것인가에 대한 고민이 많았는데, 그 중 한 가지 솔루션은 '흥미로운 지도를 만들어 홍보'하는 것이었다. 서비스 초기에 컨텐츠 생성자를 먼저 유치하기란 쉽지 않고, 흥미롭게 들어와보는 사람이라도 조금 생긴다면 성공하는 것이기 때문이다. 이 프로젝트와 유사한 지향점을 가진, '대동타코야끼여지도', '대동풀빵여지도'를 활용하기로 했다. 몇년 전 구글맵을 기반으로 활성화되었던 오픈맵인데 현재는 많이 잊혀진 것 같았다. 이 데이터들을 우리 지도에 가져온 뒤 사용자들을 유입시켜 더 편한 방식으로 지도를 리부트시키고 싶었다. (오래된 데이터를 자발적으로 업데이트하는 등) 팀원들과의 회의 결과, 날씨가 추워지는 요즘..
현재 진행하고 있는 팀 프로젝트 서비스에서는, 최근에 업데이트된 지도를 메인 화면에 보여주고 있다. 우리 도메인에서 지도에는 사람들이 '핀'을 꽂을 수 있는데, 기존에 관리되는 지도의 '업데이트 일시'는 지도의 생성, 정보 수정 시에만 업데이트되고 있었다. 그래서 오래 전에 만들어진 지도이지만, 방금 핀이 추가되어도 이 지도를 메인 화면에서 빠르게 확인할 수 없었다. 지도 내 핀이 추가되거나, 핀을 수정했을 때에도 지도의 업데이트 일시에 반영될 필요가 있었다. 기존 지도의 updatedAt 외에, 사용자에게 보여줄 정보인 lastPinUpdatedAt 이라는 정보를 추가로 관리하기로 했다. PR 링크로 확인하기 컬럼의 추가 방법으로는 무엇이 있을까? 1. 지도를 조회할 때, 지도가 가진 핀들을 가져와 가..
배경 지난 9월, 레벨4를 시작하며 팀 프로젝트에서 가장 우선시 했던 일은 로깅 환경 개선이었다. 기존에는 콘솔/파일 로그로 ERROR, WARN 레벨만 기록하고 있었다. 그와 동시에 개발, 운영 환경에 무관하게 콘솔 로그를 EC2내 log 파일로 기록하고 있었다. 콘솔 로그에는 hibernate의 sql 로그를 포함해 매우 많은 양의 로그가 빠르게 쌓였다. 로그 모니터링을 하다보니 ERROR, WARN 레벨의 로그만 보고 상황을 파악하기란 쉽지 않았다. 그래서 콘솔 로그를 보려고 들어가면, 수많은 양의 로그를 화면에 출력하는 데에만 한 세월이 걸렸다. 계속해서 커지는 로그 파일의 용량 또한 문제였다. 그래서 파일 로그에 대한 용량 관리가 필수적임을 체감했고, 운영 환경 별로 필요한 로그들을 잘 정리해서..
