KR102423038B1 - 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법 및 장치 - Google Patents

Abstract

본 발명의 일 양태는 분석 정보 수집 장치에서의 대용량 네트워크 모니터링을 위한 실시간으로 패킷 데이터를 수집하는 방법을 개시하고 있다. 상기 방법은, 분석 대상이 되는 복수 개의 패킷들을 실시간으로 분석함에 의해 생성되는 트랜잭션 블록(TR Block: TRansaction Block)을 수신하는 단계(여기서, 상기 트랜잭션 블록은 제 1 시간 간격으로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임), 상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하는 단계, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하는 단계 및 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 단계를 포함한다.

Description

대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법 및 장치{REAL-TIME PACKET DATA COLLECTION METHOD AND APPARATUS FOR MASS NETWORK MONITORING}

본 발명은 데이터 수집 방법에 관한 것으로, 보다 상세하세는, 대용량 네트워크의 실시간 모니터링을 위해 패킷 데이터 및 패킷 분석 결과를 효율적으로 수집하는 방법에 관한 것이다.

네트워크는 통신 링크 및 통신링크에 접속된 통신능력을 가진 다양한 장치들을 전반적으로 포함한다. 여기서, 네트워크와 관련된 장치들은, 컴퓨터, 주변장치, 라우터, 저장장치, 및 프로세서와 통신 인터페이스를 갖는 여러 전기제품을 포함한다. 여기서, "장치"라는 용어는 전형적으로 논리 장치들 혹은 기능성 및 데이터를 처리 및 교환할 수 있는 능력을 갖는 다른 장치들을 포함하며, 가정용 장치들뿐만 아니라 일반 목적의 컴퓨터들을 포함할 수 있다.

전통적인 네트워크 시스템들은 사용자가 사용하는 클라이언트 장치와 웹 사이트와 연관된 다양한 서버 장치들을 포함한다. 일반적으로 클라이언트 장치는 웹 사이트를 이용하기 위해, 특정 IP 주소를 갖는 서버에 접속요청을 하고, 대기시간을 거쳐 접속한다. 이때, 다수의 사용자에 의해 다수의 클라이언트 장치가 특정 시점에 몰려서 서버에 접속하는 경우, 병목현상(bottleneck)에 의해 서버와 연관된 네트워크 서비스의 성능이 저하될 수 있다. 서비스 성능 또는 품질 문제 발생시 사용자는 지연으로 인해, 기다리는 시간을 늘어서 서비스의 이용률이 떨어지게 되고, 이는 생산성 및 매출의 감소로 이어진다. 또한, IT 운영비용 증가가 발생하고, 서버의 운영자 및/또는 관련 비즈니스의 경영자는 기업의 경쟁력 하락이라는 좋지 않는 결과를 맞게 될 수 있다.

따라서, 성능 저하의 원인을 신속히 파악하고, 이에 대한 대응이 최대한 빠르게 이루어져야 한다. 하지만, 이러한 성능 저하의 원인이 어디에 있는지를 명확히 파악하는 데에는 마땅한 서비스가 없어서 적절한 대응이 이루어지지 못하는 실정이다. 이로 인해, 성능 개선의 골든 타임(golden time)을 놓치게 되는 문제점이 있다. 특히, 대용량의 데이터를 취급하는 환경에서 이를 실시간으로 처리하는 것은 더욱 어렵다.

추가적으로, 클라우드(cloud) 환경에서는 다수의 서버 및/또는 서버 역할을 수행하는 다수의 인스턴스(instance)들이 서로 연계하여 동작하기 때문에, 특정 부분에서의 성능 저하를 파악하는 것은 어렵다는 문제점이 있다. 또한, 클라우드 서비스 제공자가 이를 모니터링하는 별도의 장치를 통해 관련 정보를 제공하는 것을 쉽게 동의하지 않기 때문에, 개별 서버 및/또는 개별 인스턴스들의 네트워크 성능을 실시간으로 모니터링하기는 매우 어렵다는 문제점이 있다.

더욱이, 대용량 네트워크를 모니터링할 때, 실시간으로 송수신되는 패킷 및 패킷을 분석한 정보를 수집 및 저장할 필요가 있는데, 이를 효율적으로 수집/저장하기에는 너무 많은 저장 공간이 필요하다. 이에, 이러한 대용량의 네트워크의 데이터를 효율적으로 수집 및 저장하지 못하는 문제점이 있다. 네트워크의 패킷을 저장하지 못하면, 네트워크의 성능 또는 보안 측면에서 문제 발생 후, 시간을 되돌려 문제의 원인을 역추적하는 것이 어렵게 되는 문제점이 있다.

상술한 문제점을 해결하기 위한 본 발명의 일 양태에 따른 목적은 대용량 데이터를 취급하는 네트워크 서비스의 성능을 모니터링하고 이를 효율적으로 통합 관리하기 위한 실시간 패킷 데이터 수집 및 저장 방법을 제공하는 것이다.

상기한 목적을 달성하기 위한 본 발명의 일 양태에 따른, 분석 정보 수집 장치에서의 대용량 네트워크 모니터링을 위한 실시간으로 패킷 데이터를 수집하는 방법은, 분석 대상이 되는 복수 개의 패킷들을 실시간으로 분석함에 의해 생성되는 트랜잭션 블록(TR Block: TRansaction Block)을 수신하는 단계(여기서, 상기 트랜잭션 블록은 제 1 시간 간격으로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임), 상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하는 단계, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하는 단계 및 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 단계를 포함할 수 있다.

상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하는 단계는, 상기 정렬된 트랜잭션 블록 내의 패킷이 트랜잭션 시작을 위한 동기 신호(Syn) 및 트랜잭션 종료를 위한 종료 신호(Fin)를 포함하는지 확인하는 단계 및 동기 신호와 종료 신호를 조합함에 의해 완성된 트랜잭션을 생성하여 트랜잭션 단위로 구분하는 단계를 포함할 수 있다.

동기 신호와 종료 신호가 모두 존재하는 패킷은 상기 레포지토리에 바로 저장할 수 있다.

동기 신호만 있는 패킷은 상기 레포지토리에 저장하면서 템포러리 리스트(temporary list)에도 함께 저장하되, 종료 신호가 있는 패킷이 수신될 때까지 대기시킬 수 있다.

상기 동기 신호만 있는 패킷을 대기시키는 상태에서 타임아웃(Timeout) 임계 시간이 도래했음에도 상기 종료 신호가 있는 패킷이 수신되지 않을 때, 상기 동기 신호만 있는 패킷을 실패(Fail) 처리하고 상기 템포러리 리스트에서 삭제할 수 있다.

동기 신호가 없는 패킷은 상기 템포러리 리스트에서 매칭되는 패킷을 찾아서 업데이트(update)하되, 상기 동기 신호가 없는 패킷이 종료 신호를 포함하고 있을 때, 상기 템포러리 리스트에서 삭제할 수 있다.

상기 제 1 시간은 8초 내지 12초이고, 상기 타임아웃 임계시간은 55초 내지 65초일 수 있다.

상기 트랜잭션 블록은 복수 개의 패킷 분석 모듈로부터 실시간으로 수신되되, 상기 트랜잭션 블록을 수신 시간으로 정렬할 때, 상기 복수 개의 패킷 분석 모듈 각각과 연관된 서버를 구분하여 정렬할 수 있다.

상기 레포지토리는 제 2 시간 단위의 트랜잭션 블록 정보를 저장하는 복수의 디렉토리(directory)들로 구성되되, 상기 제 2 시간은 상기 제 1 시간보다 긴 시간일 수 있다.

제 2 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리에 저장되어질 현재 저장 대상 트랜잭션 블록들 중 상기 제 1 디렉토리에 저장된 기 저장 트랜잭션 블록들 중 어느 하나의 트랜잭션과 연관된 트랜잭션 블록을 상기 기저장 트랜잭션 블록들 중 어느 하나와 연관시키기 위해, 상기 제 1 디렉토리는 열려 있는 상태로 두되, 상기 제 1 디렉토리는 상기 제 2 디렉토리 바로 이전 디렉토리일 수 있다.

상기 제 1 디렉토리는 상기 제 2 디렉토리에 대한 저장 처리가 완료된 이후, 제 3 디렉토리에 저장을 개시할 때, 닫힌 상태로 전환시키고, 상기 제 3 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리는 열려 있는 상태로 두되, 상기 제 3 디렉토리는 상기 제 2 디렉토리 바로 이후 디렉토리일 수 있다.

상기 제 1 시간은 수 초(seconds) 단위 시간이고, 상기 제 2 시간은 분(minute) 단위 시간일 수 있다.

상기 복수 개의 패킷들은 제 1 엔티티(entity)와 제 2 엔티티 간에 송수신되는 패킷들을 포함하고, 상기 제 1 엔티티 및 상기 제 2 엔티티 중 적어도 하나는 컴퓨팅 장치 또는 상기 컴퓨팅 장치에서 실행되는 애플리케이션 인스턴스(application instance)를 포함할 수 있다.

상기 트랜잭션 블록은, (i) 상기 적어도 하나의 트랜잭션들에 포함된 각각의 트랜잭션의 한 세트의 요소 정보를 포함하는 트랜잭션 리스트(TR List) 정보, (ii) 상기 트랜잭션 리스트 정보와 연관된 텍스트들의 목록인 텍스트 리스트(Text List) 정보 및 (iii) 상기 제 1 시간 동안의 네트워크 성능 지표의 통계 정보를 포함할 수 있다.

상기한 목적을 달성하기 위한 본 발명의 다른 양태에 따른, 대용량 네트워크 모니터링을 위해 실시간으로 패킷 데이터를 수집하는 장치는, 분석 대상이 되는 복수 개의 패킷들을 실시간으로 분석함에 의해 생성되는 트랜잭션 블록(TR Block: TRansaction Block)을 수신하는 리시버(receiver)(여기서, 상기 트랜잭션 블록은 제 1 시간 간격으로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임) 및 상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하고, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하여 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 프로세서를 포함할 수 있다.

상기한 목적을 달성하기 위한 본 발명의 또 다른 양태에 따른, 대용량 네트워크 모니터링을 위한 실시간 패킷 분석을 수행하는 패킷 분석 시스템은, 분석 대상이 되는 복수 개의 패킷들을 수집하여, 트랜잭션 블록(TR Block: TRansaction Block) 을 생성하여 실시간으로 분석 정보 수집 장치로 전송하는 패킷 분석 장치(여기서 상기 트랜잭션 블록은 제 1 시간 간격으로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임), 상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하고, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하여 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 분석정보 수집장치 및 상기 트랜잭션 블록과 관련된 정보를 저장하고 있는 레포지토리를 포함할 수 있다.

본 발명의 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 장치 및 방법에 따르면, 대용량 패킷이 송수신되는 네트워크 환경(클라우드 환경 포함)에서 네트워크 성능 문제에 신속하게 대응하게 하는 효과가 있다.

또한, 네트워크 성능 또는 보안 측면에서 문제 발생 이후, 문제 발생 시점의 데이터를 추출하여, 문제의 원인을 명백하게 규명하는 것을 지원하는 효과가 있다.

도 1은 본 발명의 일 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법이 적용되는 시스템을 나타낸 개념도,
도 2는 본 발명의 다른 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법이 적용되는 클라우드 환경을 나타낸 개념도,
도 3은 본 발명의 또 다른 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법이 적용되는 시스템을 나타낸 개념도,
도 4는 패킷 분석 모듈에서 생성되어 분석 정보 수집 장치로 제공되는 트랜잭션 블록의 구성을 구체적으로 나타낸 개념도,
도 5는 본 발명의 일 실시예에 따른 분석 정보 수집 장치의 구성을 구체적으로 나타낸 상세블록도,
도 6은 도 5의 수집 모듈에서 10초 단위의 트랜잭션 블록으로부터 트랜잭션을 구분하는 방법을 설명하기 위한 개념도,
도 7은 수집 모듈에서 트랜잭션 단위로 구분하여 레포지토리에 트랜잭션 블록 데이터를 저장하는 방법을 설명하기 위한 개념도,
도 8a 및 도 8b는 동기 신호(syn)와 종료 신호(fin)를 포함하는 패킷을 이용하여 개별 트랜잭션을 구분하는 방법을 설명하기 위한 패킷 구분 테이블 및 이에 대한 처리 흐름도,
도 9는 도 6 내지 도 8b의 방법을 이용하여 복수의 패킷 분석 모듈로부터 수신되는 트랜잭션 블록을 레포지토리에 저장하는 과정을 예시적으로 나타낸 도면,
도 10은 본 발명의 일 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 저장 방법에 따라 트랜잭션 블록을 저장하는 레포지토리의 구성을 나타낸 개념도,
도 11은 도 10의 레포지토리에 10초 통계, 1분 통계, 10분 통계, 1시간 통계 및 1일 통계를 저장하는 방법을 설명하기 위한 개념도,
도 12는 레포지토리에 트랜잭션 데이터와 함께 저장되는 인덱스 데이터를 설명하기 위한 개념도,
도 13은 도 12의 인덱스를 이용하여 데이터 검색을 수행할 때, 검색 요청 및 그에 따른 필터링 과정을 설명하기 위한 개념도,
도 14는 도 4의 트랜잭션 블록 내의 트랜잭션 리스트의 상세 요소 정보의 구성을 구체적으로 나타낸 테이블,
도 15는 도 4의 트랜잭션 블록 내의 텍스트 리스트(text list)의 구성을 구체적으로 나타낸 테이블,
도 16은 도 4의 트랜잭션 블록 내의 통계 정보의 구성을 구체적으로 나타낸 테이블이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다.

그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제 1, 제 2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제 1 구성요소는 제 2 구성요소로 명명될 수 있고, 유사하게 제 2 구성요소도 제 1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.

도 1은 본 발명의 일 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법이 적용되는 시스템을 나타낸 개념도이다. 도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 시스템은 클라이언트 단말(110-1~110-N), 네트워크(120), 서버단(130-1~130-N), 패킷 분석 모듈(140-1~140-N) 및 분석 정보 수집 장치(150)를 포함할 수 있다.

도 1을 참조하면, 클라이언트 단말(110-1~110-N)은 네트워크(120)를 통해 특정 웹 사이트(web site) 및/또는 웹 애플리케이션(web application)에 접속한다. 이때, 접속은 상기 웹 사이트 및/또는 웹 애플리케이션과 연관된 URL(Uniform Resource Locator)을 매개로 이루어질 수 있다. 상기 URL로 접속하면, 이를 해당 주소에서의 동작을 실행하는 서버단(130-1~130-N)과 통신한다. 클라이언트 단말(110-1~110-N)은 웹 브라우저를 통해 특정 웹 페이지에 접속하여 원하는 페이지 또는 애플리케이션의 실행을 요청한다. 상기 요청은, HTML 문서와 같은 정적인 콘텐츠뿐만 아니라, 동영상, 오디오와 같은 멀티미디어 콘텐츠, 및/또는 기타 다른 애플리케이션의 실행을 포함할 수 있다.

본 발명의 일 실시예에 따르면, 클라이언트 단말(110-1~110-N)은 사용자에 의해 동작하고, 통신 기능(인터넷 접속 및 웹 브라우저 실행 기능 포함) 및 데이터 처리 기능을 포함하는 임의의 장치를 포함할 수 있다. 클라이언트 단말(110-1~110-N)은, 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 고정 또는 이동 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 셀룰러 전화, 무선 기기(wireless device), 무선 통신 디바이스, 무선송수신유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일, 모바일국, 개인 휴대 정보 단말(personal digital assistant; PDA), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 소비자 전자기기(CE) 또는 다른 용어들로서 지칭될 수 있다. 클라이언트 단말(110-1~110-N)의 다양한 실시예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있으나, 이에 한정되는 것은 아니다.

각 클라이언트 단말(110-1~110-N)은 사용자 입력을 수신하기 위한 마우스 및 키보드와 같은 입력 수단들 및 디스플레이 유닛과 같은 출력 수단들을 포함하는 사용자 인터페이스를 포함할 수 있다. 상기 사용자 인터페이스는 사용자에게 정보를 제공하기 위한 그래픽 사용자 인터페이스(GUI: Graphical User Interface)를 포함할 수 있다. 또한, 사용자가 네트워킹된 장치들과 상호작용하기 위한 통신 인터페이스를 포함한다.

네트워크(120)는 유선 및/또는 무선 네트워크를 포함한다. 네트워크(120)는 인터넷(internet)을 포함할 수 있다. 네트워크(120)는 다양하게 접속된 클라이언트 단말(110-1~110-N)과 서버단(130-1~130-N) 간에 데이터를 송신하고 수신하기 위해 물리층(매체)을 제공하는 시리얼 버스를 포함할 수 있다. 여기서 시리얼 버스는 1394 시리얼 버스를 포함할 수 있다. 이는 시간-다중송신(Time-multiplexed) 오디오/비디오(A/V) 스트림 및 표준 아이피(IP: Internet Protocol) 통신(예컨대, IETF REC 2734)을 양쪽 모두 지원할 수 있고, 다만 반드시 이에 한정되는 것은 아니다. 네트워크(120)는 비-1394 네트워크(예컨대, 이더넷 등)도 포함할 수 있다. 또한, 네트워크(120)는 홈 네트워크를 포함할 수도 있다. 각 클라이언트 단말(110-1~110-N)들은 네트워크(120)에서 하나 이상의 서버 장치들(130-1~130-N)과 통신할 수 있다.

서버단(130-1~130-N)은 사용자에게 서비스들을 제공하기 위해 네트워크(120) 자원을 이용하여 사용자들의 요청에 응답한다. 이는 정보(데이터)의 리턴(return)을 포함한다. 또한, 기능의 성능(예컨대, 기계적인 기능) 및 상태의 리턴, 데이터 스트림 및 상태의 리턴, 데이터 스트림의 수용 및 상태의 리턴, 또는 각종 행위에 대한 상태의 저장을 포함한다. 서버단(130-1~130-N)은 그 자신의 하드웨어의 제어를 구현하기 위해, 주문형, 내장형, 제어 프로그램을 포함할 수 있다.

서버단(130-1~130-N)은 특정 웹 사이트 및/또는 웹 애플리케이션과 연관될 수 있고, 각 웹 사이트 및/또는 웹 애플리케이션에서 수행되는 작업과 관련된 연산 및 데이터 관리를 수행한다. 서버단(130-1~130-N)은 클라이언트 단말들(110-1~110-N) 및 다른 서버들(130-1~130-N)과 상호작용할 수 있다. 예시적인 서비스들은 MPEG 소싱/싱킹(sourcing/sinking), 및 디스플레이 서비스를 포함할 수 있다.

