미리보기

StudyMingle 플랫폼 개발

해외 대학 진학을 튜터와 멘티를 연결하는 커뮤니티 사이트의 백엔드 개발

담당 기능

• Restful API -> GraphQL 서버 마이그레이션

Old Server : NoSQL DB(MongoDB), Rest API 기반의 Nest.js 백엔드 서버

Mig Server : RDBMS(PostgreSQL), GraphQL 기반의 Nest.js 백엔드 서버

• DB Event Notify / Listen 을 통한 SSE 알림

PostgreSQL 이벤트 트리거를 활용해 실시간 알림을 SSE를 통해 사용자에게 전송

• Mailgun API를 활용한 사용자 메일 전송

비밀번호 재설정 코드와 재설정 링크 메일 발송 ->

링크를 통해 재설정 코드 입력 -> 비밀번호 재설정 수행

항해99 Assistant Product Manager

개발자 양성 부트캠프 항해99 16기 담당 운영 매니저

역할

• 일반 행정 전반 관리

일정 관리 : 과제 제출 관리, 성적과 성향에 따른 팀 편성, 만족도 지표 수집, 케어 리포트 작성, 기술 매니저 일정 관리, 수강생 개인 별 담당 기술 매니저의 피드백 전달

학습 관리 : 약 100명의 수강생 개인별 학습 진도 수집, 부진 학생 독려, 학습 간 질문 사항 수집, 강의 수강 중 가장 어려워하는 챕터에 대한 기술 매니저 특강 일정 매칭, 개인 별 담당 기술 매니저 학습 피드백 전달

• Java Spring 기반 코드 학습 관련 질문 응답

강의 기반 질문 답변 : 수강생들이 수강한 강의와 동일한 강의 학습, 특히 입문 강의부터 어려움을 겪는 일부 수강생에게 해당 파트에 대한 부연 설명, 진입 장벽으로 이탈을 고민하던 여러 수강생들의 과정 복귀 도움, 주차별 과제 동일하게 수행 후 조별 순회 시 도움 제공

• 소개 : 대규모 트래픽을 효과적으로 처리하여 안정적이고 확장 가능한 '문화생활 티켓팅 서비스'를 구축하여 사용자들에게 원활한 티켓 구매 경험을 제공.

• Github : Link

• 인원 : Back-End(3명)

• 사용 기술

  • DB : PostgreSQL, Redis

  • Library : Spring Security, Spring Cloud, JPA, QueryDsl

  • Devops : AWS EC2, RDS, Elastic Cache, Kafka, Docker

  • Tools : Github, Notion, Figma, Slack

• 담당 기능 :

1. JPA를 활용한 도메인 CRUD 구현

2. Spring Security를 활용한 JWT 기반 사용자 인증/인가

3. Spring Cloud를 활용한 대규모 트래픽 대비 MSA 아키텍처 도메인 설계

4. Redis 도입, 데이터 캐싱 및 분산락 기반 선착순 쿠폰 발급, 실시간 인기 공연 랭킹 조회에 적용

5. QueryDsl을 활용한 조건별 다중 필터링 검색 기능 구현

