• SNAPPI 서비스 개발
  • 결제 서비스, 알림 서비스, 리뷰 서비스, 쿠폰 서비스 등 다양한 API의 개발 및 유지보수
• CLIVEWORKS 서비스 개발
  • 정산 서비스, 알림 서비스, 작업물 할당 서비스, 데이터 정제 서비스 등 다양한 API의 개발 및 유지보수
• 스케줄 배치 환경 구성 및 개발
  • Jenkins와 Spring Batch를 기반으로 스케줄 배치 환경 구성
  • 사용자 추이 분석, 정산 처리, 영상 데이터 정제 작업을 위한 배치 작업 개발
• 팀 내 개발문화 확립
  • 시니어 개발자가 없는 상황에서 소규모 팀의 개발 문화 정착을 주도
  • 공통 API 문서 도입 및 알림 시스템을 통한 협업 강화
  • 백엔드 내부 기능 및 인프라 작성 및 관리
  • Git Flow 방식을 도입하여 개발 워크플로우 개선
• 서비스 설계
  • 데이터베이스 설계: 초기 요구사항을 바탕으로 확장에 유연한 데이터베이스 스키마 설계
  • API 설계: REST API 디자인 가이드에 맞게 API 설계

프로젝트 설명

• 자신이 가지고 있는 동여상 및 유튜브 등 수많은 동영상을 언어의 제약 없이 시청할 수 있도록 돕는 서비스를 개발했습니다.

역할

• 아래의 서버를 설계 및 개발 진행하였습니다.

1. 업로드 및 번역 서버

2. 결제 서버

3. 각종 이벤트/쿠폰 지급 서버

4. 알림 서버

문제점 1 : 동영상 업로드 시 많은 자원 사용 및 스토리지 비용 증가

• 오픈 베타 기간 사용자 문의에서 10분 이상의 동영상 업로드 필요성이 제기되었습니다.

• 많은 사용자가 동시에 동영상을 업로드할 경우 리소스 사용이 급증하고 서버 부하로 인해 진행 속도가 느려지며 사용자 경험이 저하되었습니다.

해결 방법

1. 서버 분할

   • 기존에는 영상 업로드, 자막 생성, 번역이 모두 한 서버에서 이루어졌으나, 이를 각각의 서버로 분할하여 각 서버가 특정 작업만 처리하도록 했습니다.

   • 서버 분할을 통해 한 서버에 문제가 발생해도 다른 비즈니스 로직에는 영향을 주지 않도록 하였습니다.

2. 업로드 서버 새로운 로직 개발

   • 기존 방식은 영상을 한 번에 업로드하는 것이었으나, TUS 프로토콜을 사용하여 영상을 약속된 청크 단위로 업로드하도록 수정했습니다.

   • 이를 통해 빠르고 안정적인 서버 구축이 가능해졌고, 많은 사용자가 동시에 업로드해도 서버가 다운되지 않게 되었습니다.

결과

• 사용자가 대용량 영상(2GB, 2시간)을 안정적으로 업로드할 수 있게 되었습니다.

문제점 2 : 중복 유튜브 영상 업로드

• 사용자가 증가함에 따라 유튜브 링크를 통한 이용량이 많아졌고, 인기 동영상과 같은 중복 영상의 요청이 증가했습니다.

• 동일한 영상이 스토리지에 중복으로 저장되어 스토리지 비용이 증가했습니다.

• 중복 영상 요청 증가로 인해 유튜브 API 리소스가 낭비되었습니다.

• 중복 영상 번역으로 인해 AI 서버 자원이 낭비되었습니다.

해결 방법

1. 유튜브 영상 중복 업로드 로직 변경

• 유튜브 영상을 가져올 때 먼저 Redis에서 해당 영상의 정보를 확인한 후, 기존에 있는 경우 이를 재활용하는 로직으로 변경하였습니다.