서버단(130-1~130-N)은 네트워크(120)를 통해 장치의 명령 및 제어를 위한 인터페이스를 제공하는 인터페이스 데이터(예컨대, HTML, XML, 자바, 자바스크립트, GIF, JPEG, MPEG, 그래픽 파열 또는 의도한 목적에 사용되는 임의의 다른 포맷)와 같은 정보를 처리할 수 있다. 특정 실시예에서, 각 서버들(130-1~130-N)은 그 장치의 명령 및 제어를 제공하는 하나 이상의 하이퍼텍스트 마크업 언어(HTML: Hypertext Markup Language)와 같은 정보를 처리할 수 있다. 서버단(130-1~130-N)은 브라우저 기법을 이용하여 HTML 페이지를 나타내는 인터넷 표준을 사용한다.

본 발명의 실시예에 따르면, 서버단(130-1~130-N)은 웹 서버(130-1), 앱 서버(130-2: APP server), 및 데이터베이스 서버(130-N: DB 서버)를 포함할 수 있다. 다만, 반드시 서버단이 3개 서버의 조합으로만 구성되어야 하는 것은 아니다. 웹 서버(130-1)만 존재하고, 앱 서버(130-2) 및 데이터베이스 서버(130-N)는 존재하지 않는 것도 유효하고, 또는 앱 서버(130-2) 하나만 구성되는 것도 가능하고, 기타 다양한 형태 및 계층의 서버 조합도 가능하다. 서버단(130-1~130-N)을 구성하는 각각의 서버에 대한 설명은 추후 하기로 한다.

서버단(130-1~130-N)은 대용량 패킷을 처리하기 위한 다수의 서버들의 군으로 형성될 수 있다. 경우에 따라, 이는 약 1000여 개가 넘는 대규모 서버 팜(server farm)의 형태로 구성될 수 있다. 이러한 대규모 서버 군에서 송수신되는 패킷들은 그 수가 너무 많기 때문에, 하나의 패킷 분석 장치로는 모든 패킷에 대한 분석이 어렵다. 이 경우, 샘플링(sampling)을 통해 분석을 수행하는 방법도 고려할 수 있지만, 샘플링을 통한 분석 결과는 샘플링의 단위에 따라 그 분석결과의 신뢰도가 달라지는 문제점이 있고, 문제 발생 이후 원인을 추적하는데도 데이터가 띄엄띄엄 존재하기 때문에, 정확한 판단을 할 수 없다는 문제점이 있다.

한편, 클라이언트 단말(110-1~110-N)과 서버단(130-1~130-N)의 장치들은 네트워크(120)를 통해 패킷을 주고받을 수 있다. 본 명세서 상에서는, 이들을 서버와 클라이언트로 구분하지 않고 하나의 개체 또는 엔티티(entity)라고 부를 수 있다.

패킷 분석 장치(140-1~140-N)는 서버단(130-1~130-N)을 구성하는 다수의 서버들 및/또는 클라이언트 간에 송수신되는 패킷들을 분석하여 분석 결과를 분석정보 수집장치(150)로 제공한다. 특히, 상당히 많은 수의 서버들(130-1~130-N)에서의 패킷들을 빠짐없이 모두 분석하기 위해서는, 해당 서버 각각에 대응하는 패킷 분석 장치(140-1~140-N)가 개별 서버(130-1~130-N)에 임베디드된(embedded) 형태로 구성되어 1차적인 패킷 수집 및 분석을 수행하고, 그 결과를 2차적으로 최종 분석하는 분석정보 수집장치(150)로 제공하는 형태가 바람직하다. 즉, 분석을 이원화하여 실시간 분석이 이루어지도록 하는 것이 바람직하다.

이러한 실시예에서, 패킷 분석 장치(140-1~140-N)는 소프트웨어적으로 구성되어, 서버 장치 내에서 하나의 기능블록을 이룰 수 있다. 별도의 하드웨어 장치가 아니기 때문에, 이를 패킷 분석 모듈 또는 모듈이라 부를 수 있다. 패킷 분석 모듈(140-1~140-N)은 대용량 데이터를 처리하는 서버단(130-1~130-N)에서 실시간 분석을 효율적으로 수행하기 위해 임베딩된다. 서버와 모듈 간의 대응관계는 1:1이 적합하나, 1:다(多)의 관계도 가능하다. 예컨대, 둘 이상의 서버들에 대해 하나의 패킷 분석 모듈이 대응될 수도 있고, 그 반대의 경우도 가능하다.

대용량 네트워크에서 송수신되는 다수의 패킷들을 실시간 분석하기 위해, 임베디드된 형태의 모듈(140-1~140-N)은 패킷에 대한 1차 분석 결과를 분석정보 수집장치(150)로 제공하고, 1차 분석 결과를 가지고 2차적으로 분석정보 수집장치(150)가 보다 고차원적인 분석 및 사용자 요청에 대한 응답을 수행한다. 이러한 의미에서, 패킷 분석 모듈(140-1~140-N)은 1차 분석 장치로, 분석정보 수집장치(150)는 2차 분석 장치로 불릴 수 있다. 양자간에는 분석결과를 효율적으로 공유하기 위해, 전체 분석 과정을 분할할 필요가 있다. 그리고, 그 내용을 공유하여 전체적으로 완전한 분석이 이루어지도록 하는 것이 바람직하다. 즉, 분석정보 수집장치(150)는 모듈에서의 1차 패킷 분석 방법 및 분석 과정을 공유한다. 그리고, 1차 분석 결과의 송수신 및 데이터 저장 등 연계된 작업을 효율적으로 처리하기 위해, 서로간에 동기를 맞추는 것이 바람직하다. 즉, 전체적인 패킷 분석을 패킷 분석 모듈(140-1~140-N)과 분석정보 수집장치(150) 간에 분할하여 수행하되, 중복이 최대한 이루어지지 않고 분산하여 패킷에 대한 분석이 이루어질 수 있도록 하는 것이 바람직하다.

패킷 분석 모듈(140-1~140-N)에서는 자신이 삽입된 개별 서버를 대상으로 클라이언트 또는 다른 서버와 주고받은 패킷들에 대한 1차적인 분석을 수행하여 분석정보 수집장치(150)로 제공한다. 분석정보 수집장치(150)는 1차적인 분석에 의해 생성된 개별 트랜잭션 블록들(142)을 수집하여 추가적인 분석 및 분석 결과에 따른 응용(필터링, 경고, 브라우징 등)을 수행한다.

패킷 분석 모듈(140-1~140-N)은 패킷을 직접 수집하여 분석할 수도 있고, 이를 미러링(mirroring)하여 미러링된 패킷을 분석할 수도 있다. 미러링된 패킷이라고 기재되어 있어도, 직접 수집한 패킷을 이용하는 것을 고려할 수 있고 반대의 경우도 고려될 수 있음은 본 발명이 속하는 기술분야의 통상의 기술자에게는 자명한 것이다.

패킷 분석 모듈(140-1~140-N)은 미러링된 패킷에 포함된 각종 정보들(예컨대, 소스 ID(source id), 목적지 ID(destination id) 및 시간 정보(time) 등)을 기반으로 네트워크 서비스의 성능을 나타내는 각종 지표들을 실시간으로 산출할 수 있다. 지표의 산출은 패킷 및/또는 트랜잭션(transaction) 단위로 이루어질 수 있다. 산출되는 지표는 약 30여 가지가 될 수 있다. 모듈(140-1~140-N)은 이를 데이터 블록(data block) 형태로 형성하여 분석정보 수집장치(150)로 제공한다. 이러한 데이터 블록을 트랜잭션 블록(142)이라고 부를 수 있다.

앞서 설명한 바와 같이, 패킷 분석 모듈(140-1~140-N)은 실시간성을 중요시하는 환경에서 사용될 수 있다. 모듈(140-1~140-N)은 패킷들을 1차적으로 트랜잭션 단위로 분석하고, 분석된 내용을 분석정보 수집장치(150)로 제공한다. 이때, 모듈(140-1~140-N)은 기설정된 일정 기간(예를 들어, 10초, 20초 등) 동안의 패킷들을 수집하고, 수집된 패킷들에 포함된 헤더 정보를 분석할 수 있다. 그리고는, 패킷 헤더 정보를 트랜잭션 단위로 분석하여 트랜잭션 블록(142)을 생성한다. 상기 트랜잭션 블록(142)에는 한 개 또는 복수 개의 트랜잭션에 대한 정보가 포함되어 있다. 이는, 트랜잭션과 관련된 패킷들에 대한 정보 및 상기 트랜잭션들에 대한 기본적인 네트워크 성능 정보를 포함할 수 있다. 트랜잭션 블록과 관련된 트랜잭션은 10초 내에 처리할 수 있는 트랜잭션일 수 있다. 본 명세서 상에서 10초라고 기재된 부분은 사용자 설정에 의해 설정된 다른 임의의 시간으로 대체되어 해석될 수 있다. 예를 들어, 1초, 2초, 5초, 8초, 10초, 15초, 20초, 30초 등의 시간으로 대체되어도 무방하다. 다만, 8초 내지 12초 단위로 분석을 수행하는 것이 효율적일 수 있다. 보다 바람직하게는, 10초 단위로 분석하는 것이 좋다.

트랜잭션 블록(142)에는 10초 동안의 트랜잭션들에 대한 정보가 포함되어 있다. 즉, 10초 내에 처리할 수 있는 트랜잭션을 분석하여 분석정보 수집장치(150)로 전달한다. 모듈(140-1~140-N)은 이러한 트랜잭션 블록(142)들을 일정시간(예를 들어, 10초) 간격으로 생성하여 분석정보 수집장치(150)로 제공한다. 즉, 실시간이라고 하지만, 여기서 실시간은 "준실시간"이라고 해석될 수 있고, 실제로는 10초 단위로 데이터(패킷들)를 모았다가 이를 분석한 내용을 기반으로 블록을 생성하여 다른 장치로 전달한다고 볼 수 있다.

트랜잭션 블록(142)에는, 약 30여 가지의 정보가 포함될 수 있다. 여기에는, 전송측 엔티티(클라이언트 단말 또는 서버단의 서버들 중 하나) 및 수신측 엔티티(역시, 클라이언트 단말 또는 서버단의 서버들 중 하나)의 IP 및 포트(port) 정보, 트랜잭션과 관련된 시간 정보, 트랜잭션 요청 및 응답 패킷과 관련된 정보, 트랜잭션과 관련된 세션의 실시간 데이터 전송 속도 정보, 트랜잭션 상태 정보, 및 트랜잭션 결과 정보가 포함되어 있을 수 있다. 이러한 상세 정보에 대해서는, 도 4를 통해 보다 상세히 설명한다.

트랜잭션 블록(142)은 장치에 부담이 가지 않는 선에서 데이터 처리를 수행하고 그에 따라 최소한의 실시간성을 보장하기 위해, 적절한 크기로 생성되는 것이 바람직하다. 그 크기는 2.2MB 미만의 크기를 갖는 것이 바람직하다. 이러한 크기 및 규격은 실시간성의 보장과 패킷 분석 정보의 다양성(그에 따른 네트워크 모니터링의 정확성)과의 상관관계를 고려할 때, 매우 중요하게 다뤄져야할 필요가 있다. 패킷 분석을 통해 100여 개가 넘는 성능지표를 추출할 수 있지만, 트랜잭션 블록(142)은 대용량 네트워크 및 실시간 분석이라는 조건을 고려할 때, 비교적 제공하는 정보를 단순화하여 장치(150)로 제공된다. 여기에는, 기초 통계(예를 들어, 약 10초 동안의 트랜잭션에 대한 데이터 전송 속도, 지연, 에러 관련 통계를 포함함)가 함께 제공된다. 일 예에서, 이러한 트랜잭션 블록(142)에는 약 10000개 정도의 트랜잭션에 대한 정보가 포함될 수 있다. 하나의 트랜잭션에 있어서, 산출되는 지표는 120가지의 종류의 상세 정보(후보 요소 정보)들 중 필수적이라 여겨지는 일부의 지표가 포함될 수 있다.

한편, 트랜잭션 블록(142)은 HTTP(Hypertext Transfer Protocol)를 이용하여 일정 시간(예를 들어, 8초 내지 12초, 보다 바람직하게는 10초) 단위로 분석정보 수집장치(150)로 제공될 수 있다.

분석정보 수집장치(150)는 실시간으로 제공되는 트랜잭션 블록(142)을 수신하는 장치이다. 분석정보 수집장치(150)는 트랜잭션 블록(142) 내에 포함된 패킷 관련 정보를 수집 및 저장하는 장치이기 때문에, 패킷 데이터 수집 장치, 패킷 분석 데이터 수집 장치, 패킷 데이터 저장 장치 또는 패킷 분석 데이터 저장 장치로 불릴 수 있다. 분석정보 수집장치(150)는 트랜잭션 블록(142)을 실시간으로 수신하여 트랜잭션 단위로 구분하고, 트랜잭션 단위로 대용량 저장소(예를 들어, 레포지토리(repository))에 저장할 수 있다. 이때, 저장 효율 및 데이터 검색 효율을 극대화할 수 있는 방법을 이용한다.

분석정보 수집장치(150)는 다양한 형태로 구현될 수도 있다. 경우에 따라, 일반 클라이언트 단말(110-1~110-N)과 같이 네트워크(120)를 통해 트랜잭션 블록(142) 정보를 수신하는, 사용자 측의 단말장치로 구현될 수도 있다. 또한, 분석정보 수집장치(150)는 2차로 트랜잭션 블록(142)을 추가 분석한 후, 해당 정보를 사용자 단의 단말(110-1~110-N)으로 제공하여, 사용자에게 네트워크 성능 및 보안과 관련된 사항을 제공하는 장치로서 동작할 수도 있다.

분석정보 수집장치(150)는 트랜잭션 블록(142)을 기반으로 2차적으로 네트워크 성능과 관련된 지표를 산출하여, 어떤 구간에 속도 지연, 대기 지연, 트래픽 초과, 에러 발생과 같은 문제가 있는지 여부를 서버 단의 특정 구간 별로 판단하고, 판단 결과를 운영자 또는 관리자가 확인할 수 있도록 시각화할 수 있다. 여기서, 운영자 또는 관리자는 네트워크 운영자 또는 네트워크 관리자를 포함한다. 이를 통해, 에러 구간을 신속하게 파악하고, 이를 기반으로 에러구간에 대한 대응이 신속하게 이루어질 수 있도록 한다.

다른 실시예에서, 분석정보 수집장치(150) 없이, 패킷 분석 모듈(140-1~140-N)만 존재하는 시스템이 있을 수 있다. 이 경우, 트랜잭션 블록(142) 형태의 분석결과가 제공될 수 있다.

한편, 패킷 분석 모듈(140-1~140-N)과 분석정보 수집장치(150)는 패킷 분석 결과를 가지고 악의적인 사용자로부터의 접근(보안 이슈 관련)을 추적할 수 있고, 이에 대한 대응도 실시간으로 이루어질 수 있도록 한다.

또 다른 실시예에서, 패킷 분석 모듈과 분석정보 수집장치(150)는 하나의 장치로 구현될 수도 있다.

서버단(130-1~130-N)에 대해 보다 상세히 설명하면, 웹 서버(130-1)는 웹 클라이언트(Web Client)에게 요청된 컨텐츠를 제공하는 서버이다. 웹 서버(130-1)는 정적인 HTML이나 JPEG, GIF같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공할 수 있다. 경우에 따라, 웹 서버(130-1)도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장할 수 있다.

앱 서버(130-2)는 WAS(Web Application Server) 서버라고도 불릴 수 있고, 이는 클라이언트/서버 환경에서 트랜잭션 처리 및 관리와 애플리케이션 실행 환경을 제공하는 미들웨어 소프트웨어 서버를 나타낸다. 전형적으로, 서버단(130-1~130-N)은 웹 서버, 애플리케이션 서버, 데이터베이스의 3계층 웹 컴퓨팅 환경으로 구축될 수 있는데, 이때, 앱 서버(130-2)는 클라이언트/서버 환경의 애플리케이션 서버와 같은 역할을 한다. 앱 서버(130-2)는 애플리케이션 실행 환경과 데이터베이스 접속 기능을 제공하고, 트랜잭션을 관리하며, 업무를 처리하는 비즈니스 로직을 수행하고, 다른 기종 시스템 간의 애플리케이션 연동 등을 수행한다.

본 발명의 실시예에 따르면, 웹 서버(130-1)와 WAS(130-2)의 기능적 분류를 통해 효과적인 분산을 유도할 수 있다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버(130-1)에서 처리하고, 동적인 데이터는 뒷단의 WAS(130-2)가 처리할 수 있다. 예컨대, 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, 이미지 등을 앞단의 웹 서버(130-1)에 위치시켜 처리함으로써 WAS(130-2)로 서비스 요청이 넘어가지 않게 한다. 또한, 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS(130-2)에 넘겨줌으로써 WAS(130-2)는 웹 애플이케이션의 수행에 집중할 수 있다. 웹 서버(130-1)에서 처리할 것과 WAS(130-2)에게 넘겨질 것을 처리하는 방식은 웹 서버(130-1)의 컨피규어레이션(Configuration)을 통해 처리할 수 있다. 특정 확장자나 디렉토리 업무를 WAS(130-2)로 넘길지 여부는 웹 서버(130-1)에서 처리한다.

데이터베이스 서버(130-N)는 웹 서버(130-1) 및/또는 앱 서버(130-2)가 취급하는 각종 데이터가 저장되어 있는 저장소이다. 데이터베이스 서버(130-N)는 웹 서버(130-1) 및/또는 앱 서버(130-2)가 처리하는 작업, 웹 사이트, 웹 애플리케이션의 성격에 따라 그와 연관된 엄청난 양의 데이터가 저장될 수 있다. 이는 개인정보, 기관정보, 각종 콘텐츠(예컨대, 멀티미디어 콘텐츠)와 연관된 데이터 등을 포함할 수 있다.

도 2는 본 발명의 다른 실시예에 따른 네트워크 모니터링을 위한 실시간 패킷 분석 방법이 적용되는 클라우드 환경을 나타낸 개념도이다.

