KR101653685B1 - 컴퓨터 수행 가능한 api 관리 방법 - Google Patents

컴퓨터 수행 가능한 api 관리 방법 Download PDF

Info

Publication number
KR101653685B1
KR101653685B1 KR1020150167898A KR20150167898A KR101653685B1 KR 101653685 B1 KR101653685 B1 KR 101653685B1 KR 1020150167898 A KR1020150167898 A KR 1020150167898A KR 20150167898 A KR20150167898 A KR 20150167898A KR 101653685 B1 KR101653685 B1 KR 101653685B1
Authority
KR
South Korea
Prior art keywords
api
service
user
request
asset
Prior art date
Application number
KR1020150167898A
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 KR1020150167898A priority Critical patent/KR101653685B1/ko
Application granted granted Critical
Publication of KR101653685B1 publication Critical patent/KR101653685B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS

Abstract

컴퓨터 수행 가능한 API 관리 방법은 사용자로부터 API(Application Programming Interface) 서비스의 요청을 분산되게 수신하는 단계, 시간적 서비스 제약조건을 기초로 상기 API 서비스의 요청을 쓰로틀링하여 상기 API 서비스의 제공여부를 결정하는 단계, API 애셋 제공자와 상기 사용자 간에 미리 설정된 서비스 레벨 규약 조건을 기초로 상기 API 서비스의 요청을 재쓰로틀링하여 상기 API 서비스의 제공여부를 재결정하는 단계를 포함한다. 따라서, 컴퓨터 수행 가능한 API 관리 방법은 컨텐츠 및 서비스를 REST API화 하여 관리를 용이하게 하고, API의 개발을 용이하게 하는 기능을 제공할 수 있다.

Description

