KR102569833B1 - 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템 - Google Patents

디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템 Download PDF

Info

Publication number
KR102569833B1
KR102569833B1 KR1020220190178A KR20220190178A KR102569833B1 KR 102569833 B1 KR102569833 B1 KR 102569833B1 KR 1020220190178 A KR1020220190178 A KR 1020220190178A KR 20220190178 A KR20220190178 A KR 20220190178A KR 102569833 B1 KR102569833 B1 KR 102569833B1
Authority
KR
South Korea
Prior art keywords
server
query signal
resource
query
agent
Prior art date
Application number
KR1020220190178A
Other languages
English (en)
Inventor
황창호
Original Assignee
주식회사 에스티씨랩
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 에스티씨랩 filed Critical 주식회사 에스티씨랩
Priority to KR1020220190178A priority Critical patent/KR102569833B1/ko
Priority to KR1020230108124A priority patent/KR102634229B1/ko
Application granted granted Critical
Publication of KR102569833B1 publication Critical patent/KR102569833B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying

Abstract

디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템이 개시된다. 본 발명의 일 실시예에 따른 유량 제어 서버는, 통신부; 및 통신부와 연결되어 서비스 서버 내부의 유량을 제어하는 프로세서;를 포함하고, 프로세서는, 서비스 서버 내 서버 에이전트로부터 전송된 쿼리 신호 및 리소스 데이터를 수신하고, 쿼리 신호 및 리소스 데이터를 기초로 쿼리 신호에 대한 서비스 서버 내 DB(database) 서버에서의 응답 처리 가능 여부를 파악하고, 및 파악 결과에 따라 쿼리 신호를 DB 서버로 전송하도록 하거나, 또는 쿼리 신호를 이용한 대기열을 형성한다.

Description

