KR101396394B1 - 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법 - Google Patents

Abstract

본 발명은 모바일 단말 노드, 서비스, 서비스의 실용 서버/노드, 이를 사용하는 여러 모바일 애플리케이션으로 이루어진 고도의 이질적인 환경에서, 전체적인 품질을 유지하는데 소요되는 오버헤드(Overhead)를 최소화하여 효율적으로 자율적인 판단에 의해 동적으로 품질을 관리하는 방법에 관한 것으로, (a) 모바일 클라우드 환경(MCE)에서 자율 성능최적화를 위한 글로벌 매니저, 클러스터 매니저 및 노드 매니저로 구성된 모바일 클라우드 매니저가 품질 관리를 위한 태스크를 분할하여 수행함에 있어서, 상기 노드 매니저가 해당 노드의 여러 품질을 측정하여 현재 측정된 품질과 이전에 측정된 품질의 차이가 사전에 정의된 임계치보다 큰 경우에 노드 매니저는 담당 클러스터 매니저에게 품질 데이터를 전송하는 단계; (b) 각 클러스터에 할당되어 있는 상기 클러스터 매니저는 현재 품질이 안정한 수준에 있는지 아닌지를 평가하여, 현재 품질이 불안정한 상태인 경우 클러스터 수준의 품질 향상 계획을 수립하는 단계, 및 (c) 상기 클러스터 매니저는 설정된 계획에 따라 클러스터 수준의 품질을 안정화시키는 활용을 수행한 후 수정된 형상 정보를 클러스터 형상 관련 저장소에 업데이트 하는 단계를 포함하여 이루어진 것이다. 본 발명은 MCC의 품질 관리 문제를 해결하고 관리 오버헤드를 줄이면서 효율적인 품질 관리를 할 수 있도록 한 것이다.

Description

모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법{Methods to Autonomously Optimize Performance using Clustering in Mobile Cloud Environment}

본 발명은 모바일 클라우드 환경에서 클러스터링을 이용하여 자율 성능을 최적화하는 방법에 관한 것으로, 더욱 상세하게는 모바일 단말 노드, 서비스, 서비스의 실용 서버/노드, 이를 사용하는 여러 모바일 애플리케이션으로 이루어진 고도의 이질적인 환경에서, 전체적인 품질을 유지하는데 소요되는 오버헤드(Overhead)를 최소화하여 효율적으로 자율적인 판단에 의해 동적으로 품질을 관리하는 방법에 관한 것이다.

모바일 디바이스는 크기가 작기 때문에 PC에 비해 컴퓨팅 자원이 부족하다. 그 결과 자원 소비가 많고 높은 복잡도를 가진 애플리케이션은 모바일 디바이스에서 설치 및 운영되기 어렵다. 그러나 모바일 디바이스는 풍부한 네트워크 연결 능력이 있어 외부 자원을 사용하기가 용이하므로, 모바일 디바이스의 자원이 아닌 클라우드 서비스 또는 PC 등 외부 자원을 사용하는 모바일 클라우드 컴퓨팅(Mobile Cloud Computing, MCC) 연구가 활발히 진행되고 있다.

일반적으로 MCC 환경(MCC Environment, MCE)에는 다른 운영체제와 플랫폼을 가지는 여러 개의 노드, 다양한 모바일 애플리케이션과 서비스 등이 배치되어 있다. 즉 여러 이질적인(Heterogeneous) 특성을 가지는 요소들의 서로 상호작용하여 MCE 환경을 이룬다. 이런 환경에서 모바일 디바이스에 자원 부족, 서비스 품질 저하 등의 문제가 발생하면, 주로 기능 컴포넌트를 다른 노드로 오프로딩 (Offloading)시킴으로써, 해당 문제를 해결하는 접근법을 주로 사용한다.

MCE에서는 오프로딩을 포함한 품질 향상 활동을 수행하기 위하여 여러 노드들을 관리하는 중앙 관리자를 위치시킨다. 하나의 중앙 관리자는 이런 이질적인 요소들이 일정 수준 이상의 품질을 유지하도록 품질 측정, 품질 향상 활동 수행 등의 여러 관리 태스크를 자율적으로 수행한다.

MCE에 속한 노드들이 적을 경우에는 하나의 중앙 관리자의 품질 관리 관련 오버헤드가 비교적 작지만, 노드 수, 모바일 애플리케이션 수, 모바일 애플리케이션들이 사용하는 서비스의 수가 많아지거나 실행빈도가 잦아질 경우, 기존의 중앙 관리자를 통한 서비스 실행 관리는 병목현상으로 인해 성능저하를 유발시킬 수 있는 근본적인 문제를 가지고 있다. 즉 중앙 관리자의 관리 오버헤드로 인해, 모바일 애플리케이션의 품질 저하 문제를 해결하지 못하고, 전체 MCE 품질이 오히려 저하되는 부작용을 초래하게 된다.

현재 MCE 클러스터링과 직접적인 관련이 있는 연구는 이루어지고 있지 않은 실정이다. 그러나 센서 네트워크 분야에서 적은 비용으로 클러스터링을 유지하는 방법, 로드 밸런싱을 위한 클러스터링 방법 등 MCE의 클러스터링과 비슷한 연구가 진행되고 있다.

이러한 연구 중에서 노드 간 근접 정도를 기반으로 클러스터링을 하는 방법으로, 한 노드는 전송 가능한 거리에 있는 노드들과 클러스터링 되며, 가장 많은 노드의 정보를 가진 노드를 관리자로 지정하는 것을 제시하고 있다.

즉 식별 기반 클러스터링 방법으로, 각 노드마다 ID를 가지고 있고, 노드들은 클러스터 관리자 역할을 하는 노드보다 항상 작은 ID를 가지도록 한다. 필요시 클러스터 관리자 노드는 자신의 역할을 자신보다 작은 ID를 가진 노드에 위임할 수 있고, 따라서 각 클러스터들은 서로 일부 노드를 공유하게 된다. 노드 공유시 발생 할 수 있는 문제들은 게이트웨이 역할을 노드에 부여하여 해결하고 있다.

또한, 하나의 클러스터에 최적 개수의 노드를 위치하도록 하는 방법으로, 주기적으로 최적의 개수를 클러스터가 보유하고 있는지 검사하여, 조건을 만족하고 있지 않으면 관리자 역할의 노드를 일반 노드로 역할을 변경하고 새로운 관리자 노드를 임명하도록 한다.

이 외에도 노드의 에너지 효율성을 고려하거나 노드의 이동성을 고려한 클러스터링 등의 다양한 방법들이 제시되고 있다. 그러나 MCE 고유의 특징인 동적으로 변화하는 환경을 고려하지 않고, MCE 클러스터링의 목적과 차이가 있으므로 이들을 그대로 MCE 클러스터링에 적용하기 어렵다.

이와 같이 현재까지 진행된 MCC에 대한 연구는 하나의 관리자가 전체 노드들을 관리하는 접근법을 사용하므로, 다음과 같은 기술적 이슈를 가지고 있다. 즉 동적으로 변화하는 모바일 클라우드 환경을 하나의 관리자가 모두 모니터링 하기가 어렵다. 그리고 모바일 클라우드 환경에 다양한 요소들이 포함되어 있기 때문에 요소들에 대한 최신 정보로 상태를 유지하는데 오버헤드 증가하는 문제가 있다.

더욱이 무선 센서 네트워크 분야에서의 클러스터링 방법은 전체적인 에너지 소비를 균일화하기 위하여 클러스터링을 구성하였다. 또한, 센서 네트워크 분아에서 클러스터링을 위하여 물리적인 거리 또는 네트워크 대역폭 등의 제한된 기준을 사용하여 클러스터링을 사용하였다.

모바일 클라우드 환경의 관리 및 운영이 기술적으로 어렵고, 모바일 클라우드 환경의 품질 관리로 인한 오버헤드가 높다. 대부분은 중앙 관리자에 의해 전체 품질이 유지 및 관리되고 있으므로 모바일 클라우드 환경에 속한 모바일 단말기 수, 클라우드 서버 수, 모바일 애플리케이션 수, 서비스 수가 급증하면 중앙 관리자의 병목현상이 발생하여 관리 자체의 오버헤드가 발생된다. 따라서 모바일 클라우드 환경을 위한 관리 오버헤드를 줄이면서 효율적으로 관리하기 위한 방법이 필요한 실정이다.

대한민국 등록특허공보 제10-1052592호(2011.07.29.공고) 대한민국 등록특허공보 제10-1086531호(2011.11.23.공고) 대한민국 등록특허공보 제10-1129562호(2012.03.29.공고) 대한민국 등록특허공보 제10-0933681호(2009.12.23.공고) 대한민국 등록특허공보 제10-1054679호(2011.08.08.공고) 대한민국 등록특허공보 제10-0910799호(2009.08.05.공고) 대한민국 등록특허공보 제10-0987394호(2010.10.12.공고) 대한민국 등록특허공보 제10-1113006호(2012.01.31.공고) 대한민국 등록특허공보 제10-1068214호(2011.09.28.공고) 대한민국 등록특허공보 제10-0999046호(2010.12.09.공고) 대한민국 공개특허공보 제10-2006-0124500호(2006.12.05.공개) 대한민국 공개특허공보 제10-2011-0138229호(2011.12.26.공개)

