TroubleShooting

캐싱 도입 이후캐싱 도입 이후에 발생한 문제들과 문제를 해결하면서서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 캐싱 도입 이후 발생한 문제들캐싱 도입 이후에 DB로의 부하가 많이 줄어들었습니다.대략적으로 발생헀던 문제들은 다음과 같습니다.캐시 만료 시점에 다량의 DB 데이터 조회가 발생데이터가 없는 경우 캐시 미스로 DB 조회가 추가적으로 발생캐시가 장애 발생한 경우에 처리량 급격히 저하핫키 만료시 다량의 DB 조회가 발생Redis 클러스터 구성에서 장애 노드 발생하여 클러스터 구성 정보 refreshDNS 구성된 노드의 변경시 장애 발생이러한 문제들을 겪으면서 했던 고민과 해결과정을 공유합니다.2. 캐시의 사용 이유캐시의 사용 이유에 앞서 백엔드 개발자의 주요 고민을 한번 볼까요?같은 리소스로..

분산 DB를 사용하면서 겪은 경험분산 DB인 Mongodb를 사용하면서 발생한 문제들과문제를 해결 하면서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 분산 DB 사용 하면서 겪은 문제운영 환경은 AWS의 Document DB를 사용하고 있었습니다.Document DB는 MongoDB와 호환되는 NoSQL DB 이지만 차이점이 조금 있습니다.바로 샤딩은 지원하지 않습니다. 하지만 Replica Set(복제셋)은 지원합니다. Replica Set 구성에서 primary 노드의 데이터는 secondary 노드에 동기화 됩니다.따라서 primary 노드에 장애가 발생하더라도 데이터는 모든 노드에 동기화 되기 때문에secondary 노드가 primary로 승격되어 정상적으로 서비스 운영이 가능합니다.서비..

캐싱 도입 과정캐싱을 도입하면서 발생한 문제들과 문제를 해결하면서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 캐싱 도입을 고민 하게된 이유캐싱을 도입하고자 하는 서비스는 다음과 같은 특징을 가지고 있었습니다.데이터가 insert된 이후 update가 거의 발생하지 않음CRUD중 R 연산이 압도적으로 많음짧은 시간동안 동일한 데이터의 Read가 매우 많이 발생이러한 이유로 인해 캐싱을 하게되면 DB접근 횟수를 줄이면서 응답속도를 빠르게 개선할 수 있을것으로 보였습니다.2. 초창기 캐싱 도입초기에는 In-Memory 캐시 도입을 고민하였습니다.데이터의 접근 속도가 Redis보다는 메로리에 접근하는게 더욱 빠르기 때문이었습니다.Redis에 데이터를 가져오기 위해서는 네트워크 통신을 통해야 하기 때문입..