KR20230165515A - 마이크로서비스 기반의 워크플로우 관리 방법 및 시스템 - Google Patents

Abstract

본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 방법은 워크플로우를 실행하는 단계와, 상기 워크플로우 실행에 따른 데이터베이스 상태를 모니터링하는 단계와, 상기 데이터베이스의 성능 저하가 발생되면 제어 정책을 새로운 제어 정책으로 갱신하는 단계를 포함할 수 있다.

Description

마이크로서비스 기반의 워크플로우 관리 방법 및 시스템{METHOD AND SYSTEM FOR MANAGING BASED ON MICROSERCIVES}

본 발명은 워크플로우 최적화를 지원하는 마이크로서비스 기반의 워크플로우 관리 방법 및 시스템에 관한 것이다.

일반적으로, IoT 장치 및 스마트기기가 증가하면서 데이터를 지능적으로 처리하기 위해 컴퓨팅 리소스를 효율적으로 활용하는 다양한 방법이 소개되고 있다.

기존에는 대용량의 컴퓨팅 리소스를 요구하는 응용 프로그램들이 클라우드로 이동해서 복잡한 연산을 수행하였지만 최근에는 엣지컴퓨팅과 같은 제한된 자원 제약 하에서 다양한 유형의 성능 보장을 지원하는 워크플로우 시스템에 대한 관심이 집중되고 있다. 워크플로우는 여러 개의 공동 작업으로 구성된 복잡한 데이터 처리 애플리케이션을 표현할 수 있어 다양한 IT 도메인에서 활용되고 있다.

종래 워크플로우 시스템은 리소스 및 지연 제약 조건을 고려하여 클러스터 또는 그리드와 같은 컴퓨팅 인프라에서 워크 플로우를 실행할 수 있는 방법을 지정하는 워크플로우 실행 계획을 실행한다. 이를 이용하면 클라우드 리소스의 탄력성과 서비스 수준을 어느 정도 보장할 수 있다.

하지만, 종래 워크플로우 시스템은 스케줄링 및 리소스 최적화를 수행하기 위해 워크플로우 구조에 대한 고급 지식이 필요한 경우가 많고, 워크플로우 작업 분할 또는 중요한 경로 결정에 대한 사전 지식 없이 워크플로우를 관리하기가 어렵다.

또한, 종래 워크플로우 시스템은 워크플로우 구현 및 실행을 위해 단일 접근(Sigle Approach) 방식을 채택한다. 이러한 방식은 지나치게 플랫폼 의존적인 형태이기 때문에 새로운 도메인 및 환경으로의 확장 및 재구성에 부적합하다.

또한, 클러스터 및 그리드의 워크플로우 형태는 애플리케이션과 도메인의 유형에 상관 없이 종종 CPU 및 메모리와 같은 물리적 리소스를 클라우드 서버/VM에 워크플로우 작업을 할당한다. 이렇게 되면 상대적으로 가벼운 애플리케이션 워크로드라도 멀리 위치한 클라우드에서 리소스 자원을 할당받기 때문에 연산처리 및 네트워크 지연이 발생된다.

본 발명의 목적은 워크플로우를 독립적으로 처리하여 보다 유연하고 확장 가능한 워크플로우 구성 및 스케줄링이 가능한 마이크로서비스 기반의 워크플로우 관리 방법 및 시스템을 제공하는 데 있다.

상기한 목적을 달성하기 위한 본 발명에 따른 마이크로서비스 기반의 워크플로우 관리 방법은 워크플로우를 실행하는 단계와, 상기 워크플로우 실행에 따른 데이터베이스 상태를 모니터링하는 단계와, 상기 데이터베이스의 성능 저하가 발생되면 제어 정책을 새로운 제어 정책으로 갱신하는 단계를 포함할 수 있다.

본 발명에 따르면, 실시예는 마이크로서비스 기반의 워크플로우 관리 시스템을 구현함으로써, 별도의 고급 지식의 필요 없이 워크플로우 스케줄링 및 리소스 최적화를 수행할 수 있는 효과가 있다.

또한, 본 발명은 마이크로서비스 형태로 개발되어 플랫폼에 독립적이며 확장 및 재구성이 용이한 효과가 있다.

또한, 본 발명은 유연하고 확장 가능한 워크 플로우의 구성 및 스케줄링이 가능한 효과가 있다.

도 1은 본 발명의 일실시예에 따른 엣지 컴퓨팅 환경의 구성을 나타낸 도면이다.
도 2는 본 발명의 일실시예에 따른 엣지 서버의 구성을 나타낸 도면이다.
도 3은 본 발명의 일실시예에 따른 쿠버네티스의 구성을 나타낸 도면이다.
도 4는 본 발명의 일실시예에 따른 쿠버네티스의 구성의 세부 아키텍처를 나타낸 도면이다.
도 5는 본 발명의 일실시예에 따른 쿠버네티스의 구성의 세부 아키텍처를 간략한 모습을 나타낸 도면이다.
도 6은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 시스템을 나타낸 블록도이다.
도 7은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 시스템의 워크플로우 실행부의 세부 구성을 나타낸 블록도이다.
도 8은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 방법을 나타낸 블록도이다.
도 9는 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 실행 단계를 나타낸 블록도이다.
도 10은 본 발명의 일실시예에 따른 컴퓨터 시스템의 구성을 나타낸 블록도이다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

비록 "제1" 또는 "제2" 등이 다양한 구성요소를 서술하기 위해서 사용되나, 이러한 구성요소는 상기와 같은 용어에 의해 제한되지 않는다. 상기와 같은 용어는 단지 하나의 구성요소를 다른 구성요소와 구별하기 위하여 사용될 수 있다. 따라서, 이하에서 언급되는 제1 구성요소는 본 발명의 기술적 사상 내에서 제2 구성요소일 수도 있다.

본 명세서에서 사용된 용어는 실시예를 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 또는 "포함하는(comprising)"은 언급된 구성요소 또는 단계가 하나 이상의 다른 구성요소 또는 단계의 존재 또는 추가를 배제하지 않는다는 의미를 내포한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 해석될 수 있다. 또한, 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.

본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다.

이하, 첨부된 도면을 참조하여 본 발명의 실시예들을 상세히 설명하기로 하며, 도면을 참조하여 설명할 때 동일하거나 대응하는 구성 요소는 동일한 도면 부호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.

도 1은 본 발명의 일실시예에 따른 엣지 컴퓨팅 환경의 구성을 나타낸 도면이다.

도 1에 도시된 바와 같이, 실시예에 따른 엣지 컴퓨팅 환경의 구성은 엣지 게이트웨이, 엣지 서버, 기지국 및 클라우드로 이루어질 수 있으며, 본 발명에 따른 워크플로우 관리는 엣지 서버에서 수행될 수 있다.

도 2는 본 발명의 일실시예에 따른 엣지 서버의 구성을 나타낸 도면이다.

도 2에 도시된 바와 같이, 엣지 서버는 어플리케이션(Applications), 쿠버네티스(Kubernetes(k8s)) 및 OS의 형태로 구성될 수 있다.

쿠버네티스는 컨테이너 형태의 어플리케이션을 구동 및 운용할 수 있느는 미들웨어 플랫폼일 수 있다.

도 3은 본 발명의 일실시예에 따른 쿠버네티스의 구성을 나타낸 도면이다.

도 3에 도시된 바와 같이, 쿠버네티스는 마스터 노드와 워커 노드와 컨트롤 플레인을 포함할 수 있다.

도 4는 본 발명의 일실시예에 따른 쿠버네티스의 구성의 세부 아키텍처를 나타낸 도면이고, 도 5는 본 발명의 일실시예에 따른 쿠버네티스의 구성의 세부 아키텍처를 간략한 모습을 나타낸 도면이다.

도 4에 도시된 바와 같이, 본 발명에서 언급하는 마이크로서비스는 각 노드의 POD 안 컨테이너 형태로 구동될 수 있다.

본 발명의 워크플로우 스케줄링은 쿠버네티스 컨트롤플레인과 밀접한 관련이 있다.

본 발명에서 언급하는 워크플로우 실행부, 모니터링부, 제어정책 제공부는 각각의 POD 형태로 구성되고, 이하에서 명시한 두 모듈을 제외한 나머지 각 <부>안의 <모듈>은 컨테이너 형태로 구현될 수 있다. 상기 내용을 그림으로 표현하면 도 5와 같다.

제어부의 시스템 상태 수집기 모듈은 해당 모듈이 속해있는 노드의 kubelet이고 모니터링부의 시스템 DB는 컨트롤플레인의 etcf일 수 있다.

도 6은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 시스템을 나타낸 블록도이다.

도 6을 참조하면, 실시예에 따른 워크플로우 관리 시스템(100)은 워크플로우 실행부(110)를 포함할 수 있다.

워크플로우 실행부(110)는 워크플로우의 실행을 수행할 수 있다. 워크플로우 실행부(110)는 워크플로우의 이질성을 처리하기 위해 마이크로서비스 기반의 아키텍처를 사용할 수 있다.

마이크로서비스 기반의 아키텍처는 이벤트 기반 메시지 전달 매커니즘을 통해 작업의 시작, 업데이트 및 종료와 같은 상호 작용 메시지를 전달할 수 있다. 다시 말해, 작업의 시작 및 종료와 같은 응답(ack) 정보를 호스트와 클라이언트가 이벤트가 발생할 때마다 메시지를 서로 주고 받을 수 있다.

워크플로우 실행부(110)는 복잡한 작업 의존성을 낮추기 위해 마이크로서비스 형태의 개별 작업을 구현함으로써, 보다 유연하고 확장 가능한 워크플로우 구성 및 스케줄링이 가능하게 한다.

또한, 마이크로서비스 모델을 통해 마이크로서비스 집합에 대한 자원 할당으로 시스템 자원 추상화를 단순화하여 자원을 최적화할 수 있다.

워크플로우 실행부(110)는 컨테이너 오케스트레이션 엔진인 쿠버네티스를 사용할 수 있다. 쿠버네티스를 사용하게 되면 각 작업의 마이크로서비스 작업 처리자 집합을 쿠버네티스의 복제 컨트롤러로 추상화할 수 있고, 컨테이너 충돌 및 서버장애 발생 시 작업 당 지정된 수의 컨테이너가 항상 실행되도록 할 수 있다.

제어정책 제공부(150)로부터 제어 입력으로 수신한 모니터링부(130)의 자원 할당기 모듈(139)은 쿠버네티스에게 각 작업의 복제 컨트롤러의 스케일링 계수(파라미터 값이라는 의미의 계수를 의미함)를 변경할 수 있다.

워크플로우 실행부(110)는 작업 실행기 모듈(111)과, 작업 의존성 서비스 모듈(113)과, 마이크로서비스 기반의 작업처리 모듈(115)을 포함할 수 있다.

도 7은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 시스템의 워크플로우 실행부의 세부 구성을 나타낸 블록도이다.

도 7에 도시된 바와 같이, 워크플로우 요청이 수신되면 작업 실행기 모듈(111)은 작업 호출자가 작업 의존성 서비스 모듈(113)에 워크플로우의 어떤 작업자가 먼저 처리해야 하는지 문의할 수 있다.

작업 실행기 모듈(111)은 작업 의존성 서비스 모듈(113)로부터 응답을 받으면 작업처리 모듈(115)로 요청을 전송할 수 있다. 즉, 작업실행기 모듈(111)은 여러 처리자(예를들어, 소비자) 중 '작업 1의 요청 큐'에서 순서를 대기하고 있는 처리자의 워크플로우 작업을 처리할 수 있도록 요청을 작업처리 모듈(115)로 전송할 수 있다.

각 작업 처리자는 작업 요청 대기열을 모니터링하며 처리가 완료되면 다음 요청을 처리할 수 있도록 작업 의존성 서비스 모듈에 피드백을 전달할 수 있다. 작업 1의 마지막 워크플로우 작업이 완료되면 요청 처리는 종료될 수 있다.

작업처리 모듈(115)은 '작업 요청 큐'에 적재된 워크플로우 작업들을 처리하는 역할을 한다. 작업처리 모듈(115)은 처리에 대한 결과를 작업 의존성 서비스 모듈(113)에 보고할 수 있다. 여기서, 작업 요청 집합, 작업 처리자는 도커(Docker) 컨테이너 형태로 배포될 수 있다.

