KR20170062235A - 서비스 처리 시스템 및 방법 - Google Patents

서비스 처리 시스템 및 방법 Download PDF

Info

Publication number
KR20170062235A
KR20170062235A KR1020150167794A KR20150167794A KR20170062235A KR 20170062235 A KR20170062235 A KR 20170062235A KR 1020150167794 A KR1020150167794 A KR 1020150167794A KR 20150167794 A KR20150167794 A KR 20150167794A KR 20170062235 A KR20170062235 A KR 20170062235A
Authority
KR
South Korea
Prior art keywords
message
service module
service
scaling
auto
Prior art date
Application number
KR1020150167794A
Other languages
English (en)
Other versions
KR102387930B1 (ko
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 KR1020150167794A priority Critical patent/KR102387930B1/ko
Publication of KR20170062235A publication Critical patent/KR20170062235A/ko
Application granted granted Critical
Publication of KR102387930B1 publication Critical patent/KR102387930B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Debugging And Monitoring (AREA)

Abstract

서비스 처리 시스템 및 방법이 제공된다. 본 발명의 일 실시예에 따른 서비스 처리 시스템은, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하고, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 메시지 모니터링부; 및 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하고, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 서비스 모듈 실행부를 포함한다.

Description

서비스 처리 시스템 및 방법{SYSTEM AND METHOD FOR PROCESSING SERVICE}
본 발명의 실시예들은 플랫폼 상에서 서비스를 효율적으로 처리하는 기술과 관련된다.
종래에는 워크플로우 모델(Workflow Model)의 작성시 서비스 모듈 간의 실행 방식(순차적 실행 또는 병렬적 실행) 및 실행 순서를 결정하고, 작성된 워크플로우 모델을 기반으로 서비스 모듈을 실행하는 것이 일반적이었다. 그러나, 종래 기술에 따르면 특정 서비스 모듈의 메시지 처리 속도가 느리거나 메시지 처리량이 많은 경우(즉, 특정 서비스 모듈의 메시지 처리 성능이 저하되는 경우) 해당 서비스 모듈에서 병목 현상이 발생되는 문제점이 있었다.
일 예시로서, 서비스 모듈 M1 내지 M5가 M1 → M2 → M3 → M4 → M5 순으로 실행되도록 워크플로우 모델이 작성된 경우, 서비스 모듈 M1의 메시지 처리 성능의 저하로 서비스 모듈 M1에서 처리하여야 할 메시지가 계속적으로 적체되면 서비스 모듈 M2, M3, M4, M5는 서비스 모듈 M1에서의 메시지 처리가 완료될 때까지 대기 상태를 유지할 수 밖에 없다. 이러한 병목 현상은 플랫폼 전체의 성능을 저하시키며, 이에 따라 사용자에게 원활한 서비스를 제공하는 데 어려움이 있을 수 있다.
또한, 복수의 서비스 모듈(예를 들어, 서비스 모듈 M1 내지 M5)이 하나의 리소스(resource)에 접근하여야 하는 경우, 상기 복수의 서비스 모듈이 병렬적으로 실행되도록 워크플로우 모델을 작성할 수 없으며 상기 복수의 서비스 모듈이 순차적으로 실행되도록 워크플로우 모델을 작성하여야 한다. 이는 플랫폼 전체의 성능에 악영향을 미치게 되며, 서비스 모듈의 순차적 실행에 따라 앞서 설명한 병목 현상이 발생될 우려가 있다.
한국등록특허공보 제10-1345068호(2013.12.28)
본 발명의 실시예들은 서로 다른 서비스를 처리하는 복수의 서비스 모듈 간의 실행 순서를 동적으로 결정하는 수단을 제공하기 위한 것이다.
본 발명의 예시적인 실시예에 따르면, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하고, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 메시지 모니터링부; 및 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하고, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 서비스 모듈 실행부를 포함하는, 서비스 처리 시스템이 제공된다.
상기 메시지 모니터링부는, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈 각각에서의 메시지 트래픽을 계산하고, 상기 메시지 트래픽에 따라 상기 서비스 모듈별 메시지 처리 성능을 판단할 수 있다.
상기 서비스 모듈 실행부는, 상기 복수의 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 가장 먼저 실행하도록 상기 실행 순서를 결정할 수 있다.
상기 서비스 모듈 실행부는, 상기 메시지 트래픽이 가장 적은 서비스 모듈의 실행이 완료된 이후 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 새롭게 수신하고, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 다음으로 실행할 서비스 모듈을 결정할 수 있다.
상기 서비스 모듈 실행부는, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 상기 복수의 서비스 모듈에서 상기 실행이 완료된 서비스 모듈을 제외한 나머지 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 상기 다음으로 실행할 서비스 모듈로 결정할 수 있다.
상기 서비스 처리 시스템은, 상기 메시지 모니터링부로부터 오토-스케일링 요청 메시지를 수신하고, 상기 오토-스케일링 요청 메시지에 따라 상기 복수의 서비스 모듈 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링(auto-scaling)하는 오토 스케일링부를 더 포함할 수 있다.
상기 메시지 모니터링부는, 상기 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산하며, 상기 스케일링 기준 정보와 설정된 기준치와의 비교 결과에 따라 상기 오토-스케일링 요청 메시지를 생성할 수 있다.
상기 스케일링 기준 정보는, 상기 복수의 서비스 모듈을 구비하는 플랫폼 전체의 초당 트랜잭션 처리 수(TPS(S)) 및 상기 플랫폼 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함할 수 있다.
상기 메시지 모니터링부는, 상기 서비스 모듈 각각에 대한 초당 트랜잭션 처리 수(TPS(Mi)) 및 상기 서비스 모듈 각각에 대한 평균 메시지 처리 시간(T(Mi)) 중 하나 이상을 계산하며, 상기 비교 결과와 상기 TPS(Mi) 또는 상기 T(Mi)를 고려하여 상기 오토-스케일링 요청 메시지를 생성할 수 있다.
상기 오토-스케일링 요청 메시지는, 상기 TPS(S)가 제1 기준치보다 설정된 값 이상 낮은 경우 상기 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃(scale-out)하도록 요청하는 메시지이며, 상기 TPS(S)가 상기 제1 기준치보다 설정된 값 이상 높은 경우 상기 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인(scale-in)하도록 요청하는 메시지일 수 있다.
상기 오토-스케일링 요청 메시지는, 상기 T(S)가 제2 기준치보다 설정된 값 이상 높은 경우 상기 T(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃하도록 요청하는 메시지이며, 상기 T(S)가 제2 기준치보다 설정된 값 이상 낮은 경우 상기 T(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인하도록 요청하는 메시지일 수 있다.
본 발명의 다른 예시적인 실시예에 따르면, 메시지 모니터링부에서, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하는 단계; 상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계; 서비스 모듈 실행부에서, 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하는 단계; 및 상기 서비스 모듈 실행부에서, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 단계를 포함하는, 서비스 처리 방법이 제공된다.
상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계는, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈 각각에서의 메시지 트래픽을 계산하고, 상기 메시지 트래픽에 따라 상기 서비스 모듈별 메시지 처리 성능을 판단할 수 있다.
상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 상기 복수의 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 가장 먼저 실행하도록 상기 실행 순서를 결정할 수 있다.
상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 상기 메시지 트래픽이 가장 적은 서비스 모듈의 실행이 완료된 이후 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 새롭게 수신하고, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 다음으로 실행할 서비스 모듈을 결정할 수 있다.
상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 상기 복수의 서비스 모듈에서 상기 실행이 완료된 서비스 모듈을 제외한 나머지 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 상기 다음으로 실행할 서비스 모듈로 결정할 수 있다.
상기 서비스 처리 방법은, 오토 스케일링부에서, 상기 메시지 모니터링부로부터 오토-스케일링 요청 메시지를 수신하는 단계; 및 상기 오토 스케일링부에서, 상기 오토-스케일링 요청 메시지에 따라 상기 복수의 서비스 모듈 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링(auto-scaling)하는 단계를 더 포함할 수 있다.
상기 서비스 처리 방법은, 상기 오토-스케일링 요청 메시지를 수신하는 단계 이전에, 상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산하며, 상기 스케일링 기준 정보와 설정된 기준치와의 비교 결과에 따라 상기 오토-스케일링 요청 메시지를 생성하는 단계를 더 포함할 수 있다.
상기 스케일링 기준 정보는, 상기 복수의 서비스 모듈을 구비하는 플랫폼 전체의 초당 트랜잭션 처리 수(TPS(S)) 및 상기 플랫폼 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함할 수 있다.
상기 오토-스케일링 요청 메시지를 생성하는 단계는, 상기 서비스 모듈 각각에 대한 초당 트랜잭션 처리 수(TPS(Mi)) 및 상기 서비스 모듈 각각에 대한 평균 메시지 처리 시간(T(Mi)) 중 하나 이상을 계산하며, 상기 비교 결과와 상기 TPS(Mi) 또는 상기 T(Mi)를 고려하여 상기 오토-스케일링 요청 메시지를 생성할 수 있다.
상기 오토-스케일링 요청 메시지는, 상기 TPS(S)가 제1 기준치보다 설정된 값 이상 낮은 경우 상기 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃(scale-out)하도록 요청하는 메시지이며, 상기 TPS(S)가 상기 제1 기준치보다 설정된 값 이상 높은 경우 상기 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인(scale-in)하도록 요청하는 메시지일 수 있다.
상기 오토-스케일링 요청 메시지는, 상기 T(S)가 제2 기준치보다 설정된 값 이상 높은 경우 상기 T(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃하도록 요청하는 메시지이며, 상기 T(S)가 제2 기준치보다 설정된 값 이상 낮은 경우 상기 T(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인하도록 요청하는 메시지일 수 있다.
본 발명의 다른 예시적인 실시예에 따르면, 하드웨어와 결합되어 메시지 모니터링부에서, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하는 단계; 상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계; 서비스 모듈 실행부에서, 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하는 단계; 및 상기 서비스 모듈 실행부에서, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 단계를 실행시키기 위하여 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램이 제공된다.
본 발명의 실시예들에 따르면, 서비스 모듈별 실시간 메시지 처리 성능에 따라 서비스 모듈의 실행 순서를 동적으로 결정함으로써, 특정 서비스 모듈에서의 병목 현상을 방지하고 서비스 모듈 각각에서 제공되는 서비스를 원활하게 처리할 수 있다. 특히, 본 발명의 실시예들은 각 서비스 모듈이 서로 독립적으로 작동하는 마이크로 서비스 아키텍쳐 및 워크플로우 모델 내 서비스 모듈 간의 실행 방식(순차적 실행 또는 병렬적 실행)에 제약이 없는 경우 상술한 종래 기술의 문제점을 해결하는 수단으로서 활용될 수 있다.
또한, 본 발명의 실시예들에 따르면, 서비스 모듈별 메시지 처리량 또는 메시지 처리 시간(또는 메시지 처리 속도)을 고려하여 플랫폼의 컴퓨팅 자원을 오토 스케일링함으로써, 메시지를 빠르고 안정적으로 처리할 수 있다.
도 1은 본 발명의 일 실시예에 따른 서비스 처리 시스템의 상세 구성을 나타낸 블록도
도 2는 본 발명의 일 실시예에 따른 서비스 모듈 실행부에서 서비스 모듈의 실행 순서를 결정하는 과정을 나타낸 예시도
도 3은 본 발명의 일 실시예에 따른 워크플로우 모델 및 서비스 모듈의 실행 흐름을 설명하기 위한 예시도
도 4는 본 발명의 일 실시예에 따른 메시지 모니터링부에서 오토-스케일링 수행 여부를 결정하는 과정을 나타낸 예시도
도 5는 본 발명의 일 실시예에 따른 메시지 모니터링부에서 오토-스케일링 수행 여부를 결정하는 과정을 나타낸 예시도
도 6은 본 발명의 일 실시예에 따른 메시지 모니터링부에서 오토-스케일링 수행 여부를 결정하는 과정을 나타낸 예시도
도 7은 본 발명의 일 실시예에 따른 서비스 처리 방법을 설명하기 위한 도면
도 8은 도 7의 S704 단계를 구체적으로 설명하기 위한 흐름도
도 9는 도 7의 S714 단계를 구체적으로 설명하기 위한 흐름도
이하, 도면을 참조하여 본 발명의 구체적인 실시형태를 설명하기로 한다. 이하의 상세한 설명은 본 명세서에서 기술된 방법, 장치 및/또는 시스템에 대한 포괄적인 이해를 돕기 위해 제공된다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.
본 발명의 실시예들을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 상세한 설명에서 사용되는 용어는 단지 본 발명의 실시예들을 기술하기 위한 것이며, 결코 제한적이어서는 안 된다. 명확하게 달리 사용되지 않는 한, 단수 형태의 표현은 복수 형태의 의미를 포함한다. 본 설명에서, "포함" 또는 "구비"와 같은 표현은 어떤 특성들, 숫자들, 단계들, 동작들, 요소들, 이들의 일부 또는 조합을 가리키기 위한 것이며, 기술된 것 이외에 하나 또는 그 이상의 다른 특성, 숫자, 단계, 동작, 요소, 이들의 일부 또는 조합의 존재 또는 가능성을 배제하도록 해석되어서는 안 된다.
도 1은 본 발명의 일 실시예에 따른 서비스 처리 시스템(100)의 상세 구성을 나타낸 블록도이다. 도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 서비스 처리 시스템(100)은 플랫폼(110) 상에서 서비스를 효율적으로 처리하기 위한 것으로, 메시지 모니터링부(102), 서비스 모듈 실행부(104) 및 오토 스케일링부(106)를 포함한다.
여기서, 플랫폼(110)은 사용자에게 서비스를 제공하기 위한 여러 기술적 모듈들의 집합체로서, 본 실시예들에 있어서 상기 플랫폼(110)은 예를 들어, 사물인터넷(IoT : Internet of Things) 서비스를 개발하고 실생활에 적용될 수 있도록 지원하는 IoT 플랫폼일 수 있다. 상기 플랫폼(110)은 복수의 서비스 모듈(120 ; Mi)을 구비할 수 있으며, 상기 서비스 모듈(120 ; Mi) 각각은 서로 다른 서비스를 처리할 수 있으며 서로간의 의존도(dependency)가 없거나 적어 상호 독립적으로 작동할 수 있다. 도 1에 도시된 바와 같이, 상기 서비스 모듈(120 ; Mi)은 하나 이상의 서버(또는 가상 머신, Si1, Si2, Si3…)에 의해 실행될 수 있다. 예를 들어, 서비스 모듈 M1은 서버 S11, S12 및 S13에 의해 실행될 수 있으며, 서비스 모듈 M2는 서버 S21, S22 및 S23에 의해 실행될 수 있다. 도 1에서는 설명의 편의상 플랫폼(110)이 5개의 서비스 모듈(M1, M2, M3, M4, M5)을 구비하고 각 서비스 모듈(M1, M2, M3, M4, M5)이 3개의 서버(Si1, Si2, Si3)에 의해 실행되는 것으로 도시하였으나, 이는 일 실시예에 불과하며 플랫폼(110) 내 서비스 모듈(120 ; Mi)의 개수 및 상기 서비스 모듈(120 ; Mi)을 실행하는 서버의 개수가 이에 한정되는 것은 아니다. 이하에서는, 서비스 처리 시스템(100)의 상세 구성에 대해 자세히 살펴보기로 한다.
메시지 모니터링부(102)는 서비스 모듈(120 ; M1, M2, M3, M4, M5) 각각으로부터 서비스 모듈(120)에서의 메시지 입출력 정보를 수신하고, 상기 메시지 입출력 정보를 이용하여 서비스 모듈(120)별 메시지 처리 성능을 판단한다. 여기서, 메시지 입출력 정보는 서비스 모듈(120)에 입력되는 메시지와 상기 서비스 모듈(120)로부터 출력되는 메시지의 식별정보(예를 들어, 메시지의 ID), 상기 메시지가 서비스 모듈(120)에 입력된 시간 및 상기 메시지가 서비스 모듈(120)로부터 출력된 시간에 관한 정보 중 하나 이상을 포함할 수 있다. 각 서비스 모듈(120)(또는 각 서비스 모듈(120) 내 서버)은 해당 서비스 모듈(120)(또는 해당 서비스 모듈(120) 내 서버)에서의 메시지의 입출력을 감지하여 메시지 입출력 정보를 생성하며, 상기 메시지 입출력 정보를 메시지 모니터링부(102)로 송신할 수 있다. 예를 들어, 서비스 모듈 M1은 서비스 모듈 M1에서의 메시지 입출력 정보를 생성하여 메시지 모니터링부(102)로 송신할 수 있으며, 서비스 모듈 M2는 서비스 모듈 M2에서의 메시지 입출력 정보를 생성하여 메시지 모니터링부(102)로 송신할 수 있다. 각 서비스 모듈(120)은 메시지의 입출력이 발생될 때마다 메시지 입출력 정보를 생성하여 메시지 모니터링부(102)로 송신할 수 있으나, 이에 한정되는 것은 아니며 설정된 주기(예를 들어, 1분)마다 메시지 입출력 정보를 생성하여 메시지 모니터링부(102)로 송신할 수도 있다.
메시지 모니터링부(102)는 서비스 모듈(120) 각각으로부터 수신한 메시지 입출력 정보를 이용하여 서비스 모듈(120)별 메시지 처리 성능을 실시간으로 판단할 수 있다. 상기 메시지 처리 성능은 해당 서비스 모듈(120)에서의 메시지 처리 속도, 해당 서비스 모듈(120)에서 현재 처리하고 있는 메시지의 량 등에 따라 달라질 수 있다.
메시지 모니터링부(102)는 상기 서비스 모듈(120)별 메시지 처리 성능을 판단하기 위해 메시지 입출력 정보를 이용하여 서비스 모듈(120) 각각에서의 메시지 트래픽을 계산할 수 있다. 상술한 바와 같이, 메시지 입출력 정보는 서비스 모듈(120)에 입력되는 메시지와 상기 서비스 모듈(120)로부터 출력되는 메시지의 식별정보, 메시지가 서비스 모듈(120)에 입력된 시간 및 상기 메시지가 서비스 모듈(120)로부터 출력된 시간에 관한 정보 등을 포함할 수 있으며, 메시지 모니터링부(102)는 상기 메시지 입출력 정보를 이용하여 서비스 모듈(120) 각각에서 처리되는 데이터의 량, 즉 서비스 모듈(120) 각각에서의 메시지 트래픽을 계산할 수 있다.
메시지 모니터링부(102)는 상기 메시지 트래픽에 따라 서비스 모듈(120)별 메시지 처리 성능을 판단할 수 있다. 예를 들어, 메시지 모니터링부(102)는 서비스 모듈(120)에서의 메시지 트래픽이 적을수록(즉, 서비스 모듈(120)에서 처리하여야 할 메시지가 적을수록) 현재 해당 서비스 모듈(120)의 메시지 처리 성능이 우수한 것으로 판단하고, 서비스 모듈(120)에서의 메시지 트래픽이 많을수록(즉, 서비스 모듈(120)에서 처리하여야 할 메시지가 많을수록) 현재 해당 서비스 모듈(120)의 메시지 처리 성능이 저조한 것으로 판단할 수 있다. 메시지 모니터링부(102)는 상기 메시지 처리 성능에 관한 정보를 서비스 모듈 실행부(104)로 송신할 수 있다.
서비스 모듈 실행부(104)는 메시지 모니터링(102)부로부터 서비스 모듈(120)별 메시지 처리 성능에 관한 정보를 수신하고, 서비스 모듈(120)별 메시지 처리 성능에 따라 복수의 서비스 모듈(120) 각각의 실행 순서를 동적으로 결정한다. 상기 메시지 처리 성능에 관한 정보는 예를 들어, 서비스 모듈(120) 각각에서의 메시지 트래픽에 관한 정보일 수 있으며, 서비스 모듈 실행부(104)는 상기 메시지 트래픽에 관한 정보를 이용하여 서비스 모듈(120) 각각의 실행 순서를 동적으로 결정할 수 있다. 본 실시예들에 있어서, 워크플로우 모델의 작성시에는 플랫폼(110) 내 서비스 모듈(120)들의 세트(set)만 표시될 수 있으며 서비스 모듈(120)들의 실행 순서에 특별한 제약이 없는 것으로 가정한다. 또한, 서비스 모듈 실행부(104)는 워크플로우 모델의 실행을 위한 메시지(Msg)가 입력되는 경우 작동하는 것으로 가정한다.
일 예시로서, 서비스 모듈 실행부(104)는 복수의 서비스 모듈(120) 중 상기 메시지 트래픽이 가장 적은 서비스 모듈(120)을 가장 먼저 실행하도록 실행 순서를 결정할 수 있다. 예를 들어, 서비스 모듈 M1 내지 M5에서 처리하여야 할 메시지가 각각 500개, 300개, 100개, 200개, 200개인 경우, 서비스 모듈 실행부(104)는 메시지 트래픽이 가장 적은 서비스 모듈 M3를 가장 먼저 실행하도록 상기 실행 순서를 결정할 수 있다.
또한, 서비스 모듈 실행부(104)는 상기 메시지 트래픽이 가장 적은 서비스 모듈(120)의 실행이 완료된 이후 메시지 모니터링부(102)로부터 상기 서비스 모듈(120)별 메시지 처리 성능에 관한 정보를 새롭게 수신하고, 새롭게 수신된 서비스 모듈(120)별 메시지 처리 성능에 관한 정보를 이용하여 다음으로 실행할 서비스 모듈(120)을 결정할 수 있다. 구체적으로, 서비스 모듈 실행부(104)는 새롭게 수신된 서비스 모듈(120)별 메시지 처리 성능에 관한 정보를 이용하여 상기 복수의 서비스 모듈(120)에서 상기 실행이 완료된 서비스 모듈(120)을 제외한 나머지 서비스 모듈(120) 중 상기 메시지 트래픽이 가장 적은 서비스 모듈(120)을 다음으로 실행할 서비스 모듈(120)로 결정할 수 있다.
위 예시에서, 서비스 모듈 실행부(104)는 서비스 모듈 M3의 실행이 완료된 이후 서비스 모듈 M1 내지 M5 중 서비스 모듈 M3를 제외한 나머지 서비스 모듈의 메시지 처리 성능에 관한 정보(즉, 서비스 모듈 M1, M2, M4, M5에서의 메시지 트래픽에 관한 정보)를 메시지 모니터링부(102)로부터 새롭게 수신할 수 있으며, 서비스 모듈 M1, M2, M4, M5에서 처리하여야 할 메시지가 각각 300개, 200개, 100개, 200개인 경우 서비스 모듈 M4를 다음으로 실행할 서비스 모듈로 결정할 수 있다. 서비스 모듈 실행부(104)는 이와 같은 과정을 반복하여 하나의 서비스 모듈(120)의 실행이 완료될 때마다 다음으로 실행할 서비스 모듈(120)을 동적으로 결정할 수 있다.
즉, 본 발명의 실시예들에 따르면, 서비스 모듈(120)별 실시간 메시지 처리 성능에 따라 서비스 모듈(120)의 실행 순서를 동적으로 결정함으로써, 특정 서비스 모듈(120)에서의 병목 현상을 방지하고 서비스 모듈(120) 각각에서 제공되는 서비스를 원활하게 처리할 수 있다. 특히, 본 발명의 실시예들은 각 서비스 모듈(120)이 서로 독립적으로 작동하는 마이크로 서비스 아키텍쳐 및 워크플로우 모델 내 서비스 모듈(120) 간의 실행 방식(순차적 실행 또는 병렬적 실행)에 제약이 없는 경우 상술한 종래 기술의 문제점을 해결하는 수단으로서 활용될 수 있다.
또한, 메시지 모니터링부(102)는 상기 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산하며, 상기 스케일링 기준 정보와 설정된 기준치와의 비교 결과에 따라 오토-스케일링 요청 메시지를 생성할 수 있다. 오토-스케일링이란 플랫폼(110)의 컴퓨팅 자원을 늘리거나 줄이는 것으로, 서비스 모듈(120)을 실행하는 서버의 개수를 조절함으로써 상기 플랫폼(110)의 컴퓨팅 자원을 늘리거나 줄일 수 있다. 예를 들어, 스케일-아웃(scale-out)은 서비스 모듈(120)을 실행하는 서버의 개수를 늘림으로써 실현될 수 있으며, 스케일-인(scale-in)은 서비스 모듈(120)을 실행하는 서버의 개수를 줄임으로써 실현될 수 있다. 즉, 본 발명의 실시예들에서는, 상술한 방법으로 서비스 모듈(120)의 실행 순서를 동적으로 결정한 경우에도 데이터베이스의 조회 속도가 느리거나 디스크 I/O 또는 네트워크 I/O의 영향에 따라 메시지 처리 시간이 저하될 수 있으므로, 스케일링 기준 정보를 이용하여 플랫폼(110)의 컴퓨팅 자원을 효율적으로 오토 스케일링할 수 있도록 하였다.
여기서, 스케일링 기준 정보는 오토-스케일링의 수행 여부을 결정하는 데 기준이 되는 정보로서, 플랫폼(110) 전체의 초당 트랜잭션 처리수(TPS(S), TPS : Transaction Per Second) 및 플랫폼(110) 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함할 수 있다. 메시지 모니터링부(102)는 스케일링 기준 정보와 설정된 기준치를 비교하고, 상기 비교 결과에 따라 오토-스케일링 요청 메시지를 생성할 수 있다. 이하에서는, (1) 스케일링 기준 정보가 TPS(S)인 경우, (2) 스케일링 기준 정보가 T(S) 경우 메시지 모니터링부(102)에서 오토-스케일링 요청 메시지를 생성하는 과정을 각각 설명하기로 한다.
(1) 스케일링 기준 정보가 TPS(S)인 경우
메시지 모니터링부(102)는 서비스 모듈(120) 각각으로부터 수신한 메시지 입출력 정보를 이용하여 각 서비스 모듈(120)별 초당 트랜잭션 처리 수(TPS(Mi)) 및 플랫폼(110) 전체의 초당 트랜잭션 처리수(TPS(S))를 각각 계산하고, 상기 TPS(S)와 설정된 제1 기준치를 비교할 수 있다. 여기서, 제1 기준치는 예를 들어, 목표 TPS(Target TPS)일 수 있다. 상술한 바와 같이, 메시지 입출력 정보는 메시지가 서비스 모듈(120)에 입력된 시간 및 메시지가 서비스 모듈(120)로부터 출력된 시간에 관한 정보를 포함하므로, 메시지 모니터링부(102)는 상기 메시지 입출력 정보를 이용하여 각 서비스 모듈(120) 내에서 메시지가 처리되는 시간 및 각 서비스 모듈(120) 내에서의 메시지 처리량(throughput)을 획득할 수 있으며, 이로부터 TPS(Mi) 및 TPS(S)를 계산할 수 있다. 메시지 모니터링부(102)는 TPS(S)와 설정된 제1 기준치를 비교하여 오토-스케일링의 수행 여부을 결정할 수 있다. 예를 들어, TPS(S)가 제1 기준치보다 설정된 값 이상 낮거나 높은 경우, 메시지 모니터링부(102)는 오토-스케일링이 필요한 것으로 판단할 수 있다.
구체적으로, 메시지 모니터링부(102)는 TPS(S)가 제1 기준치보다 설정된 값 이상 낮은 경우 메시지 상기 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃을 수행하도록 결정할 수 있다. 예를 들어, TPS(S)가 1000(T/s) 이고 제1 기준치가 1200(T/s)인 경우(상기 설정된 값은 0으로 가정) TPS(S)＜제1 기준치이므로, 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 또한, 메시지 모니터링부(102)는 TPS(Mi)가 가장 낮은 서비스 모듈(예를 들어, M4)의 컴퓨팅 자원부터 스케일-아웃하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 생성하여 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나(즉, 스케일-아웃이 필요하다고 판단된 서비스 모듈)에 대한 컴퓨팅 자원을 오토-스케일링할 수 있다. 오토-스케일링 요청 메시지는 오토-스케일링 대상이 되는 서비스 모듈에 관한 정보(예를 들어, 상기 서비스 모듈의 식별 정보, 상기 서비스 모듈을 실행 중인 서버의 식별 정보 등), 상기 오토-스케일링의 종류(즉, 스케일-아웃인지 또는 스케일-인인지)에 관한 정보 등을 포함할 수 있다.
또한, 상기 오토-스케일링 요청 메시지에 따라 오토 스케일링부(106)에서 스케일-아웃이 수행된 이후, 메시지 모니터링부(102)는 설정된 시간(예를 들어, 1분) 동안 대기하고 서비스 모듈(120) 각각으로부터 새롭게 수신된 메시지 입출력 정보를 이용하여 TPS(Mi) 및 TPS(S)를 재계산할 수 있다. 만약, 상기 스케일-아웃의 수행 이후에도 TPS(Mi)(위 예시에서, TPS(M4))가 변동이 없는 경우, 메시지 모니터링부(102)는 TPS(Mi)가 두 번째로 낮은 서비스 모듈(예를 들어, M3)의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 이와 같이, 메시지 모니터링부(102)는 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 순차적으로 스케일-아웃하도록 결정할 수 있다. 이러한 스케일-아웃 과정은 아래의 조건 중 하나가 만족할 때까지 계속될 수 있다.
1) TPS(S)가 제1 기준치보다 높아지는 경우
→ 플랫폼(110)의 컴퓨팅 자원이 충분하다고 판단되므로, 메시지 모니터링부(102)는 스케일-아웃을 중지하도록 결정할 수 있다.
2) 플랫폼(110)에 입력되는 메시지의 수가 현저히 적은 경우
→ 예를 들어, 제1 기준치가 1200(T/s)일때 플랫폼(110)에 입력되는 메시지가 500개에 불과한 경우 입력되는 메시지의 수가 적어서 TPS(S)가 낮아진 것일 뿐 메시지 처리 속도가 느린 것은 아니므로, 메시지 모니터링부(102)는 스케일-아웃을 중지하도록 결정할 수 있다.
3) TPS(Mi)가 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃을 수행했지만 더 이상 TPS(S)를 개선할 수 없는 경우
→ 예를 들어, 플랫폼(110) 내 네트워크 환경, 서버 환경 등으로 인해 TPS(S)가 더 이상 개선되지 않을 때 더 이상의 오토-스케일링 과정은 무의미하므로, 메시지 모니터링부(102)는 스케일-아웃을 중지하도록 결정할 수 있다.
또한, 메시지 모니터링부(102)는 TPS(S)가 제1 기준치보다 설정된 값 이상 높은 경우 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인을 수행하도록 결정할 수 있다. 예를 들어, TPS(S)가 1300(T/s)이고 제1 기준치가 1200(T/s)인 경우(상기 설정된 값은 0으로 가정) TPS(S)＞제1 기준치이므로, 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-인하도록 결정할 수 있다. 또한, 메시지 모니터링부(102)는 TPS(Mi)가 가장 높은 서비스 모듈(예를 들어, M2)의 컴퓨팅 자원부터 스케일-인하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나(즉, 스케일-인이 필요한 것으로 판단된 서비스 모듈)에 대한 컴퓨팅 자원을 오토-스케일링할 수 있다.
또한, 상기 오토-스케일링 요청 메시지에 따라 오토 스케일링부(106)에서 스케일-인이 수행된 이후, 메시지 모니터링부(102)는 설정된 시간(예를 들어, 1분) 동안 대기하고 서비스 모듈(120) 각각으로부터 새롭게 수신된 메시지 입출력 정보를 이용하여 TPS(Mi) 및 TPS(S)를 재계산할 수 있다. 만약, 상기 스케일-인의 수행 이후에도 TPS(Mi)(위 예시에서, TPS(M2))가 변동이 없는 경우, 메시지 모니터링부(102)는 동일한 서비스 모듈(예를 들어, M2)의 컴퓨팅 자원에 대해 다시 한 번 스케일-인하거나 TPS(Mi)가 두 번째로 높은 서비스 모듈(예를 들어, M1)의 컴퓨팅 자원을 스케일-인하도록 결정할 수 있다. 이와 같이, 메시지 모니터링부(102)는 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 순차적으로 스케일-인하도록 결정할 수 있다. 만약, 스케일-인의 수행 이후 TPS(Mi)(위 예시에서, TPS(M2))의 변동이 발생하는 경우, 메시지 모니터링부(102)는 스케일-인을 중지하도록 결정할 수 있으며, TPS(Mi) 및 TPS(S)를 재계산할 수 있다.
(2) 스케일링 기준 정보가 T(S)인 경우
메시지 모니터링부(102)는 서비스 모듈(120) 각각으로부터 수신한 메시지 입출력 정보를 이용하여 각 서비스 모듈(120)별 평균 메시지 처리 시간(T(Mi)) 및 플랫폼(110) 전체의 평균 메시지 처리 시간(T(S))를 각각 계산하고, 상기 T(S)와 설정된 제2 기준치를 비교할 수 있다. 여기서, 제2 기준치는 예를 들어, 메시지당 총 처리 시간(Target process time)일 수 있다. 상술한 바와 같이, 메시지 입출력 정보는 메시지가 서비스 모듈(120)에 입력된 시간 및 메시지가 서비스 모듈(120)로부터 출력된 시간에 관한 정보를 포함하므로, 메시지 모니터링부(102)는 상기 메시지 입출력 정보를 이용하여 서비스 모듈(120) 내에서 메시지가 처리되는 시간 및 각 서비스 모듈(120) 내에서의 메시지 처리량(throughput)을 획득할 수 있으며, 이로부터 T(Mi) 및 T(S)를 계산할 수 있다. 메시지 모니터링부(102)는 T(S)와 설정된 제2 기준치를 비교하여 오토-스케일링의 수행 여부을 결정할 수 있다. 예를 들어, T(S)가 제2 기준치보다 설정된 값 이상 낮거나 높은 경우, 메시지 모니터링부(102)는 오토-스케일링이 필요한 것으로 결정할 수 있다.
구체적으로, 메시지 모니터링부(102)는 T(S)가 제2 기준치보다 설정된 값 이상 높은(즉, 느린) 경우 상기 T(Mi)가 가장 높은(즉, 느린) 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃을 수행하도록 결정할 수 있다. 예를 들어, T(S)가 2(sec)이고 제2 기준치가 1.5(sec)인 경우(상기 설정된 값은 0으로 가정) T(S)＞제2 기준치이므로, 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 또한, 메시지 모니터링부(102)는 T(Mi)가 가장 높은 서비스 모듈(예를 들어, M5)의 컴퓨팅 자원부터 스케일-아웃하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나(즉, 스케일-아웃이 필요한 것으로 판단된 서비스 모듈)에 대한 컴퓨팅 자원을 오토-스케일링할 수 있다.
또한, 상기 오토-스케일링 요청 메시지에 따라 오토 스케일링부(106)에서 스케일-아웃이 수행된 이후, 메시지 모니터링부(102)는 설정된 시간(예를 들어, 1분) 동안 대기하고 서비스 모듈(120) 각각으로부터 새롭게 수신된 메시지 입출력 정보를 이용하여 T(Mi) 및 T(S)를 재계산할 수 있다. 만약, 스케일-아웃의 수행 이후에도 T(Mi)가 변동이 없는 경우, 메시지 모니터링부(102)는 T(Mi)가 두 번째로 높은 서비스 모듈의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 이와 같이, 메시지 모니터링부(102)는 T(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 순차적으로 스케일-아웃하도록 결정할 수 있다. 이러한 스케일-아웃 과정은 아래의 조건 중 하나가 만족할 때까지 계속될 수 있다.
1) T(S)가 제2 기준치보다 낮아지는 경우
→ 플랫폼(110)의 컴퓨팅 자원이 충분하다고 판단되므로, 메시지 모니터링부(102)는 스케일-아웃을 중지하도록 결정할 수 있다.
2) T(Mi)가 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃을 수행했지만 더 이상 T(S)를 개선할 수 없는 경우
→ 예를 들어, 플랫폼(110) 내 네트워크 환경, 서버 환경 등으로 인해 T(S)가 더 이상 개선되지 않을 때 더 이상의 오토-스케일링 과정은 무의미하므로, 메시지 모니터링부(102)는 스케일-아웃을 중지하도록 결정할 수 있다.
또한, 메시지 모니터링부(102)는 T(S)가 제2 기준치보다 설정된 값 이상 낮은(즉, 빠른) 경우 T(Mi)가 가장 낮은(즉, 빠른) 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인을 수행하도록 결정할 수 있다. 예를 들어, T(S)가 1(sec)이고 제2 기준치가 1.5(sec)인 경우(상기 설정된 값은 0으로 가정) T(S)＜제2 기준치이므로, 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-인하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나(즉, 스케일-인이 필요한 것으로 판단된 서비스 모듈)에 대한 컴퓨팅 자원을 오토-스케일링할 수 있다.
또한, 상기 오토-스케일링 요청 메시지에 따라 오토 스케일링부(106)에서 스케일-인이 수행된 이후, 메시지 모니터링부(102)는 설정된 시간(예를 들어, 1분) 동안 대기하고 서비스 모듈(120) 각각으로부터 새롭게 수신된 메시지 입출력 정보를 이용하여 T(Mi) 및 T(S)를 재계산할 수 있다. 만약, 스케일-인의 수행 이후에도 T(Mi)가 변동이 없는 경우, 메시지 모니터링부(102)는 동일한 서비스 모듈의 컴퓨팅 자원에 대해 다시 한 번 스케일-인하거나 T(Mi)가 두 번째로 낮은 서비스 모듈의 컴퓨팅 자원을 스케일-인하도록 결정할 수 있다. 이와 같이, 메시지 모니터링부(102)는 T(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 순차적으로 스케일-인하도록 결정할 수 있다. 만약, 스케일-인의 수행 이후 T(Mi)의 변동이 발생하는 경우, 메시지 모니터링부(102)는 스케일-인을 중지하도록 결정할 수 있으며, T(Mi) 및 T(S)를 재계산할 수 있다.
오토 스케일링부(106)는 메시지 모니터링부(102)로부터 수신한 스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링한다. 상술한 바와 같이, 스케일링 요청 메시지는 오토-스케일링 대상이 되는 서비스 모듈에 관한 정보, 상기 오토-스케일링의 종류(즉, 스케일-아웃인지 또는 스케일-인인지)에 관한 정보 등을 포함할 수 있다. 만약, 스케일링 요청 메시지에 “서비스 모듈 M4에 대한 컴퓨팅 자원의 스케일-아웃 요청” 정보가 포함된 경우, 오토 스케일링부(106)는 서비스 모듈 M4에 대한 컴퓨팅 자원을 스케일-아웃할 수 있다. 예를 들어, 오토 스케일링부(106)는 서비스 모듈 M4를 실행 중인 서버의 개수를 늘릴 수 있다. 만약, 스케일링 요청 메시지에 “서비스 모듈 M2에 대한 컴퓨팅 자원의 스케일-인요청” 정보가 포함된 경우, 오토 스케일링부(106)는 서비스 모듈 M2에 대한 컴퓨팅 자원을 스케일-인할 수 있다. 예를 들어, 오토 스케일링부(106)는 서비스 모듈 M2를 실행 중인 서버의 개수를 줄일 수 있다.
이와 같이, 본 발명의 실시예들에 따르면, 서비스 모듈(120)별 메시지 처리량 또는 메시지 처리 시간(또는 메시지 처리 속도)을 고려하여 플랫폼(110)의 컴퓨팅 자원을 오토 스케일링함으로써, 메시지를 빠르고 안정적으로 처리할 수 있다.
일 실시예에서, 메시지 모니터링부(102), 서비스 모듈 실행부(104) 및 오토 스케일링부(106)는 하나 이상의 프로세서 및 그 프로세서와 연결된 컴퓨터 판독 가능 기록 매체를 포함하는 컴퓨팅 장치 상에서 구현될 수 있다. 컴퓨터 판독 가능 기록 매체는 프로세서의 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서와 연결될 수 있다. 컴퓨팅 장치 내의 프로세서는 각 컴퓨팅 장치로 하여금 본 명세서에서 기술되는 예시적인 실시예에 따라 동작하도록 할 수 있다. 예를 들어, 프로세서는 컴퓨터 판독 가능 기록 매체에 저장된 명령어를 실행할 수 있고, 컴퓨터 판독 가능 기록 매체에 저장된 명령어는 프로세서에 의해 실행되는 경우 컴퓨팅 장치로 하여금 본 명세서에 기술되는 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.
도 2는 본 발명의 일 실시예에 따른 서비스 모듈 실행부(104)에서 서비스 모듈(120)의 실행 순서를 결정하는 과정을 나타낸 예시도이다. 도 2에 도시된 바와 같이, 플랫폼(110) 내에 서비스 모듈 A 내지 E가 존재하며 이들 간의 실행 순서에는 특별한 제약이 없는 것으로 가정한다. 이 경우, 워크플로우 모델의 작성시에는 위 서비스 모듈(120)들의 세트만 표시될 수 있다.
도 2를 참조하면, 워크플로우 모델의 실행 시점에서 서비스 모듈 C에서의 메시지 트래픽이 가장 적으므로(단계 1), 서비스 모듈 실행부(104)는 서비스 모듈 C를 가장 먼저 실행할 수 있다(단계 2).
또한, 서비스 모듈 실행부(104)는 서비스 모듈 C의 실행이 완료된 이후 메시지 모니터링부(102)로부터 서비스 모듈 A, B, D, E의 메시지 처리 성능에 관한 정보를 새롭게 수신할 수 있다. 이때, 서비스 모듈 D에서의 메시지 트래픽이 가장 적으므로, 서비스 모듈 실행부(104)는 서비스 모듈 D를 다음으로 실행할 수 있다(단계 3). 또한, 서비스 모듈 실행부(104)는 이와 같은 과정을 반복하여 하나의 서비스 모듈(120)의 실행이 완료될 때마다 다음으로 실행할 서비스 모듈(120)을 동적으로 결정할 수 있다.
이에 따라, 서비스 모듈 실행부(104)는 서비스 모듈 D의 실행이 완료된 이후 메시지 트래픽이 가장 적은 서비스 모듈 E를 다음으로 실행하고, 이후 서비스 모듈 B, A를 순차적으로 실행할 수 있다(단계 4, 5, 6). 즉, 본 발명의 실시예들에 따르면, 워크플로우 모델의 작성시에 서비스 모듈(120)의 실행 방식 및 실행 순서를 결정하는 것이 아니라 워크플로우 모델의 실행 시점에 서비스 모듈(120)별 메시지 처리 성능에 따라 서비스 모듈(120)의 실행 순서를 동적으로 결정할 수 있다.
한편, 위 예시에서 서비스 모듈 M1의 실행에도 불구하고 서비스 모듈 M1의 메시지 처리 성능이 지속적으로 저하되는 경우, 메시지 모니터링부(102)는 서비스 모듈 M1을 스케일-아웃하도록 결정함으로써 서비스 모듈 M1에 의한 병목 현상을 보다 효율적으로 해결할 수 있다.
도 3은 본 발명의 일 실시예에 따른 워크플로우 모델 및 서비스 모듈(120)의 실행 흐름을 설명하기 위한 예시도이다.
도 3을 참조하면, 본 발명의 일 실시예에 따른 워크플로우 모델은 예를 들어, 의사가 환자의 증상을 바탕으로 감기 몸살인지의 여부를 진단하는 시나리오를 바탕으로 작성된 워크플로우 모델일 수 있다. 상기 워크플로우 모델은 환자의 과거 병력을 조회하는 서비스 모듈(서비스 모듈 1), 환자의 체온을 체크하는 서비스 모듈(서비스 모듈 2), 환자의 두통 유무를 체크하는 서비스 모듈(서비스 모듈 3), 환자의 기관지 염증을 체크하는 서비스 모듈(서비스 모듈 4), 위 내용을 바탕으로 환자의 병명을 진단하는 서비스 모듈(서비스 모듈 5) 등을 포함할 수 있으며, 서비스 모듈 2 내지 4는 상호 독립적으로 작동할 수 있다.
따라서, 본 발명의 실시예들은 상호 독립적으로 작동하며 서로간의 의존도가 없는 서비스 모듈 2 내지 4의 실행 순서를 동적으로 결정하는 데 유용하게 적용될 수 있다.
도 4 내지 도 6은 본 발명의 일 실시예에 따른 메시지 모니터링부(102)에서 오토-스케일링 수행 여부를 결정하는 과정을 설명하기 위한 예시도이다. 도 4 내지 6에서는 스케일링 기준 정보가 TPS(S)이며, 제1 기준치 = 1200(T/s)으로 가정한다.
먼저, 도 4를 참조하면, t=1 에서 TPS(S) = 1000(T/s)이며, 이 경우 TPS(S)＜제1 기준치이므로 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 또한, 메시지 모니터링부(102)는 TPS(Mi) 가 가장 낮은 서비스 모듈, 즉 M4의 컴퓨팅 자원부터 스케일-아웃하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 M4에 대한 컴퓨팅 자원을 스케일-아웃할 수 있다. 즉, 오토 스케일링부(106)는 M4를 실행하는 서버(instance)의 개수를 늘릴 수 있다(예를 들어, 2개→3개).
다음으로, 도 5를 참조하면, t=2 에서 TPS(S) = 1160(T/s)이며, 이 경우 여전히 TPS(S)＜제1 기준치이므로 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원을 스케일-아웃하도록 결정할 수 있다. 또한, 메시지 모니터링부(102)는 TPS(Mi) 가 가장 낮은 서비스 모듈, 즉 M2의 컴퓨팅 자원부터 스케일-아웃하도록 결정할 수 있다. 메시지 모니터링부(102)는 상기 결정된 내용을 포함하는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있으며, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 M2에 대한 컴퓨팅 자원을 스케일-아웃할 수 있다. 즉, 오토 스케일링부(106)는 M2를 실행하는 서버의 개수를 늘릴 수 있다(예를 들어, 2개→3개).
다음으로, 도 6을 참조하면, t=3 에서 TPS(S) = 1240(T/s)이며, 이 경우 TPS(S)＞제1 기준치이므로 메시지 모니터링부(102)는 플랫폼(110)의 컴퓨팅 자원의 스케일-아웃을 중지하도록 결정할 수 있다. 메시지 모니터링부(102)는 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신하지 않거나, 스케일-아웃의 중지 요청이 포함된 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신할 수 있다. 이에 따라, 오토 스케일링부(106)는 M2에 대한 컴퓨팅 자원을 스케일-아웃을 중지할 수 있다.
도 7은 본 발명의 일 실시예에 따른 서비스 처리 방법을 설명하기 위한 도면이다. 도시된 흐름도에서는 상기 방법을 복수 개의 단계로 나누어 기재하였으나, 적어도 하나의 단계들은 순서를 바꾸어 수행되거나, 다른 단계와 결합되어 함께 수행되거나, 생략되거나, 세부 단계들로 나뉘어 수행되거나, 또는 도시되지 않은 하나 이상의 단계가 부가되어 수행될 수 있다.
S702 단계에서, 메시지 모니터링부(102)는 각 서비스 모듈(120)로부터 상기 서비스 모듈(120)에서의 메시지 입출력 정보를 수신한다. 상술한 바와 같이, 메시지 입출력 정보는 모듈(120)에 입력되는 메시지와 상기 모듈(120)로부터 출력되는 메시지의 식별정보(예를 들어, 메시지의 ID), 상기 메시지가 모듈(120)에 입력된 시간 및 상기 메시지가 모듈(120)로부터 출력된 시간에 관한 정보 중 하나 이상을 포함할 수 있다.
S704 단계에서, 메시지 모니터링부(102)는 상기 메시지 입출력 정보를 이용하여 서비스 모듈(120) 중 적어도 하나에 대한 오토-스케일링의 수행 여부를 결정한다. 상기 S704 단계는 도 8을 참조하여 구체적으로 설명하기로 한다.
S706 단계에서, 메시지 모니터링부(102)는 오토-스케일링 요청 메시지를 생성하고, 생성된 오토-스케일링 요청 메시지를 오토 스케일링부(106)로 송신한다. 오토-스케일링 요청 메시지는 오토-스케일링 대상이 되는 서비스 모듈에 관한 정보(예를 들어, 상기 서비스 모듈의 식별 정보, 상기 서비스 모듈을 실행 중인 서버의 식별 정보 등), 상기 오토-스케일링의 종류(즉, 스케일-아웃인지 또는 스케일-인인지)에 관한 정보 등을 포함할 수 있다.
S708 단계에서, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링한다. 구체적으로, 오토 스케일링부(106)는 상기 오토-스케일링 요청 메시지에 따라 상기 서비스 모듈(120) 중 적어도 하나(즉, 스케일-아웃 또는 스케일-인이 필요한 것으로 결정된 서비스 모듈)에 대한 컴퓨팅 자원을 스케일-아웃 또는 스케일-인할 수 있다.
S710 단계에서, 서비스 모듈 실행부(104)는 메시지 모니터링부(102)로 서비스 모듈(120)별 메시지 트래픽 정보를 요청한다.
S712 단계에서, 서비스 모듈 실행부(104)는 메시지 모니터링부(102)로부터 서비스 모듈(120)별 메시지 트래픽 정보를 수신한다. 상술한 바와 같이, 메시지 모니터링부(102)는 각 서비스 모듈(120)로부터 수신한 메시지 입출력 정보를 이용하여 서비스 모듈(120)별 메시지 트래픽을 계산할 수 있다.
S714 단계에서, 서비스 모듈 실행부(104)는 서비스 모듈(120)별 메시지 트래픽 정보를 이용하여 서비스 모듈(120) 각각의 실행 순서를 동적으로 결정한다. 상기 S714 단계는 도 9를 참조하여 구체적으로 설명하기로 한다.
한편, 도 7에서는 설명의 편의상 오토 스케일링부(106)에 의한 오토-스케일링 과정이 서비스 모듈 실행부(104)에 의한 서비스 모듈(120) 실행 순서 결정 과정보다 먼저 수행되는 것으로 도시하였으나 이는 일 실시예에 불과할 뿐 이들의 수행 순서가 도 7의 도시대로 한정되는 것은 아니다. 예를 들어, 서비스 모듈 실행부(104)에 의한 서비스 모듈(120) 실행 순서 결정 과정 이후 오토 스케일링부(106)에 의한 오토-스케일링 과정이 수행되어도 무방하다. 이 경우, S704 내지 S708 단계는 S710 내지 S714 단계 이후 수행될 수 있다.
도 8은 도 7의 S704 단계를 구체적으로 설명하기 위한 흐름도이다.
S802 단계에서, 메시지 모니터링부(102)는 각 서비스 모듈(120)로부터 수신된 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산한다. 상술한 바와 같이, 스케일링 기준 정보는 오토-스케일링의 수행 여부을 결정하는 데 기준이 되는 정보로서, 플랫폼(110) 전체의 초당 트랜잭션 처리수(TPS(S)) 및 플랫폼(110) 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함할 수 있다.
S804 단계에서, 메시지 모니터링부(102)는 스케일링 기준 정보와 설정된 기준치(제1 기준치 또는 제 2 기준치)를 비교한다.
S806 단계에서, 메시지 모니터링부(102)는 상기 비교 결과에 따라 오토-스케일링의 수행 여부를 결정한다. 일 예시로서, 스케일링 기준 정보가 TPS(S)인 것으로 가정할 때, 메시지 모니터링부(102)는 TPS(S)가 제1 기준치보다 설정된 값 이상 낮거나 높은 경우 오토-스케일링이 필요한 것으로 판단할 수 있다. 다른 예시로서, 스케일링 기준 정보가 T(S)인 것으로 가정할 때, 메시지 모니터링부(102)는 T(S)가 제2 기준치보다 설정된 값 이상 낮거나 높은 경우 오토-스케일링이 필요한 것으로 판단할 수 있다. 메시지 모니터링부(102)가 오토-스케일링 수행 여부를 결정하는 구체적인 방법은 앞에서 자세히 설명하였는바, 여기서는 그 자세한 설명을 생략하도록 한다.
도 9는 도 7의 S714 단계를 구체적으로 설명하기 위한 흐름도이다.
S902 단계에서, 서비스 모듈 실행부(104)는 복수의 서비스 모듈(120) 중 메시지 트래픽이 가장 적은 서비스 모듈(120)을 선별한다.
S904 단계에서, 서비스 모듈 실행부(104)는 선별된 서비스 모듈(120)이 현재 실행 가능한지의 여부를 판단한다. 예를 들어, 서비스 모듈 실행부(104)는 선별된 서비스 모듈(120)에서의 메시지 트래픽이 설정된 값 이하인 경우 해당 서비스 모듈(120)이 현재 실행 가능한 것으로 판단할 수 있다.
만약, 해당 서비스 모듈(120)이 실행 가능한 것으로 판단되는 경우, S906 단계에서, 서비스 모듈 실행부(104)는 해당 서비스 모듈(120)을 실행한다. 만약, 해당 서비스 모듈(120)이 실행 가능하지 않은 것으로 판단되는 경우, 서비스 모듈 실행부(104)는 설정된 시간(예를 들어, 10분) 동안 대기 후 S710, S712 단계를 반복한다.
S908 단계에서, 서비스 모듈 실행부(104)는 실행할 서비스 모듈(120)이 더 존재하는지의 여부를 판단한다. 만약, 실행할 서비스 모듈(120)이 더 존재하는 경우, 서비스 모듈 실행부(104)는 S710, S712 단계를 반복한다.
한편, 본 발명의 실시예는 본 명세서에서 기술한 방법들을 컴퓨터상에서 수행하기 위한 프로그램, 및 상기 프로그램을 포함하는 컴퓨터 판독 가능 기록매체를 포함할 수 있다. 상기 컴퓨터 판독 가능 기록매체는 프로그램 명령, 로컬 데이터 파일, 로컬 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나, 또는 컴퓨터 소프트웨어 분야에서 통상적으로 사용 가능한 것일 수 있다. 컴퓨터 판독 가능 기록매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광 기록 매체, 및 롬, 램, 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 상기 프로그램의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함할 수 있다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 전술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다. 그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.
100 : 서비스 처리 시스템
102 : 메시지 모니터링부
104 : 서비스 모듈 실행부
106 : 오토 스케일링부
110 : 플랫폼
120 : 서비스 모듈

Claims (23)

  1. 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하고, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 메시지 모니터링부; 및
    상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하고, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 서비스 모듈 실행부를 포함하는, 서비스 처리 시스템.
  2. 청구항 1에 있어서,
    상기 메시지 모니터링부는, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈 각각에서의 메시지 트래픽을 계산하고, 상기 메시지 트래픽에 따라 상기 서비스 모듈별 메시지 처리 성능을 판단하는, 서비스 처리 시스템.
  3. 청구항 2에 있어서,
    상기 서비스 모듈 실행부는, 상기 복수의 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 가장 먼저 실행하도록 상기 실행 순서를 결정하는, 서비스 처리 시스템.
  4. 청구항 3에 있어서,
    상기 서비스 모듈 실행부는, 상기 메시지 트래픽이 가장 적은 서비스 모듈의 실행이 완료된 이후 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 새롭게 수신하고, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 다음으로 실행할 서비스 모듈을 결정하는, 서비스 처리 시스템.
  5. 청구항 4에 있어서,
    상기 서비스 모듈 실행부는, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 상기 복수의 서비스 모듈에서 상기 실행이 완료된 서비스 모듈을 제외한 나머지 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 상기 다음으로 실행할 서비스 모듈로 결정하는, 서비스 처리 시스템.
  6. 청구항 1에 있어서,
    상기 메시지 모니터링부로부터 오토-스케일링 요청 메시지를 수신하고, 상기 오토-스케일링 요청 메시지에 따라 상기 복수의 서비스 모듈 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링(auto-scaling)하는 오토 스케일링부를 더 포함하는, 서비스 처리 시스템.
  7. 청구항 6에 있어서,
    상기 메시지 모니터링부는, 상기 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산하며, 상기 스케일링 기준 정보와 설정된 기준치와의 비교 결과에 따라 상기 오토-스케일링 요청 메시지를 생성하는, 서비스 처리 시스템.
  8. 청구항 7에 있어서,
    상기 스케일링 기준 정보는, 상기 복수의 서비스 모듈을 구비하는 플랫폼 전체의 초당 트랜잭션 처리 수(TPS(S)) 및 상기 플랫폼 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함하는, 서비스 처리 시스템.
  9. 청구항 8에 있어서,
    상기 메시지 모니터링부는, 상기 서비스 모듈 각각에 대한 초당 트랜잭션 처리 수(TPS(Mi)) 및 상기 서비스 모듈 각각에 대한 평균 메시지 처리 시간(T(Mi)) 중 하나 이상을 계산하며, 상기 비교 결과와 상기 TPS(Mi) 또는 상기 T(Mi)를 고려하여 상기 오토-스케일링 요청 메시지를 생성하는, 서비스 처리 시스템.
  10. 청구항 9에 있어서,
    상기 오토-스케일링 요청 메시지는, 상기 TPS(S)가 제1 기준치보다 설정된 값 이상 낮은 경우 상기 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃(scale-out)하도록 요청하는 메시지이며, 상기 TPS(S)가 상기 제1 기준치보다 설정된 값 이상 높은 경우 상기 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인(scale-in)하도록 요청하는 메시지인, 서비스 처리 시스템.
  11. 청구항 9에 있어서,
    상기 오토-스케일링 요청 메시지는, 상기 T(S)가 제2 기준치보다 설정된 값 이상 높은 경우 상기 T(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃하도록 요청하는 메시지이며, 상기 T(S)가 제2 기준치보다 설정된 값 이상 낮은 경우 상기 T(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인하도록 요청하는 메시지인, 서비스 처리 시스템.
  12. 메시지 모니터링부에서, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하는 단계;
    상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계;
    서비스 모듈 실행부에서, 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하는 단계; 및
    상기 서비스 모듈 실행부에서, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 단계를 포함하는, 서비스 처리 방법.
  13. 청구항 12에 있어서,
    상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계는, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈 각각에서의 메시지 트래픽을 계산하고, 상기 메시지 트래픽에 따라 상기 서비스 모듈별 메시지 처리 성능을 판단하는, 서비스 처리 방법.
  14. 청구항 13에 있어서,
    상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 상기 복수의 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 가장 먼저 실행하도록 상기 실행 순서를 결정하는, 서비스 처리 방법.
  15. 청구항 14에 있어서,
    상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 상기 메시지 트래픽이 가장 적은 서비스 모듈의 실행이 완료된 이후 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 새롭게 수신하고, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 다음으로 실행할 서비스 모듈을 결정하는, 서비스 처리 방법.
  16. 청구항 15에 있어서,
    상기 복수의 서비스 모듈 각각의 실행 순서를 결정하는 단계는, 새롭게 수신된 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 이용하여 상기 복수의 서비스 모듈에서 상기 실행이 완료된 서비스 모듈을 제외한 나머지 서비스 모듈 중 상기 메시지 트래픽이 가장 적은 서비스 모듈을 상기 다음으로 실행할 서비스 모듈로 결정하는, 서비스 처리 방법.
  17. 청구항 12에 있어서,
    오토 스케일링부에서, 상기 메시지 모니터링부로부터 오토-스케일링 요청 메시지를 수신하는 단계; 및
    상기 오토 스케일링부에서, 상기 오토-스케일링 요청 메시지에 따라 상기 복수의 서비스 모듈 중 적어도 하나에 대한 컴퓨팅 자원을 오토-스케일링(auto-scaling)하는 단계를 더 포함하는, 서비스 처리 방법.
  18. 청구항 17에 있어서,
    상기 오토-스케일링 요청 메시지를 수신하는 단계 이전에,
    상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 스케일링 기준 정보를 계산하며, 상기 스케일링 기준 정보와 설정된 기준치와의 비교 결과에 따라 상기 오토-스케일링 요청 메시지를 생성하는 단계를 더 포함하는, 서비스 처리 방법.
  19. 청구항 18에 있어서,
    상기 스케일링 기준 정보는, 상기 복수의 서비스 모듈을 구비하는 플랫폼 전체의 초당 트랜잭션 처리 수(TPS(S)) 및 상기 플랫폼 전체의 평균 메시지 처리 시간(T(S)) 중 하나 이상을 포함하는, 서비스 처리 방법.
  20. 청구항 19에 있어서,
    상기 오토-스케일링 요청 메시지를 생성하는 단계는, 상기 서비스 모듈 각각에 대한 초당 트랜잭션 처리 수(TPS(Mi)) 및 상기 서비스 모듈 각각에 대한 평균 메시지 처리 시간(T(Mi)) 중 하나 이상을 계산하며, 상기 비교 결과와 상기 TPS(Mi) 또는 상기 T(Mi)를 고려하여 상기 오토-스케일링 요청 메시지를 생성하는, 서비스 처리 방법.
  21. 청구항 20에 있어서,
    상기 오토-스케일링 요청 메시지는, 상기 TPS(S)가 제1 기준치보다 설정된 값 이상 낮은 경우 상기 TPS(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃(scale-out)하도록 요청하는 메시지이며, 상기 TPS(S)가 상기 제1 기준치보다 설정된 값 이상 높은 경우 상기 TPS(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인(scale-in)하도록 요청하는 메시지인, 서비스 처리 방법.
  22. 청구항 20에 있어서,
    상기 오토-스케일링 요청 메시지는, 상기 T(S)가 제2 기준치보다 설정된 값 이상 높은 경우 상기 T(Mi)가 가장 높은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-아웃하도록 요청하는 메시지이며, 상기 T(S)가 제2 기준치보다 설정된 값 이상 낮은 경우 상기 T(Mi)가 가장 낮은 서비스 모듈에 대한 컴퓨팅 자원부터 스케일-인하도록 요청하는 메시지인, 서비스 처리 방법.
  23. 하드웨어와 결합되어
    메시지 모니터링부에서, 서로 다른 서비스를 처리하는 복수의 서비스 모듈 각각으로부터 상기 서비스 모듈에서의 메시지 입출력 정보를 수신하는 단계;
    상기 메시지 모니터링부에서, 상기 메시지 입출력 정보를 이용하여 상기 서비스 모듈별 메시지 처리 성능을 판단하는 단계;
    서비스 모듈 실행부에서, 상기 메시지 모니터링부로부터 상기 서비스 모듈별 메시지 처리 성능에 관한 정보를 수신하는 단계; 및
    상기 서비스 모듈 실행부에서, 상기 서비스 모듈별 메시지 처리 성능에 따라 상기 복수의 서비스 모듈 각각의 실행 순서를 동적으로 결정하는 단계
    를 실행시키기 위하여 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램.
KR1020150167794A 2015-11-27 2015-11-27 서비스 처리 시스템 및 방법 KR102387930B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150167794A KR102387930B1 (ko) 2015-11-27 2015-11-27 서비스 처리 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150167794A KR102387930B1 (ko) 2015-11-27 2015-11-27 서비스 처리 시스템 및 방법

Publications (2)

Publication Number Publication Date
KR20170062235A true KR20170062235A (ko) 2017-06-07
KR102387930B1 KR102387930B1 (ko) 2022-04-15

Family

ID=59223737

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150167794A KR102387930B1 (ko) 2015-11-27 2015-11-27 서비스 처리 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR102387930B1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190137235A (ko) * 2018-06-01 2019-12-11 주식회사 티맥스 소프트 서버, 서버를 제어하는 방법 및 컴퓨터 판독 가능 매체에 저장된 컴퓨터 프로그램
US11140564B2 (en) 2019-05-28 2021-10-05 Samsung Electronics Co., Ltd. Method and apparatus for performing radio access network function
KR102537906B1 (ko) * 2022-01-07 2023-05-30 주식회사 저스트큐 위탁 판매를 위한 관리 서버의 오토 스케일링 방법

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000044317A (ko) * 1998-12-30 2000-07-15 윤종용 통신시스템의 서비스모듈 독립적 상태관리방법
KR20110077291A (ko) * 2009-12-30 2011-07-07 아주대학교산학협력단 십 캔슬 플러딩 공격탐지방법 및 그 장치
KR101345068B1 (ko) 2013-06-12 2013-12-26 성결대학교 산학협력단 워크플로우 모델링 및 시뮬레이션 시스템 및 방법
JP5609868B2 (ja) * 2009-05-15 2014-10-22 日本電気株式会社 ワークフロー監視制御システム、監視制御方法および監視制御プログラム
KR20150062634A (ko) * 2013-11-29 2015-06-08 고려대학교 산학협력단 클라우드 컴퓨팅 환경 내 오토 스케일링 시스템 및 방법
KR20150089665A (ko) * 2014-01-28 2015-08-05 한국전자통신연구원 워크플로우 작업 스케줄링 장치
JP2015184879A (ja) * 2014-03-24 2015-10-22 株式会社野村総合研究所 基盤運用管理システムおよび基盤運用管理方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000044317A (ko) * 1998-12-30 2000-07-15 윤종용 통신시스템의 서비스모듈 독립적 상태관리방법
JP5609868B2 (ja) * 2009-05-15 2014-10-22 日本電気株式会社 ワークフロー監視制御システム、監視制御方法および監視制御プログラム
KR20110077291A (ko) * 2009-12-30 2011-07-07 아주대학교산학협력단 십 캔슬 플러딩 공격탐지방법 및 그 장치
KR101345068B1 (ko) 2013-06-12 2013-12-26 성결대학교 산학협력단 워크플로우 모델링 및 시뮬레이션 시스템 및 방법
KR20150062634A (ko) * 2013-11-29 2015-06-08 고려대학교 산학협력단 클라우드 컴퓨팅 환경 내 오토 스케일링 시스템 및 방법
KR20150089665A (ko) * 2014-01-28 2015-08-05 한국전자통신연구원 워크플로우 작업 스케줄링 장치
JP2015184879A (ja) * 2014-03-24 2015-10-22 株式会社野村総合研究所 基盤運用管理システムおよび基盤運用管理方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190137235A (ko) * 2018-06-01 2019-12-11 주식회사 티맥스 소프트 서버, 서버를 제어하는 방법 및 컴퓨터 판독 가능 매체에 저장된 컴퓨터 프로그램
US11140564B2 (en) 2019-05-28 2021-10-05 Samsung Electronics Co., Ltd. Method and apparatus for performing radio access network function
KR102537906B1 (ko) * 2022-01-07 2023-05-30 주식회사 저스트큐 위탁 판매를 위한 관리 서버의 오토 스케일링 방법

Also Published As

Publication number Publication date
KR102387930B1 (ko) 2022-04-15

Similar Documents

Publication Publication Date Title
US9569288B2 (en) Application pattern discovery
US20190394132A1 (en) System and Method for Network Slicing for Service-Oriented Networks
US11163769B2 (en) Joining two data tables on a join attribute
EP2650786A2 (en) Distributed processing system, scheduler node and scheduling method of distributed processing system, and program generation apparatus thereof
US11188348B2 (en) Hybrid computing device selection analysis
CN113177062B (zh) 一种数据查询方法及装置
US20130117755A1 (en) Apparatuses, systems, and methods for distributed workload serialization
US20130074189A1 (en) Software license reconciliation within a cloud computing infrastructure
KR20150087265A (ko) 동적 컴포넌트 퍼포먼스 모니터링
KR20170062235A (ko) 서비스 처리 시스템 및 방법
CN112990895A (zh) 一种加速区块链交易并行执行的方法、设备及储存介质
KR101914347B1 (ko) 대용량 이벤트 로그 재생 방법 및 대용량 이벤트 로그 재생 시스템
US20150135187A1 (en) Method for monitoring resources in computing device, and computing device
US20200326952A1 (en) Modification procedure generation device, modification procedure generation method and storage medium for storing modification procedure generation program
Gu et al. Analyzing execution dynamics of scientific workflows for latency minimization in resource sharing environments
CN117763024A (zh) 一种数据分片抽取方法及装置
GB2582509A (en) Error handling
US20170147407A1 (en) System and method for prediciting resource bottlenecks for an information technology system processing mixed workloads
US20160274954A1 (en) Distributed processing control device
JP6954347B2 (ja) 実験計画最適化装置、実験計画最適化方法および実験計画最適化プログラム
JP5532052B2 (ja) 評価モデル分析システム、評価モデル分析方法およびプログラム
JP5029584B2 (ja) 開発支援装置
US20140215473A1 (en) Objectives of operations executing across environments
KR102496332B1 (ko) 고차 돌연변이를 이용한 소프트웨어 결함 위치 추정을 위한 컴퓨터 시스템 및 그의 방법
Nozdrzykowski et al. Testing the significance of parameters of models estimating execution time of parallel program loops according to the Open MPI Standard

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant