KR102619580B1 - Api 게이트웨이 및 이의 동작 방법 - Google Patents

Abstract

스프링 클라우드 게이트웨이에 기반하여 요청 별로 트래픽을 제어할 수 있는 API 게이트웨이의 동작 방법이 개시된다.

Description

API 게이트웨이 및 이의 동작 방법{API GATEWAY AND OPERATION METHOD THEREOF}

본 개시는 많은 트래픽을 처리할 수 있는 API 게이트웨이의 동작 방법에 관한 것이다.

복수의 고객들은 각각의 단말에 설치된 어플리케이션을 구동하여 서버로부터 요청에 대응하는 응답을 제공받을 수 있다. 어플리케이션을 이용하는 트래픽의 예측된 양에 기반하여 어플리케이션의 구동과 관련하여 API 게이트웨이가 설계될 수 있다. 다만, 만약 예측된 트래픽 보다 많은 트래픽이 발생할 경우 API 게이트웨이는 안정성, 보안성 및 효율성 측면에서 많은 구조적인 한계에 노출될 수 있다. 따라서, 많은 트래픽이 발생하더라도 구조적인 문제가 발생되지 않는 API 게이트웨이 동작 방법과 관련된 기술이 필요하다.

개시된 실시 예들은 API 게이트웨이 및 이의 동작 방법를 개시하고자 한다. 본 실시 예가 이루고자 하는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 이하의 실시 예들로부터 또 다른 기술적 과제들이 유추될 수 있다.

제1 실시 예에 따라, API 게이트웨이의 동작 방법은, 메시지를 파싱(parsing)하는 단계; 상기 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인하는 단계; 상기 확인된 동작 상태를 고려하여 상기 파싱된 메시지에 포함된 파일로부터 라우트 구성(route configuration)을 확인하는 단계; 상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하는 단계; 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계; 및 상기 리포지토리에서 관리 여부에 기반하여 상기 리포지토리의 업데이트 진행 여부를 결정하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인하는 단계는, 상기 API 게이트웨이의 상기 동작 상태가 상기 구동 중으로 확인된 경우, 상기 파싱된 메시지에 기초하여 타겟 서버와 관련된 정보를 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 타겟 서버와 관련된 정보를 확인하는 단계는, 상기 타겟 서버의 IP 주소 정보를 확인하는 단계; 및 상기 타겟 서버의 상기 IP 주소 정보와 상기 파싱된 메시지로부터 확인된 IP 주소 정보 간의 대응 여부를 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인하는 단계는, 상기 타겟 서버의 상기 IP 주소 정보와 상기 파싱된 메시지로부터 확인된 상기 IP 주소 정보가 대응할 경우, 상기 파싱된 메시지에 포함된 상기 파일의 시간 정보를 확인하는 단계; 및 상기 파일의 상기 시간 정보에 기반하여, 최신의 파일인지 여부를 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 타겟 서버의 상기 IP 주소 정보와 상기 파싱된 메시지로부터 확인된 IP 주소 정보 간의 대응 여부를 확인하는 단계는, 상기 타겟 서버의 상기 IP 주소 정보와 상기 파싱된 메시지로부터 확인된 상기 IP 주소 정보가 대응하지 않을 경우 상기 파싱된 메시지에 기초한 상기 업데이트를 스킵하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 파일의 상기 시간 정보에 기반하여, 최신의 파일인지 여부를 확인하는 단계는, 상기 최신의 파일이 아닌 경우 상기 파싱된 메시지에 기초한 상기 업데이트를 스킵하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 확인된 동작 상태를 고려하여 상기 파싱된 메시지에 포함된 파일로부터 라우트 구성(route configuration)을 확인하는 단계는, 상기 API 게이트웨이의 상기 동작 상태가 상기 구동 중으로 확인되고 상기 파일의 상기 시간 정보에 기반하여 상기 최신의 파일로 확인된 경우, 상기 파싱된 메시지에 포함된 상기 파일로부터 상기 라우트 구성을 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 확인된 동작 상태를 고려하여 상기 파싱된 메시지에 포함된 파일로부터 라우트 구성(route configuration)을 확인하는 단계는, 상기 API 게이트웨이의 상기 동작 상태가 상기 구동 시작으로 확인된 경우, 상기 파싱된 메시지에 포함된 상기 파일로부터 상기 라우트 구성을 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계는, 상기 파싱된 적어도 하나의 라우트가 상기 리포지토리(repository)에 존재하는지 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계는, 상기 파싱된 적어도 하나의 라우트가 상기 리포지토리에 존재할 경우, 상기 파싱된 적어도 하나의 라우트의 버전의 변화 여부를 확인하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 리포지토리에서 관리 여부에 기반하여 상기 리포지토리의 업데이트 진행 여부를 결정하는 단계는, 상기 파싱된 적어도 하나의 라우트가 상기 리포지토리에 존재하지 않을 경우 상기 리포지토리에 상기 파싱된 적어도 하나의 라우트를 추가하도록 상기 업데이트를 진행하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 리포지토리에서 관리 여부에 기반하여 상기 리포지토리의 업데이트 진행 여부를 결정하는 단계는, 상기 파싱된 적어도 하나의 라우트의 상기 버전이 변화된 경우 상기 리포지토리에 상기 파싱된 적어도 하나의 라우트를 추가하도록 상기 업데이트를 진행하도록 결정하거나, 상기 버전이 변화되지 않은 경우 상기 업데이트를 스킵하도록 결정하는 단계를 포함할 수 있다.

실시 예에 따르면, 상기 업데이트된 적어도 하나의 라우트에 기초하여 요청(request)에 대응하는 타겟 라우트를 결정하는 단계를 더 포함할 수 있다.

실시 예에 따르면, 상기 타겟 라우트에 기반하여 타겟 서비스를 제공하는 타겟 서버로부터 상기 요청에 대응하는 관련 정보를 확인하는 단계; 상기 관련 정보를 포함하는 응답을 회신하는 단계를 더 포함할 수 있다.

제2 실시 예에 따라, API 게이트웨이는 통신부; 메모리; 및 메시지를 파싱(parsing)하고, 상기 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인하고, 상기 확인된 동작 상태를 고려하여 상기 파싱된 메시지에 포함된 파일로부터 라우트 구성(route configuration)을 확인하고, 상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하고, 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하고, 상기 리포지토리에서 관리 여부에 기반하여 상기 리포지토리의 업데이트 진행 여부를 결정하는 프로세서를 포함할 수 있다.

제3 실시예에 따라, 컴퓨터로 읽을 수 있는 기록매체는 상술한 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 비일시적 기록매체를 포함한다.

기타 실시 예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.

