본문 바로가기

전체 글142

롤링페이퍼 유저 상호작용 부하 테스트 및 성능 개선 목차1. 서론 1.1 테스트 목적 1.2 결과 요약2. 부하 테스트 2.1 테스트 환경 및 시나리오 2.2 테스트 결과 요약3. 지표 분석 3.1 문제 현상 3.2 메모리 분석 3.3 CPU 분석 3.4 커넥션 분석 3.5 리눅스 서버 설정과 오류 발생 지점 분석 3.6 힙 메모리, GC 분석 3.7 N+1 분석 3.8 부가로직의 동기 처리 분석4. 문제점 개선 4.1 문제점 요약 4.2 우선순위 상: Connection Refused 해결 4.3 우선순위 중: DB 커넥션 부족 해결 4.4 우선순위 중: N+1 해결 4.5 우선순위 하: GC 스파이크 해결 4.6 우선순위 하: 부가로직의 비동기화5. 목표.. 2025. 8. 7.
추가적인 보안 관련 고민 (2025년 4월 26일) 2025년 4월 26일의 고민 노션에서 옮겨오고 있습니다. 고민1차 테스트 서버에서 모의 해킹결과 GET요청에 민감 데이터를 넣어서 프론트에서 민감데이터 처리를 하는 바람에 서버로 직접 요청해서 응답을 탈취하는 경우가 있었음. HTTPONLY쿠키 SAMESITE STRICT SECURE 설정 다 했기 때문에 CSRF나 쿠키탈취 가능성은 적음 그리고 서버 시큐리티에서 권한 검사 함 다만 서버에 직접 요청이 가능한 점 프론트를 통해서만 서버에 접근 가능하는 것도 생각해보았지만 ELB에서는 루트를 분기하는 기능만 있고 서버에 접근해도 신원검사와 보안을 해놓았기 때문에 신원을 검사하지 않는 GET요청의 민감 데이터를 내려주지 않으면 될 듯 함해결 민감데이터 처리는 프론트에서 하지말고 서버에서 해야함 그리고 서버.. 2025. 8. 7.
실시간 알림 시스템 기술 선택 관한 고민 (2025년 4월 13일) 2025년 4월 13일의 고민 노션에서 옮겨오고 있습니다. 고민 비밀로그는 젊은 층을 저격한 SNS의 특성상 유행이 빠르게 일어나고 빠르게 사라질 특성을 가진 서비스유행 탄 초반에는 순간적으로 대량의 알림이 일어날 수 있음 롤링페이퍼에 메시지가 달릴때 알림이 발생 친구가 메시지 보낼 때 친구의 친구가 메시지를 보낼 수도 있기 때문에 동시성이 보장되어야 함. 알림은 최대 30개까지 저장되며 개인이 삭제하지 않는 이상 다시 읽을 수 있어야 함. 모바일 유저는 백그라운드에서 알림을 받을 수 있어야 함. 목표:1. 1분에 500개의 알림을 처리할 수 있는 성능2. 동시성 보장3. 실시간성 보장4. 유실 방지5. 모바일 유저만을 위한 전용 알림 기능과정 제외 기술폴링, 롱 폴링 : 계속 Get요청을 보내는 것이 .. 2025. 8. 7.
단일책임원칙에 대한 고민 단일책임원칙은 '클래스는 변경이 일어나야하는 이유가 하나여야 한다'고 말한다. 단일책임원칙을 적용하면 유지보수성이 증가하고 테스트도 쉬워지고 후에 CQRS를 적용할때도 용이하다다만 비밀로그의 퍼블릭 메서드는 최소 100개 이상이다 150~200개 까지 될 수도 있다. 그럼 클래스도 100개 이상 생긴다그런데 모조리 단일책임원칙을 적용하는게 맞을까?어느정도 분리하는건 좋지만 모조리 적용하면 클래스가 너무 많아질 것 같다.클래스란.. 속성과 동작을 정의하며 객체를 생성하기 위한 틀이다. 자바 공식문서에서는 '클래스를 특정 종류의 객체를 구현하는 데 필요한 타입을 정의한다'라고 설명하고있다특정 객체.. 하나의 성격.. 그 성격에 맞는 타입들클래스의 관점에서봐도 단일책임 원칙이 맞아보인다 하지만 현실적으로 클래.. 2025. 8. 6.
비밀로그 자체 스캐닝 및 공격 (2025년 8월 5일) ZAP을 이용한 스캐닝과 공격으로 비밀로그의 취약점을 진단했습니다.이 글은 취약점을 해결한 이후에 공개로 전환될 예정입니다. 1. 개요본 보고서는 ZAP(Zed Attack Proxy) 스캔 결과를 바탕으로 작성된 종합 보안 보고서입니다. 비밀로그의 현재 보안 상태를 평가하고 각 문제에 대한 상세 분석과 조치 사항을 작성했습니다.스캐닝 뿐만 아니라 파일취약공격, SQL 인젝션, XSS등 약 30가지 이상의 공격들을 총 2만번 시행했는데 모두 방어할정도로 기본 보안은 나쁘지 않았습니다.하지만 스캐닝에서 검출된 취약점을 보완하겠습니다2. 취약점 요약ZAP 스캔 결과, 총 11개의 경고가 감지되었습니다. 취약점의 리스크 레벨별 분포는 다음과 같으며, 정보성 리스크는 여기 적지 않았습니다.높음(High): 0건.. 2025. 8. 5.
DB를 거치지 않은 JWT을 통한 사용자 식별에 관해 (2025년 4월 7일) 2025년 4월 7일의 고민 노션에서 옮겨오고 있습니다. 고민 만약 토큰에 식별자만 넣으면 JWT필터에서 인증객체를 만들기 위해 DB를 조회해야하지 않나?프론트에서는 페이지마다 /userinfo API로 서버에 유저정보를 요청할것이고 서버는 응답으로 유저정보를 반환한다. 그리고 필터는 모든 API요청마다 작동한다.그럼 모든 요청마다 DB를 조회해야하나? 그럼 토큰을 사용하는 의미가 없다.시큐리티컨텍스트홀더를 활용해서 최초한번만 DB를 조회하게하는 방법은 없나?해결 1. 우선 필터에서 DB를 조회하면 안된다. 필터는 서버를 들어오는 요청을 사전에 확인하는 거름망으로 Tomcat 서버의 필터레벨에 스프링 시큐리티의 필터체인이 삽입된다. 스프링의 필터체인에는 JWT필터도 있고 아직 웹 서버에 도착하지 않은 상.. 2025. 8. 3.

티스토리툴바