이찬진 컴퓨터 교실

[Nextjs] Sharp Missing In Production ( memory leak 이슈 )

ImNM — Sun, 21 May 2023 21:48:49 +0900

두둥서비스는 한 ec2 안에

nginx를 프록시로 활용하여

next js , redis , spring , react 어플리케이션을 도커로 띄우고 있다.

금일 오후 오후 1시 3분...

nextjs 프론트 도커이미지가 다운되어버렸다.

출시이후 3개월만에 처음 있는 일이였다.

이때 철렁했다..

3개월째 잘 굴러가던 서비스가

이렇게 다운이되니깐 매우 당황했었다.

이슈가 있었던 부분을 살펴보고 트러블슈팅한 경험을 공유하고자 한다.

에러 원인찾기 : 도커 event ,syslog

두둥 서비스는 근검절약(돈이없따 ㅠ)을 위해 ec2 micro 에 swap memory 설정으로 꽉꽉 채워서 돌아가는 서비스다.

메모리가 아예 넘치게되면 ec2 ssh 접속조차 안되는데 이번경우는 달랐다.

sudo docker ps

를 했을 때 프론트 이미지만 내려간 상황이였고,

아쉽게도

sudo docker logs -f <image-id> --tail <tail line>

명령어로도 디버깅할만한 로그가 남아있지 않은 상황이였다.

이때부터 메모리 이슈일것같은 느낌이 강하게 왔고,

sudo docker events --slice '2023-05-20'

(https://docs.docker.com/engine/reference/commandline/events/ 도커 이벤트 관련 )

위명령어로 도커에서 발행된 이벤트 로그를 살펴보았고.

oom, exitCode=129 라는 내용으로 왔다.

exitCode 의 경우 128번 까지는 도커관련한 코드고

이후 128 + n 형식으로

n은 리눅스관련 코드이다.

What is the authoritative list of Docker Run exit codes?

Apologies if this has been asked, but nowhere in the Docker documentation can I find an authoritative list of exit codes (also called exit status). Surprising! I see suggestions about making it

stackoverflow.com

cat /var/log/syslog

명령어로 syslog를 봐도 oom-killer 가 동작해서 다운되어있었다.

스왑메모리 1기가 까지 차곡차곡 다 드셨다 ㅋㅌ

이유가 뭘까 : 이미지처리

왜 메모리 oom 이 났을 까.. 생각해보면

넥스트가 ssr이고, node 런타임을 기반으로 하고 있어 생긴 문제라고 생각했다.

그중에서 가장 크게 메모리를 잡아먹는게 무엇일까 하면

이미지가 그중에 가장크게 잡아먹을것 같았다. ( 프론트에서 별다른 메모리잡아먹을 작업을 하지 않기 때문 )

공식문서가서 프로덕션 모드로 배포하는 부분을 살펴보았다.

Building Your Application: Deploying | Next.js

Using App Router Features available in /app

nextjs.org

to prevent excessive memory usage... 두둥에서는 공연 상세화면에서 이미지 사이즈의 최적화를 위해서

next/image 를 쓰고 있었고.,.

이번 참사의 원인

이것이 원인임을 알아냈다...

(프론트 배포때 이거 안하고 뭐했어..)

해결하기 : sharp install

sharp-missing-in-production | Next.js

Sharp Missing In Production The next/image component's default loader uses squoosh because it is quick to install and suitable for a development environment. For a production environment using next start, it is strongly recommended you install sharp. You a

nextjs.org

개발환경에서는 가벼운 squoosh 를 사용하고,

프로덕션환경에서는 sharp 를 사용하는데

문제는 sharp를 install 하지 않은 채로 프로덕션으로 올려

실제 배포 어플리케이션에서 squoosh를 사용하기 때문이다.

간단하게 yarn add sharp 로 처리했다.

근데 왜 squoosh가 문제일까?

Fix memory leak in image optimization by shuding · Pull Request #23565 · vercel/next.js

This RP fixes the problem that the image optimization API uses a large amount of memory, and is not correctly freed afterwards. There're multiple causes of this problem: 1. Too many WebAssembly ins...

github.com

Wasm needs a better memory management story · Issue #1397 · WebAssembly/design

Hi all, after a video call with google last week, I was encouraged to raise a conversation here around issues we at Unity have with Wasm memory allocation. The short summary is that currently Wasm ...

github.com

squoosh 는 웹어셈블리 기반으로 작성되었는데, 가장 큰문제는 할당된 메모리를 축소할 수 있는 방안이 없다고 한다..

사용자 브라우저에서 돌아가는 이미지 압축이라면, 메모리가 축소되든 말던 브라우저만 꺼지면 그렇게 큰 문제 가 없다.

문젠 node js 런타임이 서버에서 돌아간다는것이고,

node 위에서 웹 어셈블리를 통해 돌아가는 ( https://nodejs.dev/en/learn/nodejs-with-webassembly/ )

squoosh 의경우..점점 메모리만 늘어나는 꼴이라고 한다.

https://github.com/vercel/next.js/issues/20915

물론 sharp 의경우에도 메모리관련해서 문제가있지만 동시성을 낮추면서 문제를 해결했다고 한다...

( 사실 두둥 세팅이면 그럼 이미지가 하나에 한번씩 sharp 되는 꼴이다 )

성능을 제대로 확보할라면 메모리 할당자를 jemalloc 같은걸로 바꾸라고 한다.

방법은 도커이미지를 아래와 같이 하면된다.

RUN apt-get update && apt-get install --force-yes -yy \
  libjemalloc1 \
  && rm -rf /var/lib/apt/lists/*

# Change memory allocator to avoid leaks
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1

https://github.com/lovell/sharp/issues/955#issuecomment-475532037

결국 사실 공식문서 제대로 안읽고, sharp 안깔고 배포해서 생긴 문제였지만..

이미지를 sharp하는걸 서버에서... 처리하는게 이상한 그림이긴하다.

메모리 많이쓰는 작업이고, 백엔드도 서버에서 처리안하고 람다에서 sharp 사용해서 리사이징 하는 등..

그런 부분 고려하면 next/image 자체를 안쓰는것도 좋은 방안이라고 생각한다.

아무튼 기존에 이미지 리사이징에 sharp를 사용한 경험이 있어서 한번 다시 돌아볼 수 있는

그런 경험이었다.

[스프링] spring redisson 분산락 Aop 적용기

ImNM — Wed, 8 Mar 2023 20:47:56 +0900

둥둥즈

두둥 프로젝트를 진행하면서,

재고 감소나 , 주문 과정에서의 티켓 정보 확인등 동시성을 고려해야할 상황이 생겼다.

재고시스템으로 알아보는 동시성이슈 해결방법 - 인프런 | 강의

동시성 이슈란 무엇인지 알아보고 처리하는 방법들을 학습합니다., - 강의 소개 | 인프런

www.inflearn.com

이중에서 Redisson 을 활용해서 분산락을 적용하고있고,

두둥에서는 RedissonLock 이라는 Aop를 만들어서

중복코드를 없애면서 적용하고 있다.

분산락을 Aop로 만드는 과정을 담은 블로그들은 많다.

- https://devroach.tistory.com/82

- https://devroach.tistory.com/83

- https://devfunny.tistory.com/888

Redisson 분산락 Aop 를 구현하는 방법이 아닌 실제 적용하면서

고민 되었던 포인트들을 공유하고자 한다.

1. 두둥의 분산락 구성

- RedissonLock.java

- RedissonLockAop.java

- RedissonCallNewTransaction.java

// Aop 적용
@RedissonLock(LockName = "주문", identifier = "orderUuid")
public String execute(String orderUuid) {
    Order order = orderAdaptor.findByOrderUuid(orderUuid);
    order.approve(orderValidator);
    return orderUuid;
}

두둥 프로젝트에서는 간단하게 위와 같은 구성을 취하고있다.

덤으로 매개변수가 항상 원시타입, 원시래퍼타입을 경우는 없으니

객체로 넘겨받았을 때 , 객체 안에도 접근 할 수 있는 구조로도 작성했다.

@RedissonLock(
        LockName = "주문",
        identifier = "orderId",
        paramClassType = ConfirmPaymentsRequest.class)
public String execute(ConfirmPaymentsRequest confirmPaymentsRequest, Long currentUserId) {

소스 궁금하신 분들은 RedissonLockAop 에서 참고 하시면된다.

2. IllegalMonitorStateException

Redisson lock 안으로 진입할때에 leaseTime 을 설정할 수 있는데.

boolean available = rLock.tryLock(waitTime, leaseTime, timeUnit);

leaseTime은 처리 작업이 해당 시간만큼 지나게 되면 소스 구조상 IllegalMonitorStateException 을 발생 시킨다.

분산락 안으로 들어간 상황에서 10초 ( 두둥에서는 leaseTime을 10초 디폴트로 잡았다 )

가 지난 상황에서 IllegalMonitorStateException 이 뜬다.

문제는 leaseTime이 TransactionTimeOut보다 짧을 때 벌어진다.

leaseTime이 지나면 IllegalMonitorStateException 이 뜨는데

이 에러는 트랜잭션 안에서 발생하는 에러가 아니라 트랜잭션을 콜한 상위 콜스택에서 발생하는 에러다.

분산락 -> tryLock -> 락휙득 -> 트랜잭션 안으로 진입

트랜잭션 진입하기전에 있는 콜스택에서 터지는 에러라서, 커밋이 되어버린다.

에러가났는데.. 커밋이 된다. 당황스럽지않은가

실제로 업데이트 쿼리가 나가버린다.

그래서 IllegalMonitorStateException 에러에 대해 대응을 해줘야한다.

leaseTime 을 넘어도 커밋이 되면안된다.

이를 해결하기위해선 간단하게

@Transactional(propagation = Propagation.REQUIRES_NEW, timeout = 9)
public Object proceed(final ProceedingJoinPoint joinPoint) throws Throwable {
    return joinPoint.proceed();
}

트랜잭션 타임아웃을 leaseTime 보다 적게 잡으면된다. 그럼 안에서 leaseTime이 넘기전에 rollback 되어버린다.

근데 이러면 TransactionTimeout 에러가 발생하므로 적절한 에러처리도 동반해야줘야한다.

// try rLock.tryLock
} catch (DuDoongCodeException | DuDoongDynamicException | TransactionTimedOutException e) {
    throw e;
} finally {
    try {
    // 비즈니스 에러 또는 , TransactionTimedOutException 발생시 즉시 반환해줘야한다.
        rLock.unlock();
    // IllegalMonitorStateException 은 rLock.unlock 을 실행시킬때 발생하는 에러다.
    } catch (IllegalMonitorStateException e) {
        //적절한 로그 처리
        // forceUnlock 하면 안된다. rLock.unlock에서 이미 락이 풀린상태다
    }
}

2.1. 왜 IllegalMonitorStateException 이 발생하나요?

그외 leaseTime에 제한이 되지않는 , 정상적으로 종료한 경우에 자신의 락을 본인이 해제를 해야한다.

그래서 finally 에 rLock.unlock() 메소드가 있다.

https://github.com/redisson/redisson/wiki/8.-Distributed-locks-and-synchronizers

하지만 leaseTime 이 지난 경우 자동으로 해제되는데

finally 쪽에서는 unlock을 시도하므로( 정상상태일때 본인 락은 본인이 해제해야함 ) , 다른 스레드가 기달리다가 들어와있는 상태에서

leaseTime으로 풀려난 스레드가 락을 unlock할려고 하면, IllegalMonitorStateException 이발생하게 되는 것이다.

이미 자신의 락은 자동으로 풀린상태이기 때문에 error 로그 정도... 남기고 적당한처리를 해주시면 된다.

이제 leaseTime이 지나기전 TransactionTimeOut을 이용해서 커밋을 하기전 롤백처리를 적절하게 할 수 있게되었다.

leaseTime 으로 인한 자동으로 락이 풀릴시에, 해당 스레드가 다른 스레드의 락을 풀려고 할 때 발생할 수 있는

IllegalMonitorStateException 에 대해 적당한 로그처리를 진행해 주면된다.

3. 동시성을 테스팅을 디비를 안거쳐도 되지않을까

동시성 이슈에 대해서 당연 테스트를 통해서 검증을 해야한다.

두둥에서는 주문이 취소시, 동시요청이 들어왔을 때

주문상태가 취소가능한 상태인지 검증하는 로직에,

한번 취소가 이미 된상태라면 다시 취소될수 없게 구성이 되어있다. ( 그외에도 많다 )

해당 테스트를 진행할려면, 레포지토리에 주문 객체를 저장했다가, 꺼내오면서 테스팅을 해야하는데

두둥에서는 테스트를 할때 굳이 레포지토리 까지 왔다갔다 해야하나? 라는 생각이들었다.

즉 stub으로 order 객체를 만들어서 활용 할 수 있지 않을 까 라는 생각이 들었다.

결론부터 말씀드리자면 가능하다.

https://www.geeksforgeeks.org/java-memory-management/

힙영역 , Method area는 여러 쓰레드가 동시에 접근이 가능하다.

힙영역의 field에 stub 용 order 객체를 선언하면,

동시 접근가능한 공유 자원이 생기는 샘이다.

@DomainIntegrateSpringBootTest
@DisableDomainEvent
@Slf4j
class OrderApproveServiceConcurrencyTest {
	// 레포지토리를 통해 디비에 갔다오지 않아도. 공유자원으로 
    // 테스팅 관련한 환경 구성이 가능하다.
    Order order;

@BeforeEach
void setUp() {
    given(orderLineItem.getTotalOrderLinePrice()).willReturn(Money.ZERO);
    order =
            Order.builder()
                    .orderMethod(OrderMethod.APPROVAL)
                    .orderStatus(OrderStatus.PENDING_APPROVE)
                    .orderLineItems(List.of(orderLineItem))
                    .build();
    order.addUUID();
    willDoNothing().given(orderValidator).validCanDone(any());
    willDoNothing().given(orderValidator).validUserNotDeleted(any());
    willCallRealMethod().given(orderValidator).validCanApproveOrder(any());
    willCallRealMethod().given(orderValidator).validStatusCanApprove(any());
    given(orderAdaptor.findByOrderUuid(any())).willReturn(order);
}

위처럼 적절하게 order 객체를 테스팅 관련한 환경으로 만들고

나머지 레포지토리( 두둥에서는 orderAdaptor로 한번 레포지토리를 감쌌다)를 적절하게 @MockBean 을통해

공유되는 order 객체를 리턴하게 해주면된다.

4. 동시성 실패 테스트를 만들고 싶다면?

분산락을 적용하게되면 그럼이제 항상 성공하는 테스트를 작성할 수 밖에 없다.

분산락이 이미 어노테이션과 AOP로 적용되어있는 상태이기 때문이다.

분산락이 없을 때의 상황을 다시만들기 위해서는,

@RedissonRock 어노테이션을 떼어버려야 하는 환경을 구성해야하는데.

[스프링] Spring disable Aop in test

오랜만에... 글을 씁니다.! 디프만 12기 끝나고 ( 13기 운영진도 할 예정입니다. ㅎㅎ ) 고스락 티켓예매 세번째 프로젝트로 두둥이라는 프로젝트를 시작하게 되었다. 기존엔 고스락만을 위한 예매

devnm.tistory.com

위 포스팅을 참고하면된다.

@DomainIntegrateSpringBootTest
@DisableDomainEvent
// 분산락 꺼버리기
@DisableRedissonLock
@Slf4j
class OrderApproveServiceConcurrencyFailTest {

5. 두둥에서 동시성 테스트를 하는 방법

두둥에서는 편하게 동시성테스트를 진행하기위해서 유틸을 만들어서 쓰고있다.

@Test
@DisplayName("동시에 주문 승인 요청이 와도 하나의 요청만 성공해야한다.")
void 동시성_주문승인() throws InterruptedException {
    // 성공 횟수를 측정하기 위한 atomicLong
    AtomicLong successCount = new AtomicLong();
    CunCurrencyExecutorService.execute(
            () -> orderApproveService.execute(order.getUuid()), successCount);
    // then
    assertThat(successCount.get()).isEqualTo(1);
}

@Slf4j
public class CunCurrencyExecutorService {
    static int numberOfThreads = 10;
    static int numberOfThreadPool = 5;

    public static void execute(Executable executable, AtomicLong successCount)
            throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(numberOfThreadPool);
        CountDownLatch latch = new CountDownLatch(numberOfThreads);

        for (long i = 1; i <= numberOfThreads; i++) {
            executorService.submit(
                    () -> {
                        try {
                            executable.execute();
                            // 오류없이 성공을 하면 성공횟수를 증가시킵니다.
                            successCount.getAndIncrement();
                        } catch (Throwable e) {
                            // 에러뜨면 여기서 확인해보셔요!
                            log.info(e.getClass().getName());
                        } finally {
                            latch.countDown();
                        }
                    });
        }
        latch.await();
    }
}

간단하다 Exexcutable ( 두둥에서는 jupiter.api.funcution 꺼를 씀 ) 형태의 함수형 인터페이스로

실행가능한 람다를 넘겨 받으면 된다. 자바기본 인터페이스인 Consumer 도 괜찮을 것 같다.

위처럼 동시성 테스트 유틸을 만들어서 여러 테스트에서 적용하고 있다.

6. 왜 트랜잭션 전파속성이 REQUIRES_NEW 여야하지..

@Transactional(propagation = Propagation.REQUIRES_NEW, timeout = 9)
public Object proceed(final ProceedingJoinPoint joinPoint) throws Throwable {
    return joinPoint.proceed();
}

분산락 안으로 들어갈때는 항상 트랜잭션 전파옵션을

REQUIRES_NEW 로 둬야한다.

트랜잭션 격리 수준에 의해서 그런데,

mysql 은 기본 격리수준이 REPEATABLE READ 이다.

즉 트랜잭션이 시작할 때 id 기준으로 자신보다 더 일찍 커밋된 정보만 최신으로 가져오기 때문에,

만일 트랜잭션이 동일트랜잭션으로 전파가 되어 분산락 안에서 실행된다고 가졍하면,

재고가 100 이있다 가정한다면

B 트랜잭션 시작(재고 100) -> A 트랜잭션 시작(재고 100) -> A 분산락 진입 후 재고 1 감소 (재고99) -> 
A가 분산락 벗어났지만 트랜잭션 전파로인해서 아직 커밋이 안됨 ->
B 분산락 진입 ( 재고 100 ) 진입후 재고 1 감소 ( 재고 99) -> 최종 99로 기록됨.

위처럼 분산락을 진입하기 이전의 트랜잭션과 동일한 트랜잭션을 분산락 안에서 수행되게되면,

커밋할 때 까지가 분산락이 끝나는 시점이 아닌 , 상위 트랜잭션 영역까지 넓어지므로,

결국 동시성 이슈가 생기게 되어있다. ( 분산락 끝나자마자 다른 쓰레드가 들어와서 업데이트 쳐버린경우 나중에 덮어씌기가 된다. )

따라서 항상 REQUIRES_NEW로 트랜잭션 전파 속성을 둬야 한다.

7. 새로운 트랜잭션으로 인해서, 정보가 새로 안받아와져요. ( mapper 레이어 에서 처리 )

위 6번의 조건으로 인해 트랜잭션 전파 속성으로 인해서 항상 새로운 트랜잭션을 분산락 안에서 실행시킨다.

// ConfirmOrderUseCase 의 잘못된 예
@Transactional(readOnly = true)
public OrderResponse execute(String orderUuid, ConfirmOrderRequest confirmOrderRequest) {
    Long currentUserId = SecurityUtils.getCurrentUserId();
    ConfirmPaymentsRequest confirmPaymentsRequest =
            ConfirmPaymentsRequest.builder()
                    .paymentKey(confirmOrderRequest.getPaymentKey())
                    .amount(confirmOrderRequest.getAmount())
                    .orderId(orderUuid)
                    .build();
                    // orderConfirmService 는 분산락으로 동작한다.
    String confirmOrderUuid =
            orderConfirmService.execute(confirmPaymentsRequest, currentUserId);
    return orderMapper.toOrderResponse(confirmOrderUuid);
}

두둥에서는 멀티 모듈 구조로 usecase와 도메인 서비스를 분리 해놨고,

도메인 모듈 ( orderConfrimService ) 에서만 분산락을 적용하고 있다.

만일 위와같이 usecase ( facade 형태로 여러 도메인의 응답값을 받아 클라이언트한테 응답을 하는 레이어 ) 를

Transaction으로 감싼다고 가정하면,

usecase 의 execute를 실행할 때에 트랜잭션이 먼저 시작되고,

분산락의 트랜잭션이 나중에 실행이된다.

즉 , 분산락 내부에서 트랜잭션이 종료되어 데이터가 정상적으로 커밋이 되어도,

트랜잭션 고립 수준에 의하여 , usecase execute의 트랜잭션이 먼저 시작되었으므로,

그 이후에 분산락에서 벌어진 커밋 내역에서는 최신본을 불러오지 못한다.

따라서 위와같은 구조를 취하게되면 , 클라이언트한테 응답할 때 최신의 정보를 리턴해 주지못한다.

// ConfirmOrderUseCase
public OrderResponse execute(String orderUuid, ConfirmOrderRequest confirmOrderRequest) {
    Long currentUserId = SecurityUtils.getCurrentUserId();
    ConfirmPaymentsRequest confirmPaymentsRequest =
            ConfirmPaymentsRequest.builder()
                    .paymentKey(confirmOrderRequest.getPaymentKey())
                    .amount(confirmOrderRequest.getAmount())
                    .orderId(orderUuid)
                    .build();
    String confirmOrderUuid =
            orderConfirmService.execute(confirmPaymentsRequest, currentUserId);
    return orderMapper.toOrderResponse(confirmOrderUuid);
}

// OrderMapper
@Transactional(readOnly = true)
public OrderResponse toOrderResponse(String orderUuid) {
    Order order = orderAdaptor.findByOrderUuid(orderUuid);

    Event event = getEvent(order);

    List<OrderLineTicketResponse> orderLineTicketResponses = getOrderLineTicketResponses(order);

    return OrderResponse.of(order, event, orderLineTicketResponses);
}

위와 같이 mapper 레이어를 두어서 클라이언트한테 응답을 전달 할 때는

분산락의 트랜잭션이 끝난뒤에 응답용 트랜잭션을 시작시켜서,

최신의 정보를 가져오게 끔 할 수 있다.

김영한 선생님께서 말씀하시는 커맨드성 함수는 엔티티를 리턴시키지말고 id 와 같은 정보만 넘겨줘서

다시 조회하게 끔 만들어야 한다는 경우가 이런 경우이다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

위 해당하는 소스들은 두둥 프로젝트에서 진행하며 작성한 코드들이다.

처음 락을 잡아보고 , 동시성을 고려하고 , 트랜잭션 전파속성 때문에 어떻게 대응해야하는지

그런 노하우들을 담아봤다.

[스프링] 멀티모듈 jacoco , sonarqube (cloud) 세팅

ImNM — Wed, 8 Mar 2023 03:50:36 +0900

두둥 프로젝트를 진행하면서 sonarcloud 를 활용해서

pr 간의 테스트 코드 측정 , 머지후 dev브런치의 테스트 커버리지 측정등

ci 단에서 테스트 코드를 돌렸다.

아직 전체 테스트커버리지가 20퍼 대 이긴하지만, 중요한 도메인 로직들은

단위테스트는 거의 다 되어있는상태이다.

테스트 코드를 돌리면서 정말.. 많이 도움 되었다.

잘못 변경한 부분이나, 빌드 페일등을 방지하면서 안정성 있게 운영했었다.

다만 멀티모듈기준으로 초기 세팅하는데 잘 안된 부분들이 있어서

공유하려고한다.

1. 전체적인 구성방식

테스트를 돌리면 jacocoTestReports 그래들 태스크를 실행시키면서

build.reports 에 테스트 커버리지 관련 내용들이 나오고,

xml을 sonarcloud 에 전송해서 테스트 커버리지를 측정한다.

또한 정적분석도 소나클라우드 측에서 진행해준다.

위 방식으로 흘러가고

- name: test and analyze
  env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
  run: ./gradlew test sonar --info --stacktrace

github ci단에서는 dev 브런치에 머지 리퀘스트가 날라올때 , dev에 푸시가 될때 두번 날려서

디폴트 브런치인 dev 브런치의 테스트 커버리지 측정과 피알 단위의 테스트 커버리지 측정 ,

두개를 측정하게 된다.

2. jacoco 세팅하기

테스트 커버리지 측정을 위해선 jacoco를 세팅해야한다.

제일 바깥 모듈의 gradle에서

subprojects {
	// 다른 부분은 생략
    apply plugin: 'jacoco'
    jacoco {
        toolVersion = '0.8.8'
    }
    jacocoTestReport {
        dependsOn test
        reports {
            html.enabled true // html 설정
            csv.enabled true // csv 설정
            xml.enabled true
            //xml 의 위치 조정
            xml.destination file("${buildDir}/reports/jacoco.xml")
        }
        def Qdomains = []
        for (qPattern in '**/QA'..'**/QZ') { // qPattern = '**/QA', '**/QB', ... '*.QZ'
            Qdomains.add(qPattern + '*')
        }
        afterEvaluate {
            classDirectories.setFrom(
                    files(classDirectories.files.collect {
                        fileTree(dir: it, excludes: [
                        		// 측정 안하고 싶은 패턴
                                "**/*Application*",
                                "**/*Config*",
                                "**/*Dto*",
                                "**/*Request*",
                                "**/*Response*",
                                "**/*Interceptor*",
                                "**/*Exception*"
                                // Querydsl 관련 제거
                        ] + Qdomains)
                    })
            )
        }
    }
    test {
        useJUnitPlatform()
        finalizedBy jacocoTestReport
    }
}

