KR20160005253A - 소프트웨어 정의 네트워크에서 제어 장치 및 그 동작 방법 - Google Patents

Abstract

복수의 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치의 패킷 전송 경로 설정 방법은 상기 소프트웨어 정의 네트워크의 네트워크 정보를 수집하는 단계; 상기 수집한 네트워크 정보에 기초하여 전송되는 플로우의 특성을 판단하는 단계; 상기 판단된 플로우의 특성에 적합한 전송 경로를 상기 플로우에 할당하는 단계; 및 상기 전송 경로를 상기 플로우에 할당한다는 것을 규정하는 플로우 테이블 수정 요청 메시지를 상기 플로우에 속하는 네트워크 스위치에 전송하는 단계를 포함한다.

Description

소프트웨어 정의 네트워크에서 제어 장치 및 그 동작 방법{CONTROL APPARATUS AND METHOD THEREOF IN SOFTWARE DEFINED NETWORK}

본 발명은 소프트웨어 정의 네트워크(Software Defined Network)에서 제어 장치 및 그 동작 방법에 관한 것이다.

2008년 발표된 소프트웨어 정의 네트워킹 기술의 등장은 최근 네트워크 구조를 바꾸고 있다. 소프트웨어 정의 네트워크 기술의 핵심은, 기본적으로, 복잡한 제어 플레인(control plane)의 기능을 데이터 플레인(data plane)과 분리하여, 제어 플레인 의 복잡한 기능을 소프트웨어적으로 처리하고, 데이터 플레인은 단순한 네트워크 패킷의 전달, 무시, 변경 등의 기능만을 수행하도록 하는 데에 있다. 이 경우, 복잡한 하드웨어의 제약 없이 제어 플레인의 도움을 통해 소프트웨어적으로 새로운 네트워크의 기능이 개발될 수 있으며, 동시에 이전 네트워크 구조에서 하기 어려웠던 다양한 시도가 가능하게 되었다.

예를 들어, 클라우드 네트워크와 같은 환경에서, 각 네트워크 스위치 혹은 라우터의 기능을 다이나믹하게 설정하여, 에너지 소비를 줄일 수 있으며, 엔터프라이즈 급의 환경에서는 각 스위치나 라우터에 원하는 접근 제어 방식을 구현할 수 있다. 따라서, 이 방식을 이용하여 기존의 네트워크에서 사용되는 장비의 수를 줄일 수 있으며, 동시에 장비 관리 비용 역시 줄일 수 있다. 또한, 새로운 기능을 자유자재로 실험적으로 개발하여 테스트할 수 있다.

그러나 이러한 기능을 사용하기 위해서는 소프트웨어 정의 네트워크의 콘트롤러의 기능과 성능이 매우 중요하다. 소프트웨어 정의 네트워크의 구조상, 소프트웨어 정의 네트워크는 콘트롤러의 기능과 성능에 의존하여 동작하여서, 콘트롤러가 지원하지 않는 기능을 수행하기 어렵다. 그리고 콘트롤러의 처리능력을 넘는 양의 이벤트가 콘트롤러에 전달되면, 콘트롤러의 처리 속도가 저하됨에 따라 네트워크 전체의 성능이 저하될 수 있다. 예를 들어, 콘트롤러 하나가 100대의 네트워크 스위치를 관리하고, 각 스위치에서 초당 1,000개의 이벤트를 콘트롤러에 보낸다고 하면, 콘트롤러는 초당 100,000개의 이벤트를 처리해야 한다. 콘트롤러가 초당 100,000개의 이벤트를 처리할 수 없음에도 초당 100,000개의 이벤트가 계속해서 콘트롤러에 전달된다면, 콘트롤러가 전달되는 이벤트들을 원활하게 처리할 수 없다. 이에 따라, 콘트롤러에 연결된 스위치들도 네트워크 기능을 원활하게 수행할 수 없다. 그리고 콘트롤러가 이벤트를 처리하는 시간이 길어지게 되면, 네트워크 전체의 속도가 느려질 뿐만 아니라, 콘트롤러의 응답을 기다리던 라우터나 스위치가 패킷을 버리게 되는 상황이 발생할 수도 있다.

따라서, 소프트웨어 정의 네트워크의 콘트롤러에 유입되는 이벤트의 양이 처리할 수 있는 이벤트의 양보다 많은 경우에도 콘트롤러가 일정 시간 내에 이벤트를 원활히 처리할 수 있어서, 소프트웨어 정의 네트워크의 성능이 저하되지 않을 수 있는 방법이 요구된다.

본 발명이 해결하고자 하는 기술적 과제는 소프트웨어 정의 네트워크에서 콘트롤러에 많은 이벤트가 전달되어도, 네트워크가 원활히 동작할 수 있도록 효율적으로 동작하는 제어 장치를 제공하는 것이다.

실시예에서, 복수의 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치의 패킷 전송 경로 설정 방법은 상기 제어 장치의 이벤트 처리 상태를 모니터링하는 단계; 상기 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 단계; 상기 혼잡 상태로 판단되면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 단계; 및 선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 단계를 포함한다.

실시예에서, 복수의 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치는 상기 제어 장치의 이벤트 처리 상태를 모니터링하고, 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 모니터링 모듈; 상기 혼잡 상태이면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 응용 프로그램 선택 모듈; 및 선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 동작 모듈을 포함한다.

실시예에서, 복수의 네트워크 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치를 동작시키는 컴퓨터 프로그램은 상기 제어 장치의 이벤트 처리 상태를 모니터링하는 단계; 상기 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 단계; 상기 혼잡 상태로 판단되면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 단계; 및 선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 단계를 실행시키기 위하여 매체에 저장된다.

실시예에서, 본 발명의 제어 장치는 많은 이벤트가 전달되는 경우에도 네트워크 전체의 성능 저하 없이 안정적으로 동작할 수 있다.

또한, 본 발명의 제어 장치는 이벤트의 우선순위 및 소모 자원을 고려하여, 중요한 작업을 우선적으로 처리할 수 있다.

도 1은 본 발명의 일 실시예에 따른 소프트웨어 정의 네트워크의 기본적인 구조를 보여주는 블록도이다.
도 2는 본 발명의 실시예에 따른 제어 장치의 구조를 보여주는 블록도이다.
도 3은 본 발명의 실시예에 따른 스위치의 구조를 보여주는 블록도이다.
도 4는 본 발명의 실시예에 따른 소프트웨어 정의 네트워크의 동작을 보여주는 래더 다이어그램이다.
도 5는 본 발명의 실시 예에 따른 제어 장치의 동작 방법을 나타내는 흐름도이다.
도 6은 본 발명의 실시 예에 따른 제어 장치의 동작을 나타내는 예시도이다.

아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

도 1은 본 발명의 일 실시예에 따른 소프트웨어 정의 네트워크의 기본적인 구조를 보여주는 블록도이다.

