Search

 Posting

Gallery
Search
목차

배경

최근에 학습 중인 ‘가상 면접 사례로 배우는 대규모 시스템 설계 기초’ 도서에서는 매 챕터, 매 계층마다 ‘다중화’를 강조합니다. 이는 대규모 시스템 구조에서 장애에 가장 취약한 SPOF(Single Point of Failure)를 방지하기 위함인데요, 하나의 서버에서 장애가 발생할 경우 모든 서비스에 장애가 발생하는 것을 막기 위함입니다. 또한 하나의 서버에서 모든 요청을 처리하게 되므로 트래픽이 몰릴 경우 병목 현상이 생겨 성능을 제대로 발휘할 수 없다는 문제점도 있습니다. 이러한 문제를 해결하기 위해 DB 계층의 다중화는 항상 언급되는 부분이었고, 저희 모락 서비스에서도 미처 대응하지 못한 지점이었기때문에 데이터베이스 다중화를 학습해보고 그 중에서도 레플리케이션에 대해 적용해 보기로 하였습니다.

DB 다중화

MySQL 에서 서버를 다중화하는 방법은 크게 Clustering 과 Replication 이 있습니다.

Clustering

MySQL 에서 지원하는 클러스터링은 Shared-Nothing Architecture 구조를 가지며 각각의 서버가 모두 독립적으로 운영되고 수평적인 계층을 가집니다.
이에 따라 하나의 서버에서 장애 시에 대응이 쉽고 병목 현상이 발생할 우려가 적다는 장점이 있습니다. 하지만 독립적으로 구성된 여러 서버에서 데이터가 변경될 시 모든 서버에서 데이터가 동기화 되어야 합니다. 이로 인해 여러 노드들 간의 데이터를 동기화하는 시간이 필요하여 쓰기 성능이 비교적 좋지 않고 장애가 전파된 경우 처리가 까다로울 수 있다는 한계가 있습니다.

Replication

복제는 한 서버의 데이터를 복제하여 다른 서버로 동기화하는 것을 의미하는데요, 클러스터링과 다른 점은 수직적인 계층을 가집니다.
원본 데이터가 저장되어 있는 서버를 source 서버, 복제된 데이터가 저장되어 있는 서버를 replica 서버라고 합니다. 이에 따라 복제되는 방향도 source 서버에서 replica 서버로 단방향으로 흐르게 되어 동기화가 클러스터링보다 빠르고, 정합성 관리도 상대적으로 편하다고 할 수 있습니다.
과거에는 Master-Slave 로 불렸지만 사회적 통념상 slave 라는 단어 사용을 억제하기 위해 Source-Replica 또는 Primary-Secondary 를 사용하는 추세입니다. 이에 따라 해당 포스트 및 레플리케이션 코드에서는 Source-Replica 라는 단어를 사용합니다.
DB 다중화와 Replication(MySQL편)
2023/05/08
MySQL
infra
Structure

목차

배경

현재 저희 서비스에서 투표/약속잡기 등을 생성하면 슬랙으로 알림을 보내주는 로직이 있습니다. 이러한 알림 로직을 위해 투표/약속잡기 서비스 계층에서는 알림 서비스 계층을 의존하고, 생성 시 알림을 보내는 로직까지 포함되어 있습니다. 즉 투표/약속잡기 생성, 슬랙 알림이 하나의 비즈니스 로직 내에 있는 것이죠. 이는 바꿔말하면 의존도가 높다고 할 수 있습니다. 현재의 로직에서 발생할 수 있는 문제점과 해결 방법으로 사용한 스프링 이벤트 방식의 동작 원리를 알아보겠습니다.

문제점

현재 투표의 생성 로직을 단순화하면 다음과 같습니다.
투표 생성 save(poll)과 알림notifyPollOpen(teamCode)이 하나의 로직으로 묶여있는데요, 이렇게 다른 컨텍스트가 서로 의존되어 있는 상황을 강하게 결합되어 있다고 할 수 있고 결합도가 높은 위의 로직은 크게 세 가지의 문제점을 가집니다.
1.
유지, 보수에 어려움
2.
얽혀있는 트랜잭션
3.
불필요한 대기