디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템{FLOW CONTROL METHOD, SERVER AND SYSTEM USING MONITORING OF SERVICE SERVER BASED ON DIGITAL SERVICE}
본 개시는 서비스 서버 내부의 모니터링을 통해 유량 제어를 하기 위한 방법에 관한 것이다. 보다 상세하게는, 본 개시는 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템에 관한 것이다.
수강신청, 콘서트 예약 및 구매 이벤트 등의 콘텐츠 서비스를 제공하는 서비스 서버의 동시 접속자가 증가함에 따라, 콘텐츠 서비스를 제공하는 서비스 서버측의 응답속도가 저하되거나 서비스가 중단되는 등의 상황이 종종 발생하고 있는 실정이다.
상술한 서비스 서버는 HTML(hypertext markup language)로 구성된 웹 페이지를 제공하는 WEB, WEB으로부터 전달된 요청 메시지에 대한 응용 프로그램 서비스를 처리하는 WAS(web application server) 및 쿼리문에 대한 응답으로 제공할 수 있는 데이터를 저장하는 데이터베이스로 구성될 수 있다.
상술한 서비스 서버의 구성들은 쿼리 신호를 다른 구성으로 전송하거나, 또는 쿼리 신호에 대응되는 처리를 수행하여 회신할 수 있다.
대한민국 등록특허공보 제10-1654266호 (2016. 08. 30.)
본 개시에 개시된 실시예는 서비스 서버 내 애플리케이션 서버와 DB 서버의 모니터링을 통해 쿼리 신호 처리와 관련된 유량을 제어하기 위한 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템을 제공하는데 그 목적이 있다.
본 개시가 해결하고자 하는 과제들은 이상에서 언급된 과제로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 기술적 과제를 달성하기 위한 본 개시에 일 측면에 따른 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 서버는, 통신부; 및 상기 통신부와 연결되어 서비스 서버 내부의 유량을 제어하는 프로세서;를 포함하고, 상기 프로세서는, 상기 서비스 서버 내 서버 에이전트로부터 전송된 쿼리 신호 및 리소스 데이터를 수신하고, 상기 쿼리 신호 및 상기 리소스 데이터를 기초로 상기 쿼리 신호에 대한 상기 서비스 서버 내 DB(database) 서버에서의 응답 처리 가능 여부를 파악하고, 및 파악 결과에 따라 상기 쿼리 신호를 상기 DB 서버로 전송하도록 하거나, 또는 상기 쿼리 신호를 이용한 대기열을 형성할 수 있다.
상기 서버 에이전트는, 상기 애플리케이션 서버에 설치된 앱 에이전트 및 상기 DB 서버에 설치된 DB 에이전트를 포함하고, 상기 프로세서는, 상기 앱 에이전트로부터 전송된 상기 쿼리 신호 및 상기 DB 에이전트로부터 전송된 상기 리소스 데이터를 수신하고, 상기 리소스 데이터의 수신 시점과 상기 쿼리 신호의 수신 시점 간의 차이의 절대값이 기준시간 미만일 때, 상기 리소스 데이터와 상기 쿼리 신호가 서로 매칭되는 정보라고 판단할 수 있다.
상기 프로세서는, 상기 응답 처리 가능 여부를 파악할 때, 상기 쿼리 신호의 수, 상기 쿼리 신호의 용량, DB 리소스 상태 및 상기 쿼리 신호를 처리하기 위한 예상 DB 리소스 사용량 중 적어도 하나 이상을 이용하여 상기 응답 처리 가능 여부를 파악할 수 있다.
상기 DB 서버는, CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리를 포함하고, 상기 프로세서는, 상기 쿼리 신호의 처리 대상이 상기 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 처리 대상의 잔여 리소스 용량이 상기 쿼리 신호를 처리하기 위한 예상 리소스 사용량 보다 큰 경우, 상기 쿼리 신호를 상기 DB 서버로 전송할 수 있다.
상기 프로세서는, 상기 쿼리 신호의 처리 대상이 상기 DB 서버 내 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 처리 대상의 잔여 리소스 용량이 상기 쿼리 신호를 처리하기 위한 예상 리소스 사용량 보다 기 설정된 여유 용량을 초과하는 경우, 상기 쿼리 신호를 상기 DB 서버로 전송하되, 상기 앱 어플리케이션 서버와 상기 DB 서버 간의 커넥션 수를 현재 보다 증가시킬 수 있다.
상기 DB 서버는, CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리를 포함하고, 상기 프로세서는, 상기 응답 처리 가능 여부를 파악할 때, 상기 DB 서버 내 복수의 구성요소 중 중요도에 따라 모니터링 우선순위를 결정하고, 결정된 우선순위에 따라 상기 리소스 상태를 분석할 수 있다.
또한, 본 개시의 다른 측면에 따른 유량 제어 시스템은, 서비스 서버 내 애플리케이션 서버에 설치되어, 상기 애플리케이션 서버로 수신된 쿼리 신호를 우선적으로 획득하여 전달하는 앱 에이전트; 상기 서비스 서버 내 DB(database) 서버에 설치되어, 상기 DB 서버의 리소스 데이터를 수집하여 전달하는 DB 에이전트; 및 상기 앱 에이전트로부터 전송된 상기 쿼리 신호 및 상기 DB 에이전트로부터 전송된 상기 리소스 데이터를 수신하고, 상기 쿼리 신호 및 상기 리소스 데이터를 기초로 상기 쿼리 신호에 대한 상기 서비스 서버 내 DB 서버에서의 응답 처리 가능 여부를 파악하고, 및 파악 결과에 따라 상기 쿼리 신호를 상기 DB 서버로 전송하도록 하거나, 또는 상기 쿼리 신호를 이용한 대기열을 형성하는 유량 제어 서버;를 포함할 수 있다.
상기 앱 에이전트는, 상기 애플리케이션 서버의 쿼리 신호를 후킹(hooking)하는 제1 프레임 워크를 포함하고, 상기 제1 프레임 워크는, Tomcat, Jeus 및 Weblogic을 포함하는 자바 계열 서버, PHP(hypertext preprocessor), .NET, Node.js 및 Python 중 어느 하나를 포함하고, 상기 DB 에이전트는, 상기 DB 서버의 리소스 데이터를 모니터링하는 제2 프레임 워크를 포함하고, 상기 제2 프레임 워크는, C++ 기반으로 구현될 수 있다.
상기 앱 에이전트는, 상기 애플리케이션 서버를 모니터링하여 상기 쿼리 신호의 수, 상기 쿼리 신호의 용량을 획득하고, 상기 DB 에이전트는, 상기 DB 서버 내 CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리 중 적어도 하나 이상을 모니터링할 수 있다.
또한, 본 개시의 다른 측면에 따른 유량 제어 방법은, 유량 제어 서버에 의해 수행되는 방법에 있어서, 서비스 서버 내 서버 에이전트로부터 전송된 쿼리 신호 및 리소스 데이터를 수신하는 단계; 상기 쿼리 신호 및 상기 리소스 데이터를 기초로 상기 쿼리 신호에 대한 상기 서비스 서버 내 DB(database) 서버에서의 응답 처리 가능 여부를 파악하는 단계; 및 파악 결과에 따라 상기 쿼리 신호를 상기 DB 서버로 전송하도록 하거나, 또는 상기 쿼리 신호를 이용한 대기열을 형성하는 단계;를 포함할 수 있다.
이 외에도, 본 개시를 구현하기 위한 실행하기 위한 컴퓨터 판독 가능한 기록 매체에 저장된 컴퓨터 프로그램이 더 제공될 수 있다.
이 외에도, 본 개시를 구현하기 위한 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공될 수 있다.
본 개시의 전술한 과제 해결 수단에 의하면, 서비스 서버 내 애플리케이션 서버의 쿼리 신호와 DB 서버의 리소스 데이터를 모니터링하여 애플리케이션 서버와 DB 서버 간의 유량을 제어하기 때문에, DB 서버에서의 쿼리 신호에 대한 처리를 효율적으로 수행할 수 있다는 효과를 기대할 수 있다.
본 개시의 효과들은 이상에서 언급된 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 유량 제어 서버와 타 구성들 간의 연결 관계를 나타내는 도면
도 2는 본 개시의 유량 제어 시스템의 구성을 나타내는 블록도
도 3은 본 개시의 유량 제어 서버의 구성을 나타내는 블록도
도 4 내지 도 5는 본 개시의 유량 제어 방법을 설명하기 위한 예시도
도 6은 본 개시의 유량 제어 방법을 설명하기 위한 흐름도
본 개시 전체에 걸쳐 동일 참조 부호는 동일 구성요소를 지칭한다. 본 개시가 실시예들의 모든 요소들을 설명하는 것은 아니며, 본 개시가 속하는 기술분야에서 일반적인 내용 또는 실시예들 간에 중복되는 내용은 생략한다. 명세서에서 사용되는 '부, 모듈, 부재, 블록'이라는 용어는 소프트웨어 또는 하드웨어로 구현될 수 있으며, 실시예들에 따라 복수의 '부, 모듈, 부재, 블록'이 하나의 구성요소로 구현되거나, 하나의 '부, 모듈, 부재, 블록'이 복수의 구성요소들을 포함하는 것도 가능하다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 직접적으로 연결되어 있는 경우 뿐 아니라, 간접적으로 연결되어 있는 경우를 포함하고, 간접적인 연결은 무선 통신망을 통해 연결되는 것을 포함한다.
또한 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
명세서 전체에서, 어떤 부재가 다른 부재 "상에" 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
제 1, 제 2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위해 사용되는 것으로, 구성요소가 전술된 용어들에 의해 제한되는 것은 아니다.
단수의 표현은 문맥상 명백하게 예외가 있지 않는 한, 복수의 표현을 포함한다.
각 단계들에 있어 식별부호는 설명의 편의를 위하여 사용되는 것으로 식별부호는 각 단계들의 순서를 설명하는 것이 아니며, 각 단계들은 문맥상 명백하게 특정 순서를 기재하지 않는 이상 명기된 순서와 다르게 실시될 수 있다.
이하 첨부된 도면들을 참고하여 본 개시의 작용 원리 및 실시예들에 대해 설명한다.
본 명세서에서 '본 개시에 따른 유량 제어 서버'는 연산처리를 수행하여 사용자에게 결과를 제공할 수 있는 다양한 장치들이 모두 포함된다. 예를 들어, 본 개시에 따른 유량 제어 서버는, 컴퓨터, 서버 장치 및 휴대용 단말기를 모두 포함하거나, 또는 어느 하나의 형태가 될 수 있다.
여기에서, 상기 컴퓨터는 예를 들어, 웹 브라우저(WEB Browser)가 탑재된 노트북, 데스크톱(desktop), 랩톱(laptop), 태블릿 PC, 슬레이트 PC 등을 포함할 수 있다.
상기 서버 장치는 외부 장치와 통신을 수행하여 정보를 처리하는 서버로써, 애플리케이션 서버, 컴퓨팅 서버, 데이터베이스 서버, 파일 서버, 게임 서버, 메일 서버, 프록시 서버 및 웹 서버 등을 포함할 수 있다.
상기 휴대용 단말기는 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, PCS(Personal Communication System), GSM(Global System for Mobile communications), PDC(Personal Digital Cellular), PHS(Personal Handyphone System), PDA(Personal Digital Assistant), IMT(International Mobile Telecommunication)-2000, CDMA(Code Division Multiple Access)-2000, W-CDMA(W-Code Division Multiple Access), WiBro(Wireless Broadband Internet) 단말, 스마트 폰(Smart Phone) 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치와 시계, 반지, 팔찌, 발찌, 목걸이, 안경, 콘택트 렌즈, 또는 머리 착용형 장치(head-mounted-device, HMD) 등과 같은 웨어러블 장치를 포함할 수 있다.
도 1은 본 개시의 유량 제어 서버와 타 구성들 간의 연결 관계를 나타내는 도면이다.
도 1을 참고하면, 유량 제어 서버(100)는 사용자 단말(End-User(Browser))(200)과 서비스 서버(300) 사이에 위치하여, 사용자 단말(200)의 서비스 서버(300)로의 진입을 관리할 수 있다. 이때, 진입은 사용자 단말(200)이 서비스 서버(300)에 접속되는 것을 의미할 수 있다.
유량 제어 서버(100)는 서비스 서버(300)로의 진입을 요청하는 사용자 단말(200)에 대해 차단, 우회 및 진입 허용 관리의 절차를 수행할 수 있다.
상기 차단은 초당 접근 수가 매크로 수준인 경우, 차단 정보를 사용자 단말(200)로 전송하여 특정 액션을 발생시키는 버튼(예를 들어, 제출 및 확인 등)을 선택하지 못하도록 차단하는 절차를 의미할 수 있다.
상기 우회는 서비스 서버(300)로의 진입을 대기하기 위한 대기열이 발생한 상태여도 특정한 정책이나 주요 클라이언트인 경우, 대기하지 않고 서비스 서버(300)로 바로 진입하도록 우회시키는 절차를 의미할 수 있다.
상기 진입 허용 관리는 서비스 서버(300)로의 진입을 위한 정상적인 대기 관리를 의미하는 것으로서, 진입 허용 수를 기초로 진입을 제어하여 콘텐츠 서비스를 제공하는 서비스 서버(300)의 리소스 또는 상태를 관리하는 절차를 의미할 수 있다.
이때, 진입 허용 수는 유량 제어 서버(100)의 키(key)를 발급받아 해당 시간에 서비스 서버(300)의 특정 트랜잭션(예를 들어, 로그인 버튼, 수강 신청 버튼 등)에 동시 진입이 가능한 사용자 수를 의미할 수 있다. 이때, 사용자 수는 실질적으로 사용자 단말(200)를 통해 서비스 서버(300)로 진입할 수 있는 사용자 단말(200) 수를 의미할 수 있다.
한편, 본 개시의 유량 제어 서버(100)는 서비스 서버(300) 내 애플리케이션 서버와 DB 서버의 모니터링 정보를 수신하여, 애플리케이션 서버와 DB 서버 간의 쿼리 요청에 대한 처리를 수행하기 위한 과정의 유량 제어를 수행할 수 있다. 즉, 본 개시의 유량 제어는 애플리케이션 서버와 DB 서버 간의 유량 제어를 의미하는 것일 수 있다. 이에 대한 상세 설명은 후술하기로 한다. 상기 애플리케이션 서버는 하기 WAS를 의미할 수 있다.
서비스 서버(300)는 웹(web) 서버, 웹 애플리케이션 서버(web application server, 이하, WAS라고 하기로 함) 및 DB(database) 서버를 포함할 수 있다. 이때, DB 서버는 데이터베이스 관리 시스템(database management system, DBMS)이라 하는 것도 가능하다.
웹 서버는 HTTP(hypertext transfer protocol) 프로토콜을 기반으로 웹 브라우저 또는 웹 크롤러와 같은 클라이언트의 요청을 주로 처리하는 서버를 의미하는 것으로, HTTP 요청(request)을 수신하면 이에 대한 HTTP 응답(response)을 회신할 수 있다.
예를 들어, 웹 서버는 파일 경로 이름을 수신하여 경로와 일치하는 정적(static)인 형태의 파일 콘텐츠(html, jpeg, css 등)를 반환할 수 있다.
웹 서버는 동적인 컨텐츠 제공을 위한 요청을 WAS로 전달하고, 이에 대한 처리 결과를 WAS로부터 수신하여 클라이언트에게 전달할 수 있다.
WAS는 HTTP를 이용한 애플리케이션 서버를 의미하는 것으로, 정적인 HTTP 데이터 처리에 특화된 웹 서버에 동적인 데이터를 이용할 수 있도록 하는 컨테이너(container)를 포함할 수 있다.
WAS는 DB 서버 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위한 애플리케이션 서버일 수 있다. 상기, WAS는 HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행하여 주는 미들웨어(소프트웨어 엔진)일 수 있다. WAS는 웹 컨테이너(web container) 또는 서블릿 컨테이너(servlet container)라고 명명하는 것도 가능하다. 이때, 컨테이너는 JSP 및 Servlet을 실행시킬 수 있는 소프트웨어를 의미할 수 있다.
WAS는 분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산 환경에서 적용될 수 있다.
구체적으로, WAS는 프로그램 실행 환경과 DB 서버의 접속 기능 및 다수의 트랜잭션 관리 기능을 구현할 수 있다. 상기 트랜잭션은 논리적인 작업 단위를 의미할 수 있다.
WAS는 사용자의 요청에 따라 DB 서버로부터 해당 데이터를 수신하여, 비즈니스 로직에 맞게 실시간으로 결과를 생성하여 제공할 수 있다. 상기 WAS는 복수 개로 구현될 수 있으며, 각 서비스 서버(300)마다 적용하는 WAS의 개수가 상이할 수 있다.
DB(database) 서버는 데이터를 저장 및 관리하는 구성을 의미할 수 있다. 이때, DB 서버는 WAS의 요청에 따라 해당 데이터를 회신할 수 있다.
도 2는 본 개시의 유량 제어 시스템의 구성을 나타내는 블록도이다.
도 2를 참고하면, 유량 제어 시스템(10)은 서버 에이전트 및 유량 제어 서버(100)를 포함할 수 있다.
도 2를 참고하면, 서버 에이전트는 앱 에이전트(322) 및 DB 에이전트(332)를 포함할 수 있으며, 이에 한정되지 않고, 로드 밸런서(310)에 설치되는 로드 에이전트(312) 등을 추가로 포함할 수 있다.
상기 서버 에이전트는 서비스 서버(300) 내 복수의 서버 각각에 설치되어, 서버의 정보를 모니터링 및 수집하고, 이를 유량 제어 서버(100)로 전달하기 위한 구성일 수 있다. 즉, 서버 에이전트는 유량 제어 서버(100)와 정보 송수신을 수행할 수 있는 것이다. 예를 들어, 복수의 서버는 로드 밸런서(310), 애플리케이션 서버(320), DB 서버(330)를 포함할 수 있다. 도시하지 않았지만, 복수의 서버는 웹 서버, 캐시 서버 등을 추가로 포함할 수 있으며, 각각에는 서버 에이전트가 설치될 수 있다.
앱 에이전트(322)는 서비스 서버(300) 내 애플리케이션 서버(320)에 설치되어, 애플리케이션 서버(320)로 수신된 쿼리 신호를 우선적으로 획득(후킹(hooking))하여 전달하는 구성일 수 있다.
도 2에서 도시하는 바와 같이, 애플리케이션 서버(320)는 복수일 수 있다. 이때, 복수의 애플리케이션 서버(320) 각각은 로그인 담당, 결제 담당 및 회원정보 담당 등과 같은 역할 중 적어도 하나를 부여받고, 부여된 역할과 관련된 쿼리 신호 발생 등의 동작을 수행할 수 있는 것이다.
앱 에이전트(322)는 애플리케이션 서버(320)의 쿼리 신호를 후킹(hooking)하는 제1 프레임 워크를 포함할 수 있다. 즉, 앱 에이전트(322)는 후킹 기능을 런타임 엔진을 적용하여, 애플리케이션 서버(320)로 전달된 쿼리 신호를 DB 서버(330)로 전달되기 전에 우선적으로 획득하여, 쿼리 신호를 유량 제어 서버(100)로 전달할 수 있다.
제1 프레임 워크는, Tomcat, Jeus 및 Weblogic을 포함하는 자바 계열 서버, PHP(hypertext preprocessor), .NET, Node.js 및 Python 중 어느 하나를 포함할 수 있다. 즉, 앱 에이전트(322)는 제1 프레임 워크 기반으로 구현되어 애플리케이션 서버(320)의 쿼리 신호를 후킹할 수 있는 것이다.
앱 에이전트(322)는 애플리케이션 서버(320)를 모니터링하여 쿼리 신호의 수, 쿼리 신호의 용량을 획득할 수 있다. 이때, 쿼리 신호의 용량은 기 설정된 용량 기준치를 초과하면 해비(heavy) 쿼리로 판단하고, 용량 기준치 이하인 경우 라이트(light) 쿼리도 판단할 수 있다.
DB 에이전트(332)는 서비스 서버(300) 내 DB(database) 서버(330)에 설치되어, DB 서버(330)의 리소스 데이터를 수집하여 전달할 수 있다.
상기 DB 에이전트(332)는, DB 서버(330)의 리소스 데이터를 모니터링하는 제2 프레임 워크를 포함할 수 있다.
예를 들어, DB 서버(330)는 오라클, MY SQL, 마리아 DB일 수 있으며, 제2 프레임 워크는, C++ 기반으로 구현될 수 있다. 이러한 DB 에이전트(332)는 후킹 기능의 런타임 엔진을 미 적용하고 C++ 기반으로 구현되기 때문에, DB 서버(330)의 정보를 후킹이 아닌 모니터링할 수 있다.
DB 에이전트(332)는 DB 서버(330) 내 CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리 중 적어도 하나 이상을 모니터링할 수 있다.
유량 제어 서버(100)는 앱 에이전트(322)로부터 전송된 쿼리 신호 및 DB 에이전트(332)로부터 전송된 리소스 데이터를 수신할 수 있다.
유량 제어 서버(100)는 쿼리 신호 및 리소스 데이터를 기초로 쿼리 신호에 대한 DB 서버(330)에서의 응답 처리 가능 여부를 파악할 수 있다.
유량 제어 서버(100)는 파악 결과에 따라 쿼리 신호를 DB 서버(330)로 전송하도록 하거나, 또는 쿼리 신호를 이용한 대기열을 형성할 수 있다.
도 3은 본 개시의 유량 제어 서버의 구성을 나타내는 블록도이다.
이하에서는, 본 개시의 유량 제어 방법을 설명하기 위한 예시도인 도 4 내지 도 5를 참조하여 설명하기로 한다.
도 3을 참고하면, 유량 제어 서버(100)는 프로세서(110), 메모리(130) 및 통신부(150)를 포함한다. 도 1에 도시된 구성요소들은 본 개시에 따른 유량 제어 서버(100)를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 유량 제어 서버(100)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.
본 개시의 유량 제어 서버(100)은 서비스 서버(300) 내 애플리케이션 서버(320)와 DB 서버(330)의 모니터링 정보를 수신하여, 애플리케이션 서버(320)와 DB 서버(330) 간의 쿼리 요청에 대한 유량 제어를 수행할 수 있다. 즉, 본 개시의 유량 제어는 애플리케이션 서버(320)와 DB 서버(330) 간의 쿼리 신호 처리와 관련된 유량 제어를 의미하는 것일 수 있다.
프로세서(110)는 통신부(150)와 연결되어 서비스 서버(300) 내부의 유량을 제어하는 구성일 수 있다.
구체적으로, 프로세서(110)는 서비스 서버(300) 내 서버 에이전트(322, 332)로부터 전송된 쿼리 신호 및 리소스 데이터를 수신할 수 있다.
상기 서버 에이전트는, 애플리케이션 서버(320)에 설치된 앱 에이전트(322) 및 DB 서버(330)에 설치된 DB 에이전트(332)를 포함할 수 있다.
프로세서(110)는 앱 에이전트(322)로부터 전송된 쿼리 신호 및 DB 에이전트(332)로부터 전송된 리소스 데이터를 수신할 수 있다. 이때, 앱 에이전트(322)는 애플리케이션 서버(320)로 수신된 쿼리 신호를 후킹할 수 있는 제1 프레임 워크를 포함하고 있을 수 있다.
프로세서(110)는 수신된 쿼리 신호 및 리소스 데이터가 서로 대응되는 정보인지 여부를 체크할 수 있다. 즉, 프로세서(110)는 수집된 리소스 데이터가 쿼리 신호의 즉시 처리 가능 여부를 판단하기 위해 반영할 해당 리소스 데이터가 맞는지 여부를 체크하는 것이다.
구체적으로, 프로세서(110)는 수학식 1을 기초로 리소스 데이터와 쿼리 신호가 서로 매칭되는 정보인지 여부를 판단할 수 있다. 프로세서(110)는 수학식 1을 만족하는 경우, 리소스 데이터와 쿼리 신호가 서로 매칭되는 정보인 것으로 판단할 수 있다.
(수학식 1)
| TQ - TR | < Tref
이때, TQ는 쿼리 신호의 수신 시점이고, TR는 리소스 데이터의 수신 시점이며, Tref는 기준시간을 의미할 수 있다.
구체적으로, 도 4를 참고하면, 프로세서(110)는 리소스 데이터의 수신 시점과 쿼리 신호의 수신 시점 간의 차이의 절대값이 기준시간 미만일 때, 리소스 데이터와 쿼리 신호가 서로 매칭되는 정보라고 판단할 수 있다. 이때, 기준시간은 특정 시간 범위를 포함할 수 있다. 예를 들어, 기준시간은 A 시각으로부터 B 시각까지의 범위를 포함하는 형태일 수 있는 것이다.
반대로, 리소스 데이터의 수신 시점과 쿼리 신호의 수신 시점 간의 차이의 절대값이 기준시간 이상일 때, 프로세서(110)는 리소스 데이터가 쿼리 신호에 대응되는 리소스 데이터가 아닌 것으로 판단하고, 해당 리소스 데이터를 기초한 쿼리 신호에 대한 DB 서버에서의 응답 처리 가능 여부 판단을 미수행할 수 있다.
프로세서(110)는 쿼리 신호 및 리소스 데이터를 기초로 쿼리 신호에 대한 DB 서버(330)에서의 응답 처리 가능 여부를 파악할 수 있다.
즉, 프로세서(110)는 애플리케이션 서버(320)로부터 전송될 쿼리 신호에 대해 현재 DB 서버(330)가 처리할 수 있는 상태인지 여부를 파악하는 것이다. 후술하겠지만, 프로세서(110)는 DB 서버(330)가 쿼리 신호에 대응되는 처리를 즉시 수행할 수 있는 리소스 상태인 경우, 쿼리 신호가 DB 서버(330)로 전송되도록 하고, DB 서버(330)가 쿼리 신호에 대응되는 처리를 즉시 수행하기 불가능한 리소스 상태인 경우, 해당 쿼리 신호의 DB 서버(330)로의 전송을 대기시킬 수 있다.
구체적으로, 프로세서(110)는 응답 처리 가능 여부를 파악할 때, 쿼리 신호의 수, 쿼리 신호의 용량, DB 리소스 상태 및 쿼리 신호를 처리하기 위한 예상 DB 리소스 사용량 중 적어도 하나 이상을 이용하여 응답 처리 가능 여부를 파악할 수 있다. 이때, 프로세서(110)는 쿼리 신호의 용량을 기 설정된 용량 기준치를 초과하면 해비(heavy) 쿼리로 판단하고, 용량 기준치 이하인 경우 라이트(light) 쿼리도 판단할 수 있다.
상술한 DB 서버(330)는 CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리와 같은 구성 요소를 포함할 수 있다. 상기 DB 리소스 상태는 DB 서버(330) 내 포함된 각 구성요소의 리소스 잔여량 또는 리소스 사용량을 비롯하여 쿼리 신호를 처리하는데 요구되는 리소스 정보를 포함할 수 있다.
프로세서(110)는 응답 처리 가능 여부를 파악할 때, DB 서버(330) 내 복수의 구성요소 중 중요도에 따라 모니터링 우선순위를 결정하고, 결정된 우선순위에 따라 리소스 상태를 분석할 수 있다. 이때, 복수의 구성요소는 CPU, 디스크, 네트워크, GPU 및 메모리를 포함할 수 있다.
즉, 프로세서(110)는 DB 서버(330) 내 구성요소 중 CPU가 가장 중요한 경우, CPU를 우선적으로 모니터링하여 쿼리 신호의 전송 가능 여부를 판단할 수 있는 것이다.
이를 위해, 운용자에 의해서 임의로 설정하거나, 또는 DB 서버(330) 내에서의 사용량을 기준으로 복수의 구성요소별 우선순위를 사전에 설정하고, 프로세서(110)는 DB 서버(330) 내 구성요소의 리소스 상태를 분석할 때 상기 우선순위에 따라 수행할 수 있다.
한편, 프로세서(110)는 DB 에이전트(332)로부터 기 설정된 시간 동안 전송되는 쿼리별 사용 리소스를 학습 데이터로 이용하여 학습을 수행하고, 쿼리별 사용 리소스를 결과로 도출할 수 있다. 프로세서(110)는 학습된 쿼리별 사용 리소스를 기초로 특정 쿼리에 대한 DB 서버(330) 내 리소스 데이터를 중점 모니터링할 수 있다. 이때, 프로세서(110)는 특정 쿼리에 대응되는 사용 리소스에 모니터링 가중치를 부여할 수 있다.
상술한 쿼리별 사용 리소스는 특정 쿼리 신호를 처리하기 위해 사용되는 DB 서버(330) 내 구성요소를 의미할 수 있다. 이때, 쿼리별 사용 리소스는 쿼리 신호, 상기 쿼리 신호에 대응되는 DB 서버 내 구성요소 및 쿼리 신호 처리 시의 리소스 사용량 중 적어도 하나 이상을 포함할 수 있다.
예를 들어, A 쿼리 신호를 처리할 때, DB 서버(330) 내 구성요소 중 CPU를 사용하는 경우, 프로세서(110)는 A 쿼리 신호를 수신하면, CPU의 리소스 데이터를 다른 구성요소(예를 들어, 디스크, 네트워크 등)에 비해 중점 분석할 수 있다는 것이다.
프로세서(110)는 파악 결과에 따라 쿼리 신호를 DB 서버(330)로 전송하도록 하거나, 또는 쿼리 신호를 이용한 대기열을 형성할 수 있다. 이때, 대기열은 DB 서버(330)로의 쿼리 신호 전송을 대기하는 열을 의미할 수 있다.
도 5를 참고하면, 프로세서(110)는 애플리케이션 서버(320)를 통해 쿼리 신호를 DB 서버(330)로 전송하도록 하거나(①), 또는 쿼리 신호를 이용한 대기열을 형성(②)할 수 있다.
일 예로, 프로세서(110)는 쿼리 신호의 처리 대상이 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 처리 대상의 잔여 리소스 용량이 쿼리 신호를 처리하기 위한 예상 리소스 사용량 보다 큰 경우, 쿼리 신호를 DB 서버(330)로 전송할 수 있다.
상술한 DB 서버(330)는 CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리를 포함할 수 있다.
다른 예로, 프로세서(110)는 쿼리 신호의 처리 대상이 DB 서버(330) 내 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 처리 대상의 잔여 리소스 용량이 쿼리 신호를 처리하기 위한 예상 리소스 사용량 보다 기 설정된 여유 용량을 초과하는 경우, 쿼리 신호를 상기 DB 서버(330)로 전송하되, 앱 어플리케이션 서버(320)와 DB 서버(330) 간의 커넥션 수를 현재 보다 증가시킬 수 있다.
예를 들어, 프로세서(110)는 수학식 2를 통해 쿼리 신호를 DB 서버(330)로 전송할지 여부를 판단할 수 있다. 즉, 하기 수학식 2를 만족하는 경우, 프로세서(110)는 DB 서버(330)로의 쿼리 신호 전송이 가능하다고 판단할 수 있다.
(수학식 2)
KD+a > LR
상기 D는 처리 대상의 잔여 리소스 용량, a는 여유 용량, R은 쿼리 신호를 처리하기 위한 예상 리소스 사용량 및 K와 L은 상수를 의미할 수 있다.
프로세서(110)는 쿼리 신호를 이용하여 대기열을 생성한 후, 대기 중인 쿼리 신호를 처리하기 위한 DB 서버(330)의 리소스 상태를 모니터링할 수 있다. 프로세서(110)는 DB 서버(330)의 리소스 상태 모니터링 결과, 대기 중인 쿼리 신호에 대한 처리를 수행할 수 있는 상태인 경우, 해당 쿼리 신호가 애플리케이션 서버(320)를 통해 DB 서버(330)로 전송되도록 할 수 있다.
만약, 복수의 앱 에이전트(322) 중 서로 다른 앱 에이전트(322)로부터 수신한 쿼리 신호가 복수이거나, 또는 하나의 앱 에이전트(322)로부터 수신한 쿼리 신호가 복수인 경우일 수 있다. 이러한 경우, 프로세서(110)는 복수의 쿼리 신호 각각의 예상 리소스 사용량, DB 서버(330)내 쿼리 신호를 처리할 구성요소 및 쿼리 신호를 처리할 구성요소의 잔여 리소스 용량을 기초로 산출된 전송 우선순위에 따라 쿼리 신호를 DB 서버(330)로 전송하거나, 또는 대기열을 형성할 수 있다. 상기 예상 리소스 사용량은 쿼리 신호를 처리하기 위한 예상 리소스 사용량일 수 있다.
일 예로, 복수의 쿼리 신호 각각을 처리할 구성요소가 동일하고, 복수의 쿼리 신호의 예상 리소스 사용량의 총합이 쿼리 신호를 처리할 구성요소의 잔여 리소스 용량 미만인 경우, 프로세서(110)는 예상 리소스 사용량이 작은 우선순위로 쿼리 신호를 DB 서버(330)로 전송하도록 할 수 있다.
예를 들어, 쿼리 신호 1 내지 쿼리 신호 3을 처리하기 위한 구성요소가 CPU이고, 쿼리 신호 1의 예상 리소스 사용량 10%, 쿼리 신호 2의 예상 리소스 사용량 20%, 쿼리 신호 3의 예상 리소스 사용량 30%이며, CPU의 잔여 리소스 용량이 70%인 경우, 프로세서(110)는 쿼리 신호 1 -> 쿼리 신호 2 -> 쿼리 신호 3의 순위로 쿼리 신호를 DB 서버(330)로 전송하도록 할 수 있다.
한편, 본 개시의 예상 리소스 사용량은 DB 서버(330)내 구성요소의 리소스 용량과 동일한 형식으로 정규화된 정보일 수 있다. 예를 들어, 예상 리소스 사용량 20%는 구성요소의 리소스 용량 20%와 동일할 수 있는 것이다. 이러한 경우, 구성요소의 잔여 리소스 용량이 70%이고, 쿼리 신호에 대한 처리를 위한 예상 리소스 사용량 20%인 경우, DB 서버(330)에서 쿼리 신호를 처리한 후 잔여 리소스 용량은 50%가 되는 것이다.
다른 예로, 복수의 쿼리 신호 각각을 처리할 구성요소가 서로 상이하고, 제1 쿼리 신호의 예상 리소스 사용량은 제1 쿼리 신호를 처리할 구성요소의 잔여 리소스 용량 미만이고, 제2 쿼리 신호의 예상 리소스 사용량은 제2 쿼리 신호를 처리할 구성요소의 잔여 리소스 용량 이상인 경우, 프로세서(110)는 제1 쿼리 신호만을 DB 서버(330)로 전송하도록 할 수 있다. 이때, 복수의 쿼리 신호는 동일한 앱 에이전트(322) 또는 서로 다른 앱 에이전트(322)로부터 수신한 신호 모두일 수 있다.
다른 예로, 복수의 쿼리 신호 각각을 처리할 구성요소가 서로 상이하고, 복수의 쿼리 신호 각각의 예상 리소스 사용량의 총합이 쿼리 신호를 처리할 해당 구성요소의 잔여 리소스 용량 미만인 경우, 프로세서(110)는 구성요소별 예상 리소스 사용량의 총합이 작은 우선순위로 쿼리 신호를 DB 서버(330)로 전송하도록 할 수 있다.
예를 들어, 쿼리 신호 1 내지 쿼리 신호 2를 처리하기 위한 구성요소가 CPU이고, 쿼리 신호 3 내지 쿼리 신호 5를 처리하기 위한 구성요소가 GPU이며, 쿼리 신호 1의 예상 리소스 사용량 10%, 쿼리 신호 2의 예상 리소스 사용량 20%, 쿼리 신호 3의 예상 리소스 사용량 10%, 쿼리 신호 4의 예상 리소스 사용량 20%, 쿼리 신호 5의 예상 리소스 사용량 30%이고, CPU의 잔여 리소스 용량이 50%, GPU의 잔여 리소스 용량이 70%일 수 있다. 이러한 경우, 프로세서(110)는 쿼리 신호 1 및 2의 예상 리소스 사용량의 총합이 30%이고, 쿼리 신호 3 내지 5의 예상 리소스 사용량의 총합이 60%인 것을 고려하여, 쿼리 신호 1 및 2를 우선적으로 DB 서버(330)로 전송하도록 할 수 있다. 이후, 프로세서(110)는 쿼리 신호 3 내지 쿼리 신호 5를 DB 서버(330)로 전송하도록 할 수 있다. 이때, 프로세서(110)는 쿼리 신호 1 및 2 중에서도 예상 리소스 사용량이 작은 우선순위로 쿼리 신호가 전송되도록 할 수 있다.
본 개시는 상술한 바와 같이, 쿼리 신호 및 리소스 상태를 기초로 다양한 방식을 통해 쿼리 신호를 처리할 수 있도록 유량을 제어하기 때문에, 서비스 서버(300) 내 쿼리 신호에 대한 처리가 원활하게 이루어질 수 있도록 하고, 이로 인해 콘텐츠 서비스 이용 중 요청 신호를 발생시킨 엔드 유저의 사용자 단말(200)로도 응답을 신속하게 회신할 수 있다는 효과를 기대할 수 있는 것이다.
메모리(130)는 유량 제어 방법을 제공하기 위한 컴퓨터 프로그램을 저장할 수 있으며, 저장된 컴퓨터 프로그램은 프로세서(110)에 의해 판독되어 구동될 수 있다. 메모리(130)는 프로세서(110)가 생성하거나 결정한 임의의 형태의 정보 및 통신부(150)가 수신한 임의의 형태의 정보를 저장할 수 있다.
메모리(130)는 유량 제어 서버(100)의 다양한 기능을 지원하는 데이터와, 프로세서(110)의 동작을 위한 프로그램을 저장할 수 있고, 입/출력되는 데이터들을 저장할 있고, 유량 제어 서버(100)에서 구동되는 다수의 응용 프로그램(application program 또는 애플리케이션(application)), 유량 제어 서버(100)의 동작을 위한 데이터들, 명령어들을 저장할 수 있다. 이러한 응용 프로그램 중 적어도 일부는, 무선 통신을 통해 외부 서버로부터 다운로드 될 수 있다.
이러한, 메모리(130)는 플래시 메모리 타입(Flash memory type), 하드디스크 타입(Hard disk type), SSD 타입(Solid State Disk type), SDD 타입(Silicon Disk Drive type), 멀티미디어 카드 마이크로 타입(Multimedia card micro type), 카드 타입의 메모리(예를 들어 SD 또는 XD 메모리 등), 램(Random access memory; RAM), SRAM(Static random access memory), 롬(Read-only memory; ROM), EEPROM(Electrically erasable programmable read-only memory), PROM(Programmable read-only memory), 자기 메모리, 자기 디스크 및 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. 또한, 메모리는 본 장치와는 분리되어 있으나, 유선 또는 무선으로 연결된 데이터베이스가 될 수도 있다.
통신부(150)는 외부 장치와 통신을 가능하게 하는 하나 이상의 구성 요소를 포함할 수 있으며, 예를 들어, 방송 수신 모듈, 유선통신 모듈, 무선통신 모듈, 근거리 통신 모듈, 위치정보 모듈 중 적어도 하나를 포함할 수 있다.
도시하지 않았지만, 본 개시의 유량 제어 서버(100)는 출력부 및 입력부를 더 포함할 수도 있다.
출력부는 유량 제어 결과 등을 제공하기 위한 사용자 인터페이스(UI, user interface)를 표시할 수 있다. 출력부는 프로세서(110)가 생성하거나 결정한 임의의 형태의 정보 및 통신부(150)가 수신한 임의의 형태의 정보를 출력할 수 있다.
출력부는 액정 디스플레이(LCD: liquid crystal display), 박막 트랜지스터 액정 디스플레이(TFT LCD: thin film transistor- liquid crystal display), 유기 발광 다이오드(OLED: organic light-emitting diode), 플렉시블 디스플레이(Flexible display), 3차원 디스플레이(3D display) 중에서 적어도 하나를 포함할 수 있다. 이들 중 일부 디스플레이 모듈은, 그를 통해 외부를 볼 수 있도록 투명형 또는 광 투과형으로 구성될 수 있다. 이는 투명 디스플레이 모듈이라 지칭될 수 있는데, 상기 투명 디스플레이 모듈의 대표적 인 예로는 TOLED(Transparent OLED) 등이 있다.
입력부는 사용자에 의해서 입력된 정보를 수신할 수 있다. 입력부는 사용자에 의해서 입력된 정보를 수신하기 위한 사용자 인터페이스 상의 키 및/또는 버튼들, 또는 물리적인 키 및/또는 버튼들을 구비할 수 있다. 입력부를 통한 사용 자 입력에 따라 본 개시의 실시예들에 따른 디스플레이를 제어하기 위한 컴퓨터 프로그램이 실행될 수 있다.
도 6은 본 개시의 유량 제어 방법을 설명하기 위한 흐름도이다.
유량 제어 서버(100)의 프로세서(110)는 서비스 서버(300) 내 서버 에이전트로부터 전송된 쿼리 신호 및 리소스 데이터를 수신할 수 있다(1100).
유량 제어 서버(100)의 프로세서(110)는 수신된 쿼리 신호 및 리소스 데이터가 서로 대응되는 정보인지 여부를 체크할 수 있다(1200).
구체적으로, 프로세서(110)는 수학식 1을 기초로 리소스 데이터와 쿼리 신호가 서로 매칭되는 정보라고 판단할 수 있다.
도 4를 참고하면, 프로세서(110)는 리소스 데이터의 수신 시점과 쿼리 신호의 수신 시점 간의 차이의 절대값이 기준시간 미만일 때, 리소스 데이터와 쿼리 신호가 서로 매칭되는 정보라고 판단할 수 있다.
반대로, 리소스 데이터의 수신 시점과 쿼리 신호의 수신 시점 간의 차이의 절대값이 기준시간 이상일 때, 프로세서(110)는 리소스 데이터가 쿼리 신호에 대응되는 데이터가 아닌 것으로 판단하고, 해당 리소스 데이터를 기초한 유량 및 쿼리 신호 전송 여부 판단을 미수행할 수 있다.
다음, 유량 제어 서버(100)의 프로세서(110)는 쿼리 신호 및 리소스 데이터를 기초로 쿼리 신호에 대한 DB 서버(330)에서의 응답 처리 가능 여부를 파악할 수 있다(1300).
다음, 프로세서(110)는 파악 결과에 따라 쿼리 신호를 DB 서버(330)로 전송하도록 하거나, 또는 쿼리 신호를 이용한 대기열을 형성할 수 있다(1400).
한편, 전술한 본 개시에 따른 방법은, 하드웨어인 서버와 결합되어 실행되기 위해 프로그램(또는 애플리케이션)으로 구현되어 매체에 저장될 수 있다.
개시된 실시예들은 컴퓨터에 의해 실행 가능한 명령어를 저장하는 기록매체의 형태로 구현될 수 있다. 명령어는 프로그램 코드의 형태로 저장될 수 있으며, 프로세서에 의해 실행되었을 때, 프로그램 모듈을 생성하여 개시된 실시예들의 동작을 수행할 수 있다. 기록매체는 컴퓨터로 읽을 수 있는 기록매체로 구현될 수 있다.
컴퓨터가 읽을 수 있는 기록매체로는 컴퓨터에 의하여 해독될 수 있는 명령어가 저장된 모든 종류의 기록 매체를 포함한다. 예를 들어, ROM(Read Only Memory), RAM(Random Access Memory), 자기 테이프, 자기 디스크, 플래쉬 메모리, 광 데이터 저장장치 등이 있을 수 있다.
이상에서와 같이 첨부된 도면을 참조하여 개시된 실시예들을 설명하였다. 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자는 본 개시의 기술적 사상이나 필수적인 특징을 변경하지 않고도, 개시된 실시예들과 다른 형태로 본 개시가 실시될 수 있음을 이해할 것이다. 개시된 실시예들은 예시적인 것이며, 한정적으로 해석되어서는 안 된다.
100: 유량 제어 서버
110: 프로세서
130: 메모리
150: 통신부
200: 사용자 단말
300: 서비스 서버
310: 로드 밸런서
312: 로드 에이전트
320: 애플리케이션 서버
322: 앱 에이전트
330: DB 서버
332: DB 에이전트

