목차

1. 문제상황 정리
2. 비관적 락과 낙관적 락
3. 비관적 락 적용
4. 낙관적 락 적용
5. 결과 비교
6. 결론

1. 문제상황 정리

지난 글에서 쿠폰 발급시 동시성 문제가 발생하는 것을 확인했다.

1번 테스트는 100개 제한의 쿠폰을 동시에 120회 발급 시도하였고, 2번 테스트는 인당 1개 발급 가능한 쿠폰을 동시에 100회 발급 시도하였다.

결과는 두 테스트 모두 100개, 1개를 초과 발급하여 동시성 문제가 발생하는 것을 확인 하였다.

이 동시성 문제를 해결하기 위해 락을 걸고자 한다.

2. 비관적 락과 낙관적 락

2.1. 락이란?

DB에 여러 사용자, 서비스 혹은 스레드 등이 동시에 접근하는 상황에서 데이터의 무결성, 일관성을 지키기 위한 자원에 대한 잠금 동시성 문제를 해결하기 위해 사용한다.

락의 종류

• S-Lock(공유 락,Shared Lock) : 테이블을 조회 할 경우 사용됨. 여러 사용자가 동시에 데이터를 읽어도 일관성 문제 발생하지 않기 때문에, S-Lock 끼리는 동시 접근 가능. 락이 걸려있는 동안 데이터 변경 불가.
• X-Lock(베타 락, Exclusive Lock) : 데이터의 변경이 발생할 경우 사용됨. 다른 세션, 스레드 등이 자원에 접근하는 것을 막고 해제될 때 까지 읽기 쓰기 접근이 불가능 함. 트랜잭션 끝까지 유지됨.
• Update-Lock(업데이트 락) : 데이터 수정 전 X 락을 걸기 전에 데드락 방지를 위해 거는 락. 일반적으로 Update 쿼리의 필터(WHERE)가 실행되는 과정에서 적용.
• Intent-Lock(내재 락) : 사용자가 요청한 범위에 락을 걸 수 있는지 여부를 빠르게 확인하기 위해 사용 됨.

2.2. 비관적 락(Pessimistic Lock)

데이터에 동시성 문제가 발생할 것이라고 가정하고, 수정전에 미리 접근을 제한하는 방식

비관적 락은 데이터 충돌이 많이 발생할 것 같은 상황에서 주로 사용 됨. 한번에 같은 데이터에 접근을 못하게 막는 방식으로 여러 데이터의 충돌을 방지함.

데이터 접근이 엄격하게 통제되므로 데이터의 일관성이 중요한 경우 사용.

• 장점
  • 데이터의 일관성과 동시성을 보장할 수 있음
  • 데이터에 대한 잠금을 설정하여 충돌을 방지할 수 있음
• 단점
  • 동시성이 낮아짐. 트랜잭션동안 다른 트랜잭션이 접근할 수 없음
  • 때문에 시스템 성능이 저하될 수 있음

2.3. 낙관적 락(Optimisitc Lock)

데이터를 읽을 때 락을 걸지 않고, 변경 시점에 충돌을 검사하는 방식

낙관적 락은 데이터 충돌이 비교적 적게 발생할 것 같은 상황에서 주로 사용 됨. 충돌이 발생한 경우, 롤백을 수행하거나, 충돌을 해결하는 로직을 사용.

JPA에서는 Version 필드를 만들어서 해당 필드를 관리함.

• 장점
  • 동시성이 높아짐. 동시에 여러 트랜잭션이 데이터에 접근하고 변경 할 수 있음
  • 충돌 발생 시 롤백을 피하고 충돌을 해결 할 수 있는 기회를 제공
• 단점
  • 충돌 발생시 롤백이 발생할 수 있음
  • 충돌 업데이트 로직에 따라 뒷 요청이 무시될 수 있다.

3. 비관적 락 적용

비관적 락 적용은 쿼리를 진행할 때 락을 거는 키워드를 붙여서 적용할 수 있다.

일반 쿼리를 적용하는 레파지토리 일 경우 @Lock(LockModeType.PESSIMISTIC_WRITE) 키워드를 붙이면 된다.

필자가 진행하는 프로젝트는 QueryDSL을 통해 쿼리를 빌드하기 때문에 아래와 같이 작성하면 된다.

//UserCouponCustomRepositoryImpl.java
    @Override
    public Coupon findByIdWithPessimisticLock(Long couponId) {
        Coupon result = queryFactory
                .selectFrom(coupon)
                .where(coupon.couponId.eq(couponId))
                .setLockMode(LockModeType.PESSIMISTIC_WRITE)
                .fetchFirst();

        if(result == null) {
            throw new CouponNotFoundException("존재하지 않는 쿠폰입니다");
        }

        return result;
    }



//CouponService.java  
    //issue coupon (create UserCoupon)
    //Only Admin can issue "ALL" type coupon
    //every user can issue "LIMIT" type coupon
    //"LIMIT" type coupon can issue amount less than "couponAmount"
    @Transactional
    public UserCouponResponseDto issueCoupon(Long couponId, String userRole, Long userId){

        Coupon coupon = couponRepository.findByIdWithPessimisticLock(couponId);

        //ALL 쿠폰 발급시 관리자 권한 체크
        if(!checkIsAdmin(userRole) && coupon.getCouponType().equals(CouponType.ALL)){
            throw new PermissionNotfoundException("쿠폰발급 권한이 없는 사용자입니다.");
        }

        //check amount
        if (coupon.getCouponAmountRemaining() <= 0) {
            throw new CouponAmountErrorException("쿠폰이 소진되었습니다.");
        }

        //check already have
        if(userCouponRepository.findUserCouponByUserIdAndCouponId(userId, couponId).isPresent()){
            throw new CouponAmountErrorException("이미 보유한 쿠폰입니다");
        }

        coupon.decreaseCoupon();

        UserCoupon userCoupon = UserCoupon.builder()
                .userId(userId)
                .coupon(coupon)
                .isUsed(false)
                .build();

        userCouponRepository.save(userCoupon);
        return UserCouponResponseDto.from(userCoupon);
    }

위와 같이 쿼리를 작성하면 조회 쿼리에서 FOR UPDATE 가 추가되며 락을 획득한 상태에서 로직이 실행되는 것을 볼 수 있다. 해당 코드가 실행될 때의 Hibernate 로그는 아래와 같다

select c1_0.coupon_id,c1_0.available,c1_0.coupon_amount_remaining,c1_0.coupon_amount_total,c1_0.coupon_code,c1_0.coupon_maximum,c1_0.coupon_minimum,c1_0.coupon_name,c1_0.coupon_type,c1_0.discount_percentage,c1_0.discount_price,c1_0.discount_type,c1_0.expiry_date,c1_0.issue_date from coupon c1_0 where c1_0.coupon_id=? limit ? for update

4. 낙관적 락 적용

낙관적 락은 실질적으로 락을 걸지 않고, 버전 체크를 통해서 충돌을 확인한다. 따라서 Coupon Entity에 Version을 저장하는 필드가 필요하다.

트랜잭션을 진행하며 버전간 충돌이 발생하면 충돌이 발생한 버전에 대해서 롤백을 진행하고 다음 트랜잭션을 진행한다.

//Coupon.java
    @Getter
    @NoArgsConstructor
    @EntityListeners(AuditingEntityListener.class)
    @Entity
    public class Coupon {

        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private Long couponId;

        //중략

        @Version
        private Long version;
    }



//CouponCustomRepositoryImpl.java
    @Override
    public Coupon findByIdWithPessimisticLock(Long couponId) {
        Coupon result = queryFactory
                .selectFrom(coupon)
                .where(coupon.couponId.eq(couponId))
                .setLockMode(LockModeType.OPTIMISTIC)
                .fetchFirst();

        if(result == null) {
            throw new CouponNotFoundException("존재하지 않는 쿠폰입니다");
        }

        return result;
    }

    @Override
    public Coupon findByIdOrElseThrow(Long couponId) {
        Coupon result = queryFactory
                .selectFrom(coupon)
                .where(coupon.couponId.eq(couponId))
                .fetchFirst();

        if(result == null) {
            throw new CouponNotFoundException("존재하지 않는 쿠폰입니다.");
        }

        return result;
    }



//CouponService.java
    @Transactional
    public UserCouponResponseDto issueCoupon(Long couponId, String userRole, Long userId){

        Coupon coupon = getCoupon(couponId);

        //ALL 쿠폰 발급시 관리자 권한 체크
        if(!checkIsAdmin(userRole) && coupon.getCouponType().equals(CouponType.ALL)){
            throw new PermissionNotfoundException("쿠폰발급 권한이 없는 사용자입니다.");
        }

        //TODO: 추후 락 구현 필요
        //check amount
        if (coupon.getCouponAmountRemaining() <= 0) {
            throw new CouponAmountErrorException("쿠폰이 소진되었습니다.");
        }

        //check already have
        if(userCouponRepository.findUserCouponByUserIdAndCouponId(userId, couponId).isPresent()){
            throw new CouponAmountErrorException("이미 보유한 쿠폰입니다");
        }

        coupon.decreaseCoupon();

        UserCoupon userCoupon = UserCoupon.builder()
                .userId(userId)
                .coupon(coupon)
                .isUsed(false)
                .build();

        userCouponRepository.save(userCoupon);
        return UserCouponResponseDto.from(userCoupon);
    }

    private Coupon getCoupon(Long couponId){
        return couponRepository.findByIdOrElseThrow(couponId);
    }

5. 결과 비교

5.1. 비관적 락 결과

발급 개수가 일정하게 제한 개수를 초과하지 않는 결과가 나오는 것을 확인하였다. 즉 동시성 문제가 발생하지 않는다는 것이다.

다만, 락을 걸고 트랜잭션 처리 후 락을 해제 하는 과정을 순차적으로 진행하다 보니 처리율이 낮아지는, 즉 동시성이 떨어지는 모습이 보였다.

특히 DB의 성능이 떨어지는 상황에서 요청이 지연되자, 아래와 같이 HikariPool에서 타임아웃이 발생하는 모습도 보였다.

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction] with root cause
java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms (total=10, active=10, idle=0, waiting=33)

5.2. 낙관적 락 결과

비관적락과 마찬가지로 제한개수를 초과하지 않으며 동시성 문제가 발생하지 않는 문제를 보였다. 또한 락을 거는 비관적 락 보다 우월한 속도 성능을 보였다.

다만 충돌로 인해 많은 예외가 발생하였다. 또한 충돌로 인한 롤백이 다수 발생하여 여러 트랜잭션이 롤백으로 무시되는 현상이 발견되었다.

아래 사진을 보면 UserCouponId가 5, 16, 27...으로 띄엄띄엄 증가하는 모습을 보인다. 이는 여러 트랜잭션이 동시에 쿠폰 발급을 시도하고, 낙관적 락 충돌이 발생하여 일부 트랜잭션이 롤백되었음을 시사한다. 즉 14, 615 등의 트랜잭션은 충돌로 인해 무효화되었다는 것이다.

게다가 낙관적 락의 방식에서는 서버 단에서 롤백된 트랜잭션을 다시 시도하는 방법이 없다. 어플리케이션(프론트) 단에서 에러를 처리해 다시 시도하던지, 사용자가 재 요청하는 방법밖에 없다는 것이다.

이렇게 무시된 트랜잭션은 Retryable을 통해 재시도 처리를 따로 해주어야 한다.

6. 결론

결과적으로 두 방식 모두 동시성 문제를 예방할 수 있는 해결책이나, 각자의 문제점을 안고 있으며 문제 상황에 맞는 해결 방법을 적용할 필요가 있다.

