KR20200045639A - 큐 관리 장치 및 방법 - Google Patents

큐 관리 장치 및 방법 Download PDF

Info

Publication number
KR20200045639A
KR20200045639A KR1020180126413A KR20180126413A KR20200045639A KR 20200045639 A KR20200045639 A KR 20200045639A KR 1020180126413 A KR1020180126413 A KR 1020180126413A KR 20180126413 A KR20180126413 A KR 20180126413A KR 20200045639 A KR20200045639 A KR 20200045639A
Authority
KR
South Korea
Prior art keywords
message
queue
processing
work
processor
Prior art date
Application number
KR1020180126413A
Other languages
English (en)
Inventor
이광재
오형탁
김재홍
박주경
Original Assignee
삼성에스디에스 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성에스디에스 주식회사 filed Critical 삼성에스디에스 주식회사
Priority to KR1020180126413A priority Critical patent/KR20200045639A/ko
Publication of KR20200045639A publication Critical patent/KR20200045639A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

큐 관리 장치 및 방법이 제공된다. 예시적인 실시예에 따른 큐 관리 장치는, 하나 이상의 클라이언트로부터 작업 메시지의 처리 요청을 수신하는 애플리케이션 서버, 상기 작업 메시지가 적재되는 메시지 큐(message queue) 및 상기 작업 메시지를 처리하는 처리기와 각각 연결되는 큐 관리 장치로서, 상기 애플리케이션 서버로부터 상기 처리 요청을 수신하는 경우 상기 메시지 큐의 상태를 모니터링하고, 상기 메시지 큐의 상태에 따라 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 모니터링부; 상기 작업 메시지가 상기 메시지 큐에 적재되는 경우, 상기 메시지 큐의 처리량(throughput) 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하는 예측부; 및 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인하고, 확인 결과 상기 작업 메시지의 처리가 완료된 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 완료 메시지를 전달하는 응답 수행부를 포함한다.

Description