본 개시에 따르면, 각각의 요청 별로 트래픽 제어가 가능하여 시스템 안정성이 향상될 수 있다. 또한, 일부 라우트의 수정이 필요할 경우, 전체 라우트를 업데이트할 필요 없이 일부 라우트만 수정이 가능하여 시스템 안정성이 개선될 수 있다. 또한, 라우트 구성 별로 독립적인 환경 보안성이 개선될 수 있다. 또한, 타겟 서비스인 업스트림 도메인에서 일부 수정이 필요할 경우 전체 코드 수정 및 재배포할 필요 없이 일부만 수정하여 실시간으로 반영이 가능하므로 효율성이 개선될 수 있다. 또한, 라우트 구성에 대한 버전을 관리하여 예외적인 상황에서 이전 버전으로 쉽게 회귀될 수 있다.

발명의 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 청구범위의 기재로부터 당해 기술 분야의 통상의 기술자에게 명확하게 이해될 수 있을 것이다.

도 1은 고객으로부터 요청을 처리하는 기존의 API 게이트웨이를 설명하기 위한 도면이다.
도 2는 일 실시 예에 따른 새로운 구조의 API 게이트웨이를 설명하기 위한 도면이다.
도 3은 일 실시 예에 따른 관리 포털을 설명하기 위한 도면이다.
도 4는 일 실시 예에 따른 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈에서의 동작을 설명하기 위한 도면이다.
도 5는 일 실시 예에 따른 스프링 클라우드 게이트웨이(Spring Cloud Gateway)를 설명하기 위한 도면이고, 도 6은 일 실시 예에 따른 스프링 클라우드 게이트웨이에 임베디드된 프레디케이트를 설명하는 도면이다.
도 7은 일 실시 예에 프리 타입 필터에 포함되는 트래픽 제어 필터를 설명하기 위한 도면이다.
도 8은 일 실시 예에 따라 프리 타입 필터에 포함되는 인증 필터를 설명하기 위한 도면이다.
도 9는 일 실시 예에 따라 프리 타입 필터에 포함되는 레이트 리밋 필터를 설명하기 위한 도면이다.
도 10는 일 실시 예에 따라 프리 타입 필터에 포함되는 블랙리스트 필터를 설명하기 위한 도면이다.
도 11은 일 실시 예에 따라 프리 타입 필터에 포함되는 회로 차단 필터를 설명하기 위한 도면이다.
도 12는 일 실시 예에 따른 API 게이트웨이가 수행하는 동작 방법의 흐름도를 나타낸다.
도 13은 일 실시 예에 따른 API 게이트웨이의 블록도를 나타내는 도면이다.

실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.

명세서 전체에서 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 "~부", "~모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.

명세서 전체에서 기재된 "a, b, 및 c 중 적어도 하나"의 표현은, 'a 단독', 'b 단독', 'c 단독', 'a 및 b', 'a 및 c', 'b 및 c', 또는 'a,b,c 모두'를 포괄할 수 있다.

이하에서 언급되는 "단말"은 네트워크를 통해 서버나 타 단말에 접속할 수 있는 컴퓨터나 휴대용 단말로 구현될 수 있다. 여기서, 컴퓨터는 예를 들어, 웹 브라우저(WEB Browser)가 탑재된 노트북, 데스크톱(desktop), 랩톱(laptop) 등을 포함하고, 휴대용 단말은 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, IMT(International Mobile Telecommunication), CDMA(Code Division Multiple Access), W-CDMA(W-Code Division Multiple Access), LTE(Long Term Evolution) 등의 통신 기반 단말, 스마트폰, 태블릿 PC 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치를 포함할 수 있다.

아래에서는 첨부한 도면을 참고하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.

이하에서는 도면을 참조하여 본 개시의 실시 예들을 상세히 설명한다.

도 1은 고객으로부터 요청을 처리하는 기존의 API 게이트웨이를 설명하기 위한 도면이다.

도 1을 참조하면, 복수의 고객들(110)은 각각의 단말에 설치된 어플리케이션을 구동시켜 서버(170)로부터 요청에 대응하는 응답을 제공받을 수 있다. 예를 들면, 복수의 고객들(110)은 각각의 단말에 설치된 어플리케이션을 통해 음식 배송 서비스(예를 들면, 스토어 정보, 주문 정보, 결제 정보, 아이템 정보, 리뷰 정보 등)와 관련된 요청을 할 수 있고 서버(170)는 요청에 대응하는 응답을 제공할 수 있다. 이때, 고객들(110)의 요청에 대응하는 트래픽들은 퍼블릭 어플리케이션 로드 밸런서(public Application Load Balancer(ALB))(130)에 기반하여 자동으로 분산될 수 있다.

API 게이트웨이(150)는 어플리케이션 레이어(Application layer)(151)에 기반하여 도메인(152)을 확인할 수 있다. 예를 들면, API 게이트웨이(150)는 퍼블릭 어플리케이션 로드 밸런서(130)를 통한 트래픽을 어플리케이션 레이어(151)에서 분석하여 /endpoint/, /meta/, /abtest/와 같은 도메인(152)을 확인할 수 있다.

API 게이트웨이(150)는 컨트롤러 모듈(153)을 포함하며, 컨트롤러 모듈(153)은 엔드포인트 핸들러(Endpoint Handler)와 컨트롤러(Controller)을 포함할 수 있다. 이때, 엔드포인트 핸들러(Endpoint Handler)는 도메인(152)을 이용하여 요청에 대응하는 서버를 확인하고, 서버에서 확인된 관련 정보가 고객(110)에게 회신되는 응답에 포함될 수 있다. 이때, 엔드포인트 핸들러(Endpoint Handler)는 AB Test 관련 파일을 설정할 수 있거나, CMDB KV Config 관련 동작에서 확인된 키값을 설정할 수 있다. 참고로, 엔드포인트 핸들러(Endpoint Handler)는 CMDB KV Config에 설정된 값을 일정 시간(예컨대, 60초) 마다 확인할 수 있다. 또한, 엔드포인트 핸들러(Endpoint Handler)가 수신한 정보는 HTTP UI에 기반하여 레스트 웹 클라이언트(Rest Web Client)(154)를 통해 서버(170)로 요청을 전송할 수 있다. 이때, 서버(170)은 요청에 대응하여 확인된 서버일 수 있다. 즉, 고객이 어플리케이션을 통해 관련 정보를 요청할 경우, 모든 요청은 엔드포인트 핸들러(Endpoint Handler)를 통해 대응하는 서버(170)로 전송될 수 있고, 서버(170)에서 확인된 정보에 기반하여 고객에게 응답 정보가 회신될 수 있다.