위처럼 jacoco 관련 세팅을 해준다.

빼고싶은 부분은 제거하고,

test 그래들 task를 실행시키면 jacocoTestReport 도 실행된다.

subproject 안에 작성된거여서 각 서브 모듈마다 적용이된다.

위와같은 설정을하게되면 test task 를 돌릴시에 테스크 커버리지 측정이된다.

3. sonarqube 설정하기

3.1. 소나 클라우드 관련

소나큐브를 직접 띄워도 되지만, 두둥 프로젝트에서는 sonarcloud를 사용했다.

간단하게 가입하고, 본인의 조직과 레포지토리를 선택한다.

그리고 항상 ci로 분석을 진행한다고 선택한다. 즉 자동 분석은 꺼준다.

또한 소나클라우드에서 설정할 값은 없다. 세팅은 다 그래들 쪽에서 해줄거다.

Quality Gate만.. 최소 테스트 커버리지 그런것만 팀원들이랑 상의해서 정하면된다.

우리는 ... 최대로 낮췄다 ㅎㅎ...

그다음 깃헙 액션 들어가서 두 값을 잘 체크해 둔다.

env 세팅

깃헙 액션의 환경변수를 위와 같이 설정하면 된다.

3.2. 그래들 관련

위 env 세팅에서 밑에 Gradle 버튼을 누르면 projectKey 랑 organization을 볼수있다.

복사해서 밑에 그래들을 공통 부분에 작성한다. ( 공통부분이라 함은 subproject 바깥을의미 )

// 공통으로 들어갈 부분
sonarqube {
    properties {
        property 'sonar.projectKey', 'Gosrock_DuDoong-Backend' // 본인 꺼 집어넣으세용
        property 'sonar.organization', 'dudung-gosrock' // 이것두
        property 'sonar.host.url', 'https://sonarcloud.io'
        property 'sonar.sources', 'src'
        property 'sonar.language', 'java'
        property 'sonar.sourceEncoding', 'UTF-8'
        property 'sonar.test.inclusions', '**/*Test.java'
        // 테스트 커버리지에서 빼고싶은거 넣어야함
        property 'sonar.exclusions', '**/test/**, **/Q*.java, **/*Doc*.java, **/resources/** ,**/*Application*.java , **/*Config*.java,' +
                '**/*Dto*.java, **/*Request*.java, **/*Response*.java ,**/*Exception*.java ,**/*ErrorCode*.java'
        property 'sonar.java.coveragePlugin', 'jacoco'
    }
}