도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 소프트웨어 정의 네트워크(1)는 제어 장치(100), 복수의 네트워크 스위치(200), 복수의 서버(300)를 포함한다. 하나의 제어 장치(100)는 복수의 네트워크 스위치(200)를 관리한다.

이하에서는, 제어 장치(100), 복수의 네트워크 스위치(200), 복수의 서버(300)를 커버하는 개념으로 노드라는 용어가 사용된다. 링크는 2개의 노드 사이의 연결을 나타낸다. 플로우는 일련의 링크들을 나타낸다. 복수의 네트워크 스위치(200), 링크, 플로우를 커버하는 개념으로 네트워크 구성 요소(network element)라는 용어가 사용된다.

서버(300)는 다른 서버에 보내기 위한 패킷을 생성하여 네트워크 인터페이스의 포트를 통해 스위치(200)로 패킷을 전송한다.

네트워크 스위치(200)는 서버(300) 또는 다른 스위치로부터 패킷을 수신하면, 플로우 테이블에 기초하여 패킷을 스위칭한다. 이때, 플로우 테이블이 패킷 스위칭을 위한 플로우 엔트리를 가지지 않는다면, 네트워크 스위치(200)는 제어 장치(100)에 이벤트를 전송하거나 플로우 룰 요구 메시지를 전송한다.

여기서 이벤트는 네트워크 패킷, 네트워크 스위치*200)의 상태 변경과 통계, 네트워크 토폴로지의 상태 변경과 통계 등, 네트워크 스위치(200)에서 제어 장치(100)로 전달되어 제어 장치(100)의 처리를 요하는 다양한 정보를 의미한다.

제어 장치(100)는 복수의 네트워크 스위치(200)의 플로우 테이블들을 관리한다.

한편, 소프트웨어 정의 네트워크(1)는 복수의 제어 장치(100)를 포함할 수 있으며, 복수의 제어 장치(100)는 후술할 제어 장치(100)의 역할을 분산하여 처리할 수 있다.

다음은 도 2를 참조하여 본 발명의 실시예에 따른 제어 장치(100)의 구조를 설명한다.

도 2는 본 발명의 실시예에 따른 제어 장치의 구조를 보여주는 블록도이다.

도 2에 도시된 바와 같이, 본 발명의 실시예에 따른 제어 장치(100)는 네트워크 설정 모듈(110), 네트워크 설정 정보 저장소(113), 네트워크 정보 수집 모듈(120), 네트워크 장애 처리 모듈(130), 모니터링 모듈(140), 자원 계산 모듈(150), 응용 프로그램 선택 모듈(160), 응용 프로그램 저장부(170), 동작 모듈(180), 디스플레이부(193), 및 사용자 입력부(195)를 포함할 수 있다.

여기서, 네트워크 정보 수집 모듈(120)은 네트워크 링크 정보 수집 모듈(121), 네트워크 링크 동작 상태 수집 모듈(123), 네트워크 링크 사용량 수집 모듈(125), 네트워크 토폴로지 정보 수집 모듈(127), 네트워크 플로우 정보 수집 모듈(129)을 포함할 수 있다. 그리고 네트워크 장애 처리 모듈(130)은 네트워크 장애 감지 모듈(131), 백업 모듈(133), 백업 정보 저장소(135), 네트워크 복구 모듈(137)을 포함할 수 있다.

네트워크 설정 모듈(110)은 네트워크 설정 정보를 이용하여 소프트웨어 정의 네트워크(10)를 설정한다.

네트워크 설정 정보 저장소(113)는 네트워크 설정 정보를 저장한다.

네트워크 링크 정보 수집 모듈(121)은 네트워크 링크 정보를 수집한다.

네트워크 링크 동작 상태 수집 모듈(123)은 네트워크 링크 동작 상태 정보를 수집한다.

네트워크 링크 사용량 수집 모듈(125)은 네트워크 링크 사용량 정보를 수집한다.

네트워크 토폴로지 정보 수집 모듈(127)은 네트워크 토폴로지 정보를 수집한다.

네트워크 플로우 정보 수집 모듈(129)은 네트워크 플로우 정보를 수집한다.

네트워크 장애 감지 모듈(131)은 소프트웨어 정의 네트워크(10)의 장애를 감지한다.

백업 모듈(133)은 네트워크 정보를 백업 정보 저장소(135)에 백업한다.

백업 정보 저장소(135)는 네트워크 정보를 보관한다.

네트워크 복구 모듈(137)은 백업된 네트워크 설정 정보를 이용하여 네트워크를 복구한다.

모니터링 모듈(140)은 이벤트 처리 상태를 모니터링한다.

자원 계산 모듈(150)은 제어 장치(100)의 이벤트 처리 가능 자원과 응용 프로그램 저장부(170)에 저장된 하나 이상의 응용 프로그램이 동작 시 소모하는 소모 자원을 계산한다.

응용 프로그램 선택 모듈(160)은 계산된 제어 장치(100)의 이벤트 처리 가능 자원과 응용 프로그램의 소모 자원을 기초로, 이벤트 처리 상태에 따라 동작할 응용 프로그램을 선택한다.

응용 프로그램 저장부(170)는 제어 장치(100)에서 실행되는 하나 이상의 응용 프로그램을 저장한다.

동작 모듈(180)은 선택된 응용 프로그램을 동작시킨다. 그리고 동작 모듈(180)은 네트워크 설정 모듈(110)에 포함될 수 있다.

디스플레이부(193)는 다양한 정보를 디스플레이한다.

사용자 입력부(195)는 다양한 사용자 입력을 획득한다.

다음은 도 3을 참조하여 본 발명의 실시예에 따른 스위치(200)의 구조를 설명한다.

도 3은 본 발명의 실시예에 따른 스위치의 구조를 보여주는 블록도이다.

도 3에 도시된 바와 같이, 본 발명의 실시예에 따른 스위치(200)는 복수의 포트(210), 스위칭 모듈(220), 플로우 테이블 저장부(230), 플로우 테이블 관리 모듈(240)를 포함한다.

플로우 테이블 저장부(230)는 플로우 테이블을 가진다.

스위칭 모듈(220)은 플로우 테이블에 기초하여 패킷 스위칭을 수행한다. 이때, 복수의 포트(210) 중 한 포트를 통해 패킷이 수신되면, 스위칭 모듈(220)은 플로우 테이블에 기초하여 복수의 포트(210) 중 어떤 포트로 수신 패킷을 출력할 지를 결정하고, 결정한 포트로 수신 패킷을 출력한다.

플로우 테이블 관리 모듈(240)은 플로우 테이블 저장부(230)의 플로우 테이블 업데이트가 필요한지를 확인하고, 제어 장치(100)의 플로우 테이블 수정 요청에 따라 플로우 테이블을 수정한다.

다음은 도 4를 참조하여 본 발명의 실시예에 따른 소프트웨어 정의 네트워크의 동작을 설명한다.

