KR102521744B1 - 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템 - Google Patents

디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템 Download PDF

Info

Publication number
KR102521744B1
KR102521744B1 KR1020220190175A KR20220190175A KR102521744B1 KR 102521744 B1 KR102521744 B1 KR 102521744B1 KR 1020220190175 A KR1020220190175 A KR 1020220190175A KR 20220190175 A KR20220190175 A KR 20220190175A KR 102521744 B1 KR102521744 B1 KR 102521744B1
Authority
KR
South Korea
Prior art keywords
api
priority
server
request
service
Prior art date
Application number
KR1020220190175A
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 KR1020220190175A priority Critical patent/KR102521744B1/ko
Application granted granted Critical
Publication of KR102521744B1 publication Critical patent/KR102521744B1/ko

Links

Images

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
    • 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/62—Establishing a time schedule for servicing the requests

Abstract

디지털 서비스 기반 유량 제어 서버, 방법 및 API 유량 제어 시스템이 개시된다. 본 발명의 일 실시예에 따른 디지털 서비스 기반 유량 제어 서버는, 통신부; 및 통신부와 연결되어 API(application programming interface) 유량을 제어하기 위한 프로세서;를 포함하고, 프로세서는, 특정 콘텐츠 서비스를 제공하는 서비스 서버와 연계되어 특정 콘텐츠 서비스를 중계하는 복수의 API 요청 서버로부터 발생된 요청신호를 수신하고, 서비스 서버의 상태 및 요청신호를 기초로 요청신호에 대한 회신 신호를 송신할 복수의 API 요청 서버의 우선순위를 결정하고, 및 우선순위에 따라 복수의 API 요청 서버의 요청신호를 서비스 서버로 전달한다.

Description