비관적 락의 경우 느린 성능을 보유하였지만, 락과 해제를 통해 대기중인 트랜잭션이 누락 없이 해결되도록 동작하는 모습을 보인다. 낙관적 락의 일부 트랜잭션이 무효화 되고, 잦은 충돌에 예외가 많이 발생하지만, 상대적으로 빠른 처리속도를 보여준다.

따라서 낮은 DB의 처리 속도와 동시성 문제가 낮은 빈도로 발생할 것으로 예상하여 낙관적 락으로 우선 적용하고자 한다.

다음 글에서는 동시성 문제를 해결 할 수 있는 다른 방법들을 더 알아보고자 한다.

참고자료

• https://hstory0208.tistory.com/entry/%EB%9D%BDLock%EC%9D%B4%EB%9E%80-Lock%EC%9D%98-%EC%A2%85%EB%A5%98%EC%99%80-%EA%B5%90%EC%B0%A9%EC%83%81%ED%83%9CDeadLock
• https://velog.io/@soongjamm/Select-%EC%BF%BC%EB%A6%AC%EB%8A%94-S%EB%9D%BD%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4.-X%EB%9D%BD%EA%B3%BC-S%EB%9D%BD%EC%9D%98-%EC%B0%A8%EC%9D%B4
• https://velog.io/@yellowsunn/%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88%EB%A5%BC-%ED%95%B4%EA%B2%B0%ED%95%98%EB%8A%94-%EB%8B%A4%EC%96%91%ED%95%9C-%EB%B0%A9%EB%B2%95
• https://velog.io/@lsb156/JPA-Optimistic-Lock-Pessimistic-Lock
• https://ksh-coding.tistory.com/125

목차

1. 동시성 문제란?
2. 배경지식
3. 테스트 - 동시성 문제 확인
4. 테스트 결과 - 동시성 문제 발생
5. 동시성 문제 해결 방법

1. 동시성 문제란?

동시성 문제란 하나의 자원에 두개 이상의 스레드, 세션에서 가변 데이터를 동시에 제어할 때 나타나는 문제이다. 하나의 세션이 데이터에 접근중일 때, 다른 세션에서 동시에 접근할 경우 동시성 문제로 인해 데이터 정합성에 문제가 생긴다.

현재 프로젝트의 쿠폰 발급 서비스에서 한정된 쿠폰을 여러 사람이 동시에 발급하고자 할 때 동시성 문제가 발생할 가능성이 있어 이를 파악하고 해결해보고자 한다.

2. 배경 지식

• *Race condition(경쟁상태) : * 두 개 이상의 프로세스가 공통 자원을 병행적으로 접근할 때, 접근 순서에 따라 실행 결과가 달라지는 상황. 두개의 스레드 혹은 세션 등이 자원을 놓고 경쟁하는 상황
• *Dead Lock(교착상태) : * 프로세스가 두 자원 모두에 접근해야 하는 상황에서, 두 개의 프로세스가 각자 한 자원을 점유하였을 때, 각자 소유한 리소스를 해제하지 않고 무한정 대기하게 되는 상황
• *Starvation(기아상태) : * 특정 프로세스의 우선순위가 낮아 원하는 자원을 할당받지 못하는 상황

3. 테스트 - 동시성 문제 확인

동시성 문제가 발생하는지 확인하기 위해 Lock 등 동시성문제 처리가 되지 않은 상태에서 테스트를 진행한다. Locust를 통해 서버에 요청을 보내 결과를 확인하는 방식으로 진행한다.

3.1. 테스트 시나리오

1번 테스트: 100매 발급 가능한 쿠폰을 120명이 발급 시도한다. -> 정상적인 경우 100매 성공, 20매 실패 2번 테스트: 1일당 1매 발급 가능한 쿠폰을 1인이 동시에 여러번 발급 시도한다. -> 정상적인 경우 1매만 발급 성공

3.2. 테스트 코드

1번 테스트

from locust import HttpUser, task, between, SequentialTaskSet
import requests
import random
import string

#시나리오:
#다수의 사용자가 한번에 동시에 쿠폰 발급을 시도하는 시나리오

HOST = "http://localhost:8080"

class BoardServiceUser(SequentialTaskSet):

    def on_start(self):
        # 1. 회원가입
        randEmail = self.generate_random_email()

        response = requests.post(HOST + "/api/v1/users", json={
            "email" : randEmail,
            "password": "test1234",
            "nickname": "testUser",
            "userRole" : "USER",
            "phoneNumber" : "01012340000"
        })
        data = response.json()
        if data["status"] == "success":
            print("회원가입 성공")
        else:
            print("회원가입 실패:", data["message"])
            self.interrupt()


        # 2.로그인 요청
        response = requests.post(HOST + "/api/v1/users/login", json={
            "email": randEmail,
            "password": "test1234"
        })

        data = response.json()
        if data["status"] == "success":
            token = data["data"]
            self.client.headers.update({'Authorization': f'Bearer {token}'})
        else:
            print("로그인 실패:", data["message"])
            self.interrupt() 


    @staticmethod
    def generate_random_email():
        random_string = ''.join(random.choices(string.ascii_lowercase + string.digits, k=8))
        return f"test_{random_string}@example.com"

    #쿠폰 발급
    @task
    def issueCoupone(self):
        response = self.user.client.post(HOST + "/api/v1/coupons/user-coupons/1")
        print(response)

class WebsiteUser(HttpUser):
    host = HOST
    tasks = [BoardServiceUser]
    wait_time = between(1, 1)

2번 테스트

from locust import HttpUser, task, between, SequentialTaskSet
import requests
import random
import string

#시나리오:
#단일 사용자가 하나의 쿠폰에 대해 여러번 쿠폰 발급을 시도하는 시나리오

HOST = "http://localhost:8080"

class BoardServiceUser(SequentialTaskSet):

    def on_start(self):

        # 2.로그인 요청
        response = requests.post(HOST + "/api/v1/users/login", json={
            "email": "test@test.com",
            "password": "test1234"
        })

        data = response.json()
        if data["status"] == "success":
            token = data["data"]
            self.client.headers.update({'Authorization': f'Bearer {token}'})
        else:
            print("로그인 실패:", data["message"])
            self.interrupt() 

    #쿠폰 발급
    @task
    def issueCoupone(self):
        response = self.user.client.post(HOST + "/api/v1/coupons/user-coupons/1")
        print(response)

class WebsiteUser(HttpUser):
    host = HOST
    tasks = [BoardServiceUser]
    wait_time = between(1, 1)

3.3. 테스트 진행

1번 테스트 *시나리오: *120명의 사용자가 랜덤 회원가입 후 로그인하여 인증 키를 얻고, 해당 키를 첨부해 쿠폰 발급을 시도한다. *기대 결과: * 120명의 사용자가 생성된 후, 100매의 쿠폰이 발급된다. 20개의 요청은 에러가 발생한다. *참고 사항: * 환경상 발생할 수 있는 차이를 고려해 10회 실시한다.

2번 테스트 *시나리오: * 한명의 사용자가 100번의 쿠폰 발급 요청을 동시에 시도하는것을 모사하여 쿠폰발급을 시도한다. *기대 결과: * 1명의 사용자에 1매의 발급이 가능한만큼, 매 회 1매의 쿠폰만이 발급되고. 99개의 에러가 발생한다. *참고사항: * 환경 상 발생할 수 있는 차이를 고려해 10회 실시한다.

4. 테스트 결과 - 동시성 문제 발생

4.1. 1번 테스트 결과

회차	1	2	3	4	5	6	7	8	9	10	평균
생성된 쿠폰 수	105	101	101	101	101	101	100	103	101	101	101.5

Locust를 통해 10회의 테스트를 진행하였으며, 매 회 100개의 쿠폰만 생성될 것을 기대하였으나, 평균 1.5개의 쿠폰이 더 발급되며, 동시성 문제가 발생하는 것을 확인했다.

4.2. 2번 테스트 결과

회차	1	2	3	4	5	6	7	8	9	10	평균
생성된 쿠폰 수	9	7	8	4	8	4	10	5	6	2	6.3

Locust를 통해 10회의 테스트를 진행하였으며, 매 회 1개의 쿠폰만 발급될 것을 기대하였으나. 평균 6.3개의 쿠폰이 더 발급되며, 동시성 문제가 발생하는 것을 확인했다.

5. 동시성 문제 해결 방법

동시성 문제에는 비관적 락(Pessimistic Lock), 낙관적 락(Optimistic Lock), 분산락 등의 해결방법이 있는데, 이를 알아보고 알맞은 방법을 이용해 해결해보고자 한다.

참고자료

• https://iredays.tistory.com/125

목차

1. 성능 테스트
2. Locust란?
3. Locust 설치
4. 스크립트 작성
5. 부하테스트 실행
6. 결과
7. 성능 개선

1. 성능테스트

성능 테스트는 왜 필요한가?

서버 기능 작성을 마쳤다. 서버는 정상적으로 작동한다. 하지만 그렇지 않을수도 있다.

사람들이 몰리면 부하가 발생한 서버는 예상한 것과 다르게 작동할 수 있기 때문이다. (락 발생, 쿼리 지연, 병목 현상 등) 때문에 위와 같은 문제를 해결하기 위해 성능 테스트, 부하테스트를 진행하려 한다.

1.1 성능테스트 종류

• *부하테스트(Load Test): * 특정 부하를 제한시간동안 부여. 일반적으로 1시간 기준
• *스트레스 테스트 : * peak Load 보다 높은 부하(일반적으로 2배)에 어떻게 대응하는지, 정상 복구되는지 테스트
• *내구 테스트(Endurance Test): * 장기간에 걸쳐 나타나는 문제(메모리 누수)를 확인하기 위해 장시간에 걸쳐 시스템의 안정성을 검사
• *스파이크 테스트(Spike Test): * 급작스러운 사용량 급증 시나리오에 대해 시뮬레이션
• *중단점 테스트(Breaking Point Test): * 동시단말 사용자 수를 점진적 증가시켜, 시스템 장애 시점을 결정하는 테스트

1.2. 성능테스트 목적

성능 테스트를 통해 시스템의 성능상 한계와 리소스의 한계를 파악할 수 있다. 최대 성능이 어느정도인지 파악해 서버를 최적화 할 수 있다. 서버를 최적화하는 과정을 아래의 단계를 따른다

성능 측정 <-> 결함 검출 <-> 병목 제거 <-> 용량 검증 => 반복

1.3. 배경지식

• Response Time, 응답시간: 사용자의 Request 시점에서 시스템이 Response 하기까지의 종단시간.

  

• User: 서버를 사용중인 사람

  • Current User: 언제든 부하를 줄 수 있는 사용자
  • Active User: 실제로 부하를 주고 있는 사용자

• TPS(Transaction Per Test) : 초당 트랜잭션 수

• Saturation Point, 임계점: 최대 TPS가 나타나는 최초의 지점.

  

2. Locust란?

다양한 부하테스트 툴(JMeter, Locust, K6)중 가볍고(로컬에서 요청 발생시킬 예정), 러닝커브가 적은(Python으로 스크립트 작성 가능) Locust를 선택하게 되었다.

Locust는 오픈소스 부하테스트 도구이다. Python으로 스크립트를 작성할 수 있으며, 웹 애플리케이션의 성능을 측정할 수 있도록 도와준다. 웹 인터페이스를 제공하여 실시간으로 테스트를 모니터링하고 결과를 분석하기 쉽도록 한다.

2.1. Locust의 장점

• 쉽게 설치가 가능
• Python 스크립트를 통해 쉽게 작성 가능
• 빠르게 테스트 진행 가능
• 웹 인터페이스 지원으로 결과 시각화

3. Locust 설치

pip를 통해 로컬에 Locust를 설치해준다. pip가 설치되어있지 않다면 다음 링크를 참고하여 Python, pip 등을 설치하여 환경을 준비해준다

#설치
$ pip install locust
# 설치확인
$ locust -V

4. 스크립트 작성

locustfile.py 파일에 작성해도 되며, locust -f {경로} 명령어를 통해 경로를 첨부해 실행해도 된다.

4.1. 스크립트

• wait_time : 가상 사용자의 대기시간 정의
• host : 테스트 할 대상 호스트 정의.(주소, IP 등)
• @task : 테스트 할 작업을 정의하는 데코레이터. TaskSet이 실행될 때 TaskSet 안의 task를 랜덤 하게 선택해서 실행한다. 가중치를 줄 수 있다.
• seq_task: 테스트 할 작업을 순서까지 정의하는 데코레이터. TaskSequence가 실행될 때 안의 seq_task 순서에 따라 실행한다.
• setup & teardown : setup과, teardown은 TaskSet의 생성시, 종료시 한번씩 실행된다.
• on_start,on_stop: 매 클라이언트마다 실행된다.'

실행 순서 Locust setup TaskSet setup TaskSet on_start TaskSet tasks… TaskSet on_stop TaskSet teardown Locust teardown

4.2. 필요한 모듈 임포트

기본적인 HTTP 요청을 테스트하려면 HttpUser와 task 데코레이터를 임포트해야 한다.

from locust import HttpUser, task, TaskSet

4.3. HttpUser 클래스 정의

HttpUser class를 상속받아 가상의 사용자를 정의한다.

class QuickstartUser(HttpUser):
    # 사용자 간 대기 시간 설정
    wait_time = between(1, 2)  
    # 테스트 대상 호스트 설정
    host = "http://example.com"  

    @task
    def index_page(self):
        self.client.get("/")

    @task
    def about_page(self):
        self.client.get("/about/")

아래는 스크립트 예제이다.

from locust import HttpUser, task, between

class QuickstartUser(HttpUser):
    # 시뮬레이션 된 유저는 작업을 실행하기 전 5~9초 기다린다.
    wait_time = between(5, 9)

    def on_start(self):
        # 토큰으로 인증 헤더를 초기화
        self.client.headers.update({'Authorization': 'Bearer TOKEN_HERE'})

    @task(1)
    def index_page(self):
        # 대기 시간동안 아래 네번의 Get 요청을 진행
        self.client.get("/api/hosts")
        self.client.get("/api/tests")
        self.client.get("/api/result/1488")
        self.client.get("/api/result/1463")

아래는 로그인 방식을 처리하는 예제이다.

from locust import HttpUser, TaskSet, task
import requests

class UserBehavior(TaskSet):
  def on_start(self):

        #로그인 요청 작성
      response = requests.post("http://mysite.com/login", {
        "username": "user",
        "password": "pass"
      })

      # 1. response header에서 토큰 설정
      self.client.headers.update({'Authorization': response.headers.get('token')})

      # 2. cookies에서 토큰 설정
      self.client.cookies.set('Authorization', response.cookies.get('token'))

      # 3. response body에서 토큰 설정
      token = str(response.content.decode().find('token')
      self.client.headers.update({'Authorization': token)})

  # 나머지 테스트 코드 작성

4.4. 스크립트 작성

위 코드 작성 방법을 바탕으로 로그인 이후 단순 게시글 조회를 진행하는 테스트 코드를 작성해보았다.

from locust import HttpUser, task, TaskSet, between
import requests
import re

HOST = "[호스트 경로]:8900"

class UserBehavior(TaskSet):
    def on_start(self):
        #로그인 요청
        response = requests.post(HOST + "/api/auth/login", json={
                "userEmail": "testEmail@test.com",
                "userPassword" :"Test" 
        })

        data = response.json()
        if data["code"] == 200:
            set_cookie = response.headers.get('Set-Cookie')
            if set_cookie:
                token_match = re.search(r'accessToken=([^;]+)', set_cookie)
                if token_match:
                    token = token_match.group(1)
                    print(token)  # 순수 토큰 값 출력
                    self.client.cookies.set('accessToken', token)

                else:
                    print("토큰을 찾을 수 없습니다.")
            else:
                print("Set-Cookie 헤더가 없습니다.")
        else:
            print("로그인실패:", data["message"])

    @task
    def get_board(self):
        with self.client.get("/api/board/1", catch_response=True) as response:
            if response.status_code == 200:
                print("게시글 조회 성공")
            else:
                print("게시글 조회 실패: {response.status_code}")
                response.faiure(f"게시글 조회 실패: {response.status_code}")


class WebsiteUser(HttpUser):
    host = HOST
    tasks = [UserBehavior]
    wait_time = between(1, 1)

5. 부하 테스트 실행

5.1. 부하 테스트 환경

기기: 시놀로지 DS220+ CPU: INTEL Celeron J4025(2코어, 2 GHz) RAM: 18GB

5.2. Locust 실행

아래 명령어를 실행하여 로커스트를 실행한다.

locust -f [파일경로]

이후 아래 명령어에 나오는 URL로 접속해주면 웹 인터페이스를 볼 수 있다. 별도의 설정이 없었다면 http://localhost:8089/로 접속하면 된다.

5.3. 테스트 설정

위 주소로 접속하면 아래와 같은 화면이 나온다 각 값의 의미는 아래와 같다

• Number of User : 최대(피크) 동시접속 유저 수
• Ramp Up : 초마다 증가될 유저 수(사용자 점진적 증가)
• Host : 테스트를 진행할 서버 주소. 코드에서 지정해 줬다면 미리 입력되어있다.

테스트를 원하는 값을 입력해주고 start 버튼을 누른다.

아래 조건을 입력 후 진행해보았다.

6. 결과

6.1. 결과 지표

• RPS: 초당 요청 수. 값이 높을 수록 초당 처리할 수 있는 요청수가 많음을 의미. 성능 테스트의 부하를 알 수 있음.
• Failures: 실패 비율. 요청이 실패한 비율과 횟수를 표기
• 50th Percentile: 요청 응답시간의 중앙값. 평균보다 왜곡이 적은 응답 값(평균은 극단적 값을 포함)
• 95th Percentile:요청 응답시간의 95번째 백분위의 수. 성능의 일관성을 평가할 수 있음
• Number Of User: 활성 사용자 수

6.2. 결과 분석

• 테스트 시작 후 RPS가 점차 증가하여 0.2 ~ 0.4 범위를 변동
• 응답 시간이 테스트 시작부터 꾸준히 증가하여 60,000ms(60초) 이상까지 도달
• 50번째와 95번째 백분위수 응답 시간이 거의 동일하게 증가하는 것으로 보아, 대부분의 요청이 매우 느리게 처리되고 있음을 알 수 있음

6.3. 종합 평가

• 테스트 대상 시스템은 100명의 사용자를 처리하지만, 초당 요청 수가 매우 낮고 응답 시간이 매우 높음
• 시스템이 요청을 제대로 처리하지 못하고 있거나, 매우 느리게 처리하고 있음을 나타냄
• 낮은 RPS와 높은 응답 시간은 시스템의 심각한 성능 문제를 시사

7. 성능 개선

... 심각하다

성능 개선을 위해 아래 목록을 점검하고자 한다.

• 시스템 자원 점검: 서버의 CPU, 메모리, 디스크 I/O 등을 점검하여 병목 지점 확인
• 데이터베이스 성능 개선: 데이터베이스 쿼리 최적화, 인덱싱 등을 통해 데이터베이스 성능을 개선
• 애플리케이션 코드 분석: 애플리케이션 코드의 성능 저하 요인을 분석하고 개선
• 네트워크 점검: 네트워크 지연이나 대역폭 문제를 점검

참고자료

• https://loadforge.com/directory
• https://engineering-skcc.github.io/performancetest/Performance-Testing-Terminologies/
• https://dewble.tistory.com/entry/concept-of-performance-test
• https://bcho.tistory.com/1369

해당 과정을 진행하기에 DS220+의 기본 2GB 메모리는 너무 작다. 필자는 추가 메모리 16GB를 증량하여 총 18GB의 메모리로 운용중이다. 시놀로지 NAS의 메모리 증량은 아래 글 참고 '참고 글' (필자는 다양한 램을 시도하여 보았으나 2R 로 시작하는 램만 성공하였다)

목차

1. 젠킨스란?
2. 왜 젠킨스를 사용하는가
3. 젠킨스 설치
4. 젠킨스 설정
5. 젠킨스 작업 생성 및 설정
6. 젠킨스 파이프라인 작성
7. 배포 자동화

1. 젠킨스 란?

Jenkins란 소프트웨어 개발 시 CI/CD를 제공하는 툴이다. CI/CD(Continuous Integration/Continuous Deployment)는 소프트웨어의 지속적 통합 / 지속적 배포를 말하는데, 이 과정을 자동적으로 진행해준다.

젠킨스의 특징은 아래와 같다.

• JRE(Java Runtime Environment)에서 동작
• 각종 플러그인을 통해 자동화 처리 가능
• 웹 UI를 지원하여 사용 편리
• 파이프라인(선언적 / 스크립트)를 이용하여 복잡한 빌드 및 배포 단계를 정의 및 자동화 할 수 있음

2. 왜 젠킨스를 사용하는가?

GitHub Actions 를 비롯한 많은 CI/CD 툴이 존재하지만, 젠킨스를 선택한 이유는 아래와 같다.

1. 다양한 플러그인 생태계

• 젠킨스는 수많은 플러그인을 지원하여 다양한 기술, 다양한 플랫폼과의 연결을 지원한다.
• 따라서 넓은 확장성을 갖는다.
• 2. 높은 유연성, 사용자 정의 가능성*
• 다양한 파이프라인 기능을 통해 복잡한 빌드 단계를 자유롭게 정의하고 자동화 가능하다.
• Groovy 스크립트를 사용하여 다양한 빌드, 배포 단계의 사용자 정의가 가능하다.
• 3. 수많은 사용자*
• 많은 사용자를 보유하고 있어, 레퍼런스가 많고 활성화된 커뮤니티의 도움을 받을 수 있다.

위와같은 사유로 CI/CD 툴로 Jenkins를 선택하게 되었다.

3. 젠킨스 설치

시놀로지 나스의 Docker 컨테이너를 관리하는 프로그램인 Container Manager가 설정되어있다는 가정 하에 진행한다.

UI를 통한 Jenkins 설치는 아래 글을 참고하자. UI를 통한 Jenkins 설치

3.1. 터미널 연결

시놀로지에서 지원하는 UI툴을 통해 설치해도 되지만, 편리한 명령어 사용을 위해 Putty를 통해 NAS에 접속한다.

Synology NAS의 제어판 > 터미널 및 SNMP > 터미널의 SSH 서비스 활성화를 통해 접속을 활성화할 수 있다.

3.2. Docker 명령어 통해 Jenkins 설치

docker run -itd --name jenkins -p 9090:8080 jenkins/jenkins:lts

위 명령어를 통해 도커에 Jenkins를 최신 버전으로 설치 한다. 포트 설정은 개인에 맞게 하면 된다.

docker ps

설치 후 위 명령어를 통해 젠킨스가 작동하는 지 확인해준다. 아래처럼 Jenkins 컨테이너가 뜬다면 성공이다.

3.3. 네트워크 설정

NAS 내부에서는 Jenkins에 접근이 가능하지만, 외부 환경에서 젠킨스에 접속하려면 포트 설정이 필요하다.

제어판 > 외부 엑세스 > 라우터 구성 > 생성 에서 내장 응용 프로그램 선택 후 'Docker Jenkins' 를 찾아서 활성화 해준다. (보이지 않으면 사용자 지정 포트에서 설정해줘도 괜찮다)

포트 개방시 아래와 같이 젠킨스 포트가 활성화 된것이 보인다. (보안 사유로 가린 것이 많은 것을 양해 바란다)

추가로 외부 접속까지 허용할 필요가 있다면 공유기 등의 포트 포워딩 설정을 진행한다.

4. 젠킨스 설정

NAS의 외부 접속 IP 혹은 내부 IP를 통해 젠킨스에 접속한다. 나의 경우 내부 접속 IP가 192.168.0.3 인 관계로 192.168.0.3:9090 으로 접속해주면 됐다.

접속하면 젠킨스 초기 비밀번호를 입력하여 Unlock 하라는 페이지가 뜬다.

위에서 접속했던 대로 NAS에 SSH 접속을 통해 접속한 후, 설치한 젠킨스 컨테이너 내부에 접속해야 한다.

아래 명령어를 통해 젠킨스 컨테이너에 접속 후

docker exec -it jenkins /bin/bash

아래 명령어로 initialPassword를 얻는다

cat /var/jenkins_home/secrets/initialAdminPassword

패스워드를 입력하면 플러그인 설치 화면이 뜬다. 좌측의 추천 플러그인 설치를 선택했다.

캡쳐하지 못했으나, 각종 플러그인을 설치하는 화면이 뜨고 (DS220+ 기준 20분 가량 소요되었다), 어드민 계정을 생성하는 화면이 뜬다.

해당 단계를 완료하면 젠킨스 접속이 완료된다.

위 단계로 초기 설정을 마쳤다

5. 젠킨스 작업 생성 및 설정

5.1. 작업 생성

젠킨스 메인 화면에서 새로운 작업을 선택 한다.

위 화면에서 아이템 명을 입력한 후 아래에서 Pipeline을 선택한다.

5.2. 작업 설정

• General 설정 GitHub Project를 선택해 깃허브 레포지토리의 URL을 넣어주고, 아래 GitHub hook trigger for GITScm Polling을 활성화 해 웹훅을 통해 푸시 된 신호를 받도록 한다

• Advanced Project Option 필요 시 작성하도록 한다.

• Pipeline Definition에서 Pipeline script from SCM을 선택한 후 SCM 에 Git을 선택한다.

Repository URL을 마찬가지로 깃허브 레포지토리 URL을 채워넣고 Credentials는 해당되는 경우 작성한다.

Branches to build는 푸시를 감지하고 빌드할 브랜치를 선택한다. 기본은 */master로 되어있는데, 깃허브 정책 변경에 따라 기본 브랜치가 main으로 바뀐지 꽤 지났으므로 */main으로 수정해준다.

마지막으로 Script Path는 JenkinsFile이 위치할 경로를 작성해준다. 필자의 프로젝트는 최상위 경로에 위치할 예정이라 파일명인 Jenkinsfile로만 작성해둔다

위와같이 실행하면 파이프라인 아이템 생성이 완료된다.

5.3. 환경변수 설정

각 아이템에서 빌드 및 실행시에 사용할 환경변수를 설정해 줄 필요가 있다. GitHub에 올린 코드를 가져오기 때문에, Secret 값들은 환경변수 처리후 Jenkins에서 빌드 시에 삽입해주는 것이다.

젠킨스 관리(설정) > Security > Credential 메뉴 진입

아래와 같이 저장소가 보인다.

(global) 부분을 눌러서 진입 후 우 상단의 +Add Credentials 선택

kind에서 Secret text 선택 ID에는 환경변수 명을, Secret에 값을 넣는다.

필요시 Description을 작성한다.

Create를 누르면 저장 완료된다.

위 과정을 반복해 필요한 환경변수를 모두 작성해준다.

5.4. 깃허브 웹훅 설정

깃허브에서 푸시 될 때마다 젠킨스에 알려주도록 웹 훅 설정이 필요하다.

깃허브 > 해당 레포지토리 > Setting > Webhooks에 접속 후

Payload URL은 외부에서 접속 가능한 Jenkins URL + /github-webhook/

Contents type 은 application/json

나머지는 아래와 같이 선택 후 생성한다

기본적인 설정은 모두 완료되었다.

6. 젠킨스 파이프라인 작성

젠킨스 파이프라인 코드를 작성하는데에는

1) Web UI 를 통해서 직접 스크립트 작성 2) SCM 통해서 Jenkinsfile에 스크립트 작성 등의 방식이 있다고 한다.

우리는 2번 방식을 선택하였기에, 레포지토리에 Jenkinsfile을 작성해줘야한다.

6.1. 선언적, 스크립트 파이프라인

Jenkinsfile의 파이프라인을 작성하는데에는 역시 두가지 방식이 있는데

1) Declarative Pipline 2) Scripted Pipeline 이렇게 두가지 방식이 있다고 한다.

각 방식의 장단점을 간단히 살펴보자면 1. 선언적 파이프라인 장점

• 구문이 단순하고 직관적이라 낮은 러닝커브
• 높은 코드 가독성
• 단점*
• 구문과 구조의 제약으로 복잡한 워크플로우 작성 어려움

2. 스크립트 파이프라이 장점

• 높은 유연성과 복잡한 워크플로우 구현 가능
• Groovy 언어의 강력한 기능 사용 가능
• 단점*
• Groovy 언어에 대한 높은 러닝커브

따라서 필자는 복잡한 워크플로우를 구현할 필요는 없기때문에 선언적 파이프라인으로 구현하였다.

6.2. 선언적 파이프라인 구조

Jenkinsfile (Declarative Pipeline)
pipeline {
    agent any 
    stages {

          #빌드단계를 정의
        stage('Build') { 
            steps {
                // 
            }
        }

        #테스트 단계를 정의
        stage('Test') { 
            steps {
                // 
            }
        }

        #배포 단계를 정의
        stage('Deploy') { 
            steps {
                // 
            }
        }
    }
}

pipeline

• 파이프라인은 CD(지속적 배포) 파이프라인의 사용자 정의 모델
• 파이프라인 코드는 애플리케이션 빌드, 테스트, 배포 단계를 포함하는 전체 빌드 프로세스를 정의

Stage

• stage블록은 전체 파이프라인에서 개념적으로 구별되는 작업의 하위집합 ('빌드', '테스트', '배포')을 정의하는 블록

Step

• 단일 작업
• 특정 시점에 Jenkins에 무엇을 해야할지 알려주는 역할

6.3. pipeline 코드

6.3.1 environment

환경변수 값을 설정해주는 부분의 블럭이다. 서비스 명, 이미지 명, 각종 포트 및 환경변수를 설정해준다. 단순 선언부이다.

environment {
        SERVICE_NAME = 'cranebackend_v2'
        IMAGE_TAG = "cranebackend_v2:latest"
        LOCAL_PORT = "8900"
        // ✅ 환경 변수 설정
        JWT_SECRET = credentials('JWT_SECRET')
        REDIS_HOST = credentials('REDIS_HOST')
        REDIS_PORT = credentials('REDIS_PORT')
        MYSQL_URL_V2 = credentials('MYSQL_URL_V2')
        MYSQL_USER = credentials('MYSQL_USER')
        MYSQL_PASSWORD = credentials('MYSQL_PASSWORD')

        TZ = "Asia/Seoul"
        SLACK_CHANNEL = "build-deploy"
        SLACK_SUCCESS_COLOR = "#2C953C"
        SLACK_FAIL_COLOR = "#FF3232"
        SLACK_MESSAGE_UNIT = "=================================================="
        SLACK_DURATION_TIME_MESSAGE = ""
        SLACK_MESSAGE_BUILDER = ""
    }
    //슬랙 알림 부분은 무시하자

6.3.2. Check Changes stage

github 코드를 가져와 변경사항이 있는지 감지하는 부분이다. 변경사항이 없는 경우 error를 발생시켜 단계를 중단시킨다.

    stage('Check Changes') {
            steps {
                script {
                    def changes = sh(script: "git diff --name-only HEAD^", returnStdout: true).trim()

                    if (!changes) {
                        currentBuild.result = 'NOT_BUILT'
                        error('No changes in cranebackend_v2 directory, skipping build')
                    }
                    echo "✅ cranebackend_v2 변경 사항 감지됨. 빌드를 진행합니다."
                }
            }
        }

6.3.3. Checkout stage

레포지토리의 브랜치를 checkout 해오는 스테이지이다. 가장 최근 커밋을 가져오게 되어있다.

stage('Checkout') {
            steps {
                git branch: 'main',
                    url: 'https://github.com/CraneWebProject/Crane_web_backend_v2'

                script {
                    def gitCommit = sh(script: 'git rev-parse HEAD', returnStdout: true).trim()
                    echo "✅ 현재 빌드하는 커밋: ${gitCommit}"
                }
            }
            post {
                failure {
                    slackSend (
                        channel: SLACK_CHANNEL,
                        color: SLACK_FAIL_COLOR,
                        message: "${SLACK_MESSAGE_BUILDER}" + stageFailSlackMessage("Git Checkout") + "${SLACK_MESSAGE_UNIT}"
                    )
                }
            }
        }

6.3.4. Build stage

shell script를 실행시켜 빌드를 진행하는 단계. 빌드 실패 시 슬랙 메시지를 보내는 부분이 있다. 슬랙 세팅을 해주지 않았다면 제외해도 된다.

stage('Build') {
            steps {
                script{
                    long startTime = new Date().getTime()
                    sh '''
                        chmod +x gradlew
                        ./gradlew clean build -x test
                    '''
                    long endTime = new Date().getTime()
                    SLACK_DURATION_TIME_MESSAGE = getStageDurationMessage(startTime, endTime)
                    SLACK_MESSAGE_BUILDER += ":white_check_mark: Build 성공! (${SLACK_DURATION_TIME_MESSAGE}) \n"
                }

            }
            post {
                success {
                    echo "✅ Build 단계 완료"
                }
                failure {
                    error "❌ Build 단계 실패"
                    slackSend (
                        channel: SLACK_CHANNEL,
                        color: SLACK_FAIL_COLOR,
                        message: "${SLACK_MESSAGE_BUILDER}" + stageFailSlackMessage("Build") + "${SLACK_MESSAGE_UNIT}"
                    )
                }
            }
        }

6.3.5. Docker build and Run Stage

도커 컨테이너를 빌드하고 기존 컨테이너 삭제 후, 새로운 컨테이너를 실행하는 단계이다. 위 단계를 실행하기 위해서는 프로젝트에 알맞는 Dockerfile이 필요하다.

환경변수는 빌드시, 실행시 모두 필요하기때문에 모두 작성해서 넣어준다.

stage('Docker Build & Run') {
            steps {
                script {
                    long startTime = new Date().getTime()

                    sh '''
                    echo "🔍 현재 REDIS_HOST 값: $REDIS_HOST"
                    echo "🔍 현재 REDIS_PORT 값: $REDIS_PORT"

                    docker build -t $IMAGE_TAG \
                        --build-arg TZ=$TZ \
                        --build-arg JWT_SECRET=$JWT_SECRET \
                        --build-arg REDIS_HOST=$REDIS_HOST \
                        --build-arg REDIS_PORT=$REDIS_PORT \
                        --build-arg MYSQL_URL_V2=$MYSQL_URL_V2 \
                        --build-arg MYSQL_USER=$MYSQL_USER \
                        --build-arg MYSQL_PASSWORD=$MYSQL_PASSWORD \
                        .

                    # 기존 컨테이너 종료 후 삭제
                    docker stop $SERVICE_NAME || true
                    docker rm $SERVICE_NAME || true

                    # 새 컨테이너 실행
                    docker run -d --name $SERVICE_NAME \
                        -e TZ=$TZ \
                        -e JWT_SECRET=$JWT_SECRET \
                        -e REDIS_HOST=$REDIS_HOST \
                        -e REDIS_PORT=$REDIS_PORT \
                        -e MYSQL_URL_V2=$MYSQL_URL_V2 \
                        -e MYSQL_USER=$MYSQL_USER \
                        -e MYSQL_PASSWORD=$MYSQL_PASSWORD \
                        -p $LOCAL_PORT:8900 $IMAGE_TAG
                    '''

                    long endTime = new Date().getTime()
                    SLACK_DURATION_TIME_MESSAGE = getStageDurationMessage(startTime, endTime)
                    SLACK_MESSAGE_BUILDER += ":white_check_mark: Deploy 성공 (${SLACK_DURATION_TIME_MESSAGE}) \n"
                    SLACK_MESSAGE_BUILDER += ":tada: `${env.JOB_NAME}` 배포 파이프라인이 성공적으로 완료되었습니다. :beer:\n" + "${env.SLACK_MESSAGE_UNIT}"
                }
            }
        }

