인생을 코딩하다.

Redis Pipeline에 설명하기에 앞서 No Pipeline에 관해 간략하 말씀드리겠습니다. redis는 요청을 보낼 때 일반적으로 아래와 같이 수행됩니다. 클라이언트는 서버에 쿼리를 보내고 일반적으로 차단 방식으로 소켓에서 서버 응답을 읽습니다. 서버는 명령을 처리하고 클라이언트에 응답을 다시 보냅니다. Redis는 클라이언트-서버 모델과 요청/응답 프로토콜을 사용하는 TCP 서버이며, 클라이언트가 서버에 명령을 보내고 응답을 받는 구조입니다. 위 과정은 클라이언트가 연속적으로 많은 요청을 보내야 하는 경우 RTT가 길어져 성능에 악영향을 미칠 수 있습니다. 예를 들어 RTT가 250밀리초인 경우, 초당 최대 4개의 요청만 처리할 수 있습니다. 만약 요청이 1000개라면 엄첨 느리겠죠? 위와 같이..

안녕하세요. 이번에는 프로젝트에서 Redis를 적용해야 하는 이슈가 생겼는데요. Redis를 적용해야 하는 이유는 여기서 확인 하실 수 있습니다. 우선 Spring Boot Redis Docs와 함께 외부 Redis에 간단히 알아볼까요? https://docs.spring.io/spring-boot/docs/2.0.0.M7/reference/htmlsingle/#boot-features-connecting-to-redis hget "spring:session:sessions:9a398c47-36c6-4d33-95d1-80f51447f7eb" "sessionAttr:email" "\xac\xed\x00\x05t\x00\x0fadmin@gmail.com" 하지면 여기서 문제가 하나 있습니다. 스프링에서 로그..

프로젝트를 scale out 방식으로 확장할 계획을 하면서 그에 따른 session의 정합성에 관한 이슈가 생겼습니다. 별도의 독립적인 session 저장소로 세션의 정합성 문제를 해결하기 위해서는 대표적인 redis와 memcached 데이터 베이스를 고려해볼 수 있습니다. Amazon ElastiCache는 Memcached 및 Redis 캐시 엔진을 지원합니다. 각 엔진에는 몇 가지 장점이 있습니다. 이 항목의 정보를 활용하면 요구 사항에 가장 잘 맞는 엔진과 버전을 선택하는 데 도움이 됩니다. Memcached와 Redis 엔진은 둘 다 인 메모리 키-값 저장소입니다. NoSql 데이터베이스라고도 할 수 있죠. 그러나 실제로 상당한 차이점이 있습니다. session의 정합성 이슈를 해결하기 위해서..

프로젝트에서 세션 로그인 기능을 만들었습니다. 그리고 추후 저는 대용량 트레픽을 감당할 수 있는 서버를 만들 계획이 있었습니다. 대용량 트레픽을 감당할 수 있는 서버를 만들기 위해 scale up을 고려해 서버를 한 대만 놓는다면, 서버 한 대에 모든 부하가 집중되므로 장애 시 서버가 복구될 때까지 서비스를 중단해야 하는 상황이 발생합니다. 사용하려던 서비스가 중단된다면, 그에 안좋은 기억이 생기고 타 서비스로 이용을 바꾸거나, 서비스를 사용하지 않을 수 있는데, 이것은 엄청난 비즈니스 손실(수익 손실)이 생길 수 있습니다. 그러기 위해선 scale out을 고려해 서버를 확장해야 했습니다. 하지만 서버 확장시 제가 만든 세션 로그인 기능에 문제가 생길 우려가 있었습니다. 이 문제는 아래에서 그림과 함께..

Redis(Remote dictionary server)란? Remote -> 외부, dictionary -> HashMap (Key - Value), server -> 서버 Database, Cache, Message borker In-memory Data Structure Store Supports rich data structure Redis(레디스)는 REmote DIctionary Server의 약자로 오픈소스DBMS입니다. In-memory 데이터 저장소이며, Key-Value기반의 NoSQL DBMS입니다. 보통 DB, Cache(캐시), 메시지 브로커 등의 용도로 사용합니다. Redis를 효율적으로 쓰기 위해선 Cache에 관해 잘 알아야합니다. Cache는 나중의 요청에 대한 결과를 미리..