큐 관리 장치 및 방법{APPARATUS AND METHOD FOR MANAGING QUEUE}
본 발명의 실시예들은 메시지 큐(Message Queue)를 관리하는 기술과 관련된다.
메시지 큐(Message Queue)는 키보드나 마우스와 같은 입력 장치에서 발생되는 사용자의 입력을 메시지로 전달하는 시스템에서 어떤 프로세스에 대한 메시지를 저장하기 위해 할당된 큐를 의미한다. 일반적으로, 이러한 메시지 큐는 서로 다른 시스템이나 서비스를 업무적으로 연결시킬 때 사용된다. 특히, 메시지 큐를 사용하는 서비스는 즉시성 보다는 시스템 자원을 많이 활용하는 작업을 상호 연결시킬 때 주로 사용되며, 클라이언트의 메시지 처리 요청과 이에 대한 응답(즉, 메시지 처리 여부에 대한 응답)의 트랜잭션을 각각 분리시킴으로써 클라이언트에 대한 응답성을 향상시키고 서버로의 부하 집중을 완화시킬 수 있다.
그러나, 종래에는 이와 같은 트랜잭션의 분리로 인해 클라이언트가 메시지 처리가 완료될 때까지 대기하고 이를 확인하는 로직을 별도로 구현하게 되었다. 클라이언트는 폴링(polling) 로직을 통해 메시지 처리의 완료 여부를 주기적으로 확인하였으며, 이 과정에서 매 폴링시마다 항상 기본 대기시간만큼 대기하여야 했다. 일 예시로서, PDF 변환의 처리를 요청하는 트랜잭션이 메시지 큐에 적재된 상태에서 상기 트랜잭션의 처리를 위한 처리기 또는 애플리케이션 서버가 다른 요청의 처리로 인해 바쁜 경우, 클라이언트는 폴링 로직을 통해 상기 트랜잭션의 처리가 완료되었는지를 주기적으로 확인하였으며 이 과정에서 매 폴링시마다 항상 기본 대기시간(예를 들어, 10초)만큼 대기하여야 했다. 특히, 종래에는 업무 피크시간과 같이 응답성이 떨어지는 시간대와 퇴근 후 응답성이 높은 시간대를 구별하지 않고 클라이언트가 항상 최소 기본 대기시간만큼 대기한 후 메시지의 처리가 완료되었는지를 확인하였으며, 이에 따라 클라이언트에게 빠르고 효율적인 응답을 제공할 수 없었다.
한국공개특허공보 제10-2014-0021433호(2014.02.20)
본 발명의 실시예들은 메시지 큐의 상태, 처리기의 현재 가용 자원 등을 고려하여 클라이언트 측 작업 메시지의 처리 요청에 대한 처리 결과를 반환하기 위한 응답 대기시간(또는 폴링 주기)을 동적으로 결정하는 수단을 제공하기 위한 것이다.
예시적인 실시예에 따르면, 하나 이상의 클라이언트로부터 작업 메시지의 처리 요청을 수신하는 애플리케이션 서버, 상기 작업 메시지가 적재되는 메시지 큐(message queue) 및 상기 작업 메시지를 처리하는 처리기와 각각 연결되는 큐 관리 장치로서, 상기 애플리케이션 서버로부터 상기 처리 요청을 수신하는 경우 상기 메시지 큐의 상태를 모니터링하고, 상기 메시지 큐의 상태에 따라 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 모니터링부; 상기 작업 메시지가 상기 메시지 큐에 적재되는 경우, 상기 메시지 큐의 처리량(throughput) 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하는 예측부; 및 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인하고, 확인 결과 상기 작업 메시지의 처리가 완료된 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 완료 메시지를 전달하는 응답 수행부를 포함하는, 큐 관리 장치가 제공된다.
상기 모니터링부는, 현재 상기 메시지 큐의 적재량이 제1 임계치 이하인 경우 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하고, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 상기 메시지 큐에 적재시킬 수 있다.
상기 응답 수행부는, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 지연 메시지를 전달할 수 있다.
상기 예측부는, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우 상기 메시지 큐의 처리량 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측할 수 있다.
상기 예측부는, 상기 메시지 큐의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 상기 처리기의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측할 수 있다.
다른 예시적인 실시예에 따르면, 하나 이상의 클라이언트로부터 작업 메시지의 처리 요청을 수신하는 애플리케이션 서버, 상기 작업 메시지가 적재되는 메시지 큐(message queue) 및 상기 작업 메시지를 처리하는 처리기와 각각 연결되는 큐 관리 장치에서의 큐 관리 방법으로서, 상기 큐 관리 장치의 모니터링부에서, 상기 애플리케이션 서버로부터 상기 처리 요청을 수신하는 경우 상기 메시지 큐의 상태를 모니터링하는 단계; 상기 모니터링부에서, 상기 메시지 큐의 상태에 따라 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 단계; 상기 큐 관리 장치의 예측부에서, 상기 작업 메시지가 상기 메시지 큐에 적재되는 경우, 상기 메시지 큐의 처리량(throughput) 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하는 단계; 및 상기 큐 관리 장치의 응답 수행부에서, 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인하고, 확인 결과 상기 작업 메시지의 처리가 완료된 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 완료 메시지를 전달하는 단계를 포함하는, 큐 관리 방법이 제공된다.
상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 단계는, 현재 상기 메시지 큐의 적재량이 제1 임계치 이하인 경우 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하고, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 상기 메시지 큐에 적재시킬 수 있다.
상기 큐 관리 방법은, 상기 메시지 큐의 상태를 모니터링하는 단계 이후, 상기 응답 수행부에서, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 지연 메시지를 전달하는 단계를 더 포함할 수 있다.
상기 큐 관리 방법은, 상기 대기시간을 예측하는 단계 이후, 상기 예측부에서, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우 상기 메시지 큐의 처리량 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측하는 단계를 더 포함할 수 있다.
상기 대기시간을 예측하는 단계는, 상기 메시지 큐의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 상기 처리기의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측할 수 있다.
예시적인 실시예에 따르면, 메시지 큐의 적재량이 없거나 설정된 값 이하인 경우 큐 관리 장치가 처리기로 작업 메시지의 실시간 처리를 요청하도록 함으로써, 클라이언트는 작업 메시지의 실시간 처리가 가능한 리소스 상황에서 불필요한 대기시간 없이 곧바로 처리 결과를 반환 받을 수 있다.
또한, 예시적인 실시예에 따르면, 클라이언트가 폴링 주기에 따라 작업 메시지의 처리 여부를 확인하는 대신, 큐 관리 장치가 메시지 큐의 상태에 따라 작업 메시지의 처리 확인을 위한 최적의 대기시간을 동적으로 결정하고 상기 대기시간만큼 대기한 후 클라이언트 측으로 응답을 전달하도록 함으로써, 클라이언트는 별도의 폴링 로직을 구현할 필요가 없으며 상기 최적의 대기시간 내에 처리 결과를 반환 받을 수 있다.
또한, 예시적인 실시예에 따르면, 메시지 큐의 적재량이 매우 많은 경우 큐 관리 장치가 애플리케이션 서버로 상기 작업 메시지의 처리 지연 메시지를 전달하도록 함으로써, 클라이언트는 현재 작업 메시지의 실시간 처리가 불가능하며 긴 시간만큼 대기가 필요한 상황임을 곧바로 응답 받을 수 있으며, 불필요한 폴링을 계속적으로 수행하는 낭비를 줄일 수 있다.
이와 같이, 클라이언트는 메시지 큐가 여유로운 경우 빠른 응답을 반환 받을 수 있으며, 메시지 큐가 여유롭지 않더라도 현재 처리중인 상태를 곧바로 반환 받을 수 있으므로 사용자에게 빠른 피드백의 제공이 가능하다. 또한, 종래 클라이언트에서 처리되었던 폴링 로직을 큐 관리 장치에서 대신 수행하도록 함으로써, 반복적인 폴링 작업으로 인해 발생될 수 있는 클라이언트 측 부하를 경감시킬 수 있다. 또한, 이 경우 애플리케이션 서버에서 복수의 클라이언트 각각으로부터 별도의 폴링 메시지(즉, 상태 확인 요청 메시지)를 수신하지 않게 되므로, 이로 인한 애플리케이션 서버 측 부하를 경감시킬 수 있다.
도 1은 일반적인 메시지 처리 시스템의 상세 구성을 나타낸 블록도
도 2는 예시적인 실시예에 따른 메시지 처리 시스템의 상세 구성을 나타낸 블록도
도 3은 예시적인 실시예에 따른 큐 관리 장치의 상세 구성을 나타낸 블록도
도 4는 예시적인 실시예에 따른 큐 관리 방법을 설명하기 위한 흐름도
도 5는 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경을 예시하여 설명하기 위한 블록도
이하, 도면을 참조하여 본 발명의 구체적인 실시형태를 설명하기로 한다. 이하의 상세한 설명은 본 명세서에서 기술된 방법, 장치 및/또는 시스템에 대한 포괄적인 이해를 돕기 위해 제공된다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.
본 발명의 실시예들을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 상세한 설명에서 사용되는 용어는 단지 본 발명의 실시예들을 기술하기 위한 것이며, 결코 제한적이어서는 안 된다. 명확하게 달리 사용되지 않는 한, 단수 형태의 표현은 복수 형태의 의미를 포함한다. 본 설명에서, "포함" 또는 "구비"와 같은 표현은 어떤 특성들, 숫자들, 단계들, 동작들, 요소들, 이들의 일부 또는 조합을 가리키기 위한 것이며, 기술된 것 이외에 하나 또는 그 이상의 다른 특성, 숫자, 단계, 동작, 요소, 이들의 일부 또는 조합의 존재 또는 가능성을 배제하도록 해석되어서는 안 된다.
도 1은 일반적인 메시지 처리 시스템(100)의 상세 구성을 나타낸 블록도이다. 도 1에 도시된 바와 같이, 메시지 처리 시스템(100)은 복수의 클라이언트(102), 애플리케이션 서버(104), 메시지 큐(106), 복수의 처리기(108) 및 데이터베이스(110)를 포함한다. 한편, 여기서는 설명의 편의상 애플리케이션 서버(104), 메시지 큐(106), 복수의 처리기(108) 및 데이터베이스(110)가 각각 별도의 구성인 것으로 도시하였으나 이는 일 예시에 불과하며, 메시지 큐(106), 복수의 처리기(108) 및 데이터베이스(110)는 애플리케이션 서버(104)의 일 구성으로 이루어질 수도 있다.
클라이언트(102)는 작업 메시지를 생성하고, 애플리케이션 서버(104)로 상기 작업 메시지의 처리를 요청한다. 여기서, 클라이언트(102)는 예를 들어, 서버, 데스크탑, 노트북, 태블릿 컴퓨터, 스마트폰, PDA, 스마트 워치 등과 같은 웨어러블 디바이스 등이 될 수 있다. 이때, 클라이언트(101)는 애플리케이션 서버(104)와 통신하기 위한 전용 애플리케이션(또는 웹 애플리케이션)을 구비할 수 있으며, 상기 애플리케이션을 통해 상기 작업 메시지의 생성, 상기 작업 메시지의 처리 요청 등의 기능을 수행할 수 있다. 도 1에 도시된 바와 같이, 각 클라이언트(102)는 네트워크(미도시)를 통해 애플리케이션 서버(104)와 연결될 수 있다. 이때, 네트워크는 인터넷, 하나 이상의 로컬 영역 네트워크(local area networks), 광역 네트워크(wire area networks), 셀룰러 네트워크, 모바일 네트워크, 그 밖에 다른 종류의 네트워크들, 또는 이러한 네트워크들의 조합을 포함할 수 있다. 또한, 본 실시예들에 있어서, 작업 메시지는 예를 들어, PDF 문서 변환 메시지, 인덱싱 메시지, 바이러스 체크 메시지, 금칙어 체크 메시지 등과 같이 주로 일정 시간이 소요되는 작업의 처리 메시지일 수 있다. 이러한 작업 메시지는 애플리케이션 서버(104)를 거쳐 메시지 큐(106)에 적재되고, 처리기(108)를 통해 순차적으로 처리될 수 있다.
애플리케이션 서버(104)는 하나 이상의 클라이언트(102)로부터 작업 메시지의 처리 요청을 수신하고, 클라이언트(102) 측으로 상기 처리 요청에 대한 응답을 수행한다. 도 1에 도시된 바와 같이, 애플리케이션 서버(104)는 메시지 큐(106) 및 데이터 베이스(110)와 각각 연결될 수 있다.
메시지 큐(106)는 애플리케이션 서버(104)로부터 작업 메시지를 수신하고, 이를 순차적으로 적재시킨다. 메시지 큐(106)는 복수의 처리기(108)와 연결되고, 내부에 적재된 작업 메시지를 대응되는 처리기(108)로 출력할 수 있다.
처리기(108)는 메시지 큐(106)에 적재된 작업 메시지 중 자신이 담당하는 작업 메시지를 처리한다. 일 예시로서, 제1 처리기는 PDF 변환을 담당하며, 제2 처리기는 본문 인덱싱을 담당하며, 제3 처리기는 바이러스 스캔을 담당할 수 있다. 이와 같이, 각 처리기(108)는 그 기능에 따라 별도로 존재할 수 있으며, 메시지 큐(106)에 적재된 작업 메시지 중 자신이 담당하는 작업 메시지를 처리할 수 있다. 이후, 처리기(108)는 작업 메시지의 처리 결과를 데이터베이스(110)에 전달할 수 있다. 한편, 여기서는 각 처리기(108)가 그 기능에 따라 별도로 존재하는 것으로 설명하였으나 이는 일 예시에 불과하며, 하나의 처리기(108)에서 여러 기능을 수행할 수도 있다.
데이터베이스(110)는 처리기(108)에서의 작업 메시지 처리 결과가 저장되는 저장소이다. 처리기(108)는 작업 메시지의 처리 결과를 데이터베이스(110)에 전달하고, 애플리케이션 서버(104)는 데이터베이스(110)에 저장된 처리 결과를 상기 작업 메시지의 처리를 요청한 클라이언트(102) 측으로 전달할 수 있다.
한편, 클라이언트(102)는 작업 메시지의 처리 요청(즉, 첫 번째 트랜잭션) 이후 폴링(polling) 로직을 통해 상기 작업 메시지(즉, 첫 번째 트랜잭션)의 처리가 완료되었는지를 애플리케이션 서버(104)에 주기적으로 확인할 수 있으며, 이 경우 폴링을 위한 주기가 미리 설정되어 있어 현재 상기 작업 메시지의 처리가 가능하더라도 기본 대기시간(예를 들어, 10초)만큼의 대기가 필수적이다(애플리케이션 서버의 가용성 측면).
일 예시로서, PDF 변환의 처리를 요청하는 트랜잭션이 메시지 큐(106)에 적재된 상태에서 상기 트랜잭션의 처리를 위한 처리기(108) 또는 애플리케이션 서버(104)가 다른 요청의 처리로 인해 바쁜 경우, 클라이언트(102)는 폴링 로직을 통해 상기 트랜잭션의 처리가 완료되었는지를 주기적으로 확인하는 과정을 수행하게 되며 이 과정에서 매 폴링시마다 항상 기본 대기시간(예를 들어, 10초)만큼 대기하게 된다. 또한, 이 경우 작업 메시지의 처리 확인을 위한 API(Application Program Interface)가 클라이언트(102) 측에 별도로 제공되어야만 하며, API가 별도로 제공된다 하더라도 폴링 주기가 짧을 경우 시스템 부하가 예상되고 폴링 주기가 길 경우 확인 간격이 길어지는 문제가 발생하게 된다.
이와 같이, 클라이언트(102)는 일정 시간(t) 동안 n회의 폴링을 수행할 수 있으며, 상기 폴링을 통해 자신이 요청한 작업 메시지, 즉 첫 번재 트랜잭션의 처리 완료를 확인할 경우 애플리케이션 서버(104)로부터 상기 처리 결과가 포함된 응답 메시지를 수신할 수 있다.
즉, 일반적인 메시지 처리 시스템(100)에 따르면, 클라이언트(102)의 작업 메시지 처리 요청과 이에 대한 응답(즉, 메시지 처리 여부에 대한 응답)의 트랜잭션이 각각 분리되어 작업 메시지의 처리에 대한 상태 추적(예를 들어, 처리 중, 처리 완료 등의 상태 추적)이 필요하게 되며, 클라이언트(102)는 상기 처리가 완료될 때까지 대기하고 이를 확인하는 로직을 별도로 구현하여야만 한다. 이에 따라, 클라이언트(102)는 작업 메시지의 실시간 처리가 가능한 리소스 상황에서도 빠른 응답을 수신할 수 없으며, 처리 결과의 확인을 위한 폴링 주기의 배수만큼의 대기가 필수적이다. 예를 들어, 클라이언트(102)가 화면 표시를 위해 PDF 변환의 완료 체크를 10초마다 수행한다고 가정할 경우, 실제 PDF 변환이 PDF 변환 요청 후 11초만에 완료된다면 클라이언트(102)는 20초를 대기하게 된다. 이 경우, 클라이언트(102)는 불필요한 시간, 즉, 9초 동안 추가적인 대기를 하여야 하는 문제점이 있다. 또한, 일반적으로 이러한 폴링 주기는 테스트에 의해 하드코팅되어 애플리케이션 서버(104)의 상황에 맞게 조절할 수 없으며, 폴링 주기의 변경시에는 각 클라이언트(102)의 폴링 로직을 일일이 수정하여야 하는 번거로움이 있다.
이에 따라, 이하에서는 이러한 문제점을 해결하기 위한 예시적인 실시예에 따른 메시지 처리 시스템(200)에 대해 살펴보기로 한다.
도 2는 예시적인 실시예에 따른 메시지 처리 시스템(200)의 상세 구성을 나타낸 블록도이다. 도 2에 도시된 바와 같이, 예시적인 실시예에 따른 메시지 처리 시스템(200)은 복수의 클라이언트(202), 애플리케이션 서버(204), 메시지 큐(206), 복수의 처리기(208), 데이터베이스(210) 및 큐 관리 장치(212)를 포함한다. 한편, 도 1을 참조하여 설명하였던 실시예에서의 구성요소와 대응되는 구성요소는 앞선 실시예에서 설명한 바와 동일 또는 유사한 기능을 수행하며, 앞서 설명한 내용과 중복되는 내용에 대한 구체적인 설명은 이하에서 생략하도록 한다.
클라이언트(202)는 작업 메시지를 생성하고, 애플리케이션 서버(204)로 상기 작업 메시지의 처리를 요청한다. 본 실시예들에 있어서, 작업 메시지는 처리 대상이 되는 메시지(또는 트랜잭션)로서, 예를 들어, PDF 문서 변환 메시지, 인덱싱 메시지, 바이러스 체크 메시지, 금칙어 체크 메시지 등이 될 수 있다.
애플리케이션 서버(204)는 하나 이상의 클라이언트(202)로부터 작업 메시지의 처리 요청을 수신하고, 클라이언트(202) 측으로 상기 처리 요청에 대한 응답을 수행한다. 도 2에 도시된 바와 같이, 애플리케이션 서버(204)는 큐 관리 장치(212) 및 데이터베이스(210)와 각각 연결될 수 있다.
메시지 큐(206)는 큐 관리 장치(212)를 통해 애플리케이션 서버(204)로부터 작업 메시지를 수신하고, 큐 관리 장치(212)의 제어에 따라 이를 내부에 적재시킨다. 메시지 큐(206)는 복수의 처리기(208)와 연결되고, 내부에 적재된 작업 메시지를 대응되는 처리기(208)로 출력할 수 있다.
처리기(208)는 메시지 큐(206)에 적재된 작업 메시지 중 자신이 담당하는 작업 메시지를 처리한다. 일 예시로서, 제1 처리기는 PDF 변환을 담당하며, 제2 처리기는 본문 인덱싱을 담당하며, 제3 처리기는 바이러스 스캔을 담당할 수 있다. 이와 같이, 각 처리기(208)는 그 기능에 따라 별도로 존재할 수 있으며, 메시지 큐(206)에 적재된 작업 메시지 중 자신이 담당하는 작업 메시지를 처리할 수 있다. 또한, 각 처리기(208)는 큐 관리 장치(212)와 연결되어 큐 관리 장치(212)를 통해 수신된 작업 메시지를 실시간으로 처리할 수도 있다. 도 2를 참조하면, 각 처리기(208) 큐 컨슈머(Queue Consumer) 및 레스트풀 핸들러(RESTful Handler)를 포함할 수 있다. 큐 컨슈머는 메시지 큐(206)에 적재된 작업 메시지를 순차적으로 처리하는 모듈이며, 레스트풀 핸들러는 큐 관리 장치(212)를 통해 수신된 작업 메시지를 실시간으로 처리하는 모듈이다. 처리기(208)는 작업 메시지의 처리 결과를 데이터베이스(110)에 전달할 수 있다.
데이터베이스(210)는 처리기(208)에서의 작업 메시지 처리 결과가 저장되는 저장소이다. 처리기(208)는 작업 메시지의 처리 결과를 데이터베이스(210)에 전달하고, 애플리케이션 서버(204)는 데이터베이스(210)에 저장된 처리 결과를 상기 작업 메시지의 처리를 요청한 클라이언트(202) 측으로 전달할 수 있다.
큐 관리 장치(212)는 애플리케이션 서버(204), 메시지 큐(206) 및 처리기(208)와 각각 연결되어 클라이언트(202) 측 작업 메시지의 처리 요청에 대한 보다 빠르고 효율적인 응답 처리를 수행한다.
구체적으로, 큐 관리 장치(212)는 애플리케이션 서버(204)로부터 클라이언트(202) 측 작업 메시지의 처리 요청을 수신하고, 상기 처리 요청의 수신에 따라 메시지 큐(206)의 상태를 모니터링한다. 큐 관리 장치(212)는 메시지 큐(206)의 상태에 따라 처리기(208)로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 메시지 큐(206)에 적재시킬 수 있다.
일 예시로서, 큐 관리 장치(212)는 현재 메시지 큐(206)의 적재량(예를 들어, 현재 메시지 큐(206)에 적재된 작업 메시지의 수)이 제1 임계치 이하인 경우 처리기(208)로 상기 작업 메시지의 실시간 처리를 요청할 수 있다. 이 경우, 처리기(208)의 레스트풀 핸들러(RESTful Handler)는 상기 작업 메시지를 실시간으로 처리하고, 그 처리 결과를 큐 관리 장치(212) 및 데이터베이스(210)로 각각 전달할 수 있다. 이후, 큐 관리 장치(212)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 완료 메시지를 전달하고, 애플리케이션 서버(204)는 상기 처리 결과를 포함하는 응답 메시지를 클라이언트(202) 측으로 곧바로 전달할 수 있다. 즉, 예시적인 실시예에 따르면, 클라이언트(202)는 작업 메시지의 실시간 처리가 가능한 리소스 상황에서 불필요한 대기시간 없이 곧바로 처리 결과를 반환 받을 수 있다.
다른 예시로서, 큐 관리 장치(212)는 현재 메시지 큐(206)의 적재량(예를 들어, 현재 메시지 큐(206)에 적재된 작업 메시지의 수)이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 메시지 큐(206)에 적재시킬 수 있다. 상기 작업 메시지가 메시지 큐(206)에 적재되는 경우, 큐 관리 장치(212)는 메시지 큐(206)의 처리량(throughput) 및 처리기(208)의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하고, 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인할 수 있다. 구체적으로, 큐 관리 장치(212)는 메시지 큐(206)의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 처리기(208)의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측할 수 있다. 예를 들어, 큐 관리 장치(212)가 1초당 처리하는 작업 메시지의 수가 5개인 경우, 큐 관리 장치(212)는 단위 시간당(예를 들어, 초당) 작업 메시지 1개의 처리시간(t)을 0.2초로 계산할 수 있다. 이때, 큐 관리 장치(212)는 처리기(208)의 가용 자원에 따라 상기 처리시간(t)을 아래와 같이 보정함으로써 상기 대기시간(Dt)을 예측할 수 있다.
대기시간(Dt) = t + α
여기서, 처리기(208)의 가용 자원에 따른 보정값(α)은 허용 오차(tolerance)로서, 설정된 임의의 상수값일 수 있다.
큐 관리 장치(212)는 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인할 수 있다. 확인 결과 상기 작업 메시지의 처리가 완료된 경우, 큐 관리 장치(212)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 완료 메시지를 전달할 수 있다. 이에 따라, 애플리케이션 서버(204)는 상기 처리 완료 메시지와 작업 메시지의 처리 결과를 포함하는 응답 메시지를 클라이언트(202) 측으로 전달할 수 있다. 만약, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우, 큐 관리 장치(212)는 메시지 큐(206)의 처리량 및 처리기(208)의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측할 수 있다.
이와 같이, 예시적인 실시예에 따르면, 클라이언트(202)가 폴링 주기에 따라 작업 메시지의 처리 여부를 확인하는 대신, 큐 관리 장치(212)가 메시지 큐(206)의 상태에 따라 작업 메시지의 처리 확인을 위한 최적의 대기시간을 동적으로 결정하고 상기 대기시간만큼 대기한 후 클라이언트(202) 측으로 응답을 전달하도록 함으로써, 클라이언트(202)는 별도의 폴링 로직을 구현할 필요가 없으며 폴링 로직의 구현이 불필요하며 상기 최적의 대기시간 내에 처리 결과를 반환 받을 수 있다.
또 다른 예시로서, 큐 관리 장치(212)는 현재 메시지 큐(206)의 적재량(예를 들어, 현재 메시지 큐(206)에 적재된 작업 메시지의 수)이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우 애플리케이션 서버(204)로 상기 작업 메시지의 처리 지연 메시지를 전달할 수 있다. 애플리케이션 서버(204)는 상기 처리 지연 메시지를 포함하는 응답 메시지를 클라이언트(202) 측으로 전달할 수 있다. 이 경우, 클라이언트(202)는 현재 작업 메시지의 실시간 처리가 불가능하며 긴 시간만큼 대기가 필요한 상황임을 곧바로 응답 받을 수 있으며, 불필요한 폴링을 계속적으로 수행하는 낭비를 줄일 수 있다.
도 3은 예시적인 실시예에 따른 큐 관리 장치(212)의 상세 구성을 나타낸 블록도이다. 도 3에 도시된 바와 같이, 예시적인 실시예에 따른 큐 관리 장치(212)는 요청 수신부(302), 모니터링부(304), 예측부(306) 및 응답 수행부(308)를 포함한다.
요청 수신부(302)는 애플리케이션 서버(204)로부터 클라이언트(202) 측 작업 메시지의 처리 요청을 수신한다.
모니터링부(304)는 상기 처리 요청을 수신함에 따라 메시지 큐(206)의 상태를 모니터링한다. 여기서, 메시지 큐(206)의 상태는 예를 들어, 현재 메시지 큐(206)의 적재량(예를 들어, 현재 메시지 큐(206)에 적재된 작업 메시지의 수)이 될 수 있다. 다만, 이에 한정되는 것은 아니며, 메시지 큐(206)의 상태는 예를 들어, 애플리케이션 서버(204)의 CPU 또는 메모리 사용량, 애플리케이션 서버(204)에서 동시에 허용 가능한 작업 메시지의 수 등이 될 수도 있다.
또한, 모니터링부(304)는 메시지 큐(206)의 상태에 따라 처리기(208)로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 메시지 큐(206)에 적재시킬 수 있다.
일 예시로서, 현재 메시지 큐(206)의 적재량이 제1 임계치 이하인 경우(예를 들어, 적재량 = 0인 경우), 모니터링부(304)는 처리기(208)로 상기 작업 메시지의 실시간 처리를 요청할 수 있다. 이 경우, 처리기(208)의 레스트풀 핸들러(RESTful Handler)는 상기 작업 메시지를 실시간으로 처리하고, 그 처리 결과를 큐 관리 장치(212) 및 데이터베이스(210)로 각각 전달할 수 있다. 이후, 응답 수행부(208)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 완료 메시지를 전달하고, 애플리케이션 서버(204)는 데이터베이스(210)에 저장된 처리 결과를 포함하는 응답 메시지를 클라이언트(202) 측으로 곧바로 전달할 수 있다.
다른 예시로서, 현재 메시지 큐(206)의 적재량이 상기 제1 임계치를 초과하는 경우(예를 들어, 적재량 = 1인 경우), 모니터링부(304)는 상기 작업 메시지를 메시지 큐(206)에 적재시킬 수 있다.
또한, 현재 메시지 큐(206)의 적재량이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우(예를 들어, 적재량 = 10인 경우), 후술할 응답 수행부(308)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 지연 메시지를 전달할 수 있다. 애플리케이션 서버(204)는 상기 처리 지연 메시지를 포함하는 응답 메시지를 클라이언트(202) 측으로 전달할 수 있다.
예측부(306)는 상기 작업 메시지가 메시지 큐(206)에 적재되는 경우 메시지 큐(206)의 처리량 및 처리기(208)의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측한다. 상술한 바와 같이, 예측부(306)는 메시지 큐(206)의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 처리기(208)의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측할 수 있다.
만약, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우, 예측부(306)는 메시지 큐(206)의 처리량 및 처리기(208)의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측할 수 있으며 앞선 과정을 반복 수행할 수 있다.
응답 수행부(308)는 클라이언트(202) 측 작업 메시지의 처리 요청에 따른 응답을 수행한다.
일 예시로서, 작업 메시지가 처리기(208)를 통해 처리 완료되는 경우, 응답 수행부(308)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 완료 메시지를 전달할 수 있다. 이에 따라, 애플리케이션 서버(204)는 상기 처리 완료 메시지와 작업 메시지의 처리 결과를 포함하는 응답 메시지를 클라이언트(202) 측으로 전달할 수 있다.
다른 예시로서, 현재 메시지 큐(206)의 적재량이 과도하여 작업 메시지의 처리가 지연될 것으로 예상되는 경우(즉, 단 시간 내에 작업 메시지의 처리가 불가능한 경우), 응답 수행부(308)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 지연 메시지를 전달할 수 있다. 이에 따라, 애플리케이션 서버(204)는 상기 처리 지연 메시지를 포함하는 응답 메시지를 클라이언트(202) 측으로 전달할 수 있다.
도 4는 예시적인 실시예에 따른 큐 관리 방법을 설명하기 위한 흐름도이다. 도 4에 도시된 방법은 예를 들어, 전술한 큐 관리 장치(212)에 의해 수행될 수 있다. 도시된 흐름도에서는 상기 방법을 복수 개의 단계로 나누어 기재하였으나, 적어도 일부의 단계들은 순서를 바꾸어 수행되거나, 다른 단계와 결합되어 함께 수행되거나, 생략되거나, 세부 단계들로 나뉘어 수행되거나, 또는 도시되지 않은 하나 이상의 단계가 부가되어 수행될 수 있다.
S102 단계에서, 요청 수신부(302)는 애플리케이션 서버(204)로부터 클라이언트(202) 측 작업 메시지의 처리 요청을 수신한다.
S104 단계에서, 모니터링부(304)는 상기 처리 요청을 수신함에 따라 메시지 큐(206)의 상태를 모니터링한다. 여기서, 메시지 큐(206)의 상태는 예를 들어, 현재 메시지 큐(206)의 적재량일 수 있다.
S106 단계에서, 모니터링부(304)는 현재 메시지 큐(206)의 적재량이 제1 임계치 이하인 경우 처리기(208)로 상기 작업 메시지의 실시간 처리를 요청한다.
S108 단계에서, 모니터링부(304)는 현재 메시지 큐(206)의 적재량이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 메시지 큐(206)에 적재시킨다.
S110 단계에서, 모니터링부(304)는 메시지 큐(206)의 처리량을 확인한다.
S112 단계에서, 모니터링부(304)는 처리기(208)의 가용 자원을 확인한다.
S114 단계에서, 예측부(306)는 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측한다. 일 예시로서, 예측부(306)는 메시지 큐(206)의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 처리기(208)의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측할 수 있다.
S116 단계에서, 응답 수행부(308)는 상기 대기시간만큼 대기한다.
S118 단계에서, 응답 수행부(308)는 상기 대기시간만큼 대기한 후 작업 메시지의 처리 완료 여부를 확인한다. 확인 결과, 상기 작업 메시지의 처리가 완료되지 않은 경우, S110 단계로 되돌아가 앞선 과정이 반복 수행된다.
S120 단계에서, 응답 수행부(308)는 상기 작업 메시지의 처리가 완료되었음을 확인한다.
S122 단계에서, 응답 수행부(308)는 애플리케이션 서버(204)로 상기 작업 메시지의 처리 완료 메시지를 전달한다.
도 5는 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경을 예시하여 설명하기 위한 블록도이다. 도시된 실시예에서, 각 컴포넌트들은 이하에 기술된 것 이외에 상이한 기능 및 능력을 가질 수 있고, 이하에 기술되지 것 이외에도 추가적인 컴포넌트를 포함할 수 있다.
도시된 컴퓨팅 환경(10)은 컴퓨팅 장치(12)를 포함한다. 일 실시예에서, 컴퓨팅 장치(12)는 큐 관리 장치(212), 또는 큐 관리 장치(212)에 포함되는 하나 이상의 컴포넌트일 수 있다.
컴퓨팅 장치(12)는 적어도 하나의 프로세서(14), 컴퓨터 판독 가능 저장 매체(16) 및 통신 버스(18)를 포함한다. 프로세서(14)는 컴퓨팅 장치(12)로 하여금 앞서 언급된 예시적인 실시예에 따라 동작하도록 할 수 있다. 예컨대, 프로세서(14)는 컴퓨터 판독 가능 저장 매체(16)에 저장된 하나 이상의 프로그램들을 실행할 수 있다. 상기 하나 이상의 프로그램들은 하나 이상의 컴퓨터 실행 가능 명령어를 포함할 수 있으며, 상기 컴퓨터 실행 가능 명령어는 프로세서(14)에 의해 실행되는 경우 컴퓨팅 장치(12)로 하여금 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.
컴퓨터 판독 가능 저장 매체(16)는 컴퓨터 실행 가능 명령어 내지 프로그램 코드, 프로그램 데이터 및/또는 다른 적합한 형태의 정보를 저장하도록 구성된다. 컴퓨터 판독 가능 저장 매체(16)에 저장된 프로그램(20)은 프로세서(14)에 의해 실행 가능한 명령어의 집합을 포함한다. 일 실시예에서, 컴퓨터 판독 가능 저장 매체(16)는 메모리(랜덤 액세스 메모리와 같은 휘발성 메모리, 비휘발성 메모리, 또는 이들의 적절한 조합), 하나 이상의 자기 디스크 저장 디바이스들, 광학 디스크 저장 디바이스들, 플래시 메모리 디바이스들, 그 밖에 컴퓨팅 장치(12)에 의해 액세스되고 원하는 정보를 저장할 수 있는 다른 형태의 저장 매체, 또는 이들의 적합한 조합일 수 있다.
통신 버스(18)는 프로세서(14), 컴퓨터 판독 가능 저장 매체(16)를 포함하여 컴퓨팅 장치(12)의 다른 다양한 컴포넌트들을 상호 연결한다.
컴퓨팅 장치(12)는 또한 하나 이상의 입출력 장치(24)를 위한 인터페이스를 제공하는 하나 이상의 입출력 인터페이스(22) 및 하나 이상의 네트워크 통신 인터페이스(26)를 포함할 수 있다. 입출력 인터페이스(22) 및 네트워크 통신 인터페이스(26)는 통신 버스(18)에 연결된다. 입출력 장치(24)는 입출력 인터페이스(22)를 통해 컴퓨팅 장치(12)의 다른 컴포넌트들에 연결될 수 있다. 예시적인 입출력 장치(24)는 포인팅 장치(마우스 또는 트랙패드 등), 키보드, 터치 입력 장치(터치패드 또는 터치스크린 등), 음성 또는 소리 입력 장치, 다양한 종류의 센서 장치 및/또는 촬영 장치와 같은 입력 장치, 및/또는 디스플레이 장치, 프린터, 스피커 및/또는 네트워크 카드와 같은 출력 장치를 포함할 수 있다. 예시적인 입출력 장치(24)는 컴퓨팅 장치(12)를 구성하는 일 컴포넌트로서 컴퓨팅 장치(12)의 내부에 포함될 수도 있고, 컴퓨팅 장치(12)와는 구별되는 별개의 장치로 컴퓨팅 장치(12)와 연결될 수도 있다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 전술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다. 그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.
10 : 컴퓨팅 환경
12 : 컴퓨팅 장치
14 : 프로세서
16 : 컴퓨터 판독 가능 저장 매체
18 : 통신 버스
20 : 프로그램
22 : 입출력 인터페이스
24 : 입출력 장치
26 : 네트워크 통신 인터페이스
100, 200 : 메시지 처리 시스템
102, 202 : 클라이언트
104, 204 : 애플리케이션 서버
106, 206 : 메시지 큐
108, 208 : 처리기
110, 210 : 데이터베이스
212 : 큐 관리 장치
302 : 요청 수신부
304 : 모니터링부
306 : 예측부
308 : 응답 수행부