컴퓨터 수행 가능한 API 관리 방법{COMPUTER-EXCUTABLE METHOD FOR MANAGING API}
본 발명은 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치 에 관한 것으로, 보다 상세하게는, 기존의 비즈니스 자산 또는 클라우드 서비스들로부터 새로운 API를 빠르게 설계할 수 있고, API에 대한 액세스 제어, 효율적 보안, 최적화 및 분석측정기능 등을 수행하여 효율적인 API관리를 가능하게 하는 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 방법에 관한 것이다.
근래에 들어서 모바일 애플리케이션의 발전과 SNS의 발전과 더불어서 Open API 에 대한 관심도가 급격하게 높아졌다. Open API란, API를 내부 사용자뿐만 아니라 외부 개발자에게까지 공개해서, 외부 개발자가 API를 이용해서 새로운 서비스를 만들도록 하는 모델이다. 근래에 들어서는 API만 전문적으로 개발 및 서비스를 해서 이를 통해서 수익을 창출하는 비즈니스 모델까지 생겨나고 있다. 이런 배경으로 API 관리에 대한 중요성이 대두되었는데, API에 대한 쉬운 관리, 모니터링 및 유료화 그리고, API에 대한 편리한 사용법, 샘플 코드 및 매뉴얼을 제공하는 시나리오가 필요하게 되었는데, 이를 하나의 플랫폼 형태로 묶어 놓은 것을 API 플랫폼이라고 한다.
한국등록특허 제10-1528853호는 공개 API서비스에 관한 것으로, API를 실행하기 위한 메타 데이터를 생성하는 단계, API의 매쉬업(mashup)을 생성하기 위한 자원 데이터를 생성하는 단계, API, 메타 데이터 및 자원 데이터에 대한 기술 데이터를 생성하는 단계 및 API, 메타 데이터, 자원 데이터, 및 기술 데이터를 포함하는 API 패키지를 생성하는 단계를 포함하도록 함으로써, 다양한 형태의 API들로부터 매쉬업 컨텐츠를 용이하게 생성할 수 있도록 하는 기술을 개시한다.
한국등록특허 제10-1528853호
본 발명의 일 실시예는 컨텐츠 및 서비스를 REST API화 하여 관리를 용이하게 하고, API의 개발을 용이하게 하는 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치를 제공하고자 한다.
본 발명의 일 실시예는 API의 트래픽을 관리하여 대용량 트래픽을 안정적으로 처리 및 통제할 수 있는 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치를 제공하고자 한다.
본 발명의 일 실시예는 분산환경 기반의 다양한 캐싱을 적용하여 API 분산처리 및 API 처리에 따른 지연시간을 최소화할 수 있는 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치를 제공하고자 한다.
실시예들 중에서, API 관리 방법은 (a) 사용자로부터 API(Application Programming Interface) 서비스의 요청을 분산되게 수신하는 단계, (b) 시간적 서비스 제약조건을 기초로 상기 API 서비스의 요청을 쓰로틀링하여 상기 API 서비스의 제공여부를 결정하는 단계 및 (c) API 애셋 제공자와 상기 사용자 간에 미리 설정된 서비스 레벨 규약 조건을 기초로 상기 API 서비스의 요청을 재쓰로틀링하여 상기 API 서비스의 제공여부를 재결정하는 단계를 포함한다.
일 실시예에서, 상기 (a) 단계는 상기 API 서비스의 제공 적합성을 판단하기 위한 API 서비스 환경정보를 저장하는 단계를 포함할 수 있다.
일 실시예에서, 상기 (c) 단계는 상기 서비스 레벨 규약 조건을 기초로 상기 API 서비스 요청을 실시간 카운트 캐싱하고, 상기 API 서비스의 요청에 관한 재쓰로틀링을 실시간으로 수행하는 단계를 포함할 수 있다.
일 실시예에서, 상기 (b) 단계는 상기 쓰로틀링 후에 상기 사용자에 대한 인증 및 권한 검증을 통해 상기 API 애셋에 대한 접근 가능성을 판단하는 단계를 포함할 수 있다.
일 실시예에서, 상기 (c) 단계는 상기 API 서비스의 요청에 따라 상기 API 서비스의 제공 적합성을 계속적으로 갱신하는 단계를 포함할 수 있다.
일 실시예에서, 상기 API 관리 장치는 로컬 캐시와 원본 캐시를 포함하고, 상기 (c) 단계는 상기 원본 캐시로부터 갱신내용이 수신되면 해당 로컬 캐시에 상기 갱신내용의 유무를 검출하여 상기 해당 로컬 캐시와 상기 원본 캐시 간의 일치성을 유지하는 단계를 포함할 수 있다.
일 실시예에서, 상기 API 관리 방법은 (d) 상기 사용자의 API 서비스 요청 메시지 포맷과 상기 API 애셋 제공자에 의해 생성된 API 애셋의 메시지 포맷 간 메시지 변환을 수행하는 단계를 더 포함할 수 있다. 다른 일 실시예에서, 상기 API 관리 방법은 (e) 상기 사용자에게 기 등록된 상기 API 애셋을 제공하거나 API 애셋 제공자로부터 상기 API 애셋을 원격 호출하여 제공하는 단계를 더 포함할 수 있다.
개시된 기술은 다음의 효과를 가질 수 있다. 다만, 특정 실시예가 다음의 효과를 전부 포함하여야 한다거나 다음의 효과만을 포함하여야 한다는 의미는 아니므로, 개시된 기술의 권리범위는 이에 의하여 제한되는 것으로 이해되어서는 아니 될 것이다.
본 발명의 일 실시예에 따른 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치는 컨텐츠 및 서비스를 REST API화 하여 관리를 용이하게 하고, API의 개발을 용이하게 하는 기능을 제공할 수 있다.
본 발명의 일 실시예에 따른 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치는 API의 트래픽을 관리하여 대용량 트래픽을 안정적으로 처리 및 통제할 수 있다.
본 발명의 일 실시예에 따른 컴퓨터 실행 가능한 API 관리 방법 및 API 관리 장치는 분산환경 기반의 다양한 캐싱을 적용하여 API 분산처리 및 API 처리에 따른 지연시간을 최소화할 수 있다.
도 1은 본 발명의 일 실시예에 따른 API 관리 장치의 개념적 구조를 설명하는 블록도이다.
도 2는 본 발명의 일 실시예에 따른 API 통합관리모듈을 포함하는 API 관리 장치의 구조를 설명하는 블록도이다.
도 3은 도 1에 있는 API 게이트웨이 모듈의 구성을 설명하는 블록도이다.
도 4는 도 1에 있는 API게이트웨이 모듈의 전체 동작을 설명하는 흐름도이다.
도 5는 도 3에 있는 유효성 검증부가 사용자의 API서비스 요청에 대한 유효성을 검증하는 방법을 설명하는 도면이다.
도 6은 도 3에 있는 쓰로틀링부가 API호출을 제어하여 과부하를 방지하고 트래픽을 통제하는 방법을 설명하는 도면이다.
도 7은 도 3에 있는 인증부가 사용자 인증을 처리하고 API 권한을 부여하는 방법을 설명하는 도면이다.
도 8은 도 3에 있는 관리자 포탈 모듈 접근에 대한 보안 강화 관리를 위해 사용되는 추가적인 방법을 설명하는 도면이다.
도 9는 도 1에 있는 OAuth인증부가 표준화된 인증 방식을 제공하는 것을 설명하는 도면이다.
도 10은 도 3에 있는 중재부가 API서비스 요청 메시지 포맷과 API 애셋 메시지 포맷을 변환하여 제공하는 것을 설명하는 도면이다.
도 11은 도 2에 있는 캐시 관리부가 분산환경을 기반으로 API를 분산처리 하는 것을 설명하는 도면이다.
도 12은 도 2에 있는 분석측정관리부가 API 게이트웨이 모듈에서 수집된 로그 정보를 통해 통계정보를 제공하는 것을 설명하는 도면이다.
도 13은 도 2에 있는 응답데이터 관리부가 응답데이터를 API 게이트웨이 모듈로 리턴 하는 과정을 설명하는 도면이다.
본 발명에 관한 설명은 구조적 내지 기능적 설명을 위한 실시예에 불과하므로, 본 발명의 권리범위는 본문에 설명된 실시예에 의하여 제한되는 것으로 해석되어서는 아니 된다. 즉, 실시예는 다양한 변경이 가능하고 여러 가지 형태를 가질 수 있으므로 본 발명의 권리범위는 기술적 사상을 실현할 수 있는 균등물들을 포함하는 것으로 이해되어야 한다. 또한, 본 발명에서 제시된 목적 또는 효과는 특정 실시예가 이를 전부 포함하여야 한다거나 그러한 효과만을 포함하여야 한다는 의미는 아니므로, 본 발명의 권리범위는 이에 의하여 제한되는 것으로 이해되어서는 아니 될 것이다.
한편, 본 출원에서 서술되는 용어의 의미는 다음과 같이 이해되어야 할 것이다.
"제1", "제2" 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위한 것으로, 이들 용어들에 의해 권리범위가 한정되어서는 아니 된다. 예를 들어, 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다.
어떤 구성요소가 다른 구성요소에 "연결되어"있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결될 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어"있다고 언급된 때에는 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다. 한편, 구성요소들 간의 관계를 설명하는 다른 표현들, 즉 "~사이에"와 "바로 ~사이에" 또는 "~에 이웃하는"과 "~에 직접 이웃하는" 등도 마찬가지로 해석되어야 한다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한 복수의 표현을 포함하는 것으로 이해되어야 하고, "포함하다"또는 "가지다" 등의 용어는 실시된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이며, 하나 또는 그 이상의 다른 특징이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
각 단계들에 있어 식별부호(예를 들어, a, b, c 등)는 설명의 편의를 위하여 사용되는 것으로 식별부호는 각 단계들의 순서를 설명하는 것이 아니며, 각 단계들은 문맥상 명백하게 특정 순서를 기재하지 않는 이상 명기된 순서와 다르게 일어날 수 있다. 즉, 각 단계들은 명기된 순서와 동일하게 일어날 수도 있고 실질적으로 동시에 수행될 수도 있으며 반대의 순서대로 수행될 수도 있다.
본 발명은 컴퓨터가 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현될 수 있고, 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다. 컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있으며, 또한, 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
여기서 사용되는 모든 용어들은 다르게 정의되지 않는 한, 본 발명이 속하는 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한 이상적이거나 과도하게 형식적인 의미를 지니는 것으로 해석될 수 없다.
도 1은 본 발명의 일 실시예에 따른 API 관리 장치(10)의 개념적 구조를 설명하는 구조도이다.
도 1을 참조하면, API 관리 장치 (10)는 개발자포탈 모듈(100), API 게이트웨이 모듈(200), 관리자 포탈 모듈(300) 및 OAuth인증부(400)를 포함한다. 도 1에서 엔드유저와 개발자는 통칭하여 사용자로 부를 수 있다. 어플리케이션은 엔드유저 또는 개발자가 사용하고자 하는 응용프로그램 또는 서비스에 해당할 수 있다. API란, 응용프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있도록 만든 인터페이스의 집합체를 의미한다. 개발자포탈 모듈(100)은 개발자 센터(Developer Center)를 의미할 수 있고, 관리자 포탈 모듈(300)은 매니지먼트 센터(Management Center)를 의미할 수 있다.
개발자포탈 모듈(100)은 API 사용자에게 어플리케이션에 대한 정보, API에 대한 정보, API 사용법, API 샘플 등을 제공하거나 API 테스트 등을 할 수 있는 기능을 제공할 수 있다. 즉, 개발자포탈 모듈(100)은 사용자에게 API의 개발뿐만 아니라 API 사용에 대한 편의성을 제공할 수 있다.
개발자포탈 모듈(100)은 API 키 또는 어플리케이션 키를 발급할 수 있고, 관리자 포탈 모듈(300)에 의해 제시된 서비스 레벨 규약 조건(SLA, Service Level Agreement)을 선택할 수 있다. SLA란 품질보장제도를 말하며, 특정 서비스에 대해서 약속한 수준의 품질 요건을 충족시켜주는 것을 의미한다. 예를 들어, 관리자 포탈 모듈(300)에 서비스 레벨 규약 조건이 API 애셋 제공자 별로 하루에 5000건의 호(call)를 제공하거나 API 사용자 별로 하루에 1000건의 호(call)를 제공하는 것으로 제시되어 있는 경우, API게이트웨이 모듈(200)은 개발자포탈 모듈(100)을 통해 선택된 서비스 레벨 규약 조건을 기초로 API 애셋 제공자 별로 하루 5000건의 호(call) 또는 API 사용자 별로 1000건의 호(call)까지만 API 서비스를 제공하게 할 수 있다. 즉, 개발자포탈 모듈(100)은 계약 레벨 별로 서비스 수준을 조정(QoS, Quality of Service 조정) 할 수 있다. 여기에서 애셋 또는 서비스는 API를 의미할 수 있다.
또한, 개발자포탈 모듈(100)은 외부 API사용자에게 API를 제공하는 기능 외에 API를 판매하지 않고 기업 내부에서 부서간 API를 공유하고 쉽게 API를 사용할 수 있게 하는 기능도 제공할 수도 있다. 따라서, 개발 생산성을 높일 수 있는 효과가 있다.
API게이트웨이 모듈(200)은 애셋/서비스의 엔드 포인트를 단일화하여 묶어주고 API 요청에 대한 유효성 검증 기능, API 접근에 대한 인증과 허가를 통한 보안 기능, API에 대한 접근 제어를 통한 서버 과부하 방지 및 트래픽 통제 기능, 메시지에 따라 여러 서버로 라우팅 하는 기능, 분산 메모리 캐싱 기능, 캐싱 데이터 모니터링 기능 및 서비스 사용 통계 기능까지 많은 기능을 제공할 수 있다. 사용자는 API게이트웨이 모듈(200)을 통해 원하는 API를 제공받고 애셋 또는 서비스에 접근할 수 있다. 즉, API게이트웨이 모듈(200)은 API 제공자로부터 API를 원격 호출하거나 애셋 또는 서비스에 등록된 API를 사용자에게 제공할 수도 있다. API게이트웨이 모듈(200)에 대해서는 이하 도 3에서 더 자세히 설명한다.
관리자 포탈 모듈(300)은 API 애셋 제공자에 의하여 생성된 API 애셋을 포함하고, API 애셋 제공자에 의하여 생성된 API에 대한 정보를 관리하고 통제할 수 있다. 또한, 관리자 포탈 모듈(300)은 위에서 설명한 SLA 기준을 제시할 수 있고 API의 수용력에 관한 정보 제공 및 관리 및 API 부정사용(Abusing)에 대한 통제 기능을 제공할 수 있다. 즉, 관리자 포탈 모듈(300)은 API 정보, 인증/검증, 접근 제한 정책, 서비스 정보, QoS(Quality of Service)에 대한 정보, SLA(Service Level Agreement) 및 부정사용(Abusing) 식별정보 등에 관한 캐시 데이터를 모니터링 하여 사용자의 API 호출 및 호출된 API 제공에 대한 관리를 수행할 수 있다.
OAuth인증부(400)는 사용자의 API 서비스 요청이 있는 경우 접근 토큰을 이용하여 표준화된 사용자 인증과 권한 부여 방식을 제공할 수 있다. OAuth인증부(400)는 개별 API에 대한 표준 인증 방식인 OAuth 2.0을 사용하여 사용자 인증을 수행할 수 있다. 이를 통해, OAuth인증부(400)는 API 게이트웨이 모듈(200)의 사용자 인증과 권한 검증에 강화된 보안 기능을 제공할 수 있다. OAuth는 어플리케이션마다 제 각각이었던 인증방식을 표준화함으로써 인증을 공유하는 어플리케이션끼리는 별도의 인증이 필요 없도록 하여 여러 어플리케이션을 통합하여 사용할 수 있게 한다. OAuth에 대해서는 이하 도 9에서 자세히 설명한다.
도 2는 본 발명의 일 실시예에 따른 API 통합관리모듈(20)을 포함하는 API 관리 장치(10)의 구조를 설명하는 구조도이다.
도 2를 참조하면, API 관리 장치(10)는 사용자로부터 API(Application Programming Interface) 서비스의 요청을 분산되게 수신하고 각각은 API 서비스의 제공 적합성을 판단하기 위한 API 서비스 환경정보를 저장하는 적어도 하나의 API 게이트웨이 모듈(200), API 애셋 제공자에 의하여 생성된 API 애셋을 포함하고, API 서비스의 요청에 따라 API 애셋 또는 서비스 제공을 관리하는 관리자 포탈 모듈(300) 및 로컬 캐시(260)를 동기화하는 원본 캐시(530, 730)를 포함하고, 상기 API 서비스의 제공 적합성을 계속적으로 갱신하는 API 통합관리모듈(20)을 포함한다.
즉, API 관리 장치(10)는 도 1에 있는 개발자포탈 모듈(100), API 게이트웨이 모듈(200), 관리자 포탈 모듈(300) 외에 캐시 관리부(500), 실시간 카운트 관리부(600), 분석측정관리부(700) 및 응답데이터 관리부(800)를 포함하는 API 통합관리모듈(20)을 포함할 수 있다.
API 통합관리모듈(20)을 포함하는 API 관리 장치(10)는 API개발, 관리 및 운영을 위해 API의 트래픽 관리, 보안 관리, 버전 관리, 인증, 모니터링, 분석 등을 쉽고 효과적으로 지원할 수 있다.
또한, API 관리 장치(10)는 클라우드 스택(Cloud Stack), 오픈 스택(Open Stack), VMware, IDC(Internet Data Center), AWS(Amazon Web Service) 등의 다양한 인프라 환경에서 온프레미스(On-Premise), 폐쇄형 클라우드(Private Cloud), 공개형 클라우드(Public Cloud), 하이브리드 클라우드(Hybrid Cloud) 등의 개발(Deployment) 모델을 지원할 수 있고, 따라서 사용자가 원하는 서비스 형태에 따라 해당 서비스에서 동작하는 API들을 쉽게 연결해 줄 수 있다. API 통합관리모듈(20)은 API 서비스의 이용에 관한 통합 정보를 관리할 수 있다.
도 2에 있는 캐시 관리부(500)는 API 통합관리모듈(20)과 관리자 포탈 모듈(300)을 연결하는 내부 인터페이스 모듈(510), 적어도 하나의 API 게이트웨이 모듈(200) 각각의 로컬 캐시(260)와 API 통합관리모듈(20)의 원본 캐시(530, 730)를 동기화시켜 로컬 캐시(260)를 갱신시키는 캐시 관리 모듈(520), 원본 캐시 또는 캐시 저장 모듈(530)을 포함할 수 있다.
캐시 관리부(500)는 사용자의 API 서비스의 요청에 대해 적어도 하나의 API 게이트웨이 모듈(200) 각각을 통해 분산 처리하게 함으로써 API 서비스의 요청 처리에 따른 지연 시간을 최소화할 수 있다. 캐시 관리부(500)를 이용한 API 분산 처리에 대해서는 이하 도 11에서 자세히 설명한다.
실시간 카운트 관리부(600)는 사용자의 API 서비스 요청에 대한 실시간 캐싱을 통해 API 서비스의 요청을 카운트하는 캐시 카운터 모듈(610), 캐시 카운터 모듈(610)을 통해 카운트된 API 서비스 요청 수를 실시간으로 모니터링하고 관리하여 QoS(Quality of Service) 및 SLA(Service Level Agreement, 서비스 레벨 규약)을 보장하기 위한 카운트 관리 모듈(620) 및 원본 캐시 또는 캐시 저장 모듈(Cache Repository)(630)을 포함할 수 있다. 보다 상세하게, 실시간 카운트 관리부(600)는 실시간 캐싱한 사용자의 API 서비스 호출을 차감하는 방식으로 QoS와 SLA를 보장한다. 사용자의 API 서비스 호출 차감에 대한 캐싱 정보는 원본 캐시(630)에 저장된다. 실시간 카운트 관리부(600)는 실시간 카운트 캐싱을 통해 API 애셋의 QoS 및 SLA를 보장하고, API 게이트웨이 모듈(200)로 하여금 실시간으로 API 서비스의 요청을 제한할 수 있게 한다. 즉, API 게이트웨이 모듈(200)은 실시간 카운트 관리부(600)를 통해 API 서비스의 요청에 따른 트래픽을 통제할 수 있다. API 서비스의 요청에 따른 트래픽 제어에 대해서는 이하 도 6에서 자세히 설명한다.
분석측정관리부(700)는 통계분석 모듈(710), 이상거래 분석모듈(720) 및 원본 캐시(730)을 포함할 수 있다.
통계분석 모듈(710)은 API 게이트웨이 모듈(200)의 로깅부(240)로부터 로그 정보를 수집하여 수집한 로그 정보를 데이터베이스, 검색엔진 또는 맵 리듀스(MapReduce) 중 하나에 저장할 수 있다. 여기에서 로그 정보는 사용자 API 서비스 요청의 유효성 검증, 인증, 권한부여, 트래픽 제어 또는 API 애셋에 관한 호출 내용 및 호출 에러 여부를 포함할 수 있다. 통계분석 모듈(710)은 수집한 로그정보를 이용해 다양한 통계정보를 생성할 수 있고, 이러한 통계정보는 개발자 포털 모듈(100) 또는 관리자 포탈 모듈(300)에서 조회될 수 있다.
이상거래 분석모듈(720)은 기설정된 시간간격 마다 API 게이트웨이 모둘(200)로부터 로그 정보를 수집할 수 있다. 예를 들어, 이상거래 분석모듈(720)은 1분 간격으로 로그 정보를 수집할 수 있다. 이상거래 분석모듈(720)은 수집한 로그 정보의 IP를 기반으로 이상거래(Abusing)에 대한 접근 제한 여부 및 잠금 시간 통제 여부를 판단한다.
원본 캐시(730)는 기설정된 시간간격 단위로 IP 기반의 이상거래에 대한 접근 제한 여부 및 잠금 시간 통제 여부에 관한 정보를 저장할 수 있다. 각각의 API 게이트웨이 모듈(200)은 로컬 캐시(260)와 분석측정관리부(700)의 원본 캐시(730)를 동기화 하여 이상거래 여부를 판단하고, 이상거래로 판단되는 경우 해당 접근에 대한 차단을 수행할 수 있다. 즉, 분석측정관리부(700)은 API 게이트웨이 모듈(200)에서의 이상거래에 대한 접근 제한 및 잠금 시간 통제 수행을 위한 백업 데이터(Backup Data)를 제공할 수 있다. 이하 도12에서, 분석측정관리부(700)를 자세히 설명한다.
응답데이터 관리부(800)는 애셋 또는 서비스에 대한 응답데이터를 관리할 수 있고, 응답캐시 관리모듈(810) 및 원본 캐시(820)를 포함할 수 있다.
응답캐시 관리모듈(810)은 API 게이트웨이(200)의 중재부(250)에서 응답캐시가 필요한 애셋 또는 서비스를 응답캐시관리 모듈(820)을 통해 호출하면 원본 캐시(820)에 데이터가 있는지 여부를 확인할 수 있다. 응답캐시 관리모듈(810)은 조회결과 원본 캐시(820)에 애셋 또는 서비스에 대한 응답캐시가 없으면 애셋/서비스를 호출하여 원본 캐시(820)에 응답데이터를 저장하고 API 게이트웨이(200)의 중재부(250)으로 응답데이터를 리턴 할 수 있다. 여기서, 응답캐시가 필요한 애셋 또는 서비스는 푸시(Push), 소셜(Social) 서비스 등에 해당할 수 있다.
원본 캐시(820)는 응답캐시가 필요한 애셋 또는 서비스의 조회에 대한 응답데이터를 저장할 수 있다. 일 실시예에서, 원본 캐시(820)는 기설정된 주기마다 응답데이터를 삭제할 수 있다. 응답데이터 관리부(800)의 동작은 이하 도 13에서 자세히 설명한다.
도 3은 도 1에 있는 API 게이트웨이 모듈(200)의 구성을 설명하는 블록도이다.
도 3을 참조하면, API 게이트웨이 모듈(200)은 유효성 검증부(210), 인증부(220), 쓰로틀링부(230), 로깅부(240) 및 중재부(250)를 포함할 수 있다. 또한, API 게이트웨이 모듈(200)은 사용자로부터 API 서비스의 요청을 분산되게 수신하고 각각은 상기 API 서비스의 제공 적합성을 판단하기 위한 API 서비스 환경정보를 저장하는 로컬 캐시(260)를 포함할 수 있다. 여기에서 API 서비스 제공 적합성은 위에서 설명한 서비스 레벨 규약 조건(SLA)을 의미할 수 있고, API 서비스 환경 정보는 API 서비스를 이용하는 어플리케이션 정보, API 서비스 정보, 동기화된 SLA 정보, 경로 검증 규칙, 파라미터 검증 규칙, 인증 정책, 접근 제한 정책, 서비스 정보, 서버 정보 또는 어댑터 정보를 포함할 수 있다.
일 실시예에서, 적어도 하나의 API 게이트웨이 모듈(200) 각각은 원본(530, 730) 캐시로부터 갱신내용이 수신되면 해당 로컬 캐시(260)에 갱신내용의 유무를 검출하여 해당 로컬 캐시(260)와 원본 캐시(530, 730) 간의 일치성을 유지할 수 있다. 또한, 적어도 하나의 API 게이트웨이 모듈(200) 각각은 API 서비스의 요청에 따라 해당 로컬 캐시(260)가 갱신되어야 하는 경우에는 원본 캐시(530, 730)에 갱신의 필요성을 알릴 수 있다.
유효성 검증부(210)는 API 서비스의 요청에 따른 API 애셋의 존재 여부를 확인할 수 있다. 유효성 검증부(210)는 사용자의 API 서비스 요청에 따라 URL 및 헤더(Header)에 대한 유효성을 검증하여 애셋 또는 서비스에 대한 접근 제어 및 API 호출 제어를 수행할 수 있다. 또한, 유효성 검증부(210)는 API게이트웨이 모듈(200)의 로컬 캐시(260)에 저장된 정보를 참조하여 유효성 검증을 수행할 수 있다. 유효성 검증이란 오류 검증이나 표준 적합 검증을 위해 소프트웨어나 수작업으로 수행하는 검사를 말한다. 즉, 사용자의 입력 값에 오류가 있는지 여부를 판단하는 것으로, 사용자의 API 서비스 요청이 적절한지 판단하는 것을 의미한다. 유효성 검증 방법에 대하여는 이하 도 5에서 자세히 설명한다.
인증/권한부(220)는 사용자에 대한 인증 및 권한 검증을 통해 사용자의 API 애셋에 대한 접근 가능성을 판단할 수 있다. 또한, 인증/권한부(220)는 API게이트웨이 모듈(200)의 로컬 캐시(260)에 저장된 정보를 참조하여 사용자에 대한 인증 및 권한부여를 수행할 수 있다. 인증은 API를 호출하는 사용자 또는 클라이언트에 대한 신분(identity)를 확인(즉, 인증키에 대한 확인)하는 기능이고, 권한 부여 또는 검증은 사용자 또는 클라이언트가 API를 호출할 수 있는 권한이 있는지를 확인(즉, 인증된 키와 호출대상 API가 상호 매핑되는지 확인)하는 기능이다. 예를 들면, 인증/권한부(220)는 사용자가 API를 호출할 경우 사용자가 계정을 가지고 있는지 인증하고, 해당 계정이 호출 API와 매핑 되는지 판단하여 API 호출을 허가할 수 있다. 인증/권한부(220)의 동작에 대해서는 이하 도 7에서 자세히 설명한다.
쓰로틀링부(230)는 시간적 서비스 제약조건을 기초로 사용자의 API 서비스의 요청을 쓰로틀링하여 상기 API 서비스를 일시적으로 제한할 수 있다. 여기에서 시간적 서비스 제약조건이란 애셋 또는 서비스의 과부하를 방지하기 위한 조건을 의미한다. 즉, 쓰로틀링부(230)는 일시에 사용자의 API 서비스의 요청이 과도하게 발생하는 경우 시간적 서비스 제약조건을 통해 API 서비스 요청을 일시적으로 제한할 수 있다.
또한, 쓰로틀링부(230)는 API 애셋 제공자와 상기 사용자 간에 미리 설정된 서비스 레벨 규약 조건을 기초로 상기 API 서비스의 요청을 재쓰로틀링하여 API 서비스의 제공여부를 재결정할 수 있다. 즉, 쓰로틀링부(230)는 사용자의 API 서비스 요청에 따른 트래픽을 통제하여 상기 애셋 또는 서비스의 과부하 방지 및 서비스 품질 보장 기능을 제공할 수 있다. 쓰로틀링부(230)의 동작에 대해서는 이하 도 6에서 자세히 설명한다.
로깅부(240)는 API 호출 시 모든 로그를 수집할 수 있다. 즉, 로깅부(240)는 사용자 API 서비스 요청의 유효성 검증, 인증, 권한부여, 트래픽 제어 또는 상기 API 애셋에 관한 호출 내용 및 호출 에러 내용을 기록할 수 있다. API 호출 패턴을 분석하면 사용자의 사용 패턴을 분석해낼 수 있기 때문에, 빅데이타 영역과 연계하여 API 호출 로그는 아주 중요한 자산으로 다루어지고 있다. 또한, API 호출 로그는 차후 문제가 발생하였을 때, 문제를 추적하기 위한 중요한 자료로도 사용될 수 있다. 로깅부(240)는 수집된 로그를 API 지원 모듈(20)의 분석측정관리부(700)에 제공하여 통계 정보를 제공할 수 있게 한다.
중재부(250)는 사용자의 API 서비스 요청 메시지 포맷과 API 애셋 또는 서비스의 메시지 포맷 간 변환을 수행할 수 있다. 즉, 중재부(250)는 사용자가 요청한 API 서비스 데이터 형식으로 API를 제공할 수 있다. 예를 들어, 사용자가 XML 또는 JSON 포맷의 서비스를 요청한 경우 API게이트웨이 모듈(200)은 REST 구조의 API를 XML 또는 JSON 포맷으로 변환하여 제공할 수 있다. 여기에서 REST(Representational State Transfer)는 네트워크 아키텍처 원리의 모음이다. '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트래킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. REST API는 리소스지향(Resource Oriented Architecture) Web API를 의미한다. 중재부(250)의 동작에 대해서는 이하 도 10에서 자세히 설명한다.
도 4는 도 1에 있는 API게이트웨이 모듈(200)의 전체 동작을 설명하는 흐름도이다.
도 4를 참조하면, API게이트웨이 모듈(200)은 먼저 어플리케이션, 개발자 또는 사용자로부터 API 서비스의 요청을 수신할 수 있다(S410). 유효성 검증부(210)는 수신된 API 서비스 요청에 대해 URL, Header 및 API 애셋의 존재 여부 등에 관한 유효성 검증을 수행할 수 있다(S420). 쓰로틀링부(230)는 유효성이 검증된 복수의 사용자의 API 서비스의 요청(호출, call)에 대해 제1차 쓰로틀링을 수행할 수 있다. 제1차 쓰로틀링은 시간적 서비스 제약조건을 기초로 수행될 수 있다. 쓰로틀링부(230)는 사용자 API서비스 요청이 시간적 서비스 제약조건과 다르게 애셋 또는 서비스의 수용 부하를 초과하는 경우에는 사용자에게 사용대기 메시지를 제공할 수 있다(S430). 인증/권한부(220)는 제1차 쓰로틀링을 통과한 사용자의 API 서비스 요청에 대해 사용자 인증을 처리하고 API 권한 부여를 검증할 수 있다(S440). 쓰로틀링부(230)는 인증 과정을 통과한 사용자의 API 서비스 요청에 대해 제2차 쓰로틀링을 수행할 수 있다. 제2차 쓰로틀링은 API 애셋 제공자와 사용자 간에 미리 설정된 서비스 레벨 규약 조건을 기초로 사용자의 API 서비스의 요청을 재쓰로틀링 하는 것을 의미한다. 쓰로틀링부(230)는 사용자의 API 서비스 요청 수가 개발자 포탈 모듈(100)이 제공하는 서비스 레벨 규약 조건(SLA)을 초과하는 경우 API 서비스 제공을 차단하여 사용자의 API 애셋에 대한 접근을 제한할 수 있다(S450). 중재부(250)는 제2차 쓰로틀링을 통과한 사용자의 API서비스 요청에 대해 API 서비스 요청 메시지 포맷을 API 애셋 메시지 포맷으로 변환하고, API 애셋 메시지 포맷을 응답 메시지 포맷으로 변환하여 반환할 수 있다(S460).
도 5는 도 3에 있는 유효성 검증부(210)가 사용자의 API서비스 요청에 대한 유효성을 검증하는 방법을 설명하는 도면이다.
도 5를 참조하면, 유효성 검증부(210)는 API게이트웨 모듈(200)의 로컬 캐시(260)에 저장된 오픈 API, 헤더, 경로, 파라미터 정보를 참조하여 유효성 검증을 수행할 수 있다. 유효성 검증부(210)는 사용자의 API서비스 요청을 수신하면 API 자체의 존재 여부 등을 검증하는 API Validation(211), 사용자가 요청한 데이터 포맷과 애셋 또는 서비스에서 제공 가능한 데이터 포맷을 검사하는 Media Type Negotiation(212), 헤더 구문이 적합한지 검사하는 Header Validation(213), 접근 경로가 적합한지 검사하는 Path Parameter Validation(214), 사용자 요청 데이터에 포함된 파라미터의 적합 여부를 검사하는 Query Parameter Validation(Parameter Validation, 215)의 다섯 단계를 통해 API서비스 요청에 대한 유효성 검사를 수행할 수 있다. 유효성 검증부(210)는 유효성 검사를 수행하는 동안 로깅부(240)에 각 단계에서의 검사 결과를 저장할 수 있다. 유효성 검사를 통해 애셋 또는 서비스에 대한 불필요한 접근을 차단할 수 있으므로, 유효성 검증부(210)는 접근 제어 기능을 제공할 수 있다.
도 6은 도 3에 있는 쓰로틀링부(230)가 API호출을 제어하여 과부하를 방지하고 트래픽을 통제하는 방법을 설명하는 도면이다.
도 6을 참조하면, 쓰로틀링부(230)는 API 통합관리모듈(20)의 실시간 카운트 관리부(600)를 통해 사용자의 API 서비스의 요청에 관한 쓰로틀링을 실시간으로 수행할 수 있다. API 통합관리모듈(20)의 실시간 카운트 관리부(600)가 사용자의 API 서비스의 요청을 실시간으로 카운트 캐싱하고 그에 관한 데이터를 원본 캐시(530,730)에 갱신하면 API 게이트웨이 모듈(200)은 로컬 캐시(260)를 원본 캐시(530,730)와 동기화하고, 쓰로틀링부(230)는 사용자의 API 서비스의 요청을 쓰로틀링 할 수 있다. 쓰로틀링부(230)는 API 호출 수에 따라 애셋 또는 서비스의 과부하를 방지할 수 있고, 애셋 또는 서비스에 대한 사용자의 접근을 제한할 수 있다. 사용자의 API 서비스 요청에 따른 트래픽 제어 속도는 원본 캐시(530,730)와 API 게이트웨이 모듈(200)의 로컬 캐시(260) 간의 동기화를 통해 향상될 수 있다.
도 7은 도 3에 있는 인증/권한부(220)가 사용자 인증을 처리하고 API 권한을 부여하는 방법을 설명하는 도면이다.
도 7을 참조하면, 인증/권한부(220)는 API게이트웨이 모듈(200)의 로컬 캐시(260)에 저장된 인증키, IP 또는 리퍼러, 오픈 API, 권한 정보를 참조하여 사용자 인증(221) 및 권한 검증(222)을 수행할 수 있다.
사용자 인증(221)은 인증키와 IP주소 또는 리퍼러(referer)를 이용하여 수행될 수 있다. 리퍼러(referer)는 웹 브라우저로 월드 와이드 웹을 서핑할 때, 하이퍼링크를 통해서 각각의 사이트로 방문시 남는 흔적을 말한다. 따라서 웹 사이트의 서버 관리자가 사이트 방문객이 어떤 경로로 자신의 사이트에 방문했는지 알아볼 때 유용하게 사용된다. 즉, 인증/권한부(220)는 사용자의 API 호출 기록을 바탕으로 사용자 인증을 처리할 수 있다.
권한 검증(222)은 오픈 API와 그에 대한 권한 정보를 바탕으로 수행될 수 있다. 인증/권한부(220)는 사용자 인증(221)과 권한 검증(222) 결과를 API게이트웨이 모듈(200)의 로컬 캐시(260)에 저장할 수 있다.
도 8은 도 3에 있는 애셋 또는 서비스 접근에 대한 보안 강화를 위해 사용되는 추가적인 방법을 설명하는 도면이다.
도 8을 참조하면, API 관리 장치(10)는 API게이트웨이 모듈(200)을 통한 자체 인증(221) 및 권한 검증(222) 외에 제3 서버 또는 인터넷 서버(30)를 통해 화이트리스트(Whitelist) 방식의 보안 기능도 제공할 수 있다. 화이트리스트란 '안전'이 증명된 것만을 허용하는 것으로 '악의성'이 입증된 것을 차단하는 블랙리스트 보안과 상반되는 보안 방식이다. 예를 들어, API 애셋 접근에 대해 이미 인증 및 권한을 부여 받은 사용자만이 API 게이트웨이 모듈(200)을 통과할 수 있다. 또한, API 관리 장치(10)는 리퍼러 검사를 통하여 API게이트웨이 모듈(200)에 대한 잘못된 접근을 막을 수 있다.
도 9는 도 1에 있는 OAuth인증부(400)가 표준화된 인증 방식을 제공하는 것을 설명하는 도면이다.
도 9를 참조하면, OAuth인증부(400)는 접근 토큰(Access token)을 이용하여 표준화된 인증 방식을 제공할 수 있다. 도 9에서 사용자(user)(40)는 서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인을 의미하고, 제3 서비스(50)는 OAuth를 통해 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션을 의미한다. 서비스(Service)(60)는 OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스) 서비스 제공자(service provider)를 의미한다. OAuth인증은 제3 서비스와 서비스제공자 사이에서 일어나는데 이 인증 과정은 다음과 같다.
제3 서비스(50)가 서비스제공자(60)에게 접근 토큰을 요청하면 서비스제공자(60)가 제3 서비스(50)에게 접근 토큰을 발급해준다. 제3 서비스(50)가 사용자(40)를 서비스제공자(60)로 이동시킨다. 여기서 사용자 인증이 수행된다. 서비스제공자(60)가 사용자(40)를 제3 서비스(50)로 이동시킨다. 제3 서비스(50)가 접근 토큰을 요청한다. 서비스제공자(60)가 접근 토큰을 발급한다. 발급된 접근 토큰을 이용하여 제3 서비스(50)에서 사용자(40) 정보에 접근한다.
도 10은 도 3에 있는 중재부(250)가 API 서비스 요청 메시지 포맷과 API 애셋 메시지 포맷을 변환하여 제공하는 것을 설명하는 도면이다.
도 10을 참조하면, 중재부(250)는 사용자의 API 서비스 요청 메시지와 API 애셋 메시지 간 포맷의 변환이 필요한지 여부를 판단하는 어댑터 컨트롤러(251), 메시지 간 포맷 변환이 필요한 경우 변환규칙에 기반하여 메시지 포맷을 변환하는 메시지변환부(252) 및 사용자에 의해 요청된 API 서비스의 통신 프로토콜과 API 애셋의 통신 프로토콜을 호환시킬 수 있는 프로토콜 핸들러(253)를 포함할 수 있다. 여기에서 변환규칙은 맵핑 룰(Mapping Rule)을 포함할 수 있다. 맵핑 룰은 메시지간 변환 구조를 정한 규칙을 의미할 수 있다. 예를 들어, 중재부(250)는 JSON으로 된 요청(Request) 메시지를 애셋 또는 서비스로 보낼 때 변환해서 보내거나 또는 애셋 또는 서비스에서 생성된 응답 메시지를 클라이언트에 반환 할 때 메시지 포맷을 변환해서 보낼 수 있다.
어댑터 컨트롤러(251)는 사용자의 API 서비스 요청 메시지에 변환이 필요한지 판단하여 변환이 필요한 경우에는 메시지 변환부(252)에 API 서비스 요청 메시지를 전송하고, 변환이 필요하지 않은 경우에는 프로토콜 핸들러(253)로 API 서비스 요청 메시지를 바로 전송할 수 있다.
메시지 변환부(252)는 API 게이트웨이 모듈(200)의 로컬 캐시(260)에 저장된 맵핑 룰을 이용하여 메시지 포맷을 변환할 수 있다. 예를 들어, 사용자가 XML 포맷의 API를 요청한 경우, 메시지 변환부(252)는 XML 포맷이 아닌 API를 XML 포맷의 API로 변환할 수 있다. 마찬가지로, 사용자가 JSON 포맷의 API를 요청한 경우, 메시지 변환부(252)는 JSON 포맷이 아닌 API를 JSON 포맷의 API로 변환할 수 있다. 일 실시예에서, 메시지 변환부(252)는 XML기반의 API를 JSON 또는 바이너리 기반의 API로 데이터 변환하여 API를 경량화 할 수 있다.
프로토콜 핸들러(253)은 SOAP, REST, HTTP 및 TCP/IP 핸들러 등을 포함하여 SOAP, REST, HTTP 및 TCP/IP 등에 해당하는 프로토콜을 다룰 수 있다. 프로토콜 핸들러(253)는 API 게이트웨이 계층에서 프로토콜 변환을 수행하여 다양한 타입의 프로토콜을 지원할 수 있고, 따라서 동일 API가 다른 프로토콜로 서비스될 수 있다.
도 11은 도 2에 있는 캐시 관리부(500)가 분산환경을 기반으로 API를 분산처리 하는 것을 설명하는 도면이다.
도 11a에서 캐시 관리부(500)는 API 통합관리모듈(20)과 관리자 포탈 모듈(300)을 연결하는 내부 인터페이스 모듈(510), 적어도 하나의 API 게이트웨이 모듈(200) 각각의 로컬 캐시(260)와 API 통합관리모듈(20)의 원본 캐시를 동기화시켜 로컬 캐시(260)를 갱신시키는 캐시 관리 모듈(520), 원본 캐시 또는 캐시 저장 모듈(530)을 포함할 수 있다.
복수의 API게이트웨이 모듈(200)들은 각각 로컬 캐시(260)를 갖는데, 캐시 관리부(500)는 각각의 API 게이트웨이 모듈(200)의 로컬 캐시(260)를 통해 사용자의 API 서비스의 요청을 분산 처리하게 할 수 있다. 따라서 캐시 관리부(500)는 API 처리에 따른 지연시간(Latency Time)을 최소화할 수 있다.
도 11b는 관리자 포탈 모듈(300)이 캐시 데이터의 정상동작을 확인하기 위해 캐시 모니터링을 제공하는 것을 설명하는 도면이다. 관리자 포탈 모듈(300)은 API 통합관리모듈(20)의 캐시 관리부(500)에 있는 내부 인터페이스 모듈(510)을 통하여 개발자 포탈 모듈(100)에서 캐시 데이터를 조회하는 기능을 제공할 수 있다. 캐시 데이터에는 API 정보, 경로 검증 규칙, 파라미터 검증 규칙, 인증 정책, 접근 제한 정책, 서비스 정보, 서버 정보, 어댑터 정보 또는 어플리케이션 정보가 포함된 환경설정 캐시(Configuration Cache) 및 수용력(Capacity) 제한 정보, SLA 제한 정보, 부정사용자 식별 정책이 포함된 허가 캐시(Permission Cache)가 포함될 수 있다.
도 12은 도 2에 있는 분석측정 관리부(700)가 API 게이트웨이 모듈(200)에서 수집된 로그 정보를 통해 통계정보를 제공하는 것을 설명하는 도면이다.
도 12를 참조하면, 분석측정관리부(700)는 API게이트웨이 모듈(200)의 로깅부(240)에 저장된 로그 정보를 통해 다양한 통계 정보를 생성할 수 있다. 분석측정 관리부(700)는 API 서비스의 요청 및 API 서비스에 관한 정보를 적어도 하나의 API 게이트웨이 모듈 각각으로부터 수집하여 분산 병렬 처리하고 분석하여 통계 정보를 제공할 수 있다. 통계 정보에는 API 이용 현황, 서버 이용 현황, 응답시간, 에러 발생, 캐시 이용 현황, 서비스 별 API 이용 현황, API 별 이용 현황, 어플리케이션 별 이용 현황, 개발자 별 이용 현황 등이 포함될 수 있다. 이러한 통계 정보는 서비스의 정상적인 상태 체크뿐만 아니라 향후 API 서비스 개발에 유용하게 사용될 수 있다.
도 13은 도 2에 있는 응답데이터 관리부가 응답데이터를 API 게이트웨이 모듈로 리턴 하는 과정을 설명하는 도면이다.
API 게이트웨이 모듈(200) 는 사용자의 API 호출 요청이 있으면, JSON 또는 XML 기반의 REST API(설명의 편의를 위한 것으로, 이에 한정되는 것은 아니다)를 사용자에게 제공할 수 있다. 응답데이터 관리부(800)는 이러한 API 제공 과정에서 API 게이트웨이 모듈(200)로부터 응답캐시가 필요한 애셋 또는 서비스에 대한 API 호출 요청을 수신할 수 있다. 이때, 응답데이터 관리부(800)의 응답데이터 관리모듈(810)은 요청 받은 애셋 또는 서비스에 대한 응답데이터가 원본 캐시(820)에 있는지 여부를 조회할 수 있다. 응답데이터 관리모듈(810)은 원본 캐시(820)에 응답데이터가 있는 경우 해당 응답데이터를 API 게이트웨이 모듈(200)에 제공할 수 있다. 즉, API 게이트웨이 모듈(200)은 애셋/서비스를 통하지 않고 응답데이터 관리부(800)를 호출함으로써 응답데이터를 바로 리턴받을 수 있다. 따라서, 응답데이터 관리부(800)는 API 게이트웨이 모듈(200)과 애셋 또는 서비스 사이의 지연시간(Latency Time)을 최소화 할 수 있다.
상기에서는 본 출원의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 출원을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.
10: API 관리 장치 20: API 지원 모듈
100: 개발자포탈 모듈 200: API게이트웨이 모듈
210: 유효성 검증부 220: 인증/권한부
230: 쓰로틀링부 240: 로깅부
250: 중재부 300: 관리자 포탈 모듈
400: OAuth인증부 500: 캐시 관리부
510: 내부 인터페이스 모듈
520: 캐시 관리 모듈 530: 원본 캐시
600: 실시간 카운트 관리부
610: 캐시 카운터 모듈 620: 카운트 관리 모듈
630: 원본 캐시 700: 분석측정관리모듈
710: 통계분석 모듈(710) 720: 이상거래 분석모듈(720)
730: 원본 캐시(730) 800: 응답데이터 관리부
810: 응답캐시 관리모듈 820: 원본 캐시