작업 의존성 서비스 모듈(113)은 작업 조회에 대한 응답을 수행할 수 있다. 작업 의존성 서비스 모듈(113)은 병렬로 실행되는 작업 간의 동기화도 수행할 수 있다. 작업 의존성 서비스 모듈(113)은 복수의 작업 의존성 서버를 포함할 수 있다.

워크플로우의 형태는 큐와 같이 순차적인 형태 또는 분기 형태의 워크플로우를 가질 수 있다. 순차적인 형태는 시간에 흐름에 따라 작업을 하나씩 처리하고 작업 의존성 서비스 모듈에 완료 보고를 하는 방식이다. 하지만, 분기 워크플로우는 해당 분기에 종속되어 있는 모든 작업이 완료가 되어야 다음 워크플로우로 넘어갈 수 있다. 만약, A->B->C,D(병렬)->E 라는 워크플로우가 있으면, C와 D가 모두 처리되어야만 E로 넘어갈 수도 있다. 개별 병렬 단계가 완료되는 시점에 '완료 토큰'이 생성되고, 해당 토큰의 개수가 병렬 처리 작업 숫자와 동일해지면 마지막 작업이 완료되었다고 판단하며 동기화를 진행할 수 있다.

도 6으로 돌아가서, 실시예에 따른 워크플로우 관리 시스템(100)은 모니터링부(130)를 포함할 수 있다.

모니터링부(130)는 워크플로우 및 관련 마이크로서비스 성능을 모니터링할 수 있다. 모니터링부(130)는 성능 보장을 지원하기 위해 시스템 상태를 모니터링하여 비정상적인 상황에 대응하는 역할을 할 수 있다.

모니터링부(130)는 수집기 모듈(133)과, 시각화 모듈(135)과, 알람 모듈(137)과, 자원 할당기 모듈(139)을 포함할 수 있다.

수집기 모듈(133)은 시스템 성능 정보(Performance metrics)와 현재 할당된 자원 정보를 수집할 수 있으며, 수집된 정보는 시스템 DB(131)에 저장될 수 있다.

시각화 모듈(135)은 시스템 DB(131)에서 실시간 성능 데이터를 검색하여 그 결과를 그래프로 생성할 수 있다. 생성된 그래프는 시스템 관리자에게 제공될 수 있다. 시각화 모듈(135)로는 Grafana를 사용할 수 있다.

알람 모듈(137)은 시스템 DB(131)의 성능 정보를 주기적으로 검사하고 성능 보장이 위반될 경우 알림을 생성할 수 있다. 예컨대, 알람 모듈(137)은 시스템 DB(131)의 성능이 미리 설정된 기준값 이하인 경우 알림을 생성할 수 있다. 여기서, 시스템 DB(131)에 대한 성능 검사는 별도의 성능 검사부에서 수행될 수도 있다.

자원 할당기 모듈(139)은 알람에 대한 응답으로, 리소스 할당 결정을 위해 다음 워크플로우 실행 단계의 자원을 재할당하는 작업을 수행할 수 있다.

또한, 수집기 모듈(133)은 작업처리 모듈(115)에서 작업의 '시작'및 '종료'를 나타내는 라우팅 키를 수집하여 시스템 DB(131)에 저장할 수 있다. 수집기 모듈은 작업을 수행하는 동안 시스템 DB에 저장된 '시작 시간' 및 '종료 시간'을 집계하여 전체 성능 메트릭의 평균 요청 처리 시간을 계산할 수 있다. 시스템 DB(131)는 InfluxDB를 사용할 수 있다.

실시예에 따른 워크플로우 관리 시스템(100)은 제어정책 제공부(150)를 포함할 수 있다.

제어정책 제공부(150)는 모니터링부(130)에 성능 보장을 위반하는 알림이 수신될 때마다 새로운 제어 정책을 갱신하는 역할을 수행할 수 있다.

제어정책 제공부(150)는 시스템 식별기 모듈(153)과, 최적 제어기 모듈(155)을 포함할 수 있다.

