기록하는 개발자

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

피움 서비스의 런칭 페스티벌을 무사히 마쳤습니다. 런칭 일정에 맞춰 빠르게 개발을 진행하다 보니 꼼꼼하지 못한 부분이 존재했고, 다음 개발에 착수하기 전 부족한 부분을 개선하고 넘어가기로 했습니다. 먼저 서비스 내에서 발생하는 모든 쿼리를 정리해보았습니다. 현재 서비스의 모든 기능을 인수 테스트로 작성했기 때문에 인수 테스트를 하나씩 돌려보며 발생하는 쿼리를 추적했습니다. JPA를 사용하는 환경에서 스프링 properties 설정 중 아래 옵션을 설정하면 쿼리를 확인할 수 있습니다. spring.jpa.show-sql=true spring.jpa.properties.hibernate.format_sql=true 현재 서비스에서 사용하고 있는 API에서 발생하는 쿼리를 위와 같이 정리하였고 개선이 필요한 ..

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

CloudWatch는 AWS에서 제공하는 모니터링 툴입니다. 기존에 프로메테우스와 그라파나를 활용해 모니터링을 할 수 있었지만, 현재 보유 중인 서버가 모두 가용 중이고 가용 중인 서버에 모니터링 툴을 설치하는 경우 다른 서버들이 영향을 받을 수 있기 때문에 별도의 툴이 필요했습니다. 그래서 EC2 인스턴스를 추가로 생성해 모니터링용 서버를 구축할 수 있었으나, 비용(금전)적으로 cloud watch를 사용하는 것이 훨씬 비용 절감이 되고 적용과정도 비교적 간편하기 때문에 AWS CloudWatch를 사용하기로 결정했습니다. CloudWatch 적용 과정 클라우드 와치를 인스턴스에 적용하기 위해서는 권한이 필요합니다. IAM을 발급 받는 방법은 다른 블로그에서 쉽게 찾을 수 있기 때문에 생략하고, 적용하..

로깅이란 ? 우리가 처음 개발을 할 때 System.out.println(), cout

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

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