예컨대 음식 배송 서비스를 제공하기 위한 서버(170)는 복수로 구분되어 관련 정보를 관리할 수 있다. 예를 들면, 스토어에 대한 정보를 관리하는 서버, 아이템에 대한 정보를 관리하는 서버, 고객에 대한 정보를 관리하는 서버, 결제에 대한 정보를 관리하는 서버, 주문에 대한 정보를 관리하는 서버, 리뷰에 대한 정보를 관리하는 서버와 같이 복수로 구분되어 관련 정보가 관리될 수 있다. 이에, API 게이트웨이(150)으로부터 요청에 대응하는 서버(170)에서 관련 정보가 확인될 수 있고, 확인된 관련 정보를 포함하는 응답이 고객에게 전송될 수 있다.

다만, 이와 같은 구조의 API 게이트웨이(150)는 안정성, 보안성 및 효율성 측면에서 다음과 같은 어려움이 있다. 예를 들면, 각각의 요청에 대응하여 레이트 리밋, 회로 차단 또는 안티 크롤러와 같이 트래픽을 제어하여 시스템을 보호하지 못하는 어려움이 있었다. 또한, 라우트 구성과 관련하여 일부 라우트의 변경이 필요할 경우 전체 라우트 구성이 매번 업데이트되어 라우트 구성을 관리함에 있어 어려움이 있었다. 또한, 각각의 라우트 별로 개인화된 기능을 적용하지 못하여 일부 변화가 모든 요청에 적용될 수 밖에 없는 어려움이 있었다. 타겟 서버에 대응하는 업스트림 서버(170)에 서버의 추가와 같이 변경될 경우, API 게이트웨이(150)는 코드를 변경하고 이를 재배포해야하므로 업스트림 서버(170)를 수정하거나 관리함에 있어 효율적이지 못한 어려움이 있었다. 또한, 엔드포인트 핸들러(Endpoint Handler)는 CMDB KV Config에 설정된 값을 일정 시간(예컨대, 60초) 마다 확인할 수 있으며, 라우트 구성과 관련하여 수정이 필요한 경우, 60초 간의 딜레이가 발생하고 실시간으로 반영되지 못하는 어려움이 있었다. 또한, 환경이 분리되지 않아 스테이지에서 동일한 설정 값을 공유하여 라우트 구성에서 일부를 수정할 경우 수정된 내용을 확인하는 것이 어려운 문제가 있었다.

따라서, 도 1과 같은 구조의 API 게이트웨이를 이용할 경우 전술한 바와 같은 어려움이 있어, 이하 도 2와 같은 구조의 트래픽 별로 제어가 가능한 API 게이트웨이에 대해 자세히 검토한다.

도 2는 일 실시 예에 따른 새로운 구조의 API 게이트웨이를 설명하기 위한 도면이다.

도 2를 참조하면, 관리 포털(Admin Portal)(210)은 구성 대쉬보드(Configuration Dashboard) 모듈(211), 라우트 공개(Route Publish) 모듈(212) 및 컨트롤러(213)을 포함할 수 있다. 구성 대쉬보드(Configuration Dashboard) 모듈(211)은 프리티케이트(Predicate), 필터(Filter) 및 라우트 구성(Route Configuration)을 각각 별도로 관리할 수 있다. 즉, 구성 대쉬보드 모듈(211)은 프레디케이트 플러그인 관리(Predicate Plugins Management) 모듈, 필터 플러그인 관리(Filter Plugins Management) 모듈 및 라우트 구성 관리(Route Configuration Management) 모듈에 기반하여 각각 프레디케이트, 필터 및 라우트 구성을 관리할 수 있다. 도 2는 본 실시 예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 2에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시 예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다. 또한, 프레디케이트, 필터 및 라우트와 관련하여 관련된 기술분야에서 알려진 내용이 적용될 수 있다.

관리 포털(210)은 스토리지(220)로 관련 정보를 저장할 수 있으며, 이때 스토리지(220)은 Mysql Cluster과 S3 Bucket로 구성될 수 있다. Mysql Cluster과 S3 Bucket는 각각 저장 기능을 담당하며, Mysql Cluster에 저장된 정보와 S3 Bucket에 저장된 정보는 설정에 따라 상호간의 연동이 가능할 수 있다.

관리 포털(210)은 라우트가 변경되거나 실행 중일 경우, API 게이트웨이(230)로 변경된 라우트 또는 실행 중인 라우트에 대한 정보(예컨대, 버전)를 전송할 수 있다. 이때, 컨트롤러(213)는 API 게이트웨이(230)로 정보를 전송하기 위해 Mysql Cluster를 통해 라우트에 대한 정보를 확인하고, 라우트 구성 관리(Route Configuration Management) 모듈은 S3를 통해 관련된 정보를 확인할 수 있다. 대용량의 정보들은 Mysql Cluster에서 S3로 이동되어 관리될 수 있다. 또한, 라우터 정보, 프레디케이트 정보 및 필터 정보는 S3 Bucket에 저장되며, Mysql Cluster은 싱글 라우터 정보만 저장한다. S3 Bucket는 Mysql에 저장된 정보에 기반하여 추가로 생성된 정보를 저장하거나 크기가 일정값 이상인 정보를 저장할 수 있다. 라우트 구성 로더 컴포넌트는 Mysql에 저장된 정보에 기반하여 S3 Bucket에서 관리되는 정보를 수신할 수 있다.

구성 대쉬보드 모듈(211)은 라우트가 업데이트될 경우 관련 정보를 라우트 공개 모듈(212)로 전송할 수 있고, 라우트 공개 모듈(212)은 업데이트된 라우트의 버전을 관리할 수 있다. 즉, 라우트 공개 모듈(212)는 라우트 버전 관리 모듈(Route Version Management)에 기반하여 업데이트된 라우트의 버전을 관리할 수 있고, 이에 라우트 버전에 대한 히스토리 정보가 확인될 수 있다.

라우트 버전 관리 모듈은 프로세서인 CONSUL로 실시간으로 라우트 버전에 대한 정보를 제공할 수 있고, 프로세서인 CONSUL은 실시간으로 라우트의 변경이 확인된 경우 관련 정보를 API 게이트웨이(230)로 제공할 수 있다. 따라서, API 게이트웨이(230)은 라우트 구성의 변경을 확인할 수 있고, 변경에 따른 업데이트를 수행할 수 있다.

복수의 고객들(240)은 각기 다른 단말에 설치된 어플리케이션에 접속할 수 있고, 이때 고객들(240)에 대응하는 트래픽들은 인터넷 페이싱 로드 밸런서(Internet-facing Application Load Balancer(ALB))(250)에 기반하여 자동으로 분산되어 관리될 수 있다. 보다 구체적으로, Nginx 또는 Envoy는 로드 밸런서로서, 이중에서 택일된 로드 밸런서에 기반하여 고객의 요청에 따른 트래픽이 API 게이트웨이(230) 내의 특정 파드(pod)로 전송될 수 있다.

