gotogg

[학습포인트] RDS 때려치고 EC2로 DB 굴린 후기

cheolhyeon — Thu, 6 Nov 2025 17:06:10 +0900

요즘 회사 다니면서 정작 손 가는 기술적인 실험을 못 하니까, 사이드 프로젝트에서라도 갈증을 풀어보자고 파고들었다. RDS로 DB만 띄워놨는데, 테이블도 거의 없는데도 슬금슬금 3만 원씩 나가더라. 데이터도 거의 없는데 이건 아니다 싶어서, “그럼 EC2에 DB 직접 올려서 굴려보자”로 방향을 틀었다. 예전에 대충 퍼블릭 열어두고 쓰다 봇들 스캔에 긁히는 걸 본 뒤로는, 이번엔 보안부터 단단히.

간략한 흐름은 아래와 같다

DB는 절대 퍼블릭 금지.
Elastic IP도 안 달고, VPC 안에서만 살게 한다. 비용도 깎이고, 공격면도 줄어든다.
BE → DB는 오직 Private IP.
같은 VPC/서브넷에서만 붙인다. application.yml에는 DB의 프라이빗 IP만 적는다.
운영툴 접속은 SSH 터널링만.
DataGrip 같은 클라이언트는 BE를 점프 서버로 삼는다. DB 3306은 안 보이게.

최소 아키텍처를 머릿속에 그려보면 아래와 같다.

[Client] ──HTTPS──▶ [EC2: BE (Public IP 有)]
                      │
                      ├─(VPC 내부, 3306)─▶ [EC2: DB (Private IP 仅)]
                      │
(운영툴) DataGrip ──SSH Tunnel(22)──▶[BE]──(Private 3306)──▶[DB]

핵심은 “바깥에서 DB로 가는 길은 없다”. 바깥→BE(22/80/443), BE→DB(3306, 프라이빗)만 존재.

보안그룹은 이렇게 딱 자른다

SG-BE

Inbound
- 22/TCP: 내 노트북 공인 IP/32 딱 하나만
- 80, 443/TCP: 0.0.0.0/0 (또는 ALB SG로 제한)
- (가능하면) 8080/TCP 외부 미개방. Nginx/ALB 뒤에 숨긴다.
Outbound
- 기본 All 허용(필요하면 축소)

SG-DB

Inbound
- 3306/TCP: Source = SG-BE (보안그룹 간 참조)
Outbound
- 기본 All 허용(패치/백업 고려. 필요 시 축소)

왜 이렇게? SG→SG 참조로 해두면 BE를 교체하거나 오토스케일해도 DB 접근 규칙이 자동으로 따라온다. 그리고 3306을 퍼블릭에 안 내놓으니 스캐닝·사전대입 봇이 접근할 구멍 자체가 없다.

애플리케이션(Spring Boot) 설정

spring:
datasource:
	url: jdbc:mysql://10.0.1.23:3306/mydb?characterEncoding=UTF-8&serverTimezone=UTC
	username: app
	password: strongPW!

DB 호스트는 프라이빗 IP. 비밀번호 같은 건 환경변수나 SSM/Secrets Manager로 뺀다. 커넥션풀(HikariCP) 최소/최대도 프로젝트 규모에 맞춰 잡아둔다.

DataGrip은 BE를 점프로 쓴다(SSH 터널)

SSH/Proxy
- Use SSH tunnel: ON
- Host: <BE 퍼블릭 IP>
- Port: 22
- User: ubuntu(Ubuntu) / ec2-user(Amazon Linux)
- Auth: 키페어 .pem, Keep alive 체크
General
- Host: <DB 프라이빗 IP> (예: 10.0.1.23)
- Port: 3306
- DB: mydb
- User/PW: app / strongPW!

그리고 SG 전제는 다시 확인:

SG-DB 인바운드 3306 ← Source = SG-BE
SG-BE 인바운드 22 ← 내 공인 IP

이런식으로 설정을 완료하면 DB서버로 연결하지 않고도 터널링을 통해 충분히 DB EC2서버에서 DDL,DML을 작성할 수있다... 후... 네트워크 지식이없으니... 이것도 몰랐다... 다른 분들에게도 도움이 되길

[트러블 슈팅] ⚠️ 게시글 검색 및 페이지네이션 슬로우 쿼리

cheolhyeon — Tue, 1 Apr 2025 20:42:04 +0900

자유 게시판 프로젝트 진행 중 검색 기능을 구현한 뒤였다. 해당 프로젝트에는 더미데이터 약 2000천만건이 들어가 있었고, 게시글 첫 페이지 조회 시에만 해도 5초 이상이 걸리며 만약 맨 마지막 페이지의 컨텐츠를 확인하기 위해서 limit 20에 offset 20000000을 주게 될 경우 타임아웃이 발생하는 에러를 마주하게 되었다....

이는 MySQL의 물리 디스크에 접근하여 데이터를 찾는데 그만큼 오래 걸린다는 것인데 이를 해결하기 위해서는 인덱스 생성이 필요해 보였다.

문제 원인 파악

원인을 파악하기 위해서 EXPLAIN 명령어로 해당 쿼리를 분석.

확인 결과 type이 ALL인 것을 확인했다. 이는 쿼리가 인덱스를 사용하지 않고 풀 테입블 스캔을 하고 있음을 의미한다.
게다가 총 1987만건의 데이터에 접근하여 데이터 추출 작업을 하는 것이다. 이는 총 데이터 2천만건의 거의 모든 데이터를 훑어보고 데이터를 추출을 하게 되므로 느려지는 것.

DB의 성능 최적화를 위해서는 최대한 데이터 접근 수를 낮추고, 쿼리가 인덱스에서 데이터를 찾게끔 해야 물리 디스크로의 접근이 낮춰지면서 디스크 I/O 작업 비용도 낮아질 것이다.

해당 쿼리는 가장 최신 게시글 20개를 불러오는 작업을 수행하는 것인데, 결과적으로 인덱스가 없는 원본 테이블에서 가장 늦게 생성된 게시글을 불러오려고하는 것인데, 성능이 안좋을 수 밖에없다. 원본 테이블은 PK를 기준으로 오름차순 정렬이기 때문에 가장 최신의 게시글을 불러온다는 건 가장 늦게 생성된 PK를 뽑아오는 작업이다.

그러니 최신 게시글을 불러오기 위해서 거의 모든 데이터 1987만건의 데이터를 훑어보고 데이터를 찾아오는 것이 논리적으로 맞다.