6.3.6. post 단계

성공 및 실패 결과를 슬랙 메시지로 전송하는 단계이다. 상술하였듯, 슬랙 세팅을 원하지 않는경우 제외하면 된다.

post {
        success {

            echo """
            ===========================================
            ✅ Pipeline Successfully Completed
            Service: ${SERVICE_NAME}
            Image: ${IMAGE_TAG}
            Port: ${LOCAL_PORT}
            ===========================================
            """

            slackSend (
                channel: SLACK_CHANNEL,
                color: SLACK_SUCCESS_COLOR,
                message: SLACK_MESSAGE_BUILDER
            )
        }
        failure {
            echo """
            ===========================================
            ❌ Pipeline Failed
            Service: ${SERVICE_NAME}
            Stage: ${currentBuild.result}
            ===========================================
            """

             slackSend (
                channel: SLACK_CHANNEL,
                color: SLACK_FAIL_COLOR,
                message: "${SLACK_MESSAGE_BUILDER}" + stageFailSlackMessage("Deploy") + "${SLACK_MESSAGE_UNIT}"
            )
        }
        always {
            cleanWs()
        }
    }

6.3.7. 각종 메서드

// Stage 경과 시간을 계산하여 메시지를 생성하는 함수
def getStageDurationMessage(long startTime, long endTime) {
    long durationMillis = endTime - startTime

    long durationSeconds = (long) (durationMillis / 1000) % 60
    long durationMinutes = (long) (durationMillis / (1000 * 60)) % 60

    def durationMessage = ""
    if (durationMinutes > 0) {
        durationMessage += "${durationMinutes}분 "
    }
    durationMessage += "${durationSeconds}초"

    return durationMessage
}


// 슬랙 실패 메세지를 생성하는 함수
def stageFailSlackMessage(stageName) {
    return ":alert: ${stageName} 단계에서 배포가 실패하였습니다. \n"
}

6.4. Dockerfile

참고를 위해 덧붙인다. 각 프로젝트에 알맞은 Dockerfile을 작성한다.

#dockerfile
FROM openjdk:17
WORKDIR /app

#환경변수 정의
ARG JWT_SECRET
ARG MYSQL_PASSWORD
ARG MYSQL_URL_V2
ARG MYSQL_USER
ARG REDIS_HOST
ARG REDIS_PORT

# 환경변수 설정
ENV JWT_SECRET=${JWT_SECRET}
ENV MYSQL_PASSWORD=${MYSQL_PASSWORD}
ENV MYSQL_URL_V2=${MYSQL_URL_V2}
ENV MYSQL_USER=${MYSQL_USER}
ENV REDIS_HOST=${REDIS_HOST}
ENV REDIS_PORT=${REDIS_PORT}

COPY build/libs/CraneWebBackend_v2-0.0.1-SNAPSHOT.jar app.jar

EXPOSE 8900

ENTRYPOINT ["java", "-jar", "app.jar"]

7. 배포 자동화

위 과정을 모두 마치면, 설정해둔 레포지토리의 해당 브랜치에 커밋이 될때마다 자동으로 감지하여 빌드가 실행된다.

생성된 아이템들의 빌드 상태는 아래와 같이 젠킨스 메인에서 한눈에 볼 수 있다.

생성된 도커 컨테이너는 SSH 접속을 통해 docker ps 명령어나, 아래와 같이 시놀로지 웹의 Container Manager를 통해 조회할 수 있다.

8. 참고 자료

• 젠킨스 공식문서
• https://velog.io/@bbkyoo/Jenkins
• https://code00.tistory.com/123
• https://velog.io/@revelation/Jenkins-pipeline-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0
• https://seongwon.dev/DevOps/20220715-CICD%EA%B5%AC%EC%B6%95%EA%B8%B01/

Entity 코드를 작성하던 도중 엔티티 생성 시 기본 값에 대한 고민이 발생 해 공부 해 본 부분을 정리해 본다.

목차

0. 들어가며
1. 개념 및 배경 지식
2. 각 방식의 비교
3. 두 방식 모두 작동하는 이유
4. 각 방식의 장단점
5. 추천하는 방식
6. 결론

0. 🤔들어가며

스프링 부트에서 Java를 사용하여 Entity를 생성할 때에는 아래와 같은 코드를 사용한다.

@Getter
@NoArgsConstructor
@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long userId;

    @Column(nullable = false)
    private String email;

    @Column(nullable = false)
    private String password;

    //각종 필드 및 메서드 생략
}

위 코드에서 특히 ID 부분에 집중해보자.

JAVA Entity를 생성할 때에는 위와 같은 방식으로 NULL 값 혹은 0L 값을 ID의 초기 값으로 넣어 생성해 왔다.

허나, 코틀린은 Null이 가능한 Type을 완전히 다르게 취급하여 Null 안정성을 강조한다.

코틀린은 Null 처리를 명확하게 하기 위해 Null이 가능한 값과 불가능한 값의 타입을 다르게 정의한다. 즉 위 코드를 코틀린으로 작성했을 때 기본 값이 Null인지, 0L인지에 따라 아래와 같이 타입이 달라지는 것이다.

//1번 방식 (초기 값이 Null)
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val boardId: Long? = null

//2번 방식 (초기 값이 0L)
1. @Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val boardId: Long = 0L,

🤔그럼 어떤 방식이 맞는가

0L을 기본값으로 두어 Null을 피하는게 안정적인 방식일까? Null을 기본 값으로 두어 현실의 객체 모델링 방식을 반영하는 것이 맞을까?

코드를 작성하다 위 두 방식 중 어떤 방식이 좋은지 고민이 되어 공부해 보려 한다.

1. 개념 및 배경지식

JPA 관련 배경지식

DB 자동증가 기능 활용

ID 부분에는 @GeneratedValue(strategy = GenerationType.IDENTITY) 전략을 사용하여 ID 생성을 자동증가 하도록 DB에 위임하는 방식이다.

JPA는 ID 생성 시 관여X

JPA는 엔티티를 영속화 할 때 별도의 값을 생성하거나, 전달하지 않는다. DB에 새로운 레코드 삽입을 요청할 뿐이다.

DB는 ID 생성 후 JPA에 반환

위 코드에 따르면 자동 증가된 ID를 생성하여 레코드에 삽입하고 해당 값을 JPA에 알려준다.

JPA는 반환받은 ID로 엔티티 업데이트

JPA는 DB로 부터 받은 ID 값으로 엔티티의 ID 필드를 업데이트 한다. 이 시점에서 엔티티는 영속 상태가 되는 것이다.

Kotlin 관련 배경지식

null이 될수 있는 type

코틀린은 type에 ?를 붙임으로서 null이 가능한 변수임을 명시적으로 표현한다.

2. 각 방식의 비교

2.1. Nullable Type 사용

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
var boardId: Long? = null

• boardId를 nullable 타입(Long?)으로 선언
• 엔티티가 처음 생성될 때 Null 상태로 두다가 DB에 저장되면 자동으로 ID가 할당됨

2.2. 0L 방식 사용

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
var boardId: Long = 0L

• boardId를 non-nullable 타입(Long)으로 선언하고 기본값으로 0L을 할당
• DB에 저장되면 자동으로 ID가 할당되지만, 엔티티 생성 시 기본값 0L로 초기화됨

3. 두 방식 모두 작동하는 이유

3.1. 개념적 설명

배경 지식에서 설명하였듯, @GeneratedValue(strategy = GenerationType.IDENTITY) 전략은 ID 생성을 전적으로 DB에 위임하는 방식이다. 어떤 방식으로 초기 값이 설정 되던간에, JPA는 해당 값을 쿼리에 포함하지 않고, DB에도 전달하지 않는다.

아래 표는 Chat GPT에게 도움을 받아본 Hibernate 내부 처리 및 DB 별 처리 방식이다.

nullable(Long? = null) 인 경우

• 자동으로 null을 감지하여 ID를 할당.
• JPA는 null 을 기본키가 없는 상태로 판단.
• Hibernate에서 새 엔티티로 판단하여 DB에 Insert(AutoIncreament) 사용 (표 참고)

non-nullable(Long = 0) 인 경우

• 자동으로 0L을 더미 값으로 감지하여 ID를 할당한다.
• 0L은 Jpa 구현체 (Hibernate)에서 내부적으로 특별 처리 되어 'ID가 없음을 의미'하도록 동작한다.
• Hibernate에서 새 엔티티로 판단하지만 0L이라는 ID 필드의 값을 삽입하려 시도. (즉, 신규 엔티티이지만, 0L이라는 유효한 ID 값을 갖고있다고 판단 함)

3.2. 코드 분석

위 내용을 코드를 기반으로 분석해보자

spring Data JPA의 save() 메서드

@Transactional
    public <S extends T> S save(S entity) {
        Assert.notNull(entity, "Entity must not be null");
        if (this.entityInformation.isNew(entity)) {
            this.entityManager.persist(entity);
            return entity;
        } else {
            return (S)this.entityManager.merge(entity);
        }
    }

• isNew() 메서드를 통해서 새로운 엔티티이면 persist()를 호출하여 저장하고, 그렇지 않으면 merge()를 호출하여 기존 값을 업데이트 한다.

isNew() 메서드

 public boolean isNew(T entity) {
        ID id = (ID)this.getId(entity);
        Class<ID> idType = this.getIdType();
        if (!idType.isPrimitive()) {
            return id == null;
        } else if (id instanceof Number) {
            return ((Number)id).longValue() == 0L;
        } else {
            throw new IllegalArgumentException(String.format("Unsupported primitive id type %s", idType));
        }
    }

• entity의 ID가 Null이면 true를 반환한다
• entity의 ID가 숫자형 0L이면 true를 반환한다.

따라서 초기 값이 0L이든 Null이든 잘 작동하는 것을 알 수 있다.

4. 각 방식의 장단점

4.1. Nullable 방식

장점

엔티티 생명주기 명확화

• null 값을 통해 엔티티의 생명주기 (영속화 이전 / 이후) 구분이 코드 레벨에서도 명확하다.
• 영속화 된 후에야 비로소 ID가 부여되는 방식
• 현실의 객체 모델링 방식을 그대로 반영한다.
• ID 값을 DB에서 생성한다는 IDENTITY 전략의 의도를 명확히 표현할 수 있다.

NullSafety 극대화 및 안정성 확보

• 코틀린의 강력한 Null safety 기능을 활용하여 NPE(Null Pointer Exception)을 원천 차단할 수 있다.
• ID가 Null일 수 있음을 항상 고려하고 코딩하며 런타임 오류를 예방한다.
• 다양한 Null safety 연산자(?., !!. ?:)를 사용해 null 처리를 간결하게 할 수 있다.

단점

번거로운 Nullable 필드 처리

• 코틀린의 Nullable 필드는 null 가능성을 항상 염두에 두고 코드를 작성해야하기에 번거로움이 발생할 수 있음 (코틀린의 Nullsafety 기능을 사용하여 안전한 코드를 작성할 수 있도록 하는 실질적 장점이 될 수 있음.)

4.2. Non-Nullable 방식

장점

Null check 회피 가능

