AWS 환경에서 Audi, NGINX Plus API Gateway로 마이크로서비스 Dashboard 구축 사례

AWS 환경에서 Audi의 개발자이자 웹 솔루션 아키텍트인 Timo Stark는 자동차 회사가 마이크로서비스로의 여정에서 어떻게 0에서 60으로 변화했는지 공유했습니다. 1년도 채 되지 않아 그의 팀은 Audi 직원이 업무에 사용하는 모든 내부 앱에 액세스할 수 있는 Dashboard인 Audi Cockpit을 구축했습니다. Timo는 NGINX Plus가 API Gateway 역할을 하는 방법을 자세히 설명합니다. Dashboard는 Kubernetes로 관리되는 컨테이너에서 AWS에서 호스팅되는 마이크로서비스를 사용합니다.

Timo Stark

목차

1. 주요 요점
2. 다중 인증(MFA) 및 권한 부여 체계 지원
3. 갱신 토큰(Token)의 올바른 처리
4. API를 위한 “Macro-Design” 정의
5. SNI(Server Name Indication) 사용
6. AWS에서 앱 인스턴스 자동 확장

1. 주요 요점

  • 클라이언트 측에 새로 고침 토큰을 저장하지 마십시오. 요청 헤더에 암호화되지 않은 사용자 ID와 비밀번호를 포함하는 것과 같습니다. Timo는 이를 처리하기 위해 NGINX Plus의 JavaScript 모듈을 활용하는 마이크로서비스를 작성했습니다.
  • API Gateway를 배포하기 전에 Timo가 API에 대해 “macro‑design”라고 부르는 것을 정의합니다. 특히 요청 URI의 어떤 요소가 요청이 라우팅되는 서비스를 나타내는지 결정합니다.
  • HTTPS를 사용하는 경우 SNI(Server Name Indication)를 사용하도록 설정합니다. 그렇지 않으면 Kubernetes Ingress Controller는 클라이언트가 요청을 보낸 호스트 이름을 볼 수 없습니다.
  • NGINX Plus의 nginx-asg-sync 통합 소프트웨어를 사용하여 AWS 오토 스케일링 그룹의 로드 밸런싱을 수행합니다. 이 도구는 AWS 오토 스케일링 그룹의 업스트림 서비스를 모니터링하고 프로세스를 다시 시작하지 않고 동적으로 구성합니다.
NGINX Plus Load Balancing for AWS Auto Scaling Groups

2. 다중 인증(MFA) 및 권한 부여 체계 지원

Audi Cockpit을 가볍고, 빠르고, 안정적이고, 유연하며, 안전한 것으로 만드는 것이 가장 중요한 목표였습니다. 마지막은 단순성과 안정성을 위해 클라이언트가 앱에 액세스하는 방식에 관계없이 Backend 앱에 대한 요청(Request)이 동일하게 표시되어야 하기 때문에 특별한 과제였습니다. 그러나 Cockpit은 각각 고유한 URL과 인증/허가 체계를 가진 세 가지 접근 방식을 지원합니다.

  • React.js로 작성된 Frontend 브라우저 앱을 통해 https://yourhost.com에 액세스할 수 있습니다. OpenID Connect 인증 코드 부여(또는 인증 코드 흐름이)로 보호됩니다.
  • API는 https://api.yourhost.com에 액세스합니다. OpenID Connect beare token으로 보호됩니다.
  • 모바일 장치는 https://m.api.yourhost.com에 액세스합니다. CA Technologies API Gateway(OpenID Connect를 지원하지 않음) 및 ID 공급자 Keycloak의 토큰(Token)으로 보호됩니다.

Timo가 설명하듯이, NGINX Plus를 API Gateway로 사용하는 것은 세 가지 다른 체계를 지원하고 Backend 서비스를 불투명하게 만드는 것을 가능하게 합니다. “인텔리전스는 [the] 헤더 필드를 만들고, 토큰(Token)을 사용하여 사용자가 어디에서 왔는지에 관계없이 Backend의 API가 이해할 수 있는 구조를 만듭니다.”