거기에 추가적으로 Extra 항목을 보면 Using filesort를 볼 수 있는데 이 또한 데이터를 찾고 나서 데이터를 반환하기 위해 정렬 작업을 별도의 메모리나 디스크 공간을 사용해서 정렬 작업을 수행하고 있다.

해결방안

그럼 해결책으로 생성 날짜를 기준으로 내림차순의 인덱스를 생성하면 첫 페이지 검색 시에 상위 첫 20개를 바로 꺼내와서 가져올 수 있다. type 또한 ALL이 아닌 인덱스를 사용하게 함으로써 index가 사용 될 것이고 데이터 접근도 limit 20에 맞게 20이 될 것이다.

정렬 작업 또한 별도의 메모리나 디스크 공간을 사용하지 않을 것이다.(인덱스에서 찾은 순차대로 그대로 뽑아오면 될 것이기에)

인덱스를 created_at desc로 생성 한 뒤에 explain으로 실행 계획을 살펴본 사진이다.

실제로 type이 index가 되면서 더 이상 ALL이 아니라 인덱스 스캔을 통해서 데이터를 가져오는 것을 확인할 수 있다. 성능 또한 향상 되었다 원래 기존의 첫 페이지 검색 시에는 응답속도가 5s 41ms 이였는데, 353ms로 단축된걸 확인할 수 있다. 대략 성능이 14배정도 빨라진걸 확인할 수 있다.

생성 날짜를 내림차순으로 정렬한 인덱스를 생성하여 첫 페이지 조회 시 가장 최신의 게시글을 빠른 시간 내에 접할 수 있게 되었지만 문제점이 존재한다.

인덱스 생성 후의 문제점

만약 맨 마지막 페이지의 게시글을 확인해 보지 않았다. 인덱스 생성 전에는 맨 마지막 페이지를 조회하기 위해 offset을 2천만을 넣었을 때 타임아웃이 발생해 애초에 조회 조차도 해보지 못하게 되어있었다.

인덱스 생성 후에는 어떻게 나올까??

1분 40초... 2분에 근접한 시간이 걸리게 된다. 물론 장족의 발전이라고 볼 수 있다. 애초에 타임아웃이 나오는 쿼리였기 때문이다. 하지만 이 상태의 커뮤니티 서비스를 누가 이용할 것인가....

위와 같이 발생한 이유는 explain analyze명령어로 확인할 수 있다.

확인 결과 옵티마이저가 인덱스를 통해 offset을 처리하여 필터링을 먼저 수행하고 필터링의 결과로 row id값을 반환하게 되는데, 인덱스가 반환한 row id 값으로 원본 테이블에서 데이터를 조회하는 작업이 발생하여 늦게 처리가 되는 것이다.

created_at desc 인덱스를 통해서 row id를 찾는데, 사용자가 원하는 값은 생성 날짜가 아니다. 생성 날짜를 통해 최신 게시글을 보고싶은것. 즉 게시글 데이터를 필요로 하는 것이다.

created_at을 통해 row id를 찾았고 이를 통해 원본 테이블에 접근하여 Post에 대한 컬럼을 뽑아서 반환해야 되는 것이다.

인덱스 접근 -> 필터링 -> 원본 테이블 접근 -> 데이터 조회

위의 작업에서 데이터 조회 작업은 실제 MySQL의 물리 디스크에 접촉해서 Post에 대한 컬럼을 찾기 시작하는데 여기서 디스크 I/O 비용이 발생하면서 작업 속도가 오래 걸리는 것을 확인했다.

offset이 커짐에 따라 인덱스 트리를 순회하는 것은 어쩔 수 없지만 원본 테이블로의 접근을 막아 디스크 I/O 비용을 줄이기라도 해보자 라는 마음으로 커버링 인덱스를 생성하였다.

데이터 추출에 필요한 컬럼들은 post_id, title, categoryId, created_at 이였고, 인덱스의 정렬 구조는 항상 첫 번째 컬럼을 기준으로 정렬 되고, 해당 SELECT 쿼리의 ORDER BY가 created_at을 기준으로 하기 때문에 created_at 을 첫 번째 조건으로 멀티컬럼 인덱스를 생성.

커버링 인덱스 사용으로 인해 원본 테이블에 접근하여 데이터를 조회하는 과정을 건너뜀으로써 모든 작업은 디스크 접근 없이 인덱스 메모리 상에서 처리되고 이로 인한 성능 저하가 최소화 될 것이라 판단 하였다.

인덱스 생성 전에는 offset 2천만 조건으로 조회 시에는 타임 아웃이였다, 그 후 created_at desc로 인덱스 생성 후에는 14984ms 1분 40초 정도 걸리는 시간이다.

커버링 인덱스 생성 후의 offset 2천만은?

거의 2분걸리던 작업을 3초 내외로 응답을 받을 수 있었다!!

이처럼 쿼리를 튜닝하여 적절한 인덱스를 생성하게 되면 비약적으로 성능이 개서되는 사례를 볼 수 있다. 단점도 있으니 무분별한 인덱스 생성은 좋지 못하다. 해당 테이블을 사용하는 쿼리들을 보고 최적의 인덱스를 생성하는게 바람직하다. 무분별한 인덱스 생성은 오히려 CUD 작업의 성능을 저하시킨다.

[학습 포인트] Redis SortedSet을 활용한 실시간 인기글 구현하기

cheolhyeon — Sun, 30 Mar 2025 17:20:32 +0900

자유 게시판 프로젝트를 진행함에 있어서 실시간 인기글을 구현해야 했다. 인기글 선정은 게시글의 좋아요와, 조회수, 그리고 댓글의 수를 따져가며 인기글인지 아닌지를 선정하게 되는데 여기에 있어서 Redis를 사용했다.

결정적인 이유는 자동 정렬 기능으로 인해 조회해 올 시 속도가 빠르다는 것이다. 인기글 조회는 사용자가 많이 접근하는 기능이기도 할 것이고, 그만큼 빠른 속도가 중요하기 때문에 채택하게 되었다.

인기글 선정을 RDBMS로 선정하고 저장해서 가져오게 될 경우 쿼리를 통해 조회해야 한다. 이 경우 인덱스를 활용하여 정렬과 조회 속도를 개선할 수 있겠지만, 새로운 인기글이 선정될 때마다 정렬 작업이 매번 이루어지게 되고 트래픽이 많아질 수록 DB 부하가 증가할 것이기 때문에 NoSQL DB인 Redis를 택했다.

게다가 TTL을 지원하기 때문에, 기간별로 인기글을 저장했다가 지울수도 있고, 여러가지 기능의 확장성으로 보았을 때 적합하다고 생각해서 Redis를 통해서 기능을 구현하기로 했다.

Redis SortedSet

해당 자료구조는 각 원소에 대해서 점수가 부여되고, 점수에 따라 자동으로 정렬되는 데이터 집합이다.

아래와 같은 특징을 가지기 때문에 인기글 선정에 대한 작업에 있어서 적합하다.

중복을 허용하지 않는다 : 중복이 발생할 경우 기존 점수만 덮어씌워진다.
점수 기반 자동 정렬 : 점수가 낮은 순서, 내림 차순으로 정렬되며 조회 시 정렬된 상태로 반환한다.
빠른 조회 성능 : 점수를 기반으로 조회할 때의 시간복잡도는 O(logN)이다.
범위 검색 지원 : 점수 또는 순위의 범위를 지정하여 데이터를 효율적으로 검색할 수 있는 함수를 제공한다.

데이터 삽입 (ZADD)

public void addOrUpdatePost(String key, String postId, double score) {
    redisTemplate.opsForZSet().add(key, postId, score);
    System.out.println("✅ " + postId + " 추가됨 (점수: " + score + ")");
}

postId를 원소로 지정하고 score를 통해 해당 key값으로 내부적으로 내림차순으로 정렬을 수행한다.

점수 증가 (ZINCRBY)

게시물의 점수를 증가시키는 방법이다.

public void incrementPostScore(String key, String postId, double increment) {
    redisTemplate.opsForZSet().incrementScore(key, postId, increment);
    System.out.println("  " + postId + "의 점수가 " + increment + "만큼 증가했습니다.");
}

점수 변경 후에도 자동으로 정렬된다.

[학습 포인트] Redis를 활용한 toggle(좋아요)기능 구현하기

cheolhyeon — Sun, 30 Mar 2025 16:59:53 +0900

자유 게시판 프로젝트를 진행함에 있어서 게시글의 좋아요 기능과 댓글의 좋아요 기능을 구현함에 있어서 적절한 방법은 무엇일지 고민했었다. 기본적으로 한번 누르면 좋아요가 증가하고 한번 더 누르면 좋아요가 감소해야된다.

일반적으로 MySQL과 같은 RDBMS들은 쿼리가 발생하는 DB에 게시글의 좋아요 기능 혹은 댓글의 좋아요 기능을 구현함에 있어서는 select 쿼리와 update 쿼리가 발생하게 될 것인데, 이에 따른 동시성 문제를 어떻게 해결하고, 응답속도 최적화를 하기 위해서는 어떤 방법이 있을지 고민하다가 NoSQL인 Redis를 활용하기로 결정하였다.

Redis를 사용하면 단일 스레드로 동작하기 때문에 증가, 감소, 삭제와 같은 명령어는 모두 Atomic하게 실행되므로 동시성 문제를 해결하기 위해서 적절하다고 판단했다. 더불어 트랜잭션 처리가 필요하지 성능 적인 부분도 함께 가져갈 수 있다.

Redis를 활용하여 Toggle 기능 구현하기

Redis는 Key-Value 형태로 값을 저장하고 Key 값으로 Value를 찾아오기 때문에 조회 부분에서 가장 좋은 성능을 보여준다.

toggle 기능을 구현하기 위한 기본적인 로직은 아래와 같다.

해당 요청을 보낸 특정 유저의 Id와 Post의 Id 혹은 Comment의 Id를 조합하여 키를 생성.
이를 기반으로 Key값이 이미 Redis에 존재한다면 좋아요 감소, 없다면 좋아요 증가를 하면 된다.

아래 코드는 Post의 좋아요 기능을 기반으로 작성된 코드이다.

@Repository
@RequiredArgsConstructor
public class PostLikeQueryRedisRepository {
    private static final String TOGGLE_KEY = "post:%s:users:%s:toggle";
    private final StringRedisTemplate postLikeRedisTemplate;

    public boolean isLikedByUserIdAndPostId(Long postId, Long userId) {
        String key = generateKey(postId, userId);
        return Boolean.TRUE.equals(postLikeRedisTemplate.hasKey(key));
    }
    public void insert(Long postId, Long userId) {
        String key = generateKey(postId, userId);
        postLikeRedisTemplate.opsForValue().set(key, "");
    }
    public void delete(Long postId, Long userId) {
        String key = generateKey(postId, userId);
        postLikeRedisTemplate.delete(key);
    }

    private String generateKey(Long postId, Long userId) {
        return TOGGLE_KEY.formatted(postId, userId);
    }
}

Key-Value 저장 방식: post:%s:users:%s:toggle 라는 형식으로 Redis의 Key를 구성.
isLikedByUserIdAndPostId() : hasKey() 메서드를 사용하여 특정 키가 존재하는 지 확인한다. O(1)
insert() : opsForValue().set(key, “”)로 Redis에 key를 추가한다. 이 때 Value는 별로 중요치 않고, Key의 존재 여부만 체크할 것이므로 빈값으로 넣기로 하였다.
delete() : Key가 이미 존재한다면 좋아요를 취소하는 것으로 간주하고 Key를 삭제한다.

@Service
@RequiredArgsConstructor
public class PostLikeService {
    private final PostLikeRedisRepository likeRedisRepository;
    private final PostLikeQueryRedisRepository queryRedisRepository;

    public Long toggleLike(Long postId, Long userId) {
        boolean isAlreadyLiked = queryRedisRepository.isLikedByUserIdAndPostId(postId, userId);
        if (isAlreadyLiked) {
            return unlikePost(postId, userId);
        }
        return likePost(postId, userId);
    }

    public Long getCurrentPostLikeCount(Long postId) {
        return likeRedisRepository.getCurrentPostLikeCount(postId);
    }

    private Long likePost(Long postId, Long userId) {
        queryRedisRepository.insert(postId, userId);
        return likeRedisRepository.increment(postId);
    }

    private Long unlikePost(Long postId, Long userId) {
        queryRedisRepository.delete(postId, userId);
        return likeRedisRepository.decrement(postId);
    }
}

[학습 포인트] Mockito Matchers와 실제 값을 이용한 테스트의 차이

cheolhyeon — Sun, 30 Mar 2025 16:52:52 +0900

레이어드 아키텍처의 단위 테스트 코드를 작성하다보면 Mock과 AssertJ를 사용하여 값을 검증하는 테스트 코드를 작성하게 된다. 이 때 테스트 코드 입문과정 시 헷갈리는 부분들을 정리하여 작성하게 되었다. 해당 테스트 코드는 BDD 스타일로 작성된 코드이다.

메서드의 호출 여부가 중요한 경우 - then()

