API Gateway 정책이란 무엇인가요?
Yuan Bao
December 15, 2022
클라우드 네이티브와 마이크로서비스 아키텍처의 발전과 함께, API 게이트웨이의 트래픽 포털로서의 역할은 점점 더 중요해지고 있습니다. API 게이트웨이는 주로 요청된 트래픽을 수신하고 적절한 업스트림 서비스로 전달하는 역할을 합니다. API 게이트웨이의 정책은 트래픽을 관리하는 논리와 규칙을 결정하며, 이는 비즈니스 트래픽의 동작을 직접적으로 결정합니다.
API 게이트웨이 정책이란 무엇인가
API 게이트웨이는 일반적으로 모든 업스트림 서비스 앞에 위치합니다. 사용자가 서비스에 요청을 보내면, 요청은 먼저 API 게이트웨이에 도달하며, API 게이트웨이는 일반적으로 몇 가지 사항을 확인합니다:
- 요청이 합법적인지 확인합니다. 접근이 금지된 사용자 목록에 있는지 확인합니다.
- 요청이 인증되었는지, 그리고 접근하려는 콘텐츠가 권한이 있는지 확인합니다.
- 요청이 특정 제한 규칙을 트리거하는지 확인합니다. 예를 들어, 속도 제한 등이 있습니다.
- 어떤 업스트림 서비스로 전달할지 확인합니다.
이러한 일련의 단계를 거친 후, 요청은 거부되거나 지정된 업스트림 서비스에 정확히 도달합니다. 우리는 이러한 처리 규칙을 API 게이트웨이의 정책이라고 부릅니다. 이러한 규칙은 게이트웨이 관리자가 게이트웨이가 실행 중일 때 게이트웨이에 지속적으로 추가합니다. 게이트웨이는 이러한 규칙을 수용하고 해당 트래픽 처리 동작을 수행합니다.
API 게이트웨이 Apache APISIX를 예로 들면, APISIX에는 두 가지 유형의 구성 정보가 있습니다: 게이트웨이 시작을 위한 구성 파일, 예를 들어 config.yaml, 이 파일은 게이트웨이가 정상적으로 시작하는 데 필요한 몇 가지 구성을 결정합니다. 또한, 관리자는 런타임에 Admin API를 통해 다양한 규칙과 구성을 동적으로 생성할 수 있습니다, 예를 들어 Route, Consumer, Plugin 등이 있습니다. API 게이트웨이의 정책은 관리자가 Admin API를 통해 동적으로 생성한 다양한 규칙과 구성입니다.
이 글에서는 네 가지 API 게이트웨이 시나리오, 인증 및 권한 부여, 보안, 트래픽 처리, 그리고 관찰 가능성에 대해 설명하고, 각 시나리오에서 API 게이트웨이 정책이 어떻게 작동하는지 설명합니다.
인증 및 권한 부여 정책
인증은 API 호출자의 신원을 확인할 수 있으며, 권한 부여는 호출자가 권한 내의 리소스만 접근할 수 있도록 제한합니다.
예를 들어, 승객이 역에 도착하면, 역에 들어가기 전에 신분증을 사용하여 "인증"을 통해 신원을 확인합니다. 역에 들어간 후, 승객은 직원에게 티켓을 보여주고 확인을 받아 특정 열차에 "권한 부여"를 받습니다. 인증 및 권한 부여 정책의 주요 목적은 업스트림 서비스로 전달되는 모든 요청이 합법적이며, 요청이 권한 범위 내의 리소스만 접근하도록 보장하는 것입니다. 몇 가지 표준 정책은 다음과 같습니다:
기본 인증
기본 접근 인증 정책은 가장 간단한 접근 제어 기술입니다. 일반적으로 사용자의 HTTP 프록시는 요청을 보낼 때 인증을 위한 요청 헤더를 포함하며, 이는 일반적으로 Authorization: Basic <credentials>입니다. credentials에는 사용자 인증에 필요한 사용자 ID와 비밀번호가 포함되며, :로 구분됩니다. 이 방법은 로그인 페이지와 쿠키와 같은 복잡한 설정이 필요하지 않습니다. 요청 헤더의 간단한 자격 증명 정보를 기반으로 인증되며, 일반적으로 사용자 이름과 비밀번호로 구성되어 있어 구성과 사용이 간단합니다.
기본 인증이 포함된 cURL 요청의 예는 다음과 같으며, username과 password가 포함됩니다:
curl -i -u 'username:password' http://127.0.0.1:8080/hello
credentials의 정보는 전송 중에 암호화되지 않으며, base64로 인코딩만 되므로 일반적으로 HTTPS와 함께 사용하여 비밀번호의 보안을 보장해야 합니다.
이 정책이 게이트웨이에 구현되면, 자격 증명이 없는 요청은 전달되지 않으며, 요청에 올바른 인증 정보가 포함되어야 합니다. 이 정책은 최소 비용으로 API 접근 검증을 구현합니다.
키 인증
키 인증 정책은 API에 키를 추가하고 키를 사용하여 리소스 접근을 제어합니다. 올바른 키가 포함된 요청만 리소스에 접근할 수 있으며, 이 키는 요청 헤더나 쿼리에 포함될 수 있습니다. 일반적으로 이 키는 다른 API 호출자를 구분하는 데도 사용될 수 있습니다. 따라서 다른 호출자에 대해 다른 정책이나 리소스 제어를 구현할 수 있습니다. 기본 인증과 마찬가지로 키는 암호화되지 않습니다. 요청이 HTTPS를 사용하여 보안을 보장해야 합니다.
APISIX의 key-auth 플러그인을 예로 들면, 이 플러그인은 Admin API를 통해 고유한 키 값을 가진 Consumer를 생성해야 합니다:
curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "jack-key"
}
}
}'
이 요청은 jack이라는 이름의 Consumer를 생성하고, 키 값으로 jack-key를 설정합니다.
라우트에서 이 플러그인을 활성화할 때, 요청에서 키의 위치와 필드 이름을 구성해야 합니다. 기본 구성 위치는 header이며, 필드 이름은 apikey입니다. 따라서 이 라우트를 요청하는 올바른 코드는 다음과 같습니다:
curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'
APISIX가 이 요청을 받으면, APISIX는 키를 파싱하고 구성된 모든 키 중에서 Consumer jack을 매칭합니다. 따라서 게이트웨이는 이 요청이 jack에 의해 전송된 것임을 알 수 있습니다. 매칭되는 키가 없으면 불법 요청으로 판단할 수 있습니다.
JSON 웹 토큰
JSON 웹 토큰(JWT)은 json 객체 형태로 당사자 간에 정보를 안전하게 전달하는 방법을 정의한 개방형 표준입니다. JWT 정책은 인증과 권한 부여를 결합할 수 있습니다. 사용자가 권한을 부여한 후, JWT 토큰이 사용자에게 전달되며, 호출자는 이후 모든 요청에 이 토큰을 포함하여 요청이 권한이 있음을 보장합니다.
API 게이트웨이에서 JWT 인증은 JWT 정책을 통해 게이트웨이에 추가할 수 있습니다. 따라서 인증 로직을 비즈니스 코드에서 분리할 수 있으며, 개발자는 비즈니스 로직 구현에 더 집중할 수 있습니다. APISIX의 jwt-auth 플러그인을 예로 들면, 이 플러그인은 Consumer에서 활성화 및 구성되어야 하며, 고유한 키, 암호화를 위한 공개 및 개인 키, 암호화 알고리즘, 토큰 만료 시간 등을 설정해야 합니다. 동시에 라우트에서 이 플러그인을 활성화하고 게이트웨이가 토큰을 읽을 위치와 필드를 구성해야 합니다, 예를 들어 header, query, cookie 등이 있습니다. 이 플러그인은 API 게이트웨이에 토큰 발급을 위한 API를 추가합니다. 요청을 보내기 전에 토큰 발급 API를 요청해야 합니다. 요청을 보낼 때 구성 정보에 따라 지정된 위치에 토큰을 포함해야 합니다. 요청이 게이트웨이에 도달하면, 게이트웨이는 구성 정보에 따라 요청의 지정된 위치에서 토큰을 읽고 토큰의 유효성을 검증합니다. 검증이 완료되면 요청을 업스트림 서비스로 전달할 수 있습니다.
이전 두 전략과 비교하여, JWT 정책은 만료 시간 옵션을 포함합니다. 발급된 토큰은 시간이 지나면 만료될 수 있지만, 기본 인증과 키 인증의 유효 기간은 영구적입니다. 서버가 비밀번호나 키를 변경하지 않는 한 유효합니다. 또한, JWT 정책은 여러 서비스 간에 공유될 수 있어 단일 사인온(SSO) 시나리오에 유리합니다.
OpenID Connect
OpenID Connect는 OAuth2.0 프로토콜을 기반으로 한 인증 및 권한 부여 방법으로, 비교적 완전한 애플리케이션 솔루션을 제공합니다. API 게이트웨이의 OpenID Connect 정책은 업스트림 서비스가 ID 제공자(IdP)로부터 사용자 정보를 얻을 수 있도록 하여 API 보안을 보호합니다. 일반적인 IdP는 Keycloak, Ory Hydra, Okta, Auth0 등이 있습니다. Apache APISIX를 예로 들면, 게이트웨이의 OpenID Connect 정책의 작업 흐름은 다음과 같습니다:
- 클라이언트가 게이트웨이에 요청을 보냅니다.
- 게이트웨이가 요청을 받은 후, IdP에 인증 요청을 보냅니다.
- 사용자는 IdP가 제공한 페이지로 리디렉션되어 로그인 인증을 완료합니다.
- IdP는 인증 코드와 함께 게이트웨이로 리디렉션합니다.
- 게이트웨이는 코드를 통해 IdP에 액세스 토큰을 요청하여 사용자 정보를 얻습니다.
- 게이트웨이는 업스트림으로 요청을 전달할 때 사용자 정보를 포함할 수 있습니다.
이 과정을 통해 인증과 권한 부여가 비즈니스에서 분리되어 아키텍처가 더 세분화됩니다.
APISIX의 더 많은 인증 및 권한 부여 방법에 대해서는 API 게이트웨이 인증을 참조하십시오.
보안 정책
API 게이트웨이 보안 정책은 게이트키퍼처럼 작동하여 안전한 API 접근을 보장하며, 합법적인 요청은 게이트웨이를 통해 전달되고 불법 요청은 게이트웨이에서 차단됩니다. OWASP API 보안 프로젝트에 따르면, API 호출자에 대한 많은 가능한 위협과 공격이 존재합니다. API 게이트웨이 보안 정책을 사용하면 모든 API 요청에 대해 보안 검증을 수행할 수 있으며, 이러한 보안 위협으로부터 API를 보호하는 데 중요한 역할을 합니다.
다음은 몇 가지 중요한 API 게이트웨이 보안 정책입니다:
IP 접근 제한
IP 제한 정책은 특정 클라이언트가 API에 접근하는 것을 제한하기 위해 특정 IP 또는 CIDR을 허용 목록 또는 차단 목록에 설정하여 민감한 데이터의 악의적인 접근을 방지합니다. 이 정책을 적절히 구성하면 API의 보안을 크게 향상시키고 더 높은 API 보안 거버넌스를 가능하게 합니다.
URI 차단
URI 차단 정책은 일부 URI 규칙을 설정하여 잠재적으로 위험한 API 요청을 차단합니다. 예를 들어, 일부 보안 공격은 URI 경로를 스니핑하여 잠재적인 취약점을 탐지한 후 공격합니다. Apache APISIX는 uri-blocker 플러그인을 제공하여 위험한 API 요청을 차단합니다. uri-blocker 플러그인을 통해 정규 표현식을 설정할 수도 있습니다. API 게이트웨이는 요청이 규칙과 일치하면 요청을 차단합니다. 예를 들어, root.exe, admin을 구성하면, 이 플러그인은 */root.exe 및 */admin 요청을 차단하여 API 보안을 더욱 강화할 수 있습니다.
CORS
CORS(Cross-origin resource sharing)는 브라우저의 크로스 도메인 요청에 대한 보안 정책입니다. 일반적으로 브라우저에서 xhr 요청을 보내기 전에, 브라우저는 요청 주소와 현재 주소가 동일한 출처에 있는지 확인합니다. 동일 출처 내의 요청은 직접 전송됩니다. 그렇지 않으면, 브라우저는 먼저 OPTION 유형의 크로스 도메인 사전 요청을 보냅니다. 응답 헤더에는 CORS 관련 설정이 포함되며, 예를 들어 크로스 도메인 요청에서 허용되는 메서드와 자격 증명 등이 있습니다. 브라우저는 이 정보를 기반으로 정식 요청을 보낼지 여부를 결정합니다. 자세한 내용은 CORS를 참조하십시오.
일반적으로 CORS 설정이 포함된 응답은 백엔드 서비스에 의해 설정됩니다. 그러나 서비스가 많은 경우, 게이트웨이 수준에서 이를 일괄 처리하는 것이 더 안전하고 편리합니다. CORS 정책은 다른 API에 대해 다른 크로스 도메인 해결 정책을 설정할 수 있으며, 업스트림 서비스는 더 이상 이러한 로직을 처리할 필요가 없습니다.
CSRF
CSRF는 크로스 사이트 요청 위조 공격으로, 인증된 웹사이트에서 최종 사용자가 원하지 않는 작업을 수행하도록 만듭니다. 이 공격은 일반적으로 소셜 엔지니어링(피해자에게 이메일로 악성 링크를 보내는 것)과 함께 발생합니다. 사용자가 링크를 클릭하면, 공격자는 피해자의 인증된 신원을 사용하여 웹사이트에서 공격 작업을 수행합니다. 웹사이트의 관점에서, 모든 행동은 예상된 것이며, 사용자가 이미 로그인했기 때문입니다.
일반적으로 웹사이트의 백엔드 서비스는 이 부분의 로직을 처리하기 위해 추가적인 미들웨어를 추가해야 하며, 방어 방법도 특정 표준이 있습니다. CSRF 정책을 사용하면 이 공격을 방지하고 게이트웨이 레벨에서 CSRF 보안 처리를 수행하여 업스트림 서비스의 로직 복잡성을 단순화할 수 있습니다.
트래픽 처리 정책
트래픽 처리 정책은 주로 API 게이트웨이가 트래픽을 전달하는 업스트림 부하가 건강한 범위 내에 있도록 보장합니다. 동시에, 요청이 전달되거나 호출자에게 반환되기 전에 요청을 필요에 따라 재작성합니다. 이 유형의 정책은 주로 속도 제한, 서킷 브레이커, 캐싱, 재작성과 같은 기능에 관한 것입니다.
속도 제한
제한된 리소스의 경우, API가 제공할 수 있는 서비스 능력에는 한계가 있습니다. 호출이 이 한계를 초과하면, 업스트림 서비스가 충돌하여 일부 연쇄 반응을 일으킬 수 있습니다. 속도 제한은 이러한 경우를 방지할 수 있으며, API가 DDOS(서비스 거부 공격)로부터 공격받는 것을 효과적으로 방지할 수 있습니다.
속도 제한 정책에서 시간 창과 최대 허용 요청 수를 구성할 수 있습니다. API 게이트웨이는 최대 허용 요청 수를 초과하는 요청을 거부하고 속도 제한 오류 메시지를 반환합니다. 요청 수가 제한보다 적어지거나 다음 시간 창이 열릴 때까지 요청은 허용되지 않습니다.
요청 카운팅을 위한 변수는 요청에 설정하거나 특정 요청 헤더로 설정할 수 있습니다, 예를 들어, 다른 IP에 따라 해당 속도 제한 정책을 설정하여 더 나은 유연성을 달성할 수 있습니다.
서킷 브레이커
API 서킷 브레이커 정책은 업스트림 서비스에 서킷 브레이커 기능을 제공할 수 있습니다. 이 정책을 사용할 때, 게이트웨이가 업스트림 서비스의 상태를 판단하기 위해 건강한 상태와 비건강한 상태의 상태 코드를 설정해야 합니다. 또한, 브레이크를 트리거하거나 건강을 복원하기 위한 요청 임계값을 설정해야 합니다. 업스트림 서비스가 게이트웨이에 지속적으로 비건강 상태 코드를 반환하면, 게이트웨이는 일정 시간 동안 업스트림 서비스를 차단합니다. 이 기간 동안 게이트웨이는 더 이상 요청을 업스트림으로 전달하지 않고 직접 오류를 반환합니다. 이는 업스트림 서비스가 오류로 인해 계속 요청을 받아 "눈사태"를 일으키는 것을 방지하고 비즈니스 서비스를 보호합니다. 이 기간이 지난 후, 게이트웨이는 다시 요청을 업스트림으로 전달하려고 시도합니다. 여전히 비건강 상태 코드를 반환하면, 게이트웨이는 더 긴 시간(2배) 동안 차단을 계속합니다. 업스트림이 일정 수의 건강 상태 코드를 반환할 때까지, 게이트웨이는 업스트림 서비스가 건강 상태로 돌아왔다고 판단하고 트래픽을 업스트림 노드로 계속 전달합니다.
이 정책에서, 비건강 상태일 때 반환해야 하는 상태 코드와 정보를 설정해야 합니다. 업스트림 서비스가 비건강 상태일 때, 요청은 게이트웨이 수준에서 직접 반환되어 비즈니스 서비스의 안정성을 보호합니다.
트래픽 분할
트래픽 분할 정책은 다른 업스트림 서비스로 트래픽을 비율에 따라 동적으로 제어할 수 있습니다. 이는 카나리 릴리스와 블루-그린 배포에서 유리합니다.
카나리 릴리스는 일부 요청만 새 서비스를 사용하도록 허용하고, 다른 부분은 이전 서비스를 유지합니다. 새 서비스가 안정적으로 유지되면, 비율을 늘리고 점차 모든 요청을 새 서비스로 전환하여 업그레이드를 완료할 수 있습니다.
블루-그린 릴리스는 또 다른 릴리스 모드로, 피크 시간 동안 서비스를 중단하지 않고 새 버전을 릴리스합니다. 이전 버전과 새 버전의 서비스가 공존합니다. 일반적으로 프로덕션 환경(블루)은 동일하지만 별도의 컨테이너(그린)에 복사됩니다. 그린 환경에 새 업데이트를 릴리스한 후, 그린과 블루를 모두 프로덕션에 릴리스합니다. 그린 환경은 사용자가 여전히 블루 시스템에 접근하는 동안 테스트 및 수정할 수 있습니다. 그런 다음 일부 로드 밸런싱 정책을 사용하여 요청을 그린 환경으로 리디렉션할 수 있습니다. 블루 환경은 재해 복구 옵션으로 유지하거나 다음 업데이트를 위해 대기할 수 있습니다.
APISIX는 traffic-split 플러그인을 통해 두 릴리스를 모두 지원하여 비즈니스 배포를 더 편리하고 안정적으로 만듭니다.
응답 재작성
현대 마이크로서비스 아키텍처에서는 서비스 간에 다양한 프로토콜이 존재하며, 통일된 응답 데이터 형식이 없습니다. 이 변환 로직을 각 서비스에서 별도로 구현하면 중복된 로직 코드가 발생하며 관리가 어렵습니다. 일부 응답 재작성 정책은 프로토콜 변환, 요청 본문 재작성 및 기타 로직을 처리할 수 있습니다.
APISIX는 응답 재작성 플러그인을 제공하여 업스트림 서비스에서 반환된 Body 또는 Header 정보를 수정하고, 응답 헤더를 추가하거나 삭제하고, 응답 본문을 수정하는 규칙을 설정하는 등을 지원합니다. 이는 크로스 도메인 요청에 대한 CORS 응답 헤더를 설정하거나 리디렉션을 위한 위치를 설정하는 등의 시나리오에서 유용합니다.
반면, APISIX는 요청 재작성을 위한 proxy-rewrite를 제공합니다. 이 플러그인은 업스트림 서비스로 프록시된 요청의 콘텐츠를 처리할 수도 있습니다. 요청된 URI, 메서드, 요청 헤더 등을 재작성할 수 있으며, 이는 많은 시나리오에서 비즈니스 처리를 위한 편의를 제공합니다.
결함 주입
결함 주입은 소프트웨어 테스트 방법으로, 의도적으로 오류를 도입하여 시스템의 올바른 동작을 보장합니다. 일반적으로 배포 전에 테스트를 수행하여 프로덕션 환경에서 잠재적인 실패가 없는지 확인합니다. 일부 카오스 테스트 시나리오에서는 서비스에 일부 오류를 주입하여 신뢰성을 검증해야 합니다.
소프트웨어 결함 주입은 컴파일 타임 주입과 런타임 주입으로 분류될 수 있습니다. 컴파일 타임 주입은 소프트웨어 작성 중 일부 코드나 로직을 변경하는 것을 의미합니다. 런타임 주입은 실행 중인 소프트웨어 환경에 오류를 설정하여 소프트웨어의 동작을 테스트합니다. 결함 주입 정책은 런타임 주입을 통해 애플리케이션 네트워크 요청에서 결함을 시뮬레이션할 수 있습니다. 정책에서 비율을 선택하면, 이 비율 내의 요청은 결함 로직을 실행합니다, 예를 들어 지연 시간을 반환하거나 설정된 오류 코드와 오류 메시지를 호출자에게 직접 반환합니다. 이렇게 하면 소프트웨어의 적응성을 높일 수 있으며, 개발자가 릴리스 전에 가능한 오류 상황을 미리 확인하고 문제에 대한 적응 수정을 할 수 있습니다.
프로토콜 변환
프로토콜 변환 클래스의 정책은 일반적인 HTTP 요청과 gRPC와 같은 일부 표준 프로토콜 간에 변환할 수 있습니다. Apache APISIX는 grpc-transcode 플러그인을 제공하여 HTTP 요청을 gRPC 유형 서비스로 변환 및 전달할 수 있습니다. 응답은 HTTP 형식으로 클라이언트에 반환됩니다. 이렇게 하면 클라이언트는 HTTP에만 집중할 수 있으며, 업스트림 gRPC 유형에 대해 신경 쓸 필요가 없습니다.
관찰 가능성 정책
관찰 가능성은 시스템의 출력 데이터를 통해 시스템의 운영 상태를 측정할 수 있는 능력을 말합니다. 일부 간단한 시스템에서는 시스템 구성 요소의 수가 상대적으로 적기 때문에, 오류가 발생할 때 각 구성 요소의 상태를 분석하여 버그를 찾을 수 있습니다. 그러나 대규모 분산 시스템에서는 다양한 마이크로서비스 구성 요소의 수가 매우 많기 때문에, 구성 요소를 하나씩 확인하는 것은 비현실적입니다. 이때 시스템은 관찰 가능해야 합니다. 관찰 가능성은 대규모 시스템의 가시성을 제공하며, 문제가 발생할 때 엔지니어가 문제를 정확히 파악할 수 있도록 필요한 제어를 제공합니다.
데이터 수집은 애플리케이션 구성 요소 내에서 구현될 수 있습니다. API 게이트웨이는 모든 트래픽의 입구이므로, API 게이트웨이에 시스템의 관찰 가능성 기능을 구현하면 시스템 API의 사용량을 반영할 수 있습니다. API 게이트웨이 관찰 가능성 정책은 모든 팀에 도움을 줄 수 있습니다:
- 엔지니어 팀은 API 문제를 모니터링하고 해결할 수 있습니다.
- 제품 팀은 API의 사용량을 이해하여 그 뒤에 있는 비즈니스 가치를 발견할 수 있습니다.
- 영업 및 성장 팀은 API 사용량을 모니터링하고 비즈니스 기회를 주시하며 API가 올바른 데이터를 제공하는지 확인할 수 있습니다.
관찰 가능성 정책은 일반적으로 출력 데이터 유형에 따라 세 가지 범주로 나뉩니다: 추적, 메트릭, 로깅.
추적
대규모 분산 시스템에서 서비스 간의 관계는 복잡합니다. 추적(링크 추적)은 완전한 호출 링크를 추적하고, 애플리케이션 간의 종속성 분석 및 분산 애플리케이션의 요청 통계를 수행할 수 있습니다. 시스템에 문제가 발생할 때, 엔지니어가 조사 범위와 위치를 결정하는 데 도움을 줄 수 있습니다.
추적 정책은 API 게이트웨이에 다른 분산 호출 링크 추적 시스템을 통합하여 데이터를 수집하고 기록할 수 있습니다. 예를 들어, Zipkin 및 SkyWalking과 같은 서비스를 API 게이트웨이에 통합하여 데이터 및 서비스 간 통신을 수집할 수 있습니다. 따라서 이 정책을 통해 엔지니어는 특정 세션이나 관련 API 호출에 대해 어떤 로그를 확인해야 하는지 알 수 있으며, 문제 해결 범위를 확인할 수 있습니다.
메트릭
메트릭은 서비스 운영 중 일정 시간 간격 동안 수집된 소프트웨어의 관찰 데이터를 말합니다. 이 데이터는 기본적으로 구조화되어 있어 쿼리 및 시각화가 쉽습니다. 이 데이터를 분석하여 시스템의 운영 상태를 파악할 수 있습니다.
메트릭 정책은 API 게이트웨이에 Prometheus 또는 Datadog과 같은 서비스를 통합하여 시스템에 대한 모니터링 및 알림 기능을 제공할 수 있습니다. 이 정책은 게이트웨이 운영 중 다양한 API 게이트웨이 인터페이스를 통해 데이터를 수집하고 Prometheus 또는 Datadog에 데이터를 보고합니다. 이 데이터를 시각화하여 개발자는 게이트웨이의 실행 상태, API 요청의 통계 정보 및 기타 통계 그래프를 볼 수 있습니다.
로깅
로그는 특정 시간에 시스템 이벤트의 텍스트 기록입니다. 시스템에 문제가 발생할 때, 로그는 첫 번째로 확인해야 할 곳입니다. 엔지니어는 로그 내용을 통해 시스템에 무슨 일이 일어났는지 파악하고 해당 솔루션을 찾습니다. 로그 내용은 일반적으로 API 요청 로그와 게이트웨이의 실행 로그로 나뉩니다. API 요청 로그는 API 게이트웨이 운영 중 모든 API 요청 기록을 포함합니다. 엔지니어는 이러한 기록을 통해 API 접근 정보를 파악하고, 비정상 요청을 발견하고 문제를 해결할 수 있습니다. 게이트웨이의 운영 로그는 게이트웨이 작업 중 발생한 모든 이벤트의 기록을 포함합니다. API 게이트웨이가 비정상일 때, 문제 해결을 위한 중요한 근거로 사용될 수 있습니다.
로깅 정책은 API 게이트웨이의 로그를 서버 디스크에 저장하거나 HTTP 로그 서버, TCP 로그 서버, UDP 로그 서버 등과 같은 다른 로그 서버로 푸시하거나 Kafka, RocketMQ, Clickhouse와 같은 다른 로그 시스템으로 푸시할 수 있습니다.
요약
이 글에서는 API 게이트웨이에서 일반적으로 사용되는 네 가지 정책: 인증 및 권한 부여, 보안, 트래픽 처리, 그리고 관찰 가능성에 대해 소개했습니다. API 게이트웨이는 모든 업스트림 서비스 앞에서 요청된 트래픽을 수신하고, 요청이 어디로 어떻게 전달될지 제어하며, 안전하지 않고 권한이 없는 요청을 직접 거부하거나 제한합니다. API 게이트웨이 정책은 이러한 모든 동작을 구성할 수 있습니다.
더 많은 API 게이트웨이 관련 정보는 블로그와 API7.ai를 방문하여 더 많은 상업적 지원을 받으십시오.