이 페이지에서는 태스크 큐의 정의, 사용 시기, 사용 방법을 설명합니다. 태스크 큐를 사용하면 애플리케이션이 사용자 요청 이외에도 비동기식으로 태스크라는 작업을 수행할 수 있습니다. 앱이 백그라운드에서 작업을 실행해야 하는 경우 태스크가 태스크 큐에 추가됩니다. 태스크는 나중에 작업자 서비스에 의해 실행됩니다.
태스크 큐 서비스는 비동기 작업을 위해 설계되었습니다. 작업 전송 시점을 완벽하게 보장하지 않으므로, 사용자가 결과를 기다리는 대화형 애플리케이션에는 적합하지 않습니다.
push 큐와 pull 큐
태스크 큐에는 push와 pull이라는 2가지 유형이 있습니다. 태스크 큐 서비스가 작업 요청을 작업자 서비스로 전달하는 방식은 대기열마다 다릅니다.
push 큐는 App Engine 작업자 서비스에 HTTP 요청을 전달하여 작업을 실행합니다. 안정적이고 일정한 속도로 요청을 보내고 안정적으로 작업을 실행합니다. 사용자는 작업이 대기열에서 전송되는 속도를 제어할 수 있으므로 작업자의 확장 동작과 비용을 제어할 수 있습니다.
작업은 App Engine 서비스를 대상으로 하는 요청으로 실행되므로 엄격한 기한이 적용됩니다. 자동 확장 서비스로 처리되는 작업은 10분 안에 완료되어야 합니다. 기본 및 수동 확장 서비스로 처리되는 작업은 최대 24시간 동안 실행될 수 있습니다.
pull 큐는 작업을 전혀 보내지 않습니다. 대신 다른 작업자 서비스를 사용하여 큐에서 작업을 자체적으로 '임대'합니다. pull 큐를 사용하면 작업이 처리되는 시기와 장소에 대해 더 많은 권한과 유연성을 얻는 대신 더 많은 프로세스를 관리해야 합니다. 작업이 임대되면 임대 작업자가 기한을 선언합니다. 기한이 도래하면 작업자는 작업을 완료하고 삭제해야 합니다. 그렇지 않으면 태스크 큐 서비스에서 다른 작업자가 작업을 임대하도록 허용합니다.
팁: 경우에 따라 Google Cloud Pub/Sub가 pull 큐의 훌륭한 대안이 될 수 있습니다.
모든 태스크 큐 작업은 비동기적인 방식으로 수행됩니다. 작업을 만드는 애플리케이션이 작업을 대기열로 전송합니다. 원본 애플리케이션에는 작업의 완료 또는 성공 알림이 표시되지 않습니다.
작업자가 작업을 처리하지 못하면 태스크 큐 서비스에서 재시도 메커니즘을 대기열에 제공하므로 제한된 횟수만큼 작업을 다시 시도할 수 있습니다.
사용 사례
push 큐
push 큐의 일반적인 사용 사례는 '느린' 작업입니다. 소셜 네트워크 메시지 시스템을 예로 들어 보겠습니다. 사용자가 메시지를 보낼 때마다 네트워크는 보내는 사람의 팔로어를 업데이트해야 합니다. 이 작업에는 시간이 매우 오래 걸릴 수 있습니다. push 큐를 사용할 경우, 애플리케이션은 각 메시지 작업이 도착하면 이를 대기열에 추가하여 처리를 위해 작업자 서비스에 발송할 수 있습니다. 작업자가 작업 요청을 받으면 보내는 사람의 팔로어 목록을 검색하여 각각의 DB를 업데이트할 수 있습니다. 각 데이터베이스 업데이트마다 다른 내보내기 작업을 대기열에 추가하면 작업자의 효율성을 높일 수 있습니다.
push 큐의 또 다른 용도는 예약 작업입니다. 광고 캠페인을 구현하는 애플리케이션을 생각해 봅시다. 이메일 발송을 위해 작성된 작업 그룹을 push 큐에 추가하고 향후 지정된 시간까지 작업을 보류하라는 명령을 포함할 수 있습니다. 기한이 만료되면 태스크 큐 서비스가 작업 실행 요청을 실행하기 시작합니다.
pull 큐
pull 큐는 효율적인 실행을 위해 일괄 작업을 수행해야 하는 경우 효과적입니다. 한 가지 방법은 가져오기 작업에 태그 연결 기능을 활용하는 것입니다. 작업자는 동일한 태그가 있는 작업 그룹을 임대할 수 있습니다. 대표적인 예로는 여러 플레이어와 그룹이 지속적으로 플레이하는 다양한 게임의 리더보드를 관리하는 앱이 있습니다. 새로운 최고 점수가 나올 때마다 앱에서 점수와 플레이어가 포함된 가져오기 작업을 큐에 추가하고 게임 ID를 작업 태그로 사용할 수 있습니다. 작업자는 주기적으로 '깨어나' 동일한 게임 ID의 작업 그룹을 임대하고 리더보드를 업데이트합니다. 지정된 태그 값을 사용하여 작업을 명시적으로 임대하거나, 보낼 작업 중에서 유사한 태그가 지정된 작업 그룹을 서비스에서 결정하도록 할 수 있습니다.
태그를 사용한 일괄 처리는 성능이 매우 강력합니다. 앱이 실행되는 동안 태그를 동적으로 생성할 수 있으므로 작업자는 간편하게 새로운 게임 ID를 처리할 수 있습니다.