API 게이트웨이(230)은 복수의 파드(pod)를 포함할 수 있으며, 각각의 파드 별로 수신한 고객의 요청을 처리할 수 있다. 이때, 각각의 파드는 각각의 단일 서버(single server)에 대응할 수 있다.

API 게이트웨이(230)은 CONSUL로부터 실시간으로 라우트 변경 정보를 수신하고, API 게이트웨이(230)에 포함된 파드는 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈과 라우트 구성 리프레셔(Route Config Refresher) 모듈에 기반하여 새로운 라우트 또는 새로운 버전의 라우트를 리포지토리(repository)에 추가하거나 스킵할 수 있다. 이와 관련하여 자세한 내용은 이하 도 4를 참조한다.

모니터(260) 모듈은 API 게이트웨이(230)과 관련된 상태를 모니터링할 수 있다. 구체적으로, 모니터(260) 모듈의 prometheus와 관련하여, API 게이트웨이(230)의 특정 파드에서 처리량이 기준 값 이상으로 많아질 경우 실시간으로 관리자에게 알람 메시지가 전송될 수 있으며, 관리자는 알람 메시지에 기반하여 특정 파드의 이상 상태를 확인할 수 있다. 또한, 모니터(260) 모듈의 coutrace와 관련하여, API에 기반한 고객의 요청에 이상이 발생한 경우, 어떤 API에 문제가 발생하였는지 확인될 수 있다. 또한, 모니터(260) 모듈의 Coumon과 관련하여, 파드의 할당 여부가 확인될 수 있고, 파드에 대한 기대값을 초과할 경우 이에 대한 알람 메시지가 전송될 수 있다.

도 3은 일 실시 예에 따른 관리 포털을 설명하기 위한 도면이다.

도 3을 참조하면, 관리자는 관리 포털에 라우트 구성과 관련된 새로운 프레디케이트 또는 필터를 등록할 수 있다. 관리 포털은 라우트 버전을 관리할 수 있고, 관리자가 이전 버전으로 회귀를 원하는 예외적인 경우에도 라우트 버전 관리에 의해 쉽게 이전 버전으로 회귀될 수 있다. 프레디케이트 및 필터와 관련하여 관련 기술 분야에서 알려진 내용이 적용될 수 있다. 관리자는 관리 포털을 이용하여 블랙리스트를 관리하거나 업스트림 도메인에서 서버를 변경할 수 있다. 또한, FilterFactories 테이블에 기반하여 RouteFilters 테이블이 설정되며, PredicateFactories 테이블에 기반하여 RoutePredicates 테이블이 설정되며, ServiceGlobalFilters 테이블과 ServiceGlobalPredicates 테이블에 기반하여 타겟 서버에서의 Service가 설정될 수 있으며, 이를 종합하여 Route 테이블이 설정될 수 있다. 참고로, RoutePredicates 테이블은 특정 라우트에 적용되는 프레디케이트와 관련된 테이블에 해당하며, RouteFilters 테이블은 특정 라우트에 적용되는 필터와 관련된 테이블에 해당할 수 있다. 또한, ServiceGlobalPredicates 테이블은 RoutePredicates 테이블과 달리 모든 라우트에 적용되는 프레디케이트와 관련된 테이블에 해당하며, ServiceGlobalFilters 테이블은 RouteFilters 테이블과 달리 모든 라우트에 적용되는 필터와 관련된 테이블에 해당할 수 있다. 특정 서비스의 경우 많은 라우트를 포함할 수 있으며, 각 라우트는 많은 프레디케이트 또는 필터에 기초하여 설정될 필요가 있다. 만약 동일한 프레디케이트 또는 필터가 각 라우트 별로 설정될 경우 비효율적일 수 있어, 공통적으로 적용되는 프레디케이트 또는 필터가 ServiceGlobalFilters 테이블과 ServiceGlobalPredicates 테이블로 관리될 수 있다. 또한, RouteRequestApi 테이블은 특정 라우트 안에 독립적인 API를 설정할 때 사용될 수 있다. 예를 들면, 특정 라우트가 ~/a인 경우, RouteRequestApi는 ~/a/b 또는 ~/a/c에 대해 제어가 가능하도록 설정할 때 사용될 수 있다. 이와 같은 방법에 의해 관리 포털과 관련된 코드 양이 간소화될 수 있어 관리자의 관리 부담이 줄어들 수 있다.

도 4는 일 실시 예에 따른 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈에서의 동작을 설명하기 위한 도면이다.

도 4를 참조하면, 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 프로세서인 Consul로부터 라우트 변경 정보를 수신할 수 있고, 이에 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 메시지를 수신할 수 있다. 이때, 메시지는 스토리지인 S3 버킷(Bucket)에 저장된 정보에 대응할 수 있다.

단계 S411에서, 메시지를 수신한 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 JSON 형식의 메시지를 파싱할 수 있다. 이때, 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 메시지를 파싱하여 타임스탬프(timestamp), 인스턴스(instance) 및 구성 파일(Config File)을 확인할 수 있다. 여기서, 타임스탬프는 메시지와 관련된 시간 정보에 대응하며, 인스턴스는 메시지와 관련된 IP 주소 정보에 대응할 수 있다. 이때, IP 주소 정보는 일정한 범위를 갖도록 설정된 주소 정보를 포함할 수 있다.

단계 S413에서, 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 어플리케이션의 동작 상태가 구동 시작 또는 구동 중인지 확인할 수 있다. 이때, 어플리케이션의 동작 상태가 구동 시작은 어플리케이션이 처음으로 구동을 시작한 경우로서, 이는 API 게이트웨이의 동작 상태가 구동 시작인 경우에 대응할 수 있다. 즉, API 게이트웨이에 포함된 파드(즉, 서버)에서 처음으로 구동 시작한 경우는 어플리케이션이 처음으로 구동을 시작한 경우에 대응할 수 있다.

만약, 어플리케이션 또는 API 게이트웨이의 동작 상태가 구동 시작이 아닌 구동 중일 경우, 단계 S415에서 타겟 인스턴스가 파싱된 메시지에 포함된 인스턴스에 대응하는지 여부가 확인될 수 있다. 구체적으로, 어플리케이션이 구동 중일 경우 구동 중인 어플리케이션의 IP 주소 정보가 확인될 수 있고, 어플리케이션의 IP 주소 정보가 파싱된 메시지에 포함된 인스턴스에 포함되는지 여부가 확인될 수 있다. 이때 파싱된 메시지에 포함된 인스턴스는 범위(range)로 설정될 수 있으며, 어플리케이션의 IP 주소 정보가 범위에 포함되는지 여부가 확인될 수 있다.