Claims (10)

  1. 통신부; 및 상기 통신부와 연결되어 애플리케이션서버 및 DB서버를 포함한 서비스서버를 제어하는 프로세서;를 포함하고,
    상기 프로세서는, 상기 애플리케이션서버의 앱에이전트로부터 쿼리신호 및 상기 DB서버의 DB에이전트로부터 리소스데이터를 수신하고, 상기 쿼리신호 및 리소스데이터의 수신시점 차이의 절대값이 기준시간 미만일 때 상기 쿼리신호 및 리소스데이터가 서로 매칭됨으로 판단하고, 상기 쿼리신호의 수와 용량, DB리소스상태, 상기 쿼리신호의 처리를 위한 예상DB리소스사용량, 상기 DB서버 내 상기 쿼리신호를 처리하는 구성요소의 잔여리소스용량, 상기 구성요소의 여유용량 및 예상리소스사용량을 근거로 상기 DB서버로 상기 쿼리신호의 전송가능함이 판단되면 상기 쿼리신호를 상기 DB서버로 전송하거나, 또는 상기 쿼리신호의 전송불가능함이 판단되면 상기 쿼리신호를 이용한 대기열을 형성하고, 기학습된 쿼리별 사용리소스를 기초로 상기 쿼리신호에 대한 상기 구성요소의 리소스데이터를 모니터링하되 상기 쿼리신호의 종류에 따라 모니터링되는 상기 구성요소는 달라지는, 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 서버.
  2. 삭제
  3. 삭제
  4. 제1항에 있어서,
    상기 DB서버는, CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리를 포함하고,
    상기 프로세서는,
    상기 쿼리신호의 처리대상이 상기 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 상기 처리대상의 잔여리소스용량이 상기 쿼리신호를 처리하기 위한 예상리소스사용량 보다 큰 경우, 상기 쿼리신호를 상기 DB서버로 전송하는, 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 서버.
  5. 제1항에 있어서,
    상기 프로세서는,
    상기 쿼리신호의 처리대상이 상기 DB서버 내 CPU, 디스크, 네트워크, GPU 및 메모리 중 어느 하나이고, 상기 처리대상의 잔여리소스용량이 상기 쿼리신호를 처리하기 위한 예상리소스사용량 보다 기 설정된 여유용량을 초과하는 경우, 상기 쿼리신호를 상기 DB서버로 전송하되, 상기 애플리케이션서버와 상기 DB서버 간의 커넥션 수를 현재보다 증가시키는, 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 서버.
  6. 삭제
  7. 애플리케이션서버의 쿼리신호를 우선적으로 획득하여 전달하는 앱에이전트;
    DB서버의 리소스데이터를 수집하여 전달하는 DB에이전트; 및
    상기 앱에이전트로부터 쿼리신호 및 상기 DB에이전트로부터 리소스데이터를 수신하고, 상기 쿼리신호 및 리소스데이터의 수신시점 차이의 절대값이 기준시간 미만일 때 상기 쿼리신호 및 리소스데이터가 서로 매칭됨으로 판단하고, 상기 쿼리신호의 수와 용량, DB리소스상태, 상기 쿼리신호의 처리를 위한 예상DB리소스사용량, 상기 DB서버 내 상기 쿼리신호를 처리하는 구성요소의 잔여리소스용량, 상기 구성요소의 여유용량 및 예상리소스사용량을 근거로 상기 DB서버로 상기 쿼리신호의 전송가능함이 판단되면 상기 쿼리신호를 상기 DB서버로 전송하거나, 또는 상기 쿼리신호의 전송불가능함이 판단되면 상기 쿼리신호를 이용한 대기열을 형성하고, 기학습된 쿼리별 사용리소스를 기초로 상기 쿼리신호에 대한 상기 구성요소의 리소스데이터를 모니터링하되 상기 쿼리신호의 종류에 따라 모니터링되는 상기 구성요소는 달라지는 유량 제어 서버;를 포함하는, 유량 제어 시스템.
  8. 제7항에 있어서,
    상기 앱에이전트는,
    상기 쿼리신호를 후킹(hooking)하는 제1 프레임 워크를 포함하고,
    상기 제1 프레임 워크는, Tomcat, Jeus 및 Weblogic을 포함하는 자바 계열 서버, PHP(hypertext preprocessor), .NET, Node.js 및 Python 중 어느 하나를 포함하고,
    상기 DB에이전트는,
    상기 리소스데이터를 모니터링하는 제2 프레임 워크를 포함하고,
    상기 제2 프레임 워크는, C++ 기반으로 구현되는, 유량 제어 시스템.
  9. 제7항에 있어서,
    상기 앱에이전트는, 상기 애플리케이션서버를 모니터링하여 상기 쿼리신호의 수와 용량을 획득하고,
    상기 DB에이전트는, 상기 DB서버 내 CPU(central processing unit), 디스크, 네트워크, GPU(graphics processing unit) 및 메모리 중 적어도 하나 이상을 모니터링하는, 유량 제어 시스템.
  10. 유량 제어 서버에 의해 수행되는 방법에 있어서,
    애플리케이션서버의 앱에이전트로부터 쿼리신호 및 상기 DB서버의 DB에이전트로부터 리소스데이터를 수신하는 단계;
    상기 쿼리신호 및 리소스데이터의 수신시점 차이의 절대값이 기준시간 미만일 때 상기 쿼리신호 및 리소스데이터가 서로 매칭됨으로 판단하는 단계; 및
    상기 쿼리신호의 수와 용량, DB리소스상태, 상기 쿼리신호의 처리를 위한 예상DB리소스사용량, 상기 DB서버 내 상기 쿼리신호를 처리하는 구성요소의 잔여리소스용량, 상기 구성요소의 여유용량 및 예상리소스사용량을 근거로 상기 DB서버로 상기 쿼리신호의 전송가능함이 판단되면 상기 쿼리신호를 상기 DB서버로 전송하거나, 또는 상기 쿼리신호의 전송불가능함이 판단되면 상기 쿼리신호를 이용한 대기열을 형성하고, 기학습된 쿼리별 사용리소스를 기초로 상기 쿼리신호에 대한 상기 구성요소의 리소스데이터를 모니터링하는 단계; 를 포함하고,
    상기 쿼리신호의 종류에 따라 모니터링되는 상기 구성요소는 달라지는, 유량 제어 방법.