본 발명은 상기 문제점을 해결하기 위한 것으로, 모바일 디바이스와 클라우드 서비스 사이의 네트워크를 통한 호출로 인한 부하를 최소화하고 성능을 최적화하기 위하여 서비스 호출 때에 반응시간(Response Time)을 최소화하고 서비스의 처리율(Throughput Rate)을 최대화하기 위한 것이 목적이다.

또한, 본 발명은 모바일 클라우드 환경을 구성하는 모든 노드들의 관리 오버헤드를 줄이기 위하여 논리적 근접도가 높은 노드들끼리 한 그룹으로 묶어 클러스터 단위로 모바일 클라우드 환경을 관리하기 위한 것이 다른 목적이다.

또한, 본 발명은 클러스터링의 목적이 관리 오버헤드를 줄이기 위한 것이므로, 논리적 근접도가 높은 노드들을 묶기 위하여 논리적인 근접도에 영향을 미치는 여러 요소들을 고려하여 클러스터링을 수행하기 위한 것이 다른 목적이다.

본 발명은 상기 목적을 달성하기 위하여, (a) 모바일 클라우드 환경(MCE)에서 자율 성능최적화를 위한 글로벌 매니저, 클러스터 매니저 및 노드 매니저로 구성된 모바일 클라우드 매니저가 품질 관리를 위한 태스크를 분할하여 수행함에 있어서, 상기 노드 매니저가 해당 노드의 여러 품질을 측정하여 현재 측정된 품질과 이전에 측정된 품질의 차이가 사전에 정의된 임계치보다 큰 경우에 노드 매니저는 담당 클러스터 매니저에게 품질 데이터를 전송하는 단계; (b) 각 클러스터에 할당되어 있는 상기 클러스터 매니저는 현재 품질이 안정한 수준에 있는지 아닌지를 평가하여, 현재 품질이 불안정한 상태인 경우 클러스터 수준의 품질 향상 계획을 수립하는 단계, 및 (c) 상기 클러스터 매니저는 설정된 계획에 따라 클러스터 수준의 품질을 안정화시키는 활용을 수행한 후 수정된 형상 정보를 클러스터 형상 관련 저장소에 업데이트 하는 단계를 포함하여 이루어진 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법을 제공한 것이 특징이다.

본 발명에 따르면, 모바일 디바이스에 설치된 모바일 앱에서 원격 클라우드 서비스를 이용할 때에 서비스 반응시간의 최적화와 서비스의 처리율 최적화를 구현하여 MCC의 품질 관리 문제를 해결하고 관리 오버헤드를 줄이면서 효율적인 품질 관리를 할 수 있고, 자율적인 성능최적화 방법으로 서비스 품질을 위한 관리 인력을 절감한 이점이 있다.

도 1은 본 발명에 따른 모바일 클라우드 환경(MCE)의 메타 모델을 나타낸 블록도이다.
도 2는 본 발명에 따른 클러스터링으로 구성된 MCE의 예를 나타낸 것이다.
도 3은 본 발명에 따른 MCE에서 실행되는 2개의 프로세서 사이의 관계를 나타낸 것이다.
도 4는 본 발명에 따른 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화를 위한 구성을 나타낸 블록도이다.
도 5는 본 발명에 따른 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법을 나타낸 흐름도이다.
도 6은 본 발명에 따른 모바일 클라우드 환경에 적합한 자율적 클러스터링 방법을 나타낸 흐름도이다.
도 7은 본 발명에 따른 클러스터링 시퀀스 다이어그램을 나타낸 것이다.
도 8은 본 발명에서 노드 사이의 근접도를 나타내는 DF테이블을 나타낸 것이다.
도 9는 본 발명에서 세 번의 반복(Iteration)을 거친 클러스터링 결과를 나타낸 그래프이다.
도 10은 본 발명에서 클러스터링 여부에 따른 결과를 비교한 그래프이다.
도 11은 본 발명에서 NumCluster에 따른 QoMCE 결과를 나타낸 그래프이다.

이하 본 발명에 따른 실시 예로서, 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법에 관하여 첨부된 도면을 참조하여 상세하게 설명한다.

먼저, 본 발명에서는 MCE에서 중앙 관리자의 관리 오버헤드를 줄이기 위하여 클러스터 (Cluster)라는 논리적인 집합 단위를 MCE에 도입한다. 클러스터는 비슷한 특성을 가지는 객체들끼리 모아놓은 집합을 의미하며, MCE에서는 의존성 및 결합도가 높은 노드들을 묶은 관리 단위이다.

본 발명의 구성은 MCE의 메타모델을 제시하여 클러스터를 지원하기 위한 핵심 요소들을 설명하고, 클러스터링 프로세스를 제시한다. 그리고 MCE에서 동적 클러스터링을 하는데 가장 중요한 기준인 논리적 거리를 계산하는 메트릭을 정의하고, 대표적인 클러스터링 알고리즘인 k-means를 이용하여 클러스터링을 구성하는 방법을 제안한다. 그리고 클러스터링 결과가 최적으로 진행되었는지를 평가하는 MCE 최적화 평가 모델을 정의한다. 마지막으로 실험을 통해, 클러스터링을 통한 관리 성능 향상 여부와 k-means 알고리즘을 이용하여 클러스터링이 최적화 상태로 구성되는지를 확인한다.

본 발명에서 제시된 방법을 이용하여 클러스터링을 최적화 상태로 구성함으로써, MCE의 품질 관리 문제를 해결함과 동시에 관리 오버헤드를 줄이면서 효율적으로 품질 관리를 할 수 있도록 한 것이다.

도 1에서, MCE(1)는 크게 노드(Node)(3), 클러스터(Cluster)(2) 및 MCE 관리자(4)의 3가지 요소로 구성된다. 노드(3)는 애플리케이션이나 서비스를 설치하여 운영하는 물리적 컴퓨팅 디바이스로서, 모바일 노드, 클라우드 노드, 데스크톱 노드, 서버 노드로 구분 할 수 있다. 위와 같이 각 노드 유형이 존재하지만 본 발명에서는 특정 노드 유형에 국한되지 않고 일반적인 노드를 동적 클러스터링하는 방법을 제시한다.

MCE 관리자(4)는 할당 노드의 관리 태스크를 담당하는 노드 관리자(5), 클러스터 단위에서 필요로 하는 관리 태스크를 수행하는 클러스터 관리자(6), 전체 MCE의 관리 태스크를 담당하는 중앙 관리자(7)로 구분된다. 그리고 클러스터 관리자(6)는 해당 클러스터의 품질을 안정화하며, 중앙 관리자(7)는 클러스터 간의 전체 MCE의 품질을 안정화한다. MCE 관리자(4) 중 클러스터 관리자(6)와 중앙 관리자(7)는 각각 현재 MCE에 속한 노드, 클러스터, 애플리케이션, 서비스 등의 정보 및 각각의 품질 정보를 관리한다. 또한, 클러스터(2)는 확장된 MCE에서 새롭게 추가된 요소로서, 노드 간 상호작용 빈도, 공유하는 데이터 집합 등 관점에서 의존성 및 결합도가 높은 노드들을 그룹핑 하여 관리하는 개념적인 구성단위이다. 더욱이 도 2에서, 클러스터링으로 구성된 MCE의 구성도로, 여기에는 총 17개의 노드(N)들이 3개의 클러스터에 포함되어 있으며, 별표(☆)로 표시된 클러스터 관리자에 의해 품질이 관리된다.

만약 도 2에서 클러스터 개념이 없다면, 중앙에 위치한 글로벌 관리자, 즉 중앙 관리자는 17개의 모든 노드들에 설치된 애플리케이션 또는 서비스 품질을 관리해야 한다. 매 초에 각 노드들이 각자 측정된 품질을 글로벌 관리자에 전송한다면 글로벌 관리자는 매 초마다 17개의 요청을 처리해야 한다. 이렇게 집중 포화될 수 있는 관리 태스크를 효과적으로 실행하기 위해, MCE 전체를 좀 더 작은 관리 단위인 클러스터로 나누고, 각 클러스터 별로 관리자가 다양한 관리 태스크를 수행한다. 따라서 3개의 클러스터 관리자는 매 초 최대 6개의 요청을 처리하므로 그 부하가 1/3으로 줄어들게 된다.

MCE는 품질 관리하는 프로세스와 동적 클러스터링 프로세스가 서로 독립적으로 수행된다. 도 3은 MCE에서 수행되는 2개의 프로세스 간의 관계를 나타낸 것이다.