생각해본 대안

스프링 배치

•
장점
•
단점
스프링 이벤트와 동작원리
2023/04/30
Spring
Event
Transaction
Refactoring
목차

배경

서비스를 개발하고 고도화가 진행되면 필연적으로 동시성 문제를 마주하게 되는데, 저희 모락도 예외는 아니었습니다. 기본적으로 웹 환경에서는 같은 시간에 여러 개의 요청이 들어올 수 있고, 스프링같은 멀티쓰레드 환경에서는 여러 쓰레드가 한 자원을 공유할 수 있어, 동시성 문제가 심할 때는 데드락이 발생할 수 있습니다. 저희 모락에서는 쿼리 성능을 위해 반정규화를 하여 업데이트를 하는 쿼리가 생겼고, 여러 쓰레드에서 한 레코드에 대해 공유락을 획득한 뒤 배타락 획득을 시도하여 데드락이 발생하였습니다. 이에 이전 게시물에서는 데드락 문제를 해결하기 위해 비관적 락, 낙관적 락 등에 대한 고민과 결론적으로 비즈니스 로직을 나눠 데드락을 회피하면서 문제를 해결하였습니다. 하지만 이렇게 비즈니스 로직으로도 완전하지 않을 수 있습니다. 지난 로직은 단순 데이터를 삽입하는 로직이었지만 선착순 투표와 같이 자원에 제한이 있을 때에는 정합성 문제가 여전히 발생할 수 있습니다. 그래서 동시성 문제를 조금 다른 방법으로 접근해보려고 합니다.
분산락으로 동시성 문제 해결하기(Redis, 네임드 락)
목차

데드락이 발생한 이유

데드락 원인과 해결방안 고민(비관적 락, 낙관적 락)
목차

배경

저희 모락에서는 역할 정하기 기능 중 역할 기록 조회 API 에서 있던 한방 쿼리는 서브 쿼리가 2개가 발생하여 성능상 비효율적이었고, 이를 4개의 쿼리로 나누어 성능을 개선하였습니다. 이 4개의 쿼리 중 다른 쿼리들에 비해 유난히 오래 걸리는 쿼리가 있었는데요, 바로 조건절, 그룹화, 정렬이 모두 들어간 쿼리입니다. 기본적으로 존재하는 클러스터링 인덱스와 외래키 인덱스로는 해당 쿼리가 인덱스를 타지 않아 다른 기본 조회 쿼리에 비해 약 60배정도 소요 시간이 발생하였습니다. 이에 따라 해당 쿼리의 성능을 최대한 끌어올려보고자 최적의 인덱스를 찾아보기로 하였습니다.

테스트 환경

•
테스트 DB 환경
•
DB erd
•
더미 데이터 정보

문제점

현재 다루는 역할 기록 조회 는 매번 갱신할 수 있는 역할들을 일별 가장 늦게 갱신한 역할을 조회하는 API 입니다.
위 그림과 같이 하루에 100 번의 역할 갱신을 한다고 하더라도, 그 날 가장 늦게 갱신한 역할이 해당 날짜의 역할로 조회를 합니다. 이러한 API 에서 역할을 조회하고, 그룹화와 정렬하는 조회를 한 뒤, 최종적으로 조회된 역할 히스토리에 해당하는 역할 결과를 조회를 하는데, 문제가 된 쿼리는 다음과 같습니다.
위의 쿼리는 where + group by + order by desc 가 섞여 쿼리의 길이에 비해 다소 복잡한 쿼리입니다. 조금 더 자세히 보면 외래키로 있는 role_id 로 조건절 필터링을 하며, date_time을 date 로 변형하여 그룹화를 한 뒤 date_time 역순 즉 최신 날짜 순으로 정렬을 하고, 그룹화된 date_time 에서 가장 id 가 큰 데이터(날짜 별 가장 늦게 갱신한 역할) 를 조회합니다.
위 쿼리의 실행 속도는 더미 데이터 약 500만건을 기준으로 약 0.64초가 소요되었습니다. 서브쿼리가 섞인 한방 쿼리보다는 성능상 훨씬 좋았지만, 응답된 레코드 수에 비해서는 다소 오래 걸리는 것이 사실입니다.
인덱스 최대 활용하기 (where + group by + order by)
2023/01/22
MySQL
Spring
목차

