jaeiktech

기존에는 Scouter APM을 통해 서버를 모니터링했지만, 24시간 상시 모니터링은 현실적으로 어려웠습니다. 실제로 OOM으로 서버가 종료되었을 때, 이를 몇 시간 후에나 인지하여 서비스 장애로 이어진 경험이 있습니다. 이러한 문제에 직면하며 단순한 서버 상태 알림을 넘어, 문제의 원인과 심각성을 즉시 파악하고 대응할 수 있는 지능형 모니터링 시스템의 필요성을 느꼈습니다. 이에 저는 GPT 기반의 서버 모니터링 AI를 개발하여 모니터링 부담을 줄이고, 신속하고 정확한 문제 해결을 돕고자 했습니다. 처음에는 서버 내부 API로 GPT를 호출하려 했으나 서버가 죽으면 응답을 할 수 없고 설령 서버가 죽지 않더라도 트래픽에 요청이 느려질 가능성이 있었습니다. 서버 진단 기능이 서버 내부에 있는 것은 잘못..

2025년 6월 15일의 고민 노션에서 옮겨오고 있습니다. 고민 최근 데이터엑세스 코드를 수정하면서 레포지토리 계층에서 DTO나 인터페이스에 접근하는 것이 아키텍처에 어긋나는지 고민에 빠졌다. 일반적으론 Repository에서 바로 비즈니스 로직을 거치지않고 바로 DTO에 접근하는 것은 맞지 않다고 느껴진다. 하지만 그건 JPA의 관점이 아닌가? 마이바티스는 일반적으로 바로 DTO에 접근하는데? JPA의 더티체킹에 익숙해져서 서비스 -> 엔티티 -> 레포지토리 구조에 빠져버린건가? 특히 QueryDSL의 프로젝션 기능을 사용하면 복잡한 조회 쿼리도 깔끔하게 DTO로 매핑할 수 있는데, 이런 경우에도 아키텍처 원칙 때문에 포기해야 하나 하는 고민이 들었다. 같은 애플리케이션에서 기술에 따라 다른 패턴을 사..

2025년 4월 29일의 고민 노션에서 옮겨오고 있습니다 고민 알림을 읽을 때 마다 DB에서 update 쿼리를 요청하면 불 필요한 부하가 생긴다.불 필요한 부하라기엔 필요한 로직일 수도 있지만 알림을 읽는다는 역할의 중요성을 생각해 보았을 때 차후에 만약 사용자가 많아진다면 대안을 생각하는 것이 필요한 부분이라고 생각한다.당장은 사용자가 적어 문제가 되지 않지만 만약 사용자가 많아진다면? 스케일 아웃이나 스케일 업은 피할 수 없는 선택지가 되겠지만 그 선택을 하기전까진 대안과 최적화로 할 수 있는만큼은 기존 서버만으로 트래픽을 받고 싶다. 해결알림 읽음과 삭제 상태를 프론트의 로컬 스토리지에서 관리하고 5분마다 서버로 전송하여 DB에 반영하는 방식을 선택했다.그리고 사용자가 5분도 이용하지 않고 떠났을..

목차1. 서론1.1 테스트 목적1.2 핵심 성과 요약 및 개선 범위2. 부하 테스트 수행 및 문제점 분석2.1 테스트 환경 및 시나리오2.2 테스트 결과 요약2.3 정상 요소2.4 문제점 분석 (우선순위별)2.4.1 우선순위 상: N+1 쿼리 문제 (병목 지점)2.4.2 우선순위 중: 20초 Stop-The-World GC, 인덱스 미설정2.4.3 우선순위 하: DB 커넥션 부족 현상3. 성능 개선 구현 및 검증3.1 우선순위 상 개선: N+1 문제 해결3.2 우선순위 중 개선: GC 부하 감소 및 인덱스 설계3.3 우선순위 하 개선: DB 커넥션 최적화4. 성능 개선 효과 검증4.1 개선 전후 성능 비교4.2 목표 달성도 평가4.3 API별 상세 개선 결과5. 결론 및 향후 과제5.1 개선 성과 종합5..

롤링페이퍼 유저 상호작용 부하 테스트 및 성능 개선 종합 리포트 목차1. 서론 1.1 테스트 목적 1.2 핵심 성과 요약 및 개선 범위 2. 부하 테스트 수행 및 문제점 분석 2.1 테스트 환경 및 시나리오 2.2 테스트 결과 요약 2.3 문제점 분석 (우선 순위 별) 2.3.1 우선순위 상: Connection Refused (병목 지점) 2.3.2 우선순위 중: CPU 사용량 급상승의 원인 2.3.3 우선순위 하: GC 스파이크, N+1 문제 및 불 필요 컬럼 조회, 동기화 이슈 3. 성능 개선 구현 및 검증 3.1 우선순위 상 개선: Connection Refused 해결 3.2 우선순위 중 개선: DB 커넥션 최적화 ..

2025년 4월 26일의 고민 노션에서 옮겨오고 있습니다. 고민1차 테스트 서버에서 모의 해킹결과 GET요청에 민감 데이터를 넣어서 프론트에서 민감데이터 처리를 하는 바람에 서버로 직접 요청해서 응답을 탈취하는 경우가 있었음. HTTPONLY쿠키 SAMESITE STRICT SECURE 설정 다 했기 때문에 CSRF나 쿠키탈취 가능성은 적음 그리고 서버 시큐리티에서 권한 검사 함 다만 서버에 직접 요청이 가능한 점 프론트를 통해서만 서버에 접근 가능하는 것도 생각해보았지만 ELB에서는 루트를 분기하는 기능만 있고 서버에 접근해도 신원검사와 보안을 해놓았기 때문에 신원을 검사하지 않는 GET요청의 민감 데이터를 내려주지 않으면 될 듯 함해결 민감데이터 처리는 프론트에서 하지말고 서버에서 해야함 그리고 서버..

2025년 4월 13일의 고민 노션에서 옮겨오고 있습니다. 고민 비밀로그는 젊은 층을 저격한 SNS의 특성상 유행이 빠르게 일어나고 빠르게 사라질 특성을 가진 서비스유행 탄 초반에는 순간적으로 대량의 알림이 일어날 수 있음 롤링페이퍼에 메시지가 달릴때 알림이 발생 친구가 메시지 보낼 때 친구의 친구가 메시지를 보낼 수도 있기 때문에 동시성이 보장되어야 함. 알림은 최대 30개까지 저장되며 개인이 삭제하지 않는 이상 다시 읽을 수 있어야 함. 모바일 유저는 백그라운드에서 알림을 받을 수 있어야 함. 목표:1. 1분에 500개의 알림을 처리할 수 있는 성능2. 동시성 보장3. 실시간성 보장4. 유실 방지5. 모바일 유저만을 위한 전용 알림 기능과정 제외 기술폴링, 롱 폴링 : 계속 Get요청을 보내는 것이 ..