[product-manager] ForkJoinPool 적용

[tonykang22]

ForkJoinPool 적용

사용 이유

• 더 들어가기에 앞서 ForkJoinPool을 사용하기로 한 이유에 대해 서술한다.

  • 122 에도 해당 이유가 설명되어 있기는 하다.

Thread Pool 선택

• 선택에 앞서, 먼저 thread pool을 사용할 작업과 환경에 대해 정의하자.
  • Rainforest API 에 특정 ASIN으로 GET 요청을 보내 반환되는 값을 확인(성공적으로 통신을 했는지) 후 반환한다.
  • 반환 값이 존재하는 동일한 작업의 반복이 될 것이다.
  • Java 11을 사용 중이다.
• 이전에 작성한 이슈에서 언급된 thread pool (ExecutorsService 구현체)
  • Fixed Thread Pool: 스레드 풀 생성 시 가용할 스레드의 수를 지정한다.
  • Cached Thread Pool: 필요한 만큼 추가로 스레드를 생성한다.
  • Scheduled Thread Pool: 지정한 시간에 따라 작업을 요청할 수 있다.
• 위의 thread pool 외에는 Work Stealing Pool(ForkJoinPool)가 존재한다.
  • Divide and conquer 방식으로 말 그대로 일을 훔쳐다 하는 스레드 풀
  • Recursive한 Task/Action에 대한 작업에 특화되어있다.

결론은...?

• 이번엔 ForkJoinPool 이다!!
  • OM에서는 ThreadPoolExecutor로 직접 구현
  • 수행해야 하는 작업이 다채로우며, 예상 처리량에 대비한 리소스만 활용하기 위함
• 왜 ForkJoinPool?
  • 거대한 작업을 쪼개서 수행하기 위해 스레드 풀을 가용하려 하기 때문이다.
  • 동일한 작업을 반복해야 하는 상황

어떻게 사용?

ForkJoinPool commonPool = ForkJoinPool.commonPool();

• 먼저 사용의 전반을 쉽게 파악하기 위해 baeldung을 참고하도록 하자.
  • Oracle’s documentation에 따르면 commonPool을 사용하면 작업별로 별도의 스레드 풀을 생성하지 않게 되므로 리소스 소비가 줄어든다고 한다.
• commonPool()을 사용해 만든 pool에는 몇 개의 스레드를 운용하는거지?
  • 아래의 코드를 확인해보자.

ForkJoinPool.commonPool();

• commonPool()을 호출하면 common을 반환하는 것을 확인할 수 있다.
• common은 static 초기화 블럭 내에서 초기화된다.
  • new ForkJoinPool((byte)0);를 반환하는 것을 확인할 수 있다.
• 결국 parallelism = (Runtime.getRuntime().availableProcessors() - 1)으로 설정되게 된다.
  • 문서에 의하면 @param parallelism the parallelism level 이라 표현되어 있다.
  • 병렬 처리할 수 있는 스레드 수를 지정하는 거라 이해했다.
  • 운영 환경마다 다를 것으로 판단된다.

public class ForkJoinPool extends AbstractExecutorService {
...

    static final ForkJoinPool common;

...

    static {
        ...

        common = AccessController.doPrivileged(new PrivilegedAction<>() {
            public ForkJoinPool run() {
                return new ForkJoinPool((byte)0); }});
        ...
    }

...

    public static ForkJoinPool commonPool() {
        // assert common != null : "static init error";
        return common;
    }

...

    private ForkJoinPool(byte forCommonPoolOnly) {
        int parallelism = -1;
        ...
        if (parallelism < 0 && // default 1 less than #cores
            (parallelism = Runtime.getRuntime().availableProcessors() - 1) <= 0)
            parallelism = 1;
        if (parallelism > MAX_CAP)
            parallelism = MAX_CAP;
        ...
    }

...
}

직접 확인해보자

로컬은 ?

• 내 로컬 환경은 10 코어로, 문서에 따르면 commonPool()을 사용하면 병렬 작업을 할 수 있는 9개의 스레드를 사용하는 것으로 이해된다.
• 로컬에서 Task를 실행해 몇 개의 작업이 병렬적으로 수행되는지 확인해보자.
  • 수행할 Task가 있을 때 9개 까지 늘어나 작업하는 것을 확인할 수 있다.
    • Task는 16개의 작은 task로 쪼개질 수 있는 작업이었다.

서버는 ?

• HWAS 서버는 16코어로, 그렇다면 15개의 작업이 병렬적으로 수행되어야 할 것이다.
  • 과거 로그를 참고하면, 15개의 작업이 수행되는 것을 확인할 수 있다.