품질 관리 프로세스는 여러 노드 및 애플리케이션, 서비스에서 측정된 품질 데이터를 기반으로 MCE에서 발생하는 품질 관련 결함을 식별하며, 이를 해결하기 위한 오프로딩, 서비스 이주 및 복제 등 여러 품질 향상 활동을 수행한다. 이런 품질 관리 프로세스를 수행하면서, 새로운 노드가 추가되거나 기존 노드가 삭제되고, 새로운 모바일 애플리케이션 및 서비스가 설치되거나 삭제된다. 즉 MCE 형상에 다양한 변화가 발생하게 된다. 이런 변경된 형상 정보를 최적화로 유지하기 위해, 재클러스터링 (re-clustering)이 수행되어야 하며, 이를 위해 동적 클러스터링 프로세스가 수행된다. 이 두 프로세스는 서로 필요한 정보를 상호 교환하면서, MCE 전체 품질을 최적화된 상태로 자율적이며 효율적인 방법으로 유지할 수 있도록 한다.

도 4는 본 발명에서 모바일 클라우드 환경의 구성함에 있어서, MCE에서 관리 오버헤드를 감소시키면서 효율적으로 품질을 유지하기 위한 요소들의 구성도이다.

즉 클러스터는 관리 오버헤드를 줄이기 위하여 도입된 개념으로, 논리적 근접도가 가까운 노드들끼리 그룹화한 관리단위이다. 노드(12)는 모바일 클라우드 환경을 구성하는 물리적인 장치로, 모바일 단말, 클라우드 서버, 데스크톱 PC 등을 포함한다. 애플리케이션(15)은 모바일 단말에서 실행되며, 클라우드 서비스(16)는 여러 모바일 애플리케이션에 의해 재사용되는 기능성 단위이다. 모바일 단말기는 제한된 자원으로 애플리케이션을 실행하므로 대부분 복잡도가 높은 기능을 클라우드 서비스 형태로 실행된다. 모바일 클라우드 매니저(17)는 글로벌 매니저(19), 클러스터 매니터(20) 및 노드 매니저(21)의 3단계로 구성되어 품질 관리를 위한 태스크를 분할하여 수행하도록 한다.

도 5의 모바일 클라우드 환경에서 자율 성능최적화를 위한 전체적인 흐름을 참조하면, 노드 매니저(21)가 해당 노드의 여러 품질을 측정함으로서 자율 안정화 품질 관리 프로세스가 시작된다. 현재 측정된 품질과 이전에 측정된 품질의 차이가 사전에 정의된 임계치보다 큰 경우에 노드 매니저(21)는 담당 클러스터 매니저(20)에게 품질 데이터를 전송한다(S1). 각 클러스터에 할당되어 있는 클러스터 매니저(20)는 현재 품질이 안정한 수준에 있는지 아닌지를 평가하고(S2), 현재 품질이 불안정한 상태인 경우 클러스터 수준의 품질 향상 계획을 수립한다(S3). 계획에 따라 클러스터 수준의 품질을 안정화시키는 활용을 수행하며(S4), 수정된 형상 정보를 클러스터 형상 관련 저장소(18)에 업데이트 한다(S5). 클러스터 형상 관련 저장소(18)에서 관리하는 정보는 해당 클러스터에 포함된 노드(12)에 대한 스펙 정보, 노드들에 설치된 애플리케이션 및 서비스 기능성 정보, 품질 데이터 히스토리 및 기능 호출 히스토리 정보 등이 있다. 상기 단계(S3)에서 현재 발생된 문제를 해결하기 위한 클러스터 수준의 품질 향상 계획을 수립하지 못하면, 이 문제는 글로벌 수준으로 위임된다(S6 내지 S8). 이후의 활동은 클러스터 수준의 품질 향상 활동과 동일하다.

최적화된 클러스터링을 구성하기 위한 기본 원칙은 첫째, 각 클러스터 내의 노드들의 응집도가 높아야 하고, 둘째, 클러스터 간의 결합도는 최소화가 되어야 하며, 셋째, 클러스터의 전반적인 품질은 사전에 정의한 임계치 (Threshold Value)보다 높은 상태를 유지해야 하고, 넷째, 각 클러스터의 자원이용가능성 (Availability)는 사전에 정의한 임계치보다 높은 상태를 유지해야 한다.

처음 두 개의 원칙은 클러스터 간의 의존도를 줄이고 독립성을 유지하여 관리 오버헤드를 줄이도록 정의한 것이고, 나머지 두 개의 원칙은 해당 클러스터 내의 시간/자원 효율성을 보장하기 위해 정의한 것이다. 이 원칙을 만족시키기 위해 클러스터링 프로세스를 도 6과 같다.

단계(S11) 및 단계(S12)는 품질 관리 프로세스를 수행하면서 수집된 정보를 형상 관련 저장소(18)로부터 획득하는 단계이다. 형상 관련 저장소(18)에는 품질 관리 프로세스를 수행한 여러 결과가 저장되어 있으며, 형상 관련 저장소로부터 클러스터 간 결합도 및 응집도를 계산하기 위한 정보와 클러스터 내의 시간/자원 효율성 정보를 수집한다. 만약 수집된 정보로부터 클러스터 간 응집도 및 결합도, 각 클러스터의 시간/자원 효율성이 미리 정의한 임계치보다 낮으면, 현재 클러스터링을 다시 구성해야 할 필요성이 있다고 판단한다.

단계(S13)에서는 클러스터링 알고리즘을 수행하는데 필요한 요소들에 대한 Lock을 획득한다. MCC에서는 품질 관리 프로세스와 클러스터링 프로세스가 동시에 수행되기 때문에 클러스터링 프로세스를 수행하는 동안에 품질 관리 프로세스가 해당 자원을 접근하지 못하게 하기 위해서이다. 즉 클러스터링이 수행되는 동안, 특정 애플리케이션과 구독한 서비스 간의 논리적 근접도 값이 변경되면 클러스터링은 변경된 정보로 다시 수행되어야 하기 때문에 이를 방지하지 위해, Lock을 획득하여 품질 관리 프로세스가 그 정보를 사용하지 못하게 한다.

Lock을 획득하면, 단계(S14)에서는 클러스터링 알고리즘을 수행하여 현재 상황에 최적화된 클러스터링을 구성한다. 마지막으로 단계(S15)와 단계(S16)에서 변경된 형상 정보를 업데이트한다.

상기 클러스터링 알고리즘은 k-means(평균) 클러스터링 알고리즘과 계층적 클러스터링 알고리즘이 모두 적용될 수 있다.

따라서 MCE 노드 간 논리적 근접도(LOGICAL NEARNESS)를 측정하는 방법에 따른 논리적 근접도 측정의 요소로서, 노드 간 논리적 근접도는 노드 사이의 물리적인 거리 외에 여러 기준을 이용하여 계산한 상대적인 가까움을 논리적으로 나타내는 척도이다. 노드 간 논리적인 근접도를 구하기 위한 함수로서 Distance Function(DF)을 정의하기 위하여 표 1과 같은 요소 목록(Factor List, FLIST)을 적용한다.

상기 표에서 5가지 이외에도 MCE가 적용되는 도메인에 따라 논리적인 거리에 영향을 주는 다른 기준을 확장할 수 있다.

FLIST는 각각 다른 단위와 값 범위(Value Range)를 가지고 있기 때문에 이들을 동일한 기준에서 비교하기가 어렵다. 그러므로 FLIST의 값을 측정한 후, 0과 1사이의 값을 가지도록 정규화하는 과정이 필요하다. 다음은 FLIST[1]부터 FLIST[5]까지 값을 측정하고 정규화하는 메트릭을 정의한다.

FLIST[1]은 노드 간 물리적인 거리(Geographical Direct Distance, GDD)를 의미하며 Km로 표현된다. GDD는 해당 노드가 MCE 환경에 등록될 때 형상 관련 저장소에 저장된 값으로, 맵 서비스를 이용하여 측정된다. 그러므로 GDD를 측정하기 위한 별도의 수식은 없으며, 정규화된 값인 GDD _norm 은 다음의 식을 이용하여 측정할 수 있다.

MAX _GDD 는 MCE의 형상 관련 저장소에 저장된 가장 큰 GDD 값을 의미하며, 최초의 MAX _GDD 는 관리자에 의해 등록이 되며 이후 새로운 MAX _GDD 가 등록될 때마다 이 값으로 업데이트 된다. GDD _norm 는 1에 가까운 값일수록 물리적인 두 노드 사이가 논리적으로 멀리 떨어져 있음을 의미한다.

FLIST[2]는 노드 간 선언된 네트워크 대역폭(Declared Network Bandwidth, DNB)을 의미하며 Mbit/sec로 표현된다. GDD와 동일하게 DNB 역시, 해당 노드가 MCE 환경에 등록될 때 형상 관련 저장소에 저장된 값으로, 네트워크 관리자로부터 얻을 수 있다. DNB를 측정하기 위한 별도의 수식은 없으며, 정규화된 값인 DNB _norm 은 다음의 식을 이용하여 측정할 수 있다.

MAX _DNB 는 MCE의 형상 관련 저장소에 등록된 가장 큰 DNB을 의미하며, 새로운 MAX _DNB 가 등록될 때마다 이 값으로 업데이트 된다. DNB _norm 은 1에 가까운 값을 가질수록 두 노드 간의 대역폭이 좁아 논리적으로 멀리 떨어져 있음을 의미한다.

