전체 글

인증의 필요성 HTTP 통신은 요청과 응답이 종료되면 연결을 끊는 Connectionless 특성과 연결이 끊어지면 어떠한 상태도 유지하지 않는 Stateless한 처리 방식이다. 따라서, 로그인을 유지하기 위해서 쿠키, 세션, 토큰을 사용한다. Connectionless 프로토콜 클라이언트가 서버에 요청하고 응답을 받으면 연결을 끊는 처리 방식 Stateless 프로토콜 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다. 1. 쿠키 🍪 쿠키는 Key-Value 형식의 문자열로 사용자에게 맡겨도 되는 공개 가능한 정보를 사용자 브라우저에 저장시킨다. 쿠키 동작 방식 서버는 클라이언트의 로그인 요청에 대해 응답할 때, 클라이언트를 식별하는 작은 정보를 Response Header의 set-cooki..

MySQL의 격리 수준 트랜잭션의 격리 수준(Isolation Level)이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 격리 수준은 크게 4가지로 나뉜다. Read UNCOMMITTED Read COMMITTED REPEATABLE READ SERIALIZABLE 1번부터 4번까지 뒤로 갈수록 각 트랜잭션 간의 데이터 격리(고립) 정도가 높아지며, 동시 처리 성능도 일반적으로 떨어질 수 있다. 격리 수준이 높아질수록 MySQL 서버의 처리 성능이 많이 떨어질 것으로 생각할 수 있지만, 사실 SERIALIZABLE 수준이 아니라면 크게 성능 저하가 발생하지는 않으니 안심해도 된다. 하나 특별한 부분이 있다..

JOIN이 어떻게 인덱스를 사용하는지에 대해 쿼리 패턴별로 알아보고 주의사항에 대해서 알아보고자 한다. 1. JOIN의 순서와 인덱스 인덱스 레인지 스캔은 인덱스를 탐색(Seek)하는 단계와 인덱스를 스캔(Scan)하는 과정으로 구분할 수 있다. 일반적으로 인덱스를 이용해서 쿼리하는 작업에서는 가져오는 레코드의 건수가 소량이기 때문에 인덱스 스캔 작업은 부하가 작지만 특정 인덱스 키를 찾는 인덱스 탐색 작업은 상대적으로 부하가 높다. 조인 작업에서 드라이빙 테이블을 읽을 때는 인덱스 탐색 작업을 단 한 번만 수행하고, 그 이후부터는 스캔만 실행하면 된다. 하지만 드리븐 테이블에서는 인덱스 탐색 작업과 스캔 작업을 드라이빙 테이블에서 읽은 레코드 건수만큼 반복한다. 드라이빙 테이블과 드리븐 테이블이 1:1..

1. 성능 최적화 계기 현재 관리자 페이지에서 예약 내역을 페이징 처리하여 조회할 수 있는 기능이 있다. limit는 20으로 한 페이지당 20개의 예약 컨텐츠를 보여주고 있다. 전체 예약 데이터는 354,200개인 상황이고 해당 API의 성능이 평균적으로 1.74초의 시간이 걸렸고 최대 1.99초까지 걸림으로써 성능이 좋지 못했다. 해당 성능을 최적화할 수 있는 방법을 모색하기 시작했다. 미리 말하자면, 평균 56.2%의 성능향상을 맛보게 되었다! 2. 반복되는 Count Query를 개선해보자! 해당 부분에서 성능을 최적화할 수 있는 부분으로 가장 눈에 띈것은 매번 반복되는 전체 데이터의 수를 측정하는 Count Query였다. "굳이 Count Query가 페이지마다 매번 반복될 필요가 있을까?" ..

1. 토큰 재발급에 저장공간이 필요한 이유 현재 JWT 인증방식을 적용하고 있다. 해당 방식의 플로우는 대략 아래와 같다. 로그인시 Access Token과 Refresh Token이 발급된다. 권한이 필요한 API의 경우 header에 Access Token을 추가하여 요청한다. Access Token이 만료된 경우에는 Refresh Token을 통해 Access Token과 Refresh Token 모두 재발급 받는다. 이러한 절차 과정에서 토큰을 저장할 공간이 필요하다. 현재 사용하고 있는 RDBMS인 MariaDB를 사용한 경우와 Redis를 사용한 경우 기능, 성능적 차이를 비교해보았다. 아래는 최종 비교 결과이다. Redis에 대해 자세히 알고 싶으면 이전에 작성한 포스팅을 참고하자! 2023..

1. Redis Temporary Location For Speed 데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소 많은 애플리케이션에서 속도 향상을 위해 캐시를 이용한다. 당연히 속도를 높이려면 원본에 접근하는것보다 캐시에 접근하는게 빨라야 한다. 그리고 데이터의 반복적 액세스가 많아질수록 캐시를 사용하는게 유리하다. 아래와 같은 특징을 가진다. 단순한 key-value 구조 In-memory 데이터 저장소 (RAM) 빠른 성능 평균 작업속도 < 1ms 초당 수백만 건의 작업 가능 이외에도 최신 버전의 Redis는 데이터 저장뿐만 아니라 PUB/SUB 구조를 통해 메시지를 전달하는 용도로도 사용 가능하다. Redis는 메모리에 데이터를 저장하기 때문에 저장 공간에 제약..