GYUD-TECH

뉴젯 프로젝트에서 동시에 발송되는 뉴스레터로 인해 메일 수신 처리가 오래 걸리는 문제를 발견하였다. 캐싱과 같은 기법을 도입하여 이를개선하고자 하였는데, 도입 이전에 성능을 측정하여 현재 상태를 진단하고, 정확한 성능 측정 개선 정도를 파악하하고자 하였다. 성능 측정을 위해 nGrinder를 설정하며 겪었던 문제점과 Docker를 활용해 테스트 환경을 구축한 경험에 대해 자세히 소개할 예정이다. nGrinder 소개부하 테스트의 대표적인 도구인 JMeter와 비교하여 nGrinder가 가벼운 리소스를 사용하기 때문에 nGrinder를 활용한 부하 테스트 방식을 선택하였다. nGrinder를 사용할 때 controller와 agent의 개념이 나오는데 이 구조를 이해하면 테스트 환경 구축도 이해하기 쉬워 ..

뉴젯은 업무메일과 뉴스레터가 섞여 뉴스레터를 읽지 못하고 쌓아 놓기만 하는 문제를 해결하기 위해, 뉴스레터만을 위한 독립된 서비스를 제공합니다. 현재 뉴젯의 누적 사용자는 약 2,600명으로 하루 평균 8명 정도 지속적으로 서비스 사용자가 늘고 있다. 사용자가 늘어남에 따라 메일 수신 시스템의 성능 저하 문제가 발견되었다. 뉴스레터는 발행자가 전송을 누른 시점 일괄적으로 발송되기 때문에, 동시에 많은 요청이 서버로 전달된다. 뉴젯에서 가장 인기있는 뉴스레터 뉴닉의 경우 현재 637명이 구독하기 때문에 한번에 637개의 메일 수신 요청을 처리해야 한다. 메일 수신 모듈의 경우 이전에 분리를 하였지만, 수신한 메일에 대한 구독 관리 및 알림 전송을 위해 수행하는 뉴스레터 테이블 조회에서 성능 저하 문제가 ..

뉴젯 서비스의 메일 수신 로직을 스프링 서버로 분리하면서 객체지향에 초점을 맞추어 코드를 작성하고 있다.Service 계층은 Repository에서 데이터를 가져와서 도메인에 비즈니스 로직을 실현하는 역할을, Repository는 데이터를 가져와서 도메인으로 변화하는 역할을 수행한다. 이를 통해 확장성이 좋은 구조를 설계하려 한다. 테스트 코드를 먼저 작성 후 비즈니스 로직을 작성하면서, 테스트를 얼마나 간단하게 작성할 수 있는지를 고민하였다. 이 과정에서 테스트가 어려운 객체들의 역할을 잘게 나누고, 외부 주입을 통해 숨겨진 입력을 제거하면서 더욱 객체지향스럽게 구조를 바꾸고 있다. 이 과정에서 했던 좋은 설계에 대해 많이 고민하게 되었고, 자연스럽게 디자인 패턴과 DTO의 등장을 이해하는 경험이 되었..

SW 마에스트로 개발팀에서는 Git-flow 전략을 사용하였습니다. 초기 MVP 개발을 진행하였기 때문에 dev, feature, main 브랜치를 주로 사용하였고, 배포는 수동으로 진행하였습니다. 하지만 수동으로 서비스를 배포하다보니, 배포를 잘못 하거나 생략한 경우도 있었고, 코드 테스트도 제대로 이루어지지 않았습니다. 따라서 이를 해결하기 위해 새로운 Spring 서버에서는 CI를 구축하고자 합니다. 이번 글에서는 CI 구축 과정에서 공부한 내용들과 어려움들에 대해 소개합니다.(CD는 추후 배포 단계에서 구축할 예정입니다.) event 및 branch rule 설정우선 dev, main 브랜치의 push 작업을 막기 위하여 git branch rule을 설정하여 push를 막고, pr로만 merge..

SW 마에스트로 과정 종료 이후, 뉴젯 서비스를 지속적으로 운영하며 그동안 쌓였던 기술적 부채들을 하나씩 해소하며 서비스를 개선하고 있습니다. 이번 글에서는 데이터이스 성능 최적화를 진행했던 과정을 기록하였습니다. 고객이 가장 많이 이탈하는 지점에서 쿼리 성능을 측정하고, 이를 다양한 실험을 통해 최적의 방식을 도입하여 문제를 해결한 경험에 대해 자세히 소개합니다. 문제 상황: 쿼리 성능 문제로 인한 고객 이탈뉴젯 서비스를 운영하며 고객 행동 데이터를 분석하기 위해 GA를 활용해 사용자 데이터를 추적하고 있습니다. 특히 고객 이탈율을 낮추기 위해 GA 보고서를 활용해 사용자 이탈 지점을 찾아 원인을 분석하여 이를 해결하고자 하였습니다.분석 결과 아래와 같이 사용자들은 앱이 로딩되는 시점인 스플래시 화면에..

뉴젯 서비스는 하루 평균 10,000개 정도의 뉴스레터를 수신하고 있습니다. 메일들은 Node.js의 SimpleParser 라이브러리를 통해 파싱 이후 메타데이터와 함께 DB 및 파일 저장소에 저장됩니다.  이번 글에서는 현재 아키텍처에서 발생한 문제들을 소개하고, 실험을 통해 해결책을 찾아가는 과정에 대해 자세히 소개합니다.문제 상황서버 비용 절약을 위해 파싱 작업 역시 Supabase API 서버에서 처리하였기 때문에, 평균 3초 정도의 긴 시간이 소모되었습니다. 또한 Supabase API 서버에 메일 파싱 요청을 전달하는 Lambda 함수도 메일 저장 여부 확인 후 종료되는 방식으로 구현되어 있어 함수의 Duration, Throttling 지표가 높게 측정되었습니다. 이로 인해 Lambda의 ..