e-commerce 대용량 서버 프로젝트

deserialize 문제입니다.

단위테스트에서 @SpringBootTest가 적합하지 않은 이유에 대한 내용입니다.

서버 운영 중, 갑작스런 이용자의 증가나 사업의 확장 등으로 인하여 용량 및 성능을 늘리기 위한 시스템의 확장이 필요합니다. 이러한 시스템 확장 방식은 스케일 업(Scale-up)과 스케일 아웃(Scale-out)으로 구분할 수 있습니다.

스케일 아웃으로 서버의 저장소가 여러 대로 분산되면서 로드밸런싱을 통해 부하를 분산 처리해야 하는데, 이 때 세션 불일치 문제가 발생합니다. 이를 해결하는 방법에 대하여 정리해 보았습니다.

In-memory DB인 Redis와 Memchaced중에서 세션 저장소로 어떤 것이 적합할지 비교해 보았습니다.

redis에서 session이 어떻게 저장되고 삭제되는지 확인해 보았습니다.

프로젝트의 규모가 클수록 코드 작성부터 통합까지의 단계를 자동화해주는 CI의 필요가 커집니다. CI툴로는 Jenkins를 이용하였고, jenkins에 접속하여 설정하는 과정을 정리하였습니다

성능 테스트를 진행하기 전, 좀 더 유의미한 테스트를 진행하기 위한 방법으로 가짜 데이터인 `더미테이터`를 DB에 넣어보았습니다.

프로젝트의 규모가 커질수록 코드 검증과 배포를 자동화해주는 CD가 빛을 발합니다. 특히 스케일 아웃으로 서버 성능을 높일 예정이었던 프로젝트에 CD구축이 필요하다 생각하였고 이 과정을 기록해보았습니다.

실제로 트래픽을 받았을 때 성능이 어느정도까지 도달할 수 있는지 nGrinder을 사용하여 측정해보았습니다. 이 글은 nGrinder controller/agent의 설치 과정과 Groovy Script를 작성해 테스트를 실행한 결과를 담고 있습니다.

nginx를 사용해 로드밸런싱을 진행하여 스케일 아웃을 실제로 구현해보았습니다.

Redis캐시와 스케일아웃으로 대용량 서버 프로젝트의 성능을 최적화한 결과를 nGrinder와 pinpoint 로 확인해보았습니다.