기록하는 개발자

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 현재 비동기 호출과 FCM의 sendAsync를 통해 FCM 알림 호출까지 비동기로 처리하고 있다. 하지만… String response = FirebaseMessaging.getInstance().sendAsync(message).get(); 여기서 get() 메서드가 자꾸 눈에 걸렸다. 자바 5에서 비동기 함수의 리턴 값을 받을 수 있도록 Future 객체가 등장했고 Future 객체에 값을 꺼내기 위해 get 메서드를 사용한다. FirebaseMessaging의 sendAsync의 반환 타입인 ApiFuture에서 get 꺼내는 동작을 찾아보니 블록킹 방식으로 동작하고 있었다. 추가적으로 자..

문제 발생 비동기 처리와 스레드 풀 튜닝을 통해 알림 기능을 개선하며 성능 테스트 하던 중, 문제가 발생했다. ?????????????? 갑자기 CPU 수치가 급등해 99.9%를 찍게 되는 현상을 발견했다. 알림을 처리하는 중 간헐적으로 발생하는 것이 아닌, 배포를 완료한 직후 요청(초반)에만 발생한 후 천천히 내려가는 것을 파악했다. 가용 중인 애플리케이션에서 CPU 수치가 99%를 찍는다는 것은 굉장히 위험한 징후다. 누가 CPU를 좀먹고 있었을까? 해당 현상을 확인하기 위해 다양한 시도를 했다. * 배포 직후 스레드 덤프 → 총 32개 스레드 먼저 스레드 덤프를 통해 확인해보니 알림 요청이 오기 전에는 비동기 스레드가 생성되지 않다가, 알림 요청이 온 이후에야 스레드가 생성 후 RUNNABLE 상태..

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 동기적 알림 처리를 비동기로 수정 @Component @RequiredArgsConstructor public class NotificationEventListener { private final NotificationService notificationService; @EventListener @Async public void handleNotificationEvents(NotificationEvents notificationEvents) { for (NotificationEvent event : notificationEvents.getNotificationEvents()) { notificat..

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 사건의 발단 때는 23년 12월 말...하반기 공채에 무참히 실패한 우테코 5기 수료생 두 남자가 만났다. 서울대입구 라멘집에서 늘 그렇듯 일상적인 개발 얘기를 하던 와중 말을 꺼냈다. "피움(23년에 진행한 식물 관리 서비스 프로젝트)의 알림 기능이 문제가 많아 보인다. 프로젝트 막판이라 생각없이 짠 코드가 너무 많다." 처음에 그 말을 꺼냈을 때는 별 관심이 없어 보였다. "이미 끝난 프로젝트이기도 하고...알림? 그거 내가 짠 기능 아닌데? 굳이 신경써야 하나? 그냥 다른 프로젝트 하면 안돼?ㅎㅎ" 하마드는 대충 이런 생각이었다. 하지만 식사 후 서울대입구역 집무실에서 내가 그에게 이 프로젝..