도 2를 참조하면, 패킷 분석 모듈(220)은 클라우드 환경에서 동작할 수 있다. 클라우드 환경에는 다수의 앱 인스턴스(Application instance: 210)가 존재할 수 있다. 하나의 앱 인스턴스(210)는 하나 또는 둘 이상의 서비스를 수행하는 기능 블록일 수 있다. 이는 하나 또는 둘 이상의 기능 또는 특징 또는 서비스의 실행을 위한 소프트웨어 프로그램일 수 있다. 또는, 상기 앱 인스턴스(210)는 특정 고객(또는 가입자, 엔드 유저(end-user), 단말 또는 서버 등)에 의해 이용되는, 가상 머신(virtual machine), 프로세서 또는 컴퓨팅 설비에 의해 상기 앱 인스턴스(210) 프로그램을 실행하는 프로세스 또는 태스크(task)와 연관될 수 있다. 이는 "네트워크 기능 가상화(NFV: Network Function Virtualization) 환경에서 "가상 네트워크 기능-인스턴스(VNF-I: Virtual Network Function-Instance)에 대응하는 개념일 수 있다. 경우에 따라, 인스턴스는 앞서 설명한 개체(entity)에 대응되는 개념으로 해석될 수 있다. 앱 인스턴스(210)는 인스턴스라고 불릴 수 있다. 한편, 일 예에서, 복수 개의 인스턴스(210)들은 연결되어 하나의 서비스 체인을 형성할 수 있다.

본 발명의 일 실시예에 따른 패킷 분석 모듈(220)은 하나의 인스턴스(210)에 에이전트 형태로 삽입되어 해당 인스턴스로 송수신되는 패킷을 분석할 수 있다. 패킷은 해당 인스턴스와 클라이언트 간에 송수신되는 패킷 및 다른 인스턴스와 송수신된 패킷을 포함한다. 패킷 분석 모듈(220)은 일정시간 단위로 상기 패킷들을 분석하여 트랜잭션 블록을 생성한 후, 이를 외부의 분석정보 수집장치(232)로 제공할 수 있다.

본 발명의 실시예에 따르면, 패킷 분석 모듈(220)은 다수 개로 구성되어 약 1000 여개의 인스턴스(210)의 패킷들을 처리할 수 있다. 이때, 인스턴스(210)와 패킷 분석 모듈(220)의 대응관계는 1:1이 바람직하나, 2:1, 3:1 또는 더 다수 대 1, 및/또는 1:2, 1:3, 1: 다수의 관계를 가질 수도 있다. 이는 서비스 체인 단위로 대응되도록 할 수 있다. 이러한 다수의 패킷 분석 모듈(220)들은 최대 100만 TPS(Transaction Per Second)를 처리할 수 있다. 즉, 인스턴스(210)당 평균 1000 TPS로 처리할 수 있다. 즉, 1M TPS로 처리할 수 있다.

또한, 모든 인스턴스(210)들에서 발생하는 모든 트랜잭션을 처리할 수 있다. 보다 구체적으로는, HTTP 관련 정보, WAS 서버와 관련된 것 및/또는 SQL(Structured Query Language) 등을 처리할 수 있다. 패킷 분석 모듈(220)은 실시간으로 클라우드 환경의 대용량 네트워크에서의 각각의 인스턴스(210)의 패킷 분석을 목표로 할 수 있다. 이에 실시간성을 담보로 하기 위해, 앞선 도 1의 설명과 같이, 일정 시간 단위로 패킷들을 수집하고, 트랜잭션 단위로 패킷 분석 결과를 도출하되, 기초적인 통계를 분석정보 수집장치(230)로 제공하는 형태로 동작하는 것이 바람직하다. 따라서, 다수(약 1000개)의 패킷 분석 모듈(220)들은 8초 내지 12초 단위(보다 바람직하게는, 10초 단위)로 약 10000개의 트랜잭션들을 처리할 수 있다. 이때, 각각의 패킷 분석 모듈(220)은 동기화를 수행하여 10초 간격으로 트랜잭션 블록을 분석 정보 수집 장치(230)로 제공한다. 즉, 트래픽 흐름의 안정성을 위해, 서로 다른 패킷 분석 모듈(220)들은 각자 정해진 시간(서로 다른 시간)에 순차적으로 10초 단위 트랜잭션 블록을 전송하도록 동기화되어 있을 수 있다. 경우에 따라 동기화된 상태에서 동시에 트랜잭션 블록을 전송할 수도 있다.

한편, 앞서 설명한 바와 같이, 복수 개의 인스턴스들(210)이 하나의 서비스 체인을 구성하는 경우, 서비스 체인을 구성하는 인스턴스들(210)에 삽입된 패킷 분석 모듈(220) 중 적어도 하나가 해당 서비스 체인으로 송수신되는 패킷들을 분석하여 트랜잭션 블록을 생성할 수 있다. 이때, 인스턴스 단위뿐만 아니라 서비스 체인 단위의 트랜잭션을 분석할 수 있다. 또한, 패킷 분석 결과를 통해 복수 개의 인스턴스들(210)이 하나의 서비스 체인으로 동작하는 것을 인지하면, 상기 복수 개의 인스턴스들(210)과 연관된 복수 개의 패킷 분석 모듈(220)들 중 일부 또는 하나만 대표로서 서비스 체인 단위로 패킷 분석을 수행하도록 할 수 있다. 이때, 개별 인스턴스(210)는 서비스 체인 단위로 동작하면서 동시에 개별적인 동작도 가능하기 때문에, 개별 인스턴스(210)에 대한 패킷 분석도 함께 이루어지도록 할 수 있다.

분석 정보 수집 장치(230)는 하나의 장치로 구현되되, 복수 개의 모듈(232, 234, 236, 238)을 포함할 수 있다. 상기 분석정보 수집장치(230)는 수집 모듈(232), 인덱싱 모듈(234), 경고 모듈(236) 및 브라우징 모듈(238)을 포함할 수 있다. 패킷 분석 모듈들(220)에서 생성된 트랜잭션 블록 데이터는 수집 모듈(232)에 의해 수집된다. 수집 모듈(232)은 이를 트랜잭션 블록을 수신하여 템포러리 파일(temporary file)로 저장하고, 이를 수신 시간으로 정렬하여 대용량 저장소(240: repository)에 저장한다. 상기 저장소(240)는 클라우드 파일 스토리지(대용량 스토리지)를 포함한다. 예를 들어, 이는 Amazon EFS(Elastic File System), EFS IA, Google Cloud, Microsoft Azure 등의 저장소로 구현될 수 있다.

데이터가 저장소(240)에 저장되면, 인덱싱 모듈(234)은 저장소(240)에 저장된 데이터를 오프셋(offset)을 이용하여 인덱싱한다. 경고 모듈(236)은, 저장된 데이터 또는 필터링된 데이터에 대해 경고 상태 머신(alert state machine)을 실행시켜, 적절하게 경고 신호를 발생시키는 동작을 수행한다. 브라우징 모듈(238)은 사용자 검색 입력에 반응하여 인덱싱 필드를 통해 기본 검색을 수행하고, 필터링 필드를 이용하여 추가적인 검색을 수행할 수 있다. 이를 통해 사용자 입력에 대한 최종 검색 결과를 정렬하여 출력한다. 이는 도 5를 통해 보다 상세히 설명한다.

한편, 상기 분석 정보 수집 장치(230)는 각 모듈들 단위로 개별 장치로 구현되어 복수 개의 장치들로 구현될 수도 있다.

도 3은 본 발명의 또 다른 실시예에 따른 네트워크 모니터링을 위한 실시간 패킷 분석 방법이 적용되는 시스템을 나타낸 개념도이다.

도 3을 참조하면, 패킷 분석 장치(340)는 스위치(미도시)에 연결되어 스위치를 통해 서버(330-1~330-2)로 제공되는 모든 패킷을 미러링하여 획득할 수 있다. 이때, 패킷 미러링은 스위치에서 수행될 수 있다. 스위치는 서버(330-1~330-2)로 제공되는 패킷을 복제한 후, 패킷 분석 장치(340)와 연결된 포트를 목적지 포트(destination port)로 설정하여 패킷을 패킷 분석 장치(340)로 제공할 수 있다. 이때, 해당 포트를 분석 용도로 지정하여 제공할 수 있다.

패킷 분석 장치(340)는 네트워크(320)와 웹 서버(330-1) 사이, 웹 서버(330-1)와 앱 서버(330-2) 사이 및 앱 서버(330-2)와 데이터베이스 서버 사이 중 적어도 하나에 배치될 수 있다. 패킷 분석 장치(340)는 네트워크(320)와 웹 서버(330-1) 사이, 웹 서버(330-1)와 앱 서버(330-2) 사이 및 앱 서버(330-2)와 데이터베이스 서버 사이 중 적어도 하나에 배치된 스위칭 장치(미도시)와 연결되어 두 개체 간에 송수신되는 패킷 또는 이를 미러링한 패킷을 기반으로 네트워크 서버스의 성능을 구간별로 진단한다.

본 발명의 상기 실시예에 따르면, 미러링된 패킷은 실제 송수신되는 패킷(실제 사용되는 사용자 트래픽)을 복사함에 의해 생성될 수 있으므로, 네트워크 서비스의 성능 진단을 위해 별도의 인위적인 테스트 패킷을 생성할 필요가 없다. 특히, 패킷 분석 장치(340)는 이러한 방식을 통해 샘플링되는 일부 패킷이 아닌, 모든 패킷에 대한 모니터링이 가능하다.

도 3의 실시예에 따르면, 패킷 분석 장치(340) 및 분석정보 수집장치(350)는 상기 스위칭 장치에 연결되는 하드웨어로 구현될 수 있다. 이에 따라, 서버단(330-1~330-2)에 실질적으로 부하를 주는 에이전트(agent) 설치를 요구하지 않을 수 있다. 이 경우, 서버단(330-1~330-2)의 작업속도를 늦추는 등의 부담을 주지 않는다.

패킷 분석 장치(340)는 1차 패킷 분석한 내용을 기반으로 트랜잭션 블록(342)을 생성하여 분석정보 수집장치(350)로 제공한다. 이때, 서로 다른 구간에 배치된 패킷 분석 장치(340)를 이용하여 각 구간별 네트워크 성능을 파악할 수 있다.

도 4는 패킷 분석 모듈에서 생성되어 분석 정보 수집 장치로 제공되는 트랜잭션 블록의 구성을 구체적으로 나타낸 개념도이다. 도 4에 도시된 바와 같이, 하나의 앱 인스턴스에 부착된 패킷 분석 모듈로부터 생성되는 10초 단위 트랜잭션 블록은 10초 통계 정보, 텍스트 리스트 및 트랜잭션 리스트 정보를 포함할 수 있다.

도 4를 참조하면, 트랜잭션 리스트는 10초 단위의 트랜잭션들에 대한 상세 정보를 포함한다. 여기에는, 최대 10,000개의 트랜잭션들에 대한 정보(특히, 패킷 정보, 보다 구체적으로는 패킷 헤더 정보)가 포함될 수 있다. 하나의 트랜잭션에 대해서는, 약 30개의 요소 정보, 즉, 성능지표 정보가 포함될 수 있다. 이는 120개 후보 성능지표들 중 필수적이라고 여겨지는 약 30여개의 정보이며, 한 세트의 요소 정보라고 부를 수 있다. 이는 사용자 설정에 의해 미리 설정되어 있을 수 있다. 하나의 트랜잭션에 대한 요소정보들은 100 내지 120 Byte의 크기를 가질 수 있고, 10초 단위 트랜잭션 리스트는 전체적으로 약 0.8 내지 1.2MiB의 크기로 생성되는 것이 바람직하다. 보다 바람직하게는, 1.07MiB 이하의 크기를 갖도록 하는 것이 좋다.

텍스트 리스트는 트랜잭션 리스트의 텍스트 정보들의 목록이다. 텍스트는 URL, 도메인, 콘텐츠 타입, DB 쿼리문 등의 정보를 포함한다. 이는 트랜잭션 리스트의 어느 하나의 요소 정보(성능지표)와 해쉬 값을 통해 연계될 수 있다. 텍스트 리스트는 2MiB 이하의 크기로 생성되며, 압축을 통해 1MiB 미만의 크기로 생성될 수 있다.

10초 단위 통계 정보는 10초 동안의 평균 성능지표 정보, 또는 10초 단위 스탭샷 정보를 포함한다. 여기에는, 약 30여개의 통계 정보가 포함될 수 있으며, 약 300 내지 500 Byte의 크기를 가질 수 있다. 보다 바람직하게는, 380 내지 416 Byte의 크기를 가질 수 있다.

트랜잭션 블록에 포함되는 10초 통계 정보, 텍스트 리스트 정보 및 트랜잭션 리스트 정보를 병합하였을 때, 전체적으로 1.8MB 내지 2.2MB의 크기를 갖는 것이 바람직하며, 보다 바람직하게는, 1.9MB 내지 2.07MB 인 것이 좋다. 트랜잭션 리스트 내의 정보, 텍스트 리스트 내의 정보 및 10초 통계 정보 각각의 구성은 도 14 내지 도 16을 통해 보다 상세히 설명한다.

다음은 트랜잭션 블록의 생성 과정을 설명한다.

패킷 분석 모듈은 실시간으로 수집되는 패킷들을 트랜잭션 단위로 분석하여 성능지표를 산출하고, 텍스트 정보를 생성하여 해쉬 값을 이용하여 성능지표 정보와 연관시키고, 이를 기반으로 단위 기간 동안 성능지표와 관련된 간략한 통계를 낸 후, 상기 성능지표 정보와 상기 통계 정보를 합쳐 트랜잭션 블록을 생성한다.

보다 구체적으로, 패킷 분석 모듈은 수집되는 패킷의 헤더를 분석할 수 있다. 이를 통해, HTTP 패킷인지, DB와 연관된 패킷인지, TCP와 연관된 패킷인지 구분할 수 있다. 이를 통해 "GET/웹 주소/HTTP/1.1"과 같은 요청 정보를 어떤 서버로 전송했는지 확인할 수 있다. 패킷 분석 모듈은 패킷 헤더 정보를 파싱하여 구문해석한다. 상기 실시예에서, "GET"은 요청 메시지가 되고, "웹 주소"는 요청과 연관된 웹 주소를 나타낸다. 그리고, "HTTP/1.1"은 HTTP 1.1 버전인 것을 의미하며, 이외에 패킷과 연관된 언어 정보(예컨대, ko-kr)도 확인하여 저장할 수 있다. 요청 매소드는 GET 외에도, POST, HEAD, PUT, DELETE 등이 상황에 따라 전송될 수 있다.

패킷 분석 모듈은 각각의 패킷의 인덱스를 부여하고, 부여된 인덱스를 기반으로, 어떤 패킷인지, 해당 패킷이 HTTP 기반의 요청 패킷인지, 그에 대한 응답 패킷인지를 확인한다. 이때, 과거 수신했던 패킷들로부터 획득한 정보와의 비교분석도 수행된다. 즉, 제 1 개체로부터 획득된 요청 패킷이 존재하는 경우, 이후 제 2 개체로부터 그에 대한 응답 패킷이 존재할 수 있고, 이때, 시계열적인 적어도 둘 이상의 패킷, 제 1 개체와 제 2 개체로부터 송수신되는 패킷들의 관계를 파악하여 하나의 세션 확립, 및 그 안의 트랜잭션들의 흐름을 분석할 수 있다.

또한, 패킷 분석 모듈은 분석 대상 장치(서버 또는 클라이언트) 또는 분석 대상 인스턴스와 관련된 클라이언트 단말이 어떤 브라우저를 사용했는지, HOST와 연관된 정보, 이전 URL 주소 정보, 브라우저 지원 언어 정보를 파싱할 수 있다. 이때, 헤더가 어떤 종류의 헤더(general header인지, request header인지, entity header인지)인지 분석할 수 있고, 헤더와 페이로드의 경계선을 나타내는 정보를 파싱할 수 있다.

그리고는, 패킷 분석 모듈은 수집되는 패킷의 URL 또는 URI(uniform resource identifier)), 소스 IP(Source_ip), 목적지 IP(Dest_ip) 및 시간정보를 분석할 수 있다. 여기서, URL 값을 확인해 보면, "https://www.google.co.kr/?gws_rd=ssl"와 같이, 어떤 주소로 리디렉트(redirect)시켜주는 패킷인지 확인할 수 있다. 또한, 소스 IP는 클라이언트 단말의 IP 주소를, 목적지 IP는 요청의 최종 목적지 사이트와 연관된 서버의 IP를 나타낼 수 있다. 응답 패킷의 경우 반대의 정보를 나타낼 수 있다. 시간정보는 타임스탬프 형식으로 제공될 수 있다. 이외에 전체 패킷의 길이 정보(length)도 확인할 수 있다.

패킷 분석 모듈은 각각의 프로토콜, 예컨대, HTTP, IP, UDP, TCP, DNS 등 다양한 프로토콜에 대응한 패킷 분석 알고리즘을 포함하고 있고, 각 프로토콜에 맞게 적응적으로 패킷으로부터 URL, 소스 IP, 목적지 IP 및 시간정보를 추출하여 분석에 이용할 수 있다.

이렇게 2차 분석으로 추출된 패킷 관련 정보를 기반으로 1 트랜잭션당 약 30여 개의 한 세트의 성능지표 정보를 산출하여 트랜잭션 블록을 생성한다. 트랜잭션 블록에 포함되는 상기 30여 개의 성능지표 정보는 120여개 요소의 성능지표 정보 중 필수적으로 필요하다고 생각되는 항목들로 구성된다. 이는 기선택된 것일 수 있다. 다만, 이는 사용자 설정을 통해 가변될 수도 있다. 이러한 120여개 후보 요소 성능지표들 중 필수항목이라고 여겨지는 약 30여 개 항목의 추출 또는 선택은, 대용량 패킷의 처리에 있어서 매우 중요하게 여겨질 수 있다. 트랜잭션 블록에 포함되는 30여개의 요소 성능지표는 도 14를 통해 보다 상세히 설명한다. 여기서, 트랜잭션 블록에 포함 가능한 후보인 120여 개 성능지표들도 함께 소개한다.

패킷 분석 모듈은 1초에 약 1000개의 트랜잭션을 분석 및 처리한다. 이를 약 10초 단위로 생성하기 때문에, 10초에 10000 개의 트랜잭션을 분석 및 처리할 수 있다. 이러한 패킷 분석 모듈이 1000개의 인스턴스에 붙어있다고 가정할 때, 약 1000만 트랜잭션을 10초 단위로 처리하여 2차 수집 장치인 분석 정보 수집 장치로 제공할 수 있다.

패킷 분석 모듈은 산출된 성능지표 중 텍스트로 기재되어야 하는 정보는 텍스트 리스트로 별도 관리되도록 한다. 즉, 텍스트 리스트를 별도로 생성하고, 텍스트 리스트의 특정 텍스트가 성능지표들의 조합으로 이루어진 트랜잭션 리스트의 특정 성능지표와 매핑되도록 둘을 연관시킨다. 이때, 해쉬(hash) 값이 사용될 수 있다.

