개요

Transcoding 요청 개수가 증가하며 분배를 위한 계산에 소요되는 시간이 증가하게 됨.
- 대략 10분 - 15분의 시간 소요
이는 전체 미할당 데이터를 전부 쿼리하여, 분배를 위해 전체 데이터 개수들에 대한 작업이 동작하게 되므로 비효율적일 뿐더러 속도 역시 매우 느려질 수 밖에 없음
- 이와 더불어 이후에 들어온 작업 요청들의 대기도 길어지기 때문에, user 별 기민한 처리에 불리함
따라서 각 user 별 작업 요청에 대하여, 가용 TR 워커 개수만큼 조회하여 분배 작업을 수행해야 효율적일 것으로 예상
- 이와 같은 방식으로 처리된다면 현재 사용 가능한 TR 워커 개수에 맞게 작업 내용을 처리 가능하며, 각 user 별로 개수의 제한을 둬 처리할 수 있기 때문에 특정 user 의 작업 요청만 밀린다는 등의 이슈를 해결할 수 있을 것으로 기대

#현황

기존의 작업 할당 방식은, 전체 테이블에서 할당되지 않은 데이터를 전체 쿼리해여 데이터를 처리하는 방식
- 그러나 전체 데이터 개수가 커질수록 쿼리에 소요되는 시간과, 가져온 이후 처리하는 시간이 기하급수적으로 커짐
- 따라서 이러한 방식으로 프로덕 레벨의 작업 요청을 처리하게 되면 의 현상이 재현됨 (약 10-15 분 가량 분배를 위한 계산 로직 수행)

SELECT 
  id, group_nm, account_id, content_id, transcoder_type, request_body, 
  UNIX_TIMESTAMP(created_at) as created_ts, priority, retry_cnt 
FROM jobs
WHERE     assign_at      IS NULL 
AND      register_at IS NULL 
AND      complete_at IS NULL 
AND      cancelled=0 
ORDER BY priority, created_at

작업

따라서, 미할당 내역을 user 별로 TR의 워커 개수만큼 조회해 가져와서, 분배 작업을 수행
- 이 경우, 전체 조회해야 하는 row의 개수도 줄어들며 가져온 이후 처리해야 하는 데이터의 사이즈도 현격히 줄일 수 있음


 SELECT 
      id, group_nm, account_id, content_id, transcoder_type, request_body, created_ts, priority, retry_cnt
  FROM (
      SELECT 
          id, group_nm, account_id, content_id, transcoder_type, request_body, 
          UNIX_TIMESTAMP(created_at) as created_ts, priority, retry_cnt,
          @rownum := IF(@prev_acc = account_id, @rownum + 1, 1) AS row_num,
          @prev_acc := account_id
      FROM 
          jobs, 
          (SELECT @rownum := 0, @prev_acc := '') AS r
      WHERE   assign_at IS NULL 
        AND   register_at IS NULL 
        AND   complete_at IS NULL 
        AND   cancelled = 0
      ORDER BY account_id, priority ASC, created_at ASC
  ) AS t
  WHERE t.row_num <= 100
  ORDER BY t.priority, t.created_ts

테스트 수행

1차 테스트

더미 데이터 약 15만개를 입력하고서, 동일한 데이터 테이블에 대해 기존 로직과 개선된 로직의 성능 테스트 진행함
- 테스트 환경: dev
- 테스트 대상 테이블: test_table.jobs_test
- 미할당 작업 데이터 개수: 157,129
- TR 워커 개수: 28개

기존 로직
- 조회되는 각 group 별 개수
  - group1: 78535
  - group2: 78593
- 전체 로직 완료까지 소요된 시간: 약 10분 27초
개선된 로직
- 조회되는 각 group 별 개수
  - group1: 215
  - group2: 185
- 전체 로직 완료까지 소요된 시간: 약 6초 783

구분	워커 개수	전체 데이터 개수	소요 시간
기존 쿼리 로직	28	157,129	10분 39초
개선 쿼리 로직	28	157,129	6초 783

2차 테스트

더미 데이터 약 15만개를 입력하고서, 동일한 데이터 테이블에 대해 기존 로직과 개선된 로직의 성능 테스트 진행함
- 테스트 환경: dev
- 테스트 대상 테이블: test_table.jobs_test
- 미할당 작업 데이터 개수: 157,129
TR 워커 개수: 100개

개선된 로직
- 전체 로직 완료까지 소요된 시간: 약 3초 664

구분	워커 개수	전체 데이터 개수	소요 시간
개선 쿼리 로직	100	157,129	3초 664

3차 추가 테스트

더미 데이터 약 15만개를 입력하고서, 동일한 데이터 테이블에 대해 기존 로직과 개선된 로직의 성능 테스트 진행함
- 테스트 환경: dev
- 테스트 대상 테이블: test_table.jobs_test
- 미할당 작업 데이터 개수: 157,129
TR 워커 개수: 200개

개선된 로직
- 전체 로직 완료까지 소요된 시간: 약 3초 737

구분	워커 개수	전체 데이터 개수	소요 시간
개선 쿼리 로직	200	157,129	3초 737

테스트 분석 결과

개선된 로직은 평균 약 4.728초가 소요됨
- 그러나 1차 테스트의 경우 전체 조회 로직(기존 로직)의 영향이 있을 수도 있으므로, 이상치로 가정함 (추후 추가 테스트 진행 예정)
따라서 워커 개수의 약 두배만큼 조회 데이터 개수를 늘리더라도, 성능상의 차이는 크지 않음
- 다만 워커 개수가 100개에서 200개로 늘렸을 때 약 0.073초 감소함
- 해당 속도의 감소는 성능 저하를 의미할 수도 있으므로, 개선된 로직 내에서 적절값을 찾아가는 것이 필요해 보임
- 물론 TR 워커 개수가 유동적이므로, 고정 값으로 사용하지 않는 이상 계산 로직이 필요할 수도 있음

결론

그 결과 변경한 방식이 약 150 - 200배 이상의 성능 개선을 보이는 것을 확인하였다.
위 쿼리 개선 로직을 적용한다면, 작업 분배 계산 시간을 줄일 수 있거 TR 요청 처리 성능을 크게 개선시킬 수 있을 것으로 기대함
조회하는 user 데이터의 개수의 성능 임계점을 파악할 테스트 추후 진행 필요

728x90

저작자표시 비영리 변경금지 (새창열림)