FLIST[3]은 노드 간 측정된 네트워크 대역폭(Measured Network Bandwidth, MNB)을 의미하며 Mbit/sec로 표현된다. MNB는 Network Management System(NMS)나 MCE 형상 관련 저장소의 로그를 통해서 얻을 수 있다. MCE 형상 관련 저장소는 MCE에서 발생하는 모바일 애플리케이션의 호출 관련 로그를 관리하고 있으므로, 이를 바탕으로 MNB 값을 다음의 식을 이용하여 측정할 수 있다.

이 값은 일정 시간 동안 발생한 네트워크상의 데이터 전송에 대한 기록을 이용하여 측정된다. 여기서 Size( TX _i )는 해당 기간 동안 i번째로 전송된 데이터의 크기이며, TransTime(TX _i )는 TX _i 가 전송되는 동안 소요되는 시간을 의미한다. 그리고 NumDataTXs는 관찰한 기간 동안 발생한 전체 데이터 전송횟수이다. 즉 MNB는 특정 기간 동안 발생한 전체 데이터 전송 속도의 평균값을 의미한다.

이를 이용하여 정규화된 값인 MNB _norm 은 다음의 식을 이용하여 측정한다.

MAX _MNB 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 MNB 값을 의미한다. 데이터 전송 관련 기록이 없는 경우, 첫 번째 데이터 전송에 대한 Size(TX ₁ )/TransTime(TX ₁ ) 값이MAX _MNB 가 되며, 이후 새로운 MAX _MNB 가 측정될 때마다 이 값으로 업데이트된다. MNB _norn 은 1에 가까운 값을 가질수록 두 노드 간 데이터 전송 시간이 길어짐을 의미하며, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 의미한다.

FLIST[4]는 노드 간 호출 빈도(Frequency of Invocations, FOI)를 의미하며 호출 횟수가 정수로 표현된다. FOI는 얼마나 자주 애플리케이션이 서비스 인스턴스를 호출하는지에 대한 값이다. FOI는 MCE 형상 관련 저장소의 로그를 통해서 얻을 수 있다. MCE 형상 관련 저장소의 호출 관련 로그를 바탕으로 FOI 값을 다음의 식을 이용하여 측정할 수 있다.

이 값은 특정 기간 동안 발생한 애플리케이션과 서비스 간에 발생한 호출 횟수를 이용하여 측정된다. 여기서 App _i 는 i번째 애플리케이션이며, S _jk 는 j번째 서비스 타입의 k번째 인스턴스를 의미한다. NumInv(App _i , S _jk )는 특정 기간 동안의 App _i 와 S _jk 간의 호출 빈도수를 의미한다. 이를 이용하여 정규화된 값인 FOI _norm 은 다음의 식을 이용하여 측정한다.

MAX _FOI 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 FOI 값을 의미하며, 새로운 MAX _FOI 가 측정될 때마다 이 값으로 업데이트 된다. FOI _norm 은 1에 가까운 값을 가질수록 두 노드 간 호출이 드물게 일어남을 의미하며, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 의미한다.

FLIST[5]는 노드 간 평균 반응 시간(Average Response Time, ART)을 의미하며 Millisecond로 표현된다. ART는 일정 시간 동안의 서비스 호출시 측정되는 반응 시간의 평균값이다. MCE 형상 관련 저장소의 로그를 통해 얻을 수 있다. MCE 형상 관련 저장소의 호출 관련 로그를 바탕으로 ART 값을 다음의 식을 이용하여 측정할 수 있다.

이 값은 특정 기간 동안 발생한 App _i 와 S _jk 간의 호출에 대한 응답 시간의 평균값이다. RT(Inv(App _i , S _jk )) _x )는 두 노드 간 x번째 호출의 반응 시간을 의미한다. 이를 이용하여 정규화된 값인 ART _norm 은 다음의 식을 이용하여 측정한다.

MAX _ART 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 값을 의미한다. 서비스 호출 기록이 없는 경우, RT(Inv(App _i , S _jk )) ₁ ) 값이 MAX _ART 가 되며, 이후 새로운 MAX _ART 가 측정될 때마다 이 값으로 업데이트 된다. ART _norm 는 1에 가까운 값을 가질수록 두 노드 간 반응시간이 오래 걸린다는 것을 의미하며, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 의미한다. 예를 들어, TP _ART 10분 동안 MCE 형상 관련 저장소에 누적된 NumInv이 100이고, 각 호출마다 반응시간인 RT(INV _i )의 합이 1,000이라고 가정한다. 그 결과 ART는 10이라는 결과를 구하게 되는데, 이후 정규화 과정을 거쳐야 한다. ART _norm 을 구하기 위해 TPART 10분 동안의 MAX _ART 가 15라고 한다면, ART _norm 으로 0부터 1사이의 값인 약 0.66을 구하게 된다.

두 노드 간 논리적 근접도를 나타내기 위한 논리적 근접도 측정 함수로서 DF(Distance Function)는 NODE _i 와 NODE _j 가 논리적으로 얼마나 가까운지를 나타내는 값을 구하게 된다. 상기 FLIST를 구하고 정규화된 값들을 가중치를 적용하여 합한 이후에 FLIST의 유형 개수로 나누면 두 NODE _i 와 NODE _j 의 논리적 근접도를 DF로 표현할 수 있다. 따라서 DF를 구하기 위한 공식은 다음과 같다.

도메인마다 FLIST의 중요도가 다르기 때문에 FLIST마다 각각 다른 가중치(W _i )를 지정하여 논리적 근접도 DF를 계산한다.

다음으로, 최적화 알고리즘으로 k-means 기반의 동적 클러스터링 방법으로, 기존 k-means는 클러스터링에 사용되는 대표적인 알고리즘이지만, MCE 환경에 적용하기에는 표 2와 같은 차이점을 가지고 있다.

먼저, 기존의 k-means에서 각 노드는 자신의 위치에 해당하는 값을 가지는 반면에 MCE에서는 두 노드 간의 상대적인 값을 가진다. 예를 들어, 기존 k-means에서는 각 노드의 물리적인 위치 또는 각 노드가 지칭하는 학생의 평균 점수를 나타내지만, MCE에서는 각 노드가 비교 대상이 되는 노드에 대한 상대적인 위치 또는 상대 점수를 의미한다. 둘째, 기존 k-means에서는 Centroid가 클러스터 되는 노드의 위치에 상관없는 임의의 공간에 위치할 수 있으나, MCE에서는 클러스터 되는 노드 중 하나가 Centroid 역할을 해야 한다. 만약 기존의 k-means를 그대로 적용한다면, 임의의 공간에 위치한 Centroid에 새로운 노드를 설치해야 하는 상황이 발생한다. 이는 불필요한 노드를 추가해야 하고, 해당 노드를 초기화 하는 과정 때문에 실행시간 및 자원 활용 관점에서 효과적이지 못하다. 셋째, MCE 환경에서 클러스터링은 클러스터 매니저 재배치, 클러스터 관리자가 관리하는 형상 관련 저장소 업데이트, 중앙 관리자가 관리하는 형상 관련 저장소 업데이트 등 전반적인 정보 변경을 수반하므로, 최적화 상태로 클러스터링이 되어 있음을 반드시 확인해야 한다.

상기 표 2에 보인 k-means와 MCC에서의 k-means의 차이 때문에 본 발명에서는 k-means 알고리즘을 MCC환경에 적용 할 수 있도록 일부 기준을 추가하여 동적 클러스터링 방법에 사용한다.

즉 k 의 위치를 임의 위치가 아닌 임의 노드로 지정하여 노드가 클러스터링 되도록 한다. 그리고 논리적 근접도를 모든 노드에 대해 산출하고, 그 결과를 통해 최소 논리적 근접도인 경우를 바탕으로 노드를 클러스터링 한다. 또한, 클러스터 관리자와 다른 노드 간 논리적 근접도를 통해 해당 클러스터의 최적화 정도를 측정 한다.

상기 기준을 적용함으로써, 표 3과 같이 기존 k-means 알고리즘을 MCC환경에 맞게 수정한다.

k-means를 개선하기 위해 추가된 3가지 기준을 만족시키기 위해서 표 3의 라인 6에 의해서 할당된 NODE 중에서 k가 선정된다. 라인 7에서 노드 간 근접도를 산출하고, 산출된 근접도를 바탕으로 라인 12에서 최적의 Centroid를 탐색하여 업데이트하게 되면 해당 클러스터의 최적화 정도를 측정한다.

k-means의 단점 중 하나는 k를 어떤 값으로 선정하느냐에 따라서 결과가 달라질 수 있다는 것이다. 본 발명에서 제안하는 클러스터링 방법도 k-means를 개선한 방법이기 때문에 이러한 문제점을 가지고 있다. 하지만 본 발명의 방법에서는 어떠한 k, 즉 클러스터 관리자를 어떠한 노드로 선정하더라도 MCE 수준의 최적화는 정도의 차이를 보일 수는 있지만, 최초 노드 선정 때에 가중치를 바탕으로 선정하거나, 또는 선정된 노드를 반복적으로 평가하여 최적의 노드를 찾는 방법을 사용하여 방법 적용 전에 비해 최적화를 이루도록 함으로써 k-means의 단점을 최대한 보완하고 있다.