도 4는 본 발명의 실시예에 따른 소프트웨어 정의 네트워크의 동작을 보여주는 래더 다이어그램이다.

제어 장치(100)에 전달이 요구되는 이벤트가 네트워크 스위치(200)에서 발생하면(S101), 네트워크 스위치(200)의 플로우 테이블 관리 모듈(240)은 이벤트를 제어 장치(100)에 전달한다(S103).

실시예에서, 네트워크 스위치(200)의 플로우 테이블 관리 모듈(240)은 플로우 룰 요구 메시지를 제어 장치(100)에 전달할 수도 있다. 플로우 룰 요구 메시지는 플로우 룰을 요구하는 메시지이며, 플로우 룰은 네트워크 스위치(200)에 전달된 네트워크 패킷을 전달, 무시, 변경하는 동작을 포함하는 네트워크 스위치 동작에 대한 규칙을 의미한다. 플로우 테이블은 플로우 룰의 집합이다.제어 장치(100)의 네트워크 설정 모듈(110)은 수신한 이벤트에 기초하여 이벤트를 전송한 네트워크 스위치(200)의 플로우 테이블의 수정이 필요한지를 체크한다(S105).

실시예에서, 이벤트가 네트워크 스위치(200)의 초기화, 네트워크 스위치(200)의 턴온, 플로우 테이블에 규정되지 않은 패킷의 네트워크 스위치(200)에 유입 중 어느 하나에 해당하면, 제어 장치(100)의 네트워크 설정 모듈(110)은 네트워크 스위치(200)의 플로우 테이블의 수정이 필요하다고 판단할 수 있다.

한편, 제어 장치(100)의 네트워크 설정 모듈(110)은 수신한 이벤트에 기초하여 이벤트를 전송한 네트워크 스위치(200) 이외의 네트워크 스위치의 플로우 테이블의 수정이 필요한지를 체크할 수도 있다. 예컨데, 발생한 이벤트에 해당하는 네트워크 스위치(200)의 플로우 테이블이 수정되면, 패킷의 스위칭 처리(action)가 수정되어 패킷의 경로가 변경될 수 있다. 이에 따라 변경되는 경로의 반영을 위하여 이벤트를 전송한 네트워크 스위치(200) 이외의 네트워크 스위치의 플로우 테이블의 수정이 필요할 수 있다.

네트워크 스위치(200)의 플로우 테이블의 수정이 필요하면, 제어 장치(100)의 네트워크 설정 모듈(110)은 네트워크 스위치(200)의 플로우 테이블을 수정하고(S107), 네트워크 스위치(200)의 플로우 테이블의 수정 내용을 포함하는 플로우 테이블 수정 요청 메시지를 네트워크 스위치(200)에 전송한다(S109).

실시예에서, 네트워크 스위치(200)가 플로우 룰 요구 메시지를 제어 장치(100)에 전송한 경우, 제어 장치(100)의 네트워크 설정 모듈(110)은 네트워크 스위치(200)에 플로우 룰을 제공할 수 있다.

이벤트를 전송한 네트워크 스위치(200) 이외의 네트워크 스위치의 플로우 테이블의 수정이 필요하면, 제어 장치(100)의 네트워크 설정 모듈(110)은 수정이 필요한 플로우 테이블에 해당하는 네트워크 스위치에도 플로우 테이블 수정 요청 메시지를 전송할 수 있다.

네트워크 스위치(200)의 플로우 테이블 관리 모듈(240)은 플로우 테이블 수정 요청 메시지에 기초하여 자신의 플로우 테이블을 수정한다(S111).

플로우 테이블이 성공적으로 수정되면, 네트워크 스위치(200)의 플로우 테이블 관리 모듈(240)은 플로우 테이블 수정 응답 메시지를 제어 장치(100)에 전송한다(S113).

이후, 네트워크 스위치(200)의 스위칭 모듈(220)은 수정된 플로우 테이블에 기초하여 패킷 스위칭을 수행한다(S115).

구제적으로, 스위칭 모듈(220)은 유입된 패킷이 만족하는 매칭 필드를 가진 플로우 엔트리를 찾고, 유입된 패킷에 대해 플로우 엔트리의 액션을 수행하며, 카운터를 증가시킬 수 있다. 이때, 액션은 유입된 패킷을 어떤 포트로 출력할지를 나타낼 수 있다.

다음은 도 5 및 도 6을 참조하여, 본 발명의 실시 예에 따른 제어 장치의 동작 방법을 설명한다.

도 5는 본 발명의 실시 예에 따른 제어 장치의 동작 방법을 나타내는 흐름도이다.

도 6은 본 발명의 실시 예에 따른 제어 장치의 동작을 나타내는 예시도이다.

제어 장치(100)의 모니터링 모듈(140)은 제어 장치(100)의 이벤트 처리 상태를 모니터링한다(S201).

모니터링 모듈(140)은 제어 장치(100)에 요청되는 이벤트에 대한 정보를 기초로 제어 장치(100)의 이벤트 처리 상태를 모니터링 할 수 있다. 구체적으로 모니터링 모듈(140)은 제어 장치(100)에 요청된 이벤트의 종류와 수, 요청된 이벤트에 대한 응답에 요구되는 시간, 제어 장치(100)의 이벤트 처리 속도, 제어 장치(100)의 이벤트 처리 가능 자원(resource) 중 하나 이상을 모니터링 할 수 있다.

여기서 이벤트는 상술한 네트워크 스위치(200)가 제어 장치(100)에 요청한 이벤트, 제어 장치(100)에서 실행되는 복수의 응용 프로그램이 서로 주고 받는 메시지에 대한 이벤트 중 하나 이상을 포함할 수 있다.

일 실시예로, 모니터링 모듈(140)은 요청되는 하나 이상의 이벤트가 저장된 이벤트 저장구조를 기초로 제어 장치(100)의 이벤트 처리 상태를 모니터링 할 수 있다. 모니터링 모듈(140)은 이벤트 저장구조에 포함된 이벤트의 수, 종류를 모니터링 할 수 있다. 여기서 이벤트가 저장되는 이벤트 저장구조는 큐(Queue), 우선순위 큐(Priority Queue), 힙(Heap), 균형 탐색 트리 구조(Balanced search tree) 등 다양한 자료 구조로 구성될 수 있다.

이를 도 6을 참조하여 설명한다.

도 6을 참조하면, 제어 장치(100)에 요청되는 이벤트는 이벤트 저장 구조에 저장될 수 있다. 그리고 모니터링 모듈(140)은 이벤트 저장 구조를 기초로 제어 장치(100)의 이벤트 처리 상태를 모니터링 할 수 있다. 모니터링 모듈(140)은 모니터링한 이벤트 처리 상태에 대한 정보를 다른 구성에 전달할 수 있다.

다시 도 5를 참조한다.

모니터링 모듈(140)은 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단한다(S203).