Claims (10)

  1. 하나 이상의 클라이언트로부터 작업 메시지의 처리 요청을 수신하는 애플리케이션 서버, 상기 작업 메시지가 적재되는 메시지 큐(message queue) 및 상기 작업 메시지를 처리하는 처리기와 각각 연결되는 큐 관리 장치로서,
    상기 애플리케이션 서버로부터 상기 처리 요청을 수신하는 경우 상기 메시지 큐의 상태를 모니터링하고, 상기 메시지 큐의 상태에 따라 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 모니터링부;
    상기 작업 메시지가 상기 메시지 큐에 적재되는 경우, 상기 메시지 큐의 처리량(throughput) 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하는 예측부; 및
    상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인하고, 확인 결과 상기 작업 메시지의 처리가 완료된 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 완료 메시지를 전달하는 응답 수행부를 포함하는, 큐 관리 장치.
  2. 청구항 1에 있어서,
    상기 모니터링부는, 현재 상기 메시지 큐의 적재량이 제1 임계치 이하인 경우 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하고, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 상기 메시지 큐에 적재시키는, 큐 관리 장치.
  3. 청구항 2에 있어서,
    상기 응답 수행부는, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 지연 메시지를 전달하는, 큐 관리 장치.
  4. 청구항 1에 있어서,
    상기 예측부는, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우 상기 메시지 큐의 처리량 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측하는, 큐 관리 장치.
  5. 청구항 1에 있어서,
    상기 예측부는, 상기 메시지 큐의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 상기 처리기의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측하는, 큐 관리 장치.
  6. 하나 이상의 클라이언트로부터 작업 메시지의 처리 요청을 수신하는 애플리케이션 서버, 상기 작업 메시지가 적재되는 메시지 큐(message queue) 및 상기 작업 메시지를 처리하는 처리기와 각각 연결되는 큐 관리 장치에서의 큐 관리 방법으로서,
    상기 큐 관리 장치의 모니터링부에서, 상기 애플리케이션 서버로부터 상기 처리 요청을 수신하는 경우 상기 메시지 큐의 상태를 모니터링하는 단계;
    상기 모니터링부에서, 상기 메시지 큐의 상태에 따라 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 단계;
    상기 큐 관리 장치의 예측부에서, 상기 작업 메시지가 상기 메시지 큐에 적재되는 경우, 상기 메시지 큐의 처리량(throughput) 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 작업 메시지의 처리 결과를 확인하기 위한 대기시간을 예측하는 단계; 및
    상기 큐 관리 장치의 응답 수행부에서, 상기 대기시간만큼 대기한 후 상기 작업 메시지의 처리 결과를 확인하고, 확인 결과 상기 작업 메시지의 처리가 완료된 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 완료 메시지를 전달하는 단계를 포함하는, 큐 관리 방법.
  7. 청구항 6에 있어서,
    상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하거나 상기 작업 메시지를 상기 메시지 큐에 적재시키는 단계는, 현재 상기 메시지 큐의 적재량이 제1 임계치 이하인 경우 상기 처리기로 상기 작업 메시지의 실시간 처리를 요청하고, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치를 초과하는 경우 상기 작업 메시지를 상기 메시지 큐에 적재시키는, 큐 관리 방법.
  8. 청구항 7에 있어서,
    상기 메시지 큐의 상태를 모니터링하는 단계 이후,
    상기 응답 수행부에서, 현재 상기 메시지 큐의 적재량이 상기 제1 임계치보다 큰 제2 임계치 이상인 경우 상기 애플리케이션 서버로 상기 작업 메시지의 처리 지연 메시지를 전달하는 단계를 더 포함하는, 큐 관리 방법.
  9. 청구항 6에 있어서,
    상기 대기시간을 예측하는 단계 이후,
    상기 예측부에서, 상기 대기시간만큼 대기한 후에도 상기 작업 메시지의 처리가 완료되지 않은 경우 상기 메시지 큐의 처리량 및 상기 처리기의 가용 자원 중 하나 이상을 고려하여 상기 대기시간을 재예측하는 단계를 더 포함하는, 큐 관리 방법.
  10. 청구항 6에 있어서,
    상기 대기시간을 예측하는 단계는, 상기 메시지 큐의 처리량으로부터 단위 시간당 작업 메시지 1개의 처리시간을 획득하고, 상기 처리기의 가용 자원에 따라 상기 처리시간을 보정함으로써 상기 대기시간을 예측하는, 큐 관리 방법.