만약, 파싱된 메시지에 포함된 인스턴스에 어플리케이션의 IP 주소 정보가 포함되지 않을 경우, 메시지에 기초한 업데이트가 스킵(단계 S429)될 수 있다. 또는, 파싱된 메시지에 포함된 인스턴스에 어플리케이션의 IP 주소 정보가 포함될 경우, 단계 S417에서 파싱된 메시지로부터 확인된 시간 정보에 기반하여 최신의 파일인지 여부가 확인될 수 있다.

만약, 가장 최신의 파일이 아닌 경우, 메시지에 기초한 업데이트가 스킵(단계 S429)될 수 있다. 또는, 가장 최신의 파일로 확인된 경우, 파싱된 메시지에 포함된 구성 파일(Config File)로부터 라우트 구성(Route Config)이 확인될 수 있다. 단계 S421에서 라우트 구성(Route Config)은 각각의 라우트 별로 파싱될 수 있다.

단계 S423에서 라우트 구성 로더 컴포넌트(Route Config Loader Component) 모듈은 각각의 라우트 별로 리포지토리에 존재 여부를 확인할 수 있다. 만약 존재하지 않을 경우 단계 S427에서 라우트는 리포지토리에 추가되도록 업데이트될 수 있다.

또는, 만약 존재할 경우, 단계 S425에서 라우트 버전의 변화 여부가 확인될 수 있다. 만약, 버전이 변화되지 않은 경우, 메시지에 기초한 업데이트가 스킵(단계 S429)될 수 있다. 또는, 만약 버전이 변화된 경우 단계 S427에서 라우트는 리포지토리에 추가되도록 업데이트될 수 있다.

도 5는 일 실시 예에 따른 스프링 클라우드 게이트웨이(Spring Cloud Gateway)를 설명하기 위한 도면이고, 도 6은 일 실시 예에 따른 스프링 클라우드 게이트웨이에 임베디드된 프레디케이트를 설명하는 도면이다.

도 5를 참조하면, 스프링 클라우드 게이트웨이(Spring Cloud Gateway)는 고객(510)으로부터 요청을 수신할 수 있다. 고객으로부터 수신한 요청과 관련하여, 핸들러 매핑(530)은 모든 프레디케이트(Predicate)와 요청 간의 매칭 여부를 확인하여 요청에 적합한 프레디케이트를 발견할 수 있다. 이때, 핸들러 매핑(530)은 요청에 매칭된 프레디케이트에 의해 타겟 라우트(target Route)를 발견할 수 있다. 이때, 핸들러 매핑(530)이 매칭 여부를 확인하는 프레디케이트와 관련된 일례는 도 6을 통해 확인할 수 있다. 프레디케이트는 도 6과 같이 필드 이름, 연산자 등의 조합으로 구성되며, 핸들러 매핑(530)은 요청에 포함된 프레디케이트와 매칭되는 프레디케이트를 발견할 수 있다. 프레디케이트와 관련된 내용은 관련 기술분야에서 알려진 내용이 적용될 수 있다. 스프링 클라우드 게이트웨이(Spring Cloud Gateway)와 관련하여 자세한 내용은 관련 기술 분야에서 알려진 내용이 참조될 수 있다.

이후, 웹 핸들러(550) 및 필터(570)을 통과하여 타겟 서비스(590)로부터 요청에 대응하는 관련 정보가 확인될 수 있다. 이때, 요청은 타겟 서비스(590)에 도달하기 전에 프리 타입 필터(571)를 통과할 수 있고, 요청이 타겟 서비스(590)에 도달하여 관련 정보를 포함한 응답은 포스트 타입 필터(572)를 통과하여 고객에게 반환될 수 있다.

도 7은 일 실시 예에 프리 타입 필터에 포함되는 트래픽 제어 필터를 설명하기 위한 도면이다.

도 7을 참조하면, 단계 S710에서 고객으로부터 요청이 확인될 수 있다. 단계 S720에서 쿼리에 따라 고객으로부터 요청에 대응하여 핸들러 매핑에서 확인된 타겟 라우트와 기설정된 라우트 간의 매칭 여부가 확인될 수 있다. 예컨대 ABTest SDK에 기반하여 타겟 라우트와 기설정된 라우트 간의 매칭 여부가 확인될 수 있다. 매칭 여부에 기반하여 단계 S730과 단계 S740에서 True 및 False로 판단될 수 있다. 만약, True로 판단될 경우 트래픽 제어가 적절하다고 판단된 경우에 대응하며, False로 판단될 경우 트래픽 제어 실패로 판단된 경우에 대응할 수 있다.

도 8은 일 실시 예에 따라 프리 타입 필터에 포함되는 인증 필터를 설명하기 위한 도면이다.

도 8을 참조하면, 고객의 로그인 상태를 체크하기 위하여 인증 필터가 동작할 수 있다. 어플리케이션을 통해 제공되는 서비스(예컨대, 음식 배송 서비스)를 사용하기 위해서 크리덴셜 정보(credential information)에 따른 액세스 토큰에 기반하여 인증될 필요가 있으며, 액세스 토큰의 유효성은 서로 다른 방법을 적용하여 판정될 수 있다. 구체적으로, 단계 S810에서 고객으로부터 요청이 확인될 수 있다. 단계 S820에서 고객으로부터 요청에 대응하여 인증 필터에 따른 인증 성공 여부가 확인될 수 있다. 이때 액세스 토큰의 유효성에 기반하여 인증 성공 여부가 판단될 수 있으며, 보다 구체적으로 API-forge에 기반한 방식을 통해 액세스 토큰의 유효성이 판단되거나 또는 Redis(Remote Dictionary Server)에 기반한 방식을 통해 액세스 토큰의 유효성이 판단될 수 있다. 단계 S830에서 인증 성공 여부가 확인될 경우 다음 필터가 적용될 수 있고, 단계 S840에서 인증 실패한 경우 인증 실패에 따라 유효하지 않은 인증을 알리는 응답이 회신될 수 있다.

도 9는 일 실시 예에 따라 프리 타입 필터에 포함되는 레이트 리밋 필터를 설명하기 위한 도면이다.

도 9를 참조하면, 고객의 요청에 대응하여 로그인 상태를 고려한 레이트 리밋 필터가 동작할 수 있다. 레이트 리밋 필터는, 과도한 트래픽으로부터 서비스를 보호하고 리소스 사용에 대한 공정성과 합리성을 유도하기 위하여 크롤링이나 불법 유저들을 필터링할 수 있다. 단계 S910에서 고객으로부터 요청이 확인될 수 있다. 단계 S920에서 고객의 로그인 여부가 확인될 수 있고, 단계 S930에서 실제 유저인지 여부가 확인될 수 있다. 구체적으로, 로그인 상태인 경우 memberSrl 값이 레이트 리밋에 대한 식별정보로 이용되어 크롤러(crawler)인지 실제 유저인지 여부가 확인될 수 있고, 로그인 상태가 아닌 경우 pcid 값이 레이트 리밋에 대한 식별정보로 이용되어 크롤러인지 실제 유저인지 여부가 확인될 수 있다. 단계 S940에서 실제 유저로 확인된 경우 다음 필터가 적용될 수 있다. 단계 S950에서 실제 유저가 아닌 크롤링(crawling) 또는 불법 유저로 판정된 경우, pcid 값 또는 memberSrl 값이 Kafka 메시지에 의해 관리 포털에 기록될 수 있고, 고객의 요청에 대응하여 레이트 리밋 초과에 대응하는 응답이 회신될 수 있다.