2. 기존에 있던 번역 서비스 제공

   • 기존에 있던 영상인 경우 번역 API를 호출하지 않고, 기존 번역 정보를 활용하여 사용자에게 제공하도록 로직을 변경했습니다.

결과

• 이를 통해 스토리지에 중복 영상 저장을 방지하고, 유튜브 API 리소스를 효율적으로 사용할 수 있게 되었습니다.

• 최대 115번의 API 호출을 1번의 호출로 해결할 수 있었습니다.

문제점 3 : 결제 서버 개발의 어려움

• 무료 체험 기간이 끝난 후 수익화를 대비하여 결제 PG사를 통한 결제 시스템을 만들었습니다.

• 결제 문제에 PM, 상사들과 정책을 정하는 과정에서 환불, 멤버십, 등급제 등등 여러 요구사항이 나왔습니다.

• 해당 요구사항을 구현하는 것에 있어 DB 설계 및 비즈니스 로직 개발에 어려움이 있었습니다.

해결 방법

1. PG사의 데이터 구조 파악 후 테이블 설계

   • PG사에서 제공하는 데이터 구조를 파악하여 데이터를 저장하고 사용자와 결제 물품 간의 연관 관계를 파악할 수 있도록 테이블을 설계하였습니다.

2. 결제 로직 구체화

   • 결제 시 프론트에서 결제 요청을 보내고, 기본 데이터를 받아 여러 가지 검증 로직을 거치는 방식으로 개발하였습니다.

3. 결제 완료 후 데이터 일괄 분리

   • 결제가 완료되면 결제 정보가 담긴 JSON을 일괄적으로 분리하여 저장하는 스케줄 배치를 개발하였습니다. 이를 통해 실시간으로 데이터를 분리 저장하는 불필요한 작업을 제거했습니다.

결과

• 사용자가 결제를 통해 서비스를 이용할 수 있게 되었습니다.

문제점 4 : 알림 API 과다 호출

• 기존 알림을 보여주는 방식은 프론트에서 새로운 알림이 있는지 확인하는 API를 지속적으로 호출하는 방식 (2초당 한번씩)

• 알림이 없는 상황에서도 수 많은 API가 호출되었으며 자원이 낭비되고 있었습니다.

해결 방법

1. SSE(SERVER-SENT-EVENT) 방식 알림 개발

   • 한 번의 요청으로 사용자와 서버의 연결을 일정 시간 동안 유지하고, 이벤트가 발생하면 알림이 가도록 리팩토링했습니다.

2. SSE 방식 사용 시 TCP Connection 문제 해결

   • 사용자가 여러 페이지를 열 경우 TCP Connection을 모두 차지하는 문제를 해결하기 위해, 새로운 동작이 발생할 시 연결을 새로 열고 기존 연결은 삭제하도록 수정했습니다.

결과

• 알림 시스템의 효율성이 향상되고 서버 자원 낭비가 줄어들었습니다.

• 분당 평균 600회 -> 10회 호출로 98% 감소

프로젝트 소개

• 2023 AI 학습 데이터 구축 사업(국가 과제)을 위해 영상을 발화 문장 별로 잘라 번역하고 데이터화하는 서비스입니다. 사용자가 영상을 보고 영상의 발화를 타임라인에 맞게 입력하면, 그에 맞게 영상 데이터를 분리합니다. 번역이 완료된 데이터를 영상 + 자막 + 번역으로 제공하여 학습 데이터 기준에 맞도록 제작합니다.

역할

• 아래의 서버를 설계 및 개발을 진행했습니다.

1. Spring Batch 서버 (문장 발화별 영상 분리 서버)

2. 번역 서버

3. 어드민 서버

문제점 1 : 작업량 급등시 Spring Batch 성능 저하