OpenID Connect and 3rd Party

3. 갱신 토큰(Token)의 올바른 처리

Frontend 브라우저는 또 다른 보안 문제를 제시했습니다. 최적의 보안을 위해 브라우저 사용자에게 제공되는 액세스 토큰(Access Token)은 5분 후 만료됩니다. 그러나 최상의 사용자 환경을 위해 사용자가 5분마다 다시 로그인하거나 브라우저 페이지를 새로 고침을 원하지 않습니다. 이러한 상충되는 요구 사항을 지원하기 위해 Audi Cockpit은 12시간의 수명을 가지며 현재 Access Token이 만료될 때 새 Access Token을 얻는 데 사용할 수 있는 갱신 토큰(Token)을 사용합니다.

그러나 Timo가 강조하듯이, “클라이언트 측에 갱신 토큰(Token)을 저장하는 것은 결코 좋은 생각이 아닙니다. 갱신 토큰(Token)을 사용하면 유효한 기간 동안 원하는 만큼의 Access Token을 다시 만들 수 있습니다. 이것은(클라이언트 측에 저장)은 사용자 이름과 암호를 클라이언트 측에 있는 일반 텍스트로 쿠키(Cookie)에 저장하는 것과 같습니다. 당신은 절대 이런 짓을 하지 않을 겁니다.”

이 문제를 해결하기 위해 Timo는 토큰 서비스를 만들었습니다. NGINX JavaScript 모듈을 사용하여 NGINX Plus는 클라이언트의 갱신 토큰(Token)을 Timo가 작성한 Backend 마이크로서비스로 전송하여 새로운Access Token에 대한 내부 서브 요청을 합니다.

token-service_useful-for-spa

4. API를 위한 “Macro-Design” 정의

Timo는 API를 배포하기 전에 API를 “macro‑design”라고 부르는 것을 정의하는 것이 중요하다고 강조합니다. 특히, 요청 URL의 어떤 요소를 결정하면 Kubernetes Ingress Controller가 요청을 Backend 애플리케이션으로 라우팅(Routing)하는 방법이 결정됩니다. Audi Cockpit의 경우 URL에서 네 번째 요소로, 다음 예에서 주황색으로 강조 표시됩니다.

https://api.yourhost.com/api/v1/activities/activity?page=25
https://m.api.yourhost.com/api/v1/tokens/

예를 들어, activity?page=25와 같은 후속 요소는 애플리케이션 자체에 제공되는 매개 변수입니다.

5. SNI(Server Name Indication) 사용

Audi Cockpit에 대한 Kubernetes Ingress Controller의 요청 라우팅 규칙은 호스트 이름(yourhost.com, api.yourhost.com 및 m.api.yourhost.com)을 기반으로 합니다. Audi는 TLS를 사용하여 클라이언트에서 Backend 서버로의 전체 이동 경로를 따라 트래픽을 보호하기 때문에 요청 서버 호스트 이름은 암호화되며 Kubernetes Ingress Controller는 SNI(Server Name Indication)가 활성화되지 않는 한 이를 볼 수 없습니다. SNI는 NGINX 및 NGINX Plus Kubernetes용 Ingress Controller를 비롯한 많은 Ingress Controller에서 기본적으로 사용 가능하지만 Ingress 구성에 TLS 인증서를 포함해야 합니다.

tls:
    hosts:
        api.yourhost.com
        secretName: tls-certificate-name

6. AWS에서 앱 인스턴스 자동 확장

Audi Cockpit은 NGINX Plus nginx-asg-sync 패키지를 활용하여 Back 애플리케이션의 AWS 오토 스케일링 그룹을 모니터링하고 수요에 따라 동적으로 쿠버네티스 Worker 수를 조정합니다. 이 패키지를 사용하여 Timo는 이전에 이 용도로 사용되었던 AWS NLB(Network Load Balancer)를 제거할 수 있었습니다.

NGINX Plus를 API Gateway, 로드 밸런서, 리버스 프록시 또는 웹 서버로 사용하고 싶으시면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 당사에 문의하십시오.