디지털 서비스 기반 유량 제어 서버, 방법 및 API 유량 제어 시스템{DIGITAL SERVICE BASED FLOW CONTROL SERVER, METHOD AND API FLOW CONTROL SYSTEM}
본 개시는 API 요청에 대응한 유량을 제어하기 위한 방법에 관한 것이다. 보다 상세하게는, 본 개시는 디지털 서비스 기반 유량 제어 서버, 방법 및 API 유량 제어 시스템에 관한 것이다.
수강신청, 콘서트 예약 및 구매 이벤트 등의 콘텐츠 서비스를 제공하는 서비스 서버의 동시 접속자가 증가함에 따라, 콘텐츠 서비스를 제공하는 서비스 서버측의 응답속도가 저하되거나 서비스가 중단되는 등의 상황이 종종 발생하고 있는 실정이다.
시스템은 HTML(hypertext markup language)로 구성된 페이지를 제공하는 WEB, WEB으로부터 전달된 요청 메시지에 대한 응용 프로그램 서비스를 처리하는 WAS(web application server) 및 쿼리문에 대한 응답으로 제공할 수 있는 데이터를 저장하는 데이터베이스로 구성될 수 있다.
상술한 시스템은 API(application programming interface)를 포함하여, 상기 시스템에서 제공하는 콘텐츠 서비스를 중계하는 복수의 서버와 연계될 수 있다.
한편, 상기 복수의 서버로부터 콘텐츠 서비스와 관련된 요청신호가 동시 다발적으로 발생할 수 있는데, 이에 대한 회신을 원활하게 처리하지 못하면 엔드 유저의 불만이 발생할 수 있다.
대한민국 등록특허공보 제10-1654266호 (2016. 08. 30.)
본 개시에 개시된 실시예는 API(application programming interface) 호출 주체들에 회신 우선순위를 부여하여 API 유량을 효율적으로 관리할 수 있도록 하기 위한 디지털 서비스 기반 유량 제어 서버, 방법 및 API 유량 제어 시스템을 제공하는데 그 목적이 있다.
본 개시가 해결하고자 하는 과제들은 이상에서 언급된 과제로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 기술적 과제를 달성하기 위한 본 개시에 일 측면에 따른 디지털 서비스 기반 유량 제어 서버는, 통신부; 및 상기 통신부와 연결되어 API(application programming interface) 유량을 제어하기 위한 프로세서;를 포함하고, 상기 프로세서는, 특정 콘텐츠 서비스를 제공하는 서비스 서버와 연계되어 상기 특정 콘텐츠 서비스를 중계하는 복수의 API 요청 서버로부터 발생된 요청신호를 수신하고, 상기 서비스 서버의 상태 및 상기 요청신호를 기초로 상기 요청신호에 대한 회신 신호를 송신할 상기 복수의 API 요청 서버의 우선순위를 결정하고, 및 상기 우선순위에 따라 상기 복수의 API 요청 서버의 요청신호를 상기 서비스 서버로 전달할 수 있다.
상기 프로세서는, 상기 우선순위를 결정할 때, 상기 복수의 API 요청 서버의 요청신호에 포함된 호출 식별자 및 참조정보를 기초로 결정할 수 있다.
상기 프로세서는, 상기 우선순위를 결정할 때, 상기 복수의 API 요청 서버로부터 전송된 요청신호의 빈도를 기초로 결정하되, 상기 요청신호의 빈도가 많을수록 상기 우선순위를 상위 우선순위로 결정할 수 있다.
상기 프로세서는, 상기 우선순위를 결정할 때, 상기 요청신호에 대응되어 상기 복수의 API 요청 서버로 회신해야 할 데이터의 크기를 기초로 상기 우선순위를 결정하되, 상기 회신해야 할 데이터의 크기가 클수록 상위 우선순위로 결정할 수 있다.
상기 프로세서는, 상기 우선순위를 결정할 때, 상기 복수의 API 요청 서버의 누적된 우선순위를 기초로 상기 복수의 API 요청 서버들 각각에 기 설정된 주기마다 기 설정된 상위 우선순위를 부여할 수 있다.
상기 프로세서는, 상기 복수의 API 요청 서버 중 특정 API 요청 서버의 우선순위가 최우선 순위로 결정된 후, 해당 API 요청 서버의 요청신호에 대응되어 회신해야 하는 데이터의 리소스가 부족한 경우 상기 API 요청 서버로 지연 알림을 전달할 수 있다.
상기 프로세서는, 상기 복수의 API 요청 서버 각각에 대해 결정된 제1 우선순위를 상기 서비스 서버의 상태를 기초로 제2 우선순위로 변경하되, 상기 서비스 서버의 CPU 상태 및 GPU 상태 중 적어도 하나 이상을 기초로 변경할 수 있다.
또한, 본 개시의 다른 측면에 따른 디지털 서비스 기반 API 유량 제어 시스템은, 특정 콘텐츠 서비스를 제공하기 위한 서비스 서버; 상기 서비스 서버와 연계되어, 상기 특정 콘텐츠 서비스와 관련되어 요청신호를 발생시키는 복수의 API 요청 서버; 및 상기 복수의 API 요청 서버로부터 발생된 요청신호를 수신하고, 상기 서비스 서버의 상태 및 상기 요청신호를 기초로 상기 요청신호에 대한 회신 신호를 송신할 상기 복수의 API 요청 서버의 우선순위를 결정하는 유량 제어 서버;를 포함할 수 있다.
또한, 본 개시의 다른 측면에 따른 디지털 서비스 기반 유량 제어 방법은, API 유량 제어 서버에 의해 수행되는 방법에 있어서, 특정 콘텐츠를 제공하기 위한 서비스 서버와 연계된 복수의 API 요청 서버로부터 발생된 요청신호를 수신하는 단계; 상기 서비스 서버의 상태 및 상기 요청신호를 기초로 상기 복수의 API 요청 서버로 회신 신호를 송신할 우선순위를 결정하는 단계; 및 상기 우선순위에 따라 상기 복수의 API 요청 서버의 요청신호를 상기 서비스 서버로 전달하는 단계;를 포함할 수 있다.
상기 디지털 서비스 기반 유량 제어 방법은, 상기 우선순위를 결정하는 단계에서, 상기 복수의 API 요청 서버의 신호에 포함된 호출 식별자 및 참조정보를 기초로 결정할 수 있다.
이 외에도, 본 개시를 구현하기 위한 실행하기 위한 컴퓨터 판독 가능한 기록 매체에 저장된 컴퓨터 프로그램이 더 제공될 수 있다.
이 외에도, 본 개시를 구현하기 위한 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공될 수 있다.
본 개시의 전술한 과제 해결 수단에 의하면, API(application programming interface) 호출 주체들에 회신 우선순위를 부여하여 API 유량을 효율적으로 관리할 수 있다는 효과를 기대할 수 있다.
또한, 본 개시의 전술한 과제 해결 수단에 의하면, API 호출 주체들의 회신 우선순위뿐만 아니라 서비스 서버의 상태도 고려하여 API 호출에 대한 회신을 수행하기 때문에, 보다 효율적인 API 유량 제어를 수행할 수 있고, 이로 인해 콘텐츠 서비스를 이용하는 엔드 유저의 만족도도 상승할 수 있다는 효과를 기대할 수 있다.
본 개시의 효과들은 이상에서 언급된 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 API 유량 제어 시스템의 구성을 나타내는 도면
도 2는 본 개시의 유량 제어 서버의 구성을 나타내는 블록도
도 3 내지 도 9은 본 개시의 API 유량 제어 방법을 설명하기 위한 예시도
도 10은 본 개시의 유량 제어 방법을 설명하기 위한 흐름도
본 개시 전체에 걸쳐 동일 참조 부호는 동일 구성요소를 지칭한다. 본 개시가 실시예들의 모든 요소들을 설명하는 것은 아니며, 본 개시가 속하는 기술분야에서 일반적인 내용 또는 실시예들 간에 중복되는 내용은 생략한다. 명세서에서 사용되는 '부, 모듈, 부재, 블록'이라는 용어는 소프트웨어 또는 하드웨어로 구현될 수 있으며, 실시예들에 따라 복수의 '부, 모듈, 부재, 블록'이 하나의 구성요소로 구현되거나, 하나의 '부, 모듈, 부재, 블록'이 복수의 구성요소들을 포함하는 것도 가능하다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 직접적으로 연결되어 있는 경우 뿐 아니라, 간접적으로 연결되어 있는 경우를 포함하고, 간접적인 연결은 무선 통신망을 통해 연결되는 것을 포함한다.
또한 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
명세서 전체에서, 어떤 부재가 다른 부재 "상에" 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
제 1, 제 2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위해 사용되는 것으로, 구성요소가 전술된 용어들에 의해 제한되는 것은 아니다.
단수의 표현은 문맥상 명백하게 예외가 있지 않는 한, 복수의 표현을 포함한다.
각 단계들에 있어 식별부호는 설명의 편의를 위하여 사용되는 것으로 식별부호는 각 단계들의 순서를 설명하는 것이 아니며, 각 단계들은 문맥상 명백하게 특정 순서를 기재하지 않는 이상 명기된 순서와 다르게 실시될 수 있다.
이하 첨부된 도면들을 참고하여 본 개시의 작용 원리 및 실시예들에 대해 설명한다.
본 명세서에서 '본 개시에 따른 API 유량 제어 서버'는 연산처리를 수행하여 사용자에게 결과를 제공할 수 있는 다양한 장치들이 모두 포함된다. 예를 들어, 본 개시에 따른 API 유량 제어 서버는, 컴퓨터, 서버 장치 및 휴대용 단말기를 모두 포함하거나, 또는 어느 하나의 형태가 될 수 있다.
여기에서, 상기 컴퓨터는 예를 들어, 웹 브라우저(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은 본 개시의 API 유량 제어 시스템의 구성을 나타내는 도면이다.
도 1을 참고하면, API 유량 제어 시스템은 유량 제어 서버(100), 서비스 서버(200) 및 API 요청 서버(300)를 포함할 수 있다. 도시하는 바와 같이, API 요청 서버(300)는 복수 개일 수 있다.
서비스 서버(200)는 특정 콘텐츠 서비스를 제공하기 위한 구성일 수 있다.
예를 들어, 서비스 서버(200)는 여행과 관련된 호텔을 비롯한 숙소를 예약하기 위한 콘텐츠 서비스를 제공하는 구성(예를 들어, 부킹닷컴(Booking.com)의 서버)일 수 있다. 이러한 콘텐츠 서비스는 서비스 서버(200) 자체에서 제공되는 API를 통한 웹 페이지(예를 들어, 부킹닷컴 홈 페이지) 또는 애플리케이션을 통해 제공될 수 있지만, NAVER, DAUM 등의 각종 포털 서버에서의 중계를 통해서도 제공될 수 있다.
구체적으로, 서비스 서버(200)는 API(application programming interface)를 포함하는 콘텐츠 서비스를 제공하는 서버로, 상기 API는 다수의 API 요청 서버(300)로부터 호출될 수 있다. 이때, API 요청은 콘텐츠 서비스와 관련된 각종 요청(예를 들어, 숙소 상세 정보, 예매 정보 요청 등)일 수 있다.
일 예로, 동일한 API는 호출 주체(API 요청 서버(300))를 불문하고 동일한 데이터를 제공할 수 있다. 다른 예로, 일부 API는 복수의 API 요청 서버(300) 각각의 요청신호에 포함된 검색조건에 따라 다른 데이터를 제공할 수 있다. 하나의 서비스 서버(200)의 API가 다수의 협력업체인 복수의 API 요청 서버(300)로부터 호출되는 과정에서 비즈니스 관점의 회신 우선순위가 발생할 수 있다. 예를 들어, A 협력업체로부터의 API 요청(요청신호)에 대해 최우선순위로 빠르게 대응할 필요성이 있는 경우, 이를 우선적으로 처리하고 B 협력업체로부터의 API 요청을 상대적으로 낮은 우선순위로 처리할 수 있는 것이다.
WAS(web application server)가 서비스 서버(API 서버)(200)의 역할을 수행하는 경우, API가 서비스 서버(200) 내부에서 호출되는지 외부에서 호출되는지에 따라 자사 서비스의 응답속도를 조절할 수 있다. 즉, 상술한 복수의 API 요청 서버(300) 각각이 API로 API 요청을 발생시키되, 복수의 API 요청 서버(300) 중 서비스 서버(200) 내부에서 발생한 API 요청에 대해 상대적으로 빠르게 또는 느리게 사전 설정에 따라 응답을 수행할 수 있다는 것이다.
상술한 WAS는 HTTP를 이용한 애플리케이션 서버를 의미하는 것으로, 정적인 HTTP 데이터 처리에 특화된 웹 서버에 동적인 데이터를 이용할 수 있도록 하는 컨테이너(container)를 포함할 수 있다.
WAS는 데이터베이스 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위한 애플리케이션 서버일 수 있다. 상기, WAS는 HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행하여 주는 미들웨어(소프트웨어 엔진)일 수 있다. WAS는 웹 컨테이너(web container) 또는 서블릿 컨테이너(servlet container)라고 명명하는 것도 가능하다. 이때, 컨테이너는 JSP 및 Servlet을 실행시킬 수 있는 소프트웨어를 의미할 수 있다. WAS는 분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산 환경에서 적용될 수 있다. 구체적으로, WAS는 프로그램 실행 환경과 데이터베이스의 접속 기능 및 다수의 트랜잭션 관리 기능을 구현할 수 있다. 상기 트랜잭션은 논리적인 작업 단위를 의미할 수 있다. WAS는 사용자의 요청에 따라 데이터베이스로부터 해당 데이터를 수신하여, 비즈니스 로직에 맞게 실시간으로 결과를 생성하여 제공할 수 있다.
한편, 서비스 서버(200)는 웹(web) 서버, 상술한 웹 애플리케이션 서버(web application server, 이하, WAS라고 하기로 함) 및 데이터베이스(DB)를 포함할 수 있다. 이때, 데이터베이스는 데이터베이스 관리 시스템(database management system, DBMS)이라 하는 것도 가능하다.
웹 서버는 HTTP(hypertext transfer protocol) 프로토콜을 기반으로 웹 브라우저 또는 웹 크롤러와 같은 클라이언트의 요청을 주로 처리하는 서버를 의미하는 것으로, HTTP 요청(request)을 수신하면 이에 대한 HTTP 응답(response)을 회신할 수 있다.
예를 들어, 웹 서버는 파일 경로 이름을 수신하여 경로와 일치하는 정적(static)인 형태의 파일 콘텐츠(html, jpeg, css 등)를 반환할 수 있다.
웹 서버는 동적인 컨텐츠 제공을 위한 요청을 WAS로 전달하고, 이에 대한 처리 결과를 WAS로부터 수신하여 클라이언트에게 전달할 수 있다.
복수의 API 요청 서버(300)는 서비스 서버(200)와 연계되어, 특정 콘텐츠 서비스와 관련되어 요청신호를 발생시킬 수 있다. 예를 들어, 본 개시의 복수의 API 요청 서버(300)는 상술한 NAVER, DAUM 등의 각종 포털 서버와 같은 중계 서버를 의미할 수 있다.
유량 제어 서버(100)는 통신 흐름 상 서비스 서버(200)(예를 들어, API 서버인 서비스 서버 또는 WAS 서버)의 전단에 요청신호(API 호출 또는 API 요청)을 관리하도록 위치할 수 있다. 이를 위해, 유량 제어 서버(100)는 복수의 API 요청 서버(300)로부터 발생되는 요청신호(API 요청)를 수신할 수 있다.
유량 제어 서버(100)는 복수의 API 요청 서버(300)로부터 발생된 요청신호를 수신하고, 서비스 서버(200)의 상태 및 요청신호를 기초로 상기 요청신호에 대한 회신 신호를 송신할 복수의 API 요청 서버(300)의 우선순위를 결정할 수 있다. 즉, 복수의 API 요청 서버(300) 중 어느 API 요청 서버로 요청신호에 대한 회신을 전송할 순위를 결정할 수 있다는 것이다.
이를 위해, 유량 제어 서버(100)는 서비스 서버(200)의 리소스 상태를 모니터링 할 수 있다. 상기 우선순위는 운용자에 의해서 직접 설정될 수 있으며, 호출 식별자인 복수의 API 요청 서버(300) 각각에 대해 우선순위가 부여될 수 있다.
유량 제어 서버(100)는 우선순위가 상대적으로 높은 API 요청을 확인하면, 서비스 서버(200)와의 접속을 위한 대기열에서 대기순서를 변경하여 서비스 서버(200)에 API 요청이 빠르게 전달될 수 있도록 할 수 있다.
본 개시에서의 API 유량 제어로 인해, VIP용 서비스 서버를 별도로 구현할 필요 없이, 동일한 하나의 API 함수를 모든 주체가 호출하는 환경에서 우선순위 조정이 가능할 수 있다는 효과를 기대할 수 있는 것이다.
한편, 본 개시의 API 유량 제어를 위해서, 서비스 서버(200)는 기존 코드를 수정하기 않고, 에이전트(agent)(예를 들어, WAS용 에이전트)를 설치하여 자동으로 구동될 수 있도록 할 수 있다. 이때, API 유량 제어를 위한 에이전트는 복수의 API 요청 서버(300) 각각에도 설치될 수 있다. 이때, 에이전트는 소프트웨어 개발 키트(Software Development Kit, SDK) 형태로 서비스 서버(200) 및 복수의 API 요청 서버(300)로 전달될 수 있다.
도 2는 본 개시의 유량 제어 서버의 구성을 나타내는 블록도이다.
이하에서는, 본 개시의 API 유량 제어 방법을 설명하기 위한 예시도인 도 3 내지 도 9를 참조하여 설명하기로 한다.
도 2를 참고하면, 유량 제어 서버(100)는 프로세서(110), 메모리(130) 및 통신부(150)를 포함한다. 도 2에 도시된 구성요소들은 본 개시에 따른 유량 제어 서버(100)를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 유량 제어 서버(100)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.
프로세서(110)는 통신부(150)와 연결되어 API(application programming interface) 유량을 제어하기 위한 구성일 수 있다.
프로세서(110)는 특정 콘텐츠 서비스를 제공하는 서비스 서버(200)와 연계되어 특정 콘텐츠 서비스를 중계하는 복수의 API 요청 서버(300)로부터 발생된 요청신호를 수신할 수 있다. 이때, 요청신호는 API 요청으로, 호출 식별자 및 참조정보를 비롯하여 상기 특정 콘텐츠 서비스와 관련된 각종 정보를 포함할 수 있다.
프로세서(110)는 서비스 서버(200)의 상태 및 요청신호를 기초로 상기 요청신호에 대한 회신 신호를 송신할 복수의 API 요청 서버(300)의 우선순위를 결정할 수 있다.
일 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)의 요청신호에 포함된 호출 식별자 및 참조정보를 기초로 결정할 수 있다. 이때, 호출 식별자 및 참조정보를 기초로 우선순위를 결정하는 기준은 운용자에 의해서 사전에 임의로 설정될 수 있다. 즉, 우선순위를 결정하는 기준은 최우선순위로 할당할 API 요청 서버(300)를 사전에 설정하거나, 또는 복수의 API 요청 서버(300) 각각의 우선순위를 설정한 기준을 포함할 수 있다.
도 3을 참고하면, 복수의 API 요청 서버(300)는 유량 제어 서버(100)로 caller ID와 같은 호출 식별자 및 referer와 같은 참조정보를 포함하는 요청신호를 전송할 수 있다. 상기 참조정보는 현재 요청을 송부한 페이지의 절대 또는 부분 주소를 포함할 수 있다. 만약 참고정보가 링크인 경우, 링크를 포함하는 페이지의 주소를 포함할 수 있다.
예를 들어, 프로세서(110)는 호출 식별자 및 참조정보를 기초로 우선순위를 결정하되, 서비스 서버(200)의 자체 애플리케이션에 해당하는 API 요청 서버(300)의 우선순위를 최우선으로 설정할 수 있다. 또는, 프로세서(110)는 사전에 API 호출(요청신호)에 대한 회신을 우선적으로 제공하기로 협의된 API 요청 서버(300)의 우선순위를 최우선으로 설정할 수 있다. 즉, 프로세서(110)는 운용자에 의해서 설정된 우선순위에 따라 API 요청 서버(300)의 회신 우선순위를 결정할 수 있는 것이다. 이때, 운용자는 서비스 서버(200)와 사전 협약에 의해서 우선순위를 설정할 수도 있다.
한편, OTA(online travel agency) 온라인 여행 플랫폼은 온라인 상에서 각 숙박업소의 예약대행 서비스를 제공하는 플랫폼으로, 메타검색 서비스를 제공하는 API 요청 서버(300)들과 서로 API로 연결될 수 있다. 본 개시에서, OTA 온라인 여행 플랫폼은 서비스 서버(200)를 의미할 수 있다. 즉, 서비스 서버(200) 및 API 요청 서버(300) 각각은 서로 API로 연결될 수 있는 것이다.
예를 들어, 도 4를 참고하면, 제1 API 요청 서버(300-1) 및 제2 API 요청 서버(300-2)는 엔드 유저의 요청에 따라 서비스 서버(200)로 숙소 정보를 요청하고, 서비스 서버(200)는 해당 호텔에 숙소 정보를 요청 및 수신하여 회신할 수 있다. 이때, 엔드 유저는 휴대폰과 같은 모바일 단말 또는 데스크탑과 같은 유선 단말을 포함하는 사용자 단말(100)을 통해 API 요청 서버(300)에 접근할 수 있다. 상기 제1 API 요청 서버(300-1)는 카약 및 스카이스캐너와 같은 메타검색 서비스를 제공하는 서버이고, 제2 API 요청 서버(300-2)는 서비스 서버(200)의 자체 운영 서버이며, 서비스 서버(200)는 부킹닷컴과 같은 API 서버를 의미할 수 있다.
유량 제어 서버(100)의 프로세서(110)는 사전 설정에 따라 서비스 서버(200)에서 자체적으로 운영하는 제2 API 요청 서버(300-2)로부터 발생된 요청신호(API 요청)에 대한 회신 우선순위를 상대적으로 상위 우선순위로 설정하고, 메타검색 서비스를 제공하는 제1 API 요청 서버(300-1)의 우선순위를 후순위로 설정할 수 있다. 즉, 제2 API 요청 서버(300-2)의 회신 우선순위를 1순위, 제1 API 요청 서버(300-1)의 회신 우선순위를 2순위로 설정할 수 있는 것이다.
프로세서(110)는 사업적인 필요에 따라 서비스 서버(200) 자체 운용 API 요청 서버(300)에 대한 우선순위를 상대적으로 상위 우선순위로 결정하는 방식을 하위 우선순위로 결정하는 방식으로 변경 적용하는 것 역시 가능할 수 있다. 즉, 상술한 방식을 반대로 적용할 수 있는 것도 가능하다 할 것이다.
다른 한편, 금융권에서 MyData에 대한 제도가 개선되어, 하나의 은행 서비스 서버에서 자기 명의의 다른 은행 계좌 조회가 가능한 오픈뱅킹 시스템이 제공되고 있다. 도 5를 참고하면, 프로세서(110)는 A 은행 서비스를 제공하는 서비스 서버(200)와 직접 연계된 A 은행의 제2 API 요청 서버(300-2)로부터 호출되는 계좌조회 API와, B 은행의 제1 API 요청 서버(300-1)로부터 호출되는 계좌조회 API의 우선순위를 서로 다르게 설정할 수 있다. 예를 들어, 도 9와 같이, 프로세서(110)는 A 은행의 제2 API 요청 서버(300-2)의 우선순위를 최상위 우선순위로 설정하고, B 은행의 제1 API 요청 서버(300-1)의 우선순위를 후순위로 설정할 수 있다. 이와 같이, API 호출에 대한 회신을 제어하여 효율적인 서버 운영을 할 수 있다는 효과를 기대할 수 있다.
다른 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)로부터 전송된 요청신호의 빈도를 기초로 결정하되, 요청신호의 빈도가 많을수록 우선순위를 상위 우선순위로 결정할 수 있다.
도 6을 참고하면, 프로세서(110)는 복수의 API 요청 서버(300)로부터 전송되는 요청신호의 빈도가 많을수록 상위 우선순위로 결정할 수 있는 것이다. 즉, 복수의 API 요청 서버(300)의 우선순위는 요청신호의 빈도(N1> N2)가 가장 많은 해당 서버를 최우선순위로 설정하고 이후 빈도 수에 따라 순차적으로 우선순위를 설정(P1 > P2)할 수 있는 것이다. 상기 N은 요청신호의 빈도, P는 우선순위를 의미할 수 있다.
다른 예로, 도 7을 참고하면, 프로세서(110)는 우선순위를 결정할 때, 요청신호에 대응되어 복수의 API 요청 서버(300)로 회신해야 할 데이터의 크기를 기초로 우선순위를 결정하되, 회신해야 할 데이터의 크기가 클수록 상위 우선순위로 결정할 수 있다. 예를 들어, 제1 및 제2 API 요청 서버(300-2)로부터 각각 발생된 요청신호에 대응되어 회신해야 할 데이터의 크기가 각각 D1 > D2인 경우, 프로세서(110)는 데이터의 크기가 더 큰 제1 API 요청 서버(300-1)의 요청신호에 대한 회신을 제2 API 요청 서버(300-2) 보다 우선적으로 처리할 수 있도록 우선순위를 결정(P1 > P2)할 수 있다. 예를 들어, 요청신호에 대응되어 회신해야 할 데이터는 숙소 이미지, 숙소 소개 등과 같이 콘텐츠 서비스와 관련된 각종 정보를 포함할 수 있다.
다른 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)의 누적된 우선순위를 기초로 복수의 API 요청 서버(300)들 각각에 기 설정된 주기마다 기 설정된 상위 우선순위를 부여할 수 있다. 즉, 프로세서(110)는 누적된 우선순위가 낮은 경우, 상위 우선순위(예를 들어, 최우선순위 또는 기 설정된 순위 이상의 상위 우선순위)를 복수의 API 요청 서버(300)에 고르게 분배할 수 있다.
도 8을 참고하면, 프로세서(110)는 복수의 API 요청 서버(300) 중 제3 API 요청 서버(300-3)가 이전 3회동안 최우선순위로 부여된 경우, 이번에는 제1 API 요청 서버(300-1)를 최우선순위로 부여할 수 있다. 즉, 프로세서(110)는 요청신호에 대한 회신을 매번 상대적으로 늦게 회신한 API 요청 서버(300)에 대해 기 설정된 주기마다 최우선순위로 부여하여 빠르게 회신 받을 수 있도록 하는 것이다.
상술한 우선순위를 결정하는 방식은 단독 또는 적어도 하나 이상의 방식이 결합되어 적용될 수 있다.
구체적으로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)의 요청신호에 포함된 호출 식별자 및 참조정보를 기초로 최우선순위를 결정하고, 나머지 복수의 API 요청 서버(300)로부터 전송된 요청신호의 빈도를 기초로 후순위를 결정할 수 있다. 예를 들어, 제1 API 요청 서버(300) 내지 제4 API 요청 서버(300) 중 사전에 협약된 제1 API 요청 서버(300)의 우선순위를 1순위로 부여하고, 제2 내지 제4 API 요청 서버(300)는 요청신호의 빈도가 많은 기준으로 2위, 3위 및 4위를 각각 부여할 수 있는 것이다.
이 외에도, 프로세서(110)는 상술한 복수의 API 요청 서버(300)의 요청신호에 포함된 호출 식별자 및 참조정보, 복수의 API 요청 서버(300)로부터 전송된 요청신호의 빈도, 복수의 API 요청 서버(300)로 회신해야 할 데이터의 크기, 복수의 API 요청 서버(300)의 누적된 우선순위를 기초로 복수의 API 요청 서버(300)들 각각에 기 설정된 주기마다 기 설정된 상위 우선순위를 부여하는 것 및 이들의 조합 중 적어도 하나 이상을 기초로 우선수위를 부여할 수 있다.
프로세서(110)는 복수의 API 요청 서버(300) 중 특정 API 요청 서버(300)의 우선순위가 최우선순위로 결정된 후, 해당 API 요청 서버(300)의 요청신호에 대응되어 회신해야 하는 데이터의 리소스가 부족한 경우 API 요청 서버(300)로 지연 알림을 전달할 수 있다. 즉, 최우선순위로 결정된 API 요청 서버(300)의 요청신호에 대한 회신 데이터를 처리하기 위한 서비스 서버(200)의 리소스가 부족한 경우, 이러한 상황을 지연 알림을 통해 해당 API 요청 서버(300)로 전달한다는 것이다. 이로 인해, API 요청 서버(300)를 통해 콘텐츠 서비스를 이용하고 있는 엔드 유저의 회신 지연에 대한 불만을 사전에 해소시킬 수 있다는 효과를 기대할 수 있는 것이다.
프로세서(110)는 복수의 API 요청 서버 각각에 대해 결정된 제1 우선순위를 서비스 서버(200)의 상태를 기초로 제2 우선순위로 변경하되, 서비스 서버(200)의 CPU 상태 및 GPU 상태 중 적어도 하나 이상을 기초로 변경할 수 있다. 이때, 서비스 서버의 상태는 CPU 상태 및 GPU 상태에 한정되지 않고, 콘텐츠 서비스와 관련하여 요청신호(API 요청)에 대한 회신 데이터를 생성 및 회신하는데 고려되어야 하는 서비스 서버(300) 내 모든 구성의 상태를 포함할 수 있다.
즉, 프로세서(110)는 수신한 요청신호(API 요청)의 종류에 따라 서로 다른 방식으로 제어할 수 있는 것이다. 프로세서(110)는 특정 요청신호가 서비스 서버(200) 내 특정 내부 구성의 리소스를 과다하게 사용하거나, DB의 특정 테이블에 부하를 발생시키는 경우에는 우선순위를 임의로 조정할 수 있다. 이를 위해, 프로세서(110)는 API 함수 각각이 참조하는 DB 테이블이나 서비스 서버 자원에 대한 정보를 추가로 구축 및 관리할 수 있다.
도 9를 참고하면, 프로세서(110)는 제1 API 요청 서버(300-1)에 최우선순위인 우선순위 1을 부여하고, 제2 API 요청 서버(300-2)에 우선순위 2를 부여하고, 제3 API 요청 서버(300-3)에 우선순위 3을 부여할 수 있다.
이때, 제1 API 요청 서버(300-1)의 요청신호에 대응되는 회신 데이터는 서비스 서버(200) 내 CPU에 의해서 처리되어야 하고, 제2 API 요청 서버(300-2)의 요청신호에 대응되는 회신 데이터는 서비스 서버(200) 내 GPU에 의해서 처리되어야 할 수 있다.
프로세서(110)는 CPU 상태 및 GPU 상태를 포함하는 서비스 서버(200)의 상태를 요청 및 수신하고, 이를 분석한 결과 CPU 상태가 리소스 부족 등으로 인해 요청신호에 대응되는 회신 데이터를 즉시 처리할 수 없는 상태이고, GPU의 상태가 양호한 경우임을 파악할 수 있다. 프로세서(110)는 상술한 분석결과에 따라, 제1 API 요청 서버(300-1)의 우선순위를 우선순위 1에서 우선순위 2로 변경하고, 제2 API 요청 서버(300-2)의 우선순위를 우선순위 2에서 우선순위 1로 변경할 수 있다.
한편, 상술한 프로세서(110)의 CPU 상태 및 GPU 상태를 포함하는 서비스 서버(200)의 상태를 기초로 우선순위를 변경하는 것은 서비스 서버(200)에 의해서도 구현되는 것 역시 가능하다. 즉, 서비스 서버(200)는 프로세서(110)로부터 전달되는 복수의 API 요청 서버(300)로부터 전달되는 요청신호에 대한 처리 순서를 프로세서(110)에 의해서 설정된 우선순위에 따라 해당 API 요청 서버(300)로부터 전달된 요청신호 순서가 아닌 서비스 서버의 상태를 기초로 변경할 수 있다는 것이다.
프로세서(110)는 우선순위에 따라 복수의 API 요청 서버(300)의 요청신호를 서비스 서버(200)로 전달할 수 있다.
한편, 프로세서(110)는 우선순위와 별도로 서비스 서버(200)의 상태에 따라 요청신호(API 요청)을 서비스 서버(200)로 전달하지 않고 대기열을 생성하여 지연전달할 수 있다.
다른 한편, 서비스 서버(200)는 유량 제어 서버(100)로부터 전달받은 요청을 순차적으로 대응하되, Surf DB 등 서버와 DB와의 대기상태 여부를 고려하여 우선순위를 내부적으로 변경해서 처리할 수 있다.
메모리(130)는 API 유량 제어 방법을 제공하기 위한 컴퓨터 프로그램을 저장할 수 있으며, 저장된 컴퓨터 프로그램은 프로세서(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)는 출력부 및 입력부를 더 포함할 수도 있다.
출력부는 API 유량 제어 결과 등을 제공하기 위한 사용자 인터페이스(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) 등이 있다.
입력부는 사용자에 의해서 입력된 정보를 수신할 수 있다. 입력부는 사용자에 의해서 입력된 정보를 수신하기 위한 사용자 인터페이스 상의 키 및/또는 버튼들, 또는 물리적인 키 및/또는 버튼들을 구비할 수 있다. 입력부를 통한 사용 자 입력에 따라 본 개시의 실시예들에 따른 디스플레이를 제어하기 위한 컴퓨터 프로그램이 실행될 수 있다.
도 10은 본 개시의 유량 제어 방법을 설명하기 위한 흐름도이다.
도 10에서 개시하는 유량 제어 방법은 상술한 도 2의 유량 제어 서버(100)를 통해 구현되는 기술을 모두 적용할 수 있으며, 설명의 편의를 위해 중복되는 상세 설명은 생략하기로 한다.
유량 제어 서버(100)의 프로세서(110)는 특정 콘텐츠를 제공하기 위한 서비스 서버와 연계된 복수의 API 요청 서버로부터 발생된 요청신호를 수신할 수 있다(1100).
다음, 프로세서(110)는 서비스 서버(200)의 상태 및 요청신호를 기초로 복수의 API 요청 서버(300)로 회신 신호를 송신할 우선순위를 결정할 수 있다(1200). 즉, 상기 우선순위는 회신 우선순위를 의미할 수 있다.
일 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)의 요청신호에 포함된 호출 식별자 및 참조정보를 기초로 결정할 수 있다.
다른 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)로부터 전송된 요청신호의 빈도를 기초로 결정하되, 요청신호의 빈도가 많을수록 우선순위를 상위 우선순위로 결정할 수 있다.
다른 예로, 프로세서(110)는 우선순위를 결정할 때, 요청신호에 대응되어 복수의 API 요청 서버(300)로 회신해야 할 데이터의 크기를 기초로 우선순위를 결정하되, 회신해야 할 데이터의 크기가 클수록 상위 우선순위로 결정할 수 있다. 다른 예로, 프로세서(110)는 우선순위를 결정할 때, 복수의 API 요청 서버(300)의 누적된 우선순위를 기초로 복수의 API 요청 서버(300)들 각각에 기 설정된 주기마다 기 설정된 상위 우선순위를 부여할 수 있다.
다음, 프로세서(110)는 우선순위에 따라 복수의 API 요청 서버(300)의 요청신호를 서비스 서버(200)로 전달할 수 있다(1300).
모든 온라인 기반 서비스 제공 업체들(본 개시의 서비스 서버(200))는 다양한 이유로 API를 제공할 수 있다. 상기 API는 서비스 제공 업체가 다른 외부 업체(예를 들어, 본 개시의 API 요청 서버(300))로 필요한 데이터를 전송하는 수단으로 활용될 수 있다. API 중심의 독립적인 비즈니스 제공 업체(링크허브 등등 API만 제공하는 업체)도 생겨나고 있으며, API는 제휴의 구심점 역할을 담당하기 때문에 구글, 페이스북, 카카오 등도 모두 API를 생성 및 제공한다. 본 개시는 이러한 API의 흐름을 체계적으로 제어하기 때문에 원활한 API 서비스(콘텐츠 서비스)를 제공할 수 있다는 효과를 기대할 수 있다.
한편, 전술한 본 개시에 따른 방법은, 하드웨어인 서버와 결합되어 실행되기 위해 프로그램(또는 애플리케이션)으로 구현되어 매체에 저장될 수 있다.
개시된 실시예들은 컴퓨터에 의해 실행 가능한 명령어를 저장하는 기록매체의 형태로 구현될 수 있다. 명령어는 프로그램 코드의 형태로 저장될 수 있으며, 프로세서에 의해 실행되었을 때, 프로그램 모듈을 생성하여 개시된 실시예들의 동작을 수행할 수 있다. 기록매체는 컴퓨터로 읽을 수 있는 기록매체로 구현될 수 있다.
컴퓨터가 읽을 수 있는 기록매체로는 컴퓨터에 의하여 해독될 수 있는 명령어가 저장된 모든 종류의 기록 매체를 포함한다. 예를 들어, ROM(Read Only Memory), RAM(Random Access Memory), 자기 테이프, 자기 디스크, 플래쉬 메모리, 광 데이터 저장장치 등이 있을 수 있다.
이상에서와 같이 첨부된 도면을 참조하여 개시된 실시예들을 설명하였다. 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자는 본 개시의 기술적 사상이나 필수적인 특징을 변경하지 않고도, 개시된 실시예들과 다른 형태로 본 개시가 실시될 수 있음을 이해할 것이다. 개시된 실시예들은 예시적인 것이며, 한정적으로 해석되어서는 안 된다.
100: 유량 제어 서버
110: 프로세서
130: 메모리
150: 통신부
200: 서비스 서버
300: API 요청 서버