배경

저희 프로젝트의 기능들은 그룹을 기반으로 운영됩니다. 이에 따라 요청한 팀과 멤버의 정보를 대부분의 API 에서 받고 있고 이를 검증하는 로직이 존재합니다. 대부분의 서비스 계층 메서드에서 반복되어 나타나는 해당 검증 로직의 반복을 줄이기 위해 초기에는 클래스 내의 메서드로 분리하는 방식으로 해결해 왔습니다. 하지만 기능들이 점차 추가되면서 서비스 계층이 횡적으로 확장이 되었고, 동일한 검증 로직을 새로운 서비스 계층에서 반복해야 하는 상황이 발생하였습니다. 이때부터 점점 구조 변경의 필요성을 느끼고 있었는데, 쿼리 성능 튜닝을 진행하면서 검증 로직 내 JPA 메서드를 변경하였습니다. 그러자 이 검증 로직 내 JPA 메서드를 이용하던 모든 서비스 계층에서 빨간줄이 그어졌고, 현재 구조는 유지 보수가 힘들다는 것을 깨달아 구조 변경을 결심하였습니다.

문제점

현재 구조가 가지는 문제점은 다음과 같습니다.
1.
전체 서비스 계층에서 공통 로직이 반복된다.
2.
만약 새로운 기능이 추가된다면?
•
검증에 필요한 MemberRepository, TeamRepository, TeamMemberRepository 를 기본적으로 의존하며 동일한 검증 로직을 생성해야 합니다. 또한 새로운 API 마다 검증 로직을 추가해야 하기때문에 실제 비즈니스 로직에 집중할 수 있는 여건이 다소 떨어집니다.
문제를 요약해보면 두 가지 문제를 생각해볼 수 있는데요. 첫째, 검증 로직이 바뀌면 해당 로직을 이용하는 모든 로직에서 수정을 해야 합니다. 예를 들어 사용자를 확인하는 타입이 Long 에서 UUID 와 같은 문자열로 바뀌면 해당 로직을 이용하던 모든 메서드를 찾아 일일이 수정을 해주어야 합니다. 이로 인해 유지, 보수 측면에서 어려움을 겪을 수 있습니다. 둘째, 새로운 API가 추가될 때 검증 로직도 추가해야 한다는 점입니다. 이로 인해 새로운 비즈니스 로직에 대한 집중이 떨어지고 가독성 부분에서도 비효율적이었습니다. 이러한 문제점들을 가지고 있었기때문에 가독성 측면으로나 유지, 보수, 확장의 측면으로나 개선이 필요하다고 생각했습니다.

서비스 계층 설계하기

앞서 언급드렸다시피, 모락 서비스의 모든 기능은 팀을 기반으로 제공됩니다. 이에 따라 모든 API 에는 요청한 팀에 요청한 사용자가 속하는지 확인하는 로직이 존재합니다. 이 과정을 요약하면 다음과 같습니다.
어질어질 반복 로직 제거하기 (템플릿-콜백 패턴)
2022/12/10
Spring
Aop
Refactoring

테스트 환경

테스트할 도메인은 재설계를 진행했던 투표 도메인으로 테스트를 진행하였고, 더미 데이터는 쿼리 튜닝을 했던 때와 같은 수로 넣어주었습니다.
•
멤버: 500
•
팀: 1000
•
팀 멤버: 2996
•
투표: 30000
•
투표 항목: 90000
•
선택 인원: 180000
다사다난 도메인 재설계 - 심화편
2022/12/20
Spring
MySQL
Refactoring
목차

배경