패킷 분석 모듈은 상기 산출된 한 세트의 성능지표(약 30여 개의 성능지표)를 기반으로 기초 통계 값을 산출한다. 즉, 10초 평균 또는 10초 단위 스냅샷 정보를 산출하여 통계 리스트를 생성한다. 그리고는, 패킷 분석 모듈은 산출된 성능지표 정보, 텍스트 리스트 및 기초 통계값을 합성하여 10초 단위 트랜잭션 블록을 생성한다. 생성된 트랜잭션 블록은 10초 단위로 분석정보 수집 장치로 제공된다.

한편, 본 발명의 실시예에 있어서, 패킷 분석 모듈은 분석정보 수집장치에서 이루어지는 분석까지 수행하는 일원화된 분석 모드인 제 1 모드와 분석정보 수집장치와 분석과정 중 일부를 나누어서 이원화된 분석을 수행하는 제 2 모드를 가지고 선택적으로 동작할 수 있다. 즉, 일원화된 분석 모드(제 1 모드)는 120여개의 네트워크 성능지표를 모두 산출하는 모드일 수 있다. 이원화된 분석 모드(제 2 모드)는 분석정보 수집장치와 연동하는 분산 수행 모드로써, 30여개의 필수성능지표만 산출하여 트랜잭션 블록 형태로 분석정보 수집장치로 제공한다. 이 때, 이러한 모드의 선택은 패킷 분석 모듈 또는 분석 정보 수집 장치에서 이루어질 수 있다. 이는 다음의 파라미터에 따라 적응적으로 결정될 수 있다. 이를 결정하는 파라미터는 단위 시간 당 패킷의 수/바이트, 트래픽 속도, 지연시간, wait의 수, 및 모니터링 대상 서버들의 수 중 적어도 하나를 포함한다. 즉, 기준이 되는 파라미터 값을 미리 설정해 두고, 기준 파라미터 값을 넘는 상황이 발생하면, 제 1 모드에서 제 2 모드로 변경하고, 제 2 모드로 동작 중에, 다시 기준 파라미터 값보다 낮은 값을 갖는 네트워크 상태가 감지되면, 제 1 모드로 변경하도록 제어할 수 있다. 예를 들어, 네트워크 모니터링 대상 서버(또는 인스턴스)의 기준값이 100이라고 할 때, 100대 이하의 서버들에 대한 모니터링을 수행하고 있을 때면, 장치는 제 1 모드로 동작하다가 관리 대상 서버가 100대를 넘어가면 제 2 모드로 동작하도록 할 수 있다.

도 5는 본 발명의 일 실시예에 따른 분석 정보 수집 장치의 구성을 구체적으로 나타낸 상세블록도이다. 도 5에 도시된 바와 같이, 본 발명의 일 실시예에 따른 분석 정보 수집 장치는 리시버(receiver), 로컬 파일 시스템(local F/S), 저장부, 레포지토리(Repository), 인덱싱 모듈, 브라우징 모듈, 경고 모듈 및 사용자 인터페이스를 포함할 수 있다.

도 5를 참조하면, 수집모듈은 리시버, 로컬 파일 시스템 및 저장부를 포함할 수 있다. 그리고, 레포지토리와 연동할 수 있다.

우선, 복수 개의 패킷 분석 모듈로부터 수집 모듈의 리시버는 HTTP 프로토콜(특히, HTTP3)을 이용하여 트랜잭션 블록 및 기타 정보를 수신할 수 있다. 여기서, 기타 정보는 실제 패킷을 포함한다. 리시버는 수신된 트랜잭션 블록 정보를 기반으로 파일 이름을 트랜잭션 블록의 수신시점 또는 트랜잭션 블록과 연관된 패킷의 수신시점으로 하여 템포러리 파일(temporary file)로 로컬 파일 시스템에 저장한다. 저장부는 리시버를 통해 템포러리 파일로 저장된, 동 시간대의 10초 트랜잭션 블록을 수신시간으로 정렬하여 1분 단위로 디렉토리(directory)를 만들어서 레포지토리에 저장한다. 저장부는 레포지토리에 저장을 위해 트랜잭션을 구분하고 구분된 트랜잭션 단위로 레포지토리의 메모리 셀에 데이터를 할당하며, 각 시간 단위 디렉토리에 그에 대응하는 성능 정보를 산출하여 저장하는 구성으로써 프로세서로 구현될 수 있다.

저장부는 정렬을 위해 10초 동안 트랜잭션 블록을 기다렸다가 저장할 수 있다. 이때, 각 디렉토리는 8자리의 "수신 연도, 월, 일" 인덱스(yyyymmdd)와 4자리의 "수신 시간 및 분(hhmm)"의 인덱스로 저장된다. 수집 모듈은 이를 1분 단위 및 10분 단위로 네트워크 성능에 대한 통계치를 산출하여 함께 저장한다. 즉, 10초 단위 통계(이는 트랜잭션 블록에서 가져올 수 있음), 1분 단위 통계, 10분 단위 통계 등에 대한 분석이 이루어지고, 분석된 통계 결과는 각 디렉토리에 저장된다. 다시 말해, 개별 디렉토리에는 10초 통계 60개, 1분 통계 10개, 10분 통계 1개가 함께 저장된다.

인덱싱 모듈은 이러한 통계 정보에 개별적으로 검색용 인덱스를 붙인다. 이때, 00분 디렉토리에는 1시간 통계가 저장되고, 이와 유사하게, 0000분에는 1일 레포지토리 분석 결과가 함께 저장될 수 있다. 상기 1분 통계, 10분 통계, 1시간 통계 및 1일 통계는 트랜잭션 블록의 통계 정보와 동일 또는 유사한 정보의 통계치가 저장될 수 있다. 즉, 특정 성능지표의 평균값, 합산값, 최소값, 최대값, 중간값 중 적어도 하나를 산출하여 저장할 수 있다.

인덱싱 모듈은 시간에 대한 인덱스(Time Index), IP 또는 MAC 어드레스(MAC address)에 대한 인덱스(sIP(mac) Index), 텍스트 인덱스(Text Index), 상태 인덱스(State Index), 결과 인덱스(Result Index) 및 응답 코드 인덱스(Rsp. Code Index)를 1분 디렉토리의 각각의 트랜잭션에 붙일 수 있다.

이를 통해, 브라우징 모듈에서 사용자 입력에 따라 효율적인 검색이 이루어지도록 할 수 있다. 즉, 기본 검색은 인덱싱 필드에 의해 검색되도록 한다. 인덱싱 필드는 앞서 설명한 인덱스들 중, 시간 인덱스, IP/MAC 인덱스 중 적어도 하나를 포함한다.

그리고는, 추가적인 검색은 필터링 필드를 통해 이루어지도록 한다. 필터링 필드는 응답 코드 인덱스, 상태 인덱스 및 결과 인덱스를 포함한다. 2차적인 필터링은 응답지연시간(latency), 이외의 추가 조건, 및/또는 명확한 특정 로그 검색을 위한 검색어를 통해 이루어질 수 있다.

한편, 분석정보 수집장치와 패킷 분석 모듈은 하나의 모니터링 시스템으로써, 서로 간에 정보를 주고받으며 모니터링을 수행한다. 이때, 트랜잭션 리스트 및 통계 정보의 운영과 관련된 정보를 주고받을 수 있다. 예를 들어, 트랜잭션 리스트에 26개의 요소정보를 포함시키는 제 1 방식, 20개의 요소정보를 포함시키는 제 2 방식 및 30개 이상의 요소정보를 포함시키는 제 3 방식 등을 설정하고, 거기에 포함되는 정보들의 목록을 공유한 후, 현재 사용하고 있는 방식을 공유하는 형태로 동작할 수 있다. 이때, 현재 모니터링 대상 서버들(또는 인스턴스들)의 수에 따라 어느 방식을 사용할지 분석정보 수집장치가 결정하여 패킷 분석 모듈로 안내할 수 있다. 패킷 분석 모듈은 분석정보 수집장치의 결정에 따라 그에 맞는 방식으로 트랜잭션 블록을 생성한다. 더욱이, 통계 정보도 마찬가지로 운영될 수 있다. 기본 방식은 패킷 분석 모듈이 생성하는 트랜잭션 블록이 10초 단위 통계를 내고, 분석정보 수집장치에서 1분 단위, 10분 단위, 및 1시간, 그리고 나아가 1일 단위 통계를 낸다. 다만, 분석정보 수집장치는 이를 다른 방식으로 분산수행할 것을 결정하여 명령할 수 있다. 예를 들어, 10초 단위 및 1분 단위 통계를 패킷 분석 모듈에서 산출하고, 10분 단위, 1시간 및 1일 단위 통계만 분석정보 수집장치에서 산출하도록 제어할 수 있다. 또는, 10초 단위, 1분 단위 및 10분 단위 통계까지 패킷 분석 모듈에서 산출하고, 1시간 및 1일 단위 통계만 분석정보 수집장치에서 산출하도록 제어할 수도 있다.

도 6은 도 5의 수집 모듈에서 10초 단위의 트랜잭션 블록으로부터 트랜잭션을 구분하는 방법을 설명하기 위한 개념도이다.

도 6을 참조하면, 수집 모듈은 트랜잭션 블록을 수신하여 트랜잭션 단위로 구분한다. 이를 보다 구체적으로 살펴보면, 트랜잭션은 반드시 10초 단위로 끊어지지 않을 수 있기 때문에, 10초 이상의 트랜잭션과 10초 이내의 트랜잭션을 구분하여 처리한다.

장치(수집 모듈)는 트랜잭션 블록 4개를 A 서버와 관련된 제 1 패킷 분석 모듈과 B 서버와 관련된 제 2 패킷 분석 모듈로부터 수신할 수 있다. 트랜잭션 블록 내에 포함된 패킷들은 특정 서버와 관련된 것일 수 있다. 장치는 패킷 데이터를 트랜잭션 단위로 구분하여 저장하기 위해, 트랜잭션 블록 내의 패킷들을 연관된 서버별로 구분하는 것이 바람직하다. 서버 구분은 패킷 헤더 및/또는 트랜잭션 블록 전송 모듈을 구분함에 의해 이루어질 수 있다. 그리고는, 수신 시간을 기준으로 패킷들을 시계열적으로 정렬한다.

한편, 트랜잭션은 동기 신호(Syn)를 기점으로 시작되고, 종료 신호(fin)을 통해 종료된다. 따라서, 트랜잭션을 트랜잭션 단위로 구분하기 위해, 동기신호와 종료신호가 기준이 될 수 있다.

도 6의 실시예에서, A-1과 B-1 트랜잭션과 관련된 패킷들이 수신될 때, 해당 패킷은 동기 신호만 가지고 있을 수 있다. 따라서, 0초 시점에 두 패킷들은 처리가 완벽히 이루어지지 않을 수 있다. 이들은 템포러리 파일(temporary file)에 저장된다.

0 내지 10초 시점에 트랜잭션 블록 2개(A-1, A-2)가 수신되면, 장치는 해당 트랜잭션 블록 내의 패킷들에 동기 신호, 종료 신호가 존재하는지 판단한다. A-1 트랜잭션엔 종료신호가 있기에, A-1은 완전한 트랜잭션으로 구분하여 10초 시점에 레포지토리에 저장한다. A-2는 동기신호만 있기에, 다음 트랜잭션 블록을 수신할 때까지 템포러리 파일에 대기시킨다.

그리고는, 다음 10 내지 20초 구간의 트랜잭션 블록을 수신한다. 장치는 여기서, A-2, B-1의 종료신호를 확인할 수 있다. 그리고는, A-2와 B-1의 동기신호와 조합하여 완전한 트랜잭션을 형성시키고, 이를 레포지토리에 저장한다. 즉, 장치는 템포러리 파일에 이전 10초의 트랜잭션 블록을 저장하였다가 다음 10초의 트랜잭션 블록과 조합하여 트랜잭션을 구분한 뒤, 완전한 트랜잭션을 생성한다. B-2 트랜잭션은 하나의 트랜잭션 블록 내에 동기신호와 종료신호가 모두 존재하기에, 20초 시점에 완전한 트랜잭션으로 구분하여 레포지토리에 저장할 수 있다.

즉, 패킷 분석 모듈은 10초 내에 처리할 수 있는 트랜잭션만 처리해서 수집모듈로 전달하고 실제 트랜잭션 단위 처리 및 그에 대한 분석의 완성은 수집모듈에서 수행된다.

도 7은 수집 모듈에서 트랜잭션 단위로 구분하여 레포지토리에 트랜잭션 블록 데이터를 저장하는 방법을 설명하기 위한 개념도이다.

도 7을 참조하면, 수집 모듈(700: 설명의 편의상 장치라고 부를 수 있음)은 수신되는 트랜잭션 블록을 바로 현재 레포지토리(710)에 저장할 수 있다. 현재 레포지토리(710)는 1분 단위의 파일 디렉토리(directory)로 구성될 수 있다. 즉, 20200101_0100의 파일 명을 가질 수 있다. 이는 8자리의 날짜와 그 뒤의 2자리의 시(hour), 그 뒤 2자리의 분(minute)를 의미한다(yyyymmdd_hhmm). 장치(700)는 현재 레포지토리(710)에 저장할 때, 템포러리 파일을 이용하고, 앞서 설명한 바와 같이, 템포러리 파일은 이전 10초의 트랜잭션 블록 내에서 처리되지 않은 트랜잭션의 패킷들은 대기시켰다가 현재 10초 트랜잭션 블록과 함께 처리될 수 있도록 한다. 즉, 템포러리 파일은 10초간 지연된 상태로 데이터가 저장되도록 한다.

장치(700)는 이전 1분 레포지토리(720)와 현재 1분 레포지토리(710) 간에 연관된 트랜잭션을 서로 연계하여 처리될 수 있도록 한다. 즉, 1분 단위로 레포지토리를 생성하되, 현재 시점으로부터 이전 1분 레포지토리(720)는 현재 레포지토리(710)에 포함되는 트랜잭션 블록에 의해 영향을 받을 수 있기에, 열린(open) 상태로 둔다. 즉, 이전 레포지토리(720)에 트랜잭션 A가 동기 신호만 존재하고 종료 신호가 있는 패킷이 없는 경우, 이를 템포러리 리스트(temporary list)에 기록해 놓고, 열린 상태로 대기시켜 놓았다가, 현재 레포지토리(710)에 저장되는 트랜잭션 블록들 중 하나에 트랜잭션 A와 관련된 종료 신호가 있는 패킷이 존재하면, 이를 이전 레포지토리(720)와 연관시키고, 그와 관련된 통계 정보 등을 갱신시키는 등의 작업을 수행한다. 템포러리 리스트는 불완전한 패킷을 기록해 놓는 것이기 때문에, 이때 템포러리 리스트(720)에서 트랜잭션 A에 대한 정보를 삭제한다. 그리고, 시간이 흘러 현재 레포지토리(710)의 저장이 완료되는 시점에 이전 레포지토리(720)의 상태를 닫힌(closed) 상태로 변경시키고, 현재 레포지토리(710)는 열린 상태로 다음 레포지토리(미도시)에 저장되는 트랜잭션 블록과 연관시킬 수 있도록 한다. 즉, 레포지토리는 현재 저장되는 1분 레포지토리를 기점으로, 바로 이전 1분 레포지토리에 대해 열린 상태로 두어, 데이터가 1분간 지연되어 저장되도록 한다.

도 8a 및 도 8b는 동기 신호(syn)와 종료 신호(fin)를 포함하는 패킷을 이용하여 개별 트랜잭션을 구분하는 방법을 설명하기 위한 패킷 구분 테이블 및 이에 대한 처리 흐름도이다.

도 8a 및 도 8b를 참조하면, 트랜잭션 블록 내의 패킷들은 크게 7가지 상태로 구분될 수 있다. 동기 신호(Syn), 엔드 신호(End) 및 종료 신호(Fin)의 포함여부를 가지고 구분할 수 있다. 여기서, 엔드 신호는 HTTP 상에서 특정 트랜잭션을 위한 요청 및 응답(Req & Res)은 완료하였으나 소켓은 떨어지지 않는 상태의 패킷을 나타낸다. 즉, 이는 좁은 의미의 트랜잭션의 종료를 의미할 수 있다. 여기서는 향후 해당 소켓을 이용하여 추가적인 트랜잭션을 이어나갈 수 있다. 반면, 종료 신호는 소켓에서 세션을 종료 처리를 하기 위한 신호를 의미한다. 즉, 세션 종료와 유사할 수 있고, 광의의 트랜잭션의 종료를 의미할 수 있다.

동기 신호와 엔드 신호, 그리고 종료 신호가 모두 존재하는 상태 1의 패킷은 그 자체로 완전한 트랜잭션을 형성하고, 템포러리 파일에서 대기할 필요없이 바로 레포지토리에 저장한다. 엔드 신호만 없고 동기 신호와 종료 신호가 있는 패킷도 상태 1과 동일하게 처리할 수 있다.

한편, 동기 신호와 엔드 신호만 있는 상태 2의 신호는 상태 6의 종료 신호만 있는 패킷을 기다리는 것이 바람직하다. 또는, 타임아웃(timeout) 룰에 의해 트랜잭션을 불완전한 상태로 종료시킬 수도 있다. 타임아웃 룰은 임계시간이 넘으면 더 이상 종료 신호를 기다리지 않고 해당 트랜잭션을 실패(Fail) 처리하고 종결시키는 것을 의미한다. 본 발명의 실시예에서는, 타임아웃 임계 시간을 60초(sec)로 설정하는 것이 바람직하다. 1분의 시간으로 설정하면 레포지토리의 1분 디렉토리의 저장 시간과 맞물려 효율적으로 동작할 수 있다. 다만, 반드시 60초(1분)일 필요는 없고, 30초, 40초, 50초, 1분 30초, 2분, 5분 등의 시간으로 설정되어도 무방하다. 또한, 레포지토리의 디렉토리도 30초, 40초, 50초, 1분 30초, 2분, 5분 등의 시간으로 설정될 수 있다. 다만, 타임아웃 임계시간과 레포지토리의 디렉토리의 저장 시간은 동일한 것이 바람직하다. 아니면, 타임아웃 임계 시간과 레포지토리의 하나의 디렉토리에 대한 저장시간은 일정한 비례 관계를 갖도록 설정하는 것이 바람직하다. 예를 들어, 타임아웃 임계시간이 40초면, 디렉토리 저장시간은 20초로, 2배수가 되게 하여, 타임아웃 전에 2개 디렉토리를 열린 상태로 유지하도록 하는 것이 좋다.