도 10는 일 실시 예에 따라 프리 타입 필터에 포함되는 블랙리스트 필터를 설명하기 위한 도면이다.

도 10을 참조하면, 고객이 블랙리스트 인지 여부가 확인하는 필터가 동작할 수 있다. 단계 S1010에서 고객으로부터 요청이 확인될 수 있다. 단계 S1020에서 고객의 로그인 여부가 확인될 수 있다. 고객이 로그인 상태인 경우 memberSrl 값이 블랙리스트 판단에 대한 식별정보로 이용되고, 로그인 상태가 아닌 경우 pcid 값이 블랙리스트 판단에 대한 식별정보로 이용될 수 있다. 단계 S1030에서 블랙리스트에 대응하는지 여부가 확인될 수 있다. 관리 포털은 다른 방법에 의해 확인된 블랙리스트 유저에 대한 정보와 레이트 리밋에 의해 확인된 크롤러 또는 불법 유저에 대한 정보를 데이터베이스로 10초 단위로 동기화시킬 수 있다. 따라서, pcid 값 또는 memberSrl 값을 데이터베이스에 동기화된 정보와 비교하여 블랙리스트 여부가 확인될 수 있다. 단계 S1040에서 블랙리스트가 아닌 것으로 확인된 경우 다음 필터가 적용될 수 있고, 단계 S1050에서 블랙리스트로 확인된 경우 고객의 요청을 유효하지 않은 요청으로 판단하여 관련된 정보를 포함하는 응답을 회신할 수 있다.

도 11은 일 실시 예에 따라 프리 타입 필터에 포함되는 회로 차단 필터를 설명하기 위한 도면이다.

도 11을 참조하면, 회로 차단 필터는 어떤 서비스와 관련하여 과부하 또는 장애가 발생하였을 때 그 서비스를 호출하는 다른 서비스들의 연쇄적인 장애를 막기 위해 미리 차단하는 필터로서, 예컨대 실패의 횟수가 기준치를 넘을 경우 회로를 오픈하여 일정 기간 동안 실행되지 않고 실패하게 할 수 있다. 구체적으로, 단계 S1110에서 고객으로부터 요청이 확인될 수 있다. 단계 S1120에서 회로 차단 여부가 확인될 수 있다. 만약 회로가 차단되지 않은 경우 장애가 발생하지 않은 경우로서, 단계 S1130에서 업스트림 서비스(upstream service)로 요청이 전달되어 업스트림 서비스로부터 요청에 대응하는 관련 정보가 확인되어 고객에게 응답으로 제공될 수 있다. 이때, 업스트림 서비스는 전술한 타겟 서비스에 대응할 수 있다. 또는, 회로 차단으로 확인된 경우, 단계 S1140에서 업스트림 서비스를 이용 불가에 대응하는 응답이 회신될 수 있다.

도 12는 일 실시 예에 따른 API 게이트웨이가 수행하는 동작 방법의 흐름도를 나타낸다. 전술한 기재가 여기에도 적용될 수 있다.

도 12를 참조하면, 단계 S1210에서 메시지를 파싱(parsing)할 수 있다.

단계 S1220에서 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인할 수 있다. 이때, API 게이트웨이의 동작 상태가 구동 시작이 아닌 구동 중으로 확인된 경우, 메시지에 기초하여 타겟 서버와 관련된 정보가 확인될 수 있다. API 게이트웨이의 동작 상태가 구동 중인 경우는 어플리케이션이 구동 중인 경우에 대응하며, 어플리케이션의 IP 주소 정보가 확인될 수 있다. 구동 중인 어플리케이션의 IP 주소 정보는 타겟 서버(즉, 파드)의 IP 주소 정보에 대응할 수 있다. 또는, API 게이트웨이의 동작 상태가 구동 시작인 경우는 어플리케이션이 처음으로 구동 시작인 경우에 대응할 수 있다.

이때, 타겟 서버와 관련된 정보는, 타겟 서버의 IP 주소 정보를 확인하고, 이를 파싱된 메시지로부터 확인된 IP 주소 정보 간의 대응 여부에 대한 정보를 포함할 수 있다. 메시지로부터 확인된 IP 주소 정보는 범위(range)로 지정될 수 있으며, 타겟 서버의 IP 주소 정보가 범위에 포함 여부가 확인될 수 있다. 만약, 타겟 서버의 IP 주소 정보와 파싱된 메시지로부터 확인된 IP 주소 정보가 대응하지 않을 경우 수신한 메시지에 기초한 업데이트가 스킵될 수 있다.

만약, 타겟 서버의 IP 주소 정보와 파싱된 메시지로부터 확인된 IP 주소 정보가 대응할 경우, 파싱된 메시지에 포함된 파일의 시간 정보를 확인할 수 있고, 파일의 시간 정보에 기반하여 최신 파일인지 여부가 확인될 수 있다. 만약, 최신 파일이 아닌 경우 수신한 메시지에 기초한 업데이트가 스킵될 수 있다.

단계 S1230에서 확인된 동작 상태를 고려하여 파싱된 메시지에 포함된 파일로부터 라우트 구성을 확인할 수 있다.

API 게이트웨이의 동작 상태가 구동 중으로 확인되고 파일의 시간 정보에 기반하여 최신 파일로 확인된 경우, 파싱된 메시지에 포함된 파일로부터 라우트 구성이 확인될 수 있다. 만약, API 게이트웨이가 구동 시작으로 확인된 경우 파싱된 메시지에 포함된 파일로부터 라우트 구성이 확인될 수 있다.

단계 S1240에서 라우트 구성은 적어도 하나의 라우트 별로 파싱될 수 있다. 메시지에 포함된 파일로부터 확인된 라우트 구성(Route configuration)은 적어도 하나의 라우트 별로 각각 파싱될 수 있다.

단계 S1250에서 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인할 수 있고, 단계 S1260에서 리포지토리에서 관리 여부에 기반하여 리포지토리의 업데이트 진행 여부를 결정할 수 있다.

