분류 전체보기13 캐시 도입 이후에 내가 경험 한 것들 캐싱 도입 이후캐싱 도입 이후에 발생한 문제들과 문제를 해결하면서서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 캐싱 도입 이후 발생한 문제들캐싱 도입 이후에 DB로의 부하가 많이 줄어들었습니다.대략적으로 발생헀던 문제들은 다음과 같습니다.캐시 만료 시점에 다량의 DB 데이터 조회가 발생데이터가 없는 경우 캐시 미스로 DB 조회가 추가적으로 발생캐시가 장애 발생한 경우에 처리량 급격히 저하핫키 만료시 다량의 DB 조회가 발생Redis 클러스터 구성에서 장애 노드 발생하여 클러스터 구성 정보 refreshDNS 구성된 노드의 변경시 장애 발생이러한 문제들을 겪으면서 했던 고민과 해결과정을 공유합니다.2. 캐시의 사용 이유캐시의 사용 이유에 앞서 백엔드 개발자의 주요 고민을 한번 볼까요?같은 리소스로.. 2024. 11. 14. Mongodb를 사용하며 내가 경험 한 것들 분산 DB를 사용하면서 겪은 경험분산 DB인 Mongodb를 사용하면서 발생한 문제들과문제를 해결 하면서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 분산 DB 사용 하면서 겪은 문제운영 환경은 AWS의 Document DB를 사용하고 있었습니다.Document DB는 MongoDB와 호환되는 NoSQL DB 이지만 차이점이 조금 있습니다.바로 샤딩은 지원하지 않습니다. 하지만 Replica Set(복제셋)은 지원합니다. Replica Set 구성에서 primary 노드의 데이터는 secondary 노드에 동기화 됩니다.따라서 primary 노드에 장애가 발생하더라도 데이터는 모든 노드에 동기화 되기 때문에secondary 노드가 primary로 승격되어 정상적으로 서비스 운영이 가능합니다.서비.. 2024. 7. 7. 캐싱을 도입하며 내가 경험 한 것들 캐싱 도입 과정캐싱을 도입하면서 발생한 문제들과 문제를 해결하면서 겪은 경험을 공유하고자 글을 작성하였습니다 :b1. 캐싱 도입을 고민 하게된 이유캐싱을 도입하고자 하는 서비스는 다음과 같은 특징을 가지고 있었습니다.데이터가 insert된 이후 update가 거의 발생하지 않음CRUD중 R 연산이 압도적으로 많음짧은 시간동안 동일한 데이터의 Read가 매우 많이 발생이러한 이유로 인해 캐싱을 하게되면 DB접근 횟수를 줄이면서 응답속도를 빠르게 개선할 수 있을것으로 보였습니다.2. 초창기 캐싱 도입초기에는 In-Memory 캐시 도입을 고민하였습니다.데이터의 접근 속도가 Redis보다는 메로리에 접근하는게 더욱 빠르기 때문이었습니다.Redis에 데이터를 가져오기 위해서는 네트워크 통신을 통해야 하기 때문입.. 2024. 7. 5. [Spring] profile별 환경 분리 하기 Spring profile별 환경 분리 하기 1. 환경을 분리해야 하는 이유? 실무에서 개발할때는 운영 환경에 테스트를 할수는 없습니다. 테스트시에 혹여나 데이터를 잘못 건드리는 경우는 장애를 초래 할수 있기 때문인데요. 테스트간 별다른 큰 문제가 발생하지 않으면 좋겠지만, 그렇지 않을 확률이 높으니까요. 그래서 테스트시에는 별도로 분리된 환경에서 테스트하는것이 좋습니다. 혹여나 잘못되더라도 운영 환경에는 아무런 영향이 없기 위함입니다. 예를들면 테스트간 사용하는 DB는 개발용도로만 사용하는 DB이면 좋을것입니다. 2. 어떻게 분리된 환경을 사용할까? 스프링에서는 설정된 프로필에 따라 다른 환경에서 구동될수 있도록 하는 기능을 제공하고 있답니다. 예를 들어 개발환경에서 테스트하는 경우 로컬 DB에 접근 .. 2024. 2. 13. 이전 1 2 3 4 다음