입력값이 중요하지 않고 메서드의 호출 여부만 확인하고 싶을 때가 있다.

@Test
    @DisplayName("해당 메서드가 실제로 호출 되었는지 확인할 때")
    void callMethod() {
        //given
        given(mockService.process(anyString(), anyInt()))
                .willReturn(mock(MockingString.class));
        //when
        MockingString mocked = mockService.process("Mocked", 42);

        //then
        then(mockService).should().process(anyString(), anyInt());
    }

그럴 때는 값이 중요한게 아니기 때문에 matchers를 통해 인자의 타입을 정해주고, then구문 을 통해 해당 메서드가 호출 되었는지 되지 않았는지 확인할 수 있다.

⛔️ willReturn구문에는 matchers를 사용할 수 없기 때문에 객체만 Mocking 해주거나 실제 객체의 인스턴스를 넣어주어야 한다.

값 검증이 중요한 경우 - AssertJ

입력값이 중요하여 내가 예상한 객체 혹은 값이 반환이 잘 되는 것이 중요한 경우가 있다.

@Test
    @DisplayName("내가 예상한 데이터가 정확히 반환되는지가 중요할 때")
    void callMethod() {
        //given
        given(mockService.process("Mocked", 42))
                .willReturn(new MockingString("Mocked", 42));
        //when
        MockingString mocked = mockService.process("Mocked", 42);

        //then
        assertThat(mocked).extracting(
                MockingString::getNumber,
                MockingString::getRequest
        ).containsExactly(42, "Mocked");
    }

번외로 두 인자중에 하나의 인자에 any() matchers를 사용하고 하나의 인자에는 실제 값을 사용할 때에는 eq() matchers를 사용하여 실제 값을 감싸준다.

즉 일부 인자는 정확한 값이어야 하고, 일부 인자는 조건만 만족하면 되는 경우에 사용한다.

    void callMethod() {
        //given
        given(mockService.process(anyString(), eq(42)))
                .willReturn(new MockingString("Mocked", 42));
        //when
        MockingString mocked = mockService.process("Mocked", 42);
        
        //then
        assertThat(mocked).extracting(
                MockingString::getNumber,
                MockingString::getRequest
        ).containsExactly(42, "Mocked");
    }

값 검증과 메서드의 호출 둘다 검증이 필요한 경우

값 검증과 해당 메서드의 호출 여부 둘 다 검증이 필요한 경우의 테스트가 있다.

void callMethod() {
        //given
        given(mockService.process("Mocked", 42))
                .willReturn(new MockingString("Mocked", 42));
        //when
        MockingString mocked = mockService.process("Mocked", 42);

        //then
        assertThat(mocked).extracting(
                MockingString::getNumber,
                MockingString::getRequest
        ).containsExactly(42, "Mocked");
        then(mockService).should().process(anyString(), anyInt());
    }

값 검증에 대해서는 실제 값을 넣어주어야 한다.
그리고 메서드 호출 여부는 then 메서드를 통해 검증할 수 있다.

shouldHaveNoInteractions

목적 : 해당 Mock 객체에 대해 하나도 호출이 이루어지지 않았음을 검증하는 것.

예시 : 테스트 시작 후 특정 mock 객체가 전혀 사용되지 않아야 한다

then(mock).shouldHaveNoInteractions();

해당 호출은 mock에 대해 단 한건의 메서드 호출이 없었음을 증명하기 위해서 사용

shouldHaveNoMoreInteractions

목적 : 이미 검증한 메서드 호출 이외에 추가적인 호출이 없었음을 확인하는 것.

예시 : 여러 메서드의 호출을 검증한 후에 mock에 예기치 않은 호출이 없었는지 마지막으로 점검하고 싶을 때 사용한다.

  void reportWhenKeyExists() {
        // given
        String key = "report:users:1"; // generateKey(userId)가 이 값을 반환한다고 가정
        Duration ttl = Duration.ofDays(1);
        given(template.opsForValue()).willReturn(operations);
        given(template.hasKey(key)).willReturn(true);
        given(operations.increment(key)).willReturn(2L);

        // when
        Long result = reportRedisRepository.report(1L, ttl);

        // then
        assertThat(result).isEqualTo(2L);
        // key가 존재하므로, increment()만 호출되어야 함.
        then(operations).should(times(1)).increment(key);
        then(operations).should(never()).set(anyString(), any(String.class), any(Duration.class));
        // template에서는 hasKey와 opsForValue()가 각각 한 번씩 호출되어야 함.
        then(template).should(times(1)).hasKey(key);
        then(template).should(times(1)).opsForValue();

        // 추가 검증: 위에서 검증한 외에 다른 호출은 없어야 함.
        then(operations).shouldHaveNoMoreInteractions();
        then(template).shouldHaveNoMoreInteractions();
        
        // 만약 어떤 mock은 전혀 사용되지 않아야 한다면,
        // then(someOtherMock).shouldHaveNoInteractions();
    }

정리

• AssertJ와 Mockito.verify() / then()은 서로 다른 검증 목적을 가지고 있다.

• 값 검증은 AssertJ를, 메서드 호출 검증은 Mockito.verify()/then() 를 사용해야 한다.

• 둘 다 필요할 경우, 두 가지 방법을 함께 사용하여 검증하는 게 좋다.

[학습 포인트] MockMvc 컨트롤러 단위 테스트 시 인증정보 부재

cheolhyeon — Sun, 30 Mar 2025 16:29:08 +0900

SpringSecurity를 사용하는 프로젝트에서 만약 Contrller의 단위 테스트 작업을 진행할 경우, 사용자의 인증정보가 필요하게 될 것이다. 해당 인증정보를 어떻게 Mocking하는지에 대해서 알아보자

문제원인

MockMvc로 Controller Layer 단위 테스트시에 SpringSecurity가 활성화된 상태에서 MockMvc.perform() 호출 시 인증 정보가 주입되지 않으면 기본적으로 403 Forbidden 오류가 발생한다.
TestingAuthenticationToken 이나 커스텀 토큰으로 인증 객체 생성시에 필요한 권한 정보가 설정되지 않으면 Security 인가 과정이 실패한다.

해결 방안

@WithMockUser 또는 SecurityMockMvcRequestPostProcessors 사용