저희 모락은 스프린트 5를 시작하면서 요구 사항 이외에 함께 해야 할 일들에 대해 회의를 하였습니다. 캐싱 서버, 기능 추가 등 흥미로운 주제들이 나왔는데 그 중에서도 도메인 재설계에 대한 욕구가 가장 컸습니다. 모든 백엔드 팀원이 도메인에 대한 대공사를 원하기도 했고, 계층 구조 재설계에 대한 흥미도 컸기때문에 이번 스프린트 5에서 도메인 재설계를 대대적으로 하기로 결정하였습니다. 일정 상으로 일과 중에는 인덱스, 쓰레드 설정을 포함한 요구 사항, 일과 후와 주말에는 도메인 재설계를 진행하기로 하였습니다.

문제점

먼저 스프린트 1-4를 진행하면서 느낀 코드의 문제점에 대해 공유해 보았습니다.
•
의존 관계가 얽혀있다.
•
서비스 계층 하나에 많은 로직이 집중된 구조이다. → 하나의 객체가 너무 많은 역할을 가지고 있다.
위의 상황에서 발생할 수 있는 문제로는 상호 참조하는 구조로 관리가 어렵다는 점과 비즈니스 로직이 서비스 계층에 있어 응집도가 부족하다는 점 등 2가지가 있습니다. 이 문제를 해결하기 위해서는 단방향 의존성을 가지는 구조로 설계하고, 가장 중심이 되는 도메인에 비즈니스 로직을 넣어 응집도를 높여야 한다고 생각했습니다. 이와 같은 방식으로 리팩토링을 한다면 도메인 객체를 수정해야 하고, 순차적으로 영속화 계층, 서비스 계층도 영향을 받게 되는 커다란 공사를 진행하게 됩니다. 그리고 이 상황에서 서비스도 유지해야 했기때문에 약 4주의 기간을 잡고 도메인 재설계를 시작하였습니다.

목표

설계 및 개발하기에 앞서 우리의 목표부터 새로 다잡고 진행하는 것이 먼저였습니다.
우리가 설계하고 코드를 짤 때 컨셉을 잡고 항상 우리의 철칙과 이유를 생각하고 정리하도록 한다.
→ 모든 코드에 이유와 손때가 묻어나는 것이 첫번째 목표였습니다. 프로젝트 초기에는 시간 내에 서비스를 완성시켜야 했기때문에 코드를 부랴부랴 짰고, 이후 짠 코드를 다시 보면 ‘우리가 레벨 1, 2때 뭐 배웠더라’ 라는 생각을 많이 하게 되었습니다. 물론 프로젝트의 상황과 환경에 맞게 코드 퀄리티는 잠시 제쳐두고 서비스를 시간 내에 개발하는게 그 당시의 목표였습니다. 이에 따라 우리가 만든 레거시는 우리가 치우자! 라는 마인드로 레벨 1, 2기간 배운 클린 코드, 자바의 특수성 등을 활용하여 의미있고 깔끔한 코드를 작성하고자 하였습니다.
도메인 구조 우아하게 설계하기
2022/11/29
Refactoring
Spring
Structure
JPA
로드 밸런싱 with upstream
목차

배경

모락 서비스를 배포한 이후, 사용자의 피드백과 추가 기능들을 함께 반영하며 운영 서버로 자주 배포하게 되었습니다. 이 과정에서 기존 버전의 운영 서버를 종료시키고, 새로운 버전의 운영 서버를 실행시키며 약 20초 정도의 다운타임이 발생하게 되었습니다. 이 20초 간의 다운타임도 문제였지만, 개발 서버에서 미처 알아차리지 못한 에러가 발생할 때도 문제가 있었습니다. 저희 프로젝트에서 배포하는 방식은 기존 버전의 jar 파일을 새로운 버전의 jar 파일로 오버라이드하고 새로운 버전의 jar 파일을 실행하는 방식이었습니다. 이러한 방식으로 인해 새로운 버전에서 에러가 발생한다면 이전 버전의 jar 파일이 없어, 롤백하기 위해서는 이전 버전의 jar 파일로 다시 오버라이드하여 서버를 실행해야 했습니다. 이와 같은 이유로 한번 에러가 발생하면 다운타임이 길어져서비스 운영에 치명적으로 다가오게 됩니다. 이에 따라 안정적인 서비스 운영을 위해 다운타임을 최소화시키고, 빠르게 롤백할 수 있는 무중단 배포 방식 을 적용하고자 하였습니다. 또한 서버가 예기치 못하게 종료되었을 때를 대비하고 트래픽 분산을 위해 로드 밸런싱 환경도 함께 적용해 보겠습니다.

