시험기간은 2주 하루에 예약 수용 가능한 인원은 최대 600 여 명오전 8시에 예약이 오픈됩니다. 모든 스터디룸은 시험기간인 이유로 개인석 단위로 예약이 진행됩니다.이전 스터디룸을 오픈 톡방을 통해서 예약을 진행했었는데 150명 가량 신청했던 기억이 있습니다.모든 시간대를 동시다발적으로 예약한다면 저희 프로젝트의 WAS는 부하를 버틸 수 있는지 테스트를 해야합니다.하루에 예약이 가능한 인원은 방 별로 SQL 문으로 확인해보니 아래와 같았습니다.아래 데이터에 따르면 600여명이 예약이 가능합니다. 과연 우리 서버는 모든 인원을 수용할 수 있을까라는 의문이 들었습니다.SELECT room_number, SUM(capacity)FROM scheduleGROUP BY room_number+-----------+..

문제 및 원인Caused by: io.lettuce.core.RedisReadOnlyException: READONLY You can't write against a read only replica. at io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:144)서버 에러가 발생하였습니다. redis의 노드가 복제로 인해서 readonly로 바뀌었다는 로그를 확인할 수 있었습니다.저희 시스템은 redis를 refresh token을 저장하는 용도로 사용하고 있습니다. redis에 쓰기 접근이 안되기에 로그인이 불가한 상황이었습니다.더군다나 저희는 복제를 활용하는 sentinel이나 클러스터 ..

⚠️ 문제 상황운영 기간이 늘어날수록 예약 스케줄을 출력해주는 API의 성능이 저하되는 문제가 발생하였다. 따라서 실제로 스케줄이 렌더링 되는 시간이 느려지는 문제도 발생했다.🕵️ 원인 분석풀 테이블 스캔 발생: WHERE 조건에서 grade와 class_date를 사용하여 데이터를 조회하는데, 인덱스가 적용되지 않아 전체 테이블을 검색하는 문제가 발생.쿼리 실행 시간이 길어짐: 테이블 크기가 증가할수록 쿼리 성능 저하가 발생.카디널리티 부족: grade와 class_date의 조합에 대한 인덱스가 없기 때문에 검색 범위가 넓어지고 실행 시간이 증가함.✅ 해결 방법시도할 수 있는 최적화 방법단일 컬럼 인덱스 적용: grade 또는 class_date 각각에 대한 인덱스를 생성하여 조회 속도를 개선할 수..

⚠️ 문제 상황사용자로부터 재로그인 빈도가 높아 불편하다는 피드백(VOC)을 다수 접수함. 특히, 토큰이 자주 만료되어 로그인이 반복적으로 필요하다는 문제가 발생🕵️ 원인 분석Access Token 만료 주기가 짧음: 보안 강화를 위해 만료 시간을 1시간이라는 짧은 시간으로 설정했으나, 사용자 경험이 저하됨Refresh Token 미활용: 기존 시스템에서는 Access Token 만료 시, 매번 로그인 페이지로 이동하도록 설계됨인증 시스템 최적화 부족: 사용자 활동 여부와 관계없이 일괄적으로 토큰을 만료시키는 정책이 적용됨✅ 해결 방법Refresh Token을 활용한 인증 유지 연장Access Token 만료 시, Refresh Token을 사용하여 자동으로 새로운 Access Token을 발급이를 통..

문제 상황스케줄 데이터 입력 시 한국 시간과 다른 시간대로 데이터가 입력되는 문제 발생현재 시스템 시간 확인 결과mysql> SELECT CURRENT_TIMESTAMP, NOW(), CURRENT_DATE;+---------------------+---------------------+--------------+| CURRENT_TIMESTAMP | NOW() | CURRENT_DATE |+---------------------+---------------------+--------------+| 2025-01-06 16:22:07 | 2025-01-06 16:22:07 | 2025-01-06 |+---------------------+-------------------..

🚀 도전 목표퀴즈 서비스 삭제 기능 성능 최적화💡 핵심 과정 및 결과YouQuiz? 서비스에서 하나의 클래스(Class)는 다수의 퀴즈(Quiz)를 포함하고 있다.각 퀴즈는 여러 개의 선택지(Choice)를 보유계층 구조: Class(1) → Quiz(N) → Choice(M)많은 퀴즈가 생성되는 만큼 많은 퀴즈도 삭제될 것이다.클래스 삭제 시 연관된 모든 퀴즈와 선택지도 함께 삭제 필요클래스 당 평균 10개 이상의 퀴즈와 각 퀴즈당 4개 이상의 선택지 예상향후 서비스 확장 시 데이터 증가로 인한 성능 저하 우려따라서 클래스 삭제 기능의 성능을 파악하고, 개선사항을 트러블 슈팅해보았다. 퀴즈 서비스의 경우 한 게임 당 문제의 개수는 10개가 넘어가는 경우가 많아질 것이라 보았다. 삭제하는 방법은 다음..