@Test
@WithMockUser(username = "testUser", roles = {"USER"})
void testController_withMockUser() throws Exception {
    mockMvc.perform(get("/v3/api/me/playtime")
            .param("year", "2025"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$", hasSize(1)))
            .andExpect(jsonPath("$[0].totalPlayTime").value("8760시간 0분"))
            .andExpect(jsonPath("$[0].totalParticipant").value(50))
            .andExpect(jsonPath("$[0].totalFollowers").value(0))
            .andDo(print());
}

테스트 메서드에 @WithMockUser(username = "testUser", roles = {"USER"}) 해당 기능을 사용하면 기본값으로 사용자 이름과 권한을 가진 인증 객체를 생성한다

2. SecurityMockMvcRequestPostProcessors 사용하기

    mockMvc.perform(get("/v3/api/me/playtime")
                        .param("year", String.valueOf(year))
                        .with(authentication(new TestingAuthenticationToken(dummyUser, null, "ROLE_USER"))))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$", hasSize(1)))
                .andExpect(jsonPath("$[0].totalPlayTime").value("8760시간 0분"))
                .andExpect(jsonPath("$[0].totalParticipant").value(50))
                .andExpect(jsonPath("$[0].totalFollowers").value(0))
                .andDo(print());

TestingAuthenticationToken에 권한 추가하기

import org.springframework.security.authentication.TestingAuthenticationToken;
import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.authentication;

@Test
void testController_withTestingAuthenticationToken() throws Exception {
    TestingAuthenticationToken dummyUser = new TestingAuthenticationToken("testUser", null, "ROLE_USER");

    mockMvc.perform(get("/v3/api/me/playtime")
            .param("year", "2025")
            .with(authentication(dummyUser)))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$", hasSize(1)))
            .andExpect(jsonPath("$[0].totalPlayTime").value("8760시간 0분"))
            .andExpect(jsonPath("$[0].totalParticipant").value(50))
            .andExpect(jsonPath("$[0].totalFollowers").value(0))
            .andDo(print());
}

Spring Security의 TestingAuthenticationToken을 사용하여 인증 객체를 직접 생성하고 권한을 추가할 수 있다.

학습 포인트

MockMvc와 Spring Security의 연동
- MockMvc로 Controller를 테스트 때도 SpringSecurity 필터 체인이 동작한다는 점을 이해해야한다.
- 인증이 필요한 API라면 반드시 Mock 또는 실제 인증과정을 시뮬레이션 해야 테스트가 성공한다.
테스트 인증 방법의 다양성
- @WithMockUser, .with(user(...)), TestingAuthenticationToken 등 다양한 방법이 존재한다.
- 상황에 따라 원하는 사용자 정보(이메일, 권한, roles 등)를 세부적으로 설정할 수 있다.
프로덕션 환경 vs 테스트 환경 구분
- 실제 배포 환경에서는 OAuth2, JWT, 세션 등 다양한 방식으로 인증이 이루어진다.
- 하지만 테스트 시에는 인증 로직을 간소화 하거나 Mock을 사용해, Controller나 Service 로직 검증에 집중하는 것이 중요하다.
- 필요하다면 Spring Security Test 라이브러리가 제공하는 전용 애노테이션(@WithMockUser, @WithSecurityContext)또는 SecurityMockMvcRequestPostProcessors를 적극 활용할 수 있다.

[학습 포인트] Redis 단위 테스트 작성하기 feat.ValueOperations, Operations

cheolhyeon — Sun, 30 Mar 2025 16:23:48 +0900

ValueOperation이란?

ValueOperations<K,V>는 SpringDataRedis에서 StringRedisTemplate를 통해 Redis의 “Value”관련 연산을 수행하는 인터페이스이다.

Redis에서 key-value형식으로 데이터를 저장하는데 이 때 ValueOperations는 Redis의 “String 타입” 데이터를 다루는데 사용된다.

ValueOperations의 주요 역할

데이터 읽기 작업

String value = redisTemplate.opsForValue().get("key");

데이터저장

redisTemplate.opsForValue().set("key", "value");

숫자증가

redisTemplate.opsForValue().increment("counter");

숫자감소

redisTemplate.opsForValue().decrement("counter");

왜 ValueOperations를 반환해서 사용하는가?

RedisTemplate 자체는 다양한 자료구조를 지원하지만, 각 자료구조를 다루는 방식은 다르다.

RedisTemplate의 각 opsForXXX()메서드는 해당 자료구조에 맞는 Operation 인터페이스를 반환해야한다. 해당 자료구조에 맞는 API를 사용할 수 있게 해준다.

데이터 타입 인터페이스 사용 메서드

String (단일 값)	ValueOperations	opsForValue()
Hash	HashOperations	opsForHash()
List	ListOperations	opsForList()
Set	SetOperations	opsForSet()
SortedSet	ZSetOperations	opsForZSet()
HyperLogLog	HyperLogLogOperations	opsForHyperLogLog()
Stream	StreamOperations	opsForStream()

Redis의 데이터 구조별로 Operation 인터페이스가 존재하기 때문에

RedisTemplate은 다양한 Redis 자료구조를 다룰 수 있게 설계되어 있다.
특정 자료구조를 사용하려면, 자료구조에 해당하는 인터페이스를 사용해야 한다.
ValueOperations는 Redis의 기본 자료구조인 String 타입 데이터를 다루기 위한 전용 인터페이스 입니다.

타입별로 제공되는 메서드가 다르기 때문에

RedisTemplate에서 opsForValue() 메서드를 호출하면 ValueOperations 객체가 반환된다.
ValueOperations 인터페이스에는 String 타입 데이터를 다루기 위한 다양한 메서드가 포함되어 있.
다른 자료구조(Hash, List, Set, SortedSet)를 사용하려면 각 자료구조에 맞는 인터페이스를 사용해야 한다.

테스트 코드 실사용 예제

@ExtendWith(MockitoExtension.class)
class ViewCountRedisRepositoryTest {

    @Mock
    StringRedisTemplate redisTemplate;

    @Mock
    ValueOperations<String, String> valueOperations;

    @InjectMocks
    ViewCountRedisRepository viewCountRedisRepository;

    @Test
    @DisplayName("특정 게시글 조회수 조회")
    void readPostViewCount() {
        // Given
        String key = "post:1:view_count";

        given(redisTemplate.opsForValue()).willReturn(valueOperations);
        given(valueOperations.get(key)).willReturn("100");

        // When
        Long result = viewCountRedisRepository.read(1L);

        // Then
        assertThat(result).isEqualTo(100L);
    }
}

given(redisTemplate.opsForValue()).willReturn(valueOperations); 해당 구문을 통해 redisTemplate.opsForValue 호출 될 때 ValueOperations 객체를 반환하도록 한 설정이다.

redisTemplate.opsForValue()는 ValueOperations<K, V> 인터페이스를 반환하는데, 이는 기본적으로 null이므로 테스트 실행 시 NullPointerException이 발생할 수 있습니다.

Redis - ValueOperaion 테스트 코드 작성 시

    public void insert(Long postId, Long userId) {
        String key = generateKey(postId, userId);
        postLikeRedisTemplate.opsForValue().set(key, "");
    }
    public void delete(Long postId, Long userId) {
        String key = generateKey(postId, userId);
        postLikeRedisTemplate.delete(key);
    }

insert메서드는 opsForValue를 통해 set 함수를 호춯함
delete메서드는 delete를 호출할 때 opsForValue를 호출하지 않음

이유

insert()는 Redis에 key-value 형태로 데이터를 저장해야 하므로 opsForValue()가 필요하다.

delete()는 key 자체를 삭제하면 되므로 opsForValue() 없이postLikeRedisTemplate.delete(key)만 호출

두 메서드는 각기 다른 Redis 동작을 수행하므로, opsForValue() 사용 여부가 다름!

    @Test
    @DisplayName("특정 유저가 특정 게시글에 좋아요를 처음 눌렀을 경우 key를 insert한다.")
    void insert() {
        //given
        given(template.opsForValue()).willReturn(valueOperations);
        //when
        repository.insert(1L, 1L);
        //then
        then(valueOperations).should(times(1)).set(anyString(), anyString());
    }
    @Test
    @DisplayName("특정 유저가 특정 게시글에 좋아요를 처음 눌렀을 경우 key를 insert한다.")
    void delete() {
        //given
        //when
        repository.delete(1L, 1L);
        //then
        then(template).should(times(1)).delete(anyString());
    }

그렇기 때문에 opsForValue를 사용한 함수 호출 시 에는valueOperation을 반환해주고, delete는 바로 Redis로 직접 접근하면 된다.

[트러블 슈팅] ⚠️A component required a bean named 에러 원인

cheolhyeon — Sun, 30 Mar 2025 15:07:46 +0900

A component required a bean named 'redisTemplate' that could not be found.

자유 게시판 프로젝트를 진행하던 중 나는 조회수와 댓글의 좋아요를 관리하기 위해 NoSQL 데이터베이스인 Redis를 사용했다. 사용하던 와중에 Redis의 데이터베이스를 관리하던 도중 위와 같은 에러가 발생했다.

왜 redisTemplate 오류가 났었는가?

해당 에러는 Spring이 redisTemplate라는 이름의 bean을 찾지 못했기 때문에 나타나는 에러이다.
혹시 해당 프로젝트에서 redis의 데이터베이스를 나눠서 사용하는 프로젝트라면 해당 문제가 발생할 수도 있다.

문제 상황

이번 프로젝트에서 조회수를 관리하는 viewCount와 댓글의 좋아요를 commentLike가 존재하는데, viewCount는 redis의 0번째 데이터베이스, commentLike는 1번째 데이터베이스에서 관리하도록 설정을 했다.

[문제가 발생한 코드]

@Configuration
public class RedisConfig {

    @Bean
    public RedisConnectionFactory viewCountRedisConnectionFactory() {
        RedisStandaloneConfiguration configuration = new RedisStandaloneConfiguration();
        configuration.setDatabase(0);
        return new LettuceConnectionFactory(configuration);
    }

    @Bean
    public StringRedisTemplate viewCountRedisTemplate() {
        return new StringRedisTemplate(viewCountRedisConnectionFactory());
    }

    @Bean
    public RedisConnectionFactory commentLikeRedisConnectionFactory() {
        RedisStandaloneConfiguration configuration = new RedisStandaloneConfiguration();
        configuration.setDatabase(1);
        return new LettuceConnectionFactory(configuration);
    }

    @Bean
    public StringRedisTemplate commentLikeRedisTemplate() {
        return new StringRedisTemplate(commentLikeRedisConnectionFactory());
    }
}

[결과]

A component required a bean named 'redisTemplate' that could not be found.

문제 원인

이는 SpringBoot에서 spring-boot-data-redis 라이브러리 의존성을 주입받으면 Spring은 기본적으로 RedisTemplate<String, String> Bean을 제공하려고 시도하고, 찾게 되는데 이때 기본적으로 redisTemplate라는 이름으로 등록된다.

하지만 현재 RedisConfig 설정에서 수동으로 Redis를 제어하고 있기 때문에 SpringBoot의 자동설정에서(RedisAutoConfiguration)이 동작하지 않는다.

RedisTemplate를 제어하려고 하니 redisTemplate라는 이름의 Bean을 명시적으로 등록하지 않았으므로 해당 문제가 발생하게 되는것이다. 이와 같은 이유로 해당 에러가 발생한 것이다.

위에 문제의 코드에서 StringRedisTemplate가 있지만 redisTemplate는 아니다.

StringRedisTemplate는 RedisTemplate<String,String>을 상속받지만 Spring은 기본적으로 이름이 “redisTemplate”인 RedisTemplate Bean을 찾고있기 때문에 위에 에러가 나타난다.

문제원인 정리

spring-boot-data-redis를 사용하면 스프링 부트가 자동으로 RedisTemplate를 제공하고, 런타임시 해당 클래스를 주입하려고 시도한다.
하지만 해당 프로젝트에서 RedisConfig를 통해 직접 수동으로 제어하다보니 스프링부트의 자동설정작업이 동작하지 않는다.
위와 같은 이유로 redisTemplate를 찾을 수 없다고 나오는 것.

해결방법

기본 RedisTemplate (Spring이 찾을 수 있도록 제공)

   
    @Bean
    public RedisConnectionFactory redisConnectionFactoryForSpring() {
        RedisStandaloneConfiguration configuration = new RedisStandaloneConfiguration();
        return new LettuceConnectionFactory(configuration);
    }

    @Bean
    public RedisTemplate<String, Object> **redisTemplate**(@Qualifier("redisConnectionFactoryForSpring") RedisConnectionFactory redisConnectionFactoryForSpring) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactoryForSpring);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        template.setHashKeySerializer(new StringRedisSerializer());
        template.setHashValueSerializer(new StringRedisSerializer());
        return template;
    }