모니터링 모듈(140)은 요청되는 이벤트의 수, 종류 및 응답에 요구되는 시간과 제어 장치(100)가 일정 시간 동안 처리할 수 있는 이벤트의 수, 종류를 기초로 제어 장치(100)의 이벤트 처리 상태가 비정상적인 상태인 혼잡 상태인지 판단할 수 있다. 여기서 혼잡 상태란, 제어 장치(100)가 요청되는 이벤트를 요구되는 응답 시간 내에 처리하지 못하는 상태, 제어 장치(100)의 자원을 과도하게 사용하는 상태 중 하나 이상을 의미할 수 있다.

일 실시예로, 제어 장치(100)가 초당 처리할 수 있는 이벤트의 수가 1만개이고, 요청된 이벤트의 수가 3만개이며, 요청된 이벤트들은 2초 이내에 응답이 요구되는 경우, 모니터링 모듈(140)은 제어 장치(100)가 요청된 이벤트를 요구되는 응답 시간 내에 처리할 수 없는 비정상적인 상태인 혼잡 상태로 판단할 수 있다.

여기서 제어 장치(100)가 일정 시간 동안 처리할 수 있는 이벤트의 수, 종류는 제어 장치(100)의 처리 가능 자원에 따라 변동될 수 있다.

다른 실시예로, 모니터링 모듈(140)은 제어 장치(100)의 자원 사용량을 기초로 혼잡 상태 여부를 판단할 수 있다. 여기서 자원 사용량이란, 제어 장치(100)에 포함된 하드웨어의 사용량을 의미할 수 있다. 예를 들면, 제어 장치(100)에 포함된 CPU, 메모리, 디스크 중 하나 이상의 사용량이 자원 사용량일 수 있다. 이에 따라, 모니터링 모듈(140)은 제어 장치(100)의 자원 사용량이 일정값 이상이면 제어 장치(100)가 요청된 이벤트를 요구되는 응답 시간 내에 처리할 수 없는 비정상적인 상태인 혼잡 상태로 판단할 수 있다. 이에 따라 모니터링 모듈(140)은 변동되는 제어 장치(100)의 이벤트 처리 가능 자원을 기초로, 제어 장치(100)가 일정 시간 동안 처리할 수 있는 이벤트의 수, 종류를 계산할 수 있다. 그리고 모니터링 모듈(140)은 계산된 일정 시간 동안 처리할 수 있는 이벤트의 수, 종류를 기초로 상술한 혼잡 상태 여부를 판단할 수 있다.

또 다른 실시예로, 모니터링 모듈(140)은 제어 장치(100)가 요청된 이벤트를 수신하여, 응답하는 데에 걸리는 시간을 기초로 혼잡 상태 여부를 판단할 수 있다. 구체적으로, 모니터링 모듈(140)은 제어 장치(100)가 네트워크 스위치(200)로부터 이벤트를 수신하여, 수신된 이벤트에 대한 응답을 네트워크 스위치(200)에 전송하는 데에 걸리는 시간을 측정할 수 있다. 모니터링 모듈(140)은 측정된 시간이 일정 시간 이상이면 제어 장치(100)가 요청된 이벤트를 요구되는 응답 시간 내에 처리할 수 없는 비정상적인 상태인 혼잡 상태로 판단할 수 있다. 한편, 모니터링 모듈(140)은 제어 장치(100)에 요청된 모든 이벤트에 대해 응답 시간을 측정하거나 일부 이벤트에 대한 응답 시간을 측정하여, 혼잡 상태 여부를 판단할 수 있다.

모니터링 모듈(140)은 이벤트 처리 상태가 혼잡 상태로 판단되면, 혼잡 상태임을 알리는 혼잡 상태 메시지를 자원 계산 모듈(150), 응용 프로그램 선택 모듈(160)에 전송할 수 있다.

이를 도 6을 참조하여 설명한다.

도 6을 참조하면, 모니터링 모듈(140)은 혼잡 상태 메시지를 자원 계산 모듈(150), 응용 프로그램 선택 모듈(160) 중 하나 이상에 전송할 수 있다.

다시 도 5를 참조한다.

제어 장치(100)의 자원 계산 모듈(150)은 응용 프로그램의 이벤트 처리에 필요한 이벤트 처리값을 계산한다(S205).

자원 계산 모듈(150)은 응용 프로그램의 소모 자원값, 응용 프로그램의 이벤트 처리에 소요되는 시간을 기초로 응용 프로그램의 이벤트 처리에 필요한 이벤트 처리값을 계산할 수 있다. 여기서 이벤트 처리값은 응용 프로그램의 실행을 통해 이벤트를 처리하기 위한 제어 장치(100)의 소모 자원값, 이벤트 처리 시간 중 하나 이상을 포함할 수 있다. 그리고 이벤트 처리 시간은 이벤트 처리에 소요되는 시간을 의미할 수 있다.

이벤트를 처리하기 위한 제어 장치(100)의 소모 자원값은 제어 장치(100)에서 해당 응용 프로그램을 통해 이벤트를 처리하는 데에 소모되는 자원 사용량에 대한 수치일 수 있다. 그리고 소모 자원값은 해당 응용 프로그램의 CPU, 메모리, 디스크 중 하나 이상의 자원 사용량을 포함할 수 있다.

이벤트를 처리하기 위한 제어 장치(100)의 이벤트 처리 시간은 제어 장치(100)가 해당 응용 프로그램을 통해 이벤트를 처리하는 데에 소요되는 시간에 대한 수치일 수 있다. 그리고 이벤트 처리 시간은 전체 응용 프로그램의 이벤트 처리 시간, 전체 응용 프로그램 중 일부 응용 프로그램의 이벤트 처리 시간, 해당 응용 프로그램의 일부 동작에 대한 이벤트 처리 시간 중 하나 이상을 포함할 수 있다.

이를 도 6을 참조하여 설명한다.

도 6을 참조하면, 자원 계산 모듈(150)은 모니터링 모듈(140)로부터 혼잡 상태 메시지를 수신하면, 응용 프로그램 저장부(170)에 저장된 복수의 응용 프로그램 각각의 이벤트 처리값을 계산할 수 있다. 여기서 복수의 응용 프로그램 각각은 복수의 버전을 포함할 수 있고, 단일 버전으로 구성될 수도 있다. 이에 따라, 복수의 응용 프로그램 각각은 복수의 버전을 지원할 수도 있고, 단일 버전만을 허용하여 단순한 구조를 채택할 수도 있다. 그래서 후술할 응용 프로그램의 복수의 버전에 대한 내용은 응용 프로그램의 구조에 따라 적절하게 적용될 수 있다.

여기서 복수의 응용 프로그램 각각의 버전을 나타내는 n은 부정수로, 복수의 응용 프로그램 각각의 버전은 서로 다른 버전일 수 있다. 또한, 응용 프로그램의 수를 나타내는 m도 부정수를 의미한다.

