● 2024.07 - 2024.08 영상의 BPM 추출 서버 신규 개발 및 유지보수 영상에서 재생되는 음악의 BPM 정보를 추출 역할: 백엔드 개발자 기여도: 100% 기술스택: Python, AWS, docker, essentia 성과: - python, essentia 이용해서 서버로직 작성 - docker, AWS ECR 이용해서 서버 배포 - AWS Cloudformation로 AWS Batch 리소스 생성 및 관리 - AWS SQS, Batch으로 bpm 추출 작업 비동기 처리 ● 2023.02 - 2023.06 Pose estimation 서버 신규 개발 및 유지보수 요청받은 영상에 담겨진 이용자의 자세 정보를 추출해서 JSON 형태로 저장하는 기능 역할: 백엔드 개발자 기여도: 100% 기술스택: Python, AWS, docker, openCV 성과: - python, openCV 이용해서 서버로직 작성 - docker, AWS ECR 이용해서 서버 배포 - AWS Cloudformation으로 AWS Batch 리소스 생성 및 관리 - AWS SQS, Batch으로 pose estimation 작업 비동기 처리 - AWS Batch로 서버 운영해서 AWS EC2 대비해서 비용 절감 문제경험: 1. 생성된 pose data가 AWS SQS를 통해서 Lambda를 호출 후 DB에 저장됨. pose estimation이 호출될 때마다 SQS에 message가 대량으로 전송되서 짧은 시간 내에 대 량의 Lambda container를 생성함. 이는 곧 db connection 수를 과도하게 늘려서 db에 접속하는 다른 서버에도 장애를 일으킴. maximum concurrency 파라미터를 조절해서 처리 속도를 타협해서 db connection 문제를 해결함. ● 2022.10 - 2024.09 Sparky mobile 신규 API 개발 및 유지보수 / 운영 https://sparky.tv 역할: 백엔드 개발자 기여도: 100% 기술스택: Typescript, Node.js, Mysql, PrismaOrm, Webpack, AWS, Serverless framework, vitest, FCM 성과: - Serverless framework와 Cloudformation을 이용한 AWS Infrastructure 배포. - AWS APIGateway, Typescript와 Prisma ORM을 이용한 백엔드 서버 로직 구현. - Webpack을 이용한 transpiling - Prisma를 이용한 DB schema 마이그레이션 - RDS를 이용해 Mysql Database 운영. - AWS IAM을 이용한 role, group, user 권한 관리. - Mysql 테이블 설계 및 마케팅 분석용 데이터를 위한 쿼리 작성. - Cognito를 이용한 Oauth 인증 및 Authorizer로 유저 권한 확인. - AWS Secrets Manager와 KMS를 이용해 데이터베이스 정보와 백엔드 서버의 환경변수 관 리. - Cloudwatch Insight를 이용한 Log data 쿼리 - AWS Cloudfront + S3를 이용해 CDN 추가 - AWS Mediaconvert와 S3 event를 이용해서 영상 변환 및 db 정보 저장을 비동기 처리 - 게임 플레이를 위한 websocket 로직 구현 - vitest, vitest-mock-extended를 이용한 테스트코드 작성 - Mysql ranking query를 이용한 리더보드의 랭킹 표시 - 게시글 목록 정렬 알고리즘 추가 - Firebase Cloud Messaging을 이용한 ios, android 기기 notification 발송 문제경험: 1. Lambda cold start로 인한 긴 Http response time. Provision concurrency parameter를 이용해서 응답 시간을 대폭 개선했음. Provision concurrency의 pricing 정책이 container 사용 여부와 상관없이 시간에 비례해서 부과됨. Lambda의 강력한 성능의 서버를 사용하는 만큼 지불하는 장점을 이용하지 못할 뿐만 아니라 과도한 비용 발생함. 차선책으로 cron job을 이용해서 주기적으로 lambda를 호출하여 container를 warm 상태로 유지하도록 함. 서버를 무료에 가까운 수준으로 운영하면서, 응답시간을 평균 2s-> 0.1s 수준으로 개선함. 2. 서비스가 커짐에 따라서 running 상태의 container 개수가 증가함. db의 connection이 container 개수에 비례해서 증가함. client로 부터 Http 요청을 받으면 db connection 개수가 급격하게 증가함. http 요청을 많이받으면 lambda의 container 개수가 맞춰서 생성될 것을 고려해서 db connection pool의 default 크기를 1로 설정함. db connection의 개수가 안정적으로 유지할 수 있었음. 3. 유닛 테스트 작성하면서 코드가 테스트하기 어렵게 작성된 것을 깨달음. 코드들을 목적에 맞게 작게 분리함. AWS SDK를 모킹하는 것으로 인해 Unit 테스트로 AWS SDK 관련 코드의 안정성을 보장할 수 없음을 확인함. Local 환경에서 AWS 서비스 테스트해볼 수 있도록 Localstack 적용 시도함. 우선순위가 밀려서 보류됨. 4. 리더보드 관련 API의 http 응답 시간이 너무 김 (15s 이상). filtering에 영향받는 column을 인덱스로 추가해서 응답시간 단축 (평균 1~2s). Redis의 ranking set을 이용하면 응답시간을 더욱 개선할 수 있을 것으로 기대했으나 비용 때 문에 보류함. 5. 특정 topic에 구독 중인 이용자들에게 보내는 알림이 간헐적으로 도착하지 않음. FCM으로 이용자가 topic에 구독한 여부와 topic에 구독 중인 이용자들이 알림을 받은 여부를 확인할 수 없었음. Troubleshooting을 할 수 없는 한계 때문에 Notification 서버를 직접 만들어야하는 필요성을 느낌 ● 2022.06 - 2022.10 Sparky.tv (서비스 종료) 서버 유지보수 역할: 백엔드 개발자 기여도: 100% 기술스택: Typescript, Node.js, Mysql, TypeOrm, Webpack, AWS, Serverless framework, Knex.js, Github Action 성과: - 코드 리펙토링 및 에러 개선 - Knex.js를 이용한 Mysql DB Schema migration - Github Action Workflow 작성 및 테스트

더보기