Seok.LE

Distance서비스를 운영하면서 사실 마냥 순탄치는 않았습니다.서비스를 운영하면서 겪었던 문제 중 하나인 "Postman을 통한 무한 API요청"을 효과적으로 차단한 경험을 공유하려 합니다. 저희 서비스는 축제 시즌에 배포된 서비스인데 00대학교에 배포 중 갑자기 오후 11시쯤에 Slack으로 알림하나가 날라왔습니다.이 에러는 저희 서비스에 굉장한 크리티컬한 에러였습니다.사용자가 Distance서비스에 신규 가입을 하려면 반드시 SMS인증을 통해 가입을 할 수 있는데 그 인증 API가 일일 사용량 초과가 된 것입니다.분명 일일 한도가 약 390건 정도가 남아있었는데 이게 한 순간에 사라진게 이상하게 생각해 발송내역을 보니 한 번호가 391건의 요청을 했던 것을 확인할 수 있었습니다. 알고보니 Postm..

위의 화면은 사용자가 distance를 들어왔을 때 가장 먼저 볼 수 있는 화면이다.저 화면에 보이는 유저 4명은 총 3가지(비로그인 유저, 로그인한 유저, 로그인은 했지만 GPS추적을 거부한 사람)유형으로 구분하여 DB에서 불러오는 방식을 사용했다. 오늘 개선할 부분은 바로 로그인한 유저의 매칭 부분을 개선할 것입니다. public MatchResponseDto getNotFoundPositionMatchList(Member centerUser) { List userDtoList = memberReader.findMemberList().stream() ... .collect(Collectors.toList()); return getMatc..

우리 서비스의 MVP기능을 뽑으라하면 위치기반을 통한 매칭과 채팅이라고 할 수 있다.우리가 원하는 채팅의 수준은 카카오톡과 비슷했다. 1. 1대1 채팅이 가능하여야 한다.2. 채팅방 내에서 사진을 보낼 수 있어야한다.3. 채팅방안에서 실시간으로 읽음표시가 사라져야 한다.4. 채팅 목록에서 실시간으로 메시지의 변화를 감지해서 보여주어야한다.총 이렇게 3가지였다. 다른 건 사실 크게 어렵지 않았고, 1, 2번은 굳이 없어도? 크게 불편하지 않았다. 하지만 3, 4번 같은 경우는 없으면 불편하고 사용자에게 버그처럼 느껴질 수도 있을 거 같았다. 우선 3번 같은 경우는 사용자가 방에 들어오면 Event를 감지하여서 Session Table에 값이 들어옴으로써 방에 있는지 없는지를 확인할 수 있었고, 덕분에 읽음..

지금 프로젝트를 진행한지 어엿 반년이 지나고 800명의 유저와 3만건에 가까운 채팅을 많은 사용자들이 이용을 주었다..ㅎㅎ근데 가장 많이 들었던 아쉬운 점 중 하나가 "알림이 고장난거 아니에요?" 라는 피드백이었다. 왜 그럴까? 원래 초창기에 저희가 사용했던 알림 방식은 FCM을 통해서 채팅이 오면 바로 채팅내용을 카0오톡 처럼 바로 바로 보내주는 형식이었다.하지만 이렇게 하다보니 FCM자체가 동작을 안할 때가 있었고, 순서도 뒤죽박죽에 이미 갔던 문자알림이 또 가는 버그가 있었고, 무엇보다이렇게 했을 때 채팅하나 보내는데도 많은 쿼리가 나가는데 이에 FCM까지 전달하려고 하는게 아닌 거 같아 방식을 바꾸게 되었다. 그럼 어떻게 보냈냐?!특정 유저에게 메시지가 오면 FCM Table에 저장을 하고 스케줄..

구름톤에서 시작한 Distance프로젝트는 어느덧 순천향대, 경희대, 동국대, 서울여대, 한국외대를 지나 저희 팀의 리더분 학교인 전남대에도 배포를 하게 되었다. 저희가 이 프로젝트를 구현하고 순천향대에 첫 배포를 할 때 목표가 "서버를 터트릴때까지 해보자!" 였다.사실 ec2유형이 t2.micro여도 지금까진 단 한번도 서버가 터지지 않고 사용률이 70%이상만 가보기만 했다. 그리고 나름 채팅이 MVP이다보니 I/O가 많을 거 같아 미리 분산을 시켜두면서 나름 준비를 많이 해두었다.지금 현재 저는 판교에 있는 회사 인턴으로 하고 있는 중 2024/09/12에 전남대 단과대 축제에 맞춰 distance서비스를 배포를 하였다.오랜만에 배포라서 귀하디귀한(?) 점심시간도 자진 반납을 하고 서버 모니터링을 하..

TDD프로젝트의 구현을 마치고 앱스토어에 무려 1트만에 배포가 성공되어서 너무 기뻤다..ㅎㅎㅎㅎㅎ 이제 배포를 하고 문제점을 찾아가던 중 생각보다 치명적인 버그가 있었다.우리 서비스는 Todo를 등록하면 자동으로 사용자가 등록한 github repo의 README와 issue에 등록이 되는 서비스인데 만약 사용자가 깃허브에서 repo를 삭제하면 바로 버그가 생기는 것이다... 왜냐면 DB에는 사용자의 repo정보가 남아있는데 정작 깃허브에는 해당 레포가 없기 때문에 깃허브 repo READMD와 issue를 등록할 수 없기 때문이다..(물론 저 부분도 분리를 해야하는데 추후에 작업을 해보자,,,) 그래서 저 문제를 해결하기 위해 우선 webhook을 등록해서 사용자가 깃허브에서 repo를 삭제하면 자동으..

TDD프로젝트를 진행하면서 우연히 프론트분에게 todo를 불러오는데 로딩이 좀 있는거 같다 라는 연락을 받게 되었다.. 문제(?)의 동영상저걸 보고 전 어라? 저 부분은 데이터도 적은 부분인데 왜 로딩이 되지...? 라는 불안감이 생겼고, API테스터로 response time을측정해보니,,,,,,보자마자 와 뭐지,,API호출하는데 1.5초가 걸린다고? 라는 생각이 들면서 뭐가 문제인지 고민을 해보았습니다. 우선 제가 생각한 문제는 일자별로 DB에서 검색하는게 오래걸렸나..? 라는 생각을 하였습니다..그래서 cache를 적용해야하나? 라는 고민을 하며 우선 로그를 찍어서 한번 확인해보기로 했습니다. 우선 문제의(?) API의 Service를 보면fun findTodoLists(todoDateRequest..

이번에 제가 필요해서 시작한 프로젝트인 TDD 프로젝트의 코드 개선 과정에 대해 포스팅을 하겠습니다. 우선 TDD프로젝트는 개발자를 위한 TodoList서비스이고, 사용자가 TodoList에 할 일을 추가하면 깃허브 레포에 자동으로 이슈와 리드미가 생기게 되는 서비스입니다. (취준생은 잔디도 관리를 해줘야되기 때문에,,ㅎ) 그래서 이번 프로젝트에서는 대부분 Git API를 사용하는 코드가 많기 때문에 최대한 간결하게 정리를 해보고 싶었다.우선 처음 시도했던 코드를 보겠습니다. fun createTodoList( todoRequest: TodoRequest, username: String ): Long? { val member = memberReader.getMe..

이번 포스팅에서는 디스턴스 로그인 구현 중 사용자의 불편함을 덜기 위해 Refresh Token을 구현하면서 겪었던 문제에 대해 이야기를 해보겠습니다. 저는 다른 프로젝트에서는 JWT의 Access Token만을 사용해서 로그인 기능을 구현하였습니다.물론 토큰의 만료시간은 하루(24시간)으로 두고  하였습니다. 물론 그 전의 프로젝트의 실제 유저 유입이 많이 없어서 이런 부분을 크게 신경쓰지 안하고 안일하게 생각을 했었습니다..하지만 이번 디스턴스 프로젝트는 유저 유입이 많을거라고 생각하기도 했고, Access Token의 유효기간을 너무 오래잡으면 좋지 않다는 것을 알게 되었습니다.제가 생각한 단점은Token이 탈취당하면 막을 방법이 없다.그럼 유효기간을 짧게 잡아서 Token을 자주 변경한다.그럼 사..

Team Distance💕 & 9oormthin-univ 와 함께한 프로젝트를 소개합니다..!이번 '디스턴스' 라는 프로젝트는 대학생을 대상으로한 1:1 랜덤채팅 서비스입니다🎉해커톤에서 인연이 닿아 지금까지 쭉 개발을 하며 순천향대학교를 대상으로 실제 서비스까지 배포를 진행하였어요!!! 디스턴스는 '축제기간' 이라는 한정된 기간동안에만 운영을 함으로써 사용자들의 참여를 더욱 더 이끄는 서비스예요..!!이제 서비스에 대한 소개는 여기까지하고, 이제부터 서비스에 대해 설명을 해볼게요😊   디스턴스 개요주요 기능• STOMP를 활용한 1:1 실시간 채팅• 대학 메일 혹은 학생증을 통한 대학생 인증• 거리 기반 추천 기능• 대학 축제 정보 확인개발 기간• 2024.03 ~ 2024.05SkillsJAVA1..