다음은 상기 표 3의 알고리즘을 위한 설계 모델로서 도 7은 클러스터링을 위하여 노드에 대한 정보를 MCE 형상 관련 저장소에서 할당하는 부분부터 클러스터링 결과를 업데이트 하는 부분까지의 시퀀스 다이어그램이다.

클러스터링에는 총 5개의 클래스가 참여한다. ClusterMgrCtrl은 클러스터 관리자가 수행하는 전체 태스크를 관리하고, ClusterCreator는 클러스터링에 관련된 일을 수행한다. 오른쪽에 위치한 QoS, Node, Cluster클래스는 논리적 거리를 계산하는데 필요한 정보를 제공한다.

ClusterMgrCtrl는 클러스터링을 위해서 Node를 MCE 형상 관련 저장소로부터 데이터를 가져와 할당하도록 한다. ClusterMgrCtrl은 QoS클래스를 통해서 노드 간 상호작용 빈도 및 반응 시간 등을 평가한다.

클러스터링을 위한 노드가 할당되면 ClusterCreator에 의해서 클러스터링을 위한 초기화가 진행된다. k가 임의 노드로 정해지고, k와 노드에 의해 DF 테이블을 생성한다. 이후 가장 근접한 클러스터를 탐색하고, 탐색된 클러스터에서 가장 최소의 DF값을 가지고 있는 노드로 Centroid를 업데이트 해준다. 그리고 더 이상의 최소 DF값을 가지는 노드를 찾을 수 없을 때까지 반복하여 클러스터링 한다.

따라서 본 발명에서 제안하는 방법의 핵심인 클러스터링과 각 클러스터의 노드를 평가하는 메소드를 구현한다. 아래 표 4의 소스코드 1은 지정된 노드와의 논리적 근접도를 바탕으로 그룹화하는 코드 일부를 보여준다.

13라인에서 현재 클러스터 내 모든 노드들의 DF중에서 최소 DF를 찾는다. 15~18라인을 통해 탐색된 DF를 통해 클러스터를 선택하고 현재 노드를 선택된 클러스터에 추가한다.

표 5의 소스코드 2는 클러스터링 이후, 지정된 클러스터 관리자 노드가 최적인지 다른 노드들의 평균 DF와 비교하는 과정을 보여준다.

5~10라인을 통해 현재 클러스터의 각 노드마다 평균 DF를 구하고, 12라인을 통해 평균 DF가 최소인 노드를 탐색한다. 탐색된 노드가 해당 클러스터의 최적의 클러스터 관리자로 선택된다.

다음은 MCC 최적화 평가 모델로서, 동적 클러스터링은 MCC 환경의 관리 품질에 중대한 영향을 미치므로, 클러스터링이 제대로 이루어졌는지를 확인해야 한다. 본 장에서는 제안된 클러스터링 방법을 적용한 MCC의 최적화 정도를 평가하기 위해서 정량적인 측정이 가능한 품질 메트릭을 정의한다.

품질 메트릭에 사용되는 용어(Term)와 함수를 다음과 같이 정의한다.

MCE: MCC를 적용하여 구성된 도메인의 전체 환경을 나타낸다.

CLUSTER: MCE에 속한 하나의 클러스터를 의미하며, 각 클러스터는 아래첨자를 사용하여 구별한다. 즉 CLUSTERi는 i 번째 클러스터를 나타낸다.

NumClusters: MCE를 구성하는 모든 클러스터의 개수이다. 이는 상기 정의한 최적화 알고리즘에서 사용된 k와 동일하다. 즉 MCE = {CLUSTER ₁ , CLUSTER ₂ , …, CLUSTER _NumClusters } 이다.

NODE: MCE에 참여하는 하나의 노드를 나타내며, 각 노드는 아래첨자를 사용하여 구별한다. 즉 NODE _i 는 i 번째 노드를 나타낸다.

CENT_NODE: 각 클러스터의 논리적 중심에 위치해 있으며 클러스터링 결과 클러스터 관리자가 되는 노드를 의미하며, 각 클러스터별 CENT_NODE는 아래첨자를 사용하여 구별한다. 즉 CENT_NODE _i 는 i번째 클러스터인 CLUSTER _i 의 논리적 중앙 노드를 나타낸다.

NumNodes: MCE에 속한 모든 노드들의 개수이다. 즉 MCE = {NODE ₁ , NODE ₂ , …, NODE _NumNodes } 이다.

SizeCluster(CLUSTER _i ): 특정 클러스터 CLUSTER _i 에 속한 노드들의 개수를 반환하는 함수이다. 3개의 노드가 한 클러스터인 CLSUTER _k 를 구성한다면, SizeCluster(CLUSETR _k )의 값은 3이 된다.

SetNodes ( CLUSTER _i ): 특정 클러스터 CLUSTER _i 에 속한 모든 노드들의 집합을 반환하는 함수이다. 즉 SetNodes( CLUSTERi ) = {NODE _x | NODE _x 는 CLUSTER _i 에 속한 노드를 의미함}이다.

DF(NODE _i , NODE _j ): 두 개의 노드인 NODE _i 와 NODE _j 사이의 논리적 근접도를 계산하는 함수이다.

MCC의 최적화 정도는 각 클러스터가 최적으로 구성되었는지 (클러스터 수준의 최적화 정도)와, 전체 MCC 환경이 최적으로 구성되었는지(MCE 수준의 최적화 정도)를 평가함으로써 측정된다.

먼저, 클러스터 수준의 최적화 정도는 해당 클러스터가 논리적으로 근접한 노드들로 구성되어 있는지를 평가함으로써 얻을 수 있다. 즉 해당 클러스터가 높은 응집도를 가지도록 구성되어 있는지를 평가한다. 이를 위하여 다음의 식과 같이 클러스터 수준의 최적화 정도(QoCluster(CLUSTER _i ))를 정의한다.

상기 QoCluster(CLUSTER _i )는 CENT_NODE _i 와 CLUSTER _i 를 구성하는 노드들 간의 DF 값들의 평균이며, 0과 1사이의 값을 반환한다. 논리적으로 가까운 노드들끼리 클러스터를 구성할수록 QoCluster는 0에 가까운 값을 반환할 것이다. 0에 가까운 QoCluster 값을 가지는 클러스터는 상기 정의된 클러스터링의 기본 원칙 중 첫 번째 원칙을 만족시키는 결과가 된다.

MCE 수준의 최적화 정도는 현재 구성된 클러스터들이 서로 결합도가 낮은지를 평가함으로써 측정된다. 클러스터 간에 상호작용이 적다는 것은 논리적으로 멀리 떨어져 있는 노드들끼리 상호작용을 적게 한다는 것을 의미하며, 이는 MCE의 전체 품질을 효과적으로 관리하고 있음을 나타낸다. MCE 수준의 최적화 정도를 평가하기 위해, QoMCE 함수를 다음의 식과 같이 정의한다.

상기 MCE 수준의 최적화 정도는 현재 MCE를 구성하는 클러스터들의 QoCluster 값의 평균이며, 0과 1사이의 값을 반환한다. 클러스터 내의 응집도가 높고 클러스터 간 결합도가 낮을수록 QoMCE는 0에 가까운 값을 반환할 것이다. 0에 가까운 QoMCE 값을 가지는 MCE는 이미 정의한 클러스터링의 기본 원칙 중 두 번째 원칙을 만족시킨다는 것을 의미한다.

다음은, 본 발명에서 제시된 논리적 근접도 측정 방법과 클러스터링 방법의 효율성과 적용성을 MCC 환경에 대한 시뮬레이션 실험을 통하여 검증한다. 실험 결과는 상기 제시된 최적화 평가모델을 적용한다.

실험을 위한 환경의 설정으로 시뮬레이션 실험은 Windows 7에서 Java와 Eclipse로 구현하였고, 표 6과 같이 2개의 MCC 환경, 즉 MCE에 대하여 5가지의 실험을 수행하였다. 각 실험은 다시 20회의 실행을 통하여 평균치를 구하였다.

실험 1은 하나의 클러스터만 사용함으로 실제로 클러스터링을 하지 않고 전체 MCE에 하나의 관리자 노드만 사용하는 경우이며, 실험 2는 실험 1의 결과와 비교하여 클러스터링의 효율성을 확인하기 위해서 수행한다. 실험 3은 동일한 조건이나 초기 Centroid 노드를 달리 설정하여 실험 2와 클러스터링 결과에 어떤 차이가 있는지를 확인한다. 실험 4는 노드를 100개로 늘리고 클러스터는 3개를 사용하여 노드가 늘어남에 따라 클러스터링 효율성을 관찰하며, 실험 5는 클러스터를 10개로 늘렸을 때 그 결과의 차이를 관찰하기 위한 것이다.

