미리보기

- 기술 스택

• Spring Framework 2.7.13, Java17, Mysql, Spring Data Jpa, AWS SQS

- 개발 인원 (총 4명)

• 백엔드(1명), 프론트(2명), 디자이너(1명)

- 상세 내용

• "대학축제 때 대학생들끼리 새로운 친구를 만들 수 있게 해주는 서비스"
  [ 프로젝트 깃허브 주소 ]

- 배포 URL

• https://dis-tance.com

- 담당 역할

[ Backend ]

• JWT 로그인 방식을 사용해 사용자, Back Office 관리

• STOMP를 활용한 사용자들 간 1:1 실시간 채팅 

• AWS SQS를 통한 FCM 알림구축

• 전화번호 인증을 위한 문자 API 연동

• SSE를 통한 실시간 채팅 목록 관리

[ Infra ]

• AWS EC2를 활용해 서버 배포

• AWS RDS를 활용한 DB replication 구현 (master / slave 분리)

• Nginx를 통한 Load Balancer 구현 및 Blue/Green 배포

• CI / CD pipeline구축

• Prometheus & Grafana를 통한 모니터링 환경 구축

- Trouble Shooting Experience

• 채팅 기능이 있다보니 DB의 read/write 작업이 많아짐에 따라 DB I/O 성능 이슈를 발견

  • AWS RDS에 있던 기존 DB를 master/slave 로 분리하여 read작업인 경우에는 slaveDB에서, write인 작업에서는 masterDB로 분산을 시켜서 I/O 성능 이슈를 해결
    ( 피크시간(0.am ~ 1.am)인 경우 21.7ms를 유지했고, 평균 응답시간이 14ms를 유지 )
    

• 첫서비스 배포 후 유저 유입이 200명이 들어왔지만 Error로그를 관리자가 실시간으로 확인할 수 없는 이슈

  • Unchecked Exception을 제외한 주로 Internal Server Error 와 같은 에러 발생 시 Slack으로 로그가 전송되도록 해결

    
    

• 기존 FCM알림을 @Scheduled를 활용하여 전송하였는데 특정 시간마다 CPU사용률이 너무 높아지는 현상 발견

  • AWS SQS와 Lambda를 활용하여 채팅메시지가 도착하면 SQS로 FCM 내용을 전달하고 Lambda가

    
    Trigger해서 FCM 전송하여 CPU 이슈 해결
    

• 트래픽으로 인한 서버 다운

  • 서버가 다운된 시점의 Grafana를 분석해 문제점을 파악 후 메모리 부족이 원인(Heap 사용률이 87.3%)임을 알고 EC2 T2.micro -> T2.large로 유형 변경,
    서버가 다운된 시점의 로그가 찍히지 않는 이슈로 인해 별도의 모니터링 서버 구축

[ 블로그 포스팅 ]

- 기술 스택

• Spring Framework 2.7.17, Kotlin, Mysql, Spring Data Jpa, Docker, Docker-compose, CI/CD, AWS Ec2

- 개발 인원 (총 3명)

• 백엔드(1명), IOS개발자(1명), 디자이너(1명)

- 상세 내용

• "취준생 개발자를 위한 스마트 TodoList"
  [ 프로젝트 깃허브 주소 ]

- 배포URL