Claims (8)

  1. API 관리 장치가 API를 관리하는 방법에 있어서,
    (a) 사용자로부터 API(Application Programming Interface) 서비스의 요청을 분산되게 수신하는 단계;
    (b) 시간적 서비스 제약조건을 기초로 상기 API 서비스의 요청을 쓰로틀링하여 상기 API 서비스의 제공여부를 결정하는 단계; 및
    (c) 원본 캐시로부터 갱신내용이 수신되면 해당 로컬 캐시에 상기 갱신내용의 유무를 검출하여 상기 해당 로컬 캐시와 상기 원본 캐시 간의 일치성을 유지하고 API 애셋 제공자와 상기 사용자 간에 미리 설정된 서비스 레벨 규약 조건을 기초로 상기 API 서비스의 요청을 재쓰로틀링하여 상기 API 서비스의 제공여부를 재결정하는 단계를 포함하는 컴퓨터 수행 가능한 API 관리 방법.
  2. 제1항에 있어서, 상기 (a) 단계는
    상기 API 서비스의 제공 적합성을 판단하기 위한 API 서비스 환경정보를 저장하는 단계를 포함하는 것을 특징으로 하는 컴퓨터 수행 가능한 API 관리 방법.
  3. 제1항에 있어서, 상기 (c) 단계는
    상기 서비스 레벨 규약 조건을 기초로 상기 API 서비스 요청을 실시간 카운트 캐싱하고, 상기 API 서비스의 요청에 관한 재쓰로틀링을 실시간으로 수행하는 단계를 포함하는 것을 특징으로 하는 컴퓨터 수행 가능한 API 관리 방법.
  4. 제1항에 있어서, 상기 (b) 단계는
    상기 쓰로틀링 후에 상기 사용자에 대한 인증 및 권한 검증을 통해 상기 API 애셋에 대한 접근 가능성을 판단하는 단계를 포함하는 것을 특징으로 하는 컴퓨터 수행 가능한 API 관리 방법.
  5. 제2항에 있어서, 상기 (c) 단계는
    상기 API 서비스의 요청에 따라 상기 API 서비스의 제공 적합성을 계속적으로 갱신하는 단계를 포함하는 것을 특징으로 하는 컴퓨터 수행 가능한 API 관리 방법.
  6. 삭제
  7. 제1항에 있어서,
    (d) 상기 사용자의 API 서비스 요청 메시지 포맷과 상기 API 애셋 제공자에 의해 생성된 API 애셋의 메시지 포맷 간 메시지 변환을 수행하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 수행 가능한 API 관리 방법.
  8. 제7항에 있어서,
    (e) 상기 사용자에게 기 등록된 상기 API 애셋을 제공하거나 API 애셋 제공자로부터 상기 API 애셋을 원격 호출하여 제공하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 실행 가능한 API관리방법.