Claims (10)

  1. 통신부; 및
    상기 통신부와 연결되어 API 유량을 제어하기 위한 프로세서;를 포함하고,
    상기 프로세서는 특정 콘텐츠 서비스를 제공하는 서비스 서버와 연계되어 상기 특정 콘텐츠 서비스를 중계하는 복수의 API 요청 서버로부터 요청신호를 수신하고, 상기 요청신호에 대한 회신신호를 송신할 상기 복수의 API 요청 서버의 우선순위를 결정하되, 상기 복수의 API 요청 서버 각각에 대해 상기 요청신호를 기초로 결정된 제1 우선순위를 상기 서비스 서버의 상태를 기초로 제2 우선순위로 변경하고, 상기 제2 우선순위에 따라 상기 복수의 API 요청 서버의 요청신호를 상기 서비스 서버로 전달하며,
    상기 요청신호에 포함된 호출 식별자 및 상기 요청신호의 빈도를 기초로 상기 제1 우선순위를 결정하되, 상기 호출 식별자를 기초로 상기 복수의 API 요청 서버 중 상기 서비스 서버의 자체 API를 통해 상기 특정 콘텐츠 서비스를 제공하는 자체 애플리케이션에 해당하는 API 요청 서버의 요청신호를 최우선순위로 결정하고 나머지 API 요청 서버에 대해서는 상기 빈도가 많은 순서대로 상위 우선순위로 결정하는, 디지털 서비스 기반 유량 제어 서버.
  2. 삭제
  3. 삭제
  4. 제1항에 있어서,
    상기 프로세서는,
    상기 빈도 대신 상기 요청신호에 대응되어 상기 복수의 API 요청 서버로 회신해야 할 데이터의 크기를 고려하여 상기 제1 우선순위를 결정하되, 상기 회신해야 할 데이터의 크기가 클수록 상위 우선순위로 결정하는, 디지털 서비스 기반 유량 제어 서버.
  5. 제1항에 있어서,
    상기 프로세서는,
    상기 빈도 대신 상기 복수의 API 요청 서버의 누적 우선순위를 고려하여 상기 제1 우선순위를 결정하되, 상기 누적 우선순위가 낮을수록 상위 우선순위로 결정하는, 디지털 서비스 기반 유량 제어 서버.
  6. 제1항에 있어서,
    상기 프로세서는,
    상기 복수의 API 요청 서버 중 특정 API 요청 서버의 우선순위가 최우선순위로 결정된 후, 상기 특정 API 요청 서버의 요청신호에 대응되어 회신해야 하는 데이터의 리소스가 부족한 경우 상기 특정 API 요청 서버로 지연 알림을 전달하는, 디지털 서비스 기반 유량 제어 서버.
  7. 제1항에 있어서,
    상기 서비스 서버의 상태는,
    CPU 상태 및 GPU 상태 중 적어도 하나를 포함하는, 디지털 서비스 기반 유량 제어 서버.
  8. 특정 콘텐츠 서비스를 제공하는 서비스 서버;
    상기 특정 콘텐츠 서비스와 관련되어 요청신호를 발생시키는 복수의 API 요청 서버; 및
    상기 복수의 API 요청 서버로부터 상기 요청신호를 수신하고, 상기 요청신호에 대한 회신신호를 송신할 상기 복수의 API 요청 서버의 우선순위를 결정하되, 상기 복수의 API 요청 서버 각각에 대해 상기 요청신호를 기초로 결정된 제1 우선순위를 상기 서비스 서버의 상태를 기초로 제2 우선순위로 변경하는 유량 제어 서버;를 포함하고,
    상기 유량 제어 서버는 상기 요청신호에 포함된 호출 식별자 및 상기 요청신호의 빈도를 기초로 상기 제1 우선순위를 결정하되, 상기 호출 식별자를 기초로 상기 복수의 API 요청 서버 중 상기 서비스 서버의 자체 API를 통해 상기 특정 콘텐츠 서비스를 제공하는 자체 애플리케이션에 해당하는 API 요청 서버의 요청신호를 최우선순위로 결정하고 나머지 API 요청 서버에 대해서는 상기 빈도가 많은 순서대로 상위 우선순위로 결정하는, 디지털 서비스 기반 API 유량 제어 시스템.
  9. API 유량 제어 서버에 의해 수행되는 방법에 있어서,
    특정 콘텐츠 서비스를 제공하는 서비스 서버와 연계된 복수의 API 요청 서버로부터 요청신호를 수신하는 단계;
    상기 복수의 API 요청 서버로 회신신호를 송신할 상기 복수의 API 요청 서버의 우선순위를 결정하되, 상기 복수의 API 요청 서버 각각에 대해 상기 요청신호를 기초로 결정된 제1 우선순위를 상기 서비스 서버의 상태를 기초로 제2 우선순위로 변경하는 단계; 및
    상기 제2 우선순위에 따라 상기 복수의 API 요청 서버의 요청신호를 상기 서비스 서버로 전달하는 단계;를 포함하고,
    상기 요청신호에 포함된 호출 식별자 및 상기 요청신호의 빈도를 기초로 상기 제1 우선순위를 결정하되, 상기 호출 식별자를 기초로 상기 복수의 API 요청 서버 중 상기 서비스 서버의 자체 API를 통해 상기 특정 콘텐츠 서비스를 제공하는 자체 애플리케이션에 해당하는 API 요청 서버의 요청신호를 최우선순위로 결정하고 나머지 API 요청 서버에 대해서는 상기 빈도가 많은 순서대로 상위 우선순위로 결정하는, 디지털 서비스 기반 유량 제어 방법.
  10. 삭제