시스템 식별기 모듈(153)은 피드백 제어 기반 매커니즘을 기초로 과거의 성능 데이터를 기반으로 시스템 모델을 학습시키는 역할을 수행할 수 있다. 시스템 모델은 다층 구조의 인공 신경망일 수 있으며, 인공 신경망을 이용하여 시스템 식별을 수행할 수 있다. 여기서, 인공 신경망은 비선형적이고 복수의 입력층을 가지도록 구성되기 때문에, 워크플로우 관리 시스템과 같은 복잡한 동적 시스템을 사용하는 데 상당히 효과적이다.

실시예는 인공 신경망을 이용하여 시스템 식별을 수행하기 때문에 지원하는 워크플로우 구조에 대한 고급 지식이 필요하지 않게 된다.

최적 제어기 모듈(155)은 시스템 식별기 모듈(153)에서 학습한 시스템 모델을 사용하여 제어 입력을 생성하고, 시스템이 원하는 출력을 내도록 유도할 수 있다.

최적 제어기 모듈(155)을 통해 출력된 새로운 자원 할당 정책은 애플리케이션 워크로드의 역동성에 대처하기 위해 컴퓨팅 리소스를 온디맨드(On-Demand) 방식으로 처리할 수 있다. 여기서, 온디맨드 방식은 필요할 때마다 요청하고 처리하는 방식을 의미할 수 있다. 즉, 최적 제어기 모듈(155)을 통해 출력된 새로운 자원 할당 정책은 모니터링부(130)의 자원할당기 모듈(139)에 전달될 수 있다.

실시예에 따른 최적 제어기 모듈(155)은 사용자의 리소스 예산 제약이 있을 경우, 워크플로우의 예상 처리 지연을 보다 효과적으로 제어할 수 있게 된다.

도 5은 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 관리 방법을 나타낸 블록도이다. 여기서, 워크플로우 관리 방법은 워크플로우 관리 시스템(100)에서 수행될 수 있다.

워크플로우 관리 시스템은 워크플로우를 실행할 수 있다(S100). 워크플로우를 실행하는 단계는 아래와 같다.

도 9는 본 발명의 일실시예에 따른 마이크로서비스 기반의 워크플로우 실행 단계를 나타낸 블록도이다.

워크플로우 관리 시스템의 작업 실행기 모듈에 워크플로우의 요청이 수신되면(S110) 작업 의존성 서비스 모듈로부터 워크플로우 요청에 대한 작업 의존성을 확인할 수 있다(S120).

워크플로우 관리 시스템의 작업 실행기 모듈은 작업처리 모듈에 적절한 작업 큐에 해당 요청을 전달할 수 있다(S130).

워크플로우 관리 시스템의 작업처리모듈은 작업 큐에 대기중인 작업 처리자에게 요청을 배정할 수 있다(S140).

워크플로우 관리 시스템이 작업처리모듈은 작업 처리자의 작업이 완료되면 다음 작업자에게 요청을 전달할 수 있다(S150).

도 8로 돌아가서, 워크플로우 관리 시스템은 모니터링하는 단계를 수행할 수 있다(S200).

워크플로우 관리 시스템의 모니터링부는 시스템 DB의 상태를 모니터링할 수 있다. 워크플로우 관리 시스템의 모니터링부는 모니터링한 결과를 그래프로 생성하거나 성능이 기준값 이하인 경우 알람을 생성할 수 있다.

워크플로우 관리 시스템은 시스템 DB의 성능을 기초로 새로운 제어 정책을 갱신할 수 있다(S300). 예컨대, 시스템 DB의 성능이 기준값 이하인 경우 기존의 제어 정책을 새로운 제어 정책으로 갱신할 수 있다.

도 10은 본 발명의 일실시예에 따른 컴퓨터 시스템의 구성을 나타낸 블록도이다.

실시예에 따른 워크플로우 관리 시스템은 컴퓨터 판독 가능한 기록매체와 같은 컴퓨터 시스템에서 구현될 수 있다.