subprojects {
    apply plugin: 'org.sonarqube'

    sonarqube {
        properties {
        	// 각 프로젝트마다 적용해야하는부분.
            property 'sonar.java.binaries', "${buildDir}/classes"
            property 'sonar.coverage.jacoco.xmlReportPaths', "${buildDir}/reports/jacoco.xml"
        }
    }
}

공통으로 들어갈 부분과 각 모듈마다 정해야할 부분을 잘 분리해서 작성하면된다.

특히 binaries 와 xmlReportPaths 는 무조건 따로 지정해야 잘된다.

3.3. 깃헙 액션

// 풀리퀘 날려올때마다 측정
name: ci
on:
  pull_request:
    branch: 'dev'

jobs:
  spotlessJavaCheck:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: SetUp JDK 17
        uses: actions/setup-java@v2
        with:
          java-version: "17"
          distribution: 'adopt'

      - name: Gradle Caching
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew

      - name: spotless check
        run: ./gradlew spotlessCheck

      - name: test and analyze
        env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        run: ./gradlew test sonar --info --stacktrace

// 데브 브런치 기준으로 측정
name: ci
on:
  push:
    branches:
      - dev

간단..하다!

딱히 설명이 필요없을것 같다.

위처럼 ci 파일을 두개 만들게되면, 데브브런치 기준, 피알 기준으로 테스트 커버리지 측정이 가능하다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

소스 링크 걸어두니 참고하시길 바란다.!

소스보시면 금방이해하실거다.

테스트 커버리지 측정이 부담스러우시면

ci 단이라도 빌드가 되는지 안되는지 테스트 돌려보시기라도 하면 좋다.

빌드 페일 방지목적으로도 .. 안정성 있게 운영하는데 도움이 되는것 같다.

두둥 프로젝트에서는 추가적으로 소스코드 스타일도 체킹하는데

spotless 관련 설정도 있으시 참고해보면 좋겠다.

- 데브브런치 ci

- 풀리퀘 ci

- gradle

[스프링] spring oauth Open ID Connect with kakao

ImNM — Wed, 8 Mar 2023 00:03:07 +0900

두둥서비스의 회원가입전 약관 동의화면

두둥 프로젝트와 , 디프만 낙낙 프로젝트를 진행하면서 ,

회원가입하는 과정이 oauth 서버에서 인증뿐만아니라,

프로필 설정등의 중간 과정이 필요했었고, 이를 적절한 방법으로 구현하기 위해

oauth 스펙중 하나인 OIDC 를 사용해보기로 했다.

이글을통해서 직접 구현하는 방법을 공유하고자 한다.

1. 문제점

oauth 인증 과정을 수행하게 되면, 보통 code 요청을 받게되면

바로 회원가입 처리를 하되, 상태값으로 실 가입전이라고 구분하는 방법을 많이 쓰는것 같다.

두둥의 약관 동의하고 시작하기 / 카카오톡 시작하기 이후 닉네임을 정해야함

하지만 보통의 서비스에선 사실 oauth 인증후에 바로 회원가입으로 끝나는 어플은 보기 힘들다.

위 사진처럼 oauth로 카카오에서 정보를 가져오더라도 , 약관동의나 마케팅 수신여부 . 닉네임 프로필 사진등을 고르거나,

부족한 정보(주소지같은 부가정보)들을 oauth 인증 이후에 따로 채우고 있다.

1.1. Oauth AccessToken을 이용하는 여러가지 해결방안

oauth에 인증이 되어있다는 상태를 알려면

백엔드에서는

1. oauth 정보를 따로 저장하기
2. 실제 유저의 동의를 받고 회원가입을 한것은 아니지만, 유저관련데이타를 미리 생성하기
3. Oauth의 accessToken 으로 유저동의받고 회원가입 하기 ( 백엔드에서 Oauth accessToken 검증 )
4. registerToken jwt 를 따로만들어서 회원가입할 수 있는 토큰으로 oauth 인증 했다는 토큰 발급하기

등등의 방법으로 이문제를 풀 수 있을것 같다.

여러가지 구현방법은 있겠지만 보고서 드는생각은 깔끔하지 못한것같다.

1,2,3,4 번의 방법 모두다 결국 어떤형태로든 클라이언트한테 인증이 되었다는 상태를 검증할수 있는

쿠키든 토큰이든 클라이언트가 들고있다가 회원가입때 같이 보내줘야만 한다. ( 회원가입용 api를 따로 만들어야하니깐 )

1.2. Oauth AccessToken으로 회원가입 할 때의 문제점

3. Oauth의 accessToken 으로 유저동의받고 회원가입 하기 ( 백엔드에서 Oauth accessToken 검증 )

의 문제점을 확인해보자.

Oauth 인증을 통해서 나오는 accessToken,refreshToken 은

Oauth 리소스 서버 ( 카카오톡의 사진, 친구목록, 메시지 보내기 ) 등 에 쓰이는 토큰이고,

Oauth 인증 과정을 거쳐서 회원가입, 로그인을 한뒤에 자신의 서버에서 인증용 토큰을 발급해줘야한다.

즉 Oauth 인증과정을 수행후나오는 accessToken은 Oauth한 서버의 리소스에 접근하는 용도로 쓰이는 것이다.

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

GET/POST /v2/user/me HTTP/1.1
Host: kapi.kakao.com
Authorization: Bearer ${ACCESS_TOKEN}/KakaoAK ${APP_ADMIN_KEY}
Content-type: application/x-www-form-urlencoded;charset=utf-8

보통의 서버에서는 위 사용자 정보가져오기로

회원가입에 필요한 정보들을 얻어오면서 , 회원가입을 시킬것이다.

여기서 중요한점은 응답값에 Oauth AccessToken이 두둥에서 발급되었다는 사실을 확인을 할 수 없다는점이다.

오로지 해당 사용자에대한 프로필 정보만 내려온다.

그럼 발급된 AccessToken으로 사용자의 프로필 정보를 확인한 뒤에 회원가입을 시키는것은.

매우 잘못된 로직이다.

내가 만약 테스트 어플리케이션으로 카카오톡 디밸로퍼스에 두둥2 라고 만든뒤.

가입을 한뒤에 해당 AccessToken을 기존 두둥 서버에 보내도 회원가입이 된다.

그저 프로필 정보만 확인하므로.

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

curl -v -X GET "https://kapi.kakao.com/v1/user/access_token_info" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}"

그래서 따로 토큰 정보보기를 요청해서

HTTP/1.1 200 OK
{
    "id":123456789,
    "expires_in": 7199,
    "app_id":1234
}

응답값으로 넘어온 app_id가 우리 두둥의 app_id 인지 이차로 확인하는 과정이 필요하다.

이런 형태가 다른 구글 같은 oauth에도 적용할 수 있을까?

토큰 정보보기같은 api는 카카오가 친절하게 만들어준것이지 Oauth의 스펙이 아니다.