기본적으로 스프링부트가 찾을 수 있는 RedisTemplate<String, String> 를 redisTemplate라는 이름으로 등록한다.

이렇게 하면 런타임시 스프링부트는 해당 빈을 찾아 주입을 하고, 실제 프로덕션 코드에서는 우리가 실제로 사용할 Redis를 레포지토리 레이어에서 의존성을 주입받아 사용할 수 있다.

    //   View Count 전용 StringRedisTemplate
    @Bean
    public RedisConnectionFactory viewCountRedisConnectionFactory() {
        RedisStandaloneConfiguration configuration = new RedisStandaloneConfiguration();
        configuration.setDatabase(0);
        return new LettuceConnectionFactory(configuration);
    }

    @Bean
    public StringRedisTemplate viewCountRedisTemplate(@Qualifier("viewCountRedisConnectionFactory") RedisConnectionFactory viewCountRedisConnectionFactory) {
        return new StringRedisTemplate(viewCountRedisConnectionFactory);
    }
    //   Comment Like 전용 StringRedisTemplate

    @Bean
    public RedisConnectionFactory commentLikeRedisConnectionFactory() {
        RedisStandaloneConfiguration configuration = new RedisStandaloneConfiguration();
        configuration.setDatabase(1);
        return new LettuceConnectionFactory(configuration);
    }

    @Bean
    public StringRedisTemplate commentLikeRedisTemplate(@Qualifier("commentLikeRedisConnectionFactory") RedisConnectionFactory commentLikeRedisConnectionFactory) {
        return new StringRedisTemplate(commentLikeRedisConnectionFactory);
    }

