캐싱을 도입했다가 철회한 경우들. (두번째 경우)

B. 두번째 경우: Redis -> Kafka

캐시 -> 이벤트

1.  캐시를 사용한 이유

• 위치정보는 Member와 같은 테이블에 저장되어 30초 단위로 자주 업데이트 됩니다.
• 그래서 자주 Member MS(맴버 정보 MS)의 스레드 사용이 사용됩니다.
• 또한, 변경이 30초마다 있기에 Member의 테이블에 자주 락이 걸립니다.
• 이는 Member MS의 다른 CRUD 활동에 지장을 준다고 생각했습니다. 

2. 캐시서버를 포기하고 Member MS의 DB를 다시 이용한 이유

• 다른 MS에서 사용되어서 글로벌 캐시로 이용되기 위해 캐시서버가 증설되었습니다. 
• 그렇지만 사실상 캐시 서버는 추가로 DB서버를 증설 시키는 것과 같은 역할을 하고 있었습니다.
• 키 맵 형식으로만 쓰였기에 정확히는 추가로 NoSQL 서버를 둔 것같은 역할 입니다.
• 개인 프로젝트라 쉽게 도커를 이용하여 서버를 증설하였지만 Member MS에 정말 무리가 가는지 정확한 이유가 없이 서버가 증설이 되었다는 생각이 들었습니다. 

3. MS간 비동기 통신 적용

• LineUp MS(대신 줄서기 MS)에서 글로벌 캐시를 이용하지 않고 Member MS를 통해 데이터를 가지고 와야해서 MS간 통신이 필요하였습니다. 
• 이전에는 MS간 통신이 필요한 순간이 적었지만 현재는 줄서기 요청이 새로 생길때 마다 알림을 보내야 하기에 매번 Member MS와의 통신이 필요합니다. 
• 이 경우 LineUp MS는 Member MS에 의존성이 생기게 되고 매 요청마다 스레드들이 Member MS의 응답을 기다려야하여 독립적인 MS로 존재할 수 없습니다. (MS간 SRP위반, 강결합 상태)
• 이를 해결하여 느슨한 결합(Loose Coupling)의 MS로 만들기 위해 위해 MSA에 메시지큐를 사용해 EDA(Event Driven Architecture)를 적용하여 MS들끼리 토픽을 발행하고 구독하는 Pub/Sub 방식으로 변경하였습니다.

Article 2. 카프카를 통한 Pub/Sub 구현 및 분산 트랜잭션 사용기