EVO

기능 요구사항관리자는 이메일 주소를 입력하여 새로운 멤버를 초대할 수 있습니다.초대 이메일은 지정된 템플릿 형식으로 발송되어야 합니다.초대 링크는 10분간 유효합니다.초대 링크는 1회만 사용가능합니다.만료되거나 사용된 초대 링크는 더 이상 사용할 수 없습니다. 비기능 요구사항초대 링크는 추측할 수 없는 안전한 토큰을 사용해야 합니다.이메일 발송은 비동기로 처리되어야 합니다.시스템은 초대 상태를 추적하고 관리할 수 있어야 합니다. 멤버 초대 플로우프로젝트를 개설한 관리자는 본인 팀의 멤버들을 초대하기 위해 멤버 이메일을 작성하고 전송버튼을 누릅니다. 서버는 해당 이메일 받고, 그 이메일에 대한 초대토큰을 생성한 다음 템플릿에 담고 이메일 서비스를 사용해 해당 유저에게 이메일을 전달합니다.  유저는 이 이메..

장애 상황이슈 생성 API의 부하 테스트를 통해 안정적인 서비스 제공과 우수한 성능을 달성하는 것을 목표로 설정했습니다.  그러기 위해서 대규모 조직(1000명 이상)에서 50~100명의 사용자가 동시에 이슈를 생성하는 상황을 가정했을 때, 다음과 같이 요청-응답 시간(MTT)은 1~2초 이내, TPS는 30~40, 에러율은 0.1% 이하, 테스트 시간은 1분 이내인 성능 지표를 목표로 삼았습니다 💡 TPS를 30~40으로 잡은 이유 (1000명 조직 기준 예상 시나리오)- 1인당 하루 평균 5-10개 이슈 생성 - 8시간 근무 기준: 1000명 × 10개 ÷ 8시간 ÷ 3600초 ≈ 0.34 TPS- 피크 타임(10배 부하) 고려: 약 3 TPS - 버퍼(10-20배)를 둬서 30-40 TPS 설정 ..

사전 지식 이슈란이슈란 팀이 프로젝트를 진행하면서 관리해야 할 모든 종류의 작업, 버그, 개선사항, 요청 등을 포괄합니다.1. 이슈 유형- 스토리(Story): 사용자 요구사항이나 기능 개발을 의미합니다.- 버그(Bug): 시스템 오류나 문제를 추적합니다.- 태스크(Task): 구체적인 작업 단위를 나타냅니다.- 에픽(Epic): 여러 스토리와 태스크를 포함하는 큰 단위의 작업입니다.2. 설명 및 요약(Description & Summary)- 작업의 목적, 세부 내용, 예상 결과 등을 기술합니다.  이슈번호(PROJECT-1 같은 형식)를 사용하는 이유- 커뮤니케이션 효율성짧고 명확한 참조: "PROJECT-123"처럼 간단히 이슈를 지칭할 수 있음구두 커뮤니케이션: 회의나 대화에서 쉽게 언급 가능"P..

준비 사항프로젝트 1만개 생성멤버 1만개 생성프로젝트와 멤버 1대1 매칭예를들어 1번 프로젝트는 1번 멤버, 2번 프로젝트는 2번 멤버, n번 프로젝트는 n번 멤버가 속합니다.성능 비교를 위한 것은 프로젝트와 멤버가 아닌 이슈이기 때문에 최대한 간단하게 매칭 시켰습니다.EPIC 이슈는 100개 생성STORY 이슈는 에픽당 200개씩 총 2만개의 스토리 이슈 생성TASK 이슈는 스토리당 200개씩 총 4만개의 테스크 이슈 생성모든 이슈는 1번 프로젝트에 속하도록 합니다. 문제 사항1. 로직 리팩토링 더미데이터를 넣고 이슈 전체 조회 API를 요청 했지만 쿼리가 돌다가 응답이 오지 않고 멈췄습니다.(성능측정을 해야지하고 몇 초나 걸릴까를 생각했는데 그냥 아예 팅겨버린..)이유가 당연했습니다. 로직이 다음과 ..

문제사항최근 애자일허브 프로젝트는 도커이미지를 만들어 DockerHub에 올리는 방식으로 배포를 하고 있습니다. Dockerfile을 만들어서 GitHub에 올려두고, GitHub Actions로 docker build와 push를 진행하는 방식입니다.  그런데 배포를 할때마다, 매번 빌드 시간이 10분 이상이었고, 코드가 조금만 추가되어도 1분씩 늘어나 최근에는 배포 한번 하는데 13분정도 걸립니다. 이정도의 시간은 매번 배포할때마다 다른 일을 해야하고, 나중에 테스트를 해보며 수정할게 생기면 다시 또 13분을 기다려야 하는 충분히 부담되는 시간입니다. 그리고 이런 사이클은 Continuous Deployment의 장점을 잘 살리지 못한다고 생각했습니다. 배경지식 - 도커 레이어와 캐시도커 빌드 속도에..

