이전에 프로젝트를 진행하면서 매일 00시에 테이블을 일괄적으로 갱신해는 작업이 있었습니다. 경험이 부족했던 그땐 batch 작업이라는 것이 스케쥴링을 돌리면서 진행하는 어떠한 것이라고 생각했었습니다. 기능의 존재만 어렴풋이 알고만 있었던 것이지요. 시간이 지나 이번에
이 ItemReader의 구현체들이 어떻게 되어있는지 살펴보겠습니다.가장 대표적인 구현체인 JdbcPagingItemReader가 있습니다.해당 클래스의 계층 구조를 살펴보면 아래와 같습니다.보통 개발자가 ItemReader와 ItemStream 인터페이스를 직접 구현
테이블 설계 시 PK를 int로 잡느냐, varchar(char)로 잡느냐를 한참 고민해 본 적이 있습니다.더블체킹에 대해서 어떻게 방어를 해야할까요?즉, 동시에 사용자가 같은 시간대에 대해서 예약(Reservation)을 한다는데 DB에서 Atomic한 방식을 생각해
대용량 트랙픽을 견뎌내기 위해서는 서버의 크기를 늘려야 합니다.서버의 크기를 늘리는 방법은 Scale-up 과 Scale-out 이 존재합니다.1) Scale-up수직적 확장을 의미하며 컴퓨터 서버자체의 성능을 업그레이드 하는 방식입니다. 하드웨어적으로 업그레이드를 위
결론적으로, 모든 세션이 하나의 DB를 바라보게 하기 위해서입니다. 불필요한 복제(Session-Clustering)가 일어나지 않고, 서버를 계속 추가시켜도 성능의 저하 우려(Sticky Session)를 해결할 수 있습니다.Disk(HDD, SSD)에 저장되는 데이
서버 분산 시스템으로 Scale-out할 시 문제점이 하나 있습니다. 기본적으로 웹서버가 대표적인 Scale-out 방식입니다. 네트워크로부터 온 다수의 request들이 동시에 올 수 있어 가져온 데이터의 정합성이 불일치 되는 문제가 발생할 수 있습니다.예를 들어,
Scale-out시, 프로젝트 에서는 평소에는 서버 트래픽은 잠잠하지만 갑자기 read 할 request 양이 많아 대용량 트래픽이 있을 수 있다고 말씀드렸습니다.이외에도 다른 관점에서 트래픽이 모이는 현상이 있습니다.read, write, update 등의 모든 연산
Cache란 자주 사용하는 데이터를 미리 저장해놓고 다시 이 데이터를 필요로 할 때마다 빠르게 참조하여 읽기 기능을 개선하는 기술입니다. 현재 진행 중인 프로젝트에서 성능 개선을 위해 캐시를 도입, 그 기술로 Redis를 선택했습니다. 대규모 트래픽을 처리해야 하는
ThradeGroup에서 사용자수를 295로 설정,무한한 시간대로 성능테스트를 해보았습니다.JMeter성능지표는 아래와 같습니다.사용자 수가 가장많이 사용할 서비스 기능은 스터디그룹 등록일 것으로 예상, 이 api의 성능을 테스트해본 결과는 아래와 같습니다.가장 중요한
HandlerMethodArgumentResolver 를 이용하여 Custom Annotion 을 만들어 User 정보를 쉽게 가져오기를 실습하겠습니다.회원을 관리하는 API 를 만들게 되면 꼭 필요로 하게 되는 것이 HandlerInterceptorAdapter 를
100백만 건이 넘은 건수가 있는 테이블 reservataion에서 조회 성능을 측정해보겠습니다.100백만 건수 insert 작업을 하기 위해선 Test 에서 실행할려고 합니다.Junit5 기준으로 Test 클래스를 생성합니다.기존에 작업한 쿼리들을 잘 보고 싶기에 h