KR1020180126413A 2018-10-23 2018-10-23 큐 관리 장치 및 방법 KR20200045639A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020180126413A KR20200045639A (ko) 2018-10-23 2018-10-23 큐 관리 장치 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020180126413A KR20200045639A (ko) 2018-10-23 2018-10-23 큐 관리 장치 및 방법

Publications (1)

Publication Number Publication Date
KR20200045639A true KR20200045639A (ko) 2020-05-06

Family

ID=70737330

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180126413A KR20200045639A (ko) 2018-10-23 2018-10-23 큐 관리 장치 및 방법

Country Status (1)

Country Link
KR (1) KR20200045639A (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113778321A (zh) * 2021-01-15 2021-12-10 北京沃东天骏信息技术有限公司 消息处理的方法和装置
CN114971163A (zh) * 2022-04-13 2022-08-30 中移互联网有限公司 重新发起业务请求的执行方法及执行装置
CN116661969A (zh) * 2023-06-07 2023-08-29 上海汉朔信息科技有限公司 一种基于消息队列的业务处理方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140021433A (ko) 2012-08-10 2014-02-20 삼성테크윈 주식회사 프로세서간 메시지처리장치 및 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140021433A (ko) 2012-08-10 2014-02-20 삼성테크윈 주식회사 프로세서간 메시지처리장치 및 방법

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113778321A (zh) * 2021-01-15 2021-12-10 北京沃东天骏信息技术有限公司 消息处理的方法和装置
CN114971163A (zh) * 2022-04-13 2022-08-30 中移互联网有限公司 重新发起业务请求的执行方法及执行装置
CN114971163B (zh) * 2022-04-13 2023-08-18 中移互联网有限公司 重新发起业务请求的执行方法及执行装置
CN116661969A (zh) * 2023-06-07 2023-08-29 上海汉朔信息科技有限公司 一种基于消息队列的业务处理方法及系统
CN116661969B (zh) * 2023-06-07 2024-03-12 上海汉朔信息科技有限公司 一种基于消息队列的业务处理方法及系统

Similar Documents

Publication Publication Date Title
US11762703B2 (en) Multi-region request-driven code execution system
US10372499B1 (en) Efficient region selection system for executing request-driven code
CN110383764B (zh) 无服务器系统中使用历史数据处理事件的系统和方法
US10257316B2 (en) Monitoring of node.js applications
CN105159782A (zh) 基于云主机为订单分配资源的方法和装置
KR20200045639A (ko) 큐 관리 장치 및 방법
US11228658B1 (en) Pre-caching data for use upon execution of program code
US9104486B2 (en) Apparatuses, systems, and methods for distributed workload serialization
KR20170139872A (ko) 멀티 테넌트 기반의 서비스 제공 시스템 및 방법
KR101426575B1 (ko) 분산형 프로세싱 시스템 및 방법
US9609068B2 (en) Session management system, session management apparatus, and non-transitory computer readable medium
CN111200606A (zh) 深度学习模型任务处理方法、系统、服务器及存储介质
CN111107075A (zh) 请求响应方法、装置、电子设备和计算机可读存储介质
US20210132993A1 (en) Rate limiting compliance assessments with multi-layer fair share scheduling
CN113298387B (zh) 货物装卸分配方法、分配系统、电子设备及可读存储介质
US10783007B2 (en) Load distribution for integration scenarios
CN110838987A (zh) 队列限流方法、存储介质
CN116561013B (zh) 基于目标服务框架的测试方法、装置、电子设备和介质
US9152549B1 (en) Dynamically allocating memory for processes
US10979359B1 (en) Polling resource management system
CN107689979B (zh) 一种下载请求处理方法和处理设备
JP6823257B2 (ja) ジョブ監視プログラム、ジョブ監視装置及びジョブ監視方法
US9491221B1 (en) System and method for brokering distributed computation
KR20200046316A (ko) 웹 어플리케이션 서버, 사용자 요청 처리 방법 및 통합 요청 처리 방법
US20130232269A1 (en) Direct return to source (drs) routing of customer information control systems (cics) transactions