본문 바로가기
반응형

전체 글130

공간 좌표를 사용할 때 MySQL과 MongoDB의 성능 비교 스프링부트를 이용한 프로젝트를 진행하면서 공간 좌표를 다룰 수 있는 기회를 가질 수 있었습니다.요구 사항은 서울시에서 관리하는 여러 공공 쉼터들의 데이터를 DB에 저장해 놓고 사용자가 앱을 이용하면 해당 사용자의 근방 Nm에 있는 쉼터 정보를 모두 프론트로 넘겨주어야 하는 것이었습니다.해당 요구 사항을 만족시키기 위해서 구현한 내용 및 리팩토링 과정을 소개하도록 하겠습니다.MySQL st_distance_sphere 함수를 이용한 공간 좌표 활용저는 공간 좌표를 다루기 위해서 우선 저에게 제일 익숙한 DBMS인 MySQL을 사용하였습니다. 아래와 같은 도메인을 만들었고 경도, 위도를 따로 저장하여 활용하였습니다.package com.shwimping.be.place.domain;import com.shw.. 2024. 9. 23.
AOP를 이용한 분산락(Named Lock) 처리 아래의 게시글에서 마지막 부분에 분산락을 처리하기 위하여 @Transactional에 propagation 속성을 REQUIRES_NEW로 설정했었습니다. synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용한 데드락 처리이번 게시글에서는 synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용하여 데드락을 처리해 보도록 하겠습니다.우선 제가 redis나 zookeeper 등을 사용하여 데드락을 처리하지 않은 이유는 새dy-coding.tistory.com하지만 위의 방식은 커넥션을 추가로 필요로 하고 이 때문에 많은 요청이 한 번에 오면 커넥션을 얻지 못하여 데드락이 발생하는 상황도 발생했습니다.위의 상황을 막기 위해서 커넥션 풀을 분리하면 .. 2024. 7. 28.
synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용한 데드락 처리 이번 게시글에서는 synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용하여 데드락을 처리해 보도록 하겠습니다.우선 제가 redis나 zookeeper 등을 사용하여 데드락을 처리하지 않은 이유는 새로 인프라를 추가하게 된다면 개발 환경, 배포 환경 등에 변화가 생기게 되어 이로 인한 side effect가 발생할 수 있기 때문입니다.제가 진행했던 프로젝트에서는 redis를 사용하지 않았기 때문에 redis를 이용하여 분산락을 처리하지 않고 mysql에서 제공하는 분산락(named lock)을 이용하도록 하겠습니다.데드락 발생 상황우선 데드락이 발생하는 상황에 대해서 먼저 설명해 드리도록 하겠습니다.요구 사항은 유저가 ImageQuiz 문제를 풀고 제출하면 서버에서 이를 채.. 2024. 7. 26.
Prometheus, Grafana를 이용한 EC2 모니터링 환경 구축 프로젝트를 진행하면서 이후 유저에게 서비스를 제공하는 상황을 대비하여 배포 서버에 대한 모니터링 환경 구축을 해보고자 합니다.데이터 수집 툴 선택우선 EC2를 모니터링하기 위한 방식을 선택할 때 2가지의 선택지를 고민했었습니다.첫 번째 선택지는 InfluxDB였고, 두 번째는 Prometheus였습니다. 둘 다 TSDB(Time Series DataBase)로써 시계열 데이터를 다루는 데에 특화된 데이터베이스입니다.저는 이 두 TSDB 중에서 아래의 글들을 참고하여 Prometheus를 선택하였습니다.https://multicloud.tistory.com/m/84 Prometheus vs InfluxDB편향적인 내용으로 당연히 절대 평가는 되지 않습니다. 상황에 맞게 써야 하며, 특성을 참고하는데 도움은.. 2024. 7. 18.
Logback을 이용한 EC2 환경 로그 관리 이번 게시글에서는 Logback을 활용하여 EC2 환경에서 로그 관리하는 방법에 대해서 다루도록 하겠습니다.프로젝트를 진행하면서 로컬에서 개발할 때는 바로 로그를 확인할 수 있지만 EC2에 프로젝트를 배포해 놓았을 때는 로그를 바로 확인하지 못하면 사라지는 문제가 있었습니다.오류가 발생해도 로그 관리를 하지 못하여 인지하지 못하거나 다시 확인하지 못하는 것은 심각한 문제라 생각하여 스프링에서 제공하는 기능은 Logback을 활용하여 로그 관리를 하기로 결정하였습니다.로그백 설정Logback은 build.gradle에서 아래와 같은 라이브러리를 등록하면 사용할 수 있습니다. 해당 라이브러리는 스프링 개발을 위해서 필수적이기 때문에 사실상 추가로 해주어야 하는 작업은 없다고 생각하시면 됩니다.implemen.. 2024. 7. 17.
QueryDSL을 활용한 동적 쿼리 처리 이번 게시글에서는 QueryDSL을 활용하여 동적 쿼리를 처리하는 방식에 대해서 다루도록 하겠습니다.QueryDSL이란 오픈소스 프로젝트로 JPQL을 Java 코드로 작성할 수 있게 해주는 라이브러리입니다.QueryDSL의 장점은 @Query로 바로 JPQL을 사용하는 경우 런타임에 Exception이 발생하지만 QueryDSL을 사용한다면 잘못된 쿼리를 작성했을 때 컴파일 시점에 에러가 발생하기 때문에 빠르게 문제를 파악할 수 있다는 것입니다.또한 QueryDSL은 복잡한 동적 쿼리를 작성하는 것을 간단하게 해주는 장점이 있습니다.먼저 제가 프로젝트에 QueryDSL을 도입하게 된 상황에 대해서 소개해드린 후 QueryDSL을 사용하기 위한 설정과 어떻게 적용했는지를 설명하도록 하겠습니다.QueryDS.. 2024. 7. 17.
join 제거, dto projection, covering index를 활용한 성능 최적화 이 게시글은 프로젝트를 진행하면서 발생한 쿼리를 최적화하는 과정에 대한 내용을 담고 있습니다.우선 요구 사항은 아래와 같습니다.유저는 자신만의 문제를 등록할 수 있다. 유저가 등록한 문제는 등록한 유저 본인만이 풀 수 있어야 하고 관리자가 등록한 기본 문제들도 풀 수 있다. 이때 api를 요청할 때마다 정말 랜덤한 문제가 N개씩 불러와져야 한다.지금부터 리팩토링하면서 코드가 어떻게 변경되었는지 설명드리겠습니다.각각의 단계에서의 성능 비교에 대한 내용은 글의 마지막 부분에 있습니다.기존 코드처음 이 요구사항을 들었을 때 정말 랜덤한 문제를 어떻게 가져올 수 있을까에 대한 고민이 있었습니다. 따라서 처음 생각했던 방식은 해당 유저가 풀 수 있는 문제가 몇 개인지 확인 후 그 문제가 K개라고 하면 0 ~ K .. 2024. 7. 4.
spring 프로젝트에서 더미 데이터 사용 & 테스트용 fixture 사용하기 spring 프레임워크를 이용하여 프로젝트를 진행하다 보면 만든 코드가 정상적으로 동작하는지 확인할 필요가 있습니다.이때 테스트 코드를 이용하여 비즈니스 로직이 잘 작동하는지, Controller 부분이 정상적으로 동작하는지 확인하는 것도 중요하고 실제로 요청을 보냈을 때도 테스트 결과와 같이 의도한 대로 잘 동작하는지 확인하는 것이 필요합니다.이번 포스트에서는 개발 환경에서 실제 api 요청을 보냈을 때 응답을 위한 데이터를 넣는 방식과 테스트 코드를 위한 데이터를 넣는 방식에 대해서 다루도록 하겠습니다.DB에 더미 데이터 넣기서버를 작동시킨 후 실제 요청에 맞는 데이터를 응답으로 보내주기 위해서는 DB에 실제로 데이터를 넣어야 합니다.이때 서버를 실행시킨 다음에 sql을 이용하여 DB에 데이터를 넣어.. 2024. 6. 16.
반응형