기록하는 개발자

(이 글은 외로운 우테코 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년에 진행한 식물 관리 서비스 프로젝트)의 알림 기능이 문제가 많아 보인다. 프로젝트 막판이라 생각없이 짠 코드가 너무 많다." 처음에 그 말을 꺼냈을 때는 별 관심이 없어 보였다. "이미 끝난 프로젝트이기도 하고...알림? 그거 내가 짠 기능 아닌데? 굳이 신경써야 하나? 그냥 다른 프로젝트 하면 안돼?ㅎㅎ" 하마드는 대충 이런 생각이었다. 하지만 식사 후 서울대입구역 집무실에서 내가 그에게 이 프로젝..

8주차 회고에 앞서 마지막 8주 차에서는 로그인, 로깅 전략 수립, 모니터링 환경 구축을 진행했고 첫 배포인 1.0 버전을 출시했다. 마지막으로 4차 데모데이를 진행했다. 훌륭한 팀원들 덕분에 무사히 레벨 3 프로젝트를 마칠 수 있었다. 로그인 마지막 4차 스프린트에서 구현하기로 했던 로그인 기능을 구현했다. 서비스 특성 상 일반 로그인은 불필요하다고 생각했고, 소셜 로그인 방식을 선택했다. 네이버, 구글, 카카오, 깃허브 등 많은 소셜 로그인을 활용할 수 있지만, 서비스 주 타켓층인 30대 ~ 50대를 고려해 가장 범용성이 높은 카카오 로그인을 사용하기로 했다. 인증을 구현할 방식으로 토큰을 이용한 인증과 세션을 이용한 인증 방식 중 세션 인증 방식을 선택했다. 우선 현재 프로젝트 규모에서 토큰 방식과..

7주차 회고에 앞서 이번 주는 4차 데모데이까지 준비해야 하는 기능 구현을 하는데 모든 시간을 쏟았다. 3차 데모까지 구현한 기능 버그 리포팅을 진행했고, EC2를 추가로 요청해서 개발서버 / 운영서버를 분리했고, 구현 계획에 있던 캘린더를 삭제한 후 히스토리 기능을 고도화하기로 결정했다. 별다른 큰 이벤트 없이 정말 기능 개발만 했다 ! 캘린더 vs 리마인더 고도화 이번 4차 스프린트를 시작하면서 가장 이슈가 됐던 주제이다. 캘린더는 4차 데모데이에 구현할 계획이었기 때문에 이전에는 전혀 1도 관심을 갖지 않았었다. 이제 기능 개발에 들어가려고 하니 생각보다 리마인더와 히스토리에서 제공하는 기능과 많이 닮아있었다. 기획 당시에 생각했던 캘린더의 모습이다 ! 반려 식물별로 기록을 모아볼 수 있다는 가치로..

6주차 회고에 앞서 이번 주는 3차 데모데이 발표가 있었기 때문에 3차 데모데이를 준비를 위주로 시간을 보냈다. 3차 데모데이 핵심 기능인 리마인더, 타임라인, 반려식물 상세 조회 기능을 모두 구현했고 무사히 시연했다. 이번 데모데이 발표는 하마드와 참새가 담당해 주었고 발표를 깔끔하게 잘해준 덕분에 우리 팀이 보여주고 싶은 부분을 잘 보여줬다 ! 리마인더 피움 서비스의 핵심 기능 중 하나인 리마인더 기능 구현을 완료했다 ! 현재 물을 주지 않은 태스크가 존재하면 화면을 빨간색으로 보여주고 지각한 물 주기가 없고, 오늘 물주기 테스크가 있는 경우 초록색 오늘의 물주기 테스크가 모두 처리되어 앞으로의 물주기 데스크만 남아있으면 그레이색 리마인더 기능은 기획적으로 회의도 가장 오래 걸렸던 부분이고, 개발 과..

5주차 회고에 앞서 이번주는 3차 데모데이에 필요한 기능을 구현하는 일정을 위주로 진행했다. 3차 데모데이 요구사항인 HTTPS 적용 및 WS + WAS 연결을 통해 443 포트로 데모, DB 테이블 drop 막기 등을 완료했고, 3차 데모데이의 핵심 기능인 리마인더 기능과 반려 식물과 관련된 기능 개발을 진행했다. 완료한 기능들은 모두 피움 팀 기술 블로그에 게시하였다. 캠퍼스 이동 이번 5주차를 기점으로 캠퍼스 이동을 했고, 월요일부터 선릉 캠퍼스로 출근했다. 선릉으로 캠퍼스를 이동하기 전에 팀원들과 자리에 대해 걱정을 좀 했었는데,,, 다행스럽게도 랜딩 강의장을 사용할 수 있게 되었다 ! 이 날 하마드가 자리를 뽑으러 갔는데, 오늘의 운세까지 확인하고 갔다 ㅋㅋㅋ 하마드 기세 덕분에 랜딩 강의장에 ..

4주 차 회고에 앞서 이번주는 2차 데모데이를 중심으로 일정을 진행했다. 2차 데모데이까지 목표한 API 개발을 완료했고, CI/CD, CORS, 프론트 배포와 같은 프로젝트 전반적인 설정도 모두 완료했다. 이번 데모데이는 클린과 조이가 발표를 담당했다. 역시 우리 팀원들 답게 너무너무 잘해줘서 무사히 마칠 수 있었다 ! 이번 데모데이를 마치고 팀 회식도 함께 진행했다. 메인페이지 이번주에 가장 먼저 배포된 페이지는 메인 페이지였다. 메인 페이지에서는 사전 식물을 검색할 수 있다. 사전 식물이란 'Dictionary-Plant' 즉, 식물 도감을 의미하며 원하는 식물을 검색하여 정보를 얻을 수 있다. 현재 데이터베이스에는 200개 이상의 식물 데이터가 추가되어 있는데 점점 더 늘려갈 계획이다. (절대 포..

이번 피움 서비스에서 CI/CD를 적용하기 위해 Jekins와 Github Webhook을 이용했습니다. 본 글에서는 Jenkins와 Github Webhook을 이용한 SpringBoot 서버 자동 빌드, 자동 배포 과정을 다루겠습니다. Jenkins 설치 과정은 피움 팀 블로그 를 참고하시면 됩니다 ! 작업 환경 - 인스턴스: AWS EC2 t4g.small - OS: Ubuntu 22.04.2 LTS - RAM: 2GB Jenkins 접속 젠킨스를 접속하는 방법은 간단합니다. 젠킨스를 설치한 인스턴스 public IP와 port를 주소창에 입력하면 쉽게 접근할 수 있습니다. 정상적으로 접속하면 다음과 같은 화면을 만나게 됩니다. Github Webhook 설정 먼저 Webhook을 설정하기 위해 현..