한편, 동기 신호만 있는 상태 3의 패킷은 엔드 신호와 종료 신호가 함께 있는 상태 4의 신호, 엔드 신호만 있는 상태 5의 패킷을 기다린다. 상태 5의 패킷은 동기신호, 엔드신호 및 종료신호가 없는 상태 7(데이터만 존재하는 패킷일 수 있음)의 패킷 또는 종료 신호가 있는 상태 6의 패킷을 기다린다. 상태 7의 패킷은 데이터만 있는 패킷이기 때문에, 다시 상태 7의 패킷을 기다리거나 상태 5, 상태 4의 또는 상태 6의 패킷을 기다린다. 그러다가 타임아웃 룰에 의해 종결처리될 수도 있다.

경우에 따라, 상태 7의 경우처럼 동기신호, 엔드신호 및 종료신호가 없는 경우, 수신시간을 동기 또는 엔드/종료 신호로 사용할 수도 있다.

도 9는 도 6 내지 도 8b의 방법을 이용하여 복수의 패킷 분석 모듈로부터 수신되는 트랜잭션 블록을 레포지토리에 저장하는 과정을 예시적으로 나타낸 도면이다.

도 9를 참조하면, 장치가 동일한 시간대의 10초 트랜잭션 블록을 복수 개 동시에 수신하면, 이를 수신시간을 기준으로 정렬한다. 이때, 각 트랜잭션 블록당 현재의 최소값만 rbtree를 사용하는 방식이 사용될 수 있다.

도 9에서 가장 많은 점이 분포된 블록은 동기 신호(Syn)만 있는 패킷을 의미하고, 그 다음으로 많은 점이 분포된 블록은 종료 신호(Fin)가 있는 패킷(동기 신호는 존재할 수도 있고 없을 수도 있음)을 의미하며, 가장 적게 점이 분포된 블록은 동기 신호와 종료 신호가 모두 존재하는 완결 패킷을 의미한다. 장치는 각 패킷 분석 모듈로부터 수신되는 트랜잭션 블록 내의 패킷들을 시간 순서대로 정리한다. 블록 내의 숫자는 수신 시각(예를 들어, msec 기준)을, 블록 우측에 표시된 숫자는 각 패킷들 간의 상대적인 도착 순서를 의미한다.

장치는 동일 시간의 10초 트랜잭션 블록들을 수신하면, 이를 루트 팝(root pop)으로 레포지토리에 저장한다. 레포지토리에 저장할 때, 수신된 절대 시각을 기반으로 트랜잭션 단위로 메모리 셀을 할당하여 저장한다. 예를 들어, 199ms에 수신된, 4번 서버와 관련된 첫 번째 패킷(1번 패킷)이 가장 빠르게 수신된 패킷으로 첫 번째 메모리 셀에 할당되어 저장되되, 해당 패킷은 동기 신호만 있는 불완전 패킷이기 때문에, 종료 신호(Fin)만 있는 패킷을 기다린다. 이때, 1번 패킷은 템포러리 리스트에 기재한다. 그 다음, 2번째 내지 3번째 패킷 역시 동기 신호만 있는 미완성 트랜잭션 패킷으로 2번 및 3번 메모리 셀에 할당하여 저장하고 종료 신호가 있는 패킷을 기다린다. 이들도 템포러리 리스트에 저장해 놓는다. 다음 4번째 내지 7번째 패킷들은 완성된 트랜잭션 패킷이기 때문에, 바로 레포지토리에 저장한다. 8번째 패킷은 1번 서버와 관련된 패킷으로 역시 동기신호만 있고, 1번 서버와 관련된 것이기에 2번째 메모리 셀에 저장하여 업데이트되고, 계속해서 종료 신호가 있는 패킷을 기다린다. 앞서 첫 번째 메모리 셀에 할당되어 저장된 1번 패킷은 종료 신호가 있는 9번 패킷을 수신하여 완성된 트랜잭션으로 구분될 수 있다. 트랜잭션이 완성되면, 템포러리 리스트에서 1번 패킷의 기재를 삭제한다. 10번 패킷의 경우, 1003ms에 수신된 패킷이 저장되었고, 이후 2379ms에 수신된 패킷이 저장되었는데, 두 패킷 모두 동기신호만 있어 종료신호를 기다리고 있는데, 타임아웃 임계시간(예를 들어, 60초) 동안 종료신호가 있는 패킷이 수신되지 않는 경우, 실패 처리하고 불완전한 상태로 레포지토리에 저장한다. 그리고, 템포러리 리스트에서 삭제한다.

이를 정리하면, 장치는 다음의 규칙을 이용하여 트랜잭션 블록 내의 패킷 관련 정보를 레포지토리에 저장된다.

- 동기 신호와 종료 신호를 포함하는 완성된 트랜잭션에 대한 패킷은 바로 레포지토리에 저장한다.

- 동기 신호만 포함하는 미완성 트랜잭션에 대한 패킷은 레포지토리에 저장하면서 템포러리 리스트에 함께 저장한다. 이러한 패킷들은 이후의 동일 서버에서 종료 신호만 포함된 패킷을 기다린다.

- 동기 신호가 없는 미완성 패킷은 템포러리 리스트에서 관련된 기수신된 패킷(동기 신호가 있는 패킷)을 찾아서 레포지토리에 업데이트한다. 이때, 종료 신호(Fin)를 포함하고 있으면, 템포러리 리스트에서 삭제한다. 만약, 템포러리 리스트에 없으면, 새로운 동기신호로 처리한다. 예를 들어 이전 타임아웃된 패킷은 불완전한 트랜잭션으로 남겨놓고 레포지토리에 저장한다.

- 템포러리 리스트의 헤드(head)부터 타임아웃 임계시간과 비교하여 타임아웃 처리한다. 타임아웃이면, 실패 처리하고 템포러리 리스트에서 삭제한다.

- 1분 레포지토리(현재 레포지토리)의 저장이 완료되면, 템포러리 리스트는 계속 유지한다.

- 트랜잭션의 업데이트를 위해, 레포지토리는 이전 1분 레포지토리 1개만 계속 치환하면서 유지한다. 이는 타임아웃 임계시간이 하나의 레포지토리 디렉토리의 저장 시간(1분 레포지토리)과 동일하기 때문이다.

도 10은 본 발명의 일 실시예에 따른 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 저장 방법에 따라 트랜잭션 블록을 저장하는 레포지토리의 구성을 나타낸 개념도이다.

도 10을 참조하면, 장치는 트랜잭션 블록을 트랜잭션 단위로 구분하여 레포지토리에 저장한다. 이때, 1차적으로 1분 단위의 디렉토리를 생성하여 저장한다. 1분 단위 레포지토리에는, 트랜잭션 데이터, 통계 데이터 및 인덱스 데이터가 포함될 수 있다. 특히, 이 1분 단위 레포지토리는 1초에 100만 트랜잭션을 처리하는 성능(1M TR: 1,000TPS x 1,000 EA)을 가질 수 있고, 이에 1분에 60M TR을 처리할 수 있다. 이때, 트랜잭션 데이터와 통계 데이터는 수집 모듈이 생성하고, 인덱스 데이터는 인덱싱 모듈이 생성한다.

여기서, 트랜잭션 데이터는 트랜잭션 블록의 데이터로, 패킷의 헤더로부터 추출된 30여 가지의 헤더 정보를 포함하며, 이를 트랜잭션 단위로 업데이트한 것일 수 있다. 이는 약 6GiB 내지 6.5GiB의 크기를 가질 수 있다. 바람직하게는, 112Byte 크기의 트랜잭션 블록이 100만 개 있을 수 있고, 이것을 60초간 수집하여 저장한 것이기에, 112B x 1,000,000 x 60s = 6.26GiB의 크기를 가질 수 있다.

통계 데이터는 10초 단위 트랜잭션 블록의 통계로부터 산출되는 통계를 저장한다. 여기에는, 기본적으로, 이미 산출되어 트랜잭션 블록에 포함되느 10초 단위 통계치 60 개와 1분 단위 통계 데이터가 포함될 수 있다. 이는 약 2MiB 내지 2.5MiB의 크기를 가질 수 있다. 바람직하게는, 2.38MiB의 크기를 가질 수 있다.

인덱스 데이터는 시간 및 IP와 관련된 인덱스 데이터를 포함한다. 이는 패킷 수신 시간에 대한 것 및 서버 및 클라이언트 측 IP 데이터를 포함한다. 이는 약 450MiB 내지 500MiB의 크기를 갖는 것이 바람직하며, 보다 바람직하게는, 480MiB의 크기를 갖는 것이 좋다.

위와 같이, 트랜잭션 데이터, 통계 데이터 및 인덱스 데이터를 갖는 1분 레포지토리는 약 6.5GiB 내지 7GiB의 크기를 갖는 것이 바람직하며, 보다 바람직하게는, 약 6.74GiB의 크기를 갖는 것이 좋다.

1분 레포지토리는 10개가 모여 10분 레포지토리, 즉, 더 큰 크기의 디렉토리에 포함된다. 10분 레포지토리는 10개의 1분 레포지토리의 트랜잭션 데이터를 포함하며, 10개의 1분 레포지토리에 포함된 통계 데이터 및 인덱스 데이터를 포함한다. 즉, 10초, 1분 및 10분 통계를 저장하고 있다. 10분 레포지토리는 패킷 수신 시각과 관련된 연도, 달, 일 및 시간, 분으로 특정된다. 즉, 2020년 1월 9일 00시 00분부터 2020년 1월 9일 00시 10분까지의 데이터는 20200109_0000(yyyymmdd_hhmm) 디렉토리에 저장된다. 10분 레포지토리의 통계 데이터에는 10초 통계 60개, 1분 통계 10개, 그리고 10분 통계 1개가 포함되어 있다. 이때, 10분 레포지토리는 1분 레포지토리의 10배의 크기를 가질 수 있고, 약 67.4GiB의 크기를 가질 수 있다.

다음으로, 10분 레포지토리가 6개면 1시간이 되기 때문에, 6개의 10분 레포지토리 단위로 1시간 트랜잭션에 대한 네트워크 성능 통계를 산출하여 해당 레포지토리에 저장한다. 즉, 0000 디렉토리에 1시간 통계를 저장하면, 0010, 0020, 0030, 0040, 0050은 건너뛰고, 0100 디렉토리에 그 다음 1시간 통계를 저장한다. 즉, 00분 디렉토리에 1시간 통계를 저장하는 것이 바람직하다.

위와 같은 방식으로 144개의 10분 레포지토리를 생성하고 나면, 144개의 디렉토리를 1일 디렉토리(yyyymmmm 파일(예를 들어, 20200109)) 내에 저장한다. 해당 디렉토리에는, 1일 네트워크 성능 통계 정보가 포함될 수 있다. 1일 디렉토리에는, 144개의 10분 디렉토리, 그리고 1440개의 1분 디렉토리가 포함되며, 8640개의 10초 통계, 1440개의 1분 통계, 144개의 10분 통계, 24개의 1시간 통계, 그리고 1개의 1일 통계가 포함될 수 있다. 1일 레포지토리는 약 10TiB의 크기를 가질 수 있다.

도 11은 도 10의 레포지토리에 10초 통계, 1분 통계, 10분 통계, 1시간 통계 및 1일 통계를 저장하는 방법을 설명하기 위한 개념도이다.

도 11을 참조하면, 장치는 기본적으로 10초 네트워크 성능 통계 정보를 패킷 분석 모듈로부터 획득한다. 즉, 패킷 분석 모듈로부터 10초 단위로 수신되는 트랜잭션 블록 내에 10초 단위의 네트워크 성능 통계 정보가 포함되어 있기에, 장치는 이를 획득함으로써 바로 10초 단위 네트워크 성능 통계 정보를 확보한다. 그리고는, 이러한 10초 통계들 및 관련 트랜잭션 정보들을 6개를 합산하여 1분 단위 통계치 산출을 위한 정보를 확보하고, 이들의 합산값, 최소값, 최대값, 중간값, 및/또는 평균값 등의 통계치를 산출하여 1분 단위 통계 정보를 획득한다. 이때, 네트워크 성능 통계 정보의 종류는 트랜잭션 블록 내의 10초 통계와 동일할 수 있다. 즉, 1분 동안의 시간 내에 포함되는 트랜잭션에서의, 서버측 데이터 전송 속도의 통계값, 응답대기시간의 통계값, 트랜잭션 요청 및 응답에 대한 시간과 데이터 양의 통계값, HTTP 에러의 합계 값 정보 등을 포함할 수 있다. 다만, 반드시 10초 통계 정보의 종류와 동일해야만 하는 것은 아니다.

이렇게 산출된 1분 단위 통계 정보 및 트랜잭션 정보를 10개 확보하면 10분 단위 통계를 위한 데이터가 확보된다. 장치는 이러한 정보들을 이용하여 10분 통계를 생성한다. 동일한 방식으로 6개의 10분 통계 및 관련 트랜잭션 정보를 이용하여 1시간 통계를 생성하고, 1시간 통계 및 관련 트랜잭션 정보를 24개 이용하여 1일 통계치를 산출한다. 그리고는, 대응하는 디렉토리에 상기 통계 정보를 저장한다.

본 발명의 실시예에 있어서, 1분 통계치, 10분 통계치, 1시간 통계치 및 1일 통계치 중 적어도 하나는 1분 레포지토리의 저장 완료 시점이 현재 시점으로부터 1분 뒤기 때문에(현재 시점으로부터 이전 1분 레포지토리는 업데이트를 위해 열려있는 형태로 저장됨), 1분 레포지토리가 완전히 닫히는 시점에 관련 데이터를 업데이트하고, 업데이트된 내용을 가지고 통계치를 산출하여 저장하는 것이 바람직하다.

도 12는 레포지토리에 트랜잭션 데이터와 함께 저장되는 인덱스 데이터를 설명하기 위한 개념도이다.

도 12를 참조하면, 1분 레포지토리에는 인덱스 데이터가 포함된다. 인덱스 데이터에는 시간 인덱스(Time Index), IP 인덱스(IP Index) 및 텍스트 인덱스(Text Index)가 포함된다.

시간 인덱스는 패킷 수신 시각을 기준으로 인덱싱된다. 이는 초단위로 인덱스를 부착한다. 즉, 이는 초단위로 바로 접근할 수 있도록 하기 위한 인덱스이다. 시간 인덱스는 초 단위 시간 자체를 나타내는 데이터(20200109_010354: 2020년 1월 9일 1시 3분 54초), 초 단위로 시작되는 넘버를 나타내는 인덱스, 그리고 특정 트랜잭션의 시작 위치를 지시하기 위한 오프셋 데이터를 포함한다. 이에 따라, 1초 트랜잭션 블록의 기본 사이즈(112Byte일 수 있음)와 초 단위로 시작되는 넘버를 이용하여 특정 트랜잭션의 파일 위치를 검색할 수 있다. 여기서, 오프셋(offset)은 물리적 오프셋이 아니라 run-length 기준 오프셋이다. 각각의 인덱스 데이터는 4Byte로 구성되어 1분의 경우, (4+4+4) x 60s = 720 Byte의 크기를 가질 수 있다.

IP 인덱스는 서버측 IP(sIP)와 클라이언트측 IP(cIP)를 포함한다. 즉, 서버측 IP 및 클라이언트 IP를 모두 가지고 있을 수 있다. IP는 4Byte로 구성될 수 있다. 따라서, 서버측 IP와 클라이언트측 IP를 합치면 IP는 8Byte의 크기를 가질 수 있다. 특정 IP에 대한 인덱스는 IP 자체, IP에 시퀀셜하게(sequentially) 넘버를 부착한 인덱스 및 오프셋으로 표현된다. 정확하게 특정 서버와 관련된 특정 트랜잭션 정보를 특정하기 위해, 오프셋에 대한 번호만 리스트 형태로 가지고 있을 수 있다. 1분 레포지토리에는, 최대 60M 개의 IP가 저장 가능하다. 이때 IP가 전부 다르다면, 최대한 세로방향으로 길게 그 리스트가 생성될 수 있다. 반면, IP가 전부 동일하면, 오프셋으로만 구분되어야 하기에, 전체 가로방향(행)으로의 길이가 길어진다. 즉, 60M의 오프셋을 가질 수 있다. IP 인덱스의 크기는 약 240MiB의 크기를 가질 수 있다.

다른 예에서, IP 인덱스는 MAC 인덱스로 대체될 수 있다. 또는 IP와 MAC 주소를 유사한 방식으로 인덱싱하여 함께 저장할 수도 있다.

텍스트 인덱스는 URL, 도메인 등에 대한 해쉬 값이다. 텍스트 인덱스는 시간 인덱스 및 IP 인덱스가 오프셋을 통해 트랜잭션을 찾아가는 방향의 링크로 형성된 것과 다르게, 특정 트랜잭션 해쉬값으로부터 실제 텍스트 값을 찾는 방향으로의 링크로 그 방향이 다르게 되어 있다.

이 밖에, 상태를 가지고 데이터 검색을 위한 상태 인덱스(State Index), 그리고, 결과를 가지고 데이터 검색을 위한 결과 인덱스(Result Index) 및 응답 코드를 가지고 데이터 검색을 위한 응답 코드 인덱스(Rsp. Code Index)를 더 생성 및 저장할 수 있다.

도 13은 도 12의 인덱스를 이용하여 데이터 검색을 수행할 때, 검색 요청 및 그에 따른 필터링 과정을 설명하기 위한 개념도이다.

도 13을 참조하면, 앞서 도 12에서 설명한 시간 인덱스, 서버 및 클라이언트 IP 인덱스가 가장 기본적인 검색 조건으로 활용되는 인덱스이다. 이때, 시간은 거의 필수적으로 사용되는 것이 바람직하다. 위 3개의 인덱스 중 적어도 하나는 필수적으로 입력하도록 제어하는 것이 바람직하다. 다만, 이때, 반드시 모든 검색 결과를 보여줄 필요는 없다.

다음으로, 1차 추가검색 조건으로는 응답 코드 인덱스, 상태 인덱스 및 결과 인덱스가 포함될 수 있다. 이는 분석상황에 맞게 적절히 추가하면 된다.

그 다음으로 보다 명확한 특정 로그를 검색하기 위해서는 2차 추가 검색 조건을 입력하는 것이 바람직하다. 이는, 응답지연시간, wait의 수, 트래픽 속도 등의 다른 네트워크 성능 지표가 될 수 있다. 이때, 장치는 검색 후 정렬 기능을 지원할 수 있다.

이하, 도 14 내지 도 16은 분석 정보 수집 장치의 수집 대상인 트랜잭션 블록 내에 포함되는 정보들에 대해 보다 상세히 설명한다.