구체적으로, 자원 계산 모듈(150)은 모니터링 모듈(140)로부터 혼잡 상태 메시지를 수신하면, 응용 프로그램 저장부(170)에 저장된 하나 이상의 응용 프로그램 각각의 소모 자원값을 계산할 수 있다. 여기서 응용 프로그램의 소모 자원값이란, 제어 장치(100)에서 해당 응용 프로그램를 실행함에 따라 소모되는 자원 사용량에 대한 수치일 수 있다. 이에 따라, 자원 계산 모듈(150)은 복수의 응용 프로그램 각각에 대한 소모 자원값을 각각 계산할 수 있다. 여기서 자원 사용량이란, 제어 장치(100)에 포함된 하드웨어의 사용량을 의미할 수 있다. 예를 들면, 제어 장치(100)에 포함된 CPU, 메모리, 디스크 중 하나 이상의 사용량이 자원 사용량일 수 있다.

또한, 자원 계산 모듈(150)은 응용 프로그램에 포함된 복수의 버전에 대한 소모 자원값을 각각 계산할 수 있다. 응용 프로그램은 하나 이상의 버전을 포함할 수 있고, 동일한 응용 프로그램이더라도 버전에 따라 수행되는 동작이 다를 수 있다.

예를 들면, 패킷을 전달하는 동작을 수행하는 응용 프로그램의 경우, 응용 프로그램의 첫번째 버전은 패킷 전달 경로를 동적으로 계산하여 패킷을 전달할 수 있고, 두번째 버전은 이미 계산된 패킷 전달 경로를 통해 패킷을 전달할 수 있다. 그래서 동일한 응용 프로그램이더라도 버전에 따라 수행되는 동작이 다를 수 있으며, 실행하기 위한 소모 자원값도 다를 수 있다.

다른 예를 들면, 패킷을 차단하는 동작을 수행하는 응용 프로그램의 경우, 응용 프로그램의 첫번째 버전은 특정 패킷만을 차단할 수 있고, 두번째 버전은 모든 패킷을 차단할 있다. 이와 같이, 하나의 응용 프로그램이라도 응용 프로그램의 버전에 따라 수행하는 동작이 다를 수 있으며, 이에 따라 소모 자원값 및 이벤트 처리 시간이 다를 수 있다.

그래서 자원 계산 모듈(150)은 응용 프로그램에 포함된 복수의 버전 각각에 대한 소모 자원값 및 이벤트 처리 시간을 각각 계산할 수 있다. 자원 계산 모듈(150)의 이벤트 처리 시간 계산에 대해서는 후술한다.

한편, 자원 계산 모듈(150)은 응용 프로그램의 소모 자원값을 계산하지 않고, 기 저장된 소모 자원값을 이용할 수도 있다. 구체적으로, 자원 계산 모듈(150)은 복수의 응용 프로그램 각각의 소모 자원값에 대해 미리 계산된 소모 자원값을 이용할 수 있다. 또한, 자원 계산 모듈(150)은 복수의 응용 프로그램 각각의 복수의 버전 각각에 대한 소모 자원값에 대해 미리 계산된 소모 자원값을 이용할 수도 있다.

자원 계산 모듈(150)은 응용 프로그램의 이벤트 처리에 소요되는 시간인 이벤트 처리 시간을 계산할 수 있다. 자원 계산 모듈(150)은 응용 프로그램 저장부(170)에 저장된 하나 이상의 응용 프로그램 각각의 이벤트 처리 시간을 계산할 수 있다. 이에 따라, 자원 계산 모듈(150)은 복수의 응용 프로그램 각각에 대한 이벤트 처리 시간을 각각 계산할 수 있다. 또한, 자원 계산 모듈(150)은 응용 프로그램에 포함된 복수의 버전 각각에 대한 이벤트 처리 시간을 각각 계산할 수 있다.

일 실시예로 자원 계산 모듈(150)은 응용 프로그램이 이벤트 처리에 소요되는 시간들의 평균을 이벤트 처리 시간으로 계산할 수 있다.

다른 실시예로 자원 계산 모듈(150)은 응용 프로그램이 처리한 전체 이벤트 중 일부 이벤트에 대한 이벤트 처리 시간을 기초로 이벤트 처리 시간을 계산할 수 있다.

상술한 이벤트 처리 시간에 대한 설명은 설명을 위한 예시로, 사용자 또는 설계자의 선택에 따라 다양한 방법을 통해 이벤트 처리 시간을 계산할 수 있다.

한편, 자원 계산 모듈(150)은 응용 프로그램의 이벤트 처리 시간을 계산하지 않고, 미리 계산되어 기 저장된 이벤트 처리 시간을 이용할 수 있다. 그리고 자원 계산 모듈(150)은 응용 프로그램의 복수의 버전 각각에 대해 기 저장된 이벤트 처리 시간을 이용할 수도 있다.

자원 계산 모듈(150)은 계산된 응용 프로그램의 소모 자원값과 이벤트 처리 시간 중 하나 이상을 기초로, 복수의 응용 프로그램 각각의 이벤트 처리에 필요한 이벤트 처리값을 계산할 수 있다.

또한, 자원 계산 모듈(150)은 해당 응용 프로그램에 대한 이벤트의 수를 반영하여 이벤트 처리값을 계산할 수도 있다. 이에 따라, 자원 계산 모듈(150)은 응용 프로그램의 소모 자원값이 일정값보다 크고 이벤트 처리 시간이 일정 시간보다 길더라도, 해당 응용 프로그램에 대한 이벤트의 수가 일정값보다 적을 경우에는 해당 응용 프로그램에 대한 이벤트 처리값을 일정값보다 낮출 수 있다.

이외에도 자원 계산 모듈(150)은 이벤트 처리와 관련된 다양한 요소를 고려하여 이벤트 처리값을 계산할 수 있다.

그리고 자원 계산 모듈(150)은 계산된 이벤트 처리값에 대한 정보를 응용 프로그램 선택 모듈(160)에 전달할 수 있다.

다시 도 5를 참조한다.

제어 장치(100)의 자원 계산 모듈(150)은 응용 프로그램의 중요도를 계산한다(S207).

자원 계산 모듈(150)은 응용 프로그램 저장부(170)에 저장된 하나 이상의 응용 프로그램 각각의 중요도를 계산할 수 있다. 여기서 응용 프로그램의 중요도란, 제어 장치(100)가 우선적으로 실행해야 하는 응용 프로그램의 순서에 대한 수치일 수 있다. 그리고 자원 계산 모듈(150)은 계산된 응용 프로그램 각각의 중요도를 기초로, 복수의 응용 프로그램 각각의 실행에 대한 우선 순위를 계산할 수도 있다. 또한, 자원 계산 모듈(150)은 응용 프로그램의 복수의 버전 각각에 대한 중요도를 계산할 수도 있다. 이에 따라, 자원 계산 모듈(150)은 응용 프로그램의 복수의 버전 각각의 중요도를 기초로 복수의 응용 프로그램 각각의 실행에 대한 우선 순위를 계산할 수도 있다.

한편, 상술한 우선 순위는 기 설정된 순위일 수 있으며, 사용자 또는 설계자의 선택에 따라 다양하게 설정될 수 있다.

그리고 자원 계산 모듈(150)은 계산된 중요도에 대한 정보를 응용 프로그램 선택 모듈(160)에 전달할 수 있다.

제어 장치(100)의 응용 프로그램 선택 모듈(160)은 제어 장치(100)의 이벤트 처리 동작의 기준이 되는 처리 가능 자원값을 결정한다(S209).

응용 프로그램 선택 모듈(160)은 이벤트 처리 상태가 혼잡 상태인 경우, 제어 장치(100)의 이벤트 처리 동작의 기준이 되는 처리 가능 자원값을 결정할 수 있다. 구체적으로, 처리 가능 자원값이란, 제어 장치(100)의 이벤트 처리 가능 자원에 대한 수치일 있다.

따라서, 처리 가능 자원값의 최대값은 제어 장치(100)가 모든 응용 프로그램을 실행하는 경우의 소모 자원값의 총합과 같은 값일 수 있다. 그리고 처리 가능 자원값이 0인 경우, 제어 장치(100)는 어떠한 응용 프로그램도 실행하지 않을 수 있어서 이벤트 저장구조에 저장된 이벤트들을 처리하지 않을 수 있다.

한편, 응용 프로그램 선택 모듈(160)은 이전 혼잡상태가 해소된 때의 처리 가능 자원값을 기초로 현재의 처리 자원값을 결정할 수 있다. 예를 들면, 응용 프로그램 선택 모듈(160)은 이전 혼잡상태가 해소된 때의 처리 가능 자원값보다 일정값 큰 값 또는 작은 값을 현재의 처리 자원값으로 결정할 수 있다.

또한, 응용 프로그램 선택 모듈(160)은 기 설정된 처리 가능 자원값 또는 선택된 처리 가능 자원값을 현재의 처리 자원값으로 결정할 수 있다.

제어 장치(100)의 응용 프로그램 선택 모듈(160)은 계산된 이벤트 처리값, 중요도 및 결정된 처리 가능 자원값을 기초로 실행될 응용 프로그램을 선택한다(S211).

응용 프로그램 선택 모듈(160)은 응용 프로그램의 이벤트 처리값, 중요도 및 제어 장치(100)의 처리 가능 자원값을 기초로, 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택할 수 있다. 또한, 응용 프로그램 선택 모듈(160)은 하나의 응용 프로그램의 복수의 버전 중 하나의 버전을 선택할 수도 있다.

이를 도 6을 참조하여 설명한다.

응용 프로그램 선택 모듈(160)은 모니터링 모듈(140)로부터 혼잡 상태 메시지를 수신하고, 자원 계산 모듈(150)로부터 계산된 이벤트 처리값 및 중요도에 대한 정보를 수신할 수 있다. 그리고 응용 프로그램 선택 모듈(160)은 복수의 응용 프로그램 및 응용 프로그램의 복수의 버전 중에서 실행할 응용 프로그램을 선택할 수 있다.

구체적으로 응용 프로그램 선택 모듈(160)은 결정된 처리 가능 자원값 내에서 실행될 하나 이상의 응용 프로그램을 선택할 수 있다. 응용 프로그램 선택 모듈(160)은 선택된 하나 이상의 프로그램의 이벤트 처리값의 총합이 결정된 처리 가능 자원값 이하가 되도록 하나 이상의 응용 프로그램을 선택할 수 있다. 또한, 응용 프로그램 선택 모듈(160)은 선택된 하나 이상의 프로그램의 중요도의 총합이 최대가 되도록 하나 이상의 응용 프로그램을 선택할 수 있다. 그리고 응용 프로그램 선택 모듈(160)은 하나의 응용 프로그램에 대한 복수의 버전 중에서 하나의 버전에 대한 응용 프로그램만을 선택할 수도 있다.

또한, 응용 프로그램 선택 모듈(160)은 계산된 응용 프로그램 각각의 복수의 버전 각각에 대한 이벤트 처리값, 중요도 중 하나 이상을 기초로 선택 가능한 응용 프로그램의 집합을 생성할 수 있다. 응용 프로그램 선택 모듈(160)은 생성된 응용 프로그램의 집합에서 실행할 응용 프로그램을 선택할 수 있다. 그래서 응용 프로그램 선택 모듈(160)은 모니터링 모듈(140)이 모니터링하는 이벤트 처리 상태를 기초로 생성된 응용 프로그램의 집합에서 실행할 응용 프로그램을 선택할 수도 있다.

상술한 응용 프로그램 선택에 대한 설명은 설명을 위한 예시로, 응용 프로그램 선택 모듈(160)은 다양한 함수 및 방법을 통해 응용 프로그램을 선택할 수 있다. 이에 따라, 응용 프로그램 선택 모듈(160)은 결정된 처리 가능 자원값 내에서 다양한 함수 및 방법을 통해 응용 프로그램을 선택할 수 있다. 그래서 응용 프로그램 선택 모듈(160)은 결정된 처리 가능 자원값 내에서 중요도가 높은 응용 프로그램을 선택할 수 있다. 따라서 응용 프로그램 선택 모듈(160)은 처리 가능 자원값이 낮아지더라도, 상술한 다양한 함수 및 방법을 통해 중요도가 높은 응용 프로그램을 선택할 수 있다.

응용 프로그램 선택 모듈(160)은 선택된 응용 프로그램에 대한 정보를 동작 모듈(180)에 전달할 수 있다.

제어 장치(100)의 동작 모듈(180)은 선택된 응용 프로그램을 실행하여, 이벤트를 처리한다(S213).

동작 모듈(180)은 선택된 응용 프로그램에 대한 정보를 기초로, 하나 이상의 선택된 응용 프로그램을 실행하여 이벤트 처리 동작을 수행할 수 있다.

이를 도 6을 참조하여 설명한다.

도 6을 참조하면, 동작 모듈(180)은 응용 프로그램 선택 모듈(160)로부터 선택된 응용 프로그램에 대한 정보를 수신할 수 있다. 동작 모듈(180)은 선택된 응용 프로그램에 대한 정보를 기초로 하나 이상의 응용 프로그램을 실행할 수 있다. 이에 따라, 동작 모듈(180)은 이벤트 저장 구조에 저장된 이벤트에 대응하는 응용 프로그램을 통해 처리할 수 있다.

한편, 동작 모듈(180)은 선택된 응용 프로그램을 실행하여 이벤트를 처리할 때, 응용 프로그램의 중요도가 높은 응용 프로그램부터 실행할 수도 있다. 또한, 동작 모듈(180)은 선택된 응용 프로그램을 실행하여 이벤트를 처리할 때, 응용 프로그램의 복수의 버전 중 중요도가 높은 응용 프로그램의 버전부터 실행할 수도 있다.