무중단 배포 전략

무중단 배포 with jenkins

배경

저희는 프로젝트 초기부터 테스트 속도를 높이기 위해 신경을 썼습니다. 대표적으로 테스트 데이터를 격리하기 위해 @DirtiesContext 를 사용하지 않고, sql script 를 이용하였습니다. 또한 서비스 계층에서 불필요한 @SpringBootTest 대신 @DataJpaTest 와 @Import 만으로 서비스 계층 테스트를 수행할 수 있도록 하였습니다.
하지만 프로젝트가 점점 커지고 테스트 케이스 수가 400개를 넘어가면서, 테스트를 수행하는 데에 걸리는 시간이 점점 오래 걸리게 되었습니다. 소요되는 시간이 점진적으로 늘어났기때문에 인지하기 힘들었는데, 한번은 테스트를 돌리고 화장실을 다녀왔는데도 전체 테스트가 계속 수행중이었던 것을 보고 ‘이거 너무 오래 걸리는데’를 깨닫게 되었습니다..
현재 기준으로 찍히는 시간은 51초 정도 되지만 실제 추산되지 않은 시간까지 합하면 체감 시간은 2분 정도 걸리는 것 같습니다. 팀원들도 동일한 문제를 인식하고 있었기때문에 테스트 속도를 개선하기로 결정했습니다.

원인 파악

먼저 어디서 오래 걸리는지 파악하는 것이 중요했습니다. 저희 테스트는 크게 총 5가지 인수 테스트, 컨트롤러 테스트, 서비스 테스트, 레포지토리 테스트, 도메인 단위 테스트로 구분할 수 있습니다. 도메인 단위 테스트는 단순히 컴파일만 되면 수행할 수 있지만 나머지 4가지의 테스트는 컨텍스트 빈을 띄워야 합니다. 이 중 인수 테스트 는 @SpringBootTest를 사용하고, 컨트롤러 테스트는 @WebMvcTest, 서비스 테스트와 레포지토리 테스트는 @DataJpaTest 를 사용하여 컨텍스트 빈들을 띄웁니다. 그리고 이 컨텍스트 빈을 띄우는 과정에서 시간이 소요될 것이라고 판단하였습니다. 실제로 테스트가 수행되는 창을 보고 있으면 도메인 단위 테스트 부분은 ‘진짜 테스트를 한건가’ 싶을 정도로 순식간에 지나가지만, 나머지 테스트들은 ‘아 지금 이 테스트를 수행하는 중이구나’ 라는 생각이 들 정도로 버퍼링이 있었습니다.

Application Context Caching

테스트 환경 개선기
2022/10/23
Spring
test
목차

배경

저희는 프로젝트의 비즈니스 로직 개발에 몰두하면서 테스트에 다소 소홀했지만 크게 문제로 인식하지는 않았습니다. 그러다가 개발 서버에 배포한 비즈니스 로직 중 미처 테스트 코드를 작성하지 못한 부분에서 예외가 발생하는 상황을 마주했습니다. 그래서 팀 내부 회의를 거쳐, 테스트에 관심을 가지고 테스트 케이스를 늘리기로 결정했습니다. 하지만 테스트 케이스를 늘려도 기존에 있던 로직들을 모두 커버하지 못해 유사한 예외가 발생하거나, 새로운 로직에 대해 테스트 커버를 했는지 확신할 수 없는 상황이었습니다.
이에 테스트 코드 커버리지를 정량적으로 측정하고 문서화를 할 수 있는 툴을 도입하기로 결정하였습니다.

