본문 바로가기

전체 글

 (47)
캐싱을 도입했다가 철회한 경우들. (두번째 경우) B. 두번째 경우: Redis -> Kafka1.  캐시를 사용한 이유위치정보는 Member와 같은 테이블에 저장되어 30초 단위로 자주 업데이트 됩니다.그래서 자주 Member MS(맴버 정보 MS)의 스레드 사용이 사용됩니다.또한, 변경이 30초마다 있기에 Member의 테이블에 자주 락이 걸립니다.이는 Member MS의 다른 CRUD 활동에 지장을 준다고 생각했습니다. 2. 캐시서버를 포기하고 Member MS의 DB를 다시 이용한 이유다른 MS에서 사용되어서 글로벌 캐시로 이용되기 위해 캐시서버가 증설되었습니다. 그렇지만 사실상 캐시 서버는 추가로 DB서버를 증설 시키는 것과 같은 역할을 하고 있었습니다.키 맵 형식으로만 쓰였기에 정확히는 추가로 NoSQL 서버를 둔 것같은 역할 입니다.개인 프..
카프카를 통한 Pub/Sub 구현 및 분산 트랜잭션 사용기 A. MS간 통신에서 생기는 이슈들1. 비동기/논블로킹MSA(MicroService Architecture)를 사용하게 되면 관리의 범위가 작아져서 배포가 쉬워지며 복잡한 서비스에서 모놀리식 구조(Monolithic Architecture)보다 변경이 쉬워 집니다.그렇지만 이런 MSA의 장점을 온전히 이용하려면 MS간 의존도가 낮아 느슨한 결합(Loose Coupling)이 이루어져 있어야 합니다.기존의 동기 방식의 통신을 적용시 MS간 의존도가 생기기에 정합성이 매우 중요한 경우가 아니라면 비동기/논블로킹 방식을 이용하여 MS간 의존도를 낮추는 것이 권장 됩니다. 비동기/논블로킹 방식은 WebClient같은 HTTP클라이언트를 이용할 수도 있고 중간에 브로커 서버를 두는 메시지 큐(Message Que..
서버 성능을 테스트하기 위한 부하테스트 프로젝트가 마무리에 다가오고 있어서 서버의 성능을 테스트해보기로 했습니다. 실제 환경과 최대한 비슷하게 테스트를 하기 위해 Naver Cloud를 이용하여 서버와 클라이언트 각각 EC2를 만들어서 클라이언트에서 서버로 요청을 받는 방식으로 테스트 하였습니다.  A. 성능 테스트의 종류 (SK C&C, DCube-Team Merlin) 1. 부하테스트(Load Test)유저의 수와 초당 API 요청등을 증가시키며 시스템의 임계점(Peak Load) 을 찾기 위한 테스트입니다. 부하 상황에서 시간이 지남에 따라 성능을 확인하는 것으로 어플리케이션이 장시간의 부하 상황에서 어떤 퍼포먼스를 보여주는지 테스트 합니다.  30-1시간 정도 진행 됩니다. 2. 스모크 테스트(Smoke Test) 1-3명 정도의 최소..

티스토리툴바