문제 사항애플리케이션 로그를 프롬테일을 이용해 로그들을 로키로 push 하는 과정에서 nginx와 system 로그는 제대로 로키가 받아오지만 애플리케이션 로그(ERROR 레벨)는 받지 못하는 상황이 발생했다.   먼저 프롬테일 config.yaml은 다음과 같이 작성했다.문제 해결 시도1. 로그 확인 먼저, 애플리케이션이 있는 서버 안의 프롬테일을 컨테이너로 띄었는데 이를 로그로 확인해봤다. 하지만 잘 로그 경로를 잘 찾아가서 탐지하고 있었다. 그렇다면, 모니터링 서버에 띄어놓은 로키의 컨테이너 로그를 확인해봤다. 대충 로그를 보면 200 status, 즉 프롬테일이 push 한 API를 로키가 잘 응답받아왔다는 것을 알 수 있다. 하지만 분명히 prod-log에 에러로그가 있음에도 불구하고 0B 즉,..

팀원이 먼저 인증 API를 구현하고난뒤 함께 리뷰하면서 생겼던 트러블 슈팅을 적어보려 한다.- Spring Security 6.1- SpringBoot 3.2.3- Redis 5.0.7- java-jwt 4.4.0- oauth2-client 1. base 64 디코딩 에러 발생GitHub CLI gh로 PR을 로컬에 받고 테스트 도중 이상한 것을 발견했다. postman을 통해 api를 요청할 때 Authorization 헤더에 bearer: { accessToken } 을 넣고 API를 요청을 했다. e.g) /api/projects응답 결과는 다음과 같이 Token 유효성을 검사 도중 유효하지 않은 JSON format이라는 에러 메세지를 받았다.JwtUtil.verifyToken error: The..

문제 사항 테스트코드가 40개를 넘어가면서 갑자기 그 이후로 간헐적으로 깨짐이 발생했다. 처음 생겼던 에러는 다음과 같았다. org.hibernate.exception.JDBCConnectionException: Unable to release JDBC Connection [The database has been closed [90098-224]] [n/a] 문제해결 시도 해당 에러를 검색해보니 원인은 다양했다. 1. H2 데이터베이스 설정 확인 H2 데이터베이스가 테스트 하나 실행하고 닫지 않도록 DB_CLOSE_DELAY=-1; 을 추가했다. 테스트가 독립적으로 실행하니깐 H2에 필요로 하는 커넥션이 많아진것으로 예상이 되어 HikariCP maximum pool size을 100개로 늘렸다. dat..

문제 상황 같은 키를 가진 프로젝트를 생성하면 UNIQUE 제약조건에 의해 예외(DataIntegrityViolationException)가 발생한다. 4가지 방법 1. 서비스계층에서 flush + try catch 엔티티를 저장하고 unique key에 의해 중복이 감지되면, try catch를 통해 예외 변화를 하면 된다. flush를 해야하는 이유는 @Transactional 이 붙은 메서드에서 사용되는 CrudRepository의 save()와 saveAll()은 메서드를 호출할 때 바로 쿼리를 실행하지 않고 1차캐시에 우선적으로 저장했다가 메서드가 정상적으로 종료되면 커밋이 되어 실제 DB에 반영된다. try-catch 블럭 내부에서는 쿼리가 실행되지 않으니 잡아낼 DataIntegrityVio..

문제 배경로컬에서 정상적으로 API를 만들고 POSTMAN으로 테스트까지 해보고 배포를 했다. 하지만 정상적으로 요청이 오질 않아(404 error) NGINX 로그를 살피던 도중 의도치 않게 다른 문제를 발견하게 되었다. (위 문제는 Reverse Proxy 설정을 잘못한거라 해결했다)  에러로그가 굉장히 많이 쌓여 있었고 그중 수상하게 용량이 매우 크고 에러로그(error.log.6.gz)가 있길래 한번 살펴봤다.  가장 첫번째 줄에client: 124.156.187.113의 위치를 한번 검색해봤다. 무슨 홍콩 지역이 나온다.  그리고 request: "HEAD /Core/Skin/Login.aspx 이라는 요청을 보낸다. Login.aspx 이란, https://dotnet.microsoft.com..