• 트러블 슈팅

  • 선착순 쿠폰 발급 시 쿠폰 개수가 올바르게 차감되지 않는 문제

    • 문제 상황 : 쿠폰 발급 API에 Redisson 분산락 적용 - 100개 발급 테스트, 재고 90개 잔여
      
      

    • 문제 원인 : Redis 분산락 처리 사이클 7 ~ 10회 당 PostgreSQL 재고 차감 커밋이 1회 수행
      -> 앞 요청에 의해 재고가 실제로 차감되기 전(100 -> 99) 다음 요청이 재고 개수를 조회 (100)
      
      

    • 해결 방안 : 쿠폰 발급 메서드에 AOP 도입 -> 락획득 사이클과 커밋 사이클 동기화
      1. @DistributionLock 커스텀 어노테이션 제작, 분산락 메타 데이터를 필드로 선언
      2. 쿠폰 발급 메서드에 적용, 어노테이션이 적용된 메서드 호출 시 AOP 우선 실행
      3. AOP Layer에서 분산락 생명 주기와 트랜잭션 단위가 일치하도록 proceed()에 @Transactional 적용
      
      

    • 해결 : 발급 요청 횟수만큼 재고가 올바르게 차감

    ---

  • Jmeter를 활용한 공연 데이터 단건 조회 요청 테스트에서 높은 오류율

    • 문제 상황 : 공연 단건 조회 API 부하 테스트 - 3000 thread, thread per 3 request 반복 요청
      Macbook M2 Pro 10 Core 16GB : 약 15%의 요청에서 에러 발생
      Macbook M1 Air 8 Core 16GB : JMeter 프로세스 무한 로딩, 1500 Thread로 내려서 테스트, 이후 약 12%대의 에러
      
      

    • 문제 원인 : DB connection 제한을 상회하는 요청에 따른 거부 - FATAL: sorry, too many clients에러
      
      

    • 해결 방안 : 대기열 서비스 개발, config에 따른 처리량 조절로 부하 분산
      방법 1 : Redis에 데이터 캐싱 -> 마찬가지로 최대 처리량 상회, Connection Closed 에러 발생
      방법 2 : 외부 DB와의 connection을 제한할 수 있는 방식이 필요 -> 대기열 서버 개발
      => QueueService 개발 : Redis Sorted Set 구조에 대기열 저장, config에 따른 시간당 처리량 설정

      
      
      

    • 해결 : 같은 조건에서 테스트 - 2300ms / 15% error -> 6600ms / 0% error

• 소개 : 공구와 소분 등 지역 커뮤니티를 통해 1인 가구의 합리적 소비를 권장하는 쇼핑몰.

• Github : Link

• 인원 : Back-End(5명)

• 사용 기술 :

  • DB : MySQL, MongoDB, Redis

  • Library : Spring Security, Spring data JPA, QueryDsl

  • Devops : AWS EC2, S3, RDS, Elastic Cache, Docker, Nginx, RabbitMQ

  • View : Html, Css, Javascript, Thymeleaf

  • Tools : Github, Notion, Figma, Slack

• 담당 기능 :

1. JPA를 활용한 도메인 CRUD 구현

2. Spring Security를 활용한 JWT 기반 사용자 인증/인가

3. Thymeleaf를 통한 SSR방식으로 View 구현

4. Let's Encrypt와 Nginx를 활용한 HTTPS 인증

5. S3 저장소에 이미지 업로드 기능 구현

6. QueryDsl을 활용한 조건별 다중 필터링 검색 기능 구현

• 트러블 슈팅 :

  • 배포 시 Kafka 운영을 위한 EC2 메모리 부족 문제

    • 문제 상황 : Kafka 설치 EC2에 SSH 접속 시도 시 Connection Time Out -> 접속 불가
      이후 메세지 전송 요청이 실패하는 현상 -> EC2 메모리 부족에 의한 서버 다운으로 추정
      
      

    • 원인 파악 : 배포 환경 - EC2 t2.micro : 1GB, <-> Kafka Single Node 최소 메모리 : 1GB
      t2.micro의 메모리 리소스가 Kafka Single Node의 최소 메모리 조건을 충족하지 못함
      
      

    • 해결 방안 : Kafka -> RabbitMQ 마이그레이션, + 메시지 기능 재구현
      마이그레이션 근거 :
      1. Kafka Single Node 최소 조건 1GB 대비 RabbitMQ의 최소 메모리 조건: 128MB
      2. RabbitMQ의 경우 메모리 요구량이 낮으면서도 비즈니스 요구사항 충족
      3. 싱글 노드로 메시징만을 위해 Kafka를 도입하는 것은 어플리케이션 스펙 대비 오버 스펙

      
      
      

    • 해결 : 서버 배포 기간 중 Connection Time Out, 메세지 전송 요청 실패 현상 발생 X

      ---