12:00:00.011 [ForkJoinPool.commonPool-worker-45] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.012 [ForkJoinPool.commonPool-worker-59] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.014 [ForkJoinPool.commonPool-worker-9] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.014 [ForkJoinPool.commonPool-worker-33] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.014 [ForkJoinPool.commonPool-worker-39] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.014 [ForkJoinPool.commonPool-worker-53] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.014 [ForkJoinPool.commonPool-worker-11] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.015 [ForkJoinPool.commonPool-worker-25] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.015 [ForkJoinPool.commonPool-worker-31] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.015 [ForkJoinPool.commonPool-worker-55] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.015 [ForkJoinPool.commonPool-worker-5] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.016 [ForkJoinPool.commonPool-worker-3] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.016 [ForkJoinPool.commonPool-worker-17] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.017 [ForkJoinPool.commonPool-worker-37] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86
12:00:00.015 [ForkJoinPool.commonPool-worker-19] INFO  c.g.k.p.s.s.j.ItemScoutWebScrapingWorker - =================== 처리 시작, size : 86

parallelism을 직접 넣어주면 ?

ForkJoinPool forkJoinPool = new ForkJoinPool(n);

• 만약 n 개로 생성한다면 어떻게 될까?
  • n 개의 작업이 병렬적으로 수행되는 것을 확인할 수 있었다.

중간 정리

• ForkJoinPool의 기본 생성에 대해 알아보았다.
• 다시 RestTemplate 이야기로 돌아와 생각해보자.
  • (#122 )
• Connection Pool 을 사용하기로 했는데, 여기서는 참고 사항이 있다.
  • 호출하는 API 서버가 Keep-Alive를 지원해야 풀을 사용할 수 있다.
    • Keep-Alive를 지원하지 않는다면 매 요청마다 새로운 Connection이 연결되어 핸드쉐이크가 발생할 것이기 때문이다.
• Rainforest 는 Keep-Alive를 지원하는가?
  • Request를 보내 Response를 확인해보자.
  • 아래 이미지 참고 : Keep-Alive를 지원한다.

Rainforest Response Header

Rainforest API 요청 테스트

• Rainforest의 상품 상세 API 요청을 테스트 하도록 한다.
  • 싱글 스레드 기준, 해당 API 요청 - 응답에 소요되는 시간은 약 10 - 30 초이다.
• 해당 테스트는 내가 보낸 요청의 수가 늘어나도 정말 병렬 처리가 되는지 확인하기 위함이었다.
• 테스트가 진행되는 상황은 다음과 같다.
• RecursiveTask<List<AmazonSourcingProduct>>를 상속한 AmazonSyncTask를 작성한다.
  • 수행해야할 task가 1개(=threshold)가 될 때까지 subTask를 생성한다.
• RestTemplate를 활용해 Rainforest API를 호출하는 AmazonProductFetcher를 작성한다.
  • AmazonSyncTask의 수행할 task 수가 1개(=threshold)가 되면 그 때 amazonProductFetcher.getAmazonProductList()를 호출한다.

Rainforest API 요청 테스트 결과

공통

• 테스트 결과 공유 기술에 앞서, 실험군으로 사용된 항목들을 정리하면,
  • RestTemplate Connection Pool
    • Connection Pool을 사용하기 위해 HttpComponentsClientHttpRequestFactory를 사용한다.
    • HttpClientBuilder로 setMaxConnTotal / setMaxConnPerRoute를 변경해 테스트한다.
      • setMaxConnTotal: 최대 connection 수 설정
      • setMaxConnPerRoute: 특정 host에 대한 최대 connection 수 설정
  • ForkJoinPool
    • ForkJoinPool 생성
      • ForkJoinPool.commonPool();: 로컬 환경에서는 parallelism = 9
      • new ForkJoinPool(n parallelism): 입력하는 parallelism = n
  • AmazonSyncTask
    • Threshold는 1로 고정: 한 task는 한 번의 Rainfoest API 요청을 기준으로 한다. (예상 소요 시간: 10 - 30 초)
    • Task의 수를 변경
      • Ex) Task = 9 개: Rainforest API 요청이 9회 일어나야한다.

RestTemplate를 기존의 방식으로 사용

설정

• ForkJoinPool: commonPool 고정
  • 로컬에서는 9개 작업까지 병렬처리 가능하기 때문에 SimpleClientHttpRequestFactory의 한계점(5) 이상으로 설정해두어 해당 설정이 bottle neck이 되지 않기 위함