상기 실험 2의 진행과정의 중간 결과 값들을 제시된 클러스터링 알고리즘과 관련하여 설명하고, 최적화 평가 모델을 적용한다. 실험 데이터는 총 20개에 대해서 노드 간의 논리적 근접도를 난수(Random Number)를 이용하여 구하고, 도 8과 같이 DF 테이블을 생성하였다. 예를 들면, 노드 7과 노드 10 간의 DF는 0.67을 나타낸다. 실제 MCE 운영 시에는 상기 정의한 FLIST의 요소들에 기반으로 노드 간의 호출 등의 활동을 모니터링하여 계산한다.

도 8의 DF 테이블을 이용하여 상기 제시된 클러스터링 알고리즘을 적용하였고, 3번의 Iteration(반복)에 걸쳐서 클러스터링이 수행되었다. 첫 Iteration의 결과는 Centroid 노드인 1, 3, 15번을 기준으로 다음 표와 같은 클러스터링 결과가 도출되었다. 전체 MCE의 최적화를 나타내는 QoMCE는 0.26로 계산되었다.

이 클러스터링의 결과를 기반으로 각 클러스터에 대해서, 표 3의 라인 10번에 따라 Centroid가 업데이트된다. 즉 한 클러스터에 속한 여러 노드들 중에서 평균 DF가 최소인 노드가 새로운 Centroid가 된다. 예를 들면, CLUSTER2 에 속한 6개의 노드들에 대한 평균 DF를 계산한 결과는 다음과 같다. 그 결과 평균 DF 값이 0.23인 노드 #18이 새로운 Centroid가 된다.

이러한 과정을 거처 새로운 3개의 Centroid 노드는 {1, 18, 14}가 결정되었고, 두 번째 Iteration이 적용되며 그 결과는 다음과 같다. 전체 최적화 정도인 QoMCE는 0.20으로서 첫 Iteration때의 0.26보다 줄어들었고, 이는 클러스터링이 더 최적화 되었음을 나타낸다.

두 번째 클러스터링을 결과를 기반으로 새로운 3개의 Centroid는 {13, 18, 14}로 업데이트 되었으며, 세 번째 Iteration을 적용하였고, 세 번째 클러스터링의 결과는 다음의 표와 같다.

이 결과를 기반으로 새로운 Centroid를 구했으나, 기존 13, 18, 14 보다 평균 DF가 낮은 노드가 없으므로 클러스터링은 종료된다. 세 번에 Iteration을 걸친 클러스터링 결과를 종합하면 도 9와 같다.

도 9에서, 수평 축의 1, 2, 3은 Iteration(반복) 번호를 나타내며, 수직 축은 최적화 정도를 나타내는데, 클러스터와 MCE 수준의 최적화 정도를 0에서1의 범위 내에서 표현한다. 클러스터링 Iteration 1, 2, 3은 0.26, 0.2, 0.17의 순서대로 점차 줄어듦을 볼 수 있는데, 0에 가까운 값을 가질수록 효율성이 향상됨을 의미한다.

QoCluster(CLUSTER1)의 경우, Iteration 첫 번째보다 두 번째에 0에서 조금 더 멀어지고, QoCluster(CLUSTER2)의 경우, Iteration 첫 번째부터 세 번째까지 점차 최적화 정도가 0에 가까워지는 양상을 보인다. QoCluster(CLUSTER3)의 경우, Iteration 세 번째에 오히려 0에서 멀어지는 모습을 보이고 있다. 이렇게 각각의 QoCluster가 Iteration 마다 증가하거나 감소 할 수는 있지만, 최종적으로 QoMCE는 Iteration 이 진행됨에 따라서 점차 0에 가까운 값을 보임으로써 효율성이 향상되고 있음을 알 수 있다.

다음으로, 실험 결과 및 평가로서, 표 6에서 5종류의 실험을 각각 20회 수행한 결과를 정리하면 표 7과 같다.

표 11에 대한 총 5가지 실험을 통해 6가지 관점에서 평가한다.

첫 번째, 클러스터링 적용 여부에 따른 QoMCE 차이이다.

실험 1에서 클러스터링을 적용하지 않고 클러스터가 하나일 경우를 측정하고 실험 2에서는 클러스터링을 적용한 경우를 각각 측정하여 도 10과 같은 결과를 얻었다. 가로축은 실험 횟수, 세로축은 QoMCE를 의미한다.

클러스터링을 하지 않은 실험 1의 경우 QoMCE가 0.27~0.41까지 측정되었으나, 클러스터링을 적용한 실험 2의 경우 QoMCE는 0.11~0.24까지 측정되었다. 이 결과 클러스터링을 적용 여부에 따라서 QoMCE 차이가 크게는 약 4배까지 나는 것을 확인 할 수 있다. 즉 클러스터링을 적용하면 MCE에 존재하는 노드들이 근접한 노드들끼리 클러스터링 되어 효율성이 증가 하게 될 것을 예상할 수 있다. 이는 도 10을 참조하면 알 수 있다.

두 번째, 최초 클러스터 관리자 노드(Centroid Set) 결정에 대한 차이이다.

실험 2와 실험 3에서는 동일한 노드 20개를 3개의 클러스터로 클러스터링 할 때 최초 Centroid set에 따라서 어떤 차이가 있는지 평가한다. 각 실험 결과 측정된 QoMCE는 실험 2가 0.17, 실험 3이 0.18이다. 이 수치는 각각 동일한 Centroid Set을 가지고 20회씩 측정한 결과의 평균값으로서, 매 실험마다 난수(Random Number)를 바탕으로 결과를 측정하기 때문에 값이 달라질 수 있다. 하지만 본래 k-means 알고리즘은 최초 k를 무엇으로 선정하는지에 따라서 결과가 달라진다. 본 발명에서 제안한 클러스터링 방법도 역시 k에 해당하는 Centroid 선정에 따라서 결과는 달라질 수 있지만, 어떠한 노드가 Centroid로 선정되더라도 QoMCE를 감소시켜 MCE를 최적화하도록 하여 k-means의 단점을 일부 보완하고 있다.

세 번째, MCE의 NumNodes에 따른 QoMCE 차이이다.

실험 3과 실험 4를 통해 MCE에 클러스터링을 적용할 때 NumNodes가 어떤 영향을 미치는지 차이를 확인한다. 두 실험에 대해서 측정된 QoMCE를 보면 실험 3은 0.18, 실험 4는 0.23으로서 0.05정도의 차이를 보인다. 특히, 실험 4의 표준 편차는 0.018로서 실험 3의 0.038보다 0.020만큼 작게 측정되었는데, 이는 실험 4가 실험 3에 비해서 결과 값이 비교적 고르게 산출 되었다는 의미이다. 실험 3에 비해 실험 4에서의 QoMCE가 증가한 이유는 NumNodes 증가로 인해서 각 클러스터에 대한 SizeCluster가 증가하여, 동시에 QoCluster도 증가한 것이다. 즉 NumNodes의 증가는 QoCluster의 값을 증가시켜 MCE가 관리해야 할 노드가 늘어나서 QoMCE를 증가시키는 결과를 가져온다.

네 번째, MCE의 NumClusters에 따른 QoMCE 차이이다.

실험 4와 실험 5를 통해서 MCE에 클러스터링을 적용할 때 클러스터링 개수가 어떤 영향을 미치는지 차이를 확인한다. 실험 4와 실험 5는 동일한 노드를 각각 3개와 10개로 클러스터링 할 때 차이를 보이고 있다. QoMCE가 실험 4는 0.23이지만 실험 5는 0.08로서 약 3배 차이가 난다. NumClusters의 분명한 상관 관계를 확인하기 위해 NumClusters를 1부터 10까지 증가 시켰을 때 QoMCE를 측정하는 실험을 추가적으로 수행하였고, 도 11은 이에 대한 결과를 보여준다.

도 11에서 MCE에 클러스터링 적용 시 NumClusters가 늘어나면 반비례하여 QoMCE가 감소되며 각 클러스터에 존재하는 노드들이 서로 밀접한 관계임을 알 수 있다. 즉 NumClusters가 증가함에 따라서 각 클러스터가 관리해야 할 노드가 줄어들게 되어 QoMCE가 0에 가까워지는 것을 알 수 있다.

다섯 번째, 클러스터링 알고리즘 평가이다.

본 발명에서 제안하는 방법을 사용하여 상기 실험 2의 진행과정을 통해 QoMCE가 클러스터링이 진행 될수록 감소하는 것을 확인하였고, 표 7의 5가지 실험을 통해서 노드 및 클러스터 수가 달라지는 것과 같이 여러 상황에 적용 가능한 방법임을 확인 하였다. 그리고 도 10을 통해서 클러스터링을 적용 하였을 경우 더 효과적인 클러스터링이 이루어짐을 증명하였다.

여섯 번째, MCC 최적화 모델 평가이다.

기존의 k-means 알고리즘을 상기 최적화 평가모델을 이용하여 클러스터링 결과의 최적화 정도를 평가하도록 수정하였고, 실험 환경을 구축하여 QoMCE를 측정하였다. 본 발명에서 제안하는 평가 모델이 각 실험을 통해서 나타난 결과에 의해서 MCE 최적화 정도를 효과적으로 나타낼 수 있음을 확인하였다.