RedisConnectionFactory를 직접 주입하면?

Spring이 기본적으로 관리하는 RedisConnectionFactory 가 자동으로 주입받는다.

요약

Spring Boot는 기본적으로 RedisTemplate<String, String>을 redisTemplate이라는 이름으로 자동 등록하려고 한다.
하지만, 수동으로 RedisConfig를 작성하는 순간 자동 설정이 무효화된다.
그런데 RedisTemplate을 만들긴 했지만, Spring이 기대하는 redisTemplate이라는 이름으로 등록하지 않았다.
그래서 Spring이 redisTemplate을 찾을 수 없어서 오류가 발생한 것!
redisTemplate이라는 이름을 직접 등록하면 Spring이 이를 찾을 수 있게 된다.

[인프런 워밍업 클럽 스터디] 4주차 회고

cheolhyeon — Sun, 30 Mar 2025 12:35:47 +0900

Layered Architecture 구조의 레이어별 테스트 정리

Persistence Layer

특징: 데이터를 직접 접근하고 관리하는 계층.
테스트 방법: CRUD 중심으로 테스트하되, 비즈니스 로직은 포함하지 않는다.
유의점: 테스트 수행 후 데이터 정리(clean-up)를 철저히 해야 한다.

Business Layer

특징: 비즈니스 로직이 전개되는 중심 계층.
테스트 방법: 통합 테스트로 비즈니스 로직의 정확성을 검증하며, 예외 상황 처리에 더 많은 집중이 필요하다.
유의점: 예외 케이스를 잘 다루는 것이 개발자의 역량이다.

Presentation Layer

특징: 외부 요청을 처리하는 계층.
테스트 방법: 입력 값의 유효성을 검증하며, 하위 레이어는 모킹 처리하여 독립적으로 테스트한다.
유의점: 유효성 검증이 어느 레이어에서 이루어져야 하는지 신중하게 고민해야 한다.

Mocking에 대한 이해와 활용

Mock 객체를 활용하는 것이 단위 테스트의 핵심이라고 할 수 있다.

Mock 객체는 실제 객체의 행위를 대신할 수 있는 가짜 객체로, Mockito 같은 라이브러리를 활용해 쉽게 만들 수 있다.

중요한 것은 Mock 객체를 사용할 때, 실제 객체의 동작을 완벽하게 대체한다고 생각하지 말고 의심하고 검증하는 태도를 유지하는 것.

특히, Mock 객체의 역할과 Stub의 역할을 동시에 수행할 수 있다는 점을 배웠다.

또한, Mocking이 들어가는 순간 그것은 단위 테스트라는 개념을 다시 한번 되새길 수 있었습니다.

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이

@Mock: Mockito에서 단위 테스트를 위한 Mock 객체 생성. 행위 검증이 가능하다.
@MockBean: Spring Boot 테스트 환경에서 Mock 객체를 사용하기 위해 Bean을 Mock으로 교체한다.
@Spy: 실제 객체를 사용하면서 일부만 Stubbing을 할 수 있다.
@SpyBean: Spring Boot 테스트 환경에서 Bean을 Spy 객체로 교체한다.
@InjectMocks: @Mock과 @Spy로 생성된 객체를 테스트 대상 객체에 자동으로 주입해준다.

테스트 환경의 독립성 유지에 대한 고민

테스트의 독립성을 유지하는 것이 얼마나 중요한지를 다시 한번 느낄 수 있었다.

테스트 데이터가 @BeforeEach로 설정되면 모든 테스트에서 공유되는 데이터로 사용될 수 있다.

하지만, 테스트가 추가되거나 변경되면 해당 데이터가 정확히 어떤 테스트에서 필요한 것인지 혼란을 초래할 수 있다.

개인적으로는 각 테스트에서 필요한 데이터를 명시적으로 작성하는 방식이 더 명확하고 안전하다고 생각한다.

특히 예외적인 상황을 테스트하거나, 특정 요구사항을 검증할 때 명시적으로 데이터를 정의하는 것이 더 적합하다고 판단했다.

Spring REST Docs와 Swagger

Spring REST Docs와 Swagger는 문서화를 위한 좋은 도구들이다.

둘 다 장단점이 존재하므로, 팀의 환경과 목적에 맞게 적절히 선택하는 것이 중요하다고 생각한다.

Spring REST Docs: 코드 기반으로 문서를 자동으로 생성하며, 정확성과 신뢰도가 높다.
Swagger: UI 기반의 문서화가 가능하고 사용자가 직접 API를 테스트할 수 있는 장점이 있다.

회고와 느낀 점

이번 강의를 통해 테스트의 중요성과 모킹의 활용 방법을 깊게 배울 수 있었다.

특히, 단위 테스트와 통합 테스트를 구분해서 작성하는 방법을 익힌 것이 큰 성과라고 생각한다.

테스트 코드를 작성할 때 각 레이어의 특징을 이해하고, 적절한 테스트 방법을 적용하는 것이 중요하다는 것을 느꼈다.
또한, Mock 객체를 사용할 때는 항상 ‘정말 잘 모킹이 되었는가?’ 라는 의심을 가지고 테스트를 설계해야 한다고 생각한다.
앞으로는 테스트를 작성할 때도 더 효율적이고 의미 있게 작성하도록 노력해봐야겠다.

출처 : https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboard

[트러블 슈팅] ⚠️ 읽기 전용 트랜잭션 내 쓰기 작업 문제와 REQUIRES_NEW 전파 전략 활용(self invocation)

cheolhyeon — Sun, 30 Mar 2025 01:07:39 +0900