• ID에 Null 값이 들어가지 않기 때문에 Nullcheck 필요성이 없음. (다만 영속화 되지 않은 엔티티 Id 필드에 더미 값을 넣은 것과 같아 의미 왜곡의 여지가 있어 실질적 단점일 수 있음)

단점

의미 없는 0L 값으로 오류 및 혼란 야기

• 할당되지 않은 ID에 0L이라는 더미 값을 넣어 의미를 왜곡 할 수 있음.
• 영속화 이전 / 이후를 혼동하게 만들 수 있음
• DB별 0L에 대한 처리 차이로 혼동 및 오류 발생 가능 (e.g. PostgreSQLDB는 ID값이 0 부터 A.I.)

5. 추천하는 방식

Nullable 방식을 선택하기로 결정

1. Kotlin의 null safety기능 활용 가능
2. 객체 지향 설계 원칙에 부합
3. 의미론적, 상태적 명확성 확보 (영속, 비영속 상태 비교 가능)

위 근거를 바탕으로 Nullable 한 아래 방식을 선택하기로 하였다.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val boardId: Long? = nul

6. 결론

코틀린은 NullSafe를 중시 하기때문에, Null 값을 회피하는 것이 더 안전할 것이라 생각하였으나, Null값이 있을 수 있는 부분은 Nullable하게 두고, Null 처리를 명확하게 하는 것이 오히려 안전한 방식임을 알게 되었다.

내부 동작에서 JPA는 Null 과 0L 모두 새 객체로 인식하지만, 0L의 경우 DB에 값을 insert 할 위험이 있으며 이후 DB에 따라 오류가 발생할 여지도 있다.

Nullable 한 방식은 안정적이고 잘 설계되었고, 유지보수가 용이한 코드임을 확인할 수 있었다.

따라서 해당 방식을 선택하고자 한다

위 글은 제가 공부하면서 얻은 정보들을 정리한 글입니다. 오타, 잘못된 개념 등에 대해 지적해 주시면 제게 많은 배움이 있을 것 같습니다. 감사합니다

7. 참고 자료

https://ittrue.tistory.com/482

목차

0. 들어가며
1. QueryDSL이란?
2. 개념 및 배경지식
3. 필요성 및 장단점
4. 적용 방법
5. 코드 작성 방법
6. 최적화 방법
7. 결론

0. 들어가며

현재 진행중인 프로젝트에서는 JPQL을 사용하여 레포지토리 단 코드를 작성하고 있었다. 다만 쿼리가 길어지고 많아지며 불편함을 느끼고 개발에 어려움이 많아지게 된다. 이때, QueryDSL을 사용해보라는 피드백을 받아 학습하게 되었다.

1. QueryDSL이란?

Querydsl is a framework which enables the construction of type-safe SQL-like queries for multiple backends including JPA, MongoDB and SQL in Java. (QueryDSL Github) Querydsl은 Java에서 JPA, MongoDB, SQL을 포함한 여러 백엔드에 대해 타입 안전한 SQL 유사 쿼리를 구성할 수 있게 해주는 프레임워크입니다.

QueryDSL은 JPQL(Java Persistence Query Language)를 사용해 쿼리를 작성하는데에 도움을 주는 프레임워크이다. JPQL은 SQL과 유사하지만, DB 테이블이 아닌 엔티티 객체를 대상으로 쿼리를 작성한다. QueryDSL은 이 JPQL 쿼리를 타입세이프 할 뿐만 아니라, 다양한 편의성과 이점을 갖고 사용할 수 있도록 해준다.

2. 개념 및 배경지식

JPQL의 한계

JPQL은 SQL과 유사한 문법의 쿼리를 작성하게 된다. 하지만 다음과같이 문자열 형태로 쿼리를 작성하게 된다.

@Query("SELECT r FROM Reservation r WHERE r.reservationStartAt >= :startOfDay AND r.reservationStartAt < :startOfNextDay AND r.contentsId = :contentsId")
List<Reservation> findAllByResDateAndContentsId(
    @Param("startOfDay") LocalDateTime startOfDay,
    @Param("startOfNextDay") LocalDateTime startOfNextDay,
    @Param("contentsId") Long contentsId
);

위와 같이 String으로 쿼리를 작성하게 되면 다음과같은 단점이 있다

• 런타임 시점에 오류 확인 가능: 컴파일 시점에 문법 오류를 검출할 수 없다.
• 쿼리 가독성 저하: 복잡한 쿼리를 문자열로 작성하여 가독성이 떨어진다.
• 코드 자동완성 사용 불가: IDE 에서 문자열 내에 쿼리문을 작성하기 때문에, 자동완성 기능의 도움을 받는 데에 한계가 있다.

QueryDSL의 등장

위와 같은 JPQL 코드의 단점을 해결하기 위해 QueryDSL이 등장하게 된다. QueryDSL은 쿼리를 메서드 호출 형식으로 작성할 수 있게된다.

3. 필요성 및 장단점

아래와 같은 필요성으로 프로젝트에 QueryDSL을 도입하기로 하였다.

필요성

• 타입 세이프: 쿼리 작성 시 타입 오류를 방지하여 애플리케이션 런타임 안정성을 높인다.
• 생산성 향상: 쿼리 작성시간을 단축하고 생산성을 높인다.
• 유지보수 용이성: 복잡한 쿼리를 모듈화하여 코드 유지보수를 용이하게 한다. 뿐만 아니라 현재는 MySQL만 사용중인 프로젝트이지만, 서비스 확장 시 추가 DB 사용 계획이 있는만큼, 다양한 DB를 지원하는 점도 사용 근거중 하나이다.

장점

• 컴파일 시점 오류 검출: 쿼리 문법 오류를 컴파일 시점에 검출 가능하다.
• 코드 재사용성: 자주 사용되는 쿼리를 메서드로 만들어 재사용 가능하다.
• 쿼리 가독성 향상: 복잡한 쿼리를 메서드 호출 형태로 표현하여 가독성을 높일 수 있다.

단점

• 학습 곡선: QueryDSL API를 익히는데는 추가적인 학습이 약간 필요하다.
• 쿼리 성능: JPQL쿼리와 비교시, QueryDSL의 성능이 항상 더 좋지는 않다. (추후 직접적인 성능 비교를 해보고자 한다)

4. 적용방법

프로젝트 환경은 아래와 같다.

• JAVA 17
• Spring boot 3.3.4
• QueryDSL 5.0.0

4.1. 의존성 추가

build.gradle 파일 내에 QueryDSL 의존성을 추가한다.

// Query DSL 관련 스크립트 및 설정
buildscript {
    ext {
        queryDslVersion = "5.0.0"
    }
}

plugins {
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
}

dependencies {
    //QueryDSL 관련 라이브러리
    implementation "com.querydsl:querydsl-jpa:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
    implementation "com.querydsl:querydsl-core"
    implementation "com.querydsl:querydsl-collections"
    annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
    // querydsl JPAAnnotationProcessor 사용 지정
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    // java.lang.NoClassDefFoundError (javax.annotation.Generated) 대응 코드
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"
    // java.lang.NoClassDefFoundError (javax.annotation.Entity) 대응 코드
}

def querydslDir = 'build/generated/querydslDir'

querydsl {
    jpa = true
    querydslSourcesDir = querydslDir}

sourceSets {
    main.java.srcDir querydslDir
}

compileQuerydsl {
    options.annotationProcessorPath = configurations.querydsl
}

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
    querydsl.extendsFrom compileClasspath
}

만약 스프링 부트 버전이 2.X. 버전이라면 빌드시, 아래와 같은 에러가 발생하게 된다.

Unable to load class 'javax.persistence.Entity'.

다음 링크를 참고하여 버전에 맞는 build.gradle 파일을 작성하도록 하자. [QueryDSL][Spring] Unable to load class 'javax.persistence.Entity' 에러 해결 방법

4.2. gradle reload 실행

gradle reload를 실행한다.

4.3. Q-Type 클래스 생성

QueryDSL은 엔티티 클래스를 기반으로 Q-Type 클래스를 생성한다. 이는 쿼리 작성시 엔티티 속성을 참조하는데 사용되기 때문에, QueryDSL 사용에 필수이다. 아래 두 방법 중 하나를 선택하여 Q-Type 클래스를 생성하도록 한다.

1. Bash Shell 사용 프로젝트 경로에서 다음 명령어를 실행한다.

   ./gradlew compileQuerydsl

2. IDE 등 내부 기능 사용 Gradle Tasks > other > compileQuerydsl를 실행

   

4.4. 클래스 생성 확인

위에서 build.gradle 파일에 정의한 경로( 위 파일에서는 build/generated/querydsl)내부에 Q 로 시작하는 클래스가 생성되었는지 확인한다.

4.5. 설정 시 발생 할 수 있는 에러

1. querydsl cannot find symbol

annotation Processor 설정이 잘못되었을 경우 발생 할 수 있는 문제이다. 원인 1) Q 클래스가 제대로 생성되지 않음. 경로를 다시 확인하고, Q 클래스를 다시 생성 해준다.

원인 2) Annotation Processor 설정을 확인 설정 > Build,Execution,Deployment > Compiler > Annotation Processor 설정에서 Enable annotation processing 설정이 활성화되어있는지 확인하고, 왼쪽에 gradle Imported로 되어있는 그룹을 화살표를 클릭해 Default 그룹으로 이동해준다.

설정 적용 후 재실행 시 문제없이 빌드 된다.

2. attempt to recreate a file for type querydsl

Q 파일을 재 생성하며 생기는 문제이다. build clean을 통해 Q 파일을 모두 제거하고 새로 build를 하였다.

이렇게 한 후에도 빌드가 제대로 되지 않는다면 빌드 환경을 Gradle에서 InteliJ로 변경 해 보는 것도 해결에 도움이 된다고 한다. (설정 > build tools -> gradle : gradle -> intellj) 참고: query dsl 파일 중복생성, 파일을 찾지 못하는오류

3. Could not find class file for 에러

위 두 에러를 해결 한 후에도 이러한 에러가 발생하는 경우가 있다. 이런 경우 build clean을 통해 생성된 Q-class를 모두 삭제하고 직접 빌드 하지 않고 바로 애플리케이션을 실행하면 실행 된다. 참고: QueryDSL - build.gradle 설정, QClass 생성하기

5. 코드 작성 방법

5.1. QueryDSL 기본 사용법

다음은 가장 기본적인 QueryDSL을 사용한 JPQL 생성 및 실행 방법이다.

QEntity entity = QEntity.entity;

jpaQueryFactory
            .select(entity) 
            .from(entity)
            .where(entity.id.eq(id))
            .fetch();

@Query 에서 String으로 사용하던 Select문, From절, Where절을 모두 메서드 호출하듯 사용한다.

1. select()

• SQL을 통해 가져올 데이터를 지정
• 클래스 접근자를 통해 특정 데이터만 가져올 수 있음(e.g. entity.name)

2. from()

• 조회 할 테이블을 지정

3. where()

• 어떤 조건으로 데이터를 검색할지 지정
• 제공 값과 동일, 범위연산, 포함 등 다양한 조건 검색
• 여러 조건을 걸 수 있으며, AND, OR연산 모두 가능

  member.username.eq("member1") // username = 'member1'   
  member.username.ne("member1") //username != 'member1'  
  member.username.eq("member1").not() // username != 'member1'
  member.username.isNotNull() //이름이 is not null   
  member.age.in(10, 20) // age in (10,20)  
  member.age.notIn(10, 20) // age not in (10, 20)   
  member.age.between(10,30) //between 10, 30
  member.age.goe(30) // age >= 30 
  member.age.gt(30) // age > 30   
  member.age.loe(30) // age <= 30 
  member.age.lt(30) // age < 30
  member.username.like("member%") //like 검색 
  member.username.contains("member") // like ‘%member%’ 검색 
  member.username.startsWith("member") //like ‘member%’ 검색

  위 코드 출처 : 스프링부트에 QueryDSL 적용기 - 2 (설치 및 사용법, Spring Data JPA와 함께 사용하기)

