🏎️ [성능개선] N페이 승인 대사 속도 개선

개요

승인 대사란 PG사의 승인 및 취소된 데이터와 당사에서 관리되는 데이터의 일치 여부를 확인하는 작업이에요.

PG란 Payment Gateway의 약자로 온라인 결제 대행사를 뜻해요.

승인대사의 중요성

1. 무결성 확보: 결제 승인대사는 고객이 결제한 금액과 실제로 승인된 금액이 일치하는지 확인함으로써 데이터의 무결성을 보장해요.
2. 오류 발견 및 수정: 결제 과정에서 발생할 수 있는 오류나 불일치를 조기에 발견하여 수정할 수 있어요. 예를 들어, 고객이 결제한 금액과 PG사에서 승인된 금액이 다를 경우, 이를 신속하게 찾아내어 적절한 조치를 취할 수 있어요.
3. 재무 정보 신뢰성 향상: 승인대사를 통해 확보된 정확한 데이터는 기업의 재무 정보가 신뢰할 수 있는 상태로 유지되도록 해요. 이는 경영진이 올바른 의사 결정을 내리는 데 도움을 주며, 외부 감사나 규제 기관의 요구에도 적절히 대응할 수 있어요.

이번 승인 대사 개선 건은 네이버 페이 결제 수단의 승인 대사에서 유독 속도가 지연되고 있어 개선하고자 했어요.

AS-IS

기존의 경우 승인 대사 배치 속도는 최대 23390ms, 최소 29ms, 평균 3442.143ms를 기록하고 있어요. 위의 통계 데이터는 이번에 개선하고자한 승인 대사 뿐만 아니라 다양한 결제 수단에 대한 통계 수치에요. 저희 서비스에서는 하나의 API로 다양한 결제 수단 승인 대사가 배치로 이루어지고 있어요. 하나의 API로 이루어지고 있지만, 저희 시스템에서는 L사 모니터링 솔루션을 통해 특정 승인대사의 모니터링이 가능해요.

여기서 24초에 근접한 포인트가 바로 이번에 개선하려는 결제 수단이에요. 다른 결제 수단의 승인 대사에 비해 월등히 높은 수치를 기록하고 있어요.

해당 결제 수단의 승인 대사는 벌크(bulk)로 대량의 데이터를 가져와 처리하는 것이 아니라 페이지네이션 API를 통한 데이터를 수집하여 반복문을 통해 API를 호출하고 있어요(우측 하단 부분의 빨간 네모 상자들이 API 호출을 의미해요). 이로 인해 수 천 건 이상의 데이터를 한번에 가져오는 것이 아닌, 수 천 건에서 페이지네이션된 개수만큼 한 페이지, 한 페이지 호출하여 데이터를 수집해 지연(delay) 되는 시간이 길어 발생된 이유였어요.

TO-BE

우선 해당 결제 수단의 승인 대사 API가 벌크 API를 제공하는지 여부를 확인했어요. 벌크 API를 제공한다면 페이지마다 반복문을 통해 API를 호출하지 않아 서비스 속도 향상을 기대할 수 있었기 때문이에요. 하지만 벌크 API를 제공하지 않아 해당안으로는 진행할 수 없었어요.

다음 안으로는 비동기 API호출이었어요. 한 페이지마다 API Response를 대기하지 않고 비동기로 호출한다면 벌크 API와 비슷한 성능을 기대할 수 있었어요. 따라서 비동기 API를 호출하여 모든 페이지의 Response가 올 때 까지 대기 이후 데이터를 처리하는 방향으로 진행하기로 결정했어요.

기존 코드

기존의 코드는 다음과 같은 형태를 띄고 있었어요.

import org.junit.jupiter.api.Test;

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

import static org.assertj.core.api.Assertions.assertThat;

public class AsyncCallTest {
    private static class Response {}

    private static class ApiResponse {
        int totalPage;
        int currentPage;

        public ApiResponse(int currentPage, int totalPage) {
            this.currentPage = currentPage;
            this.totalPage = totalPage;
        }
    }

    private static final Random RANDOM = new Random();

    @Test
    void asIs() {
        List<Response> result = new ArrayList<>();
        List<ApiResponse> apiResponses = new ArrayList<>();
        final int START_PAGE = 1;

        // 최초 1회 API 호출하여 전체 페이지 수 획득
        ApiResponse firtApiResponse = this.apiCall(START_PAGE);
        apiResponses.add(firtApiResponse);

        // 전체 페이지 수 만큼 API 호출
        for (int i = START_PAGE + 1; i <= firtApiResponse.totalPage; i++) {
            apiResponses.add(this.apiCall(i));
        }

        // 승인 대사 진행
        for (ApiResponse apiResponse : apiResponses) {
            result.add(this.logic(apiResponse));
        }

        assertThat(result).hasSize(10);
    }