JaCoCo 채택 이유

JaCoCo 적용 이전까지는 인텔리제이의 Run with Coverage 기능을 사용하였습니다. 해당 기능은 쉽게 접근이 가능하다는 장점이 있었지만, 문서화가 어렵고 측정 기준을 세부화하기 힘들어 JaCoCo 도입을 결정하였습니다.
JaCoCo 를 채택한 이유는 다음과 같습니다.
1.
문서화가 쉽다.
2.
더 자세하다.
3.
테스트 커버를 강제할 수 있다.

기본 설정

앞으로 기술될 gradle 은 Groovy DSL 을 기반으로 합니다. 기본적인 설정은 다음과 같습니다.
코드 커버리지 툴 적용기(feat. JaCoCo)
2022/10/13
test
infra

배경

저희 프로젝트의 서비스 로직 개발과 배포가 어느정도 마무리 되었습니다. 열심히 테이블을 설계하고 코드를 작성했지만, 쿼리의 성능과 인덱스에 대한 정리는 하나도 되어 있지 않은 상태였습니다. 무엇보다 어떤 쿼리가 성능이 잘 나오고, 어떤 쿼리가 성능이 잘 나오지 않는지에 대한 정보가 없었습니다. 마침 스프린트 5의 요구 사항 중 쿼리를 확인하고 공유하는 것이었기때문에 쿼리에 대한 실태를 조사하고 개선하고자 하였습니다.

도메인 정보

간단하게 저희 프로젝트 도메인의 ERD 그림을 그려보았습니다.
실제 컬럼은 더 많지만 쿼리에서 주로 사용되는 컬럼만 넣었습니다. 저희 서비스는 ‘그룹’ 을 기반으로 하다보니, 멤버와 팀이 대부분의 도메인에 연관 관계 설정이 되어 있는 것을 알 수 있습니다. 투표 도메인은 1:N:N^2 의 형태(투표:투표 항목:투표 결과)로 테이블을 설계하였고, 약속잡기 도메인은 1:N 의 형태로 설계된 상태입니다.

더미 데이터 정보

기존 테스트에 사용하던 데이터 수로는 쿼리 상태가 아무리 나빠도 눈에 잘 띄지 않기때문에, 어느정도의 부하를 위해 더미 데이터를 삽입하였습니다.
•
멤버: 500
•
팀: 1000
•
팀 멤버: 2996
•
투표: 30000
쿼리 튜닝 여행
2022/10/02
Spring
JPA
MySQL
프로젝트를 진행하면서 초기에는 슬랙을 이용하여 서버의 에러 로그를 받았습니다. 그리고 에러가 발생하면 슬랙으로 우선 어떤 에러인지 확인을 한 뒤, 해당 서버에 접속하여 쌓인 로그를 확인하고 에러를 픽스하는 과정을 거쳤습니다. 하지만 슬랙으로 로그를 받는 구조는 에러에 대한 추이를 확인할 수 없었습니다. 그리고 실제 로그를 확인하고 이상 현상을 파악하기 위해 서버에 직접 접속해야 했지만 이는 인바운드 규칙때문에 규칙이 적용되지 않은 IP 로는 접속이 불가능했습니다. 그래서 집에서는 해당 서버로 들어갈 수가 없어 캠퍼스를 나오면 에러가 터지지 않기를 기도해야 했습니다. 이와 같은 문제점을 해결하고자 로그 모니터링 환경을 구축하였습니다.
•
앱 서버로부터 쌓은 로그를 Loki 로 전송해줍니다. 이에 따라 WAS 서버에서 구동되어 해당 서버의 로그를 Loki 서버로 전송할 수 있습니다.
•
로그를 저장하고 시계열 자료로 집계해주는 오픈 소스 툴입니다. Promtail 로부터 로그를 받고 데이터 형태에 맞게 처리합니다.
전체적인 구조는 다음과 같습니다.
먼저 앱 서버에서 로그를 생산하면 Promtail 에서 Loki 서버로 로그를 전달합니다.
로그 모니터링 환경 구축
2022/09/27
infra
linux
목차

