애송이의 유산

프로젝트를 배포, 운영해보면서 내 프로젝트에 어디서 병목 현상이 발생하는지, 트래픽은 어느 정도까지 감당할 수 있는지 확인이 필요한 경우를 공부한 과정입니다. 테스트하는 프로젝트는 sns 사이드 프로젝트로, 간단히 포스팅을 쓰고, 댓글 및 좋아요가 가능한 기본적인 커뮤니티입니다. 테스트는 다음과 같이 시나리오를 설정하고, 진행했습니다. 테스트 시나리오 구성 근거 실제로 클라우드에 배포하는 건 돈 때문에ㅜㅜ 제 컴퓨터 스펙의 서버를 기준으로 잡고 일단 테스트 기준을 세웠습니다. 1. 서버 스펙 제 컴퓨터 스펙은 다음과 같습니다. cpu : AMD Ryzen 5 3500X 6-Core Processor 3.59 GHz (6코어 입니다.)메모리 : 16GBdisk : sdd 500GB 2. ..

개요프로젝트를 진행하며 여러 layer사이에 데이터를 전달할 때, dto, entity 간 변경이 자주 일어나는 상황에 변환하는 코드를 일일이 적어넣는 것이 불편했습니다.   예시로 보면, member  한 명을 생성하는 post api는 다음처럼 작성되어 있었습니다.  @Controller@RequiredArgsConstructorclass MemberController { private final MemberService memberService; @PostMapping() public Member createMember(@RequestBody MemberDto memberDto){ //dto 사용 Member member = memberService.createM..

문제 풀이 처음에 생각한 풀이방법은 xor 비트 연산을 이용하는 것이었다. 문제 예시로 7과 8 사이의 다른 비트 개수를 셀 때 xor를 사용하면 4개라는 사실을 쉽게 알 수 있었기에 그런 생각이 들었다. 문제는 xor을 이용해서 numbers[i]보다 큰 수들을 차례로 찾아가니 시간 초과가 발생했다. 문제에서 numbers의 최대 원소 크기는 10의 15승으로, 반복문을 30번 정도로 설정해도 한 번 xor 비트 연산 시 꽤 많이 비교하는 작업이 발생했다. 이 때문에 numbers의 길이 100000 x 반복문 대략 50번 (bit를 1씩 왼쪽 쉬프트 연산하며 1 개수를 셈) x 내부에서 비트 연산 횟수 (xor 연산하는데 걸리는 시간) 을 계산하면 1억을 넘어가게 되었다... 그래서 다른 방법을 찾아..

sse 를 이용한 알림 시스템을 구현하며, 코드 개선을 고민하던 중 EventListener를 적용해 개선이 가능하다는 것을 알게 되었습니다. 이 글은 해당 기능 적용기에 대한 포스팅입니다. 1. spring의 @EventListener란? 이벤트 발행/구독 메커니즘특정 이벤트가 발생했을 때, 해당 이벤트를 구독하고 있는 리스너들에게 알림을 보내 관련 로직을 수행하도록 하는 방식입니다.제 코드에서 이벤트 발생 위치는 포스팅 생성 메서드가 되겠고, 이벤트를 구독하는 리스너는 알림 시스템이 되겠습니다. EventListener 원리이벤트 발행/구독 시스템은 spring에서 제공하는 @EventListener 어노테이션을 이용해 구현이 가능합니다.EventListener 를 통해 이벤트 발행/구독 동작을..

jwt 토큰을 통해 로그인을 구현하면 세션에 비해 서버에 부담이 적고, 확장하기도 편리하다는 장점이 있다. 하지만 온전히 사용자가 보내는 http 메시지에 담긴 토큰을 기반으로 서버가 유저를 판단하기 때문에, 이 토큰이 탈취당하면 탈취자를 사용자로 오인하게 되어 매우 위험하다. 프로젝트에서 이를 극복하기 위해 refresh 토큰을 도입했다. Refresh Token 이란? 이전에 작성한 jwt토큰을 이용한 로그인 방식은 엄밀히 보면 access를 위한 토큰이라 볼 수 있다. 그래서 사람들은 보통 이 토큰을 access token이라 지정하는 경우도 많다. 문제는 이 토큰이 탈취당하면 리스크가 크다는 점인데, 이는 access 토큰의 유효시간을 짧게 설정해서 보완할 수 있다. 유효시간이 짧다면 공격하는 사..