• AmazonSyncTask: 5개 / 6개

의의

• 내부적으로 5개의 connection pool을 갖는다 했는데, 맞는지 테스트로 확인해보기 위함
• 별도의 설정으로는 connection / read timeout만 3분으로 해둔 상태로, default로 SimpleClientHttpRequestFactory를 사용한 방식이 되겠다.

결과

AmazonSyncTask: 5개

• 정말 5개가 동시에 수행되는 것을 확인할 수 있었다.
• 소요된 시간만 확인해도 15초로 Rainforest API 평균 요청 시간 (10-30초) 범주 내로, 한 사이클만에 모두가 수행된 것으로 확인할 수 있다.
  • 소요 시간의 오차 범위가 너무 넓어 정확한 판단은 어려우나, 개략적인 확인은 가능하다.

AmazonSyncTask: 6개

• ForkJoinPool가 수행할 수 있는 작업의 수가 9 이므로, 6개가 한번에 시작된다.
• 그러나 RestTemplate의 connection pool의 상한이 5개 이므로 최대 5개까지만 요청이 보내지는 것을 확인할 수 있다.
• 소요 시간은 27초였다.

와우... 수행 시간이 이렇게 똑같다니..!?

Connection Pool을 사용한 RestTemplate

설정

• ForkJoinPool: commonPool
  • 이번에는 RestTemplate의 connection pool의 setMaxConnTotal를 변경해 commonPool을 bottle neck으로 만들 수 있는지 확인해본다.
• AmazonSyncTask: 10개
• RestTemplate Connection Pool: setMaxConnTotal / setMaxConnPerRoute(테스트 특성 상 두 값은 같도록 설정한다.) : 6/6개, 10/10개

의의

• RestTemplate의 connection pool이 의도한 대로 작동하는지 확인
• max connection 갯수 > ForkJoinPool의 parallelism가 된다면 병렬 작업을 수행할 스레드의 수가 bottle neck이 되어 ForkJoinPool의 parallelism 수 만큼만 동시에 수행하는지도 확인

결과

setMaxConnTotal: 6개

• (간단하게 표현)스레드 풀의 스레드는 9개이므로, 해당 설정 시 예상되는 시나리오
  • 한 사이클에 6개 씩 요청 처리, 2 사이클이 걸릴 것 (6개 -> 4개)
• 예상과 동일하게 스레드 풀은 한 사이클에 10개 메서드를 수행했으나, 6개의 http 통신만 우선적으로 이뤄지고 이후 4개의 통신이 일어나는 것을 확인
  • 수행 시간은 23초 였다.

setMaxConnTotal: 10개

• 예상되는 시나리오
  • 이제 RestTemplate를 통해 통신할 수 있는 수는 10이 되었다. 그러나 스레드 풀은 9개 뿐이다.
  • 실행 시: 스레드 풀의 스레드 9개가 먼저 메서드 각 1 번 씩 9번 수행 → 그 중 가장 일을 먼저 마친 스레드가 나머지 1개 task 다시 수행
• 마찬가지로 예상대로 수행되는 것을 확인할 수 있다.
  • 수행 시간은 17초 였다.

한 녀석만 동떨어져서,, 두 번째 사이클을 열심히 수행

Rainforest API 몇 개까지 ?

• 한 사이클로 수행될 수 있는 수는 얼마일까 : Rainforest 내부적으로 동일한 host에 대한 중복 접근을 얼만큼 허용할지 확인도 필요해서 테스트 수행

설정

• ForkJoinPool: n = 100
  • 병렬 작업할 수 있는 스레드 수가 bottle neck이 되지 않게 큰 값으로 설정한다.
• AmazonSyncTask: 1 ~ 64 개
• RestTemplate Connection Pool: setMaxConnTotal / setMaxConnPerRoute [테스트 특성 상 두 값은 같도록 설정한다.] : 100/100개

결과

• 이는 로그로 확인하기 어려우므로 수행 시간만 기록하도록 한다.
  • Opening connection 로그를 확인해도
    • 내 로컬에서는 테스트 실행 동시에 16개면 16개의 connection open
    • 70개면 70개의 connection open
• 50 개 부터 수행 시간이 눈에 띄게 증가하는 것으로 보아 2 사이클에 수행될 여지가 있다고 판단된다.
  • 약 40 - 50 개 사이가 아닐까 추측
• 한 사이클 당 최대 40 번의 요청을 수행할 수 있을 것으로 판단된다.