KR1020220190175A 2022-12-30 2022-12-30 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템 KR102521744B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020220190175A KR102521744B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020220190175A KR102521744B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템

Publications (1)

Publication Number Publication Date
KR102521744B1 true KR102521744B1 (ko) 2023-04-14

Family

ID=85946717

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020220190175A KR102521744B1 (ko) 2022-12-30 2022-12-30 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템

Country Status (1)

Country Link
KR (1) KR102521744B1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060093650A (ko) * 2005-02-22 2006-08-25 마이크로소프트 코포레이션 리소스 관리를 위한 방법 및 시스템
KR101654266B1 (ko) 2014-12-18 2016-09-05 (주)에임투지 웹 접속 관리 시스템을 통한 모니터링 기능을 제공하는 모니터링 장치
KR20160106626A (ko) * 2014-01-13 2016-09-12 페이스북, 인크. 우선순위-기반의 디지털 컨텐츠 다운로드를 위한 시스템 및 방법
KR20200054368A (ko) * 2018-11-05 2020-05-20 삼성전자주식회사 전자 장치 및 이의 제어방법
KR102177432B1 (ko) * 2019-05-29 2020-11-11 연세대학교 산학협력단 포그 컴퓨팅 기반 무선 네트워크에서 태스크 우선순위별 연산량 오프로딩 장치 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060093650A (ko) * 2005-02-22 2006-08-25 마이크로소프트 코포레이션 리소스 관리를 위한 방법 및 시스템
KR20160106626A (ko) * 2014-01-13 2016-09-12 페이스북, 인크. 우선순위-기반의 디지털 컨텐츠 다운로드를 위한 시스템 및 방법
KR101654266B1 (ko) 2014-12-18 2016-09-05 (주)에임투지 웹 접속 관리 시스템을 통한 모니터링 기능을 제공하는 모니터링 장치
KR20200054368A (ko) * 2018-11-05 2020-05-20 삼성전자주식회사 전자 장치 및 이의 제어방법
KR102177432B1 (ko) * 2019-05-29 2020-11-11 연세대학교 산학협력단 포그 컴퓨팅 기반 무선 네트워크에서 태스크 우선순위별 연산량 오프로딩 장치 및 방법

