도입 서비스를 운영하다보면, 다양한 이유로 애플리케이션의 구동 시점에 단 한 번만 실행되어야 하는 로직을 정의할 필요성을 느끼게 될 수도 있다. 최초 실행 시 긴 시간을 요구하는 로직들을 사용자에게 빠르게 제공하기 위한 Warm up 과정이나, 실행 시점에 입력된 동적 환경변수를 기반으로 제어되는 로직의 관리 등이 이에 해당한다. 그렇다면, 이러한 로직들은 어떻게/어디에 정의해야 할까? 이 글에서는 그 방법을 3가지로 분류하여 소개한다. Bean 생명주기를 이용 Runner를 이용 Event를 이용 Bean 생명주기를 이용 생성자 @Slf4j @Component public class MyBean { private final RequiredBean requiredBean; @Value("${hello.w..
AWS 프리티어의 공포백엔드 개발자로 사이드 프로젝트를 해본 경험이 있다면, 프리티어를 통해 AWS 클라우드를 사용해 본 경험이 한 번쯤은 있을 것이다. AWS에서는 1년 동안 EC2, RDS, S3 등 핵심 제품에 대해 무료 제공을 지원한다. 프리 티어를 사용한다면, 큰 추가 지출 없이 가벼운 서비스를 클라우드 환경에서 운영할 수 있다.그러나 프리티어는 1년이 지난 후부터 자동으로 비용이 지불되며, 프리티어 기간 동안에도 무료가 아닌 서비스를 이용하거나 계정 또는 서버에 접근하기 위한 정보들을 탈취당하는 경우 과금이 청구될 수 있다. (AWS 과금 괴담은 많은 개발자들을 두려움에 떨게 하는 이야기이다.)과금 괴담만이 아니더라도 프리티어 기간이 종료되고 나면 지불 비용이 은근히 쎄다. EC2, RDS만을..
이 글은 유데미 강의 ‘Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기’ 의 쿠폰을 받아 수강하고 작성한 글입니다. 멀티스레딩? 하나의 프로세스는 하나 이상의 스레드를 가질 수 있다. 프로그램들은 때에 따라 단일 스레드로 동작하기도, 여러 스레드로 동작하기도 한다. 멀티스레딩이란, 말 그대로 하나의 프로세스가 여러 개의 스레드를 사용하도록 프로그램을 작성하는 프로그래밍 기법이다. 이번 글에서는 멀티스레딩에 대해 아래와 같은 점들을 살펴본다. 단일 스레드 프로그램의 단점 멀티스레딩의 이점 멀티스레딩을 도입할 때 유의할 점 단일 스레드와 멀티 스레드 프로세스를 카페, 스레드를 점원에 비유해 점원이 한 명인 카페와 여러 명인 카페의 운영 방식을 상상해보자. 점원이 한 명인 카페의 문제점 먼저 한 ..
이번 글에서는 Spring Event 도입기 1장에서 언급한 이벤트 리스너 밖으로 전파된 예외의 처리에 대해 다룬다. Spring Event의 자세한 사용 방법은 1장에서 소개하고 있다. Spring Event 도입기 (1) - 핵심 로직을 변경으로부터 보호하라 핵심 로직 변경에 따른 문제 발생과 해결 문제 - 가독성 저하 현재 사내에서 운영하는 서비스에는 사용자의 요청을 받으면 엔티티를 생성해 저장하고 메시지 큐에 발행한다라는 핵심 로직이 존 devpanpan.tistory.com 리스너의 사용 방법에 따른 분류 리스너는 동기/비동기로, 발행 즉시/발행 주체의 트랜잭션 범위에 따라 다양하게 정의할 수 있다. 이 글에서는 리스너의 사용 사례를 아래의 4가지로 분류하고 각각의 예외 처리 방법을 살펴본다. ..
핵심 로직 변경에 따른 문제 발생과 해결 문제 - 가독성 저하 현재 사내에서 운영하는 서비스에는 사용자의 요청을 받으면 엔티티를 생성해 저장하고 메시지 큐에 발행한다라는 핵심 로직이 존재한다. 이 코드는 처음에는 아주 짧았고, 가독성도 나쁘지 않았다. 그러나 기획이 추가됨에 따라 해당 코드에는 여러 부가 로직들이 추가되었다. 엔티티의 생성 후 또다른 엔티티를 생성해야 하기도 하고, 메시지 큐에 발행하기 전 엔티티에 특정 변환 작업이 추가되기도 했다. 기획이 변경됨에 따라 이러한 변경 사항은 추가되기도, 다시 제거되기도 하며 핵심 로직을 포함한 클래스에 다양한 변경을 일으켰다. 그러다보니 코드는 점점 길어지고 가독성도 나빠졌다. 수정이 잦으니 여러 사람의 작업에 의해 conflict가 발생할 때도 많아졌고..
외부 API 호출이 포함된 비즈니스 로직의 테스트 테스트를 작성하는 과정에서, 우리는 항상 특정 의존 모듈에 대하여 2가지 중 하나를 선택해야 합니다. 실제 모듈을 주입받아 사용 해당 모듈의 모의 객체(Mock)를 생성하여 사용 내부 모듈로부터 수행되는 비즈니스 로직인 경우 둘 중 어느 쪽을 택하든 테스트를 구성하는 데에 문제는 없습니다. 하지만 외부에서 구동되는 서버의 API를 호출하는 경우에는 이야기가 다릅니다. 1번 방법(실제 모듈 사용)을 택해 실제 API 호출이 이루어지는 방향으로 테스트 코드를 작성하게 되면 아래와 같은 문제가 발생할 수 있습니다. 외부 API 서버의 상태에 의존 - 외부 API의 이용 가능 여부에 따라 테스트의 성패가 결정된다. 에러 상황을 테스트하기 어려움 - 외부 API가..