와 Mendix 9, 우리는 소개했다 작업 대기열 분산 방식으로 마이크로플로우나 Java 작업을 비동기적으로 실행할 수 있도록 합니다. 이 기능을 사용하면 동기화 및 작업 관리에 대해 생각하지 않고도 고성능 상태 없는 앱을 빌드할 수 있습니다.

이 게시물에서는 작업 대기열에 대해 자세히 설명하고 더 이상 사용되지 않는 프로세스 대기열 모듈과 어떻게 다른지 설명합니다. 또한 마르셀 그로네베그은 Mendix ITvisors의 전문가이자 MVP가 Task Queue를 처음 사용한 경험 중 일부를 공유해주었습니다.

작업 대기열이란 무엇인가요?

작업 대기열은 수평적으로 확장 가능한 대기열 솔루션으로, 앱을 더 안정적으로 만들고 더 나은 성능을 낼 수 있도록 도와줍니다. 백그라운드에서 장기 실행 작업을 수행하여 사용자가 기다릴 필요가 없도록 하고, 부하를 여러 런타임 인스턴스에 분산하고, 여러 대기열을 사용하여 리소스를 최적으로 할당할 수 있습니다.

작업 대기열은 일반적으로 거래량이 많거나 작업에 시간이 오래 걸리는 경우 또는 신뢰성이 핵심이다. 모든 노드는 대기 중인 작업을 선택할 수 있어 도구 상자에 수평 확장 옵션을 효과적으로 추가합니다. 실행 중에 실패한 노드에서 선택한 작업은 다시 선택되므로 단일 노드가 성공하는 데 덜 의존하게 됩니다. 예약된 이벤트에서 작업을 대기열에 추가할 수도 있으므로 예약된 이벤트의 단일 노드 종속성을 해결하고 작업 배치가 항상 실행되도록 할 수 있습니다.

굉장하네요. 어떻게 시작해야 하나요?

작업 대기열을 시작하는 것은 간단합니다. Studio Pro에서 새 작업 대기열을 추가한 후 다음을 표시할 수 있습니다. 마이크로플로우를 호출하다 마이크로플로우가 백그라운드에서 실행되어야 하는 활동입니다. 작업을 큐에 넣은 후, 처리를 위해 런타임 인스턴스 중 하나에서 선택됩니다. 마지막으로, 처리된 큐 작업 성공 상태를 나타내는 표입니다. 이를 기반으로 추가 논리를 구현할 수 있습니다.

예를 들면

관리자가 데이터베이스의 청구서 목록에서 PDF 및 Word 문서를 생성하려는 경우를 생각해 보겠습니다. 사용자는 버튼을 눌러 마이크로플로를 트리거하고, 이 버튼은 루프에서 하위 마이크로플로를 호출하여 파일을 생성합니다. 작업 대기열이 없으면 작업이 완료될 때까지 페이지에 로딩 막대가 표시되어 사용자가 그동안 앱을 사용할 수 없습니다.

이를 개선하기 위해 하위 마이크로플로가 작업 대기열을 통해 실행되도록 지정할 수 있습니다. 이제 모든 노드가 문서 생성을 도울 수 있으므로 사용자는 더 빨리 결과를 얻을 수 있고, 파일이 백그라운드에서 생성되는 동안 차단되지 않습니다.

프로세스 큐와의 비교

작업 대기열과 더 이상 사용되지 않는 작업 대기열 사이에는 몇 가지 차이점이 있습니다. 프로세스 대기열 기준 치수:

1. 작업 대기열은 다음의 기본 부분입니다. Mendix 따라서 더 이상 추가 엔터티와 연결을 설정할 필요가 없으므로 도메인 모델의 복잡성이 낮아집니다.
2. 괜찮다고 생각하셨겠지만, 작업 대기열은 수평적 확장도 허용하므로 다중 인스턴스 환경에 적합한 솔루션입니다.
3. 앞으로 작업 대기열은 작업을 자동으로 재시도하는 기능을 지원할 예정이며, 이는 올해 말에 로드맵에 포함되어 있습니다.

작업 대기열에 대한 경험

그게 다 좋은데, Task Queue는 실제 시나리오에서 어떻게 작동하나요? 마르셀 그로네베그, 인증됨 Mendix 전문가 IT바이저 Mendix 이미 Task Queue와 함께 작업한 MVP Mendix 9.

질문: 작업 대기열을 어떻게 활용하셨나요?

A: 이전에 프로세스 큐에서 실행되었던 일부 장기 실행 백그라운드 프로세스를 대체했습니다. 이러한 백그라운드 프로세스는 외부 시스템에서 데이터를 수집하여 처리합니다. 또한 큐를 사용하여 이미지를 다운로드합니다. 각 이미지는 하나의 실패한 다운로드가 다른 모든 다운로드를 중단하는 것을 방지하고 트랜잭션 크기를 작게 유지하기 위해 별도의 작업입니다.

질문: 지금까지는 어떠셨나요?

A: 사용하기 쉽고, 모델에서 이것을 구성하는 것이 정말 좋습니다. 앱 자체의 구성 페이지에서 배포 후 더 이상 구성할 필요가 없습니다.

질문: 프로세스 큐 모듈에서 마이그레이션은 어땠나요?

A: 정말 쉽습니다. 하나 이상의 대기열을 구성하고, 마이크로플로우 매개변수를 변경하고(프로세스 대기열과 관련된 추가 엔터티를 제거하고) 호출하는 마이크로플로우의 프로세스 대기열 로직을 단일 마이크로플로우 호출 활동으로 대체하기만 하면 됩니다.

질문: 이번 이전을 위해 어떤 준비를 하셨나요?

A: 영향은 모델에서 프로세스 대기열 모듈을 마우스 오른쪽 버튼으로 클릭하여 '사용법 찾기'를 통해 쉽게 확인할 수 있습니다. 각 백그라운드 작업에 대해 엔터티에서 ProcessQueue.QueuedAction으로의 모듈 간 연결이 존재하며 이를 정리해야 합니다. 구성 및 프로젝트 보안 설정을 위한 ProcessQueue.Process 엔터티에 대한 참조가 남아 있으며, 이 역시 제거할 수 있습니다.

질문: 미래에 대한 제안이 있나요?

A: 클러스터 전체 제한(한 번에 하나의 작업만 실행)과 지수적 재시도 간격으로 자동 재시도를 하는 것이 좋을 것입니다. 그 외에도 Java 작업에서 작업을 예약할 때 식별자가 반환되어 추적할 수 있다면 편리할 것입니다. 마지막으로 지연이나 실행에 대한 특정 시간을 설정할 수 있다면 정말 강력할 것입니다.

시작가!

이 블로그에서 저는 마이크로플로를 비동기적으로 실행하기 위한 수평 확장 가능한 솔루션인 Task Queue의 기능을 다루었습니다. 다음에서 시도해 보세요. Mendix 9. 귀하의 경험을 저희와 공유해 주시기 바랍니다.