[리팩토링] 작은 깨달음 : 리팩토링을 하기엔 데이터 수가 너무도 적었다

 

지난 번 Redis 서버가 미국에 있는 바람에 캐싱을 적용하자 오히려 느려졌다(?)

https://thiswooin.tistory.com/134

[리팩토링] 레디스 캐싱을 통한 인증과정 유저정보 조회 속도 개선하기

 

ElastiCache는 추후 적용해보려 하고

우선은 빠르게 EC2 인스턴스에 Redis-server를 설치하여 이를 통해 해결해보려 한다.

---

 

Redis 설치 on EC2

 

1. EC2 인바운드 규칙에 6379 포트 열주기

외부에서 해당 퍼블릭 IPv4의 6379포트를 들어가야하므로.

 

2. EC2 인스턴스에 Redis 설치

sudo apt-get install redis-server

 

2-1. 설치 확인

 

2-2. redis.conf 설정파일 업데이트

 

외부에서도 접근할 예정이므로 외부 ip를 모두 허용.

+ 비밀번호 설정 (requirepass)

+ 최대 메모리 (maxmemory)

등 설정 완료.

 

---

 

결과

 

Redis Cloud (US 서버)

 

 

Redis On EC2 (Seoul 서버)

 

 

우선 말도안되는 느려짐 현상은 해결이 됐다.

하지만 기존 속도에 비해서 엄청 빨라지진 않았다.

반대로 얘기하자면 애당초 속도를 줄일 정도로 오래걸리는 API가 아니었던 듯하다.

 

 

findUserByUsername( ) 측정

 

RDS에서 가져오기

 

Redis on EC2에서 가져오기

 

 

그럼에도 대략 10ms 빨라졌으며 쿼리를 날리지 않아도 되는 이점을 얻었다.

 

---

고민할 점

애당초 별로 안느렸다

고민 끝에 들은 생각은 지금 RDB 상에 User데이터가 그렇게 많지 않아 애당초 동작시간이 길지 않았었던 것일 수 있다.

응답속도는 유저의 데이터 수가 많아지면 오래걸릴 수 있지만 DB의 인덱스를 적용해 캐싱없이도 빠르게 가져올 수 있을 것이다.

 

새롭게 떠오른 캐싱이 적절한 데이터의 조건

앞서, 조회가 많고 데이터의 변화가 적은 것이 캐싱을 적용하기 좋다고 생각했었다.

여기에 추가로 드는 생각은, RDB의 경우 인덱스를 적용하기 힘들거나 쿼리가 복잡하거나 탐색시간이 긴 경우에 더욱 빛을 발할것 같다.

쉽게 말해 캐싱 말고는 빠르게할 방법이 없는 친구들.