테스트 더블 정리 (Dummy, Fake, Stub, Spy, Mock)
·
dev/Spring
TL;DR테스트 더블(Test Double)은 특정한 프레임워크나 도구에 종속된 기술이 아니라,"외부 의존성으로 인해 테스트가 어려운 상황을 해결하기 위해 진짜 객체 대신 사용하는 모든 대체재" 다.Java에서 테스트코드 작성시 Mockito를 주로 사용하는데, 대부분의 테스트 더블을 mock() 기반으로 표현할 수 있다.문제는 같은 mock() 객체라도 어떤 테스트는 반환값 제어에 집중하고,어떤 테스트는 호출 여부 검증에 집중하며, 어떤 테스트는 둘 다 사용한다는 점이다.하지만 코드만 봐서는 그 mock 객체가 어떤 의도의 테스트 더블인지 드러나지 않는 경우가 많다.들어가며회원 도메인을 개발하면서 UserService 단위 테스트 코드를 작성하던 중 UserRepository를 mock()으로 만들어 ..
Resilience4j CircuitBreaker 슬라이딩 윈도우 동작 원리(COUNT_BASED vs TIME_BASED)
·
dev/Spring
서킷브레이커를 도입하고 나서 슬라이딩 윈도우 타입에 대한 설정값들이 헷갈렸다.COUNT_BASED의 경우 사실 직관적이지만 TIME_BASED의 경우 딱 와닿지 않는 것 같다.Resilience4j를 기준으로 두 가지 윈도우 타입의 내부 동작 원리를 자세히 살펴보고, 어떤 상황에서 무엇을 골라야 하는지 정리해보려고 한다.슬라이딩 윈도우란?서킷브레이커는 세 가지 상태를 가진다.CLOSED: 정상 상태 (모든 요청이 통과한다.)OPEN: 차단 상태 (요청을 즉시 실패시킨다.)HALF_OPEN: 시험 상태 (일부 요청만 허용해서 회복 여부를 판단한다.)이때 CLOSED 상태에서 OPEN으로 전환할지를 결정하는 핵심 매커니즘이 바로 슬라이딩 윈도우다.윈도우는 두 가지 일을 한다.기록: 매 호출의 결과(성공/실패..
Ceph 장애가 발생했을 때, 왜 BE가 느려졌을까?
·
dev/Ceph
Ceph 클러스터 장애가 발생했을 때,BE가 계속 retry를 하면서 오히려 응답이 더 느려지고 있었습니다. 배경현재 Ceph API를 활용해서 Ceph 데이터를 서빙하는 백엔드를 개발하고 있습니다.FE → G/W → BE → Ceph MGR API (Active-Standby 구조)서비스 흐름 자체는 단순한데, Ceph의 Active-Standby 구조 때문에303 Redirect, Fallback, Retry, Active MGR 갱신 같은 걸 전부 BE에서 직접 처리하고 있었습니다.평소에는 별 문제 없이 돌아갔는데, Ceph 장애 상황에서는 다음과 같은 문제가 발생했습니다.평균 응답 시간이 1.15초까지 증가redirect → retry → host 순회 → 재귀 호출 구조장애 원인 파악이 어려움(..
[Ceph] Custom Container 배포를 해보자! (+Prometheus 연동)
·
dev/Ceph
RBD 이미지 -> PG -> OSD 매핑Ceph 클러스터를 운영하다 보면 장애 분석이나 성능·용량 이슈가 생겼을 때,“지금 보고 있는 RBD 이미지가 실제로 어떤 PG에 올라가 있고, 그 PG가 어떤 OSD 들에 퍼져 있는지”를 알고 싶은 순간이 생겼습니다. 예를 들어,1. 특정 OSD 장애가 발생했을 때, 그 OSD에 어떤 이미지가 얼마나 몰려 있는지 보고 싶거나2. 리밸런싱 이후 데이터가 의도대로 고르게 분산됐는지 확인하고 싶은경우 "Ceph 내부에서는 객체 이름과 풀 ID로 해시해서 PG를 계산하고 이 PG를 다시 CRUSH로 여러 OSD에 배치를 하게 됩니다."그래서 저는 go-cpeh(librados를 go 언어로 래핑한 오픈소스)를 사용하여 RBD 이미지 -> PG -> OSD 매핑 API ..
실행 파일을 생성하는 링커
·
dev/CS
2024.07.27 - [CS] - 소스코드파일부터 실행파일까지 컴파일러 과정 알아보기 소스코드파일부터 실행파일까지 컴파일러 과정 알아보기여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니jhost.tistory.com대상 파일(object file) 생성 과정에 대해서 궁금하신 분은 이전에 작성한 글을 참고해 주시면 됩니다. 링커여러분들이 특정 프로그램을 실행할때 해당 프로그램을 실행하기 위한 실행 파일은 하나죠?(물론 그 하나의 실행 파일을 실행 시키기 위해 부가적인 파일이 필요하기도 합니다.) 이전 글에서 말씀드린 컴파일러를 통해서 대상 파일(object file)이 생성된다..
소스 코드 파일부터 실행 파일까지 컴파일러 과정 알아보기
·
dev/CS
여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니다. 인간이 인식할 수 있는 단어로 코드를 작성하는 것 == 소스 파일 (source file)이 소스 파일을 컴파일러에게 전달하면 실행 파일 형태가 됩니다.소스 코드 -> 컴파일러 -> 실행파일컴파일러?특정 프로그래밍 언어로 쓰여있는 문서를 다른 프로그래밍 언어로 옮기는 언어 번역 프로그램입니다. (번역기)컴파일러는 고급 프로그래밍 언어를 저급 프로그래밍(CPU가 인식할 수 있는) 언어로 바꿔주는 역할을 하며, 컴파일된 이후의 코드를 목적코드(object code)라고 합니다. 왜 컴파일러를 사용할까?간단한 코드 예시int a =..
[Java] AtomicLong으로 동시성 문제 해결 (feat.비관적 락을 사용 하지 못한 이유)
·
dev/Java
콘서트 예매 사이드 프로젝트를 진행하면서 대기열 관련해서 개발을 진행하면서 비관적 락을 사용해서 대기열 동시성을 풀어 나가려고 했습니다. 요구사항 중 멀티 스레드 환경에서 여러 번의 요청이 들어와도 내가 정한 대기열의 인원수(QUEUE_LIMIT)만 ONGOING 상태로 저장되어야 하며, 대기열 등록 시 ONGOING 상태가 QUEUE_LIMIT 보다 크거나 같은 경우 WAIT 상태로 추가되어야 합니다. (REDIS를 사용하지 않고 대기열 문제를 풀어보고 싶어서 RDB를 사용) 대기열 등록 서비스 호출시 DB에서 ONGOING상태인 유저의 COUNT(*)를 가져와서 위에 요구사항 대로 진행하도록 구현을 하였습니다. 대기열 도메인 구현을 마친 후 마지막으로 동시성 테스트 코드를 작성하여 테스트를 돌려봤지만..
[JPA]프록시를 사용하는 이유(즉시로딩, 지연로딩)
·
dev/JPA
위와 같이 Member에 Team이 들어있는 경우, Member를 조회할 때 Team도 조회해야 할까? -> Member와 Team을 같이 사용하는 경우엔 괜찮지만, Member만 필요한 경우엔 Team까지 호출이 되면 리소스 낭비이다. (즉시로딩, 지연로딩의 차이점) 프록시 Hibernate가 내부에서 만든 가짜 엔티티 객체 em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getRefetence() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 em.getReference()를 호출하는 시점에는 데이터베이스에 query를 호출하지 않는다. 프록시 객체 초기화 1. em.getReference()를 호출해서 Proxy객체를 생성 2. target에 값이 없으면 영속..
[JPA] Mapped Superclass - 매핑 정보 상속
·
dev/JPA
@MappedSuperclass 공통 매핑 정보가 필요할 때 사용한다. 공통 속성이 필요할 경우 하나의 객체로 관리할 수 있다. 예시로 모든 테이블에 등록자, 등록일, 수정자, 수정일이 필요한 경우 공통으로 사용할 클래스를 만들어서 @MappedSuperclass를 사용하고, 적용할 엔티티에서 상속받아 사용한다. - 상속관계 매핑 X - 엔티티 X, 테이블과 매핑 X - 부모 클래스를 상속 받는 자식 클래스에만 매핑 정보를 제공 - 조회, 검색 불가(em.find(BaseEntity) 불가) - 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장 테이블과 관계 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할을 한다. 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로..
[JPA]상속관계 매핑
·
dev/JPA
상속관계 매핑 객체는 상속관계가 존재하지만, 관계형 데이터베이스는 상속 관계가 없다. 하지만! 슈퍼타입 서브타입 관계라는 모델링 기법이 있으며, 이 기법은 객체 상속과 유사하다. 상속관계 매핑? 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑 슈퍼타입, 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법은 3가지 전략이 있다. 1. 조인 전략 2. 단일 테이블 전략 3. 구현 클래스마다 테이블 전략 오늘 예시로 사용할 (좌) 논리모델, (우) 물리모델 엔티티 @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) @DiscriminatorColumn public class Item { @Id @GeneratedValue private L..