도 14는 도 4의 트랜잭션 블록 내의 트랜잭션 리스트의 상세 요소 정보의 구성을 구체적으로 나타낸 테이블이다.

도 14를 참조하면, 트랜잭션 블록 내에 포함된 트랜잭션 리스트는 하나의 트랜잭션에 대한 상세 정보(요소 정보)를 포함한다. 이는 client_ip, server_ip, client_port, server_port 정보를 포함한다. 이는 각각 클라이언트의 IP 정보, 서버의 IP 정보, 클라이언트의 포트 정보 및 서버의 포트 정보를 나타낸다. 이때, client_ip 및 server_ip 정보는 스트링(string)을 단위로 사용하여(예컨대, 222.103.141.187) 4 Byte의 크기를 가질 수 있다. client_port 및 server_port 정보는 넘버(number)를 단위로 사용하여(예컨대, 1254 또는 80), 2Byte의 크기를 가질 수 있다.

다음으로, 트랜잭션 블록은 패킷 수신 시간에 대한 정보로써 receive_time 정보를 포함할 수 있다. 이는 4 Byte의 크기를 가질 수 있다.

다음으로, 트랜잭션 리스트는 트랜잭션의 시작과 종료와 관련된 정보를 포함할 수 있다. 여기에는, start_usec 정보, end_usec 정보 및 fin_usec가 포함될 수 있다. 이는, 패킷의 소스 ip, 목적지 ip 및 타임 정보를 기반으로 동일한 소스(예컨대, 클라이언트)와 목적지(예컨대, 서버)에서 일정한 시간 구간 내에서 요청 패킷을 주고 그와 관련된 데이터를 모두 수신하였는지에 대한 내역을 분석함으로써 획득될 수 있다. 이는 각각 4 Byte의 크기를 가질 수 있다.

start_usec 정보는 트랜잭션이 완성되어 개시되는 시간이 될 수 있다(예컨대, 2012-07-18 22:33:06.288370). end_usec 정보는 트랜잭션 종료 시간을 백만 분의 1초 단위로 나타낸 것이다. fin_usec 정보는 트랜잭션 완전종료 시간을 백만 분의 1초 단위로 나타낸 것이다.

트랜잭션 시작과 종료와 관련하여, 트랜잭션 리스트에 포함될 수 있는 후보 요소 정보로는, start_time 정보, end_time 정보, fin_time 정보가 있다. start_time 정보는 트랜잭션 시작 시간(년월일 시분초: 예컨대, 2012-07-18 22:33:06)을 나타낸다. 앞서 설명한 start_usec 정보는 상기 start_time과 합쳐서 완성된 시간이 될 수 있다(예컨대, 2012-07-18 22:33:06.288370). end_time 정보는 트랜잭션 종료 시간을 나타낸다. 즉, 데이터의 종료(트랜잭션의 마지막 Response Data를 받은 시간)을 나타낸다. 예컨대, 2012-07-18 22:33:12로 표현될 수 있다. fin_time 정보는 트랜잭션이 종료된 후, 다음 트랜잭션이 오거나, 트랜잭션이 완료(Fin을 받음)되거나 타임아웃(Timeout)으로 끝나거나 하여 완전히 종료된 시간을 나타낸다. 예컨대, 2012-07-18 22:35:23로 표현될 수 있다. 후보 요소 정보는 사용자의 설정 또는 네트워크 상태의 변경에 따라 특정 시점에 트랜잭션 리스트에 포함되는 것으로 설정된 요소 정보를 대신하거나 아니면 추가적으로 트랜잭션 리스트에 포함될 수 있다. 즉, 단위 시간 당 패킷의 수가 기준 파라미터 값 이상 증가하면, start_usec 정보 대신 start_time 정보가 트랜잭션 리스트에 들어갈 수 있다. 후보 요소의 대체는 트랜잭션 상세 정보의 분류(예를 들어, 트랜잭션 시작/종료 시간 정보 분류, 트랜잭션 지연시간 정보 분류, 세션 응답/요청 패킷 분류, 트랜잭션 상태/결과 분류 등)를 고려하여, 동일 분류에서 이루어지도록 하는 것이 바람직하다. 다른 예에서, start_usec 정보가 포함된 상태에서 start_time 정보가 추가적으로 트랜잭션 리스트에 포함되도록 할 수 있다.

다음으로, 트랜잭션 블록은 RTT 정보, 요청시간 정보, 응답지연시간과 관련된 응답 및 요청에 대한 시간 정보(지연정보 포함)를 포함할 수 있다. 이는 tran_client_rtt, tran_req_time, tran_latency 및 tran_rsp_time으로 표현될 수 있다. 이들 정보는 각각 4 Byte의 크기를 가질 수 있다.

여기서, tran_client_rtt 정보는 해당 트랜잭션에서 클라이언트의 실시간 RTT를 나타낸다. tran_req_time은 요청전송시간에 대한 정보로써, 클라이언트로부터 서버로의 복수 개의 요청을 전송 시작한 시간부터, 해당 요청이 서버에 도달한 시간을 나타낸다.

tran_latency 정보는 트랜잭션 응답대기시간을 나타낸다. 이는 클라이언트가 요청을 보낸 후 서버로부터 첫 데이터를 받기까지의 대기 시간을 나타낸다. 이는 백만 분의 1초를 단위로 한다. 예컨대, 76328 값을 가질 수 있다. tran_rsp_time는 트랜잭션 응답 시간으로써, 응답 데이터의 전송 시간을 나타낸다. 즉, 서버가 응답 데이터를 전송한 시간을 나타낸다. 이 역시, 백만 분의 1초를 단위로 사용한다.

한편, 패킷 분석 모듈은 사용자와 서버 간의 네트워크 상의 패킷의 왕복도달 시간(RTT) 정보를 산출한다. 패킷 분석 모듈은 인스턴스에 에이전트 형태로 동작할 때, 부착된 인스턴스가 서버에 대응될 수 있다. 패킷 분석 모듈은 클라이언트와 서버 사이에 있다고 가정한다. 기본적인 동기화 시나리오를 가정하여, 최초 클라이언트가 동기신호(SYN)를 전송하고, 서버는 이를 수신하며, 서버는 수신된 동기신호에 응답하여 동기신호와 응답신호(ACK)를 함께 전송하고, 클라이언트는 서버로부터의 신호에 응답하여 응답신호(ACK)를 전송할 수 있다. 이러한 3개 신호의 송수신을 3-way Handshake라고 부를 수 있다.

이러한 신호 전송 시나리오에서, 패킷 분석 모듈은 클라이언트와 서버 사이에 있기 때문에, 클라이언트에서 출발하여 실제 서버에 동기신호(SYN)가 도착하는 시간보다 이른 T1 시점에 패킷 분석 모듈에 패킷이 도착한다. 그리고, 서버로부터의 동기신호 및 응답신호는 클라이언트 도착시점보다 이른 T2 시점에 패킷 분석 모듈에 도착한다. 마지막으로, 클라이언트에서의 응답신호(ACK)는 서버에서의 도착시점보다 이른 T3 시점에 패킷 분석 모듈에 도착한다.

이러한 관계에서, 패킷 분석 모듈은 3개 패킷 송수신 시점과 관련하여, T1 내지 T3 시간 정보를 확보할 수 있고, 서버에서의 도달시간에서 일정 시간 이른 시점으로 쉬프트된 RTT 값을 "T3-T1"을 이용하여 산출할 수 있다. 이는 네트워크 RTT라고 부를 수 있다.

네트워크 RTT를 보다 세분화하여, 서버에서의 RTT와 클라이언트에서의 RTT를 구분하여 산출할 수 있다. 서버에서의 RTT(sRTT)는 하나의 패킷에 대해 서버에서 지연되는 시간을 나타내고, 이는 "T2-T1"을 이용하여 산출할 수 있다.

또한, 클라이언트에서의 RTT(cRTT)는 클라이언트에서의 RTT로써, "T3-T2"를 이용하여 산출할 수 있다.

본 발명의 일 실시예에 따른 패킷 분석 모듈은 상기한 3개의 RTT, 네트워크 RTT, 서버 RTT 및/또는 클라이언트 RTT를 실시간으로 매 트랜잭션마다 산출하여 저장한다. 클라이언트 RTT는 tran_client_rtt 지표로써 트랜잭션 리스트에 포함되고, 서버 RTT는 server_rtt 지표에 대한 10초 단위 통계 정보 산출을 위해 사용된다.

패킷 분석 모듈은 다양한 지연지표를 산출할 수 있다. 앞서 설명한 것과 같이, 패킷 분석 모듈은 클라이언트와 서버 사이에 존재하며, 클라이언트는 복수 개의 요청 패킷을 서버로 전송하고, 서버는 복수 개의 요청에 대응하여 복수 개의 응답 패킷을 클라이언트로 전송하는 실시예를 가정한다.

패킷 분석 모듈은 패킷 분석 모듈에 최초 클라이언트 요청 패킷이 도달한 T1 시간, 마지막 클라이언트 요청 패킷이 도달한 T2 시간, 서버로부터 최초 응답 패킷이 도달한 T3 시간, 및 서버로부터 마지막 응답 패킷이 도달한 T4 시간을 미러링된 패킷의 도착시간을 통해 획득할 수 있다.

이때, 지연지표 중 요청전송시간(request time) 정보는 클라이언트로부터 서버로의 복수 개의 요청을 전송 시작한 시간부터, 해당 요청이 서버에 도달한 시간을 나타낸다. 이와 관련하여, 패킷 분석 모듈은 cRTT를 반으로 나눈 값을 통해, T1 시점을 기준으로 최초 요청 패킷이 클라이언트에서 출발한 시간을 알 수 있다. 또한, sRTT를 반으로 나눈 값을 통해 마지막 요청 패킷이 실제 서버에 도달한 시간을 알 수 있다. 이러한 산술적인 분석을 통해, "request time = cRTT/2 + (T2-T1) + sRTT/2"를 이용하여 산출할 수 있고, 일반적으로 sRTT 값은 매우 작은 값이므로, cRTT/2 + (T2-T1) 값과 근사한 값으로 산출된다. 요청전송시간 값은 tran_req_time이라는 지표로써, 트랜잭션 리스트에 하나의 정보로 포함되며, 10초 통계 정보에도 10초 동안의 요청전송시간의 합산 값이 포함된다.

다음으로, 응답대기시간(latency)은 클라이언트의 요청과 연관된 URL로부터 요청과 연관된 컨텐츠 또는 데이터를 서버가 수신할 때까지의 응답지연시간을 나타낸다. 즉, 서버는 데이터를 수신하자마자 클라이언트로 전송을 수행한다고 보고, 서버가 해당 URL로부터 요청과 관련된 첫 데이터를 수신할 때까지의 시간을 나타낸다. 이는 결국 (T2-T3)에서 sRTT 값을 뺀 값으로 산출된다. 여기서, sRTT 값을 무시해도 될 정도로 작은 값일 수 있으므로, "T2-T3"가 응답대기시간이 될 수 있다. 응답대기시간 정보는 tran_latency라는 지표로써, 트랜잭션 리스트에 하나의 정보로 포함되며, 10초 통계 정보에도, 응답대기시간의 합산 값, 최소값 및 최대값이 포함될 수 있다.

다음으로, 응답데이터 전송시간(response time)은 서버가 클라이언트로 요청과 관련된 컨텐츠를 전송하는데 소요되는 시간을 나타낸다. 이는 "response time = sRTT/2 + (T4-T3) + cRTT/2"의 수학식을 이용하여 산출된다. sRTT가 매우 작은 값인 것을 고려하면, 이는 (T4-T3) + cRTT/2 값과 거의 일치한다. 응답데이터 전송시간 값은 tran_rsp_time이라는 지표로써, 트랜잭션 리스트에 하나의 정보로 포함되며, 10초 통계 정보에도 10초 동안의 응답데이터 전송시간의 합산 값이 포함된다.

클라이언트 측에서 요청을 전송한 후부터 요청과 관련된 전체 응답 데이터를 수신할 때까지의 이용시간(used time)을 산출하면, 이는 결국 요청전송시간과 응답대기시간 및 응답데이터 전송시간의 합이므로, "used time = (T4-T1) + cRTT"를 이용하여 산출된다. 이용시간 역시, 트랜잭션 리스트에 포함되는 후보 요소 정보로써 기능할 수 있다.

다시 도 14를 참조하면, client_ip, server_ip, client_port, server_port, receive_time, start_user, end_usec, fin_usec, tran_client_rtt, tran_req_time, tran_latency, 및 tran_rsp_time에 이어, 트랜잭션 리스트에는, session_req_pkts 정보 및 session_rsp_pkts 정보가 포함될 수 있다. 이는 트랜잭션을 요청하는 데이터 패킷의 수와 이에 대한 응답 패킷의 수를 나타낸다. 이는 각각 4 Byte의 크기를 가질 수 있다.

session_req_pkts 정보는 트랜잭션 요청 데이터 패킷의 수를 나타내며, 이는 특정 클라이언트가 요청 데이터로써 보낸 패킷의 수를 기반으로 산출된다. 이는 넘버를 단위로 한다.

session_rsp_pkts 정보는, 트랜잭션 응답 패킷의 수를 나타내며, 특정 서버가 클라이언트로 보낸 응답 데이터의 패킷 수를 기반으로 산출된다. 넘버를 단위로 한다.

추가적으로, 트랜잭션 리스트에는 session_pps 정보가 포함될 수 있다. 이는, session_pps 정보는 세션의 실시간 PPS를 나타내며, 현재 맺어진 세션의 PPS를 기반으로 산출된다. 단위는 넘버이다. 이 역시 4 Byte의 크기를 갖는 것이 바람직하다.

다른 예에서, 트랜잭션과 관련된 세션의 pps 속도 관련 지표로써, sess_max_pps 정보가 후보로써 고려될 수 있다. sess_max_pps 정보는 세션의 최대 PPS를 나타내며, 해당 세션이 사용될 기간동안의 최대 PPS를 기반으로 산출된다. 단위는 넘버이다.

다음으로, 트랜잭션 리스트에는, content_len 정보가 포함될 수 있다. 이는, content_len, 정보는 응답 헤더의 콘텐츠 길이를 나타내며, 서버가 보낸 응답 HTTP 헤더 중 포함된 콘텐츠의 길이를 나타낸다. 예컨대, "/jsp/front/search/include/akc.jsp의 byte"를 의미할 수 있다. 단위는 스트링이고, 그 크기는 4 Byte를 갖는 것이 바람직하다.

그 다음으로, 트랜잭션 리스트에는, state 정보 및 result 정보가 포함될 수 있다. 이는 각각 1 Byte의 크기를 가질 수 있다.

보다 구체적으로, state 정보는 트랜잭션 상태를 나타낸다. 이는 7개의 넘버로써 표현될 수 있으며, 다음과 같다.

트랜잭션 상태 코드(Code)

1 - session_finish : 초기상태

2 - 3whs_syn_sent : 3 handshake 중 클라이언트가 syn을 보낸상태

3 - 3whs_syn_received : 3 handshake 중 클라이언트가 syn/ack를 받은상태

4 - 3whs_ack_received : 3 handshake 중 서버가 ack를 받은상태

5 - session_connected : 세션이 맺어진 상태

6 - session_request : 클라이언트가 Request(요청)을 한 상태

7 - session_response : 서버가 Response(응답)을 한 상태

다음으로, 트랜잭션 결과를 "result"라는 정보 이름으로 리스트에 포함시킨다. 이는 10개의 넘버로써 표현될 수 있으며, 다음과 같다.

트랜잭션 결과 코드

1 - trans_finish : 한 트랜잭션이 끝난 상태

2 - client_finish : 세션을 클라이언트가 종료한 상태 (Finish-FIN을 보냄)

3 - server_finish : 세션을 서버가 종료한 상태 (Finish-FIN을 보냄)

4 - client_reset : 세션을 클라이언트가 종료한 상태 (Reset-RST를 보냄)

5 - server_reset : 세션을 서버가 종료한 상태 (Reset-RST를 보냄)

6 - client_timeout : 클라이언트가 요청을 보내는 중 Timeout에 걸려 종료된 상태

7 - server_timeout : 서버가 응답을 보내는 중 Timeout에 결려 종료된 상태

8 - session_error : HTTP 세션 오류

9 - req_parser_error : HTTP Request Header 오류

10 - rsp_parser_error : HTTP Response Header 오류

그 다음으로, 트랜잭션 리스트에는, method 정보가 포함될 수 있다. 이는 1 Byte의 크기를 가질 수 있다. method 정보는 요청 메소드(POST, GET, HEAD, PUT ...)의 종류로써, 클라이언트가 요청한 요청 메소드의 타입을 나타낸다. 단위는 스트링이다.

추가적으로, 트랜잭션 리스트에는, response_code_number 정보가 포함될 수 있다. response_code_number 정보는 응답 결과로써, HTTP 상태 코드로 나타낸다. 예컨대, 서버가 응답한 Response Status Code로 "200, 304, 404, 500 ??" 중 하나의 값으로 표현될 수 있다. 단위는 스트링이다. 이 역시, 1 Byte의 크기를 갖는 것이 좋다.

다음으로, session_req_pkts 및 session_rsp_pkts에 이어, 트랜잭션 요청 및 응답과 관련된 추가적인 정보로써, session_req_bytes 정보 및 session_rsp_bytes 정보가 트랜잭션 리스트에 포함될 수 있다. 여기서, session_req_bytes 정보는, 트랜잭션의 요청 데이터의 바이트를 나타내며, 특정 클라이언트가 요청 데이터로써 보낸 바이트의 양을 기반으로 산출된다. 단위는 byte이다. session_rsp_bytes 정보는 트랜잭션의 응답 데이터의 바이트를 나타내며, 특정 서버가 응답 데이터로써 보낸 바이트의 양을 기반으로 산출된다. 단위는 byte이다. 이들 지표는 8 Byte의 크기를 가질 수 있다.

트랜잭션과 관련된 세션의 속도 정보로써, session_pps에 이어, session_bps 정보가 트랜잭션 리스트에 포함될 수 있다. session_bps 정보는 세션의 실시간 BPS를 나타내며, 현재 맺어진 세션의 BPS(Bit Per Second)를 기반으로 산출된다. 단위는 넘버이다. 이는 8 Byte의 크기를 가질 수 있다.

마지막으로, 텍스트 리스트와 연관되는 요소 정보들이 트랜잭션 리스트의 말미에 생성될 수 있다. 이는 domain 정보, URL 정보 및 mime 정보를 포함한다. 이는 해쉬 값으로 생성될 수 있다. 이들은 8 Byte의 크기를 가질 수 있다.