• 사용자의 작업량이 많아질수록 영상의 종류가 다양해지면서 데이터로 만드는 Spring batch 서버에서 속도 저하가 일어낫습니다.

  해결 방법

  1. single insert -> bulk Insert 변경

     • 초기 개발에서는 for문을 통해 데이터를 insert 하고 있었고, 이를 mybatis bulk insert로 변경했습니다

     • 2000~3000 데이터를 bulk insert로 변경하여 7~9초 걸리던 것을 약 1초 가량으로 속도향상이 일어났습니다.

  2. 서버의 cpu 사양 업그레이드

     • FFmpeg 명령어를 사용하여 영상을 분리했으며, 데브옵스 팀과 협업하여 CPU 사양을 업그레이드함으로써 영상 분리 속도를 향상시켰습니다.

  3. FFmpeg 명령어 리팩토링

     • 초기 개발에서는 오디오만 추출하는 FFmpeg 명령어를 사용했습니다.

     • -i(원본 동영상 파일) 옵션과 -ss옵션(작업을 시작할 시간 지정)의 순서를 변경하여 속도를 하였습니다.

       • -ss옵션이 -i옵션보다 뒤에 있을 경우 동영상의 첫프레임부터 검색을 하지만 -ss옵션이 앞에 있을 경우 해당 시간부터 바로 작업을 시작합니다.

       • 이를 통해 모든 구간에서 오디오를 추출하는 것을 1초 미만이 걸리도록 개선하였습니다.

     • -vn 옵션을 통한 비디오 디코딩을 진행하지 않도록 수정하였습니다.

     • 사용 명령어 예시

       ffmpeg -ss 00:01:00 -i input.mp4 -t 00:01:00 -vn -acodec copy output.wav
       

  결과

  • 기존 1시간 영상 기준 약 2000문장을 분리하고 저장하는 것까지 20분 -> 11분으로 약 45%성능 향상을 이뤘습니다.

문제점 2 : 어드민 페이지 조회속도 저하

• 데이터가 많아지는 중반시점부터 어드민 페이지에서 결과물을 조회하는 속도가 느려졌습니다.

• 로그 분석 결과, 데이터 조회가 매우 느려진 것을 확인했습니다.

  해결 방법

  1. 쿼리 수정

  • 검색해오는 데이터의 조건을 기존에는 완료,미완료, 진행중 전체 조건에 따른 다른 쿼리를 사용하였습니다.

    • 완료인 경우 INNER JOIN을 진행중인 경우 LEFT JOIN을 미완료인 경우 JOIN을 하지 않고 가장 기본적인 정보가 가져오도록 수정하였습니다.

    • 쿼리를 나눌 경우 가장 먼저 테이블에서 검색되는 데이터의 양이 줄어들었으며 그에 따라 속도도 향상되었습니다.

    • 쿼리를 나눠 조회를 하기에 넘겨받는 파라미터에 조건을 추가하였습니다.

  2. 인덱스 수정

  • 기존에는 인덱스를 사용하지 않고 있었기 때문에 조건절과 Join절에 걸려있는 조건을 인덱스로 추가하였습니다.

    • 인덱스를 추가한 방법으로는 중복되는 데이터의 양이 낮은 순(카디널리티가 높은 순)으로 인덱스를 걸었습니다.

    • 조건절에 걸려있는 순서대로 인덱스를 추가했습니다.

      SELECT *
      FROM tableA
      WHERE complete = 'complete'
      AND complete_date > 20230304;
      

      이라면 인덱스를 추가할때 complete -> complete_date순으로 인덱스를 걸었습니다.

    • 또한, Join절에서 사용되는 열에 인덱스를 걸어 성능을 높였습니다.

    • 운영 후반부 완료의 경우가 40%를 넘어갔을때 기존에 설정한 index를 없애는 작업을 하였습니다.

      • 인덱스의 경우에는 적은양의 데이터를 조회할때 유리하고 후반부에는 index의 효과가 미미해져 기존에 있던 index를 줄이는 방향으로 진행하였습니다.

  결과

  • 쿼리, 인덱스 수정을 통하여 기존 2초이상 걸리던 조회 작업을 1초 미만으로 줄이며 50%이상의 성능 개선을 맞쳤습니다.