4. fetch()

• 쿼리를 생성하고 조회된 List를 반환하는 역할
• 조회 갯수에 따라 fetchOne(), fetch() 등 사용
• 조회 쿼리가 아닌 실행 쿼리의 경우 execute() 사용해 실행

5.2. QueryDSL 객체 생성

QueryDSL이 쿼리 생성을 할 수 있도록 EntityManager를 주입한다.

@Configuration
public class QueryDslConfig {
    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory queryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

5.3. 레포지토리 클래스 생성

기존 Reposistory 코드

기존 Repository 코드는 다음과 같다.

public interface ReservationRepository extends JpaRepository<Reservation, Long>, ReservationCustomRepository {

    @Query("SELECT r FROM Reservation r WHERE r.contentsId = :contentsId")
    List<Reservation> getReservationListByContentsId(@Param("contentsId") Long contentsId);

    @Query("SELECT r FROM Reservation r WHERE r.userId = :userId")
    List<Reservation> getReservationListByUserId(@Param("userId") Long userId);

    @Query("SELECT r FROM Reservation r WHERE r.reservationStartAt >= :startOfDay AND r.reservationStartAt < :startOfNextDay AND r.contentsId = :contentsId")
    List<Reservation> findAllByResDateAndContentsId(
            @Param("startOfDay") LocalDateTime startOfDay,
            @Param("startOfNextDay") LocalDateTime startOfNextDay,
            @Param("contentsId") Long contentsId
    );

    default Reservation findByIdOrElseThrow(Long id) {
        return findById(id).orElseThrow(() -> new ReservationNotFoundException("존재하지 않는 예약입니다."));
    }
}

JPQL의 단점대로 String으로 쿼리를 작성하면서 가독성이 낮고, 빌드 시점에 오류를 알 수 없다. 따라서 아래 방법대로 클래스를 생성하도록 하였다.

위 다이어그램 구조대로 객체를 생성하였다.

CustomRepository 클래스

인터페이스에 사용할 레포지토리 메서드를 작성한다.

public interface ReservationCustomRepository {
    List<Reservation> getReservationListByContentsId(Long contentsId);

    List<Reservation> getReservationListByUserId(Long userId);

    List<Reservation> findAllByReservationDateAndContentsId(LocalDateTime startOfDay, LocalDateTime startOfNextDay, Long contentsId);

    Reservation findByIdOrElseThrow(Long id);
}

CustomRepositoryImpl 클래스

그 후 위 인터페이스 클래스를 구현한다. 설명은 주석 및 아래에서 덧붙이겠다.

@RequiredArgsConstructor
//Spring bean으로 등록하기 위해 Repository 어노테이션 추가
@Repository 
public class ReservationCustomRepositoryImpl implements ReservationCustomRepository{

    //QueryDSL 쿼리를 생성하고 실행하는 핵심 클래스.
    private final JPAQueryFactory queryFactory;
    //Reservation 엔티티의 속성을 쿼리에서 사용하기 위해 인스턴스를 생성
    QReservation reservation = QReservation.reservation;

    @Override
    public List<Reservation> getReservationListByContentsId(Long contentsId) {

        return queryFactory
                .selectFrom(reservation)
                .where(reservation.contentsId.eq(contentsId))
                .fetch();
    }

    @Override
    public List<Reservation> getReservationListByUserId(Long userId) {

        return queryFactory
                .selectFrom(reservation)
                .where(reservation.userId.eq(userId))
                .fetch();
    }

    @Override
    public List<Reservation> findAllByReservationDateAndContentsId(
            LocalDateTime startOfDay,
            LocalDateTime startOfNextDay,
            Long contentsId
    ) {
        return queryFactory
                .selectFrom(reservation)
                .where(reservation.reservationStartAt.goe(startOfDay)
                        .and(reservation.reservationEndAt.lt(startOfNextDay))
                        .and(reservation.contentsId.eq(contentsId)))
                .fetch();

    }

    @Override
    public Reservation findByIdOrElseThrow(Long id) {
        Reservation result = queryFactory
                .select(reservation)
                .where(reservation.reservationId.eq(id))
                .fetchOne();

        if(result == null) {
            throw new ReservationNotFoundException("존재하지 않는 예약입니다.");
        }
        return result;
    }
}

6. 최적화 방법

1. 벌크 연산 update() 또는 delete()같은 벌크 연산은 JPQL을 사용하는 것이 효율적이다. QueryDSL의 벌크연산은 내부적으로 결국 JPQL로 변환하기 때문에 직접 사용하는것이 성능상 유리하다.

2. 인덱스 활용 인덱싱을 활용해 쿼리 성능을 향상시킬 수 있다

3. 쿼리 튜닝 QueryDSL의 쿼리 실행계획을 분석하고 튜닝하여 성능을 최적화 할 수 있다.

4. @Query 어노테이션과 혼용 QueryDSL은 동적 쿼리 생성에 유용하다. 다만, 복잡한 정적 쿼리는 JPQL쿼리를 직접 작성하는 것이 성능상 더 좋을 수 있다.

7. 결론

QueryDSL은 쿼리 작성을 편리하게 해주고, 가독성, 생산성 등을 높여주는 유용한 프레임워크이다. 다만 QueryDSL에 대해 자세히 알고, 상황에 따라 필요에 맞게 잘 사용하는 것이 성능적, 효율적으로 더 이득이 될 수 있다. 필요에 따라 적절한 사용을 통해 좋은 애플리케이션을 개발하도록 하자.

참고자료

• Spring Data JPA + Query DSL 사용기
• [Spring] QueryDSL 완벽 이해하기
• [Spring Boot/JPA] QueryDSL 설정과 Repository에서의 사용

지금까지의 주먹구구식 스프링 시큐리티 사용에서 벗어나고자, 스프링 시큐리티에 대해 자세하게 공부를 해보고자 합니다.

최신 버전인 스프링 시큐리티 6 버전을 기준으로 공부합니다.

Spring Security란?

스프링 프레임워크에서 인증(Authentication) 및 인가(Authorization), 권한 관리 등의 기능을 제공하는 프레임워크입니다.

스프링 시큐리티에서는 필터(Filter)와, 필터로 이루어진 필터 체인의 흐름에 따라 인증과 인가를 처리합니다.

용어 정리

• 인증(Authnetication): 보호된 리소스에 접근한 대상에 대해 누구인지 확인하는 과정
• 인가(Authorization): 해당 리소스에 대해 접근할 권한을 갖고있는지 확인하는 과정
• 권한: 특정 리소스에 대한 접근 제한. 모든 리소스는 접근에 대한 제어 권한이 걸려있음. 인가 과정에서 해당 리소스에 제한된 권한을 가졌는지 확인함.
• 접근 주체(Principal): 보호된 리소스에 접근하는 대상

Spring Security 특징

• 보안과 관련된 다양한 로직과 커스텀 옵션을 사용할 수 있어, 보안 관련 로직을 직접 작성하지 않아도 됨.
• Filter 기반 동작으로, MVC와 분리하여 관리 및 동작함.
• 어노테이션을 통한 간단한 설정
• 인증 관리자(Authentication Manager)와, 접근 결정 관리자(Access Decision Mananger)를 통해 사용자의 리소스 접근을 관리함.
• 인증 관리자는 UsernamePasswordAuthenticationFilter, 접근 결정 관리자는 FilterSecurityInterceptor가 수행함.

Spring Security 구조

• SecurityContextPersistenceFilter: SecurityContextRepository에서 SecurityContext를 로드하고 저장하는 일을 담당.
• LogoutFilter: 로그아웃 URL로 지정된 가상 URL에 대한 요청을 감시하고 매칭되는 요청이 있으면 로그아웃 시킴.
• UsernamePasswordAuthenticationFilter: Username, PW로 이루어진 폼 기반 인증에 사용하는 가상 URL 요청을 감시하고, 요청이 있으면 사용자의 인증을 진행
• DefaultLoginPageGenerating Filter: 폼 기반, Open ID 기반 인증에 사용하는 가상 URL에 대한 요청을 감시하고 로그인 폼 기능을 수행하는데 필요한 HTML을 생성함.
• BasicAuthenticationFilter: HTTP 기본 인증 헤더를 감시하고 이를 처리함.
• RequestCacheAwareFilter: 로그인 성공 이후 인증 요청에 의해 가로채어진 사용자의 원래 요청을 재 구성하는데 사용됨.
• AnonymousAuthenticationFilter: 이 필터 호출 시점가지 인증을 받지 못했다면, 인증토큰에서 사용자가 익명으로 나타남
• SessionManagementFilter: 인증된 주체를 바탕으로 세션 트래킹을 처리해 단일 주체와 관련한 모든 세션들이 트래킹 되도록 도움을 줌.
• ExceptionTranslationFilter: 보호된 요청을 처리하는동안 발생할 수 있는 예외의 기본 라우팅과 위임을 처리.
• FilterSecurityIntercptor: 권한부여와 관련한 결정을 AccessDecisionManager에게 위임해 권한부여 결정 및 접근 제어 결정을 쉽게 만들어 줌.

인증정보를 담는 객체

Principal

• 인증 주체에 대한 정보를 담고있는 객체
• Spring Security가 제공하는 인증정보의 한 부분이다.

  Authentication

• 실질적으로 인증정보를 담고있는 객체
• Principal(내가 누구인지 / 로그인 ID에 해당하는 값), Credential(인증자격 / 비밀번호에 해당하는 값), Authorities(권한정보 / ROLE에 해당하는 값)의 세 객체로 구성되어있다.

SecurityContextHolder

• 시큐리티가 최종적으로 제공하는 객체
• SecurityContextHolder는 SecurityContext객체를 Thread-local로 제공하여, 같은 Thread에서는 매개로 주고받지 않아도 인증정보에 접근이 가능하다.

Spring Security동작 과정

Spring Security는 Dispatcher Servlet으로 가기 전에 요청을 가로 채 Filter에서 인증과 인가를 처리합니다.

1. 사용자가 로그인 정보로 로그인 요청
2. AuthenticationFilter가 정보를 인터셉트하여 UsernamePasswordAuthentication Token(Authentication 객체) 생성하여 AuthenticationManager에게 Authentication 객체를 전달.
3. AuthenticationManager 인터페이스를 거쳐 AutheticationProvider에게 (2)의 정보 전달(Authentication 형태), 등록된 AuthenticationProvider를 조회하여 인증 요구
4. AuthenticationProvider는 UserDetailsService를 통해 입력받은 (3)의 사용자 정보를 DB에서 조회
   • supports() 메소드를 통해 실행 가능한지 체크
   • authenticate() 메소드를 통해 DB에 저장된 이용자의 정보와 입력한 로그인 정보 비교
     • DB 이용자 정보: UserDetailsService 의 loadUserByUsername() 메소드를 통해 불러옴
     • 입력 로그인 정보: (3)에서 받았던 Authentication 객체(UsernameAuthentication Token)
   • 일치하는 경우 Authentication 반환
5. AuthenticationManger는 Authentication 객체를 AuthenticationFilter로 전달
6. AuthenticationFilter는 전달받은 Authentication 객체를 LoginSuccessHandler로 전송하고 SecurityContextHolder에 담음
7. 성공시 AuthenticationSuccessHandle, 실패기 AuthenticationFailureHandle 실행

참고자료

• https://docs.spring.io/spring-security/reference/index.html
• https://devuna.tistory.com/55
• https://thalals.tistory.com/436
• https://velog.io/@franc/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0-%ED%9D%90%EB%A6%84%EA%B3%BC-%EA%B5%AC%EC%A1%B0

눈앞의 이익만 추구하는 알고리즘

do{
    가장 좋아보이는 선택을 한다;
} until(해 구성 완료)

그리디 알고리즘은 최종 해답에 도달하기까지, 각 단계에서 최적이라고 생각되는, 가장 좋아보이는 선택을 반복하는 알고리즘이다.

그리디 알고리즘 특징

• 지역적으로 최적인 해가, 전역적으로 최적인 해라는 보장은 없다.
• 각 단계의 선택이 다음 단계의 선택에 영향을 끼치지 않는다.

근사 알고리즘

그리디 알고리즘은 최적해를 보장하지 않는다. 하지만 지역적으로는 최적해를 매번 선택한다는 점에서 최적해에 근접한 값을 구할 수 있다.

PS에서의 그리디

최적해가 보장되지 않는 예

• 이진트리의 최적합 경로 찾기

  모든 노드를 다 탐색하지 않으면 최적해를 찾을 수 없음.

• 보따리 문제 (부피가 M인 보따리에 부피가 W_i , 가치가 P_i인물건 최대한 많이 넣기)

• 거스름돈 문제

  동전 액면이 작은 단위의 배수가 아닌 경우 최적해를 찾을 수 없음.

최적해가 보장되는 예

• 최소 신장 트리(MST)
• 회의실 시간 분배 문제 등

그래프란? 그래프는 정점과 간선을 통해 자료를 표현하는 방식이다. 정점(Vertex)은 대상 및 개체를 나타낸다. 간선(Edge)은 정점간의 관계를 나타낸다. 간선은 방향성을 가질 수 있으며, 가중치를 가질 수도 있다.

BFS, 너비우선 탐색

직관적인 이해를 위해 트리에서의 너비 우선 탐색 예시를 가져왔다. 루트를 기준으로 먼저 깊이가 1인 루트의 자식을 차례로 방문한다. 그 다음 깊이가 2인 루트의 자식의 자식을 방문한다. 위 방식으로 깊이를 늘려가며 모든 노드를 탐색하는 방식이다.

즉 루트에서 시작하여 인접한 노트를 먼저 탐색하는 방식이다.

위와같은 이유로 너비 우선 탐색(Breadth-First Search)라고 불린다.

BFS의 특징

• 재귀적으로 동작하지 않는다.
• 방문한 노드를 기록해야한다. 그렇지 않으면 무한루프에 빠질 수 있다.
• 큐(Queue)를 사용하여 탐색한다.(선입선출)
• 깊이 우선 탐색보다 구현이 복잡하다.

BFS의 탐색 과정

출처 : https://gmlwjd9405.github.io/2018/08/15/algorithm-bfs.html

BFS의 구현

• 자료구조 큐(Queue)를 이용하여 구현

PS에서의 BFS

• 최단경로 탐색
• 거리 탐색 등

참고자료

https://gmlwjd9405.github.io/2018/08/15/algorithm-bfs.html https://takeitoutamber.medium.com/binary-tree-right-side-view-bfs-87a215b6237c

그래프란?

그래프는 정점과 간선을 통해 자료를 표현하는 방식이다. 정점(Vertex)은 대상 및 개체를 나타낸다. 간선(Edge)은 정점간의 관계를 나타낸다. 간선은 방향성을 가질 수 있으며, 가중치를 가질 수도 있다.

DFS, 깊이 우선 탐색

직관적인 이해를 위해 트리를 기준으로 DFS가 설명된 이미지를 가져왔다.

DFS는 루트를 기준으로 루트의 자식 정점을 하나 방문한 다음 아래로 내려갈 수 있는 곳까지 내려간다. 더 이상 내려갈 수 없는 경우, 올라오다가 내려갈 수 있는 곳이 다시 보인다면 내려가는식으로 탐색한다.

즉 루트 노드에서 시작해 다음 분기로 넘어가기 전까지, 해당 분기를 완벽하게 탐색하는 방법 이라고 설명할 수 있다.

위와 같은 이유로 BFS(깊이 우선 탐색)이라고 불린다.

DFS의 특징

• 자기 자신을 호출하는 재귀 순한의 형태를 띔.
• 단순 검색 속도는 BFS에 비해 느림.
• 노드 방문 여부를 반드시 검사해야한다.
  • 그렇지 않으면 무한하게 노드를 순환하게 된다.

DFS의 탐색 과정

출처: https://gmlwjd9405.github.io/2018/08/14/algorithm-dfs.html

DFS의 구현

1. 재귀 호출 구현방법
2. 명시적 스택 사용: 방문 정점을 스택에 저장 후 꺼내서 작업

PS에서의 DFS

• 미로, 지도 등의 탐색
• 전체를 방문하는데 걸리는 횟수 등 유형의 문제

참고자료 https://takeitoutamber.medium.com/binary-tree-right-side-view-bfs-87a215b6237c https://gmlwjd9405.github.io/2018/08/14/algorithm-dfs.html

하나의 함수에서 자기 자신을 다시 호출해 작업을 수행하는 알고리즘

재귀는 어떤 문제를 해결하는 과정에서 자신과 똑같지만 크기가 다른 문제를 발견하고, 이들의 관계를 파악해 문제 해결에 접근하는 방식이다.

재귀 알고리즘을 사용하면, 크고 복잡한 문제가 주어졌을 때, 문제의 크기를 결과를 얻을 수 있을정도로 점진적으로 줄인 다음, 그 결과를 이용하여 더 큰 문제를 풀어내, 처음 주어진 문제를 해결할 수 있다.

귀납적 사고

재귀 문제풀이를 위해서는 절차지향적 사고가 아닌, 귀납적 사고를 통해 문제에 접근하는 것이 필요하다.

(출처 위키백과)

위 사진을 보면 N번째까지 늘어진 도미노의 모습을 볼 수 있다. 1번 도미노가 쓰러지고, N번 도미노도 쓰러지면, N+1번째 도미노도 쓰러진다 => 모든 도미노는 쓰러진다는 결론에 도달

위와 같은 접근법이 귀납적 접근법이다.

재귀함수 주의할 점

Base Condition

재귀함수는 특정 입력에 대해 자기 자신을 호출하지 않고 종료해야한다. 또한 모든 입력은 Base Condition으로 수렴해야한다.

그렇지 않을 경우 스스로를 무한히 호출하다가 런타임 에러, 스택 오버플로우가 발생하게 될 것이다.

함수를 명확하게 정의하기

재귀함수를 만들때에는 함수를 명확하게 정의해야한다.

1. 함수의 인자로 어떤 값을 받을지
2. 어디까지 계산 후 넘겨줄 것인지 위 두가지를 명확히 해야한다.

PS에서의 재귀함수

재귀함수와 반복문

모든 재귀함수는 재귀 구조 없이, 단순 반복문으로만 동일 동작을 수행하는 함수를 만들 수 있다.

• 반복문을 사용하면, 메모리와 시간적 측면에서 이득이 있다. (재귀 함수를 호출하는데에 대한 비용 감소)
• 재귀함수를 사용하면 코드가 간결해진다.

따라서 반복문으로 간단히 구현이 가능하면, 반복문으로 구현하는 것이 좋고, 코드가 너무 복잡해질 것 같은 경우, 재귀함수를 사용하여 풀이하는 것이 좋다.

문제 유형

Linked List, 이진 트리, 그래프 등의 유형을 재귀 알고리즘을 통해 풀이할 수 있다.

또한 순열, 조함 같은 경우의 수를 따지는 문제도 재귀 알고리즘이 많이 활용된다.

복잡도 분석

재귀 함수가 어떻게 호출될지 알면 재귀 알고리즘의 복잡도를 구할 수 있다.

함수 내에서 재귀호출이 일어나는 횟수를 통해 시간복잡도를 구할 수 있고, 호출 스택의 최대 깊이를 통해 공간 복잡도를 구할 수 있다.

예시

참고문헌

https://www.algodale.com/algorithms/recursion/ https://blog.encrypted.gg/943?category=773649 https://novlog.tistory.com/entry/Algorithm-%EC%9E%AC%EA%B7%80-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-Recursive-Algorithm

취준 코딩테스트 준비 겸 알고리즘 스터디를 진행하기로 했다. 혼자 진행하는 알고리즘 문제풀이는 강제성이 없어서인지 동기부여가 덜하고, 지속하기가 어려워 스터디를 모집하였다.

🙄사실은...

나는 복학 전부터 심심하면 알고리즘 문제를 풀어보아서, 잘하지는 않지만 solved.ac 기준 골드5 랭크를 기록하고 있다. 그래도 나보다 많은 알고리즘을 경험해본 사람이 스터디에 들어와서 가르쳐주면 좋겠다는 생각이 은연중에 있었다. 하지만 어쩌다보니, 알고리즘 문제풀이를 처음 해보는 후배 두명과, 조금 해본 동기 한명 총 4명이 스터디를 진행하게 되었고, 내가 리드를 맡게 되었다. 하지만, 함께 공부하는 스터디이고, 서로 공부하고 서로 알려주며 발전할 수 있는 내용이 많은 분야이기 때문에, 기초를 다시 잡는다는 생각으로 진행해보려고 한다!

진행방식

✅이 스터디에서 다룰 것

• 각 유형별 알고리즘 이론 스터디
• 각 유형별 알고리즘 풀이 (그리디, 그래프, 최단경로, 이분탐색, 분할정복, 완전탐색, 구현, 문자열 등)
• PS를 위한 입출력 등
• 다양한 플랫폼 경험
• 가능하다면 SQL 공부

❌이 스터디에서 다루지 않을 것

• 수학 (부족한 부분은 개별 공부)
• 각 언어별 문법
• 자료구조

스터디 진행

• 주 N회 스터디 진행(온라인 / 오프라인)
• 스터디 진행 시각:
• 문제풀이 사이트
  • 백준 및 프로그래머스의 문제를, 문제 유형별로 나누어 풀이한다.
  • 백준 온라인 저지 / solved.ac(백준 문제 태그 및 랭킹)
  • 프로그래머스

문제풀이 진행

• 언어는 자유 선택
• 1시간 이상 문제 풀리지 않을 경우, 타인 코드 참고(복붙 금지!)
• 문제 풀이 코드는 깃허브 레포에 푸시 / 풀리퀘 하여 깃허브 사용에 익숙해지기
• 문제 풀이 후 상호 코드리뷰

많은 분들이 이야기하고 나도 동의하는 부분이지만, 1시간 이상 풀리지 않는 문제를 무작정 잡고 있거나, 마구잡이 구현으로 풀이하는 것 보다, 모범 사례를 참고하여 구현해보고, 이를 학습하는 것이 더 낫다고 생각했다.

스터디 전 준비

• 할당 된 개념 공부 및 블로그에 정리
• 할당 된 문제 풀이(문제 수는 조율 예정)
• 풀이한 문제 코드 공유(깃허브)
• 공유된 스터디원 코드 리뷰
  • 깃허브 레포 > Pull request > file Chnaged에서 리뷰 작성

스터디

• 할당된 주제 발표 (발표자 랜덤 선정)
• 할당된 문제풀이 발표(전체 발표)
• 코드리뷰 및 좋은 코드 공유

본인의 문제풀이에 대해 설명할 수 있어야 면접등에도 대비할 수 있다고 생각해 문제풀이 발표는 전체 진행하기로 한다.

스터디 종료 후

• 다음 개념 할당
• 다음 문제 할당
• 스터디에서 다룬 주제 복습, 코드리뷰 반영 등

마무리

위와같은 방식으로 스터디를 진행해보고, 상시 피드백을 받으며 운영방식을 조금씩 수정해 갈 예정이다. 스터디가 끝날 즈음에는 모두가 많이 발전해있기를 바란다...!!