이와 같이 본 발명에서는 중앙 관리자의 관리 오버헤드를 줄이기 위해, MCC에서는 의존성 및 응집도가 높은 노드들을 묶은 관리 단위인 클러스터라는 개념을 소개하였다. 먼저, MCC의 메타모델을 제시하여 클러스터를 지원하기 위한 핵심 요소들을 설명하고, MCC에서 클러스터링이 실행되는 6개의 활동으로 구성된 프로세스를 제시하였다. 그리고 동적 클러스터링을 구성하는 기준인 논리적 거리를 계산하는 메트릭을 정의하였고, 각 메트릭을 계산하는 방법도 정의하였다. 그리고 논리적 거리를 이용하도록 k-means 을 수정하여 MCC 클러스터링을 구성하는 방법을 제안하였으며, 클러스터링 결과가 최적으로 진행되었는지를 평가하는 2개의 MCC 최적화 평가 메트릭을 정의하였다. 마지막으로 실험을 통해, 클러스터링을 통해 관리 성능이 향상되며, 제시된 알고리즘을 통해 최적화된 클러스터링이 구성됨을 확인하였다. 본 발명에서 제시된 방법을 이용하여 클러스터링을 최적화 상태로 구성함으로써, MCC 의 품질 관리 문제를 해결함과 동시에 관리 오버헤드를 줄이면서 효율적으로 품질 관리를 할 수 있다.

이상의 설명에서 본 발명은 특정의 실시 예와 관련하여 도시 및 설명하였지만, 특허청구범위에 의해 나타난 발명의 사상 및 영역으로부터 벗어나지 않는 한도 내에서 다양한 개조 및 변화가 가능하다는 것을 이 기술분야에서 통상의 지식을 가진 자라면 누구나 쉽게 알 수 있을 것이다.

1: 모바일 클라우드 환경(MCE) 2, 11: 클러스터 3, 12: 노드 4: MCE 관리자 5: 노드 관리자 6: 클러스터 관리자 7: 중앙 관리자 13: OD 플랫폼 14: 미들웨어 15: 애플리케이션 16: 클라우드 서비스 17: 모바일 클라우드 매니저 18: MCC 형상 관련 저장소 19: 글로벌 매니저 20: 클러스터 매니저 21: 노드 매니저

Claims (12)

1. (a) 모바일 클라우드 환경(MCE)에서 자율 성능최적화를 위한 글로벌 매니저, 클러스터 매니저 및 노드 매니저로 구성된 모바일 클라우드 매니저가 품질 관리를 위한 태스크를 분할하여 수행함에 있어서, 상기 노드 매니저가 해당 노드의 여러 품질을 측정하여 현재 측정된 품질과 이전에 측정된 품질의 차이가 사전에 정의된 임계치보다 큰 경우에 노드 매니저는 담당 클러스터 매니저에게 품질 데이터를 전송하는 단계;
   (b) 각 클러스터에 할당되어 있는 상기 클러스터 매니저는 현재 품질이 안정한 수준에 있는지 아닌지를 평가하여, 현재 품질이 불안정한 상태인 경우 클러스터 수준의 품질 향상 계획을 수립하는 단계, 및
   (c) 상기 클러스터 매니저는 설정된 계획에 따라 클러스터 수준의 품질을 안정화시키는 활용을 수행한 후 수정된 형상 정보를 클러스터 형상 관련 저장소에 업데이트 하는 단계를 포함하고,
   상기 단계(b)에서,
   (b-1) 상기 모바일 클라우드 환경(MCE)에서 품질 관리를 위한 수정된 형상 정보를 최적화하기 위하여, 품질 관리 프로세스를 수행하면서 여러 결과가 수집되어 저장된 정보를 형상 관련 저장소로부터 클러스터 간 결합도 및 응집도를 계산하기 위한 정보와 클러스터 내의 시간 및 자원 효율성 정보를 획득하는 단계;
   (b-2) 상기 수집된 정보로부터 클러스터 간 응집도 및 결합도, 각 클러스터의 시간 및 자원 효율성이 미리 정의한 임계치보다 낮으면, 현재 클러스터링을 다시 구성해야 할 필요성이 있다고 판단하고, 클러스터링이 수행되는 동안에 특정 애플리케이션과 구독한 서비스 간의 논리적 근접도 값이 변경되면 클러스터링은 변경된 정보로 다시 수행되어야 하기 때문에 이를 방지하지 위하여 클러스터링을 수행하는데 필요한 요소들에 대한 Lock을 획득하는 단계, 및
   (b-3) 상기 Lock을 획득하면, 클러스터링 알고리즘을 수행하여 현재 상황에 최적화된 클러스터링을 구성하고, 글로벌 형상 관리 저장소와 클러스터 형상 관리 저장소에 각각 변경된 형상 정보를 업데이트 하는 단계를 더 포함하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
2. 제1항에 있어서, 상기 클러스터 형상 관련 저장소에서 관리하는 정보는 해당 클러스터에 포함된 노드에 대한 스펙 정보, 노드들에 설치된 애플리케이션 및 서비스 기능성 정보, 품질 데이터 히스토리 및 기능 호출 히스토리 정보를 포함하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
3. 제1항에 있어서, 상기 단계(b)에서,
   현재 발생된 문제를 해결하기 위한 클러스터 수준의 품질 향상 계획을 수립하지 못하는 경우에 글로벌 매니저에 위임되어 설정된 계획에 따라 글로벌 수준의 품질을 안정화시키는 활용을 수행한 후 수정된 형상 정보를 글로벌 형상 관련 저장소에 업데이트 하는 단계를 더 포함하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
4. 삭제
5. 제1항에 있어서, 상기 (b-2)에서,
   논리적 근접도를 구하기 위한 함수(Distance Function, DF)로 정의되는 요소 목록(Factor List, FLIST)은,
   해당 노드가 MCE 환경에 등록될 때 형상 관리 저장소에 저장된 값으로 맵 서비스를 이용하여 측정되는 두 노드 간 물리적인 거리(Geographical Direct Distance, GDD)(단위: Km)로 표현되는 FLIST[1]과,
   상기 GDD는 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, MAX_GDD 는 MCE의 형상 관련 저장소에 저장된 가장 큰 GDD 값이고, 최초의 MAX_GDD 는 관리자에 의해 등록이 되며 이후 새로운 MAX_GDD 가 등록될 때마다 이 값으로 업데이트 되며, GDD_norm 는 1에 가까운 값일수록 물리적인 두 노드 사이가 논리적으로 멀리 떨어져 있음을 나타낸다.)
   해당 노드가 MCE 환경에 등록될 때 형상 관련 저장소에 저장된 값으로, 네트워크 관리자로부터 얻을 수 있는 노드 간 선언된 네트워크 대역폭(Declared Network Bandwidth, DNB)(단위: Mbit/sec)로 표현되는 FLIST[2]와,
   상기 DNB는 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, MAX_DNB 는 MCE의 형상 관련 저장소에 등록된 가장 큰 DNB 값이고, 새로운 MAX_DNB 가 등록될 때마다 이 값으로 업데이트 되며, DNB_norm 은 1에 가까운 값을 가질수록 두 노드 간의 대역폭이 좁아 논리적으로 멀리 떨어져 있음을 나타낸다.)
   NMS(Network Management System) 또는 MCE 형상 관련 저장소의 로그를 통해서 얻을 수 있는 노드 간 측정된 네트워크 대역폭(Measured Network Bandwidth, MNB)(단위: Mbit/sec)로 표현되는 FLIST[3]과,
   상기 MNB는 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, Size(TX_i)는 해당 기간 동안 i번째로 전송된 데이터의 크기이고, TransTime(TX_i)는 TX_i 가 전송되는 동안 소요되는 시간이며, NumDataTXs는 관찰한 기간 동안 발생한 전체 데이터 전송횟수이다.)
   상기 MNB는 일정 기간 동안 발생한 전체 데이터 전송 속도의 평균값으로, 이를 이용하여 정규화된 값인 MNB_norm 은 다음의 수학식으로 측정된다.
   

   

   
   (여기서, MAX_MNB 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 MNB 값이고, 데이터 전송 관련 기록이 없는 경우, 첫 번째 데이터 전송에 대한 Size(TX₁)/TransTime(TX₁) 값이MAX_MNB 가 되며, 이후 새로운 MAX_MNB 가 측정될 때마다 이 값으로 업데이트 되고, MNB_norn 은 1에 가까운 값을 가질수록 두 노드 간 데이터 전송 시간이 길어짐을 나타내며, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 나타낸다.)
   얼마나 자주 애플리케이션이 서비스 인스턴스를 호출하는지에 대한 값으로, MCE 형상 관련 저장소의 로그를 통해서 얻을 수 있는 노드 간 호출 빈도(Frequency of Invocations, FOI)(호출 횟수가 정수로 표현됨)로 표현되는 FLIST[4], 및
   상기 FOI는 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, App_i 는 i번째 애플리케이션이고, S_jk 는 j번째 서비스 타입의 k번째 인스턴스이며, NumInv(App_i , S_jk)는 특정 기간 동안의 App_i 와 S_jk 간의 호출 빈도수이다.)
   상기 FOI 값은 일정 기간 동안 발생한 애플리케이션과 서비스 간에 발생한 호출 횟수를 이용하여 측정되고, 이를 이용하여 정규화된 값인 FOI_norm 은 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, MAX_FOI 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 FOI 값이고, 새로운 MAX_FOI 가 측정될 때마다 이 값으로 업데이트 되며, FOI_norm 은 1에 가까운 값을 가질수록 두 노드 간 호출이 드물게 일어남을 나타내고, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 나타낸다.)
   일정 시간 동안의 서비스 호출시 측정되는 반응 시간의 평균값으로, 노드 간 평균 반응 시간(Average Response Time, ART)(단위: Millisecond)로 표현되는 FLIST[5]
   상기 ART는 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, RT(Inv(App_i, S_jk))_x)는 두 노드 간 x번째 호출의 반응 시간이다.)
   상기 ART 값은 일정 기간 동안 발생한 App_i 와 S_jk 간의 호출에 대한 응답 시간의 평균값으로, ART_norm 은 다음의 수학식을 이용하여 측정된다.
   

   

   
   (여기서, MAX_ART 는 MCE 형상 관련 저장소에서 관리하고 있는 가장 큰 값이고, 서비스 호출 기록이 없는 경우, RT(Inv(App_i, S_jk))₁) 값이 MAX_ART 가 되며, 이후 새로운 MAX_ART 가 측정될 때마다 이 값으로 업데이트 되고, ART_norm 는 1에 가까운 값을 가질수록 두 노드 간 반응시간이 오래 걸린다는 것을 나타내며, 이는 곧 두 노드가 논리적으로 멀리 떨어져 있음을 나타낸다.)
   을 포함하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