• [Appstore : https://apps.apple.com/kr/app/tdd/id6667115881 ]

- 담당 역할

[ Backend ]

• Apple 소셜 로그인 방식을 사용해 사용자 관리

• Gituhb 소셜 로그인을 통한 Github ReadME, Issue, Repository API 활용

• FCM을 통한 알림구축

• Webhook을 통한 Github와 DB 연동

• OpenAI를 활용하여 학습 커리큘럼 추천

[ Infra ]

• AWS EC2를 활용해 서버 배포

• Nginx를 통한 Blue/Green 배포 구현

• CI / CD pipeline구축

- Challenges and Solutions

1. Problem 1 : Todo 등록 비즈니스 로직에서의 코드 오염

   • Description : Todo를 등록하는 비즈니스 로직에서의 이벤트리스너를 통한 Git이슈와 리드미 생성하는 코드로 인한 오염되는 이슈

   • Analysis : Todo 비즈니스 레이어에 EventListener 의존, SRP책임 위반

   • Solution : AOP를 활용해서 어노테이션 생성 및 어노테이션 사용을 통한 의존성 제거

   • Outcome : Todo 비즈니스 레이어에선 EventListener의 의존을 받지 않고, 어노테이션을 통한 재활용성 증가

2. Problem 2 : DB에서 사용자 Repo컬럼 유무 확인

   • Description : Todo를 등록할 때 깃 이슈와 리드미를 작성할 DB의 Repo컬럼 Null유무를 모든 컨트롤러 코드에서 작성해야 하는 번거로움

   • Analysis : 모든 요청마다 validation코드 주입을 통한 코드 오염

   • Solution : Security Filter에서 Repo Filter를 추가해서 로그인한 사용자의 Repo컬럼 Null 유무를 확인

   • Outcome : 모든 요청마다 불필요한 Validation코드 불필요

- Trouble Shooting Experience

• Apple 소셜로그인 중 ApplePubilcKeys를 통해 Token검증하기 때문에 모든 API의 Response Time이 오래걸리는 이슈 (캐싱처리 되지 않은 경우 1.4s ResponseTime 발생)

  • Apple에서 받은 JWT Token을 디코딩 후 자체 JWT Token생성 (1.4s -> 238ms 로 응답시간 단축)

[ 블로그 포스팅 ]

- 기술 스택

• Spring Framework 2.7.17, Java11, Mysql, Spring Data Jpa, Query dsl, Docker, Docker-compose, CI/CD, NCP

- 개발 인원 (총 6명)

• 백엔드(1명), 프론트엔드(2명), 기획자(1명), 디자이너(1명), 마케터(1명)

- 상세 내용

• "이스라엘과 팔레스타인의 전쟁으로 피해를 입은 가자지구 주민들에게 응원메시지를 전달해주는 서비스"
  [ 프로젝트 깃허브 주소 ]

- 담당 역할

[ Backend ] 

• Query dsl를 통한 동적 쿼리 구현

• JWT 로그인 방식 구현

• 커스텀한 라이브러리를 활용해 욕설 필터링 구현

• 예외처리를 목적에 맞게 커스텀 예외처리

[ Infra ]

• NCP를 통한 서버 배포

• Docker를 통해 이미지 생성 및 Docker-compose를 활용해 배포

• CI/CD를 통한 자동화

- Trouble Shooting Experience

• 이전까진 Session방식을 이용해 로그인을 하고 있었는데 만약 다수의 서버가 있다면 stateful 방식인 Session방식은 서버가 변경될 때마다 사용자가 재로그인을 해야하는 단점 발견

  • stateless방식인 JWT 방식을 적용하여 다수의 서버가 있어도 사용자가 재 로그인을 하지 않도록 변경

• 메시지를 불러오는 부분에서 단순 메시지 조회인데도 불구하고 메시지 로드 시간이 오래 걸리는 것을 확인

  • Caching을 통해 메시지 조회 로드 시간 단축 ( 362ms -> 3ms )
    

• 로컬에서 정상적으로 동작하여 CI 후 CD를 바로 진행했지만 서버에서는 동작하지 않는 이슈 

  • 서버를 dev와 prod서버를 두어서 우선 dev서버에 Trigger를 통해 배포를 진행한 후 이상이 없다면 prod서버에 배포

[ 블로그 포스팅 ]

[주요 내용]

• 9oormthon univ 2기 미르미 백엔드 미르미로 참여하여 1박 2일동안 해커톤에 참여하였습니다.

• "Distance" 프로젝트 백엔드 파트로 참여해 채팅기능, 유저 관리, 축제 정보 관리, FCM 알림 기능 등 전체적인 기능을 맡았습니다.

[ 어려웠던 부분 ]

• 제한된 시간 안에 MVP기능인 채팅 기능을 단순 메시지만 보내는 것이 아닌 채팅방에 들어온 경우를 인식해서 메시지 읽음 표시를 반영하는 부분을 구현하면서 많은 고민을 하였습니다.

  • EventListener를 통해 채팅방에 들어오는 API를 인식하여 Session 테이블을 두어 Session 값이 들어오면 사용자가채팅방에 들어온 것으로 확인한 후 읽음표시를 최신화하였습니다.

• FCM알림이 전송되지 않은 유저들은 어떻게 해결해야할지 고민을 하였습니다.

  • 기존의 @Scheduled를 사용하는 방식에서 AWS SQS를 활용해 사용자에게 카카오톡처럼 즉각적인 채팅알림이 가도록 해결하였습니다.

• Flutter 기반 '바로홈' 모바일 애플리케이션 개발

  • 바로홈팀에서 모바일 애플리케이션 개발에 참여하여 앱의 주요 기능을 개발(메인, 발주, 공지사항 페이지)

  • RiverPod 상태관리 라이브러리를 활용한 효율적인 상태관리 구현

  • 사용자 인터페이스 최적화 및 성능 개선

• Ktor & Kotlin 기반 백엔드 API 개발

  • 백엔드 API(Ktor & Exposed)의 설계 및 구현을 주도적으로 수행하였으며, 공지사항 갯수 불러오기와 같은 기능을 개발.

  • 데이터 처리 로직 최적화를 위한 Exposed DB 쿼리 튜닝하여 20s -> 1.2s 로 응답시간 감소

• IOS/Android 앱 배포

  • IOS 및 Android 운영 체제에 앱을 배포하고, 앱 스토어 등록, 업데이트 작업을 수행