현재 프로젝트에서 구축한 모니터링 중 로그는 서버 인스턴스의 Loki Agent인 Promtail을 사용하고, 메트릭은 Prometheus의 수집 기능을 통해 즉 Server Pull 방식으로 사용하고 있다. 각 툴의 방식이 고정적인줄 알고 있었는데, 면접 당시 Agent Push, Server Pull을 물어보는 질문에 대답을 못했던 기억이 있다. 각각의 방식을 비교하고 언제 각 수집 방법을 사용하는게 적합한지 학습하고자 정리한다. Agent PushAgent가 데이터를 모니터링하고, 서버(모니터링 시스템)로 데이터를 직접 전송하는 방식이다.장점Agent는 데이터를 수집한 즉시 전송하므로 지연이 적다.모니터링 서버는 별도로 데이터를 가져오거나 할 필요없이 Agent가 전송한 데이터를 기다리기만 하면 되..
프로젝트에서 데이터를 저장한 시점에 따라 조회가 되는지 아닌지에 대한 로직, 즉 시간에 의존한 테스트가 있었다.시간은 개발자가 제어할 수 없는 영역이기 때문에 보통 mocking을 하거나 더미데이터를 사용해서 테스트를 진행할 수 있다.해당 테스트에서는 시간 자체에 의미가 있지는 않고 mocking하는 것보다는 더미데이터를 활용해서, 기간이 지난 데이터를 미리 넣어두는 것이 간편하다고 판단해서 해당 방식을 선택했다. 더미데이터는 메서드 레벨에 @Sql 어노테이션을 활용하여 작성한 sql 파일을 저장하도록 했다.그런데 더미데이터가 계속해서 저장되지 않는 문제가 있었다.@Sql의 동작 원리@Sql은 어떻게 동작할까?내부적으로 SqlScriptsTestExecutionListener에 의해 실행된다.SqlScr..
어느날 "Http gzip 진행할게요" 라는 팀원의 이슈가 올라왔다.http 압축은 구구의 특강 때 들었었는데, 단지 http 메시지를 압축해서 효율을 올린다 정도만 기억하고 있었다. 이참에 제대로 알아보고자 작성한다! HTTP Compression 이란?HTTP 압축은 서버가 클라이언트에게 리소스를 전송하기 전에 데이터를 압축하는 방식이다.대표적으로 gzip이 사용되며, 클라이언트는 요청 시 Accept-Encoding 헤더를 통해 지원하는 압축 방식을 서버에 알린다. 서버는 압축 방식을 선택하여 사용 후 Content-Encoding 응답 헤더를 이용해 선택된 것을 클라이언트에게 알린다. HTTP 응답을 압축하면 웹 사이트의 성능을 높일 수 있다. Http Compression 설정스프링 부트에서는 ..
어느 날 제 게시글을 보다가 오잉 두 querydsl을 목격했습니다. 코드잽의 태그 정책은 다음과 같습니다.동일한 이름의 태그일 경우 하나만 생성이 가능하다.즉, 이미 존재하는 이름의 태그일 경우 해당 태그를 공유한다.비슷하게 메타 정보 역할을 하는 카테고리와 비교를 해보면, 태그라는 도메인 특성상 커스텀을 하기보단 중복도가 높을 것이라고 판단했기 때문입니다. 그런데 태그에서 중복된 이름이 발견되어 버렸습니다. 큰 문제이지 않을 수 있지만 만약 다른 사용자가 새로운 템플릿을 생성할 때, 동일한 "querydsl"이라는 이름의 태그와 함께 생성을 하게 되면 다음과 같이 계속해서 중복된 태그로 생성이 되어버립니다. 이 문제를 해결하기 위해 어떤 방법들이 있을지 고민해보고 적용을 통해 해결해보겠습니다.먼저 ..
10개월이 흘렀다. 많은 것을 배우고 너무 감사한 시간이었다.우테코 전의 삶우테코에 합류하기 전 내 모습을 돌아보면, 개발 경험은 있지만 경쟁력은 없었다. 여러 시행착오를 통해 드디어(?) 개발에 대해서 재미를 느꼈던 시기였다.하지만 단순히 기능 구현에만 초점을 맞추고 깊은 고민을 하지 않았다. 또 기술 논의에 대해 자신감이 없었고 많이 회피했던 것 같기도 하다.우테코동안의 삶우테코에 합격하고 나서 다양한 사람들과 함께 의견을 나누고 고민했다. 우테코 크루들은 페어 프로그래밍 등 기술에 대해 많은 토론을 한다. (초반에는 너무 부담스러웠다ㅋㅋ)여러 번의 미션과 코드 리뷰를 통해 정말 필요한가? 이 기술은 무엇을 위한 기술일까? 내가 작성한 코드는 잘 읽히는가? 변경에 유연한 코드는 무엇인가? 등을 고민할..
마지막 미션 요구사항 중 @DynamicUpdate라는 어노테이션을 설정하는 요구사항이 주어졌다.@DynamicUpdate변경이 일어난 컬럼에 대해서만 update 쿼리를 발생하는 어노테이션이다.우리 도메인 중 하나인 템플릿에는 반정규화를 통해 좋아요 컬럼을 가지고 있다. 좋아요 요청이 오게 될 경우 더티 체킹을 통해 좋아요 컬럼을 업데이트 하는데, 만약 @DynamicUpdate가 없다면 전체 필드에 대해 업데이트 컬럼을 날리게 된다. 하지만 @DynamicUpdate를 추가하게 된다면 변경이 발생한 컬럼에 대해서만 업데이트 쿼리가 발생하여 다음과 같이 쿼리가 나간다. 그렇다면 불필요한 컬럼에 대해 업데이트를 하지 않으면 좋을 것 같다고 생각이 드는데, 과연 어떨까?성능 측면에서 고민할 것스프링의 아버..
쿠폰 미션에서 성능을 위해 캐시를 사용하라는 요구사항을 받았다.캐시를 사용할 때 적용할 수 있는 전략에 대해 알아보고자 작성한다. 읽기 전략Look Aside (Lazy Loading) 전략조회 시 캐시를 먼저 확인하고 없다면 DB에서 조회한다.그 후 조회된 데이터를 캐시에 저장하는 전략이다.public Product getProduct(Long id) { // 1. 캐시 먼저 확인 Coupon coupon = cacheRepository.get(id); if (coupon != null) { return coupon; } // 2. 캐시에 없으면 DB에서 조회 coupon = dbRepository.findById(id); // 3. DB..
Coupon 미션 중 Read, Write DB가 분리된 분산 데이터베이스 환경에서 DataSource를 연결을 했어야 했다.그 과정에서 DataSource 빈 주입을 할 때, LazyConnectionDataSourceProxy라는 객체에 대해 알게 되었는데 해당 객체가 무엇이고, 왜 프록시 객체를 빈 등록해주어야 하는지 알아보고자 글을 작성하게 되었다. @Primary@DependsOn({"routingDataSource"})@Beanpublic DataSource dataSource(DataSource routingDataSource) { return new LazyConnectionDataSourceProxy(routingDataSource);}LazyConnectionDataSourcePr..
인스턴스 한 대 기준으로 핵심기능에 목표 TPS를 정한다. 그리고 안정적으로 서비스될 수있게 아래 값을 설정하고 이유를 공유해야한다. 위 프로젝트 요구사항을 받고 현재 어플리케이션의 TPS가 어떻게 되는지 측정해야했다. 스프링 부트를 통해 프로젝트를 진행하고 기존에 그라파나와 프로메테우스로 이미 메트릭 모니터링 시스템을 구축해놨었기 때문에이를 재활용해서 부하 테스트를 진행하기 전에 TPS를 확인하고자 했다. 관련 메트릭 설정 그라파나에서 TPS를 측정하려면 spring boot actuator 기준 http.server.requests 수집이 활성되어 있어야 한다./actuator/metrics 에 접속하여 활성화되어 있는지 확인하자. 그 중에서도 사용할 매트릭은 http_server_requests_s..
Connection Pool이 없을 때의 문제웹 개발을 하다보면 보통 애플리케이션에서 DB를 사용한다. 하지만 매번 DB가 필요한 요청마다 매번 위의 과정을 거쳐 DB에 연결을 하게 되면 비용이 상당히 많이 든다. DB 연결을 생성하는 과정에서 네트워크 연결, 인증 등의 과정이 필요하다.각 연결은 메모리와 네트워크 리소스를 사용하기 때문에 많은 연결을 만들면 서버 리소스가 빠르게 소모된다.데이터베이스 서버도 각 연결을 관리해야 해서 부하가 증가할 수 있다.연결 생성에 시간이 소요되어 전체 응답 시간이 늘어나고 애플리케이션 성능이 저하된다.DB와의 연결을 위해 생성한 java.sql.Connection 등 연결 객체의 GC 처리가 필요한데, GC 작업이 빈번할 수록 성능 저하가 발생할 가능성이 있다.Con..
