Undefined

DB 해킹당하다..

목요일에 사용자 수가 기하급수적으로 늘어났다. 알고보니 이세계 페스티벌(?) 이라는 버츄어 아이돌 관련 페스티벌  티켓 오픈일이 저녁 8시 였더라.. 사용자가 많아진 만큼 이상한 사람들도 많았다. 채팅을 도배로 가득 채우거나 닉네임을 말도안되게 길게 설정하는 사용자 등이 있었다. 애초에 검증 로직을 엄격하게 설정하지 않은 내 잘못이 크긴하다 ㅜㅜ 저녁에 퇴근하고 채팅 관리도 할겸  데이터 마이그레이션을 진행했다. Redis로는 관리하기가 조금 까다로워서 Mongo로 마이그레이션을 했다. 로컬환경에서 이미 여러번 테스트 했기 때문에 바로 스크립트를 실행했다.당연히 정상 실행되었고 기능적으로 잘 동작하는지 여부까지 확인했다. 뿐만아니라 블로그 글까지 정리하고 난 뒤 잠에들었다. 그런 후 아침에 눈을 뜨고 사..

홈서버 메모리 아끼기

개인 플젝 진행하면서 채팅 기능을 구현했다.채팅보다는 연습이 메인 기능인 사이트였기 때문에 채팅은 크게 신경 안썼다.처음에는 하루에 한번씩 채팅 내역을 초기화 하려고 redis를 활용했다. TTL만 설정해주면 스케줄러나 별도 과정없이 리셋되니까 그렇게 설계했는데.. 문제는 채팅이 생각보다 홍보효과 컸다. 입장바꿔서 내가 내 사이트를 이용하는데,  사람들이 채팅을 많이 하고 있으면  '오? 이 사이트 좀 인기 있는 사이트인가보네?' 라고 생각할거 같다.또 데이터가 많아지면 무한스크롤이나 기술적으로 고민해볼 문제들도 겪을 수 있을 거 같아서 리셋하지말고 남겨두기로 결정했다. 근데 문제는 사람들이 채팅을 너무 많이 쓴다. 대략적으로 8,000개 가량 데이터가 생성되었고 메모리 사용량도 게속 늘어나고 있다.아래..

쿠폰 발급 프로젝트 (2)

어플리케이션 단에서 Lock 개념으로 언급되는 것은 크게 낙관적 락(Optimistic Lock) 과 비관적 락(Pessimistic Lock)이 있다. 각각의 방식을 적용해서 동시성 문제를 해결해보도록 하자!  비관적 락비관적 락은 말 그대로 트랜잭션 끼리의 충돌은 무조건 발생(비관적으로 생각) 한다고 보고 트렌잭션이 접근하는 데이터에 미리 락을 거는 방식을 뜻한다.  public interface CouponRepository extends JpaRepository { @Lock(LockModeType.PESSIMISTIC_WRITE) @Query("SELECT count(c) FROM Coupon c") long countWithPessimisticLock();} 기존의 Coupon..

쿠폰 발급 프로젝트 (1)

평소 동시성 관련된 문제에 대해 관심이 많았기에 토이 프로젝트를 통해 학습하고자 해당 프로젝트를 시작했다! 또한 서비스를 운영하면서 특정 이벤트를 진행할 경우가 많은데 (쿠폰, 할인 이벤트) 이럴 경우 일시적으로 트래픽이 폭발적으로 증가하게 되는 현상이 발생한다. 단순히 스케일아웃을 통해 트래픽을 해결하는 것이 아닌, 작업 큐를 활용하여 일시적인 트래픽을 제어하는 방법 또한 이번 프로젝트를 통해 학습하고자 한다.   위 코드는 쿠폰을 발급과 관련된 정말 간단한 로직을 담고있다. 쿠폰 발급 수량이 100개가 넘어가거나, 동일 회원이 쿠폰을 중복으로 발급받으려 할 때 체크하는 유효성 검증 로직과 UUID를 바탕으로한 쿠폰 발급 로직이다. 아무런 동기화 처리를 해주지 않은 상태인데, 이 상태에서 테스트를 해보..