다시 도 5를 참조한다.

모니터링 모듈(140)은 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단한다(S215).

모니터링 모듈(140)은 상술한 동작을 통해, 혼잡 상태가 해소되었는지 판단할 수 있다. 구체적으로, 모니터링 모듈(140)은 요청되는 이벤트의 수, 종류 및 응답에 요구되는 시간과 제어 장치(100)가 일정 시간 동안 처리할 수 있는 이벤트의 수, 종류를 기초로 제어 장치(100)의 이벤트 처리 상태가 비정상적인 상태인 혼잡 상태인지 판단할 수 있다.

한편, 모니터링 모듈(140)의 혼잡 상태 판단에 대한 내용은 상술한 바 있으므로, 자세한 내용은 생략한다.

그리고 모니터링 모듈(140)은 동작 모듈(180)의 선택된 응용 프로그램 실행 동작이 실행되고 일정 시간이 경과한 후, 혼잡 상태 해소 여부를 판단할 수도 있다. 예를 들면, 모니터링 모듈(140)은 동작 모듈(180)이 상술한 과정을 통해 선택된 응용 프로그램을 실행한 때로부터 몇 초의 시간이 경과한 후, 혼잡 상태 해소 여부를 판단할 수 있다.

모니터링 모듈(140)은 혼잡 상태 메시지를 자원 계산 모듈(150), 응용 프로그램 선택 모듈(160) 중 하나 이상에 전송할 수 있다.

응용 프로그램 선택 모듈(160)은 이벤트 처리 상태가 혼잡 상태이면, 처리 가능 자원값을 변경한다(S217).

응용 프로그램 선택 모듈(160)은 이벤트 처리 상태가 여전히 혼잡 상태인 경우, 제어 장치(100)의 이벤트 처리 동작의 기준이 되는 처리 가능 자원값을 변경할 수 있다.

구체적으로, 응용 프로그램 선택 모듈(160)은 단계 S209에서 결정된 처리 가능 자원값보다 낮은 값을 처리 가능 자원값으로 변경할 수 있다.

그리고 응용 프로그램 선택 모듈(160)은 이벤트 처리 상태, 처리 가능 자원값의 변경 반복 횟수를 기초로 처리 가능 자원값을 변경하는 정도를 달리할 수 있다.

일 실시예로 응용 프로그램 선택 모듈(160)은 이벤트 처리 상태, 처리 가능 자원값의 변경 반복 횟수에 따라 처리 가능 자원값을 낮추는 정도의 간격을 다르게 하여 변경할 수 있다. 예를 들면, 응용 프로그램 선택 모듈(160)은 처리 가능 자원값을 변경하는 수치의 간격을 점점 늘려서 변경할 수도 있고, 수치의 간격을 점점 좁혀서 변경할 수도 있다. 이에 따라, 응용 프로그램 선택 모듈(160)은 처리 가능 자원값을 100에서 80으로, 80에서 50으로 변경할 수도 있으며, 100에서 70으로, 70에서 60으로 변경할 수도 있다. 상술한 처리 가능 자원값 변경의 간격에 대한 예시는 설명을 위한 예시로, 사용자 또는 설계자의 선택에 따라 다양하게 설정될 수 있다.

다른 실시예로 응용 프로그램 선택 모듈(160)은 이벤트 처리 상태, 처리 가능 자원값의 변경 반복 횟수에 따라 처리 가능 자원값을 변경하는 시간의 간격을 다르게 하여 처리 가능 자원값을 변경할 수도 있다. 예를 들면, 응용 프로그램 선택 모듈(160)은 처리 가능 자원값을 2초 간격으로 변경할 수도 있으며, 2초 간격으로 변경하다가 1초 간격으로 변경할 수도 있다. 상술한 처리 가능 자원값 변경의 시간 간격에 대한 예시는 설명을 위한 예시로, 사용자 또는 설계자의 선택에 따라 다양하게 설정될 수 있다.

상술한 응용 프로그램 선택 모듈(160)의 처리 가능 자원값 변경을 통해, 제어 장치(100)는 처리 가능 자원값 이내에서만 응용 프로그램을 실행할 수 있다. 그리고 제어 장치(100)는 혼잡 상태를 벗어날 때까지 상술한 과정을 반복할 수 있다.

이에 따라, 제어 장치(100)는 상술한 단계 S209 내지 단계 S215를 반복할 수 있다.

한편, 단계 S215에서 모니터링 모듈(140)은 이벤트 처리 상태를 기초로 혼잡 상태 여부를 판단한다. 그리고 모니터링 모듈(140)은 혼잡 상태가 아닌 것으로 판단되면 상술한 혼잡 상태가 해소된 것으로 판단하여, 일반적인 동작을 통해 이벤트를 처리할 수 있다.

여기서 모니터링 모듈(140)이 혼잡 상태 여부를 판단하는 내용에 대해서는 상술한 바 있다.

이와 같이, 제어 장치(100)는 수신된 이벤트의 양이 제어 장치가 처리할 수 있는 범위를 벗어나더라도, 중요한 작업을 우선적으로 처리하며 혼잡 상태를 벗어날 수 있다. 그래서 본 발명의 제어 장치(100)는 많은 이벤트가 전달되는 경우에도 네트워크 전체의 성능 저하 없이 안정적으로 동작할 수 있다. 또한, 본 발명의 제어 장치(100)는 수신된 이벤트의 우선순위 및 소모 자원을 고려하여, 중요한 작업을 우선적으로 처리할 수 있다.

이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있으며, 이러한 구현은 앞서 설명한 실시예의 기재로부터 본 발명이 속하는 기술분야의 전문가라면 쉽게 구현할 수 있는 것이다.

이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 통상의 기술자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims (22)

1. 복수의 네트워크 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치의 동작 방법에 있어서,
   상기 제어 장치의 이벤트 처리 상태를 모니터링하는 단계;
   상기 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 단계;
   상기 혼잡 상태로 판단되면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 단계; 및
   선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 단계를 포함하는
   동작 방법.
2. 제1항에 있어서,
   상기 실행할 응용 프로그램을 선택하는 단계는
   상기 복수의 응용 프로그램 각각의 이벤트 처리값을 계산하는 단계와,
   상기 복수의 응용 프로그램 각각의 중요도를 계산하는 단계와,
   상기 제어 장치의 처리 가능 자원값을 결정하는 단계와,
   계산된 이벤트 처리값, 중요도 및 결정된 처리 가능 자원값을 기초로 상기 실행할 응용 프로그램을 선택하는 단계를 포함하는
   동작 방법.