파싱된 적어도 하나의 라우트 별로 리포지토리(repository)에 존재 여부가 확인될 수 있고, 리포지토리에 존재 여부에 기초하여 업데이트 진행 여부가 결정될 수 있다. 또한, 리포지토리에 존재할 경우 파싱된 적어도 하나의 라우트의 버전의 변화 여부를 확인하고 이에 기초하여 업데이트 진행 여부가 결정될 수 있다. 만약, 리포지토리에 존재하지만 버전이 변화된 경우 리포지토리에 적어도 하나의 라우트를 추가하도록 업데이트가 진행될 수 있고, 버전이 변화되지 않은 경우 업데이트가 스킵될 수 있다. 또는, 리포지토리에 존재하지 않을 경우 리포지토리에 적어도 하나의 라우트를 추가하도록 업데이트가 진행될 수 있다.

이후, 업데이트된 적어도 하나의 라우트에 기초하여 요청에 대응하는 타겟 라우트가 결정된 후, 적어도 하나의 프리 타입 필터를 통과하여 타겟 서비스를 제공하는 타겟 서버로부터 요청에 대응하는 관련 정보가 확인될 수 있다. 요청에 대응하는 관련 정보를 포함하는 응답은 포스트 타입 필터를 통과한 후 고객에게 회신될 수 있다. 이때, 프리 타입 필터 및 포스트 타입 필터와 관련하여 자세한 내용은 전술한 내용을 참조한다. 도 7 내지 도 11에 기재한 프리 타입 필터들은 요청에 대응하여 선택적으로 적용될 수 있으며, 필터의 적용 순서는 요청에 따라 서로 상이하게 설정될 수 있다.

도 13은 일 실시 예에 따른 API 게이트웨이의 블록도를 나타내는 도면이다.

API 게이트웨이(1300)는 일 실시예에 따라, 통신부(1310), 메모리(1320) 및 프로세서(1330)를 포함할 수 있다. 도 13에 도시된 API 게이트웨이(1300)는 본 실시 예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 13에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시 예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.

API 게이트웨이(1300)는 고객으로부터 요청에 대응하여 응답을 제공하는 과정에서 처리되는 동작을 수행할 수 있다. 통신부(1310)는 네트워크를 통하여 관련 정보를 송수신할 수 있다. 네트워크는 근거리 통신망(Local Area Network; LAN), 광역 통신망(Wide Area Network; WAN), 부가가치 통신망(Value Added Network; VAN), 이동 통신망(mobile radio communication network), 위성 통신망 및 이들의 상호 조합을 포함하며, 본 명세서에 기재된 네트워크 구성 주체가 서로 원활하게 통신을 할 수 있도록 하는 포괄적인 의미의 데이터 통신망이며, 유선 인터넷, 무선 인터넷 및 모바일 무선 통신망을 포함할 수 있다. 무선 통신은 예를 들어, 무선 랜(Wi-Fi), 블루투스, 블루투스 저 에너지(Bluetooth low energy), 지그비, WFD(Wi-Fi Direct), UWB(ultra wideband), 적외선 통신(IrDA, infrared Data Association), NFC(Near Field Communication) 등이 있을 수 있으나, 이에 한정되는 것은 아니다.

프로세서(1330)는 API 게이트웨이(1300)의 전반의 동작을 제어하고 데이터 및 신호를 처리할 수 있다. 프로세서(1330)는 적어도 하나의 하드웨어 유닛을 포함할 수 있다. 또한, 프로세서(1330)는 메모리(1320)에 저장된 프로그램 코드를 실행하여 생성되는 하나 이상의 소프트웨어 모듈에 의해 동작할 수 있다. 프로세서(1330)는 메모리(1320)에 저장된 프로그램 코드를 실행하여 API 게이트웨이(1300)의 전반의 동작을 제어하고 데이터 및 신호를 처리할 수 있다. 또한 실시 예에서 프로세서(1330)는 적어도 하나의 프로세서를 포함할 수 있다.

프로세서(1330)는 메시지를 파싱(parsing)하고, 상기 API 게이트웨이의 동작 상태가 구동 시작 또는 구동 중인지 확인하고, 상기 확인된 동작 상태를 고려하여 상기 파싱된 메시지에 포함된 파일로부터 라우트 구성(route configuration)을 확인하고, 상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하고, 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하고, 상기 리포지토리에서 관리 여부에 기반하여 상기 리포지토리의 업데이트 진행 여부를 결정할 수 있다.

전술한 실시예들에 따른 API 게이트웨이 또는 단말은, 프로세서, 프로그램 데이터를 저장하고 실행하는 메모리, 디스크 드라이브와 같은 영구 저장부(permanent storage), 외부 장치와 통신하는 통신 포트, 터치 패널, 키(key), 버튼 등과 같은 구매자 인터페이스 장치 등을 포함할 수 있다. 소프트웨어 모듈 또는 알고리즘으로 구현되는 방법들은 상기 프로세서상에서 실행 가능한 컴퓨터가 읽을 수 있는 코드들 또는 프로그램 명령들로서 컴퓨터가 읽을 수 있는 기록 매체 상에 저장될 수 있다. 여기서 컴퓨터가 읽을 수 있는 기록 매체로 마그네틱 저장 매체(예컨대, ROM(read-only memory), RAM(random-Access memory), 플로피 디스크, 하드 디스크 등) 및 광학적 판독 매체(예컨대, 시디롬(CD-ROM), 디브이디(DVD: Digital Versatile Disc)) 등이 있다. 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템들에 분산되어, 분산 방식으로 컴퓨터가 판독 가능한 코드가 저장되고 실행될 수 있다. 매체는 컴퓨터에 의해 판독가능하며, 메모리에 저장되고, 프로세서에서 실행될 수 있다.

본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다. “매커니즘”, “요소”, “수단”, “구성”과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.

전술한 실시예들은 일 예시일 뿐 후술하는 청구항들의 범위 내에서 다른 실시예들이 구현될 수 있다.

1300: API 게이트웨이
1310: 통신부
1320: 메모리
1330: 프로세서

Claims (15)