문제 상황

Spring Boot + Spring Data JPA 환경에서 다음과 같은 코드가 있었다

@Transactional(readOnly = true)
public Post readById(Long postId, Long userId) {
		PostEntity post = postRepository.findById(postId).orElseThrow(() -> throw new RuntimeException("..."))
    viewCountService.increase(post.getPostId, userId);
    ...
}

클라이언트가 게시글을 조회할 때 조회수가 증가하는 로직이다. 해당 메서드에서는 읽기 전용 @Transactional 이 발생한다.

그리고 increase 메서드 내부

viewCountBackUpService.backUp(postId, viewCount);

조회수는 Redis를 통해서 조회해오는 상황이다. Redis에서의 조회와 더불어 특정 조회수에 도달하게 되면 DB에 백업을 하기 위해서 update 및 insert 쿼리를 발생시키도록 로직을 작성했다.

@Transactional
public void backUp(Long postId, Long viewCount) {
       repository.save(new ViewCountEntity(postId, viewCount)); // ❌ INSERT 쿼리 미발생
    }
}

하지만 현재 save 쿼리메서드 호출 시 insert 쿼리가 발생하지 않는 문제가 발생했다.

문제 원인

해당 현상은 외부 메서드인 readById 메서드에서 읽기 전용 트랜잭션인 @Transactional(readOnly = true)가 발생했고 내부에서는 쓰기 트랜잭션이 발생했다.

이는 외부 메서드 readById에서 발생한 트랜잭션이 내부 메서드인 backUp까지 전파 되면서 쓰기 작업 트랜잭션이 발생하지 않은 것이다.

스프링의 트랜잭션 전파 기본 전략은 하나의 메서드에서 이미 발생한 트랜잭션이 존재하다면 해당 트랜잭션에 참여하는 것이 기본 전략인데, 이 때 외부 메서드의 읽기 전용 트랜잭션에 내부 메서드가 참여하게 되면서 해당 로직의 전체는 읽기 전용 트랜잭션에 참여하게 되면서 쓰기 트랜잭션이 작동하지 않은 것이다.

해결 방법

트랜잭션 전파 전략을 REQUIRES_NEW 로 설정함으로써 외부 트랜잭션과는 별개의 트랜잭션을 생성하여 참여 해줄 수 있다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void backUp(Long postId, Long viewCount) {
       repository.save(new ViewCountEntity(postId, viewCount)); // INSERT 쿼리 발생
    }
}

이렇게 하면 외부 메서드에서 호출 된 읽기 트랜잭션과는 별개의 트랜잭션을 생성함으로써 문제를 해결 할 수 있다.

해당 방식은 트랜잭션을 분리해줌으로써 외부 메서드의 트랜잭션과는 별개로 커밋과 롤백을 관리해준다.

즉 외부 메서드에서 에러가 발생해도 내부 트랜잭션까지는 전파가 안되므로 내부 트랜잭션은 마치 별도의 트랜잭션 처럼 작동하며 커밋과 롤백을 보장해준다는 장점이 있다.

단점으로는 커넥션 풀 부족 및 커넥션의 누수를 야기시킬 수 있다. 하나의 요청에 동시에 많은 트랜잭션이 발생하면 커넥션 풀이 부족해질 수 있으며, 트랜잭션이 끝나지 않고 있다면 커넥션 풀에 반환되지 않기 때문에 누수를 야기할 수 있다.

새로운 트랜잭션을 만든다는 것은 새로운 DB 커넥션을 커넥션 풀에 꺼내서 사용하게 되는 것이고, 기존 외부 메서드에서 발생한 트랜잭션을 보류가 되기 때문에 누수가 될 수 있다. 하나의 요청안에서 추가적인 N개의 트랜잭션을 새롭게 발생하게 되면 N개의 커넥션을 사용하게 되는 것이다.

이는 대량 요청시 병목 현상이 발생하고 전체 성능이 저하된다.
그래서 대용량 트래픽 환경에서는 해당 방식 보다는 트랜잭션을 분리해서 우회하는 방식을 통해 해결하는 방식이 더 바람직한 방법이 될 것 같다.

gotogg

[학습포인트] RDS 때려치고 EC2로 DB 굴린 후기

간략한 흐름은 아래와 같다

최소 아키텍처를 머릿속에 그려보면 아래와 같다.

보안그룹은 이렇게 딱 자른다

SG-BE

SG-DB

애플리케이션(Spring Boot) 설정

DataGrip은 BE를 점프로 쓴다(SSH 터널)

[트러블 슈팅] ⚠️ 게시글 검색 및 페이지네이션 슬로우 쿼리

문제 원인 파악

해결방안

인덱스 생성 후의 문제점

[학습 포인트] Redis SortedSet을 활용한 실시간 인기글 구현하기

Redis SortedSet

데이터 삽입 (ZADD)

점수 증가 (ZINCRBY)

인기글 조회 (ZREVRANGE)

[학습 포인트] Redis를 활용한 toggle(좋아요)기능 구현하기

Redis를 활용하여 Toggle 기능 구현하기

[학습 포인트] Mockito Matchers와 실제 값을 이용한 테스트의 차이

메서드의 호출 여부가 중요한 경우 - then()

값 검증이 중요한 경우 - AssertJ

값 검증과 메서드의 호출 둘다 검증이 필요한 경우

shouldHaveNoInteractions

shouldHaveNoMoreInteractions

[학습 포인트] MockMvc 컨트롤러 단위 테스트 시 인증정보 부재

문제원인

해결 방안

학습 포인트

[학습 포인트] Redis 단위 테스트 작성하기 feat.ValueOperations, Operations

ValueOperation이란?

ValueOperations의 주요 역할

왜 ValueOperations를 반환해서 사용하는가?

테스트 코드 실사용 예제

Redis - ValueOperaion 테스트 코드 작성 시

이유

[트러블 슈팅] ⚠️A component required a bean named 에러 원인

A component required a bean named 'redisTemplate' that could not be found.

왜 redisTemplate 오류가 났었는가?

문제 상황

문제 원인

해결방법

[인프런 워밍업 클럽 스터디] 4주차 회고

Layered Architecture 구조의 레이어별 테스트 정리

Mocking에 대한 이해와 활용

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이

테스트 환경의 독립성 유지에 대한 고민

Spring REST Docs와 Swagger

회고와 느낀 점

[트러블 슈팅] ⚠️ 읽기 전용 트랜잭션 내 쓰기 작업 문제와 REQUIRES_NEW 전파 전략 활용(self invocation)

문제 상황

문제 원인

해결 방법