KR1020220190178A 2022-12-30 2022-12-30 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템 KR102569833B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020220190178A KR102569833B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템
KR1020230108124A KR102634229B1 (ko) 2022-12-30 2023-08-18 디지털 서비스 기반 쿼리신호와 리소스데이터를 이용한유량 제어 방법, 서버 및 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020220190178A KR102569833B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020230108124A Division KR102634229B1 (ko) 2022-12-30 2023-08-18 디지털 서비스 기반 쿼리신호와 리소스데이터를 이용한유량 제어 방법, 서버 및 시스템

Publications (1)

Publication Number Publication Date
KR102569833B1 true KR102569833B1 (ko) 2023-08-23

Family

ID=87848785

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020220190178A KR102569833B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템
KR1020230108124A KR102634229B1 (ko) 2022-12-30 2023-08-18 디지털 서비스 기반 쿼리신호와 리소스데이터를 이용한유량 제어 방법, 서버 및 시스템

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020230108124A KR102634229B1 (ko) 2022-12-30 2023-08-18 디지털 서비스 기반 쿼리신호와 리소스데이터를 이용한유량 제어 방법, 서버 및 시스템

Country Status (1)

Country Link
KR (2) KR102569833B1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100606897B1 (ko) * 2004-09-10 2006-08-01 엘지노텔 주식회사 연결설정을 위한 처리 방법과 장치
KR20090112532A (ko) * 2008-04-24 2009-10-28 (주)에임투지 대기표 관리 방법, 리소스 관리 방법 및 트랜잭션 서버
KR101654266B1 (ko) 2014-12-18 2016-09-05 (주)에임투지 웹 접속 관리 시스템을 통한 모니터링 기능을 제공하는 모니터링 장치

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100947740B1 (ko) * 2007-09-13 2010-03-17 주식회사 케이티 전산망에서 발생하는 이벤트를 모니터링하기 위한 방법 및시스템과 이벤트 관리 장치
KR101008010B1 (ko) * 2008-04-24 2011-01-14 (주)에임투지 리소스 할당 제어 방법 및 할당 리스트 관리 방법
KR20160073893A (ko) * 2014-12-17 2016-06-27 (주)에임투지 사용자 서비스 품질 기반 실시간 진입 허용수 관리 장치 및 그 방법
CN114090223A (zh) * 2020-08-24 2022-02-25 北京百度网讯科技有限公司 访存请求调度方法、装置、设备以及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100606897B1 (ko) * 2004-09-10 2006-08-01 엘지노텔 주식회사 연결설정을 위한 처리 방법과 장치
KR20090112532A (ko) * 2008-04-24 2009-10-28 (주)에임투지 대기표 관리 방법, 리소스 관리 방법 및 트랜잭션 서버
KR101654266B1 (ko) 2014-12-18 2016-09-05 (주)에임투지 웹 접속 관리 시스템을 통한 모니터링 기능을 제공하는 모니터링 장치

