오늘의하루

GitHub - dukbong/Practice-Spring-Security: 세션 기반 인증 - 예시세션 기반 인증 - 예시. Contribute to dukbong/Practice-Spring-Security development by creating an account on GitHub.github.comRoleHierarchy 사용목적RoleHierarchy는 Spring Security에서 역할(Role) 간의 계층 구조를 정의하여 권한을 상속받을 수 있게 하는 유용한 기능입니다.이를 통해 권한 간의 관계를 설정하고, 코드의 가독성을 향상시킬 수 있습니다.예를 들어, 계층 구조를 설정하면 상위 역할이 하위 역할을 자동으로 포함하므로, 보안 정책을 간단하고 효율적으로 관리할 수 있습니다.RoleHi..

개선 사항 분석 결과 반환: 기존에는 문서를 소스 코드에 번호를 붙여 작성하여 클라이언트에게 제공했습니다. 그러나 이제는 JSON 형식으로 문서를 만들어 전달하는 방식으로 변경되었습니다. 이 변경으로 인해 시간 복잡도가 O(N^2)에서 O(N)으로 개선되어 응답 속도가 향상되었습니다. 이 과정에서 Gson과 Jackson 중 어떤 라이브러리를 선택할지 고민했고, JMH를 이용하여 밴치마크를 수행한 결과 Jackson이 Gson보다 약 2.6배 정도 더 빠르다는 결론을 얻었습니다. 따라서 Jackson을 선택하였습니다. 이와 같은 과정을 통해 코드의 가독성을 유지하고, 응답 시간을 개선하는 데에 기여하였습니다. Benchmark Mode Cnt Score Error Units JSONBenchmark.gs..

성능 향상을 위한 Load Balancing 전략을 검토하고, AWS의 ELB와 오토 스케일링을 활용하여 효과적인 서비스 배포를 준비합니다. Load Balancing Load Balancing은 Scale-Out 전략의 핵심으로, 서버나 리소스의 수를 증가시켜 시스템 성능을 향상시킵니다. 테스트 결과, 30~40개의 스레드가 최적의 성능을 나타내므로 이를 고려하여 Load Balancing 전략을 수립합니다. Nginx를 통한 Load Balancing 설정 Nginx는 Reverse Proxy와 Load Balancing 설정이 간편하며, 적은 자원으로 많은 연결을 처리할 수 있어 선택했습니다. Load Balancing 알고리즘으로는 Least Connections, Generic Hash를 테스트..

개선 사항 시간 복잡도 개선: O(N^2)의 시간 복잡도를 가진 메소드를 O(N)으로 개선했습니다. 이로써 데이터 처리 과정의 속도가 향상되었습니다. 압축 해제 라이브러리 사용: 기존에는 ZipInputStream을 사용했으나, Apache의 archivers를 사용하여 압축을 해제하는 방식으로 변경했습니다. 이는 성능과 안정성을 향상시켰습니다. 데코레이터 사용: 주석 제거 전 프로세스에서 ArchiveInputStream으로 Stream을 만들어서 주석 제거 메소드에서 Stream을 사용하여 파일 IO작업의 성능을 높였습니다. 이로써 파일 IO 작업의 효율이 개선되었습니다. 반복적인 작업 개선: 반복적으로 접근하여 파일 IO 작업이 이뤄지는 부분을 개선하여 한 번만 접근하도록 수정하였습니다. 이로써 불..

개선 사항 프로세스 단계 간소화: 불필요한 프로세스 단계를 제거하고, 필요한 작업을 더 효율적으로 처리하기 위해 프로세스를 재구성했습니다. 이로써 프로세스의 실행 속도를 향상시켰습니다. String 객체 생성 최소화: 불필요한 String 객체 생성을 제거하고, 메모리 사용을 최적화하기 위해 InputStream을 활용하여 데이터를 처리하도록 수정했습니다. 버퍼 크기 증가: 프로세스의 효율성을 높이기 위해 버퍼 크기를 4096byte로 증가시켰습니다. 이는 프로세스의 데이터 처리량을 늘려서 성능을 향상시켰습니다. 불필요한 IO 작업 제거: 불필요한 IO 작업을 최소화하여 메모리 사용을 줄였습니다. 이는 프로세스의 부하를 감소시켜서 전반적인 성능을 향상시켰습니다. 환경 설정 Apache JMeter ver..