출처 카카오 로그인 과정 (https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api#before-you-begin-process)

정말 중요한 그림이라 가져왔다.

사실 Code 까지 받는건 클라이언트에서 진행해도된다.

어차피 Code는 사용자 브라우저에 url에 뜬다.

그러나 Step 2. 의 토큰 받기는 서버까지만의 그림으로 그려져있다.

AccessToken 을받아서 클라이언트한테 넘겨주고,

그 AccessToken 을 회원가입때 프로필 정보확인하며 회원가입시키는건

누구나 회원가입 Api로 다른 서비스에서 발급받은 AccessToken으로 회원가입 할 수 있다는점이다.

그래서 그림도 서버에서 토큰 받기로 되어있다.

즉 Oauth AccessToken은 인가(리소스 서버에 접근을 하기위한) 토큰일 뿐이다.

꼭 한번다시 읽어주길바랍니당..

2. Open ID Connect ( OIDC )

위 사진의 Step 3. 사용자 로그인 처리의 OpenID Connect 사용시 ID 토큰 유효성 검증이라고 적혀져 있다.

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

OpenID Connect(OIDC)는 사용자가 안전하게 로그인하는 데 사용할 수 있는
OAuth 2.0 기반의 표준 인증 프로토콜입니다.

중요한점은 인증 프로토콜이다. 표준이라서 구글에서등 OIDC를 지원하는 곳이라면 다가능하다.

OIDC 의 토큰은 jwt 형태를 따른다. (AccessToken,RefreshToken 은 jwt 형식이 아니여도된다)

{
	// 이 jwt 토큰을 받은사람
    "iss": "https://kauth.kakao.com",
    // 내앱키 , 두둥이면 230322(예시임) 이런식
    "aud": "${APP_KEY}",
    // 실제 유저의 고유 아이디 ( 카카오 유저의 고유 번호 )
    "sub": "166959",
    "iat": 1647183250,
    "exp": 1647190450,
    "nonce": "${NONCE}",
    "auth_time": 1647183250
}

내용의 정보를 보면 위와같은 정보를 받을 수 있다.

발급한 곳의 정보와, 내 앱키의 정보를 jwt 토큰에서 얻을 수 있다.

내 앱키의 정보를 jwt 토큰에서 얻을 수 있으므로, 
검증된 토큰이라면 내 두둥서버에서 등록한 어플리케이션으로
발급한 id_token이라는점을 알 수 있다.

즉 위와 같은 점 때문에 로그인 세션 유지로 쓸수 있다는 말이다.

세션 유지가 가능하다면 회원가입시에 추가 정보가 필요할경우,

IdToken(OIDC)을 활용해서 oauth에 인증된 사용자임을 검증 할 수 있다는 점이다.

jwt 에서 정보를 얻을 수 있다는 말은, header, payload 부분에 있다는 말이다.

즉 누구에게나 공개된 정보다. jwt.io 에가서 발급된 idToken을 넣어봐도 나오는 정보다.

그럼, 이 정보가 안전하게 인증된 정보라는것을 어떻게 알 수 있는가?

jwt 인증을 할때 내 시크릿키로 암호화 복호화하듯이

카카오 서버에서도 키를 준다. 근데 하나의 키가아니라 RSA 암호화 방식으로 공개키를 준다.

즉 jwt 암호화 할땐 비밀키로 암호화를 하고, 그정보를 인증되었는지 확인할땐 공개키로 복호화를 하는것이다.

1. 메타데이터 확인
2. 카카오 로그인 구현
3. ID 토큰 유효성 검증하기

바로 위링크에서는 구현 방법으로 위와같이 나뉘어져있고,

2. 카카오 로그인 구현은

설정에서 Open Id connect 를 허용해주고 각자의 서비스에서 잘 구현했다고 가정하고,

코드를 보내 토큰 발급요청 후에 AccessToken,RefreshToken,IdToken이

발급된다고 가정한 상태에서 구현방법을 설명하도록 하겠다.

3. 적용하기

두둥 프로젝트에서는 api 클라이언트로 feign을 사용중이다.

http템플릿써서 구현해도 캐싱방식에서만 구현의 편의성이 달라지지 다 똑같이 구현할 수 있다는 점 말씀드리고 싶다.

3.1. 공개키 목록 조회하기 , feign으로 캐싱하기

IdToken을 받았을 때에 , 인증되었는지에 대한 확인을 하길 위해선 공개키로 확인을 해야한다.

그 공개키를 받아오는 api는 아래 문서에서 확인가능하다.

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

curl -v -X GET "https://kauth.kakao.com/.well-known/jwks.json"
HTTP/1.1 200 OK
{
    "keys": [
        {
            "kid": "3f96980381e451efad0d2ddd30e3d3",
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "n": "q8zZ0b_MNaLd6Ny8wd4cjFomilLfFIZcmhNSc1ttx_oQdJJZt5CDHB8WWwPGBUDUyY8AmfglS9Y1qA0_fxxs-ZUWdt45jSbUxghKNYgEwSutfM5sROh3srm5TiLW4YfOvKytGW1r9TQEdLe98ork8-rNRYPybRI3SKoqpci1m1QOcvUg4xEYRvbZIWku24DNMSeheytKUz6Ni4kKOVkzfGN11rUj1IrlRR-LNA9V9ZYmeoywy3k066rD5TaZHor5bM5gIzt1B4FmUuFITpXKGQZS5Hn_Ck8Bgc8kLWGAU8TzmOzLeROosqKE0eZJ4ESLMImTb2XSEZuN1wFyL0VtJw",
            "e": "AQAB"
        }, {
            "kid": "9f252dadd5f233f93d2fa528d12fea",
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "n": "qGWf6RVzV2pM8YqJ6by5exoixIlTvdXDfYj2v7E6xkoYmesAjp_1IYL7rzhpUYqIkWX0P4wOwAsg-Ud8PcMHggfwUNPOcqgSk1hAIHr63zSlG8xatQb17q9LrWny2HWkUVEU30PxxHsLcuzmfhbRx8kOrNfJEirIuqSyWF_OBHeEgBgYjydd_c8vPo7IiH-pijZn4ZouPsEg7wtdIX3-0ZcXXDbFkaDaqClfqmVCLNBhg3DKYDQOoyWXrpFKUXUFuk2FTCqWaQJ0GniO4p_ppkYIf4zhlwUYfXZEhm8cBo6H2EgukntDbTgnoha8kNunTPekxWTDhE5wGAt6YpT4Yw",
            "e": "AQAB"
        }
    ]
}

응답값을 보면 n,e 를 받아서 공개키를 만들 수 있고,

kid 또한 중요하다.

공개키가 하나인것이아니라 IdToken의 헤더정보를 보면 kid 정보가 있으며

그 kid와 동일한 키값을 가진 공개키로 ID 토큰 유효성 검증을 해야한다.

또한 공개키는 로그인요청마다 필요하므로, 계속 가지고 있어야되는 정보인데 자주보내면 요청이 차단된다고 한다.

//KakaoOauthClient
@FeignClient(
        name = "KakaoAuthClient",
        url = "https://kauth.kakao.com",
        configuration = KakaoKauthConfig.class)
public interface KakaoOauthClient {
	@Cacheable(cacheNames = "KakaoOICD", cacheManager = "oidcCacheManager")
	@GetMapping("/.well-known/jwks.json")
	OIDCPublicKeysResponse getKakaoOIDCOpenKeys();
}

//RedisCacheConfig
@Bean
public CacheManager oidcCacheManager(RedisConnectionFactory cf) {
    RedisCacheConfiguration redisCacheConfiguration =
            RedisCacheConfiguration.defaultCacheConfig()
                    .serializeKeysWith(
                            RedisSerializationContext.SerializationPair.fromSerializer(
                                    new StringRedisSerializer()))
                    .serializeValuesWith(
                            RedisSerializationContext.SerializationPair.fromSerializer(
                                    new GenericJackson2JsonRedisSerializer()))
                    // TTL 일주일로 설정               
                    .entryTtl(Duration.ofDays(7L));

    return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(cf)
            .cacheDefaults(redisCacheConfiguration)
            .build();
}

위처럼 feign 클라이언트요청에 캐싱을 해버릴 수 있다. 얼마나 간편한가? 한번에 끝나버렸다.

위와같은 방식으로 공개키 목록을 로그인 요청시에 레디시 캐시저장소에서 꺼내올 수 있는 환경을 구성했다.

3.2. ID 토큰 유효성 검증하기

3.2.1 서명 검증전 페이로드 검증

카카오 토큰 유효성 검증하기에서 안내하는 방식이다.

1. ID 토큰의 영역 구분자인 온점(.)을 기준으로 헤더, 페이로드, 서명을 분리
2. 페이로드를 Base64 방식으로 디코딩
3. 페이로드의 iss 값이 https://kauth.kakao.com와 일치하는지 확인
4. 페이로드의 aud 값이 서비스 앱 키와 일치하는지 확인
5. 페이로드의 exp 값이 현재 UNIX 타임스탬프(Timestamp)보다 큰 값인지 확인(ID 토큰이 만료되지 않았는지 확인)
6. 페이로드의 nonce 값이 카카오 로그인 요청 시 전달한 값과 일치하는지 확인
7. 서명 검증

# 서명 검증은 다음 순서로 진행합니다.

1. 헤더를 Base64 방식으로 디코딩
2. OIDC: 공개키 목록 조회하기를 통해 카카오 인증 서버가 서명 시 사용하는 공개키 목록 조회
3. 공개키 목록에서 헤더의 kid에 해당하는 공개키 값 확인
# 공개키는 일정 기간 캐싱(Caching)하여 사용할 것을 권장하며, 지나치게 빈번한 요청 시 요청이 차단될 수 있으므로 유의
4. JWT 서명 검증을 지원하는 라이브러리를 사용해 공개키로 서명 검증

이중에서 6번 nonce 관련은 구현하지 않았다. 참고바란다.

1~5번은 한번에 처리가 가능하다.

1. 우선은 인증전에 누구나 다 얻을 수 있는 payload를 가져온다.

//JwtOICDProvider
private String getUnsignedToken(String token) {
    String[] splitToken = token.split("\\.");
    if (splitToken.length != 3) throw InvalidTokenException.EXCEPTION;
    return splitToken[0] + "." + splitToken[1] + ".";
}

Allow parsing signed JWTs without the key · Issue #280 · jwtk/jjwt

As a client I want to parse a JWT received from a server to inspect the contents. The JWT is signed by the server and obviously I don't have the secret signing key. Currently it's not possi...

github.com

위 이슈에서 가져온 코드다.

Header.body.VerifySignature

세부분에서 머리랑 몸통만 가져온다.

- 2,3,4,5 번

// JwtOIDCProvider
private Jwt<Header, Claims> getUnsignedTokenClaims(String token, String iss, String aud) {
    try {
        return Jwts.parserBuilder()
                .requireAudience(aud) //aud(두둥 카카오톡 어플리케이션 아이디) 가 같은지 확인
                .requireIssuer(iss)//iss(이슈어)가 카카오인지 확인
                .build()
                .parseClaimsJwt(getUnsignedToken(token));
    } catch (ExpiredJwtException e) { //파싱하면서 만료된 토큰인지 확인.
        throw ExpiredTokenException.EXCEPTION; 
    } catch (Exception e) {
        log.error(e.toString());
        throw InvalidTokenException.EXCEPTION;
    }
}

정말 한번에 처리가 되지않는가?

iss(이슈어)가 카카오인지 확인
aud(두둥 카카오톡 어플리케이션 아이디) 가 같은지 확인
파싱하면서 만료된 토큰인지 확인.

2,3,4,5번이 한번에 끝나버렸다.

3.2.2 서명 검증하기

출처 : https://developers.kakao.com/docs/latest/ko/kakaologin/common#oidc-id-token

우린 이제 Header와 payload (머리와 몸통 )에 해당하는 정보를 인증이 되지 않은 토큰에서 얻어올 수 있다.

인증이 되지않은 토큰에서 얻을 정보는 지금은 하나다.

공개키 목록 에서 쓸 kid를 가져오는 것이다.

// JwtOIDCProvider
private final String KID = "kid";

public String getKidFromUnsignedTokenHeader(String token, String iss, String aud) {
    return (String) getUnsignedTokenClaims(token, iss, aud).getHeader().get(KID);
}

kid를 가져오게되면 서명 검증에 어떤 공개키를 써야할지 결정할 수 있다.

// kakao Oauth helper
public OIDCDecodePayload getOIDCDecodePayload(String token) {
	// 공개키 목록을 조회한다. 캐싱이 되어있다.
    OIDCPublicKeysResponse oidcPublicKeysResponse = kakaoOauthClient.getKakaoOIDCOpenKeys();
    return oauthOIDCHelper.getPayloadFromIdToken(
    		//idToken
            token,
            // iss 와 대응되는 값
            oauthProperties.getKakaoBaseUrl(),
            // aud 와 대응되는값
            oauthProperties.getKakaoAppId(),
            // 공개키 목록
            oidcPublicKeysResponse);
}

@Helper
@RequiredArgsConstructor
public class OauthOIDCHelper {
    private final JwtOIDCProvider jwtOIDCProvider;
	// OauthOIDC는 스펙이기때문에 OauthOIDCHelper 하나로 카카오,구글 다 대응 가능하다.
    // KakaoOauthHelper 등에서 아래 소스들을 사용한다.
    // kid를 토큰에서 가져온다.
    private String getKidFromUnsignedIdToken(String token, String iss, String aud) {
        return jwtOIDCProvider.getKidFromUnsignedTokenHeader(token, iss, aud);
    }
	
    public OIDCDecodePayload getPayloadFromIdToken(
            String token, String iss, String aud, OIDCPublicKeysResponse oidcPublicKeysResponse) {
        String kid = getKidFromUnsignedIdToken(token, iss, aud);
		// KakaoOauthHelper 에서 공개키를 조회했고 해당 디티오를 넘겨준다.
        OIDCPublicKeyDto oidcPublicKeyDto =
                oidcPublicKeysResponse.getKeys().stream()
                		// 같은 kid를 가져온다.
                        .filter(o -> o.getKid().equals(kid))
                        .findFirst()
                        .orElseThrow();
		// 검증이 된 토큰에서 바디를 꺼내온다.
        return jwtOIDCProvider.getOIDCTokenBody(
                token, oidcPublicKeyDto.getN(), oidcPublicKeyDto.getE());
    }
}

// JwtOIDCProvider
// 공개키로 토큰 검증을 시도한다.
public Jws<Claims> getOIDCTokenJws(String token, String modulus, String exponent) {
    try {
        return Jwts.parserBuilder()
                .setSigningKey(getRSAPublicKey(modulus, exponent))
                .build()
                .parseClaimsJws(token);
    } catch (ExpiredJwtException e) {
        throw ExpiredTokenException.EXCEPTION;
    } catch (Exception e) {
        log.error(e.toString());
        throw InvalidTokenException.EXCEPTION;
    }
}
// OIDCDecodePayload 를 가져온다. 스펙이라 공통으로 사용할 수 있다.
public OIDCDecodePayload getOIDCTokenBody(String token, String modulus, String exponent) {
    Claims body = getOIDCTokenJws(token, modulus, exponent).getBody();
    return new OIDCDecodePayload(
            body.getIssuer(),
            body.getAudience(),
            body.getSubject(),
            body.get("email", String.class));
}

앞써 비검증된 토큰에서 header정보와 payload 정보를 가져올 수 있었다.

Header 정보에서 kid 를 가져와 공개키를 어느키에 매칭시킬지 구한다.

공개키 목록에서 검증을 진행할 공개키 하나를 구한뒤에,

n, e를 조합해서 공개키를 직접만들어야한다.

만든 공개키로 검증을 진행한뒤에 페이로드를 가져오고나서

정보를 저장하던, 필요한 정보를 카카오 리소스 서버에 더 요청하든 하면된다.

// JwtOIDCProvider
// 제일 핵심이 되는 소스이다 n ,e 값으로 Rsa 퍼블릭 키를 연산 할 수 있다.
// 진짜.. 힘들게 만든 소스다..잘 쓰시길 바란다..
private Key getRSAPublicKey(String modulus, String exponent)
        throws NoSuchAlgorithmException, InvalidKeySpecException {
    KeyFactory keyFactory = KeyFactory.getInstance("RSA");
    byte[] decodeN = Base64.getUrlDecoder().decode(modulus);
    byte[] decodeE = Base64.getUrlDecoder().decode(exponent);
    BigInteger n = new BigInteger(1, decodeN);
    BigInteger e = new BigInteger(1, decodeE);

    RSAPublicKeySpec keySpec = new RSAPublicKeySpec(n, e);
    return keyFactory.generatePublic(keySpec);
}

위소스는 넘겨온 n , e 로 공개키를 구하는 방식이다.

n,e를 구하는방식

base64로 인코딩 된 값이 넘어오기때문에 디코드를 하면서 byte 어레이를 구하고

바이트에서 정수로 변환하는 작업을 거쳐야한다. n 숫자가 큰편이니 BigInteger를 써야한다.

signum 1 은그냥 양수라는 뜻이다.

이렇게 해서 인증된 idToken에서 바디 정보를 빼올 수 있다.

그 뒤에 처리는 자유롭게 하시면될것 같다.

이렇게 IdToken을 활용해서 로그인 세션 유지를 하는 방법을 알아보았다.

중요한점은

Oauth 의 accessToken은 리소스서버에 인가를 위한 것이고,

IdToken은 인증을 위한것이며,

두둥에서는 회원가입 시에 약관 동의를 사용자에게 구하기위해서

Rsa 공개키방식으로 토큰 검증을 할 수 있는 idToken을 활용하여

실 회원가입전 id token을 활용해서 oauth에 인증된 사용자임을 검증 하고 있다.

위 소스들은 두둥 프로젝트에서 참고 가능하다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

아마 위 예시 소스로는 복잡해서, 구현하기 힘드실것같다..

내용보고 소스 레포지토리 가셔서 참고하시는게 더 좋을것같다.

찾아봐도 OIDC 를 직접 구현한 자료가 없어서

카카오 문서보면서 일일히 구현을 했다.

다행이도 캐싱과같은건 feign클라이언트를 쓰고있어서 편하게 했고,

복잡했던 과정들이 한방에 처리되는 경우도 있어서 어렵지 않게 구현을했다. 하루쯤 걸렸던것같다.

카카오의 경우 aud(앱키)가 앱환경에서는 해당 네이티브 앱 키로 나온다.

낙낙은 어플리케이션이였는데 배포하고 나서 알았다...!

웹 환경과 앱 환경 둘다 제공하는 환경이라면 네이티브 앱 키도 꼭 대응하시길 바란다.

내 어플리케이션 > 앱설정 > 요약정보

[스프링] spring feign client wiremock test

ImNM — Tue, 7 Mar 2023 18:32:32 +0900

두둥 서비스에서 api client로 feign을 사용중이다.

매우편하게 인터페이스로 선언만 해놓으면, 응답받는거와 비슷한 형식으로 사용가능하다.

또한 인터페이스 이므로 테스트 과정에서 mocking 해야할때도 편하게 진행할수있다.

토스페이먼츠에는 발생했던 매출에서 수수료를 뺀 금액 즉 정산 받을 금액을 조회할려면,

코어 API | 토스페이먼츠 개발자센터

토스페이먼츠 API 엔드포인트(Endpoint)와 객체 정보, 파라미터, 요청 및 응답 예제를 살펴보세요.

docs.tosspayments.com

정산 조회 작업을 거쳐서 발생 주문 건에 대해서 PG 수수료를 계산해야한다.

이전까진 테스트키로 개발을 하다가, 실제 결제가 이루어지기 전까진 정산데이타가 넘어오지 않아서

응답 dto로 알맞게 파싱되는지, 테스트를 해보고 싶었다.

파싱이 제대로 되는지,

테스트를 진행하기 위해서는 정말 요청을 보낼수 있는 환경을 구성해서

요청을 보낸뒤에 그에 맞는 응답을 내려주는 형식으로 구성을 해야한다.

그방법을 공유하고자 한다.

1. wiremock

wiremock 은 테스트 목적으로 사용할 수 있는 웹 서버이다. 즉 테스트 환경에서 요청이 들어오면 정해진 응답을 반환 할 수 있다.

wiremock 자체로도 서버를 껏다 킬 수 있지만 스프링과도 연동이 가능하다.

10. Spring Cloud Contract WireMock

Modules giving you the possibility to use WireMock with different servers by using the "ambient" server embedded in a Spring Boot application. Check out the samples for more details. If you have a Spring Boot application that uses Tomcat as an embedded ser

cloud.spring.io

testImplementation "org.springframework.cloud:spring-cloud-contract-wiremock:3.1.5"

위 모듈을 추가하게 되면 스프링과 쉽게 연동할 수 있다. ( 공식문서에 있는 내용 )

우린 standalone 모드 대신에 테스트 과정에 포함시킬거다.

[
  {
    "mId": "tosspayments",
    "paymentKey": "5zJ4xY7m0kODnyRpQWGrN2xqGlNvLrKwv1M9ENjbeoPaZdL6",
    "transactionKey": "8B4F646A829571D870A3011A4E13D640",
    "orderId": "a4CWyWY5m89PNh7xJwhk1",
    "currency": "KRW",
    "method": "카드",
    "amount": 34000
  }
]

간단하게 json 파일을 위와 같이 만들어두면,

Path file = ResourceUtils.getFile("classpath:payload/settlement-response.json").toPath();
// 응답예시 생성하기
.withBody(Files.readAllBytes(file))));

테스트 코드 작성시에 미리 만들어둔 json 응답을 줄 수 있다.

2. 적용하기

2.1. feign client

@FeignClient(
        name = "SettlementClient",
        // url 자체를 환경변수로 세팅한다.
        url = "${feign.toss.url}",
        configuration = {TransactionGetConfig.class})
public interface SettlementClient {
    @GetMapping("/v1/settlements")
    List<SettlementResponse> execute(
            @RequestParam(value = "startDate") @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
                    LocalDate startDate,
            @RequestParam(value = "endDate") @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
                    LocalDate endDate,
            @RequestParam(value = "dateType") String dateType,
            @RequestParam(value = "page") int page,
            @RequestParam(value = "size") int size);
}
// application-infrastructure.yml
feign:
  toss:
    url : https://api.tosspayments.com

일반적인 요청인데 중요한 부분은 url 자체를 환경변수로 넣어야한다는 점이다.

실제 요청 주소를 default 로 세팅 해놓고 테스트를 돌릴 때 @TestPropertySource 로 환경변수를 localhost로 지정줘서

요청을 보낼 것이다.

여담이지만 @TestPropertySource 는 엄청 유용하게 쓸데가 많은것 같다.

[스프링] Spring disable Aop in test

devnm.tistory.com

내가 쓴글인 spring disable aop in test 도

테스트 돌 때 어느 한 aop 를 끄고싶을 때도 설정할 수 있다.!

위글에서는 분산락을 aop 통해서 적용하고 있었는데,

분산락 지정을 안했을때의 실패테스트를 하고 싶을 때, 간단하게 환경변수로 분산락 적용을 없앨 수 있다.

유용하니 한번 둘러보길 바란다 ㅎㅎ.

이 외엔 일반적인 feign client 모습과 동일하다.

2.2. 테스트 코드 작성하기

@SpringBootTest(classes = InfraIntegrateTestConfig.class)
@AutoConfigureWireMock(port = 0)
@ActiveProfiles(resolver = InfraIntegrateProfileResolver.class)
@TestPropertySource(
        properties = {
            "feign.toss.url=http://localhost:${wiremock.server.port}",
            // 타임리프때문에 테스트 깨져서 넣음
            "spring.thymeleaf.enabled=false"
        })
public class TossSettlementClientTest {

설정부분에서 제일 중요한부분은

@AutoConfigureWireMock(port = 0) 로설정해서 randomport 상에서 실행되게끔 하는것이고,

feign 클라이언트가 요청 보낼 주소를 localhost 에 어느 random port 인지는

wiremock.server.port 환경변수로 불러올 수 있다.

이렇게 요청보낼 주소를 정할 수 있다.

@Configuration
@ComponentScan(basePackageClasses = {DuDoongInfraApplication.class, DuDoongCommonApplication.class})
public class InfraIntegrateTestConfig {}

public class InfraIntegrateProfileResolver implements ActiveProfilesResolver {

    @Override
    public String[] resolve(Class<?> testClass) {
        // some code to find out your active profiles
        return new String[] {"common", "infrastructure"};
    }
}

InfraIntegrateTestConfig , InfraIntegrateProfileResolver는 두둥 프로젝트가 멀티모듈 구조이고

인프라 모듈이 커먼 모듈에 의존성을 가지고 있기 때문에

스프링 부트 테스트를 통한 통합테스트를 진행할 경우 , 스프링 부트 빈 구성을 위해

빈 스캔 범위를 지정하고, 필요한 profile을 편하게 설정하기 위해서 만든 편의 클래스이다.

각 모듈 ( 최종 어플리케이션 모듈이 아닌 의존성이있는 모듈등인 경우 )

application-{모듈이름}.yml 형태로 환경변수들을 세팅해 줄 수 있고,

profile에 지정을 해줘야 해당 모듈의 환경변수들을 불러올 수 있다.

멀티모듈구조가 아니라면 굳이 설정해 줄 필요가 없다.

@Autowired private SettlementClient settlementClient;

@Test
public void 정산요청_올바르게_파싱되어야한다() throws IOException {
    // 만들어둔 json 파일을 불러온다.
    Path file = ResourceUtils.getFile("classpath:payload/settlement-response.json").toPath();
	// import static com.github.tomakehurst.wiremock.client.WireMock.*
    stubFor(
    		// localhost:${wiremock.server.port}/v1/settlements 요청은 willReturn을 한다.
            get(urlPathEqualTo("/v1/settlements"))
                    .willReturn(
                            aResponse()
                                    .withStatus(HttpStatus.OK.value())
                                    .withHeader(
                                            "Content-Type", MediaType.APPLICATION_JSON_VALUE)
                                    // 바디 지정
                                    .withBody(Files.readAllBytes(file))));
    LocalDate now = LocalDate.now();
    // 실제 요청이 List<SettlementResponse>에 담겨서온다 
    List<SettlementResponse> test = settlementClient.execute(now, now, "test", 1, 10);
	
    SettlementResponse settlementResponse = test.get(0);
    // 파싱이 제대로 되었는지 확인.. 다 확인은 안하고 디버거로 적당히 했다.!
    assertEquals(settlementResponse.getFees().size(), 2);
}

위처럼 코드작성을 하게 되면

실제로 응답이 잘 파싱되는지 확인 할 수 있다.

Enum 값이나 iso 형식으로 넘어오는 날짜 데이타들이 잘 파싱되는것을 볼 수 있다.

이렇게 wiremock 을 활용해서 테스트 코드간에 응답을 미리 지정해서

요청을 보낸뒤에 파싱이 잘되는지 확인해 보았다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

소스 코드는 레포지토리에서 확인 가능하다.

파싱이 잘되는지 볼려면... 매번 요청을 보내고 받았어야 했는데.

이렇게 테스트 작성하는 방법을 파악하고 나니

불편함이 많이 줄었다!

[스프링] spring batch 도커로 세팅하기 with jenkins

ImNM — Tue, 7 Mar 2023 15:00:25 +0900

두둥 이벤트 거래정산 파이프라인

두둥 서비스에서는 스프링 배치 + 젠킨스 조합으로

스텝단위가 아닌 잡단위로 파이프라인을 구성해서 처리중이다.

이동욱 님께서 발표하신 내용기반으로

스프링 배치에서 스텝으로 나눈것이 아닌 잡 단위로 만들어서 젠킨스로 파이프 라인을 구성하고있다.

강의 내용중에 스프링 배치 어플리케이션의 버젼이 바뀐경우

항상 최신본을 실행시키기위해 app.jar 를 바라보게 한후에 readlink 로

v1 -> v2.jar 로 바뀌어도 실행 명령어의 변경없이 젠킨스 잡을 돌릴 수 있도록 구성하셨다.

필자는 Api 어플리케이션도 도커로 말아서 배포 중이므로,

배치 어플리케이션도 도커로 말아서 항상 최신본을 실행시킬수 있는 구성을 공유하고자한다.

1. 배치 어플리케이션 도커로 세팅

두둥 프로젝트에서는 멀티 모듈로 사용중이다

도메인 관련 오브젝트들을 API 어플리케이션에도 사용하고, Batch 어플리케이션 둘다 사용가능하다.

// 배치 어플리케이션 그래들
implementation project(':DuDoong-Domain')
implementation project(':DuDoong-Common')
implementation project(':DuDoong-Infrastructure')

위처럼 구성을했고, 배치 어플리케이션을 항상 실행시키는것이아니라,

spring:
  profiles:
    include:
      - infrastructure
      - domain
      - common
      # --job.name=<잡이름> 형태로 파라미터를 넘겨줘서 잡을 실행시킨다.
  batch.job.names: ${job.name:NONE}

잡 단위로 실행시키기 때문에 application.yml을 위와 같이 구성했다.

FROM openjdk:17-alpine

EXPOSE 8080

COPY ./build/libs/*.jar app.jar
ARG PROFILE=dev
ENV PROFILE=${PROFILE}

ENTRYPOINT ["java","-Dspring.profiles.active=${PROFILE}", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Dockerfile은 위와같이 세팅했다.

Api 어플리케이션 도커파일과 같다.

도커를 말아올리는 ci는 github action을 사용중인데

태그기반으로 액션을 트리거 시키고있다.

on:
  push:
    tags:
      - Api-v*.*.*

on:
  push:
    tags:
      - Batch-v*.*.*

Api,Batch 두가지로 시작하는 태그에 반응하도록 하고있고,

RELEASE_VERSION_WITHOUT_V="$(cut -d'v' -f2 <<< ${GITHUB_REF#refs/*/})"

위와같이 Batch-v1.0.0 이라면

도커태그는 {user}/{project}:1.0.0 형식의 도커가 만들어지도록 하고 있다.

태그 릴리즈

깃헙의 릴리즈를 사용해서 태그를 달아주고있다.

2. 젠킨스 글로벌 환경변수 세팅

이동욱님의 배치 어플리케이션 세미나를보면 실행에서 똑같은 부분은 환경변수로 만들어서

중복되는 코드들을 줄이고 있다.

두둥에서도 위와같이 프로덕션용과 스테이징용을 환경변수로 나누어서

실행시키고있다.

latest 태그로 항상 최신버젼을 가져오고있는데 이는 깃헙 action ci 단에서 버젼이 붙은 태그로도 배포하지만,

latest 태그도 항상붙여서 올리고있다.

sudo docker run --pull=always --env-file {환경변수 파일 위치} --net=host {도커이미지}:latest

sudo 를 젠킨스에서 붙일려면

Authentication error in jenkins on using sudo

I have sh script in jenkins which has sudo ssh command and I am getting this error Warning: Identity file key.pem not accessible: Permission denied. Host key verification failed. sudo: no tty pres...

stackoverflow.com

위 내용을 참고하기 바란다.

3. sh 커맨드로 젠킨스 잡 구성하기

${BATCH_PROD_APP} --job.name=슬랙유저통계 date=${TODAY}

위처럼 간단하게 할 수 있다.

추가로 넣어야할 매개변수가 있는경우,

매개변수 추가하기로 넣을 수 있다.

간단하게, 도커로 배치 어플리케이션을 말아올려서,

젠킨스에서 사용하는 방법을 알아보았다.

배치 어플리케이션 관련소스는

두둥 프로젝트에서 확인하실 수 있다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

[스프링] spring thymeleaf to pdf 이미지,한글 적용하기

ImNM — Mon, 6 Mar 2023 17:49:48 +0900

두둥의 정산서 pdf

두둥 프로젝트를 진행하면서

통신 판매 중개업종이므로 , 호스트에게 공연 카드결제 대금

정산 작업도 배치로 돌려야 했는데, 이때 pdf로 정산서를 보내줘야할 일이 생겼다.

두둥에서는 메일도 thymeleaf를 사용해서 보내고 있으므로,

pdf 도 thymeleaf 를 사용해서 보내는 방법으로 결정했다.

이미지와, 한글 적용을 하려면 꽤나 고생좀 해야하는데 그 방법을 공유하고자한다.

1. flying-saucer-pdf

GitHub - flyingsaucerproject/flyingsaucer: XML/XHTML and CSS 2.1 renderer in pure Java

XML/XHTML and CSS 2.1 renderer in pure Java. Contribute to flyingsaucerproject/flyingsaucer development by creating an account on GitHub.

github.com

baeldung 에서도 자세히는 아니지만 대충은 확인 가능하다.

https://www.baeldung.com/thymeleaf-generate-pdf

간단하다. 해당 모듈을 이용해서 thymeleaf 로 html 스트링을 만든뒤에,

render 을 통해서 pdf를 만드는것이 가능하다.

두둥 서버스에서는 outputStream 을 파일로 내려주는게 아니라

ByteStream 으로 만든뒤에,

private S3 에 올리고 나서

이메일 전송용 잡에서 private S3에서 다운로드 받아 이메일로 전송하는 구조를 취하고있다.

// 타임리프 템플릿 엔진에서 settlement.html 파일을 context와 내려준다.
String html = templateEngine.process("settlement", context);
// PdfRender 클래스
@Component
@RequiredArgsConstructor
@Slf4j
public class PdfRender {
    
    public ByteArrayOutputStream generatePdfFromHtml(String html)
            throws DocumentException, IOException {
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        //renderer 설정
        ITextRenderer renderer = new ITextRenderer();

        renderer.getFontResolver();
        renderer.setDocumentFromString(html);
        renderer.layout();
		// PDF 만들어준다.
        renderer.createPDF(outputStream);

        outputStream.close();
        // outputStream 으로 리턴후 S3로 파일업로드를 stream 형태로 올린다.
        return outputStream;
    }
}

타임리프 템플릿 엔진으로 html으로 변환을 한후에,

pdf로 렌더링 한다.

FileOutputStream (Java Platform SE 7 )

Returns the unique FileChannel object associated with this file output stream. The initial position of the returned channel will be equal to the number of bytes written to the file so far unless this stream is in append mode, in which case it will be equal

docs.oracle.com

테스팅 할 때는 아웃풋 스트림을 파일 아웃풋 스트림으로 잡아도 상관없다.

String outputFolder = System.getProperty("user.home") + File.separator + "thymeleaf.pdf";
OutputStream outputStream = new FileOutputStream(outputFolder);
 // 중간 생략
renderer.createPDF(outputStream);

PdfRender 클래스를 만든후에

배치 작업간에 실행시켰다.

2. 한글 적용하기

기본 설정으로는 한글이 나오지 않는다.

따라서 한글이 되는 폰트를 리소스에 넣고 , 해당 한글 폰트를 html에 넣은뒤에

적용을 해야한다.

body {
  width: 100%;
  font-size: 12px;
  font-weight: lighter;
  color:#000;
  line-height:180%;
  font-family: NanumBarunGothic,serif;
}

우선은 폰트는 NanumBarunGothic 으로 정했다.

한글 되는 폰트면 다된다.!

나눔 바른 고딕 치면 다운로드 가능하다 NanumBarunGothic.ttf 로 하면 된다.

그뒤에 render 과정에서 폰트를 정해줘야한다.

renderer.getFontResolver()
	//폰트를 설정한다.
        .addFont(
                new ClassPathResource("/templates/NanumBarunGothic.ttf")
                        .getURL()
                        .toString(),
                BaseFont.IDENTITY_H,
                BaseFont.EMBEDDED);
renderer.setDocumentFromString(html);
renderer.layout();

이렇게 적용해 놓으면 폰트를 심을 수 있다.

3. 이미지 가능하게 하기

이미지를 올릴 수 있는 방법은 크게 두가지가있다.

1. 정적 이미지를 리소스에 포함해서 하는 방법

2. html src url 을 pdf 그리는 과정에서 감지 되는 스트림으로 받아와서 base64로 인코딩한후

html에 직접 포함하는 방법.

1번의 형식은 로컬에서 잘됐는데 도커환경에서 배포를 해보니 pdf 에 이미지가 제대로 안담기는 현상이 일어났다.

또한 파일로 포함해서 올리기는 .. 패키징 사이즈도 커지니 부담스러워서

2번의 방식으로 다시 적용했다.

<img
    width="244"
    alt="en-banner-black"
    src="https://asset.dudoong.com/common/en-banner-black.png"
/>

html 템플릿 안에는 원래대로 src를 적어둔다.

@Component
public class B64ImgReplacedElementFactory implements ReplacedElementFactory {

    public ReplacedElement createReplacedElement(
            LayoutContext c, BlockBox box, UserAgentCallback uac, int cssWidth, int cssHeight) {
        Element e = box.getElement();
        if (e == null) {
            return null;
        }
        String nodeName = e.getNodeName();
        if (nodeName.equals("img")) {
            String attribute = e.getAttribute("src");
            FSImage fsImage;
            try {
                fsImage = buildImage(attribute, uac);
            } catch (BadElementException e1) {
                fsImage = null;
            } catch (IOException e1) {
                fsImage = null;
            }
            if (fsImage != null) {
                if (cssWidth != -1 || cssHeight != -1) {
                    fsImage.scale(cssWidth, cssHeight);
                }
                return new ITextImageElement(fsImage);
            }
        }
        return null;
    }

    protected FSImage buildImage(String srcAttr, UserAgentCallback uac)
            throws IOException, BadElementException {
        FSImage fsImage;
        if (srcAttr.startsWith("data:image/")) {
            String b64encoded =
                    srcAttr.substring(
                            srcAttr.indexOf("base64,") + "base64,".length(), srcAttr.length());

            byte[] decodedBytes = Base64.getDecoder().decode(b64encoded);
            fsImage = new ITextFSImage(Image.getInstance(decodedBytes));
        } else {
            fsImage = uac.getImageResource(srcAttr).getImage();
        }
        return fsImage;
    }

    public void remove(Element e) {}

    public void reset() {}

    @Override
    public void setFormSubmissionListener(FormSubmissionListener listener) {}
}

B64ImgReplacedElementFactory 클래스만든뒤에 img 태그가 발견되면 이미지를 다운로드 받아서

base64 형식으로 바꿔준다.

public class PdfRender {

    private final B64ImgReplacedElementFactory b64ImgReplacedElementFactory;

    public ByteArrayOutputStream generatePdfFromHtml(String html)
            throws DocumentException, IOException {
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        ITextRenderer renderer = new ITextRenderer();
        SharedContext sharedContext = renderer.getSharedContext();
        sharedContext.setPrint(true);
        sharedContext.setInteractive(false);
        sharedContext.setReplacedElementFactory(b64ImgReplacedElementFactory);
        sharedContext.getTextRenderer().setSmoothingThreshold(0);

        renderer.getFontResolver()
                .addFont(
                        new ClassPathResource("/templates/NanumBarunGothic.ttf")
                                .getURL()
                                .toString(),
                        BaseFont.IDENTITY_H,
                        BaseFont.EMBEDDED);
        renderer.setDocumentFromString(html);
        renderer.layout();

        renderer.createPDF(outputStream);

        outputStream.close();
        return outputStream;
    }
}

B64ImgReplacedElementFactory 를 적용하면 이미지도 포함해서 pdf를 랜더링 할 수 있다.

배치잡에서 적용시킨 모습은 다음과 같다.

// Batch App 이벤트 pdf 정산 소스
String html = templateEngine.process("settlement", context);
// html
ByteArrayOutputStream outputStream =
	pdfRender.generatePdfFromHtml(html);

String fileKey =
	s3PrivateFileUploadService.eventSettlementPdfUpload(event.getId(), outputStream);

- pdfRender

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

- B64ImgReplacedElementFactory

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

- settlement.html

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

각각 소스는 위에서 참고 가능하다

[스프링] spring rate limit 적용히기 bucket4j

ImNM — Mon, 6 Mar 2023 15:06:19 +0900

슬랙으로 알림오는 Rate Limit Error

api를 공개하게 되면 유저가 마음대로 요청을 할 수 있다.

프론트 쪽에서는 쓰로틀링으로 막아주긴하지만, 백엔드에서는

추가적으로 요청량을 제한 해야한다.

요청량을 제한하는건 ip기반으로 하게되면,

로드밸런서에서 막아줄수도있고 , nginx 에서도 막아 줄 수 있다.

두둥 프로젝트에서는 유저 아이디 기반으로 요청량을 측정하고 싶어서

서버 내부서 제한을 걸기로 했다.

그 방법을 공유하고자 한다.

1. 문제점

두둥 백엔드 서비스에서는 주문, 재고감소 등 로직간의 동시성 이슈를 해소하기위해서

Redisson 기반 분산락을 사용중이다.

Redisson 기반 분산락에는 타임아웃이 존재하는데,

waitTime 이 지나게 되면 락으로 진입 자체를 못하게 된다.

boolean available = rLock.tryLock(waitTime, leaseTime, timeUnit);

락이라는건 공유자원에 접근 할때 한번에 하나 씩 집어넣는것이므로,

악성유저가 락을 쓰는 api를 계속 요청할 경우 처리하는데 시간이걸리므로 서버 에러가 발생하게 된다.

클라이언트가 작업중이다가... 실제로 계속 api 콜하면서 500번대 응답이 엄청 생긴적이있다.

그래서 쓰로틀링을 유저 아이디 기반으로 서버 쪽에도 넣어야 할것 같아서

Rate Limit 을 적용하기로 했다.

2. bucket4j

GitHub - bucket4j/bucket4j: Java rate limiting library based on token-bucket algorithm.

Java rate limiting library based on token-bucket algorithm. - GitHub - bucket4j/bucket4j: Java rate limiting library based on token-bucket algorithm.

github.com

구현 방식에는 여러 방법이 있을것 같은데,

토큰 알고리즘 을 이용해서 적용하는 방식이다.

[Rate Limit - step 3] Token Bucket 알고리즘 구현 (rate limiting)

필자는 현재 API서버를 열심히 개발 하고 있다. 개발한 서비스가 트래픽을 많이 받다보니, 트래픽을 적절히 제한하지 않았을 때 장애가 발생했고, 그에 따라 API의 Rate Limit을 구현해야 했다. 공부

etloveguitar.tistory.com

버킷 알고리즘에 관련해서는 다른 블로그를 참고하면 좋을것같다.

제일 고민했던 포인트는

High-throughput distributed rate limiter

Production-grade systems usually consist of multiple interconnected components that depend on each other. Popularization of the microservice architect...

engineering.linecorp.com

위와같은 고민이었는데 , 지금은 서버가 한대라 상관없지만 분산 서버 환경에서는

토큰이 얼마나남아있는지 서버 어플리케이션간에 공유할 수 있는 구성이였으면 했다.