1. API 게이트웨이의 동작 방법에 있어서,
   메시지를 파싱(parsing)하는 단계;
   상기 API 게이트웨이의 동작 상태가 구동 중으로 확인된 경우 상기 파싱된 메시지로부터 확인된 IP 주소 정보와 타겟 서버의 IP 주소 정보 간의 대응할 경우 상기 파싱된 메시지로부터 확인된 파일의 시간 정보에 기반하여 최신 파일로 확인된 경우 상기 파일로부터 라우트 구성(route configuration)을 확인하는 단계;
   상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하는 단계;
   상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계;
   상기 리포지토리에서 관리되지 않을 경우 상기 리포지토리의 업데이트를 진행하는 단계;
   고객 단말로부터 수신한 요청과 매칭되는 프레디케이트를 확인하는 단계;
   상기 매칭된 프레디케이트에 기반하여 상기 요청에 대응하는 타겟 라우트를 확인하는 단계; 및
   상기 타겟 라우트에 기반하여 상기 요청을 타겟 서버로 전송하는 과정에서 ⅰ) 상기 타겟 라우트와 상기 업데이트된 리포지토리에서 관리되는 라우트 간의 대응 여부를 확인하여 상기 요청에 대응하는 트래픽을 제어하는 제1 필터, ⅱ) 기 설정된 방법에 따른 액세스 토큰의 유효성에 기반하여 인증 상태를 확인하는 제2 필터, ⅲ) 상기 고객 단말에서 로그인 여부에 따른 서로 다른 식별 정보를 이용하여 실제 사용자 여부를 확인하여 레이트 리밋 초과 여부를 확인하는 제3 필터, ⅳ) 상기 로그인 여부에 따른 상기 서로 다른 식별 정보를 데이터베이스에 동기화된 정보와 비교하여 블랙리스트 사용자에 대응하는지 확인하는 제4 필터 및 ⅴ) 상기 타겟 라우트와 관련하여 에러 발생 횟수가 기준 값 초과 여부에 따른 회로 차단 여부를 확인하는 제5 필터에 기반하여 필터링하는 단계를 포함하는,
   API 게이트웨이의 동작 방법.
2. 삭제
3. 삭제
4. 삭제
5. 제1항에 있어서,
   상기 API 게이트웨이의 동작 상태가 구동 중으로 확인된 경우 상기 파싱된 메시지로부터 확인된 상기 IP 주소 정보와 상기 타겟 서버의 상기 IP 주소 정보 간의 대응하지 않을 경우 상기 파싱된 메시지에 기초한 상기 업데이트를 스킵하는 단계를 포함하는,
   API 게이트웨이의 동작 방법.
6. 제1항에 있어서,
   상기 API 게이트웨이의 동작 상태가 구동 중으로 확인된 경우 상기 파싱된 메시지로부터 확인된 상기 IP 주소 정보와 상기 타겟 서버의 상기 IP 주소 정보 간의 대응할 경우 상기 파싱된 메시지로부터 확인된 파일의 시간 정보에 기반하여 상기 최신의 파일이 아닌 경우 상기 파싱된 메시지에 기초한 상기 업데이트를 스킵하는 단계를 포함하는,
   API 게이트웨이의 동작 방법.
7. 삭제
8. 제1항에 있어서,
   상기 API 게이트웨이의 상기 동작 상태가 구동 시작으로 확인된 경우 상기 파싱된 메시지에 포함된 상기 파일로부터 라우트 구성(route configuration)을 확인하는 단계;
   상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하는 단계;
   상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계; 및
   상기 리포지토리에서 관리되지 않을 경우 상기 리포지토리의 업데이트를 진행하는 단계를 포함하는,
   API 게이트웨이의 동작 방법.
9. 제1항에 있어서,
   상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계는,
   상기 파싱된 적어도 하나의 라우트가 상기 리포지토리(repository)에 존재하는지 확인하는 단계를 포함하는,
   API 게이트웨이의 동작 방법.
10. 제9항에 있어서,
    상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하는 단계는,
    상기 파싱된 적어도 하나의 라우트가 상기 리포지토리에 존재할 경우, 상기 파싱된 적어도 하나의 라우트의 버전의 변화 여부를 확인하는 단계를 포함하는,
    API 게이트웨이의 동작 방법.
11. 제9항에 있어서,
    상기 리포지토리에서 관리되지 않을 경우 상기 리포지토리의 업데이트를 진행하는 단계는,
    상기 파싱된 적어도 하나의 라우트가 상기 리포지토리에 존재하지 않을 경우 상기 리포지토리에 상기 파싱된 적어도 하나의 라우트를 추가하도록 상기 업데이트를 진행하는 단계를 포함하는,
    API 게이트웨이의 동작 방법.
12. 제10항에 있어서,
    상기 리포지토리에서 관리되지 않을 경우 상기 리포지토리의 업데이트를 진행하는 단계는,
    상기 파싱된 적어도 하나의 라우트의 상기 버전이 변화된 경우 상기 리포지토리에 상기 파싱된 적어도 하나의 라우트를 추가하도록 상기 업데이트를 진행하는 단계를 포함하는,
    API 게이트웨이의 동작 방법.
13. 삭제
14. 제1항에 있어서,
    상기 타겟 라우트에 기반하여 타겟 서비스를 제공하는 상기 타겟 서버로부터 상기 요청에 대응하는 관련 정보를 확인하는 단계; 및
    상기 관련 정보를 포함하는 응답을 회신하는 단계를 더 포함하는,
    API 게이트웨이의 동작 방법.
15. API 게이트웨이로서,
    통신부;
    메모리; 및
    메시지를 파싱(parsing)하고, 상기 API 게이트웨이의 동작 상태가 구동 중으로 확인된 경우 상기 파싱된 메시지로부터 확인된 IP 주소 정보와 타겟 서버의 IP 주소 정보 간의 대응할 경우 상기 파싱된 메시지로부터 확인된 파일의 시간 정보에 기반하여 최신 파일로 확인된 경우 상기 파일로부터 라우트 구성(route configuration)을 확인하고 상기 라우트 구성을 적어도 하나의 라우트 별로 파싱하고, 상기 파싱된 적어도 하나의 라우트가 리포지토리에서 관리되는지 확인하고, 상기 리포지토리에서 관리되지 않을 경우 상기 리포지토리의 업데이트를 진행하고, 고객 단말로부터 수신한 요청과 매칭되는 프레디케이트를 확인하고, 상기 매칭된 프레디케이트에 기반하여 상기 요청에 대응하는 타겟 라우트를 확인하고, 상기 타겟 라우트에 기반하여 상기 요청을 타겟 서버로 전송하는 과정에서 ⅰ) 상기 타겟 라우트와 상기 업데이트된 리포지토리에서 관리되는 라우트 간의 대응 여부를 확인하여 상기 요청에 대응하는 트래픽을 제어하는 제1 필터, ⅱ) 기 설정된 방법에 따른 액세스 토큰의 유효성에 기반하여 인증 상태를 확인하는 제2 필터, ⅲ) 상기 고객 단말에서 로그인 여부에 따른 서로 다른 식별 정보를 이용하여 실제 사용자 여부를 확인하여 레이트 리밋 초과 여부를 확인하는 제3 필터, ⅳ) 상기 로그인 여부에 따른 상기 서로 다른 식별 정보를 데이터베이스에 동기화된 정보와 비교하여 블랙리스트 사용자에 대응하는지 확인하는 제4 필터 및 ⅴ) 상기 타겟 라우트와 관련하여 에러 발생 횟수가 기준 값 초과 여부에 따른 회로 차단 여부를 확인하는 제5 필터에 기반하여 필터링하도록 지시하는, 프로세서를 포함하는,
    API 게이트웨이.

Images