도입 배경

지난 스프린트 때 서버가 다운됐는데 원인 파악이 바로 되지 않았습니다. 어떤 상태였는지도 잘 몰랐기때문에 우선 인스턴스를 중지시키고 재실행한 뒤 다행히 서버를 띄울 수 있었습니다. 앞으로 또 이런 일이 발생하지 않을 것이라는 확신할 수 없습니다. 이에 따라 소잃고 외양간 고치는 심정으로, 이러한 현상을 방지하고 서버의 상태를 지속적으로 확인하기 위해 모니터링 툴을 도입하기로 하였습니다.

모니터링 시스템 목적

안정적인 서비스를 위해서는 모니터링 시스템이 필수입니다. 모니터링 환경을 구축하면 서비스 기능이 정상적으로 작동하는지, 서버가 다운되지 않았는지 등을 모니터링하고 장애가 발생하면 이에 대해 인지하고 대처할 수 있습니다. 모니터링하는 대상은 여러 가지가 있을 수 있는데, 저희 모락 프로젝트에서는 서버의 상태와 성능을 모니터링하고, 앱 서버의 로그에 대한 모니터링 등 두 대상에 대해 모니터링을 진행하고자 합니다.

상태 모니터링

해당 서버의 상태가 어떤지 확인할 수 있습니다. 서버 상태에는 CPU, 메모리 이용률 또는 앱 서버의 DB 커넥션 상태, 생성되어있는 쓰레드 수, 요청 API 빈도 등이 있고 이와 같은 서버 상태의 메트릭을 확인하고 분석할 수 있습니다.
•
이벤트 모니터링 및 경고에 사용되는 오픈 소스 툴입니다. 유연한 쿼리를 제공하고, HTTP 풀 모델을 사용하여 구축된 시계열 데이터베이스에 실시간(기본 15초)으로 메트릭을 기록하고 시각화가 가능합니다.
상태 모니터링 환경 구축
2022/09/24
Spring
infra
linux

배경

저희 모락 프로젝트의 서비스 로직 개발 중, equals 로 비교해야 할 로직이 필요했습니다. 조금 더 구체적으로는 투표를 생성한 호스트와, 수정/삭제를 요청한 멤버가 같은지 확인하는 로직이었습니다. 그래서 findById 로 객체를 불러서 비교를 하려고 하는데 원하는대로 결과가 나오지 않고 계속 일치하지 않는다는 응답을 받았습니다. 그래서 equals 내부에 디버그를 찍어보니 이상하게 계속 인자로 받은 객체가 프록시 객체로 저장되어 있었습니다.
JPA 는 프록시 객체를 영속성 컨텍스트에 저장하고 이를 다양한 부분에서 활용합니다. 이 덕분에 DB 커넥션을 할 때 발생하는 성능 저하를 줄이고, 이 기능이 JPA 의 가장 강력한 기능 중 하나입니다. 하지만 조회 시 영속성 컨텍스트에 조회를 원하는 객체가 없으면 반드시 DB 를 찔러 해당 객체를 가지고 와야 하고, 저희가 만든 로직에서는 해당 객체가 영속성 컨텍스트에 없다고 판단하였습니다. 이와 더불어 해당 객체를 조회하는 SQL 구문이 로그에 찍혔음에도 불구하고 계속 프록시 객체로 남아있었고, 이 과정에서 equals 내부 객체 비교 로직에서 false 로 반환되는 것이었습니다.
도대체 문제가 뭔지, 디버그를 찍어도 해결이 안되었고 코치분들께 도움을 요청하여 다행히 해당 문제를 해결할 수 있었습니다. 이 과정에서 알게된 내용과 해결 방법에 대해 공유하고자 합니다.

기본 세팅