KR1020150167898A 2015-11-27 2015-11-27 컴퓨터 수행 가능한 api 관리 방법 KR101653685B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150167898A KR101653685B1 (ko) 2015-11-27 2015-11-27 컴퓨터 수행 가능한 api 관리 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150167898A KR101653685B1 (ko) 2015-11-27 2015-11-27 컴퓨터 수행 가능한 api 관리 방법

Publications (1)

Publication Number Publication Date
KR101653685B1 true KR101653685B1 (ko) 2016-09-02

Family

ID=56943194

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150167898A KR101653685B1 (ko) 2015-11-27 2015-11-27 컴퓨터 수행 가능한 api 관리 방법

Country Status (1)

Country Link
KR (1) KR101653685B1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102256736B1 (ko) * 2020-02-13 2021-05-27 비엠텍시스템 주식회사 Api 관리 시스템 및 그에 관한 방법
US20220075674A1 (en) * 2020-09-09 2022-03-10 Ciena Corporation Configuring an API to provide customized access constraints
KR102417742B1 (ko) * 2021-09-08 2022-07-06 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법
WO2022220352A1 (ko) * 2021-04-16 2022-10-20 노아에스앤씨 주식회사 멀티미디어 재난정보를 제공하는 open api 서비스 시스템

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040075307A (ko) * 2004-08-05 2004-08-27 한국정보통신대학교 산학협력단 정책 쿼럼 기반의 그리드 자원 관리 시스템 및 그 방법
KR20060068553A (ko) * 2004-12-16 2006-06-21 한국전자통신연구원 개방형 서비스 게이트웨이에서의 지능형 레지스트리 및 그제어방법
US20120254901A1 (en) * 2011-03-29 2012-10-04 Denso Corporation Method and system for restoring an application in a dynamically linked environment
KR101528853B1 (ko) 2007-12-14 2015-07-01 삼성전자주식회사 Ａｐｉ 서비스 방법과 ａｐｉ 매쉬업 생성 방법, 장치 및기록매체

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040075307A (ko) * 2004-08-05 2004-08-27 한국정보통신대학교 산학협력단 정책 쿼럼 기반의 그리드 자원 관리 시스템 및 그 방법
KR20060068553A (ko) * 2004-12-16 2006-06-21 한국전자통신연구원 개방형 서비스 게이트웨이에서의 지능형 레지스트리 및 그제어방법
KR101528853B1 (ko) 2007-12-14 2015-07-01 삼성전자주식회사 Ａｐｉ 서비스 방법과 ａｐｉ 매쉬업 생성 방법, 장치 및기록매체
US20120254901A1 (en) * 2011-03-29 2012-10-04 Denso Corporation Method and system for restoring an application in a dynamically linked environment
JP2012208923A (ja) * 2011-03-29 2012-10-25 Denso Corp アプリケーション実行方法及び実行装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102256736B1 (ko) * 2020-02-13 2021-05-27 비엠텍시스템 주식회사 Api 관리 시스템 및 그에 관한 방법
US20220075674A1 (en) * 2020-09-09 2022-03-10 Ciena Corporation Configuring an API to provide customized access constraints
US11579950B2 (en) * 2020-09-09 2023-02-14 Ciena Corporation Configuring an API to provide customized access constraints
WO2022220352A1 (ko) * 2021-04-16 2022-10-20 노아에스앤씨 주식회사 멀티미디어 재난정보를 제공하는 open api 서비스 시스템
KR20220143462A (ko) * 2021-04-16 2022-10-25 노아에스앤씨 주식회사 멀티미디어 재난정보를 제공하는 Open API 서비스 시스템
KR102614759B1 (ko) * 2021-04-16 2023-12-19 주식회사 아이티에스노아 멀티미디어 재난정보를 제공하는 Open API 서비스 시스템
KR102417742B1 (ko) * 2021-09-08 2022-07-06 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법
WO2023038381A1 (ko) * 2021-09-08 2023-03-16 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법