6. 제5항에 있어서,
   상기 논리적 근접도를 구하기 위한 함수(Distance Function, DF)는 두 노드 간 논리적 근접도를 나타내기 위하여 NODE _i 와 NODE _j 가 논리적으로 얼마나 가까운지를 나타내는 값을 구하되, 상기 FLIST를 구하고 정규화된 값들을 가중치를 적용하여 합한 이후에 FLIST의 유형 개수로 나누면 두 NODE _i 와 NODE _j 의 논리적 근접도를 DF로 나타낼 수 있고, 상기 DF를 구하기 위하여 다음의 수학식,
   

   

   
   을 이용하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
7. 제6항에 있어서, 상기 DF는 도메인마다 FLIST의 중요도가 다르기 때문에 FLIST마다 각각 다른 가중치(W _i )를 지정하여 논리적 근접도 DF를 계산하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
8. 제1항에 있어서, 상기 단계(b-3)에서,
   상기 클러스터링 알고리즘은 MCC에서의 k-means가 적용되고,
   k-means 클러스터링 알고리즘은,
   1 Begin
   2 // 초기화
   3 Enter 'k'
   4 // 가중치를 적용하여 최초 Centroids 선정
   5 Enter a set of node, NODE = {x1, x2, …, xn}.
   6 Enter a set of initial k centroids,
   CEN_NODE = { xi I xi ∈ NODE } and n(CEN_NODE) = k
   7 Calculate logical closeness between nodes in NODE
   8 // 메인루프
   9 Repeat
   10 Assign xi to the cluster with the closet centroid.
   11 // 현재 Centroid 가 최적인지 평가하여 업데이트
   12 Update the centroid of each cluster.
   13 Until the centroids do not change.
   14 // 출력
   15 Return the resulting set of clusters, {C1, C2, …, Ck}.
   16 End
   을 포함하되,
   상기 k-means를 개선하기 위하여 라인 6에 의하여 할당된 NODE 중에서 k가 선정되고, 라인 7에서 노드 간 근접도를 산출하여 산출된 근접도를 바탕으로 라인 12에서 최적의 Centroid를 탐색하여 업데이트 하여 해당 클러스터의 최적화 정도를 측정하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
9. 제8항에 있어서, 최초 노드 선정 때에 가중치를 바탕으로 선정하거나 선정된 노드를 반복적으로 평가하여 최적의 노드를 찾도록 하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
   
10. 제8항에 있어서, 상기 k-means 클러스터링 알고리즘을 위한 설계 모델은,
    클러스터 관리자가 수행하는 전체 태스크를 관리하는 ClusterMgrCtrl 클래스와, 클러스터링에 관련된 일을 수행하는 ClusterCreator 클래스, 그리고 논리적 거리를 계산하는 QoS 클래스, Node 클래스 및 Cluster 클래스를 포함하고,
    상기 ClusterMgrCtrl는 클러스터링을 위해서 Node를 MCE 형상 관련 저장소로부터 데이터를 가져와 할당하도록 하고, QoS 클래스를 통해서 노드 간 상호작용 빈도 및 반응 시간을 평가하며, 클러스터링을 위한 노드가 할당되면 ClusterCreator에 의해서 클러스터링을 위한 초기화가 진행되고, k가 임의 노드로 정해지고 k와 노드에 의해 DF 테이블을 생성하며, 이후 가장 근접한 클러스터를 탐색하고, 탐색된 클러스터에서 가장 최소의 DF값을 가지고 있는 노드로 Centroid를 업데이트 해주며, 더 이상의 최소 DF값을 가지는 노드를 찾을 수 없을 때까지 반복하여 클러스터링 하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
    
11. 제10항에 있어서, 상기 클러스터링과 각 클러스터의 노드를 평가하기 위하여 지정된 노드와의 논리적 근접도를 바탕으로 그룹화하기 위한 소스코드 1은,
    1 private static void clusterNodes(int nodeID, Node nodes[ ], DF DFTable[ ] [ ],
    HashMap<Integer, ArrayList<Node>> clusters) throws
    CloneNotSupportedException {
    2 ArrayList<Node> list = null;
    3 DF df = null;
    4 Node currentNode = null;
    5 currentNode = (Node) nodes[nodeID].clone();
    6 Object[ ] key = cluster.keySet().toArray();
    7 DF dfList[ ][ = new DF[clusters.size()];
    8 for (int i = 0; i < cluster.size(); i++){
    9 df = DFTable[nodeID][(Integer)key[i]];
    10 dfList[i] = DFTable[nodeID][(Integer)key[i]];
    11 }
    12 // 최적 중앙 노드 검색
    13 DF minDF = findClosestCluster(dfList);
    14 // 클러스터 선정 및 노드 추가
    15 list = clusters.get(minDF.getClusterManagerNode().getld());
    16 if(df.getDf() != null) {
    17 currentNode.setDf(minDF.getDf(());
    18 list.add(currentNode);
    19 }
    로서,
    상기 13라인에서 현재 클러스터 내 모든 노드들의 DF중에서 최소 DF를 찾고, 15~18라인을 통해 탐색된 DF를 통해 클러스터를 선택하여 현재 노드를 선택된 클러스터에 추가하는 것을 포함하고,
    상기 클러스터링 이후, 지정된 클러스터 관리자 노드가 최적인지 다른 노드들의 평균 DF와 비교하기 위한 소스코드 2는,
    1 public DF evaluateNodes(DF DFTable[ ] [ ], Node nodes[ ]) {
    2 DF minDF = null;
    3 DF dfList[ ] = new DF[DFTable.length];
    4 // 평균 DF값 측정
    5 for (int i = 0; i < nodes.length; i++){
    6 DF df = new DF();
    7 df.setDf(calculateAVGDF(i, DFTable));
    8 df.setClusterManagerNode(nodes[i]);
    9 dfList[i] = df
    10 }
    11 // 최적 중앙 노드로 Centroid 업데이트
    12 minDF = updateCentroid ( dfList );
    13 return minDF;
    14 }
    로서,
    상기 5~10라인을 통해 현재 클러스터의 각 노드마다 평균 DF를 구하고, 12라인을 통해 평균 DF가 최소인 노드를 탐색하며, 탐색된 노드가 해당 클러스터의 최적의 클러스터 관리자로 선택하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.
    
12. 제8항에 있어서, 상기 MCC의 최적화 정도는 클러스터 수준의 최적화 정도와 MCE 수준의 최적화 정도로 평가하여 측정하되,
    클러스터의 최적화 정도는 논리적으로 근접한 해당 클러스터의 응집도를 평가하기 위하여, 다음의 수학식,
    

    

    
    이 적용되되, 논리적으로 가까운 노드들끼리 클러스터를 구성할수록 QoCluster는 0에 가까운 값에 반환하고,
    MCE 수준의 최적화 정도는 현재 구성된 클러스터들의 결합도를 평가하기 위하여 다음의 수학식,
    

    

    
    이 적용되되, 클러스터 내의 응집도가 높고 클러스터 간 결합도가 낮을수록 QoMCE는 0에 가까운 값을 반환하는 모바일 클라우드 환경에서 클러스터링을 이용한 자율 성능 최적화 방법.

Images