도 10을 참조하면, 실시예에 따른 컴퓨터 시스템(1000)은 버스(1020)를 통하여 서로 통신하는 하나 이상의 프로세서(1010), 메모리(1030), 사용자 인터페이스 입력 장치(1040), 사용자 인터페이스 출력 장치(1050) 및 스토리지(1060)를 포함할 수 있다. 또한, 컴퓨터 시스템(1000)은 네트워크에 연결되는 네트워크 인터페이스(1070)를 더 포함할 수 있다.

프로세서(1010)는 중앙 처리 장치 또는 메모리나 스토리지에 저장된 프로그램 또는 프로세싱 인스트럭션들을 실행하는 반도체 장치일 수 있다. 프로세서(1010)는 일종의 중앙처리장치로서 워크플로우 관리 시스템(100)의 전체 동작을 제어할 수 있다.

프로세서(1010)는 데이터를 처리할 수 있는 모든 종류의 장치를 포함할 수 있다. 여기서, '프로세서(processor)'는 예를 들어 프로그램 내에 포함된 코드 또는 명령으로 표현된 기능을 수행하기 위해 물리적으로 구조화된 회로를 갖는, 하드웨어에 내장된 데이터 처리 장치를 의미할 수 있다. 이와 같이 하드웨어에 내장된 데이터 처리 장치의 일 예로써, 마이크로프로세서(microporcessor), 중앙처리장치(central processing unit: CPU), 프로세서 코어(processor core), 멀티프로세서(multiprocessor), ASIC(application-specific integrated circuit), FPGA(field programmable gate array) 등의 처리 장치를 망라할 수 있으나, 이에 한정되는 것은 아니다.

메모리(1030)는 실시예에 따른 워크플로우 관리 방법을 수행하기 위한 제어 프로그램 등 전반적인 동작을 위한 다양한 데이터가 저장될 수 있다. 구체적으로, 메모리에는 워크플로우 관리 장치에서 구동되는 다수의 응용 프로그램, 워크플로우 관리 장치의 동작을 위한 데이터 및 명령어가 저장될 수 있다.

메모리(1030) 및 스토리지(1060)는 휘발성 매체, 비휘발성 매체, 분리형 매체, 비분리형 매체, 통신 매체, 또는 정보 전달 매체 중에서 적어도 하나 이상을 포함하는 저장 매체일 수 있다. 예를 들어, 메모리(1030)는 ROM(1031)이나 RAM(1032)을 포함할 수 있다.

일 실시예에 따르면, 컴퓨터 프로그램을 저장하고 있는 컴퓨터 판독 가능한 기록 매체로서, 워크플로우를 실행하는 동작과, 상기 워크플로우 실행에 따른 데이터베이스 상태를 모니터링하는 동작과, 상기 데이터베이스의 성능 저하가 발생되면 새로운 제어 정책을 갱신하는 동작을 포함하는 방법을 프로세서가 수행하도록 하기 위한 명령어를 포함할 수 있다.

본 발명에서 설명하는 특정 실행들은 실시예들로서, 어떠한 방법으로도 본 발명의 범위를 한정하는 것은 아니다. 명세서의 간결함을 위하여, 종래 전자적인 구성들, 제어시스템들, 소프트웨어, 상기 시스템들의 다른 기능적인 측면들의 기재는 생략될 수 있다. 또한, 도면에 도시된 구성 요소들 간의 선들의 연결 또는 연결 부재들은 기능적인 연결 및/또는 물리적 또는 회로적 연결들을 예시적으로 나타낸 것으로서, 실제 장치에서는 대체 가능하거나 추가의 다양한 기능적인 연결, 물리적인 연결, 또는 회로 연결들로서 나타내어질 수 있다. 또한, "필수적인","중요하게" 등과 같은 구체적인 언급이 없다면 본 발명의 적용을 위하여 반드시 필요한 구성 요소가 아닐 수 있다.

따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

100: 워크플로우 관리 시스템
110: 워크플로우 실행부
130: 모니터링부
150: 제어정책 제공부

Claims (1)

1. 워크플로우를 실행하는 단계;
   상기 워크플로우 실행에 따른 데이터베이스 상태를 모니터링하는 단계; 및
   상기 데이터베이스의 성능 저하가 발생되면 제어 정책을 새로운 제어 정책으로 갱신하는 단계;
   를 포함하는 마이크로서비스 기반의 워크플로우 관리 방법.

Images