domain 정보는 클라이언트가 요청한 URL 중 도메인과 연관된 정보를 나타낸다. 이는 스트링을 단위로 한다. 예컨대, "www.lgmobile.co.kr"과 같은 정보를 나타낸다. 이와 같은 텍스트는 텍스트에 기록하고, 여기에는 8 Byte의 해쉬값이 표시된다.

URL 정보는 클라이언트가 요청한 URL로써, "/jsp/front/search/include/akc.jsp"와 같은 정보를 나타낸다.

mime 정보는 응답 헤더 콘텐츠 타입을 나타낸다. 예컨대, text/html 등 중 하나일 수 있다. 이는 서버가 보낸 응답 HTTP 헤더 중 포함된 콘텐츠 타입 정보이다.

트랜잭션 리스트를 전체적으로 살펴보면, 여기에는, client_ip, server_ip, client_port, server_port, receive_time, start_user, end_usec, fin_usec, tran_client_rtt, tran_req_time, tran_latency, 및 tran_rsp_time, session_req_pkts, session_Rsp_pkts, session_pps, content_len, state, result, method, response_code_number, session_req_bytes, session_rsp_bytes, session_bps, domain, URL, mime 정보의 총 26개의 정보가 포함될 수 있다. 즉, 하나의 트랜잭션 당 26개의 정보를 트랜잭션을 모니터링하기 위한 필수정보로써 1차적으로 트랜잭션 블록 생성부에서 생성한다. 그리고, 그 크기는 112 Byte인 것이 적절하다. 다만, 여기서 사용자 설정을 통해 후보 요소 정보를 더하거나 빼서 약 20개 정보 내지 30 개 정보를 트랜잭션 리스트로 사용할 수 있다.

향후 트랜잭션 리스트에 포함될 수 있는 후보 요소 정보로는, 세션이 맺어진 후 생성된 트랜잭션 번호를 나타내는 transaction_number 정보, 앞서 설명한, start_time, end_time, fin_time, used_time, 트랜잭션 완전종료까지의 사용 시간을 나타내는, fin_used_time 정보가 포함될 수 있다. 또한, 해당 URL의 실시간 사용자(Client IP기준)의 수를 나타내는 users 정보, URL이 사용되고 있을 시간 동안의 해당 URL의 최대 사용자수를 나타내는 max_users 정보, 해당 URL의 실시간 세션 수를 나타내는 sessions 정보, URL이 사용되고 있을 시간 동안의 해당 URL의 최대 세션 수를 나타내는 max_sessions 정보, 해당 URL의 실시간 Wait 수를 나타내는 wait 정보, URL이 사용되고 있을 시간 동안의 해당 URL의 최대 응답대기 세션 수를 나타내는 max_wait 정보가 후보 요소 정보로 고려될 수 있다. 여기서, wait는 응답대기 중인 세션의 수를 나타낸다. 이는 도 10을 통해 보다 상세히 설명한다.

한편, 해당 URL의 실시간 UPS(User Per Second)를 나타내는 ups 정보, 해당 URL의 Max UPS를 나타내는 max_ups 정보, 해당 URL의 실시간 CPS(Connection Per Second)를 나타내는 cps 정보, 해당 URL의 Max CPS를 나타내는 max_cps 정보, 해당 URL의 실시간 TPS(Transaction Per Second)를 나타내는 tps 정보, 해당 URL의 Max TPS를 나타내는 max_tps 정보, 해당 URL의 Idle을 나타내는 idle 정보 역시 후보 요소 정보로서, 고려될 수 있다. 네트워크의 속도와 관련된 CPS, TPS 등의 산출 방법은 이하 도 11을 통해 보다 상세히 설명한다.

또한, 응답 헤더와 관련된 정보로 referrers 정보, 클라이언트가 보낸 요청 HTTP 헤더 중 포함된 에이전트를 나타내는 agent 정보, 및 클라이언트가 보낸 요청 HTTP 헤더 중 포함된 쿠키와 연관된 정보를 나타내는 cookie 정보도 후보 요소 정보로 고려될 수 있다.

또한, 특정 서버의 네트워크 서비스와 관련된 정보로써, 해당 서버의 실시간 나라 수를 나타내는 server_countrys, 해당 서버의 Max Country 수를 나타내는 server_max_countrys, 해당 서버의 실시간 에러(400, 500대 Response Code)의 수를 나타내는 server_error, 해당 서버의 실시간 사용자 수(Client IP 기준)를 나타내는 server_user, 해당 서버의 최대 사용자 수를 나타내는 server_max_user, 해당 서버의 실시간 세션 수를 나타내는 server_sessions, 해당 서버의 Max 세션 수를 나타내는 server_max_sessions, 및 서버에서의 속도들과 관련된 지표로써, server_bps, server_max_bps, server_pps, server_max_pps, server_rtt, server_max_rtt, server_ups, server_max_ups, server_cps, server_max_cps, server_tps, server_max_tps, server_hps, server_max_hps, server_wait, server_max_wait, server_idle 정보가 트랜잭션 리스트에 포함될 요소 정보로서 고려될 수 있다. 다만, 서버측과 관련된 정보는 10초 단위 통계 정보에 다수 포함되므로, 트랜잭션 리스트에 중복하여 표시하지 않아도 된다.

server_error 정보는 해당 서버의 실시간 에러(400, 500대 Response Code)의 수를 나타낸다. 예컨대, 203.247.157.199 서버가 응답한 Response Status Code 중 400~599까지의 사용자 에러 및/또는 서버 에러의 수를 나타낼 수 있다.

server_sessions 해당 서버의 실시간 세션 수를 나타낸다. server_max_sessions 정보는 해당 서버의 Max 세션 수를 나타낸다. server_bps 정보는 해당 서버의 실시간 BPS를 나타낸다. server_max_bps 정보는 해당 서버의 Max BPS를 나타낸다. server_pps 정보는 해당 서버의 실시간 PPS를 나타낸다. server_max_pps 정보는 해당 서버의 Max PPS를 나타낸다.

server_rtt 정보는 해당 서버의 실시간 RTT를 나타낸다. server_max_rtt 정보는 해당 서버의 Max RTT를 나타내며, 예컨대, 이는 "203.247.157.199 서버의 최대 평균 RTT"로 해결될 수 있다. server_rtt 정보 및 server_max_rtt 정보의 단위는 micro sec이다. 특히, server_rtt는 10초 통계 정보 산출에 이용될 수 있다.

server_ups 정보는 해당 서버의 실시간 UPS를 나타낸다. 이는 "203.247.157.199 서버의 실시간 UPS"를 나타낼 수 있고, 이는 203.247.157.199 서버에는 초당 1명 정도의 사용자가 연결되고 있음을 의미한다.

server_max_ups 정보는 해당 서버의 Max UPS를 나타낸다.

server_cps 정보는 해당 서버의 실시간 CPS를 나타내고, 예컨대, "203.247.157.199 서버의 실시간 CPS"를 나타낼 수 있다. 이는 203.247.157.199 서버에는 초당 15개 정도의 세션이 연결되고 있음을 의미한다.

server_max_cps 정보는 해당 서버의 Max CPS를 나타낸다.

server_tps 정보는 해당 서버의 실시간 TPS를 나타내며, 예컨대, "203.247.157.199 서버의 실시간 TPS"를 나타낼 수 있다. 이는 203.247.157.199 서버에는 초당 79개 정도의 트랜잭션이 발생되고 있음을 나타낸다.

server_max_tps 정보는 해당 서버의 Max TPS를 나타낸다.

server_hps 정보는 해당 서버의 실시간 HPS(Hit Per Second: 초당 요청하는 URL의 수)를 나타낸다. 예컨대, "203.247.157.199 서버의 실시간 HPS"를 나타낼 수 있다. 이는 203.247.157.199 서버r에는 초당 79개 정도의 URL이 요청되고 있음을 의미한다.

server_max_hps 정보는 해당 서버의 Max HPS를 나타낸다.

server_wait 정보는 해당 서버의 Wait 수를 나타낸다. 예컨대, "203.247.157.199 서버의 실시간 Wait 수"를 나타낼 수 있다. 이는 203.247.157.199 서버에는 현재 206개의 세션 중 46개의 세션이 응답대기 중임을 타나낼 수 있다.

server_max_wait 정보는 해당 서버의 Max Wait 수를 나타낸다.

server_idle 정보는 해당 서버의 Idle Time을 나타낸다. 예컨대, "203.247.157.199 서버에 요청이 없었던 시간"을 나타낼 수 있다. 해당 서버가 접속자가 많은 경우 Idle은 짧아지고 접속자가 작을 경우 Idle이 길어진다. 단위는 micro sec이다.

추가적으로, 특정 클라이언트의 네트워크 서비스와 관련된 정보로써, 클라이언트의 나라 코드(KR ..)를 나타내는 client_country_code, 클라이언트의 실시간 에러 수를 나타내는 client_error, 클라이언트의 실시간 서버 접속 수를 나타내는 client_servers, 클라이언트의 최대 동시 서버의 수를 나타내는 client_max_servers, 클라이언트의 실시간 세션 수를 나타내는 client_sessions, 클라이언트의 최대 세션 수를 나타내는 client_max_sessions가 트랜잭션 리스트에 포함될 요소정보 후보로 고려될 수 있다. 이외에, 클라이언트 측 속도 관련 정보로써, client_bps, client_max_bps, client_pps, client_max_pps, client_max_rtt, client_sps, client_max_sps, client_cps, client_max_cps, client_tps, client_max_tps, client_hps, client_max_hps, client_wait, client_max_wait 및 client_idle 정보가 추가적으로 고려될 수 있다.

마지막으로, 트랜잭션 리스트에 포함되는 것으로 고려될 수 있는 후보 요소 정보는 org, city_id, isp_id, os_id, browser_id, mobile_id, telcom_id 정보가 있다. 여기서, org 정보는 IP 기반 클라이언트의 조직을 나타낸다. 예컨대, "222.103.141.187 Client의 조직"은 Korea Telecom임을 나타낼 수 있다. city_id 정보는 IP 기반 클라이언트의 City Code를 나타낼 수 있다. 예컨대, "222.103.141.187 Client의 City"는 Seoul임을 나타낼 수 있다. isp_id 정보는 IP 기반 클라이언트의 ISP Code를 나타낸다. 예컨대, "222.103.141.187 Client의 ISP"는 Korea Telecom임을 나타낼 수 있다. os_id 정보는 클라이언트의 Client의 OS Code를 나타낸다. 이를 통해, 해당 클라이언트가 OS로 Win XP를 사용하는지, iOS를 사용하는지, 안드로이드를 사용하는지에 대한 정보를 확인할 수 있다. browser_id는 클라이언트의 Browser Code를 나타낸다. 이를 통해, 해당 클라이언트가 웹 브라우저로, explorer를 사용하는지, chrome을 사용하는지, MSIE9를 사용하는지에 대한 정보를 확인할 수 있다. mobile_id 정보는 클라이언트의 Mobile Code를 나타낸다. 이는 클라이언트의 기기 식별 정보로써, 삼성, 팬택, 애플 기기인지에 대한 정보를 나타낸다. telcom_id 정보는 클라이언트의 TelCom Code를 나타낸다. 이는 클라이언트의 통신사가 SKT인지 KT인지, LGT인지에 대한 정보를 나타낸다.

더욱이, 서버는 복수 개의 클라이언트로부터 적어도 하나의 요청을 처리하기 때문에, 하나의 서버에서도 상기 요청들과 관련하여 복수 개의 세션들을 처리한다. 이때, 서버에서의 처리 시간이 길어지면 클라이언트에서의 대기시간이 길어지게 되고, 이는 클라이언트 장치의 사용자로 하여금 인내심을 요구하게 된다. 따라서, 서버에서의 이러한 응답대기 세션 수(wait) 정보는 상당히 중요한 의미를 갖는다.

응답대기 세션 수는 요청과 연관된 복수 개의 세션들 중 서버에서의 처리를 거쳐 실제 응답데이터가 클라이언트로 전송된 세션을 뺀 나머지 세션의 수로 산출된다. 예컨대, 3개의 세션에 대해 1개의 세션에 대한 응답만 이루어진 경우, 응답대기 세션 수, wait = 3-1 = 2로써 산출된다. 즉, 패킷 분석 모듈은 클라이언트와 서버 사이에 존재하여 양자 간에 송수신되는 패킷들을 모두 확보 가능하므로 현재 서버 내에서 처리 중인 응답대기 세션의 수를 명확히 파악할 수 있다.

서버에서 특정 요청에 대한 처리가 완료되었는지 여부는, 소스 ip와 목적지 ip를 기반으로 특정 URL에 대한 요청에 대한 응답 패킷이 클라이언트로 전송되었는지를 기반으로 확인할 수 있다. 응답 패킷의 경우, 요청 패킷에서 나타난 상기 특정 URL과 연관되어 있으면서, 목적지 ip와 소스 ip가 요청 패킷과 반대로 포함되었는지 여부를 확인함으로써 파악 가능하다.

한편, 하나의 트랜잭션은 클라이언트와 서버 간에 적어도 하나의 요청과 상기 적어도 하나의 요청에 따른 적어도 하나의 응답데이터 패킷을 포함한다. 도 11의 실시예에서는 하나의 GET 요청에 대해 3개의 응답 데이터 패킷이 하나의 트랜잭션을 이루고 있는데, 이는 반드시 1:3의 관계를 가져야 하는 것은 아니고, 요청 패킷이 더 많고, 해당 요청 패킷에 대응 응답 데이터 패킷이 더 적은 관계를 가져도 무방하다.

이러한 트랜잭션도 네트워크 서비스의 속도 및 지연과 연관하여 중요한 의미를 갖는다. 이에, 패킷 미러링 장치는 초당 새롭게 시도되는 트랜잭션의 수를 산출한다. 이는 TPS라고 한다. 또한, 특정 클라이언트와 특정 서버 간의 연결의 수, 이를 커넥션(connection)이라 부를 수 있는데, 초당 새롭게 시도되는 커넥션의 수를 산출한다. 이는 CPS라고 한다.

이외에도, 초당 연결되는 사용자의 수를 나타내는 UPS(User Per Second) 정보 및 특정 클라이언트, 특정 서버 또는 특정 세션을 통해 초당 송수신되는 데이터의 양을 나타내는 BPS 정보도 주기적으로 산출한다. 초당 송수신되는 패킷의 수를 나타내는 PPS 정보, 초당 요청하는 URL의 수를 나타내는 HPS 정보 및 초당 연결되는 서버의 수를 나타내는 SPS(Server Per Second) 정보도 역시 주기적으로 산출한다.

도 15는 도 4의 트랜잭션 블록 내의 텍스트 리스트(text list)의 구성을 구체적으로 나타낸 테이블이다.

도 15를 참조하면, 텍스트 리스트는 도메인 정보, URL 정보 및 mime 정보와 대응되는 텍스트 정보를 포함할 수 있다. 하나의 텍스트에 해쉬 함수를 적용하여 특정 값의 색인(index) 값을 생성한다. 생성되는 색인 값은 충돌 방지를 위해 H-1 해쉬 값과 H-2 해쉬 값의 연결로 생성될 수 있다. 즉, 제 1 텍스트는 H-1__TEXT1 해쉬값과 H-2__TEXT1 해쉬값의 연결로 생성될 수 있다. 이는 트랜잭션 리스트의 특정 정보와 연관된다. 예를 들어, 제 1 텍스트는 domain 정보와, 제 2 텍스트는 URL 정보와, 그리고 제 3 텍스트는 mime 정보와 연관될 수 있다.

이때, 트랜잭션 리스트에 domain 정보로 생성된 8 Byte의 값 역시 동일한 색인을 나타내는 해쉬 값으로 표시된다. 다만, 나중에 입력된 정보와의 충돌 방지를 위해, H-1 해쉬값과 H-2 해쉬값을 연결리스트로 사용하여 써서 서로 간에 충돌이 나지 않도록 하여 두 리스트의 값들을 매칭시킨다.

도 16은 도 4의 트랜잭션 블록 내의 통계 정보의 구성을 구체적으로 나타낸 테이블이다.

도 16을 참조하면, 트랜잭션 블록은 일정시간(예컨대, 10초) 동안의 패킷 분석의 통계치를 나타내는 통계 정보를 포함한다. 통계 정보에는 약 30개 정도의 통계 정보가 포함될 수 있다. 통계 정보로 트랜잭션 리스트의 트랜잭션에 대한 상세 정보를 그대로 사용하는 것도 있고, 트랜잭션 상세 정보로부터 평균값(mean), 최대값(max), 최소값(min), 중간값(median) 및 합산값(sum)과 같은 산출치를 사용하는 것도 있다. 또는, 트랜잭션 리스트에는 포함되어 있진 않으나, 후보 요소 정보 또는 후보 요소 정보로부터 산출된 값이 포함될 수도 있다.

통계 정보에 포함되는 산출치를 보다 구체적으로 살펴보면, 통계 정보에는 4 Byte 크기의 서버 IP 정보(server_ip), 4 Byte 크기의 통계 완료 시각 정보(stats_time) 및 8 Byte 크기의 도메인 정보(domain)가 포함될 수 있다.