개선 사항 첨부 파일을 디스크에 저장한 후 분석하던 기존의 방식에서 메모리로 처리하도록 변경하여, 데이터를 일부분씩 분할하여 작은 메모리에서도 처리할 수 있도록 설계를 변경했습니다. 환경 설정 Apache JMeter version : 5.6.3 Spring boot version : 3.2.2 Java version : 17 시나리오 JMeter를 사용하여 100명의 가상 사용자가 동시에 100MB 크기의 zip 파일을 서버에 첨부하고, 해당 파일을 분석한 후 결과를 반환하도록 시나리오를 작성했습니다. 테스트 결과 부하 테스트를 수행한 결과, 사용자의 요청 후 응답까지의 평균 속도와 서버가 처리할 수 있는 양에 집중해야 한다는 것을 확인했습니다. Throughput 비교 1차 테스트 : 10.2/min..

프로젝트 소개 SourceCode.io 프로젝트는 클라이언트가 제공한 zip 파일을 분석하여 원하는 형태의 문자를 추출하여 문서화하고, 동시에 해당 zip 파일의 구조를 반환합니다. 또한, 커스텀 빌드 프로세스를 통해 서버에 zip 파일 형태로 소스 코드를 전송한 후, 해당 코드에 한글이 있는지 확인하고 한글의 개수와 위치를 클라이언트에게 반환합니다. 목표 및 배경 Apache JMeter를 사용하여 SourceCode.io 프로젝트의 부하 테스트를 수행하여 성능을 평가하고 사용자가 원활하게 이용할 수 있도록 성능을 향상시키는 것이 목표입니다. 환경 설정 Apache JMeter version : 5.6.3 Spring boot version : 3.2.2 Java version : 17 시나리오 JMe..

오류 발생 시점 Spring Security와 JWT를 통해 인증 인가를 진행하려고 했고 Jwt Filter에서 @Transactional를 사용했기 때문에 발생하였다. 원인 정확한 원인은 아닌 것 같지만 @Transactional 어노테이션을 사용하면 스프링은 해당 메서드를 실행할 때 트랜잭션을 시작하려고 하지만, 이미 실행 중인 트랜잭션이 없기 때문에 오류가 발생할 수 있습니다. 느낀점 내가 @Transactional을 적용한 곳은 단순히 데이터를 조회하는 용도이므로 트랜젝션이 필요없다. 트랜젝션 관리는 데이터를 변경하는 작업에만 필요하다는건 알고 있었지만 깜빡하고 썻던거 같다. @Transcational은 일반적으로 서비스 계층에서 DB 트랜젝션을 처리하는데 사용된다. 그리고 필터에서 DB에 직접 ..

예외 발생 이유 이 예외는 Fetch Join을 할 때 발생하게 되는데 원인은 2개 이상의 컬렉션이 있는 상태에서 Fetch Join을 하는 경우에 발생하게 된다. 어쩌다 발생했을까? C Entity와 B Entity는 N:1 관계이고 B Entity와 A Entity는 N:1 관계이고 모두 지연 로딩(LAZY)로 되어있다. A Entity에서 특정 Id값으로 조회하여 조회되는 데이터를 Json 형식으로 보내려고 했다. 처음에 별 생각 없이 A Entity 자체를 보내게 되었는데 이때 Stack Overflow가 발생하고 넘어간 데이터를 보니 재귀현상이 발생하고 있었고 이 문제를 해결하기 위해 Fetch Join을 사용하면서 발견했다. 해결 방안 쿼리를 분리하자! 여러 개의 컬렉션을 가져와야 할 경우, ..

예외 발생 이유 세션이 사라진 후 지연 로딩(LAZY) 상태에서 프록시 초기화가 불가능하기 때문에 발생하는 예외 지연 로딩 ( FetchType.LAZY ) 지연 로딩을 하는 이유는 JPA에서 발생하는 문제 중 가장 유명한 N + 1 문제를 해결하기 위함이다. 지연 로딩은 한번에 연관된 데이터까지 한번에 불러오는 것이 아닌 연관된 데이터를 필요한 시점에 그때 그때 불러오는 것이다. 그래서 왜 지연 로딩을 쓰는가? 예를 들어 Member과 Team테이블이 있고 Member와 Team는 N:1 관계가 있다. 이때 즉시 로딩(EAGER)을 하게 된다면 Team을 조회 시 해당 Team을 가진 모든 Member를 하나씩 조회하게 된다. 분명 Team 1개를 조회했는데 Team에 속한 Member N개의 조회 쿼..