3. 제2항에 있어서,
   상기 복수의 응용 프로그램 각각의 이벤트 처리값을 계산하는 단계는
   상기 복수의 응용 프로그램 각각의 이벤트 처리에 소요되는 소모 자원값, 이벤트 처리 시간 중 하나 이상을 계산하는 단계를 포함하는
   동작 방법.
4. 제2항에 있어서,
   상기 복수의 응용 프로그램 각각의 이벤트 처리값을 계산하는 단계는
   상기 복수의 응용 프로그램 각각에 포함되는 복수의 버전 각각에 대한 이벤트 처리값을 계산하는 단계를 포함하는
   동작 방법.
5. 제4항에 있어서,
   상기 응용 프로그램을 선택하는 단계는
   상기 계산된 응용 프로그램의 복수의 버전 각각에 대한 이벤트 처리값을 기초로 선택 가능한 응용 프로그램의 집합을 생성하는 단계와,
   상기 이벤트 처리 상태를 기초로 상기 생성된 응용 프로그램의 집합에서 상기 실행할 응용 프로그램을 선택하는 단계를 포함하는
   동작 방법.
6. 제2항에 있어서,
   상기 복수의 응용 프로그램 각각의 중요도를 계산하는 단계는
   상기 복수의 응용 프로그램 각각에 포함되는 복수의 버전 각각에 대한 중요도를 계산하는 단계를 포함하는
   동작 방법.
7. 제6항에 있어서,
   상기 응용 프로그램을 선택하는 단계는
   상기 계산된 응용 프로그램의 복수의 버전 각각에 대한 중요도를 기초로 선택 가능한 응용 프로그램의 집합을 생성하는 단계와,
   상기 이벤트 처리 상태를 기초로 상기 생성된 응용 프로그램의 집합에서 상기 실행할 응용 프로그램을 선택하는 단계를 포함하는
   동작 방법.
8. 제2항에 있어서,
   상기 제어 장치의 처리 가능 자원값을 결정하는 단계는
   기 설정된 처리 가능 자원값을 상기 처리 가능 자원값으로 결정하는 단계를 포함하는
   동작 방법.
9. 제2항에 있어서,
   상기 제어 장치의 처리 가능 자원값을 결정하는 단계는
   이전 혼잡상태가 해소된 때의 처리 가능 자원값을 기초로 상기 처리 가능 자원값을 결정하는 단계를 포함하는
   동작 방법.
10. 제1항에 있어서,
    상기 제어 장치의 이벤트 처리 상태를 모니터링하는 단계는
    상기 제어 장치의 이벤트 저장 구조를 기초로 상기 이벤트 처리 상태를 모니터링 하는
    동작 방법.
11. 제1항에 있어서,
    상기 혼잡 상태인지 판단하는 단계는
    상기 제어 장치에 요청된 이벤트의 수와 상기 제어 장치가 일정 시간 동안 처리할 수 있는 이벤트의 수를 기초로 상기 혼잡 상태인지 판단하는 단계를 포함하는
    동작 방법.
12. 제1항에 있어서,
    상기 혼잡 상태인지 판단하는 단계는
    상기 제어 장치의 자원 사용량을 기초로 상기 혼잡 상태인지 판단하는 단계를 포함하는
    동작 방법.
13. 제1항에 있어서,
    상기 혼잡 상태인지 판단하는 단계는
    상기 제어 장치에 요청된 이벤트에 대한 응답 시간을 기초로 상기 혼잡 상태인지를 판단하는 단계를 포함하는
    동작 방법.
14. 제1항에 있어서,
    상기 처리 단계 후, 상기 제어 장치가 상기 혼잡 상태인지 판단하는 단계; 및
    상기 혼잡 상태로 판단되면, 상기 처리 가능 자원값을 변경하는 단계를 더 포함하는
    동작 방법.
15. 제14항에 있어서,
    상기 처리 가능 자원값을 변경하는 단계는
    상기 처리 가능 자원값의 변경 횟수를 기초로 상기 처리 가능 자원값을 변경하는 수치 간격, 시간 간격 중 하나 이상을 조절하는
    동작 방법.
16. 복수의 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치에 있어서,
    상기 제어 장치의 이벤트 처리 상태를 모니터링하고, 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 모니터링 모듈;
    상기 혼잡 상태이면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 응용 프로그램 선택 모듈; 및
    선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 동작 모듈을 포함하는
    제어 장치.
17. 제16항에 있어서,
    상기 복수의 응용 프로그램 각각의 이벤트 처리값 및 중요도를 계산하고, 상기 제어 장치의 처리 가능 자원값을 결정하는 자원 계산 모듈을 더 포함하는
    제어 장치.
18. 제17항에 있어서,
    상기 응용 프로그램 선택 모듈은
    계산된 이벤트 처리값, 중요도 및 결정된 처리 가능 자원값을 기초로 상기 실행할 응용 프로그램을 선택하는
    제어 장치.
19. 복수의 네트워크 스위치를 포함하는 소프트웨어 정의 네트워크를 관리하는 제어 장치를 동작시키는 컴퓨터 프로그램에 있어서,
    상기 제어 장치의 이벤트 처리 상태를 모니터링하는 단계;
    상기 이벤트 처리 상태를 기초로 요청된 이벤트가 기준 이상인 혼잡 상태인지 판단하는 단계;
    상기 혼잡 상태로 판단되면, 상기 제어 장치가 실행하는 복수의 응용 프로그램 중 실행할 응용 프로그램을 선택하는 단계; 및
    선택된 응용 프로그램을 실행하여 상기 요청된 이벤트를 처리하는 단계를 실행시키기 위하여 매체에 저장된
    컴퓨터 프로그램.
20. 제19항에 있어서,
    상기 실행할 응용 프로그램을 선택하는 단계는
    상기 복수의 응용 프로그램 각각의 이벤트 처리값을 계산하는 단계와,
    상기 복수의 응용 프로그램 각각의 중요도를 계산하는 단계와,
    상기 제어 장치의 처리 가능 자원값을 결정하는 단계와,
    계산된 이벤트 처리값, 중요도 및 결정된 처리 가능 자원값을 기초로 상기 실행할 응용 프로그램을 선택하는 단계를 포함하여 실행시키기 위하여 매체에 저장된
    컴퓨터 프로그램.
21. 제20항에 있어서,
    상기 복수의 응용 프로그램 각각의 이벤트 처리값을 계산하는 단계는
    상기 복수의 응용 프로그램 각각의 이벤트 처리에 소요되는 소모 자원값, 이벤트 처리 시간 중 하나 이상을 계산하는 단계를 포함하여 실행시키기 위하여 매체에 저장된
    컴퓨터 프로그램.
22. 제19항에 있어서,
    상기 처리 단계 후, 상기 제어 장치가 상기 혼잡 상태인지 판단하는 단계; 및
    상기 혼잡 상태로 판단되면, 상기 처리 가능 자원값을 변경하는 단계를 더 포함하여 실행시키기 위하여 매체에 저장된
    컴퓨터 프로그램.

Images