Post

6주5일차_데이터베이스_기반_작업_큐_실습

Posted Updated
By marshmallow
7 min read
6주5일차_데이터베이스_기반_작업_큐_실습

필기 내용

1. 작업 큐 개념 이해

1.1 작업 큐의 정의와 필요성

작업 큐는 비동기 작업을 효율적으로 관리하기 위한 시스템으로, 작업 요청을 순서대로 저장하고 처리 상태를 추적합니다. 이를 통해 작업의 진행 상태를 명확히 관리하고, 시스템의 부하를 분산할 수 있습니다.

정의

  • 작업 큐는 데이터베이스나 메모리와 같은 저장소에 작업을 저장하고, 하나씩 작업을 처리하며 상태를 업데이트하는 방식으로 작동합니다.
  • 이를 통해 작업을 효율적으로 분배하고, 시스템이 안정적으로 동작할 수 있도록 돕습니다.

필요성

  • 응답성 향상: 복잡하거나 시간이 오래 걸리는 작업을 비동기적으로 처리함으로써 시스템의 응답 속도를 높일 수 있습니다.
  • 효율적인 요청 처리: 대량의 요청을 큐에 저장하고 순차적으로 처리하여 시스템 과부하를 방지합니다.
  • 작업 추적 가능: 작업의 현재 상태와 진행 상황을 추적하여 오류를 방지하고, 관리 용이성을 제공합니다.

1.2 테이블 기반 작업 큐 활용

데이터베이스를 활용한 작업 큐는 작업 상태를 명확히 관리하고, 트랜잭션과 락을 통해 동시성 문제를 방지할 수 있는 안정적인 구현 방식입니다.

2.4 확장 가능성 작업 우선순위 추가 작업 처리 순서를 정의하기 위해 우선순위 컬럼(priority)을 추가할 수 있습니다. ALTER TABLE task_queue ADD COLUMN priority INT DEFAULT 0; ​ 에러 관리 작업 실패 시 원인을 기록하기 위해 error_message 컬럼을 추가할 수 있습니다. ALTER TABLE task_queue ADD COLUMN error_message TEXT; ​ 작업 재시도 로직 작업 실패 시 재시도를 관리하기 위해 retry_count 컬럼을 추가할 수 있습니다. ALTER TABLE task_queue ADD COLUMN retry_count INT DEFAULT 0;

3.3 동시성 문제 방지의 결과

장점

  • 데이터 정합성 유지: 동일 작업을 여러 트랜잭션이 동시에 처리하지 않도록 보장합니다.
  • 작업 안정성 강화: 작업 큐에서 중복 처리가 방지되어 시스템의 안정성이 높아집니다.
  • 비동기 작업 최적화: 대량의 작업 처리 시 작업 충돌 없이 효율적으로 처리할 수 있습니다.

한계

  • 대기 시간 증가: 한 트랜잭션이 작업을 선점하면, 다른 트랜잭션은 대기 상태에 놓이므로 처리 시간이 늘어날 수 있습니다.
  • 데드락 발생 가능성: 잘못된 락 관리로 인해 데드락이 발생할 위험이 있으므로, 트랜잭션 설계를 신중히 해야 합니다.

SELECT ... FOR UPDATE는 작업 큐에서 동시 작업 처리 문제를 방지하는 강력한 도구입니다. 이를 통해 트랜잭션 간 충돌을 제어하고, 작업의 안정성을 높일 수 있습니다. 트랜잭션 설계 시 락의 활용과 해제를 적절히 관리하면, 대규모 작업 처리에서도 데이터 정합성과 시스템 성능을 효과적으로 유지할 수 있습니다.

  1. 작업 상태 변경
    • 작업이 시작되면 상태를 processing으로 변경하여 다른 트랜잭션에서 동일 작업에 접근하지 못하도록 설정합니다.
    1

     UPDATE task_queue SET status = 'processing' WHERE id = 1;

Action Plan

[ ] 작업큐 만들고 1,2개 테스트해보기.

수업 내용 필기 정리.

  • 작업 큐 정의

  • 질문 : 강의자료에 있는 작업 큐는 너무 범용적인거 같습니다.
    • 이메일 발송만 가정해도, 발송을 위한 정보 또는 그것들을 찾을수있는 정보라도 해당 task컬럼에 담아야 하는데 그런게 없습니다.
    • 추가적인 테이블은 비즈니스 로직마다 다르게 가져가고 일반적 케이스 말씀하시는 건가요?
    • 제 생각 : ref_tb_nm, ref_tb_pk 라도 필요., TaskType 도 있으면 좋아보임.
  • 질문 : 아래 강의 자료에서는 해당큐를 여러쓰레드가 동시 처리하는 것도 가정해서 이런 언급이 있는건가요? ```sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

* 에러 상태 처리
  * 강의안에 에러 상태 처리가 없는데 이런 부분에 대해서 어떻게 생각하시나요?
  * 실제 실무시 이런 부분은 다르게 가정하고 처리가 필요해보임.

* 기존의 transactional 코드를 아래와같이 나눠야하지 않을까요?
```java
// 기존
  @Transactional
  public void processQueueById(Long taskQueueId, Consumer<TaskQueue> task) {
    TaskQueue taskQueue = taskQueueRepository.findByIdForUpdate(taskQueueId)
        .orElseThrow(() -> new ServiceException(ServiceExceptionCode.NOT_FOUND_TASK));

    updateStatus(taskQueue, TaskStatus.PROCESSING);

    task.accept(taskQueue);

    updateStatus(taskQueue, TaskStatus.COMPLETED);
  }
  • 새로운 방향
    • 트랜잭션을 각각 걸음.
    • 1 -> procession으로 상태 변경
    • 태스크 처리
      • 본로직
      • 본로직 수행결과에 따른 태스크 상태 변경
        • 본로직 성공시 : 본로직 정상 처리.
        • 본로직 실패시 : 본로직 롤백, 상태 에러로 변경
  • 작업 큐 사용은 요청과 실행으로 구분한다.
Software Development
This post is licensed under CC BY 4.0 by the author.