웹 애플리케이션의 성능을 위해 고려해야할 부분은 정말 많습니다. WS 관점에선 이중화, 로드밸런싱, 캐싱, 커넥션 등, WAS 관점에선 스레드풀, 커넥션, 억셉트카운트, DB커넥션풀 등, DB 관점에선 커넥션 수와 인덱스 등이 있습니다. 그 중에서도 가장 드라마틱한 성능 개선을 만들어주는 것은 바로 캐시입니다. 가장 큰 병목을 유발하는 지점에 대해 수행하지 않고 재사용하거나, 수행하더라도 아주 짧은 시간 내에 처리될 수 있게 개선해주기 때문입니다. 캐시도 CPU에서부터 WAS, WS까지 정말 여러 영역에 걸쳐있는데요 첫번째로 WAS에서 사용되는 로컬 캐시에 대해 이해해보고자 합니다. 거기서도 다시 좁혀서 스프링에서 캐싱이 어떻게 제공되는지 살펴보겠습니다. 이를 위해 스프링 공식 문서를 통해 스프링이 제공..
MyRSS 프로젝트를 진행하며 스프링 설정 파일을 리팩터링한 내용을 정리해봤습니다. 설정 파일 공개 필요성 spring: config: import: - classpath:/2022-MyRSS-secret/application.yml 위 내용은 리팩터링 이전 application.yml 파일 내용의 전부입니다. 서브모듈로 Private Repository를 품고 있고, 그 안에 환경 설정 내용들을 담아두었습니다. Github Actions, Jenkins에서는 Github Personal Token을 전달해 서브모듈까지 가져와서 CI/CD를 수행합니다. 그대로 계속 작업해도 아무 문제 없지만, 공개 가능한 설정은 공개하도록 리팩터링하고 싶었습니다. 추가적으로, 서브모듈로 관리되는 보안이 필요한 접속정보 ..
3차 데모데이를 앞둔 현 시점 기준, 줍줍 팀의 서버 아키텍처와 고민했던 지점을 공유합니다. 3차 데모데이 시점, 줍줍의 서버 아키텍처 개발환경, 운영환경에 대해서만 나누어 구성을 완료하였습니다. Github Actions를 이용해 CI를 구성하였고, Git Flow 브랜치 전략을 채택하였으며, develop, main 브랜치에 merge가 발생할 경우, Jenkins에서 이 이벤트를 받아 테스트, 빌드를 수행하여 각각 개발, 운영 환경으로 배포하게 구성했습니다. 추후 운영 환경 백엔드 WAS에 대한 로드 밸런싱을 위해 추가적인 NGINX가 도입될 수도 있을 것 같습니다. CORS 설정이 불필요한 아키텍처 위와 같은 구성을 수행하며 가장 아쉬웠던 것은, 가장 앞에 있는 하나의 NGINX 였습니다. 백엔드..
스프링이 제공하는 테스트 관련 기능과 설정 중, 테스트 격리에 관련하여 헷갈리는 부분들을 정리해봤습니다! 학습 결과 요약은 다음과 같습니다! @Sql 애너테이션을 클래스 레벨에 선언하면 매 테스트 메서드 실행 전에 수행된다 @Sql 애너테이션을 메서드 레벨에 선언하면 해당 테스트 메서드 실행 전에 수행된다 클래스 레벨에 선언하고 메서드 레벨에도 선언하면, 메서드 레벨에 선언한 스크립트로 오버라이드 된다. 둘 다 실행하거나 하려면 merge 관련 다른 설정을 찾아봐야할듯. @Transactional 애너테이션을 클래스 레벨에 선언하면 매 테스트 메서드에 트랜잭션을 생성하고, 테스트 수행 후 롤백한다 테스트 메서드에 @Rollback(false) 또는 @Commit을 선언해서 롤백하지 않고 반영해버릴 수도 ..
크로스 사이트 스크립팅. 그 중에서도 가장 기초적인 저장 XSS공격에 대한 대응 포스팅이다. withIT 개발 단계에서 테스트했을 땐 스크립트가 작동되지 않아서 그냥 넘어갔었는데.. (왜 그땐 안된거지?;;) 혹시나 해서 테스트 해보니까 스크립트 태그가 너무 잘 작동해서;; 시급한 문제니까 바로 처리를 했다. db에 저장할 때부터 script 태그는 html에서 plain text로 인식되도록 변경 후 저장하도록 했다. 아주 초보적인 수준의 XSS공격과 대응이었다. 나중에 해보고 싶은 작업으로는 만약 XSS 공격이 인식될 경우 해당 접속 IP를 24시간동안 접속제한하는 로직에 흥미가 생겼다.