n (parallelism)	소요 시간 (초)
1	18
2	7.3
3	19
4	17
5	14
6	13
16	20
32	24
40	27
50	44
64	44

참고

퀴즈

• 아래 상황이라면 동시에 몇 개의 스레드가 일을 할까?
  • 스레드 풀의 스레드: 10개
  • Task의 threshold: 3
  • 주어진 Task 수: 10개
• 정답은 4개
  • 3개 씩 일을 나눠 갖기 때문에 네 개의 스레드가 3/3/3/1 로 나눠 갖는다.
  • 나머지 스레드는 놀게 된다.
  • 사이클도 3으로 증가한다. (threshold가 1이었다면 1 사이클에 종료되었을 것이다.)
• 수행해야할 Task의 수와 가용할 수 있는 스레드의 수 (RestTemplate Connection Pool이 한계점이 아니라는 가정)를 고려해야 한다.

결론

• 현재 기준, PM이 sync를 위해 Rainforest API 호출 수는 최대 10,000이다.
• Rainforest는 동일 host에 대해 적어도 40개의 요청에 대해 답하는 것으로 판단된다.
• 최대 250 사이클이면 모든 상품의 정보를 받아오는 것을 마칠 것으로 판단된다.
  • 30초 * 250 사이클 = 2시간 5분 이면 마칠 수 있을 것
• 동기화할 상품의 수가 10,000 개이고 스레드가 40개( < 최대 요청 수)라면,
  • Threshold를 250으로 설정해야 최적화된 시간 내에 수행할 수 있을 것이다.
• 그러나 동기화할 상품의 수가 3,000 개이고 스레드가 40개( < 최대 요청 수)라면,
  • Threshold를 250으로 잡는 것이 오히려 독이 될 것이다.
  • 12 개의 스레드만 일하고 나머지 28개의 스레드가 잉여 스레드로 존재할 것이다.
    • 3,000 개의 요청을 보내지만 10,000 개의 요청을 보낼 때와 동일하게 2시간 5분이 소요될 것이다.
• 현재 sync할 상품은 3,500 개로, 10,000 개가 등록되기 까지는 한달 조금 넘게 소요될 것으로 판단
  • 10,000 개의 상품이 등록된 상태가 정상 상태로 판단된다.
  • sync는 약 한달 주기를 가지고 수행될 작업으로 생각한다.

정리

• RestTemplate Connection Pool은 최대 connection = 45
  • 5개는 예비 (ExchangeRate 호출 등을 위함)
• ForkJoinPool parallelism = 40
  • threshold = 250
• 비록 한달 이내에 수행되는 sync는 조금 비효율 적일 수도 있으나, 결국 한달 뒤를 기점으로는 최적화된 수치이다.

아쉬운 점

• 인지만 하고 더 정리하지 못한 내용
  • 우리의 Thread는 왜 이렇게 부자가 되었을까?
  • [Spring] OpenFeign이란? OpenFeign 소개 및 사용법
    • OpenFeign도 참 흥미로워 보인다.
  • Spring WebClient 사용법

곧 떠나는구나 RestTemplate야...

[tonykang22]

코멘트 작성자: kingwaggs

@tonykang22 상웅님, 정리된 내용 잘 확인했습니다.

416 에 이어 Technical writing skill 이 엄청 좋으시네요.. 테스트도 꼼꼼하구요.

한 편의 기술 블로그 컨텐츠를 읽는 느낌이었습니다 ㅎㅎ 나중에 이런 업무를 담당하셔도 잘 하실것 같네요.

실무에서 만들고자 하는 프로젝트가 실현 가능한가, 내부적으로는 어떤 기술을 적용할 것인가 등을 PoC 단계에서 논의합니다. 그 때마다 상웅님께서 정리해주신 것 처럼 특정 기술에 대한 분석과 데모 테스트 정도가 간단하게 추가하여 정리하고 이를 바탕으로 구성원 간 논의가 이어지는데요, 나중에 자기소개서를 작성할 때 위 이슈도 포함이 되면 좋을것 같네요. 따라서 최상단쯤에 ForkJoinPool 을 왜 쓰도록 결정하였는지, 그 사용 배경 및 요구사항을 간략 정리해서 몇 줄만 추가해주고 자세한 배경은 #416 이슈를 링크걸어 추가해주시면 좋을것 같습니다.

최하단에 정리된 내용에는 이견이 없습니다. 확인해주신대로 적용해서 Sync 작업 개발 진행해주시면 되겠습니다. 잘 읽었습니다. 저도 많이 배우네요 ㅎㅎ 고생하셨습니다.