Similar Documents

Publication Publication Date Title
KR20170062244A (ko) Api 관리 장치
CN111488595B (zh) 用于实现权限控制的方法及相关设备
US11456965B2 (en) Network service request throttling system
US9369307B2 (en) Optimized service integration
CN112913208B (zh) 具有内部部署的认证集成和桥接器高可用性的多租户身份云服务
US8898731B2 (en) Association of service policies based on the application of message content filters
EP3361700A1 (en) Multi-tenant identity and data security management cloud service
KR101588932B1 (ko) 메타데이터 조정기를 통한 보안
KR101653685B1 (ko) 컴퓨터 수행 가능한 api 관리 방법
CN110839087B (zh) 接口调用方法及装置、电子设备和计算机可读存储介质
CN103716326A (zh) 一种资源访问方法及用户资源网关
JP2014505960A (ja) アプリケーション証明のためのシステムおよび方法
WO2005114488A2 (en) System and method for actively managing service-oriented architecture
US20170187705A1 (en) Method of controlling access to business cloud service
La Marra et al. Improving MQTT by inclusion of usage control
US20080301053A1 (en) Service broker
Salhofer Evaluating the FIWARE platform
Liu et al. DACAS: integration of attribute-based access control for northbound interface security in SDN
Grunwald The Internet ecosystem: The potential for discrimination
WO2014011376A1 (en) Optimized service integration
US11720507B2 (en) Event-level granular control in an event bus using event-level policies
US8839400B2 (en) Managing and controlling administrator access to managed computer systems
CN116582362B (zh) 网络访问的控制方法、装置、电子设备及存储介质
CN115801472B (zh) 一种基于鉴权网关的权限管理方法及系统
US20230092902A1 (en) Progressively validating access tokens

Legal Events

Date Code Title Description
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20190826

Year of fee payment: 4