(https://github.com/redisson/redisson) / (https://github.com/bucket4j/bucket4j)

그와중에 jcache api 사용가능하고 , redis 연동이 가능한 ( Redisson 이 jcache 를 지원함 ) , bucket4j 를 선택했다.

즉 우리는 jcache api 를 사용해서 레디스를 토큰을 여러 서버에서 공유할 수 있는 메모리 저장소로 사용할 예정이다.

3. 적용하기

3.1. Bucket4j 와 레디스 jcache 로 연결하기

14. Integration with frameworks

Redisson - Redis Java client with features of In-Memory Data Grid. Over 50 Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map...

github.com

Bucket4j 8.1.1 Reference

Question: Why does bucket invoke the listener on the client-side instead of the server-side in case of distributed scenario? What do I need to do if I need an aggregated stat across the whole cluster? Answer: Because of a planned expansion to non-JVM back-

bucket4j.com

위 두 문서를 살펴보면 될것같다.

블로그는 예시 코드일뿐이지 항상 공식 문서 읽는게 좋다.

/** for bucket4j */
// JCache 의 CacheManager를 생성한다.
@Bean
public CacheManager cacheManager(RedissonClient redissonClient) {
    CacheManager manager = Caching.getCachingProvider().getCacheManager();
    Cache<Object, Object> bucket4j = manager.getCache("bucket4j");
    // 테스트 코드에서 깨져서 null check 하고 createCache 를해야함
    if (bucket4j == null) {
        manager.createCache("bucket4j", RedissonConfiguration.fromInstance(redissonClient));
    }
    return manager;
}

/** for bucket4j */
@Bean
ProxyManager<String> proxyManager(CacheManager cacheManager) {
    // JCacheProxyManager 를 생성한다.
    return new JCacheProxyManager<>(cacheManager.getCache("bucket4j"));
}

Redisson 클라이언트가 JCache api 를 지원하고,

JCache 의 ChaceManager를 만든뒤에 해당 캐시 매니저로

Bucket4j 의 JCacheProxyManager을 생성한다.

우린 ProxyManager<String> proxyManger을 빈으로 등록하고 사용할 것이다.

레디스를 캐시 저장소로 활용 하였으니, 다중 서버에서도 토큰 여부를 같이 판단 할 수 있게 되었다.

3.2. ProxyManager 로 버킷 만들기

@Component
@RequiredArgsConstructor
public class UserRateLimiter {
    // autowiring dependencies
    private final ProxyManager<String> buckets;

    @Value("${throttle.overdraft}")
    private long overdraft;

    @Value("${throttle.greedyRefill}")
    private long greedyRefill;

    public Bucket resolveBucket(String key) {
        Supplier<BucketConfiguration> configSupplier = getConfigSupplierForUser();
        return buckets.builder().build(key, configSupplier);  // 1
    }

    private Supplier<BucketConfiguration> getConfigSupplierForUser() {
        Refill refill = Refill.greedy(greedyRefill, Duration.ofMinutes(1));
        Bandwidth limit = Bandwidth.classic(overdraft, refill);
        return () -> (BucketConfiguration.builder().addLimit(limit).build()); //2
    }
}

우선 우린 유저 아이디 기반 Rate Limit 를 걸길 원하고 있으니 ( 두둥 서버에서는 익명 유저일경우에는 아이피 기반으로 걸어버렸다 )

//1 버킷을 유저아이디를 키값으로 만들고, 있으면 리턴을 해준다 build 라고 해서 매번 새로운 버킷을 만들지 않느다.

//2 BucketConfiguration으로 Bandwith 를설정한다. 전략이 여러가지가 있다.

필자는 그리디하게 1분에 몇개를 채우는 정도로 설정해놨다.

전략이 더많으니 공식문서에서 확인하길 바란다.

3.3 인터셉터에 적용하기

3.3.1. 인터셉터에서 유저정보를 불러올려면? SecurityContextHodler

Rate Limit 을 적용하는데는 정말 자유로울 것 같다.

Aop 에 적용해도 되고 , 필터 단에 넣어도 되고,

두둥 프로젝트에서는 우선 글로벌하게 rate limit을 걸고 싶고, 유저 아이디 기반으로 걸고 싶어서

인터셉터에 위치시켰다.

요청이 들어올때에 시큐리티 context에서 유저 아이디 정보를 가져온다.

시큐리티 컨텍스트에서도 사용자에 관련된 정보를 불러올 수 있다.

// 두둥의 시큐리티 유틸 클래스 
public class SecurityUtils {
    private static SimpleGrantedAuthority anonymous = new SimpleGrantedAuthority("ROLE_ANONYMOUS");
    private static SimpleGrantedAuthority swagger = new SimpleGrantedAuthority("ROLE_SWAGGER");

    private static List<SimpleGrantedAuthority> notUserAuthority = List.of(anonymous, swagger);

    public static Long getCurrentUserId() {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if (authentication == null) {
            throw SecurityContextNotFoundException.EXCEPTION;
        }
        if (authentication.isAuthenticated()
                && !CollectionUtils.containsAny(
                        authentication.getAuthorities(), notUserAuthority)) {
            return Long.valueOf(authentication.getName());
        }
        // 스웨거 유저일시 익명 유저 취급
        // 익명유저시 userId 0 반환
        return 0L;
    }
}

위처럼 요청마다 쓰레드 로컬에 인증 관련정보가 저장되어서 요청마다 SecurityContextHodler에서

인증정보를 가져올 수 있는데, ( 마치 트랜잭션 쓰레드 로컬과 비슷하다 )

익명 유저도 값을 꺼내올 수 있다는 조건이있어,

(익명 유저는 비 인증 api 인 경우 시큐리티 필터를 통과하면 익명 유저이다 )

익명유저와 스웨거 유저( 스웨거에 비밀번호를 걸기위해서 Basic auth 를 설정한 상태임 ) 이면 유저아이디 0을 리턴하도록 했다.

3.3.2 인터셉터에 적용해보자.

@Component
@RequiredArgsConstructor
@Slf4j
public class ThrottlingInterceptor implements HandlerInterceptor {

    private final UserRateLimiter userRateLimiter;
    private final IPRateLimiter ipRateLimiter;
    private final ObjectMapper objectMapper;

    private final SlackThrottleErrorSender slackThrottleErrorSender;

    @Override
    public boolean preHandle(
            HttpServletRequest request, HttpServletResponse response, Object handler)
            throws IOException {
        Long userId = SecurityUtils.getCurrentUserId();
        Bucket bucket;
        if (userId == 0L) {
            // 익명 유저 ip 기반처리
            String remoteAddr = request.getRemoteAddr();
            bucket = ipRateLimiter.resolveBucket(remoteAddr);
        } else {
            // 비 익명 유저 유저 아이디 기반 처리
            bucket = userRateLimiter.resolveBucket(userId.toString());
        }

        if (bucket.tryConsume(1)) {
            return true;
        }
        // 슬랙 알림 메시지 발송.
        // limit is exceeded
        ContentCachingRequestWrapper cachingRequest = (ContentCachingRequestWrapper) request;
        slackThrottleErrorSender.execute(cachingRequest, userId);
        responseTooManyRequestError(request, response);

        return false;
    }

간단하다

익명 유저와 스웨거 유저일 경우 ip 기반으로,

비 익명 유저일 경우 유저 아이디 기반으로 Rate Limit 을 적용했다.

익명 유저는 비인증 api 일경우 시큐리티는 익명유저로판단한다.

추가적으로 두둥에서는 슬랙으로 알림도 전송한다.

이글에서 중요한점은 redis client인 redisson 이 jcahce api를 지원한다는점,

이를 이용해서 bucket4j 를 연동 할 수 있다는점.

redis 를 활용해서 토큰의 공유 저장소로 활용해서 분산 서버에 적용가능하다는 점.

이 세가지 정도일것같다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

이글의 소스는 위 레포지토레이서 참고 가능하다.

굳이 서버에서도 Rate Limit 처리를 안해도

aws로드밸런서나 nginx에도 처리가 가능하니,

유저아이디 기반으로 처리할게 아니라면

다른 방식을 추천 드리고싶다.

토큰 공유저장소로 레디스는 속도가 빠르긴 하지만, 진짜 몸집이 커지게되면 위 라인 블로그와 같은 방식을 고려해야할것같다.

[스프링] spring 프록시 환경에서 HttpContentCache 적용

ImNM — Mon, 6 Mar 2023 01:54:38 +0900

두둥 백엔드에서는 에러로그를 cloudWatch 로도 전송하면서,

실시간으로 500번대 알림을 받아보기 위해서 슬랙으로 비동기적으로 에러를 전송하고 있다.

하지만 스프링은 한번 깐 body의 값을 볼 수 없어서

ContentCachingRequestWrapper (Spring Framework 6.0.6 API)

handleContentOverflow protected void handleContentOverflow(int contentCacheLimit) Template method for handling a content overflow: specifically, a request body being read that exceeds the specified content cache limit. The default implementation is empt

docs.spring.io

위 처럼 ContentCachingRequest/ResponseWrapper을 사용해서

복사를 해둔뒤에 꺼내서 쓴다.

적용하는 방법은 간단하다.

필터에서 캐싱을 적용하면된다.

@Component
public class HttpContentCacheFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(
            HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        ContentCachingRequestWrapper wrappingRequest = new ContentCachingRequestWrapper(request);
        ContentCachingResponseWrapper wrappingResponse =
                new ContentCachingResponseWrapper(response);

        chain.doFilter(wrappingRequest, wrappingResponse);

        wrappingResponse.copyBodyToResponse();
    }
}

다만 프록시 환경에서는 필터의 순서 때문에 필요한곳에서 ContentCachingRequestWrapper 로 캐싱을 해줄때에,

에러가 나는 경우가있다.

그 해결방법을 공유하려고 한다.

fix : x-forward 필터로 인한 ContentCachingRequestWrapper 캐스팅 오류 해결 by ImNM · Pull Request #267 · Gosrock/Du

개요 close #266 작업사항 500 번대 오류시 슬랙 알림이 서버에서 안오더라고요? 보니깐 proxy 로 nginx 달려있으니 x-Forward 헤더 가 넘어오는데 이때 ForwardedHeaderFilter가 동작해 버리더라고요 위 필터가

github.com

이 글 내용은 위 pr을 기반으로 한다.

1. 문제점

final ContentCachingRequestWrapper cachingRequest = (ContentCachingRequestWrapper) request;

에러를 슬랙으로 바디 정보를 함께 전송할려면 GlobalExceptionHandler 에서

@ExceptionHandler(Exception.class)
protected ResponseEntity<ErrorResponse> handleException(Exception e, HttpServletRequest request)
        throws IOException {
    final ContentCachingRequestWrapper cachingRequest = (ContentCachingRequestWrapper) request;

비즈니스적으로 처리하지못한 500번대인 Exception 을 잡아서 처리해야할때

HttpServletRequest 를 다시 ContentCachingRequestWrapper로 캐스팅 해야한다.

로컬에서 개발할때는 전혀 문제가 없었다.

하지만 두둥서버는 nginx 안에서 프록시 되어있는 환경이였는데, 어느날

java.lang.ClassCastException: 
class org.springframework.web.filter.ForwardedHeaderFilter$ForwardedHeaderExtractingRequest 
cannot be cast to class org.springframework.web.util.ContentCachingRequestWrapper

위와 같은 오류가 발생 했다.

즉 ForwardedHeaderExtractionRequest 로 request가 넘어와서 캐스팅 할 수 없었던 문제였다.

ForwardedHeaderFilter를 찾아가서 발동 조건을 살펴보았다.

// FORWARDED_HEADER_NAMES
FORWARDED_HEADER_NAMES.add("Forwarded");
FORWARDED_HEADER_NAMES.add("X-Forwarded-Host");
FORWARDED_HEADER_NAMES.add("X-Forwarded-Port");
FORWARDED_HEADER_NAMES.add("X-Forwarded-Proto");
FORWARDED_HEADER_NAMES.add("X-Forwarded-Prefix");
FORWARDED_HEADER_NAMES.add("X-Forwarded-Ssl");
FORWARDED_HEADER_NAMES.add("X-Forwarded-For");

@Override
protected boolean shouldNotFilter(HttpServletRequest request) {
   for (String headerName : FORWARDED_HEADER_NAMES) {
      if (request.getHeader(headerName) != null) {
         return false;
      }
   }
   return true;
}

즉 위 헤더가 포함 되어있을 때 필터가 작동하는 것이다.

그럼 nginx는? 요청을 upstream server로 넘겨줄 때 어떤 헤더를 넘겨주길래 저렇게 작동할까. 봤다.

(https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/)

X- 종류말고도 , remote_addr 등의 정보를 헤더에 담아 upstream으로 넘겨주는것을 알 수 있다.

위와같은 조건들로 인해서. ForwardedHeaderFilter 가 작동하게 된것이다.

로컬에서는 작동하지 않았던 ForwardedHeaderFilter 가 작동하게되면서 캐스팅오류가 난것을 알 수 있었다.

그럼 , 캐스팅 오류는 왜 일어난게 된걸까?

정답은 필터의 순서 때문이다.

서블릿 필터체인

내가 만들었던 HttpContentCacheFilter가 ForwardedHeaderFilter 앞에있다.

해결방법을 알았다.

ForwardedHeaderFilter 필터가 HttpContentCacheFilter 보다 앞에오게하면,

최종적으로 에러 핸들어에서 넘어오는 HttpRequest는 ContentCachingRequestWrapper 타입일것이 명확하다.

2. 개선하기

2.1. 스프링 시큐리티 처럼 필터 조정하면되는거아니야?

자연스럽게... 생각할수 있을것같다. 나도 그랬다.

@RequiredArgsConstructor
@Component
public class FilterConfig
        extends SecurityConfigurerAdapter<DefaultSecurityFilterChain, HttpSecurity> {

    private final JwtTokenFilter jwtTokenFilter;
    private final JwtExceptionFilter jwtExceptionFilter;
    private final HttpContentCacheFilter httpContentCacheFilter;

    @Override
    public void configure(HttpSecurity builder) {
        builder.addFilterBefore(jwtTokenFilter, BasicAuthenticationFilter.class);
        builder.addFilterBefore(jwtExceptionFilter, JwtTokenFilter.class);
        // ForwardedHeaderFilter뒤에 놓으면되네!
        builder.addFilterBefore(httpContentCacheFilter, ForwardedHeaderFilter.class);
    }
}

위와 같이하면 안된다.

서블릿 필터체인

위 사진의 형광색 놓인 부분이 보이는가? DelegatingFilterProxy를 지나게되면서

스프링 시큐리티의 가상의 필터가 시작된다.

FilterChainProxy$VirtualFilterChain

3번의 서블릿 필터를 거치면서 ->

바로 위사진의 스프링 시큐리티의 로직이 수행되고 ->

4번의 필터로 돌아와서 수행된다.

위코드처럼 설정을 한다는것은, 그냥 스프링 시큐리티 내부에서 위치를 바꾸는것이다.

ForwardedHeaderFilter은 서블릿의 필터다.

그럼 우린.. 다른 방법을 알아봐야한다.

2.2 오더로 적용하기

서블릿 필터의 순서를 적용하는방법은 @Order 라는 어노테이션을 활용하는 방법이다.

@Order(Integer.MAX_VALUE)
@Component
public class HttpContentCacheFilter extends OncePerRequestFilter {

위 방식으로 Order을 지정하면 끝난다. 가아니라 이것도 안된다..

나는 맨 마지막 순서로 가길 원하는데...하나도 안움직인다.

Filter order in spring-boot

How can I specify order of my Filter in spring-boot? I need to insert my MDC filter after Spring Security filter. I tried almost everything but my filter was always first. This didn't work: @Bean ...

stackoverflow.com

그 이유는 위에서 찾아볼 수 있다.
스프링 시큐리티도, ForwardedHeaderFilter도 아무 순서를 지정하지 않아서, 맨 뒤로 배정이 된다.

아무 지정을 안하게되면 컴파일 순서로 배정되는것 같은데, 지멋대로다..

그래서 직접 순서를 재조정해야하는 작업이 필요하다.

@Configuration
@RequiredArgsConstructor
@Profile({"prod", "staging", "dev"})
public class ServletFilterConfig implements WebMvcConfigurer {

    private final HttpContentCacheFilter httpContentCacheFilter;
    private final ForwardedHeaderFilter forwardedHeaderFilter;

    @Bean
    public FilterRegistrationBean securityFilterChain(
            @Qualifier(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME)
                    Filter securityFilter) {
        FilterRegistrationBean registration = new FilterRegistrationBean(securityFilter);
        registration.setOrder(Integer.MAX_VALUE - 3);
        registration.setName(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME);
        return registration;
    }

    @Bean
    public FilterRegistrationBean setResourceUrlEncodingFilter() {
        FilterRegistrationBean registrationBean = new FilterRegistrationBean();
        registrationBean.setFilter(new ResourceUrlEncodingFilter());
        registrationBean.setOrder(Integer.MAX_VALUE - 2);
        return registrationBean;
    }

    @Bean
    public FilterRegistrationBean setForwardedHeaderFilterOrder() {
        FilterRegistrationBean registrationBean = new FilterRegistrationBean();
        registrationBean.setFilter(forwardedHeaderFilter);
        registrationBean.setOrder(Integer.MAX_VALUE - 1);
        return registrationBean;
    }

    @Bean
    public FilterRegistrationBean setHttpContentCacheFilterOrder() {
        FilterRegistrationBean registrationBean = new FilterRegistrationBean();
        registrationBean.setFilter(httpContentCacheFilter);
        registrationBean.setOrder(Integer.MAX_VALUE);
        return registrationBean;
    }
}

위방식을 활용해서 필터의 위치를 재조정 시킬 수 있다

사진처럼 우리가 원하는 위치에 필터들이 재조정되는 것을 볼 수 있다.

이로써, 프록시 환경에서 ContentCache 필터를 적용하는 방법을 찾아내서 적용시켰다.

이문제를 해결할려고 디버거를 거의 하루 왼종일 돌렸었던것 같다.

덕분에 스프링 시큐리티의 필터와 , 서블릿 필터간의 작동 방식을 알 수 있었다.

위 사진에 7,8,9번도 사실 내가 커스텀해서 적용한 필터들이다.

@Component 어노테이션으로 빈으로 등록해서 사용중인 컴포넌트들인데,

해당 필터들은 스프링 시큐리티 필터에서도 등록되어 사용되어지고있다.

그럼 두번 동작하는게 아닌가 의문점이 들수 있지만

OnecPerRequestFilter를 상속받아 사용하고 있으니 문제가 없을것같다.

이걸 보니 시큐리티 FilterConfig 에서 di를 받을게 아니라 생성자로 생성해야하나? 의문점이 들긴하다.

위 소스들 은 아래 레포지토리에서 참고 가능하다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

[스프링] spring swagger 같은 코드 여러 에러 응답 예시 만들기

ImNM — Mon, 6 Mar 2023 00:03:36 +0900

스웨거 같은코드 여러 에러응답 예시

[스프링] error code 도메인 별 분리하기

두둥 프로젝트에서는 처리중에 에러가 발생할경우 RuntimeException 을 상속받은 DuDoongException 에서 다시 상속받아서 코드별 에러클래스를 만들고 있다. @Getter @AllArgsConstructor public class DuDoongCodeExceptio

devnm.tistory.com

지난 글에서는 error code를 도메인별로 분할하는 작업을 진행했었다.

이번 글에서는 위와 같이 클라이언트들이 에러에대해 보기 쉽도록 나열을 하는 방법을

공유하고자 한다.

1. 문제점

로직 처리중에 에러를 내뱉게되어서 400번대로 응답을 해주게 되면, 클라이언트도

해당 api 를 사용할 때 어떤 때 해당 오류가 나는것인지 알아야 될 때가 있다.

@ApiResponses(
      value = {
           @ApiResponse(
               responseCode = "201",
               description = "이전까지 회원가입을 하지 않았던 경우",
               content = @Content(
                   schema = @Schema(implementation = AfterOauthResponse.class)))
                     
           @ApiResponse(
               responseCode = "200",
               description = "이미 회원가입을 했던 유저인 경우",
               content = @Content(
                    schema = @Schema(implementation = AfterOauthResponse.class)))
})

그래서 별도로 스웨거로 문서화 하기 위해서 스웨거 앞에 위와같은 형식으로 값을 적어주게 된다.

여기서 매우 복잡아진다.

에러 코드를 enum 으로 기술을 했음에도,

우리는 별도로 문서작업을 또 해야한다.

또한 클라이언트가 주문 도메인에있는 에러 코드들 문서로 뽑아주세요~ 요청하는 순간..

눈물이 앞을 가린다. 계속 바뀔텐데 이중 삼중으로 해야한다..

그래서 필자가 이미 만들어놨던 에러코드 이넘값들을 클라이언트에게

스웨거로 보여주는 방식을 고민해 보았다.

2. 에러 코드를 일일히 적지 않고 어떻게 옮길 수 있을까.

[스프링] spring swagger api 하나만 인증 풀기

두둥 서비스 백엔드에서는 api 문서로 open api swagger를 사용중이다. 스웨거를 조금 커스텀하게 하면, 덕지덕지 붙는 어노테이션의 양을 줄일 수 있는데, 커스텀 어노테이션을 만들어서 리플랙션으

devnm.tistory.com

위 글에선, 어노테이션과 리플렉션을 사용해서 스웨거로 보내질 정보인

Operation 객체를 적절히 커스텀하여, 스웨거 인증을 하나만 풀게끔 하는 방법을 공유했다.

마찬가지로, 우리는 어노테이션과 리플렉션을 사용해서

별도의 example/{domain} 형식의 api 를 만든뒤에

커스텀 어노테이션을 에러코드 정보와 함께 기술해서,

OperationCustomizer 에서 해당 커스텀 어노테이션이 붙은 api라면

Operation 정보에 응답 코드와 그 예시들을 보여줄 것이다.

3. 스웨거 타입 분석

GitHub - OAI/OpenAPI-Specification: The OpenAPI Specification Repository

The OpenAPI Specification Repository. Contribute to OAI/OpenAPI-Specification development by creating an account on GitHub.

github.com

우리가 커스텀 하게될 부분은

Responses 안에 있는 Response 객체이다.

공식 문서에 의하면 Responses 클래스 안에는 Response 클래스 형식을 가지는 필드들이있다.

// Operation 중 responses 필드
"responses": {
    "200": { // Response
      "description": "Pet updated.",
      "content": {
        "application/json": {},
        "application/xml": {}
      }
    },
    "405": { // Response
      "description": "Method Not Allowed",
      "content": {
        "application/json": {},
        "application/xml": {}
      }
    }
  },

"200" : <Response>

"400" : <Response>

위와 같은 형식이다.

content 안에 application/json 형식안에 있는 객체는 Media Type Object 이다

GitHub - OAI/OpenAPI-Specification: The OpenAPI Specification Repository

The OpenAPI Specification Repository. Contribute to OAI/OpenAPI-Specification development by creating an account on GitHub.

github.com

// Media Type Object
{
  "application/json": {
    "schema": {
         "$ref": "#/components/schemas/Pet"
    },
    "examples": {
      "cat" : {
        "summary": "An example of a cat",
        "value": 
          {
            "name": "Fluffy",
            "petType": "Cat",
            "color": "White",
            "gender": "male",
            "breed": "Persian"
          }
      },
      "dog": {
        "summary": "An example of a dog with a cat's name",
        "value" :  { 
          "name": "Puma",
          "petType": "Dog",
          "color": "Black",
          "gender": "Female",
          "breed": "Mixed"
        }
      }
    }
  }
}

Media Type Object 안에

examplse 안에는 Example Object 가 올수 있는데

GitHub - OAI/OpenAPI-Specification: The OpenAPI Specification Repository

The OpenAPI Specification Repository. Contribute to OAI/OpenAPI-Specification development by creating an account on GitHub.

github.com

우린 summary 와, value 값을 도메인별 ErrorCode enum 에서 가져와서 예시로 적어줄 것이다

사진을 보면 좀더 이해하기에 쉬울것같다.

4. 적용하기

4.1. 커스텀 어노테이션 생성

우선 커스텀 어노테이션을 만들어보자.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiErrorCodeExample {
    Class<? extends BaseErrorCode> value();
}
//ex
@ApiErrorCodeExample(UserErrorCode.class)
public void getUserErrorCode() {}

ApiErrorCodeExample 어노테이션을 만들고, 안에 value는 BassErrorCode 를 확장시킨 타입의 Class만 받도록 하였다.

적용시킨모습은 위의 예시 와 같다.

4.2. 커스텀 어노테이션 정보를 가져오기

//SwaggerConfig.java
@Bean
public OperationCustomizer customize() {
    return (Operation operation, HandlerMethod handlerMethod) -> {
        ApiErrorCodeExample apiErrorCodeExample =
                handlerMethod.getMethodAnnotation(ApiErrorCodeExample.class);
        // ApiErrorCodeExample 어노테이션 단 메소드 적용
        if (apiErrorCodeExample != null) {
            generateErrorCodeResponseExample(operation, apiErrorCodeExample.value());
        }
        return operation;
    };
}

위처럼 리플랙션을 사용해서 해당메서드의 ApiErrorCodeExample 어노테이션이 달려있다면

스웨거 예시 응답값의 커스텀을 진행한다.

중요한점은 apiErrorCodeExample.value() 로 BaseErrorCode 타입의 예시를 가져올 수 있다는 점이다.

4.3. 스웨거 예시 응답값 커스텀

private void generateErrorCodeResponseExample(
        Operation operation, Class<? extends BaseErrorCode> type) {
    ApiResponses responses = operation.getResponses();
	// 해당 이넘에 선언된 에러코드들의 목록을 가져옵니다.
    BaseErrorCode[] errorCodes = type.getEnumConstants();
	// 400, 401, 404 등 에러코드의 상태코드들로 리스트로 모읍니다.
    // 400 같은 상태코드에 여러 에러코드들이 있을 수 있습니다.
    Map<Integer, List<ExampleHolder>> statusWithExampleHolders =
            Arrays.stream(errorCodes)
                    .map(
                            baseErrorCode -> {
                                try {
                                    ErrorReason errorReason = baseErrorCode.getErrorReason();
                                    return ExampleHolder.builder()
                                            .holder(
                                                    getSwaggerExample(
                                                            baseErrorCode.getExplainError(),
                                                            errorReason))
                                            .code(errorReason.getStatus())
                                            .name(errorReason.getCode())
                                            .build();
                                } catch (NoSuchFieldException e) {
                                    throw new RuntimeException(e);
                                }
                            })
                    .collect(groupingBy(ExampleHolder::getCode));
	// response 객체들을 responses 에 넣습니다.
    addExamplesToResponses(responses, statusWithExampleHolders);
}
//ExampleHolder
@Getter
@Builder
public class ExampleHolder {
	// 스웨거의 Example 객체입니다. 위 스웨거 분석의 Example Object 참고.
    private Example holder;
    private String name;
    private int code;
}
//
private Example getSwaggerExample(String value, ErrorReason errorReason) {
//ErrorResponse 는 클라이언트한 실제 응답하는 공통 에러 응답 객체입니다.
    ErrorResponse errorResponse = new ErrorResponse(errorReason, "요청시 패스정보입니다.");
    Example example = new Example();
    example.description(value);
    example.setValue(errorResponse);
    return example;
}

위에서 스웨거의 응답값을 분석한대로.

400번대 상태코드에는 여러개의 Example Object 가 올수 있다.

private void addExamplesToResponses(
        ApiResponses responses, Map<Integer, List<ExampleHolder>> statusWithExampleHolders) {
    statusWithExampleHolders.forEach(
            (status, v) -> {
                Content content = new Content();
                MediaType mediaType = new MediaType();
                // 상태 코드마다 ApiResponse을 생성합니다. 
                ApiResponse apiResponse = new ApiResponse();
                //  List<ExampleHolder> 를 순회하며, mediaType 객체에 예시값을 추가합니다.
                v.forEach(
                        exampleHolder -> mediaType.addExamples(
                                exampleHolder.getName(), exampleHolder.getHolder()));
                // ApiResponse 의 content 에 mediaType을 추가합니다.
                content.addMediaType("application/json", mediaType);
                apiResponse.setContent(content);
                // 상태코드를 key 값으로 responses 에 추가합니다.
                responses.addApiResponse(status.toString(), apiResponse);
            });
}

위와같은 형식으로 상태코드를 기준으로 예시객체들을 모은뒤에,

ApiResponses 객체에 넣어주는, 구성으로 돌아간다.

더 복잡아질것같아서 뺀 이야기지만, 두둥에서는

해당 설명을 더 적어주고 싶을땐, ExplainError 라는 커스텀 어노테이션을 만들어서

위처럼 예시 설명을 적어두고 있다.

public enum UserErrorCode implements BaseErrorCode {
    @ExplainError("회원가입시에 이미 회원가입한 유저일시 발생하는 오류. 회원가입전엔 항상 register valid check 를 해주세요")
    USER_ALREADY_SIGNUP(BAD_REQUEST, "USER_400_1", "이미 회원가입한 유저입니다."),
    @Override
    public String getExplainError() throws NoSuchFieldException {
        Field field = this.getClass().getField(this.name());
        ExplainError annotation = field.getAnnotation(ExplainError.class);
        return Objects.nonNull(annotation) ? annotation.value() : this.getReason();
}

사실 소스보다 더 중요한것은 스웨거가 어떤 구조로 되어있는가를 파악해야 한다.

어느 백엔드 프레임워크를 쓰던, 스웨거는 공통의 json 형식을 받아서 렌더링을 해준다.

스프링이면, 스프링. nestjs면 nestjs 결국 해당 프레임워크에서

어떻게 json 형식을 만들어 주냐에 따라서 달라질 뿐이지.

view에서 받는 정보는 다 같다.

스웨거의 구조를 이해하시면 좀더 커스텀하기 편하실것 같다.

위 소스는 아래 레포지토리에서 참고 가능하다.

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

모두를 위한 새로운 공연 라이프, 두둥! Contribute to Gosrock/DuDoong-Backend development by creating an account on GitHub.

github.com

이찬진 컴퓨터 교실

[Nextjs] Sharp Missing In Production ( memory leak 이슈 )

목차

에러 원인찾기 : 도커 event ,syslog

이유가 뭘까 : 이미지처리

해결하기 : sharp install

근데 왜 squoosh가 문제일까?

[스프링] spring redisson 분산락 Aop 적용기

목차

1. 두둥의 분산락 구성

2. IllegalMonitorStateException

2.1. 왜 IllegalMonitorStateException 이 발생하나요?

3. 동시성을 테스팅을 디비를 안거쳐도 되지않을까

4. 동시성 실패 테스트를 만들고 싶다면?

5. 두둥에서 동시성 테스트를 하는 방법

6. 왜 트랜잭션 전파속성이 REQUIRES_NEW 여야하지..

7. 새로운 트랜잭션으로 인해서, 정보가 새로 안받아와져요. ( mapper 레이어 에서 처리 )

[스프링] 멀티모듈 jacoco , sonarqube (cloud) 세팅

목차

1. 전체적인 구성방식

2. jacoco 세팅하기

3. sonarqube 설정하기

3.1. 소나 클라우드 관련

3.2. 그래들 관련

3.3. 깃헙 액션

[스프링] spring oauth Open ID Connect with kakao

목차

1. 문제점

1.1. Oauth AccessToken을 이용하는 여러가지 해결방안

1.2. Oauth AccessToken으로 회원가입 할 때의 문제점

2. Open ID Connect ( OIDC )

3. 적용하기

3.1. 공개키 목록 조회하기 , feign으로 캐싱하기

3.2. ID 토큰 유효성 검증하기

3.2.1 서명 검증전 페이로드 검증

3.2.2 서명 검증하기

[스프링] spring feign client wiremock test

목차

1. wiremock

2. 적용하기

2.1. feign client

2.2. 테스트 코드 작성하기

[스프링] spring batch 도커로 세팅하기 with jenkins

목차

1. 배치 어플리케이션 도커로 세팅

2. 젠킨스 글로벌 환경변수 세팅

3. sh 커맨드로 젠킨스 잡 구성하기

[스프링] spring thymeleaf to pdf 이미지,한글 적용하기

목차

1. flying-saucer-pdf

2. 한글 적용하기

3. 이미지 가능하게 하기

[스프링] spring rate limit 적용히기 bucket4j

목차

1. 문제점

2. bucket4j

3. 적용하기

3.1. Bucket4j 와 레디스 jcache 로 연결하기

3.2. ProxyManager 로 버킷 만들기

3.3 인터셉터에 적용하기

3.3.1. 인터셉터에서 유저정보를 불러올려면? SecurityContextHodler

3.3.2 인터셉터에 적용해보자.

[스프링] spring 프록시 환경에서 HttpContentCache 적용

목차

1. 문제점

2. 개선하기

2.1. 스프링 시큐리티 처럼 필터 조정하면되는거아니야?

2.2 오더로 적용하기

[스프링] spring swagger 같은 코드 여러 에러 응답 예시 만들기

목차

1. 문제점

2. 에러 코드를 일일히 적지 않고 어떻게 옮길 수 있을까.

3. 스웨거 타입 분석

4. 적용하기

4.1. 커스텀 어노테이션 생성

4.2. 커스텀 어노테이션 정보를 가져오기

4.3. 스웨거 예시 응답값 커스텀