해당 프로젝트에서 채팅 구현을 맡고 있었다. 이전까지는 단지 STOMP프로토콜을 사용해 직접 client에게 메세지르 바로 보내는 것을 구현하였다. 하지만 해당 과정은 synchronize하기 때문에 다량의 트래픽이 몰린다면 문제가 발생될 수 있었다. 이것을 해결하기 위해서 pub/sub 구조인 Message queue를 도입하고자한다. Message queue의 후보지는 2가지가 있다. 1. Kafka 2. Redis 이 두개의 차이점을 비교하고 현재 나의 프로젝트에 맞는 Message Queue를 선택하고자 한다. 또한 DB도 문제이다. 현재는 MYSQL에다 채팅 데이터를 저장하고 있다. 항상 고민됐던게 MYSQL에 트랜잭션도 자주 발생하고 성능도 고려가 된다... 만약 채팅을 위한 DB를 구성하고 ..

이번 소프티어 부트캠프를 하면서 주유소 검색 기능을 추가해야 했었다 사용자가 입력하는 주유소 이름을 기반으로 18000개의 데이터를 full scan 해야 하는 상황.. 저희는 당연히 redis가 더 빠를것이라 생각해서 redis에 주유소 정보를 모두 저장하였다. 구조는 다음과 같다. 즉 12000개의 주유소의 PK가 Key값으로 저장되고 해당 key는 Object로 GasStation정보를 가지고 있다. Redis로 주유소를 검색하는 경우 요청 받은 이름이 포함되어 있는것은 List에 add 하여 요청이름이 포함되는 주유소 리스틀 보여주는 과정을 API 구축을 하였다. full scan 했을때 3분이 걸렸다.. ㅋㅋㅋㅋㅋ DB(MYSQL)로 주유소를 검색하는 경우 0.3초가 걸렸다.. 결론 왜 이럴까?..

IMDG? IMDG란 In-momory-data-grid로 아래 사진과 같은 형태의 아키텍쳐 입니다. 다음 그림과 같이 여러개의 메모리를 grid 형태로 보관하며, 메모리를 데이터베이스와 같은 형식으로 사용하는것입니다. 당연히 memory를 데이터 베이스로 사용한다면 더 빠르다는 장점이 있습니다. 또한 예전에는 memory의 크기가 작다는 한계가 있었지만, 기술적인 발전으로 memory의 크기가 상대적으로 증가하고 위와 같은 형태의 여러개의 memory를 하나의 memory처럼 사용하여 빠른속도로 데이터를 read/write를 할 수 있습니다. IMDG 사용 예제 Hazelcast Terracotta Enterprise Suite VMware Gemfire Oracle Coherence Gigaspace..