Azure-API-Management
Azure API Management를 이용하여 QoS, 인증, 서비스 구분, 로깅, Traffic 추적을 고려하여 서비스는 구축하는 방법에 대한 글
QoS란
서비스 품질을 관리하고 보장하기 위한 개념, 네트워크와 애플리케이션의 안정성과 성능을 유지하는 데 사용.
QoS는 시스템이 다양한 요청을 처리할 때 자원을 효율적으로 배분하여 성능 저하를 방지하고, 중요한 트래픽이 우선적으로 처리되도록 보장한다.
주요 요소
- 대역폭 관리 (Bandwidth Management)
- 네트워크 트래픽을 제어하여 특정 서비스나 애플리케이션에 필요한 대역폭 보장
- 우선순위 설정 (Prioritization)
- 특정 요청이나 트래픽 유형을 우선 처리
- 지연 최소화 (Latency Reduction)
- 요청 및 응답 간의 지연 시간을 최소화
- 패킷 손실 관리 (Packet Loss Management)
- 데이터 패킷 손실을 방지하고 신뢰성 높은 데이터 전송을 보장
- 스루풋 관리 (Throughput Management)
- 네트워크가 초당 처리할 수 있는 데이터량을 최대화하여 시스템 성능을 최적화
Azure에서 QoS 관련 도구
- Azure API Management : API 요청량 제한, 속도 제한, 스로틀링 등을 설정 가능
- Azure Traffic Manager : 글로벌 트래픽 라우팅과 서비스 우선순위 설정
- Azure Load Balancer : 로드 밸런싱을 통해 네트워크 트래픽 분산
API Management와 App Service를 사용하여 구축하면…
고려사항
- QoS
- 인증
- 서비스 구분 (요청하는 출발지 서버 또는 클라이언트 구분)
- 로깅
- Traffic 추적
API Management의 QoS (Quality of Service)
Rate Limiting & Throttling
- rate-limit-by-key
- 요청의 속도를 제한하거나 특정 시간 동안의 요청수 제한 가능
- 서비스의 오버로드를 방지하고 공정한 사용 보장 가능
- ‘rate-limit’, ‘quota’ 정책으로 설정 가능
- 사용자 지정 키 기반, IP 주소 기반, 사용자 ID 기반, 클라이언트 기반 제한 가능
Caching
- 자주 사용되는 응답 데이터를 캐싱하여 성능을 향상시키고 백엔드 서비스의 부담을 줄인다.
- 설정된 캐시 기간 동안 동일 요청은 API Management에서 응답 처리
Request/Response Timeout
Circuit Breaker
- 특정 서비스가 불안정하거나 응답 시간이 길 경우, 요청을 차단하고 대체 응답을 제공할 수 있다.
- Circuit Breaker가 작동하면 API Management는 정의된 시간동안 백엔드 서비스로의 요청을 전송하는 것을 중단하고 클라이언트에게 503 서비스를 사용할 수 없음을 반환
- Bicep 예시
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
name: 'myAPIM/myBackend'
properties: {
url: 'https://mybackend.com'
protocol: 'http'
circuitBreaker: {
rules: [
{
failureCondition: {
count: 3
errorReasons: [
'Server errors'
]
interval: 'PT1H'
statusCodeRanges: [
{
min: 500
max: 599
}
]
}
name: 'myBreakerRule'
tripDuration: 'PT1H'
acceptRetryAfter: true
}
]
}
}
}
count : 실패로 간주되는 요청의 횟수, 3연속 실패 시 Circuit Breaker 작동
errorReasons : 실패로 간주할 에러 이유 목록, ‘Server errors’는 서버 쪽 에러 (HTTP 5xx)가 원인임을 나타냄
interval : 실패 조건을 평가하는 시간 간격, 1시간 (PT1H) 동안 요청 실패를 기준으로 계산
statusCodeRanges : 실패로 간주할 HTTP 상태 코드 범위, 500~599 상태 코드는 서버 에러로 간주
Circuit Breaker 동작 요약
- 트리거 조건:
- 지난 1시간 동안 500-599 상태 코드로 인해 3번의 실패가 발생했을 경우.
- 작동 방식:
- Circuit Breaker가 활성화되면 모든 요청을 차단하고 클라이언트에게 즉시 응답을 반환
- 차단 기간:
- 1시간 동안(PT1H) 요청 차단.
- 백엔드 재시도:
- 백엔드가
Retry-After헤더를 보내는 경우, 해당 시점까지 재시도를 연기
- 백엔드가
- 트리거 조건:
인증 및 권한 관리
OAuth 2.0은 웹 API와 같은 리소스에 대한 액세스를 보호하는 데 널리 사용되는 표준 권한 부여 프레임워크이다. OAuth 2.0은 사용자의 자격 증명을 공유하지 않고도 클라이언트 앱이 사용자를 대신하여 리소스에서 수행할 수 있는 작업을 제한한다. OAuth 2.0은 인증 프로토콜은 아니지만 사용자 인증 및 SSO 기능을 제공하여 OAuth 2.0을 확장하는 OIDC(OpenID Connect)와 함께 사용되는 경우가 많다
OAuth 흐름
- 클라이언트는 ID 공급자에 대한 자격 증명을 사용하여 인증
- 클라이언트는 ID 공급자의 권한 부여 서버에서 시간이 제한된 액세스 토큰(JSON 웹 토큰 또는 JWT)를 가져온다
- ID 공급자(예: MS Entra ID)는 토큰의 발급자이며 토큰에는 리소스 서버(예: 백엔드 API 또는 API Management 게이트웨이 자체)에 대한 액세스를 승인하는 대상 그룹 클레임이 포함된다
- 클라이언트는 API를 호출하고 액세스 토큰을 제공한다 (예: 권한 부여 헤더)
- 리소스 서버는 엑세스 토큰의 유효성을 검사한다. 유효성 검사는 발급자 및 대상 그룹 클레임에 예상 값이 포함되어 있는지 유효서을 검사하는 복잡한 프로세스이다.
- 토큰 유효성 검사 조건에 따라 백엔드 API의 리소스에 대한 액세스 권한이 부여된다.
시나리오 예시 : 클라이언트 앱이 API Management에 직접 권한을 부여
- API Management 서비스는 API를 대신하여 작동
- 액세스 토큰의 범위는 호출 애플리케이션과 API Management 게이트웨이 사이
- API Management에서 게이트웨이가 요청을 백엔드에 전달하기 전에 토큰의 유효성을 검사하도록 정책(validate-jwt 또는 validate-azure-ad-token)을 구성
- MS Entra ID는 권한 부여 공급자
References
Azure API Management의 API에 대한 인증 및 권한 부여
- OAuth 2.0 및 OpenID Connect : Azure AD, Facebook, Google 등과 연동하여 인증 및 토큰 기반 권한 관리를 지원
- OAuth 2.0
- API Key 인증 : 각 클라이언트가 고유한 API 키로 인증을 수행할 수 있다.
- IP 제한 : 특정 IP 주소 또는 범위에서만 접근 가능하도록 설정 가능
서비스 구분
- Route 설정: API Gateway에서 경로(Route)를 정의하여 특정 요청이 해당 App Service로 전달되도록 설정 가능.
- Versioning: API Gateway에서 버전 관리를 통해 클라이언트가 원하는 API 버전을 호출할 수 있도록 지원.
- Multi-Backend 지원: 하나의 API Gateway를 통해 여러 App Service나 Azure Function을 서비스 구분 없이 연결할 수 있다.
Azure API Management의 가시성(?)
| 도구 | 유용한 분야 | 데이터 지연 | 보존 | 샘플링 | 데이터 종류 | 지원되는 배포 모델 |
|---|---|---|---|---|---|---|
| API 검사기 | 테스트 및 디버깅 | 인스턴트 | 마지막 100개 추적 | 요청에 따라 튜닝됨 | 요청 추적 | 관리형, 자체 호스팅, Azure Arc, 작업 영역 |
| 기본 제공 분석 | 보고 및 모니터링 | 분 | 수명 | 100% | 보고서 및 로그 | 관리형 |
| Azure Monitor 메트릭 | 보고 및 모니터링 | 분 | 90일(연장하려면 업그레이드) | 100% | 메트릭 | 관리, 자체 호스팅2, Azure Arc |
| Azure Monitor 로그 | 보고, 모니터링, 디버그 | 분 | 31일/5GB(연장하려면 업그레이드) | 100%(조정 가능) | 로그 | 관리1, 자체 호스팅3, Azure Arc3 |
| Azure Application Insights | 보고, 모니터링, 디버그 | 초 | 90일/5GB(연장하려면 업그레이드) | 사용자 지정 | 로그, 메트릭 | 관리형1, 자체 호스팅1, Azure Arc1, 작업 영역1 |
| Azure Event Hubs를 통해 로깅 | 사용자 지정 시나리오 | 초 | 관리되는 사용자 | 사용자 지정 | 사용자 지정 | 관리1, 자체 호스팅1, Azure Arc1 |
| OpenTelemetry | 모니터링 | 분 | 관리되는 사용자 | 100% | 메트릭 | Self-hosted2 |
References : https://learn.microsoft.com/ko-kr/azure/api-management/observability
API Management 모니터링
서비스를 모니터링하기 위해 데이터를 수집하는 방법과 수집된 데이터로 수행할 수 있는 작업
| 수집할 데이터 | 설명 | 데이터를 수집하고 라우팅하는 방법 | 데이터를 볼 수 있는 위치 | 지원되는 데이터 |
|---|---|---|---|---|
| 메트릭 데이터 | 메트릭은 시간상 특정 지점에서 시스템의 측면을 설명하는 숫자 값입니다. 메트릭은 다른 메트릭과 비교하여 알고리즘을 사용하여 집계하고 시간에 따른 추세를 분석할 수 있습니다. | - 정기적으로 자동으로 수집됩니다.- 일부 플랫폼 메트릭을 Log Analytics 작업 영역으로 라우팅하여 다른 데이터를 쿼리할 수 있습니다. 각 메트릭에 대한 DS 내보내기 설정을 확인하여 진단 설정을 사용하여 메트릭 데이터를 라우팅할 수 있는지 확인합니다. | 메트릭 탐색기 | Azure Monitor에서 지원하는 Azure API Management 메트릭 |
| 리소스 로그 데이터 | 로그는 타임스탬프를 사용하여 기록된 시스템 이벤트입니다. 로그는 다양한 형식의 데이터를 포함할 수 있으며 구조화되거나 자유 형식의 텍스트일 수 있습니다. 쿼리 및 분석을 위해 리소스 로그 데이터를 Log Analytics 작업 영역으로 라우팅할 수 있습니다. | 리소스 로그 데이터를 수집하고 라우팅하는 진단 설정을 만듭니다. | Log Analytics | Azure Monitor에서 지원하는 Azure API Management 리소스 로그 데이터 |
| 활동 로그 데이터 | Azure Monitor 활동 로그는 구독 수준 이벤트에 대한 인사이트를 제공합니다. 활동 로그에는 리소스가 수정되거나 가상 머신이 시작될 때와 같은 정보가 포함됩니다. | - 자동으로 수집됩니다.- 무료로 Log Analytics 작업 영역에 대한 진단 설정을 만듭니다. | 활동 로그 |
API Management에 대한 기본 제공 모니터링
Azure API Management API 분석 사용
API에 대한 분석을 제공하므로, API의 사용량과 성능을 분석할 수 있다.
분석을 사용하여 API에 대한 개괄적인 모니터링과 문제 해결을 수행할 수 있다.
- API Management는 Azure Monitor 기반 대시보드를 사용하여 분석을 제공
- 대시보드는 Azure Log Analytics 작업 영역의 데이터를 집계한다.
- API Management REST API를 사용하여 분석 데이터에 엑세스할 수 있다. Azure Monitor 기반 대시보드와 기본 제공 분석에도 매우 유사한 데이터가 표시된다.
Grafana 대시보드를 사용한 API Management 모니터링 데이터 시각화
Azure Managed Grafana를 사용하여 Log Analytics 작업 영역에 수집된 API Management 모니터링 데이터를 시각화할 수 있다.
References
https://learn.microsoft.com/ko-kr/azure/api-management/monitor-api-management
References
로깅
Application Insights
- API Gateway와 App Service 양쪽에서 Application Insights를 통해 요청/응답 로깅, 에러 추적, 성능 모니터링 등을 설정할 수 있다.
- Azure Portal, REST API 또는 관련 Azure 도구를 사용하여 Application Insights와 API Management 간의 연결을 만들 수 있다. (API Management는 연결을 위한 로거 리소스 구성)
Azure Monitor
요청 수, 대기 시간, 성공/실패 상태 코드 등 다양한 로그를 실시간으로 수집하고 대시보드로 시각화 가능.
Custom Logging
필요에 따라 로그를 Blob Storage나 Event Hub로 전달해 장기 보관 및 분석을 할 수 있다.
Slack에 경고
- Azure API Management 서비스에서 외부 서비스 사용
- 외부 서비스가 일종의 중요한 이벤트 알림을 받을 수 있도록 설정 가능
- 조건을 만족하는 경우
send-one-way-request정책을 사용하여 외부 HTTP 요청을 만들 수 있다. - Hipchat 및 Slack, SendGrid 및 MailChimp와 같은 메일 API, PagerDuty와 같은 중요 자원 인시던트 가능
- 예시) HTTP 응답 상태 코드가 500 이상인 경우 Slack 대화방에 메시지를 보내는 방법
1 | <choose> |
References
Azure Application Insights와 Azure API Management를 통합하는 방법
Event Hubs에 이벤트 기록
References
Azure API Management에서 Azure Event Hubs에 이벤트를 기록하는 방법
트래픽 추적
- Distributed Tracing: Application Insights와 통합하여 API Gateway부터 App Service까지 트랜잭션을 추적 가능하다.
- Integration with Azure Front Door: 전 세계적으로 사용자 트래픽을 라우팅하고, 실시간 요청의 경로를 추적한다.
- Latency Monitoring: 각 구간의 응답 시간 및 병목현상을 모니터링할 수 있다.
Azure-API-Management
install_url to use ShareThis. Please set it in _config.yml.