NGINX MSA 디지털 트레이닝 - 4강 : API Gateway
강의 동영상 : https://www.youtube.com/watch?v=LPZqjKp8ra8
원본 동영상 : https://www.youtube.com/watch?v=9f4LUALgyAU
1. API Management
- 특정 API Gateway에 적용되는 정책을 관리.
- 주요 역할
- Policy Management : 특정 API Gateway의 정책을 정의
- Analytics & Monitoring : 어떤 API가 어떻게 활용되는 지 분석 및 Monitoring
- Developer documentation : 어떤 API가 제공되는 지 명시한 Documentation 제공.
2. API Gateway API Request?
API Gateway는 API Management의 부분 집합의 개념으로, Client와 Backend Service사이에 있는 API Management Tool.
주요 역할
- Request routing : Client로부터의 요청 사항을 Backend Service로 전달
- Authentication : 인증 처리
- Rate limiting : Client의 요청을 제한
- Exception handling : 예외 처리
Ex)
- Client로부터 Car나 Person에 대한 요청을 수신, 수신된 요청을 구분해서 Car와 관련있는 Backend Service로 전달, Person에 대한 Backend Service로 전달.
- 각 Backend Service로부터의 응답을 모아 Client로 회신
3. NGINX API Gateway 주요 기능
3-1. TLS Terminsation
주요 사항
Client에서 전달된 HTTPS 요청을 끝내고 Backend Service에 HTTP (혹은 또다른 HTTPS) 요청을 전달 가능
listen 설정에 ssl을 같이 지정 가능.
SSL certificate와 Key는 디스크 에 저장 (NGINX+ 에서는 Key-Value 형태의 in-memory Data 저장소 이용 가능)
TLS 1.3까지 지원.
SSL cipher 지원 : Data 암호화 할 때 사용.
Ex)
server { listen 443 ssl; server_name www.browndwarf.com; ssl_certificate www.browndwarf.com.crt; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ... }
Refer : http://nginx.org/en/docs/http/ngx_http_ssl_module.html
3-2. Request routing
location 설정을 통해 Routing할 Path정의
= : 특정 Path와 일치하면 Routing
~ : Regular Expression에 때라 일치하면 Routing
그 외의 경우에는 설정한 Path로 시작하는 모든 경우에 대해 Routing
Ex)
location = /api/v1/test { proxy_pass http://v1_test_api; } ... location ~ /api/v1/[12][0-9]+ { proxi_pass http://v1-api; } ... location /api/v1/real { proxy_pass http://v1-api; }
3-3. Load Balancing
Ex)
upstream v1-api { server 192.168.10.1:9001; server 192.168.10.2:9001; sticky cookie srv_id expires=1h; }
- Round Robin 방식으로 2개의 서버로 Request가 전달이 되게 설정
- sticky session을 설정해 처음 연결된 서버로 1시간 동안 계속 Routing 시키 도록 설정.
3-4. Rate Limiting
limit_req_zone 설정을 통해 Rate-Limit 설정
- http context 내에서 설정. 하지만 server context 밖에 설정.
- 하나 이상의 Rate Limit 설정 가능. 단, 하나 이상의 Rate Limit 설정을 할 때는 각각의 End-Point들이 어떤 Rate Limit 설정을 사용하는 지 명시하기 위해 limit_req 를 정의해야함.
Ex)
http { ... limit_req_zone $remote_addr zone=zone1:1m rate-5r/m; upstream v1-api { server 192.168.10.1:9001; server 192.168.10.2:9001; sticky cookie srv_id expires=1h; } ... server { ... location /api/v1/real { proxy_pass http://v1-api; limit_req zone=zone1 nodelay; limit_req_status 429; } } }
- 분당 5개의 요청 제한을 두는 zone1을 설정
- /api/v1/real 으로 Request가 올 경우 분당 5개만 처리 가능하고, 그 수를 넘는 요청에 대해서는 Http Status 429를 Return함.
3-5.Client authentication (NGINX+ Only)
JWT를 이용해서 Client Authentication을 수행할 수 있음.
Ex) api_secret.jwt으로 들어온 Token의 유효성을 확인한 후, 유효한 경우 Request를 v1-api로 전달한다.
location /api/vi/real { auth_jwt on; auth_jwt_key_file /etc/nginx/api_secret.jwt ... proxy_pass http://v1-api; }
- auth_jwt : 동영상에서는 jwt 사용을 Enable시킨다는 의미로 'on'을 사용하는데, 공식 문서에서는 Realm을 나타내는 String이나 'off'만 사용하는 것으로 되어있음.
- auth_jwt_jwt_key : JWT의 signature를 검증할 때 사용하는 Key File Path
3-6. Fine-grained access control (NGINX+ Only)
JWT내에 Payload의 값을 이용해 사용자의 권한을 조회하고 이에 따라 명령어 처리 여부를 결정할 수 있음.
Ex) JWT내에 uid라는 권한 정보가 담긴 claim에 따라 요청 처리 여부를 결정 (Private Claim)하고 권한이 있으면 백엔드 Service로 Request를 전달, 없으면 403 오류 Return
location /api/vi/real { auth_jwt on; auth_jwt_key_file /etc/nginx/api_secret.jwt ... if ($jwt_claim_uid = 755) { add_header X-jwt-claim-uid "$jwt_claim_uid" always; add_header X-jwt-status "Redicrected to Backend-API" always; proxy_pass http://v1-api; } if (%jwt_claim_uid != 755) { add_header X-jwt-claim-uid "$jwt_claim_uid" always; add_header X-jwt_status "Invalid user, no redirect" always; return 403 "Forbidden: Not Authorized to Access"; } }
- ex1) $jwt_claim_iss : JWT Token 발급자 (Registered Claim)
- ex2) $jwt_claim_iat : JWT Token 발급 시간 (Registered Claim)