server_ip 정보에는 10초 동안의 트랜잭션과 관련된 서버의 IP 정보가 포함된다. stats_time 정보는, 해당 통계의 완료 시각에 대한 정보가 포함된다. 이는, (mmddhhmms0에서 끝자리 0을 제외한 전체 9자리 정수로 표현될 수 있다. 예를 들어, 5월 21일 19시 38분 0초 내지 9초 까지의 통계는 052119381로 저장된다. 만약 끝자리가 0이면 10초 통계가 아닌 1분, 10분등의 누산된 통계를 나타낸다. 도메인 정보는 10 동안의 트랜잭션과 관련된 도메인 정보가 포함된다.

다음으로, 10초 통계정보에는, 해당 트랜잭션과 관련된 서버의 트랜잭션 상태를 나타내는 다음의 정보들이 포함될 수 있다. 여기에는, server_user 정보, server_sessions 정보, server_session_c 정보, server_session_error 정보 및 server_transactions 정보가 포함되며, 위 정보들은 10초 동안의 트랜잭션들의 상기 지표 값의 합산 값(sum)으로 표시된다. 상기 정보들은 각각 8 Byte의 크기를 갖는 것이 바람직하다.

보다 구체적으로, server_user 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 실시간 사용자 수(Client IP 기준)의 합산값을 나타낸다. server_sessions 정보는 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 실시간 세션들의 합산값을 나타낸다. server_session_c 정보는 10초 동안의 트랜잭션과 관련된 서버의 session의 누적값을 나타낸다. 이는 일정한 시점에서 reset되는 값을 갖는다. 앞서 설명한 server_session은 해당 10초 동안의 session 수이므로, 10초 간격으로 끊어질 수 없다. 따라서 해당 서버의 실제 session 수는 server_session의 누적값으로 해결할 수 없기 때문에, 일정한 시간 단위로 server_session_c 값을 유지하는 것이 바람직하다.

다음으로, server_session_error 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 실시간 에러(400, 500대 Response Code)의 수의 합산값을 나타낸다. 그리고, server_transactions 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 트랜잭션의 수의 합산값을 나타낸다. 다수의 트랜잭션이 모여 하나의 세션을 이룰 수 있다.

다음으로, 10초 통계정보에는, 해당 트랜잭션과 관련된 서버의 트랜잭션에 사용되는 패킷의 전송속도와 관련된 통계정보들이 포함될 수 있다. 여기에는, server_bps 정보, server_req_bps 정보, server_rsp_bps 정보, server_pps 정보, server_ups 정보, server_cps 정보, server_tps 정보, server_hps 정보 및 server_rtt 정보, server_wait 정보, server_syn_wait 정보가 포함되며, 위 정보들은 10초 동안의 트랜잭션들의 상기 지표 값의 합산 값(sum), 최소값(min) 및 최대값(max)으로 표시된다. 상기 정보들은 각각 24 Byte의 크기를 갖는 것이 바람직하다. 즉, 합산값, 최소값 및 최대값이 각각 8 Byte의 크기를 가질 수 있다.

보다 구체적으로, server_bps 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 bps의 합산값, 최소값 및 최대값을 나타낸다. server_req_bps 정보는 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 요청(request)과 연관된 패킷들의 bps 값들의 합산값, 최소값 및 최대값을 나타낸다. 즉, 이를 통해, 클라이언트 측의 속도를 유추할 수 있다.

server_rsp_bps 정보는 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 요청에 대한 응답(response)과 연관된 패킷들의 bps 값들의 합산값, 최소값 및 최대값을 나타낸다. 이를 통해 서버측의 속도를 유추할 수 있다. server_pps 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 pps의 합산값, 최소값 및 최대값을 나타낸다. server_ups 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 ups의 합산값, 최소값 및 최대값을 나타낸다. server_cps 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 cps의 합산값, 최소값 및 최대값을 나타낸다. server_tps 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 tps의 합산값, 최소값 및 최대값을 나타낸다. server_hps 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 해당 서버의 실시간 hps의 합산값, 최소값 및 최대값을 나타낸다. server_rtt 정보는 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 실시간 RTT 값의 합산값, 최소값 및 최대값을 나타낸다. 다음으로, server_wait 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 wait 수의 합산값, 최소값 및 최대값을 나타낸다. 요청 이후에 응답이 끝나지 않은 session의 수로 산출된다.

그리고, server_syn_wait 정보는, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들로 전달 또는 서버들로부터 전달되는 동기 패킷(syn)의 wait 수의 합산값, 최소값 및 최대값을 나타낸다. 세션에 따라서 동기화(syn)가 완성되지 않은 상태나, 완료(fin)가 완료되지 않은 상태가 10초 통계 작성 시점에 발생할 수 있기 때문에, 이를 보완하는 용도로 작성된 필드이다.

다음으로, 10초 통계정보에는, 해당 트랜잭션과 관련된 서버의 Idle Time과 관련된 정보가 포함된다. 이는, server_idle 지표로 표현되며, server_idle 지표들의 합산값(sum)으로 산출된다. 이는 8 Byte의 크기를 갖는 것이 바람직하다. 보다 구체적으로, 10초 동안의 트랜잭션들과 관련된 적어도 하나의 서버들의 Idle Time을 나타낸다. 즉 해당 서버(들)에 요청이 없었던 시간을 나타내며, 이 시간들의 합산값을 상기 통계 값에 표시한다. 단위는 micro sec인 것이 바람직하다.

다음으로, 10초 통계정보에는, 해당 트랜잭션들에서 나타난 HTTP 응답 코드(HTTP response code)에 대한 정보들이 포함될 수 있다. 이는 에러 응답 코드를 나타낸다. 여기에는, rsp_400 정보, rsp_500 정보, rsp_300 정보, 및 rsp_200 정보가 포함되며, 위 정보들은 10초 동안의 트랜잭션들에서 특정 에러의 수의 합산 값(sum)으로 표시된다. 상기 정보들은 각각 8 Byte의 크기를 갖는 것이 바람직하다.

보다 구체적으로, rsp_400 정보는, 10초 동안의 트랜잭션들에서 400 에러의 발생 수의 합산값을 나타낸다. 즉, 요청 실패(bad request)의 횟수의 합계를 나타낸다. rsp_500 정보는, 10초 동안의 트랜잭션들에서 500 에러의 발생 수의 합산값을 나타낸다. 즉, 웹 서버가 요청사항을 수행할 수 없음을 나타내는 서버 내부 오류(internal server error)의 횟수의 합계를 나타낸다. rsp_300 정보는, 10초 동안의 트랜잭션들에서 최근에 옮겨진 데이터를 요청하는 300 에러(Multiple Choises)의 발생 수의 합산값을 나타낸다. rsp_200 정보는, 10초 동안의 트랜잭션들에서 에러 없이 전송 성공된 200 응답의 발생 수의 합산값을 나타낸다.

다음으로, 10초 통계정보에는, 해당 트랜잭션과 관련된 URL에서의 응답대기시간에 대한 것으로 특정 웹 페이지에서의 실시간 응답대기시간의 합산값, 최소값 및 최대값을 나타낸다. 이는 24 Byte의 크기를 갖는 것이 바람직하다.

마지막으로, 10초 통계정보에는, 해당 트랜잭션과 관련된 요청전송시간(tran_req_time), 응답데이터 전송시간(tran_rsp_time), 요청 데이터의 양을 나타내는 req_byte 및 응답데이터의 양을 나타내는 rsp_byte 값의 통계정보가 포함된다. 이는 합산값으로 표현되는 것이 바람직하며, 각각 8 Byte의 크기를 가질 수 있다.

보다 구체적으로, 요청전송시간(tran_req_time) 정보는 10초 동안의 트랜잭션과 관련된 요청 데이터(예컨대, 클라이언트로부터 서버로의 요청들)의 요청 전송 시간부터, 요청이 서버에 도달한 시간 값으로 산출된다. 이는 적어도 하나의 요청들의 요청전송시간 값들의 합으로 산출될 수 있다.

응답데이터 전송시간(tran_rsp_time) 정보는 10초 동안의 트랜잭션과 관련된 응답 데이터의 전송시간으로써, 서버가 클라이언트로 요청과 관련된 컨텐츠를 전송하는데 소요되는 시간을 나타낸다. 이는 적어도 하나의 응답들의 전송시간들의 합으로 산출될 수 있다. req_byte 정보는, 10초 동안의 트랜잭션들에서의 요청으로 보낸 데이터의 양을 바이트로 나타낸 것이며, 요청 패킷들의 양의 합으로 산출될 수 있다. 또한, rsp_byte 정보는, 10초 동안의 트랜잭션들에서의 응답으로 보낸 데이터를 바이트로 나타낸 것이며, 응답 패킷들의 양의 합으로 산출될 수 있다.

분석 정보 수집 장치는 트랜잭션 블록 내의 10초 통계를 기반으로, 1분, 10분 1시간 및 1일 단위의 네트워크 성능에 대한 통계 값(최대값, 최소값 및 합산값, 평균값 등(max, min, sum, avg))을 산출한다.

본 발명의 실시예에서, 분석 대상 데이터는 반드시 패킷이어야만 하는 것은 아니다. 이는 분석 대상 장치(예를 들어, 서버)와 관련된 IoT(Internet of Things) 데이터(예를 들어, 센싱 데이터), 제어 신호 데이터, 전원 공급과 관련된 데이터 등을 포함할 수 있다. 이는 데이터베이스에 파일 형태로 저장될 수 있고, 상기 저장된 데이터의 분석을 위해 데이터를 수집하는 방법은 패킷 수집 이외에, 데이터베이스(DB) 공유, 파일 공유, 에이전트(agent)를 이용한 데이터 수집 및 API(Application Program Interface)를 이용한 방법이 있을 수 있다. 데이터베이스를 공유하는 방법은 상기 서버와 연관된 데이터베이스에 SQL 요청을 전달하는 방식을 통해 이루어질 수 있다. 파일 공유는 서버와 연관된 SAN (Storage Area Network)에 파일을 요청함으로써 수집될 수 있다. 에이전트 및 API를 이용하는 방식은 분석 대상 서버에 데이터 수집을 위한 에이전트 또는 API가 직접 삽입되어, 실시간으로 데이터를 분석 모듈로 제공함에 의해 이루어질 수 있다.

위와 같이, 패킷 수집 이외의 방법을 통해 수집된 데이터들도 독립적으로 및/또는 패킷 분석 데이터와 함께, 분석될 수 있다. 즉, 네트워크 성능 및 보안 측면에서의 분석에 패킷 수집 이외의 다양한 방식을 통해 수집된 데이터가 함께 및/또는 독립적으로 사용될 수 있다.

이상에서 설명된 시스템 또는 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 시스템, 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예들에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (16)

1. 분석 정보 수집 장치에서의 대용량 네트워크 모니터링을 위한 실시간으로 패킷 데이터를 수집하는 방법에 있어서,
   분석 대상이 되는 복수 개의 패킷들을 실시간으로 분석함에 의해 생성되는 트랜잭션 블록(TR Block: TRansaction Block)을 수신하는 단계, 여기서, 상기 트랜잭션 블록은 제 1 시간 단위로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 단위 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임;
   상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하는 단계;
   상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하는 단계; 및
   상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 단계를 포함하되,
   동기 신호만 있는 패킷은 상기 레포지토리에 저장하면서 템포러리 리스트(temporary list)에도 함께 저장하되, 종료 신호가 있는 패킷이 수신될 때까지 대기시키며,
   상기 레포지토리는 제 2 시간 단위의 트랜잭션 블록 정보를 저장하는 복수의 디렉토리(directory)들로 구성되고,
   상기 제 2 시간 단위는 상기 제 1 시간 단위보다 긴 시간이며,
   제 2 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리에 저장되어질 현재 저장 대상 트랜잭션 블록들 중 제 1 디렉토리에 저장된 기 저장 트랜잭션 블록들 중 어느 하나의 트랜잭션과 연관된 트랜잭션 블록을 상기 기저장 트랜잭션 블록들 중 어느 하나와 연관시키기 위해, 상기 제 1 디렉토리는 열려 있는 상태로 두되,
   상기 제 1 디렉토리는 상기 제 2 디렉토리 바로 이전 디렉토리이고,
   상기 제 1 디렉토리는 상기 템포러리 리스트와 연계하여 동작하면서 상기 제 2 디렉토리의 저장 개시 후 상기 제 2 시간 단위 동안 열려 있는 상태로 두는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
2. 제 1 항에 있어서, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하는 단계는,
   상기 정렬된 트랜잭션 블록 내의 패킷이 트랜잭션 시작을 위한 동기 신호(Syn) 및 트랜잭션 종료를 위한 종료 신호(Fin)를 포함하는지 확인하는 단계; 및
   동기 신호와 종료 신호를 조합함에 의해 완성된 트랜잭션을 생성하여 트랜잭션 단위로 구분하는 단계를 포함하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
3. 제 2 항에 있어서,
   동기 신호와 종료 신호가 모두 존재하는 패킷은 상기 레포지토리에 바로 저장하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
4. 삭제
5. 제 1 항에 있어서,
   상기 동기 신호만 있는 패킷을 대기시키는 상태에서 타임아웃(Timeout) 임계 시간이 도래했음에도 상기 종료 신호가 있는 패킷이 수신되지 않을 때, 상기 동기 신호만 있는 패킷을 실패(Fail) 처리하고 상기 템포러리 리스트에서 삭제하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
6. 제 1 항에 있어서,
   동기 신호가 없는 패킷은 상기 템포러리 리스트에서 매칭되는 패킷을 찾아서 업데이트(update)하되,
   상기 동기 신호가 없는 패킷이 종료 신호를 포함하고 있을 때, 상기 템포러리 리스트에서 삭제하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
7. 제 5 항에 있어서,
   상기 제 1 시간 단위는 8초 내지 12초이고,
   상기 타임아웃 임계시간은 55초 내지 65초인, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
8. 제 2 항에 있어서,
   상기 트랜잭션 블록은 복수 개의 패킷 분석 모듈로부터 실시간으로 수신되되,
   상기 트랜잭션 블록을 수신 시간으로 정렬할 때, 상기 복수 개의 패킷 분석 모듈 각각과 연관된 서버를 구분하여 정렬하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
9. 삭제
10. 삭제
11. 제 1 항에 있어서,
    상기 제 1 디렉토리는 상기 제 2 디렉토리에 대한 저장 처리가 완료된 이후, 제 3 디렉토리에 저장을 개시할 때, 닫힌 상태로 전환시키고,
    상기 제 3 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리는 열려 있는 상태로 두되,
    상기 제 3 디렉토리는 상기 제 2 디렉토리 바로 이후 디렉토리인, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
12. 제 1 항에 있어서,
    상기 제 1 시간 단위는 수 초(seconds) 단위 시간이고,
    상기 제 2 시간 단위는 분(minute) 단위 시간인, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
13. 제 1 항에 있어서,
    상기 복수 개의 패킷들은 제 1 엔티티(entity)와 제 2 엔티티 간에 송수신되는 패킷들을 포함하고,
    상기 제 1 엔티티 및 상기 제 2 엔티티 중 적어도 하나는 컴퓨팅 장치 또는 상기 컴퓨팅 장치에서 실행되는 애플리케이션 인스턴스(application instance)를 포함하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
14. 제 1 항에 있어서,
    상기 트랜잭션 블록은, (i) 상기 적어도 하나의 트랜잭션들에 포함된 각각의 트랜잭션의 한 세트의 요소 정보를 포함하는 트랜잭션 리스트(TR List) 정보, (ii) 상기 트랜잭션 리스트 정보와 연관된 텍스트들의 목록인 텍스트 리스트(Text List) 정보 및 (iii) 상기 제 1 시간 단위 동안의 네트워크 성능 지표의 통계 정보를 포함하는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법.
15. 대용량 네트워크 모니터링을 위해 실시간으로 패킷 데이터를 수집하는 장치에 있어서,
    분석 대상이 되는 복수 개의 패킷들을 실시간으로 분석함에 의해 생성되는 트랜잭션 블록(TR Block: TRansaction Block)을 수신하는 리시버(receiver), 여기서, 상기 트랜잭션 블록은 제 1 시간 단위로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 단위 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임; 및
    상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하고, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하여 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 프로세서를 포함하되,
    동기 신호만 있는 패킷은 상기 레포지토리에 저장하면서 템포러리 리스트(temporary list)에도 함께 저장하되, 종료 신호가 있는 패킷이 수신될 때까지 대기시키며,
    상기 레포지토리는 제 2 시간 단위의 트랜잭션 블록 정보를 저장하는 복수의 디렉토리(directory)들로 구성되고,
    상기 제 2 시간 단위는 상기 제 1 시간 단위보다 긴 시간이며,
    제 2 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리에 저장되어질 현재 저장 대상 트랜잭션 블록들 중 제 1 디렉토리에 저장된 기 저장 트랜잭션 블록들 중 어느 하나의 트랜잭션과 연관된 트랜잭션 블록을 상기 기저장 트랜잭션 블록들 중 어느 하나와 연관시키기 위해, 상기 제 1 디렉토리는 열려 있는 상태로 두되,
    상기 제 1 디렉토리는 상기 제 2 디렉토리 바로 이전 디렉토리이고,
    상기 제 1 디렉토리는 상기 템포러리 리스트와 연계하여 동작하면서 상기 제 2 디렉토리의 저장 개시 후 상기 제 2 시간 단위 동안 열려 있는 상태로 두는, 대용량 네트워크 모니터링을 위해 실시간으로 패킷 데이터를 수집하는 장치.
16. 대용량 네트워크 모니터링을 위한 실시간 패킷 분석을 수행하는 패킷 분석 시스템에 있어서,
    분석 대상이 되는 복수 개의 패킷들을 수집하여, 트랜잭션 블록(TR Block: TRansaction Block) 을 생성하여 실시간으로 분석 정보 수집 장치로 전송하는 패킷 분석 장치, 여기서 상기 트랜잭션 블록은 제 1 시간 단위로 생성됨, 상기 트랜잭션 블록은 상기 제 1 시간 단위 동안 처리되는 적어도 하나의 트랜잭션들에 포함되는 패킷들에 대한 정보를 포함하는 데이터 블록임;
    상기 실시간으로 수신되는 트랜잭션 블록들을 수신 시간을 기준으로 정렬하고, 상기 정렬된 트랜잭션 블록들 내의 패킷 정보를 트랜잭션 단위로 구분하여 상기 트랜잭션 단위로 구분된 트랜잭션 블록들 내의 패킷 정보를 레포지토리(Repository)에 저장하는 분석정보 수집장치; 및
    상기 트랜잭션 블록과 관련된 정보를 저장하고 있는 레포지토리를 포함하되,
    동기 신호만 있는 패킷은 상기 레포지토리에 저장하면서 템포러리 리스트(temporary list)에도 함께 저장하되, 종료 신호가 있는 패킷이 수신될 때까지 대기시키며,
    상기 레포지토리는 제 2 시간 단위의 트랜잭션 블록 정보를 저장하는 복수의 디렉토리(directory)들로 구성되고,
    상기 제 2 시간 단위는 상기 제 1 시간 단위보다 긴 시간이며,
    제 2 디렉토리에 트랜잭션 블록을 저장할 때, 상기 제 2 디렉토리에 저장되어질 현재 저장 대상 트랜잭션 블록들 중 제 1 디렉토리에 저장된 기 저장 트랜잭션 블록들 중 어느 하나의 트랜잭션과 연관된 트랜잭션 블록을 상기 기저장 트랜잭션 블록들 중 어느 하나와 연관시키기 위해, 상기 제 1 디렉토리는 열려 있는 상태로 두되,
    상기 제 1 디렉토리는 상기 제 2 디렉토리 바로 이전 디렉토리이고,
    상기 제 1 디렉토리는 상기 템포러리 리스트와 연계하여 동작하면서 상기 제 2 디렉토리의 저장 개시 후 상기 제 2 시간 단위 동안 열려 있는 상태로 두는, 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 시스템.
    
    
    

Images