저희는 투표와 멤버 도메인 사이에서 발생한 문제였는데, 해당 문제는 1:N 연관관계에서 발생하는 문제이기 때문에 조금 더 보편적인 예시를 들고자 합니다. 투표를 멤버로 바꾸고, 멤버를 팀으로 바꾸어 테스트를 진행하려고 합니다. 즉 멤버:투표=1:N 의 관계를 팀:멤버=1:N 으로 바꾼 예시입니다.
비교를 위해 equals 를 재정의하였습니다.
저희가 발생했던 환경과 동일하게 하기 위해 1:N @ManyToOne 연관 관계를 설정하였습니다.
프록시 객체가 실제 값을 가지는 시점
2022/08/18
Spring
JPA

배경

프로젝트를 진행하면서 DB 관련 테스트를 DataJpaTest 어노테이션을 사용하여 작성하였습니다. 그저 단순한 이유로 레포지토리 테스트에서 SpringBootTest 로 모든 빈을 띄울 필요가 없다는 것이 이유였습니다. 그러다 제이슨의 JPA Hands-on 첫 번째 강의를 끝내고 점심을 먹고 나서 서성거리고 있는데 엘리가 테스트에서 에러가 난다고 해서 구경하러 갔습니다. 대충 에러 내용은 h2 관련이었는데 코드가 제가 작성한 코드랑 다를 것이 없었는데 에러가 발생하였습니다. 아무래도 기본 설정 값에 이유가 있다고 생각하고, @DataJpaTest 를 탐색해보기로 하였습니다.
@DataJpaTest 에는 많은 어노테이션이 있는데 이번 글에서는 그 중 @AutoConfigureTestDatabase 어노테이션을 탐색하고 나온 결과를 분석해보려 합니다.

AutoConfigureTestDatabase

AutoConfigureTestDatabase 어노테이션은 테스트 DB 관련 설정 어노테이션입니다.
1. PropertyMapping
yaml 파일이나 properties 파일 등과 같은 설정 파일의 placeholder 를 가져옵니다. 해당 PropertyMapping은 설정 파일의 spring.test.database 의 값을 가져오는데, 기본은 replace.any 입니다(아래 값).
2. Replace
내장된 DB 를 사용할 것인지 아닌지를 선택할 수 있는 옵션입니다. 기본값은 ANY 입니다(대충 내장 DB 사용한다는 뜻).
3. EmbeddedDatabaseConnection
h2 가 test DB 로 선정되는 이유 in DataJpaTest
2022/07/20
test
JPA

배경

미션 진행 중, 요청한 사용자에 대한 인증을 위해 token 방식을 사용하였습니다. 그런데 jwt token 을 파싱하고 유효성 검증을 하려고 하니, Interceptor 에서도 하고 ArgumentResolver 에서도 하게 되었습니다.

문제점

Interceptor - ArgumentResolver 로 전달되는 인자는 Request(ServletRequest, WebRequest) 이고 해당 객체에서 꺼낼 수 있는 정보는 getHeader() 로 꺼낼 수 있는 스트링입니다. 이에 따라 Interceptor 에서 파싱과 유효성 검증을 하는데, ArgumentResolver 에서 요청된 파라미터로 변환하기 위해 파싱을 또 하게 되는 중복 로직이 발생하는 것이었습니다. 그렇다고 ArgumentResolver 에서만 파싱, 유효성 검증, 요청 파라미터 변환을 모두 맡기기에는 책임지는 로직이 많아져, 이 책임들을 분리할 수 있는 방법을 생각해 보았습니다.

Interceptor

Handler 처리 전과 후에 요청에 대한 공통적인 로직을 실행할 수 있는 AOP 성격을 지닙니다.

Argument Resolver

컨트롤러의 메소드의 인자로 사용자가 임의의 값을 전달하는 방법을 제공하고자 할 때 사용합니다.
따라서 파싱과 유효성 검증은 Interceptor 에서 하고, 검증을 통과하고 받은 payload 는 ArgumentResolver 로 전달한 뒤 파라미터로 변환하는 로직을 구상하였습니다.
Request Scope 로 빈의 생애 주기 관리
2022/06/08
Spring