Also Published As

Publication number Publication date
KR102634229B1 (ko) 2024-02-06

Similar Documents

Publication Publication Date Title
US11425190B2 (en) Delivery of instructions in host applications
US10587672B2 (en) Systems and methods for client-side contextual engagement
US9141722B2 (en) Access to network content
US20190166203A1 (en) Coordinated applications within a mobile device infrastructure
JP2019514091A (ja) 将来のアクションのためのユーザインターフェースデータキャッシングの最適化
KR20140038432A (ko) 사용자 탐색 이벤트의 예측
US11601524B1 (en) Intelligent proactive template driven edge caching method and apparatus
KR102531621B1 (ko) 클라우드 기반 유량제어 비용 최적화를 위한 리소스 최적화 서버, 시스템 및 방법
KR102569833B1 (ko) 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템
KR102519073B1 (ko) 디지털 서비스 기반 트래픽 오케스트레이션을 위한 진입 관리 서버, 시스템 및 방법
KR102519005B1 (ko) 데이터베이스 상태를 이용한 디지털 기반 데이터 송수신 제어 서버, 시스템 및 방법
KR102519051B1 (ko) 디지털 서비스 기반 로드 밸런싱을 위한 대기열 관리 방법, 로드 밸런서 및 대기열 관리 시스템
KR102543972B1 (ko) 디지털 서비스 기반 진입 관리 대상의 자동 조정을 위한 진입 관리 방법 및 서버
KR102559351B1 (ko) 디지털 서비스 기반 트래픽 스파이크 평탄화 기술을 이용한 리소스 최적화 시스템 및 진입 관리 서버
KR102521744B1 (ko) 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템
KR102633182B1 (ko) 디지털 서비스 기반의 발급된 키를 활용한 진입 관리 서버 및 방법
KR102519009B1 (ko) 접속 대기 화면의 정보 제공을 위한 대기열 관리 장치 및 방법
KR102522910B1 (ko) 프록시 방식의 서비스 지속성 보장 시스템 및 방법
KR102519010B1 (ko) 디지털 서비스 기반의 병목 구간 별 진입 대상을 관리하기 위한 진입 관리 서버, 방법 및 프로그램
US10268536B2 (en) Secure debugging with an encrypted token
KR102525431B1 (ko) 디지털 서비스 기반 사전 대기실 운영 방법 및 진입 관리 서버
KR102525069B1 (ko) 클라우드 서버의 리소스 최적화를 위한 트랜잭션 관리 장치 및 방법
KR102630310B1 (ko) 디지털 서비스의 유량 제어를 위한 SaaS 기반 멀티 테넌시 서비스 서버 및 방법
KR102519061B1 (ko) 구간 제어 방식 기반의 유량 제어를 위한 장치 및 방법
US11755392B2 (en) Edge cloud caching using real-time customer journey insights

Legal Events

Date Code Title Description
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
A107 Divisional application of patent
GRNT Written decision to grant