    private ApiResponse apiCall(int page) {
        try {
            Thread.sleep(RANDOM.nextInt(1000, 3000));
            final int TOTAL_PAGE = 10;
            return new ApiResponse(page, TOTAL_PAGE);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    private Response logic(ApiResponse apiResponse) {
        // 승인 대사 진행 DB 작업 (Insert, Update)
        return new Response();
    }
}

✅ Tests passed: 1 of 1 test - 20 sec 59 ms

[API 호출] Current Page: 1 Thread: Test worker
[API 호출] Current Page: 2 Thread: Test worker
[API 호출] Current Page: 3 Thread: Test worker
[API 호출] Current Page: 4 Thread: Test worker
[API 호출] Current Page: 5 Thread: Test worker
[API 호출] Current Page: 6 Thread: Test worker
[API 호출] Current Page: 7 Thread: Test worker
[API 호출] Current Page: 8 Thread: Test worker
[API 호출] Current Page: 9 Thread: Test worker
[API 호출] Current Page: 10 Thread: Test worker
[승인 대사 진행] Current Page: 1 Thread: Test worker
[승인 대사 진행] Current Page: 2 Thread: Test worker
[승인 대사 진행] Current Page: 3 Thread: Test worker
[승인 대사 진행] Current Page: 4 Thread: Test worker
[승인 대사 진행] Current Page: 5 Thread: Test worker
[승인 대사 진행] Current Page: 6 Thread: Test worker
[승인 대사 진행] Current Page: 7 Thread: Test worker
[승인 대사 진행] Current Page: 8 Thread: Test worker
[승인 대사 진행] Current Page: 9 Thread: Test worker
[승인 대사 진행] Current Page: 10 Thread: Test worker

실제 로직은 승인 대사 데이터 기간을 설정하고 API 호출에 필요한 Header를 셋팅 하는 등 더 복잡하지만, 간략하게 핵심 내용만 추리기 위해 작성해보았어요.

apiCall을 통해 승인대사 API를 호출하면, 1~3초 정도 걸린다는 가정하에 작성하였으며, ApiResponse를 통해 전체 페이지 수가 얼마인지 표기해주어요. 현재 코드에서는 10페이지를 가정하여 작성했어요.

최초 1회 API 호출을 통해 전체 페이지 수를 얻고, 반복문을 통해 API를 호출해요. 이 경우 최악의 경우에 모든 API가 3초의 소요시간이 걸린다면 서비스 시간은 API 호출 30초 + 승인대사 데이터 처리 시간으로 30초 이상 걸릴 수 있어요.

따라서 반복문을 통해 승인 대사를 진행하는 부분을 비동기 처리로 개선하고자 하였어요.

개선 코드

@Test
void toBe() {
    List<Response> result = this.asyncApiCall() // 비동기 API 호출
            .stream()
            .map(this::logic) // 승인 대사 진행
            .collect(Collectors.toList());;

    assertThat(result).hasSize(10);
}

private List<ApiResponse> asyncApiCall() {
    final int START_PAGE = 1;
    final int SECOND_PAGE = START_PAGE + 1;

    // 최초 1회 API 호출하여 전체 페이지 수 획득
    ApiResponse firtApiResponse = this.apiCall(START_PAGE);

    // 전체 페이지 수 만큼 API 호출
    List<ApiResponse> apiResponses = IntStream
            .rangeClosed(SECOND_PAGE, firtApiResponse.totalPage)
            .boxed()
            .parallel()
            .map(this::apiCall)
            .collect(Collectors.toList());

    apiResponses.add(firtApiResponse);
    return apiResponses;
}

✅ Tests passed: 1 of 1 test - 6 sec 102 ms

[API 호출] Current Page: 1 Thread: Test worker
[API 호출] Current Page: 7 Thread: Test worker
[API 호출] Current Page: 2 Thread: ForkJoinPool.commonPool-worker-8
[API 호출] Current Page: 4 Thread: ForkJoinPool.commonPool-worker-1
[API 호출] Current Page: 5 Thread: ForkJoinPool.commonPool-worker-3
[API 호출] Current Page: 9 Thread: ForkJoinPool.commonPool-worker-4
[API 호출] Current Page: 10 Thread: ForkJoinPool.commonPool-worker-6
[API 호출] Current Page: 6 Thread: ForkJoinPool.commonPool-worker-7
[API 호출] Current Page: 8 Thread: ForkJoinPool.commonPool-worker-5
[API 호출] Current Page: 3 Thread: ForkJoinPool.commonPool-worker-2
[승인 대사 진행] Current Page: 2 Thread: Test worker
[승인 대사 진행] Current Page: 3 Thread: Test worker
[승인 대사 진행] Current Page: 4 Thread: Test worker
[승인 대사 진행] Current Page: 5 Thread: Test worker
[승인 대사 진행] Current Page: 6 Thread: Test worker
[승인 대사 진행] Current Page: 7 Thread: Test worker
[승인 대사 진행] Current Page: 8 Thread: Test worker
[승인 대사 진행] Current Page: 9 Thread: Test worker
[승인 대사 진행] Current Page: 10 Thread: Test worker
[승인 대사 진행] Current Page: 1 Thread: Test worker

Parallel Stream을 이용하여 비동기로 API를 호출했어요. Java의 Parallel Stream은 내부적으로 ForkJoinPool의 commonPool을 사용해요. ForkJoinPool은 ExecutorService인터페이스를 상속받고 있어요. 내부적으로 Task의 개수(크기, 사이즈)에 따라 분할(fork)하여 Task을 처리하고 모든 Task가 처리되었을 경우에는 Join을 통해 취합해요. ForkJoinPool의 또 다른 특징으로는 유휴(놀고 있는) Thread가 있을 경우 유휴 Thread가 다른 Thread 잡들을 가져와 수행하여 최대한 유휴 Thread가 없이 모두 일관된 개수의 Task를 처리해요.

ForkJoinPool은 수행되야하는 Task가 많아질 수록 Worker Thread가 추가되어요. 따라서 만약 ForkJoinPool의 Thread 개수를 제한하려면 다음과 같이 직접 ForkJoinPool을 생성하여 사용할 수도 있어요.

private static final ForkJoinPool EXECUTOR = new ForkJoinPool(10);

ForkJoinPool의 parallelism 파라미터에 int값으로 원하는 Thread 수 개수를 인자로 넘겨주면 해당 개수 만큼의 Thread만 생성이되어요.

public class ForkJoinPoolTest {
    private static final ForkJoinPool EXECUTOR = new ForkJoinPool(10);

    @Test
    void test() {
        EXECUTOR.submit(() -> IntStream.rangeClosed(1, 30)
                .boxed()
                .parallel()
                .peek(i -> {
                    try {
                        Thread.sleep(new Random().nextInt(1000, 3000));
                        System.out.println("[NUMBER: " + i + "] Thread: " + Thread.currentThread().getName());
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                })
                .collect(Collectors.toList())
        ).join();

    }
}

[NUMBER: 30] Thread: ForkJoinPool-1-worker-7
[NUMBER: 25] Thread: ForkJoinPool-1-worker-6
[NUMBER: 22] Thread: ForkJoinPool-1-worker-9
[NUMBER: 27] Thread: ForkJoinPool-1-worker-10
[NUMBER: 28] Thread: ForkJoinPool-1-worker-3
[NUMBER: 20] Thread: ForkJoinPool-1-worker-1
[NUMBER: 17] Thread: ForkJoinPool-1-worker-4
[NUMBER: 16] Thread: ForkJoinPool-1-worker-5
[NUMBER: 10] Thread: ForkJoinPool-1-worker-2
[NUMBER: 5] Thread: ForkJoinPool-1-worker-8
[NUMBER: 29] Thread: ForkJoinPool-1-worker-7
[NUMBER: 21] Thread: ForkJoinPool-1-worker-9
[NUMBER: 19] Thread: ForkJoinPool-1-worker-10
[NUMBER: 26] Thread: ForkJoinPool-1-worker-6
[NUMBER: 2] Thread: ForkJoinPool-1-worker-1
[NUMBER: 24] Thread: ForkJoinPool-1-worker-5
[NUMBER: 4] Thread: ForkJoinPool-1-worker-8
[NUMBER: 1] Thread: ForkJoinPool-1-worker-4
[NUMBER: 18] Thread: ForkJoinPool-1-worker-3
[NUMBER: 11] Thread: ForkJoinPool-1-worker-2
[NUMBER: 6] Thread: ForkJoinPool-1-worker-6
[NUMBER: 7] Thread: ForkJoinPool-1-worker-10
[NUMBER: 3] Thread: ForkJoinPool-1-worker-9
[NUMBER: 23] Thread: ForkJoinPool-1-worker-7
[NUMBER: 15] Thread: ForkJoinPool-1-worker-4
[NUMBER: 13] Thread: ForkJoinPool-1-worker-5
[NUMBER: 14] Thread: ForkJoinPool-1-worker-1
[NUMBER: 9] Thread: ForkJoinPool-1-worker-8
[NUMBER: 8] Thread: ForkJoinPool-1-worker-2
[NUMBER: 12] Thread: ForkJoinPool-1-worker-3

Worker Thread가 10개 이상 늘어나지 않는 것을 확인할 수 있어요.

이 처럼 이번 개선에서는 ForkJoinPool의 Thread 수를 제한하여 사용하는 방법으로 개선할 수 있었어요.

왜 ForkJoinPool을 사용하였는가?

1. 격리된 ThreadPool 환경에서 실행되어 다른 로직들에 의한 영향을 받지 않기 위함.

   Custom한 Executor를 사용할 수도 있었지만, 승인 대사 로직이 다른 로직에서 모두 사용되는 공통된 Executor에서 사용되기보다 격리된 환경에서 실행되어 다른 로직에 영향을 받지 않기 위함이 있었어요. 공통된 Executor를 사용할 경우 특정한 로직에서 Thread를 잡고 놓아주지 않거나, 혹은 Exeption이 발생한다면 다른 로직에도 영향이 갈 것으로 판단되었어요(다른 개발자가 공통된 Executor 사용 도중 적절한 예외처리를 하지 못하였거나, 예상치 못한 엑셉션이 발생될 경우). Thread 작업 시간을 한정 짓고 해당 작업시간을 초과하면 반환하도록 구현하고 Exception을 Handling 하여 구현할 수도 있었지만, 가장 큰 이유는 격리된 환경에서 승인 대사가 이루어지는 것을 원했어요.

2. 승인 대사 서버에서 비동기 작업이 필요한 로직은 위의 특정한 승인 대사에 거의 한정됨.

   승인 대사 서버에서 비동기 작업이 필요한 로직은 많지 않았어요. 따라서 Custom한 Executor를 개발하는 것보다 빠르고 간편하게 ForkJoinPool을 이용하는 방안을 채택하게 되었어요. 만약 비동기 작업이 많이 필요로하는 서비스였다면, Spring MVC가 아니라 Spring WebFlux를 채택하는 방안이나 CustomExecutor를 개발하는 방향으로 갔을 거예요. 하지만 이는 모두 개발 Cost로 이어지죠. 이러한 다양한 비용을 생각해보고 ForkJoinPool을 사용하기로 결정했어요.

결과

1. 전체 승인 대사 API 속도

동일 시간 대 Matrics - 개선 결제 수단 뿐만 아니라 다른 결제 수단의 승인 대사도 포함된 수치

비교 시간 대

• AS-IS Time: 2023-10-11 09:08:00 ~ 2023-10-12 09:08:00

• TO-BE Time: 2023-10-18 09:08:00 ~ 2023-10-19 09:08:00

AS-IS

• 평균시간: 4352.689
• 최소시간: 30
• 최대시간: 28071

TO-BE

• 평균시간: 2906.083
• 최소시간: 24
• 최대시간: 23139

2. 18:00:00 동일 시간 대 N페이 승인 대사 속도

AS-IS 서비스 시간: 22838ms

TO-BE 서비스 시간: 5354s

3. 승인 대사 서버 CPU 및 메모리 사용량

As-Is

• 최고 CPU 사용량: 3194.222
• 최고 메모리 사용량: 11226

To-Be

• 최고 CPU 사용량: 2242.222
• 최고 메모리 사용량: 7569.286

결과 정리

1. 전체 승인 대사 API

• 평균시간: 33.16% 감소

2. 승인 대사 성능

• 서비스 성능: 76.55% 향상

3. CPU 및 메모리 사용량

• CPU 사용량: 31.98% 감소
• 메모리 사용량: 32.62% 감소

마치며

많은 시간을 소비하고 있던 특정 결제의 승인 대사를 개선해 보았어요. 이번 개선을 통해 단 하나의 승인 대사만 개선했음에도 불구하고, CPU 및 메모리 사용량을 크게 감소 시킬 수 있었으며, N페이 승인 대사 속도의 경우에는 약 77%의 성능 향상을 이룰 수 있었어요.

가장 놀라운 점은 CPU와 메모리 사용량도 크게 감소되었다는 것이었어요. 이는 곧 서비스 비용 절감에도 이점을 취할 수 있는 부분이라 매우 기쁘게 여겨져요.

이번 개선을 통해 하나의 서비스가 전체 서비스에 미치는 영향이 이렇게 클 수 있구나 몸소 깨달을 수 있었어요. 따라서 하나의 서비스, 로직을 작성하더라도 단순하게 기능이 동작하게 만드는 것이 전부가 아닌 내가 작성한 코드로 인한 서비스 영향도 파악 또한 중요하다는 것을 배웠어요.

성능 개선의 답이 항상 비동기라고 생각하지는 않아요. 하지만 상황에 맞게 사용할 경우 큰 이점을 얻을 수 있다고 생각해요. 비동기적인 접근법 이외에도 코드 최적화, 캐싱, 데이터베이스 쿼리 튜닝 등 다양한 기법이 존재하니 상황에 맞게 적용하는 것이 중요한 거 같아요.

앞으로도 모니터링하고 분석하여 성능 개선이 필요한 부분을 찾아 개선하기 위해 꾸준히 노력하고 학습할 예정이예요😆.