Similar Documents

Publication Publication Date Title
KR102312916B1 (ko) 데이터 수집 동의 도구
US9760909B2 (en) Systems and methods for generating lead intelligence
US11425190B2 (en) Delivery of instructions in host applications
US11140230B2 (en) Method and procedure for dynamic services orchestration that runs within an on-device software container
US10686862B2 (en) Apparatus and method for low-latency message request/response processing
US11010215B2 (en) Recommending applications based on call requests between applications
TW201546728A (zh) 社群行事曆事件共享
JP2008543249A (ja) 移動ユーザプロフィールに基づくコンテンツのプレフェッチ
US11954629B2 (en) Activation policies for workflows
KR20100035692A (ko) 웹-기반 클라이언트-서버 애플리케이션의 오프라인 사용을 가능하게 하는 방법 및 장치
US20190020606A1 (en) Systems for managing messaging conversations
US10678881B2 (en) Usage-based predictive prefetching and caching of component-based web pages for performance optimization
US10924570B2 (en) Notification updates for saved sites
KR102531621B1 (ko) 클라우드 기반 유량제어 비용 최적화를 위한 리소스 최적화 서버, 시스템 및 방법
TWI493356B (zh) 非同步通信的方法、非同步地與網路瀏覽器通信的方法，及用於與網路通信的系統
KR102521744B1 (ko) 디지털 서비스 기반 유량 제어 서버, 방법 및 api 유량 제어 시스템
US20140297762A1 (en) Method and system for timezone aware application programming interface
US20140257878A1 (en) Routing preferred traffic within a reservation system
KR102569833B1 (ko) 디지털 서비스 기반 서비스 서버의 모니터링을 이용한 유량 제어 방법, 서버 및 시스템
KR102519073B1 (ko) 디지털 서비스 기반 트래픽 오케스트레이션을 위한 진입 관리 서버, 시스템 및 방법
KR102630310B1 (ko) 디지털 서비스의 유량 제어를 위한 SaaS 기반 멀티 테넌시 서비스 서버 및 방법
KR102519051B1 (ko) 디지털 서비스 기반 로드 밸런싱을 위한 대기열 관리 방법, 로드 밸런서 및 대기열 관리 시스템
KR102559351B1 (ko) 디지털 서비스 기반 트래픽 스파이크 평탄화 기술을 이용한 리소스 최적화 시스템 및 진입 관리 서버
KR102519005B1 (ko) 데이터베이스 상태를 이용한 디지털 기반 데이터 송수신 제어 서버, 시스템 및 방법
KR102519061B1 (ko) 구간 제어 방식 기반의 유량 제어를 위한 장치 및 방법

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant