적용 대상: 모든 API Management 계층
마이크로 서비스는 API를 빌드하는 데 적합합니다. AKS(Azure Kubernetes Service)를 사용하여 클라우드에서 마이크로 서비스 기반 아키텍처를 신속하게 배포하고 운영할 수 있습니다. 그런 다음 Azure API Management 를 사용하여 내부 및 외부 사용을 위해 마이크로 서비스를 API로 게시할 수 있습니다. 이 문서에서는 API Management를 사용하여 AKS 마이크로 서비스 기반 아키텍처를 API로 게시하는 옵션을 설명합니다. Kubernetes, API Management 및 Azure 네트워킹에 대한 기본 지식을 가정합니다.
배경
마이크로 서비스를 소비용 API로 게시하는 경우 마이크로 서비스와 마이크로 서비스를 사용하는 클라이언트 간의 통신을 관리하기가 어려울 수 있습니다. 횡단 관심사에는 인증, 인가, 제어, 캐시 저장, 변환 및 모니터링이 포함됩니다. 이러한 문제는 마이크로 서비스가 내부 또는 외부 클라이언트에 노출되는지 여부에 관계없이 적용됩니다.
API 게이트웨이 패턴은 이러한 문제를 해결합니다. API 게이트웨이는 마이크로 서비스의 현관 역할을 하며, 마이크로 서비스에서 클라이언트를 분리하고, 또 다른 보안 계층을 추가하고, 교차 절단 문제를 처리하는 부담을 제거하여 마이크로 서비스의 복잡성을 줄입니다.
API Management는 API 게이트웨이 요구 사항을 해결하는 턴키 솔루션입니다. 마이크로 서비스에 대한 일관된 최신 게이트웨이를 신속하게 만들고 API로 게시할 수 있습니다. 전체 수명 주기 API 관리 솔루션으로 API 검색, API 수명 주기 관리 및 API 분석을 위한 셀프 서비스 개발자 포털을 비롯한 추가 기능도 제공합니다.
AKS 및 API Management는 함께 사용되는 경우 마이크로 서비스 기반 API를 배포, 게시, 보호, 모니터링 및 관리하기 위한 플랫폼을 제공합니다. 이 문서에서는 API Management와 함께 AKS를 배포하기 위한 몇 가지 옵션을 설명합니다.
Kubernetes 서비스 및 API
Kubernetes 클러스터에서 컨테이너는 Pod에 배포되며,이는 임시이며 수명 주기를 포함합니다. 작업자 노드가 실패하면 노드에서 실행되는 Pod가 손실됩니다. 따라서 Pod의 IP 주소는 언제든지 변경할 수 있습니다. 그것에 의존하여 pod와 통신할 수 없습니다.
이 문제를 해결하기 위해 Kubernetes는 서비스개념을 도입했습니다. Kubernetes Service는 Pod의 논리적 그룹을 정의하고 해당 Pod에 대한 외부 트래픽 노출, 부하 분산 및 서비스 검색을 가능하게 하는 추상화 계층입니다.
API Management를 사용하여 마이크로 서비스를 API로 게시할 준비가 되면 Kubernetes의 서비스를 API Management의 API에 매핑하는 방법을 고려해야 합니다. 이 매핑에 대한 설정된 규칙은 없습니다. 비즈니스 기능 또는 도메인을 처음부터 마이크로 서비스로 디자인하고 분할하는 방법에 따라 달라집니다. 예를 들어 서비스 뒤의 Pod가 지정된 리소스(예: Customer)의 모든 작업을 담당하는 경우 서비스를 하나의 API에 매핑할 수 있습니다. 리소스에 대한 작업이 여러 마이크로 서비스(예: GetOrder 및 PlaceOrder)로 분할되는 경우 여러 서비스를 API Management의 단일 API로 집계할 수 있습니다. (다음 다이어그램을 참조하세요.)
매핑도 향상될 수도 있습니다. API Management는 마이크로 서비스 앞에 외관을 만들므로 시간이 지남에 따라 마이크로 서비스를 리팩터링하고 크기를 조정할 수 있습니다.
AKS 앞에 API Management 배포
AKS 클러스터 앞에 API Management를 배포하는 몇 가지 옵션이 있습니다.
AKS 클러스터는 항상 가상 네트워크에 배포되지만 API Management 인스턴스가 반드시 가상 네트워크에 배포되는 것은 아닙니다. API Management가 클러스터 가상 네트워크 내에 있지 않은 경우 AKS 클러스터는 연결할 API Management에 대한 공용 엔드포인트를 게시해야 합니다. 이 경우 API Management와 AKS 간의 연결을 보호해야 합니다. 즉, API Management를 통해서만 클러스터에 액세스할 수 있는지 확인해야 합니다. 다음 섹션에서는 AKS 앞에 API Management를 배포하는 옵션에 대해 설명합니다.
옵션 1: 서비스를 공개적으로 노출
NodePort, LoadBalancer 또는 ExternalName 서비스 유형을 사용하여 AKS 클러스터에서 서비스를 공개적으로 노출할 수 있습니다. 이렇게 하면 공용 인터넷에서 직접 서비스에 액세스할 수 있습니다. 클러스터 앞에 API Management를 배포한 후에는 마이크로 서비스에서 인증을 적용하여 모든 인바운드 트래픽이 API Management를 통과하도록 해야 합니다. 예를 들어 API Management는 클러스터에 대한 각 요청에 액세스 토큰을 포함할 수 있습니다. 각 마이크로 서비스는 요청을 처리하기 전에 토큰의 유효성을 검사해야 합니다.
이 옵션은 AKS 앞에 API Management를 배포하는 가장 쉬운 방법을 제공할 수 있습니다. 특히 마이크로 서비스에 인증 논리가 이미 구현되어 있는 경우 더욱 그렇습니다.
장점:
- API Management를 클러스터 가상 네트워크에 삽입할 필요가 없으므로 API Management 쪽에서 쉽게 구성
- 서비스가 이미 공개적으로 노출되었으며 마이크로 서비스에 인증 논리가 이미 존재하는 경우 AKS 쪽이 변경되지 않습니다
단점:
- 엔드포인트의 공개 가시성으로 인해 잠재적인 보안 위험을 만듭니다.
- 인바운드 클러스터 트래픽에 대한 단일 진입점을 만들지 않습니다.
- 중복 인증 논리를 사용하여 마이크로 서비스를 복잡하게 함
옵션 2: 인그레스 컨트롤러 설치
옵션 1이 더 쉬울 수 있지만 앞에서 설명한 것처럼 주목할 만한 단점이 있습니다. API Management 인스턴스가 클러스터 가상 네트워크에 상주하지 않는 경우 mTLS(상호 TLS 인증)는 API Management 인스턴스와 AKS 클러스터 간의 양방향에서 트래픽이 안전하고 신뢰할 수 있도록 하는 강력한 방법입니다.
상호 TLS 인증은 기본적으로 API Management에서 지원됩니다 . 수신 컨트롤러를 설치하여 Kubernetes에서 그것을 사용하도록 설정할 수 있습니다. (다음 다이어그램을 참조하세요.) 결과적으로, 인증은 마이크로 서비스를 간소화하는 수신 컨트롤러에서 수행됩니다. 또한 전용 IP 주소를 지원하는 서비스 계층에서 API Management의 IP 주소를 수신 허용 목록에 추가하여 API Management만 클러스터에 액세스할 수 있도록 할 수 있습니다.
장점:
- API Management를 클러스터 가상 네트워크에 삽입할 필요가 없고 mTLS가 기본적으로 지원되므로 API Management 쪽에서 쉽게 구성할 수 있습니다.
- 수신 컨트롤러 계층에서 인바운드 클러스터 트래픽에 대한 보호를 중앙 집중화합니다.
- 공개적으로 표시되는 클러스터 엔드포인트를 최소화하여 보안 위험 감소
단점:
- 수신 컨트롤러를 설치, 구성 및 유지 관리하고 mTLS에 사용되는 인증서를 관리해야 하므로 클러스터 구성의 복잡성이 증가합니다.
- API Management Standard v2 또는 프리미엄 계층을 사용하지 않는 한 수신 컨트롤러 엔드포인트의 공개 가시성으로 인해 보안 위험이 추가됩니다.
API Management를 통해 API를 게시하는 경우 구독 키를 사용하여 해당 API에 대한 액세스를 쉽고 일반적으로 보호합니다. 게시된 API를 사용해야 하는 개발자는 이러한 API에 호출 시 HTTP 요청에 유효한 구독 키를 포함해야 합니다. 그렇지 않으면 API Management 게이트웨이에서 호출을 즉시 거부합니다. 백 엔드 서비스로 전달되지 않습니다.
API에 액세스하기 위한 구독 키를 얻으려면 개발자에게 구독이 필요합니다. 구독은 일반적으로 구독 키 쌍의 이름을 지정한 컨테이너입니다. 게시된 API를 사용해야 하는 개발자는 구독을 가져올 수 있습니다. API 게시자의 승인이 필요하지 않습니다. 또한 API 게시자는 API 소비자를 위해 직접 구독을 만들 수도 있습니다.
옵션 3: 클러스터 가상 네트워크 내에 API Management 배포
경우에 따라 규정 제약 조건 또는 엄격한 보안 요구 사항이 있는 고객은 공개적으로 노출된 엔드포인트로 인해 옵션 1과 2가 불가능할 수 있습니다. 다른 경우에는 AKS 클러스터와 마이크로 서비스를 사용하는 애플리케이션이 동일한 가상 네트워크 내에 있을 수 있으므로 모든 API 트래픽이 가상 네트워크 내에 남아 있기 때문에 클러스터를 공개적으로 노출할 이유가 없습니다. 이러한 시나리오에서는 클러스터 가상 네트워크에 API Management를 배포할 수 있습니다. API Management 개발자, 프리미엄 및 프리미엄 v2(미리 보기) 계층은 클러스터 가상 네트워크에 대한 주입을 지원합니다.
API Management를 가상 네트워크에 배포하는 두 가지 모드는 외부 및 내부입니다. 현재 외부 모드는 API Management의 클래식 계층에서만 사용할 수 있습니다.
API 소비자가 클러스터 가상 네트워크에 상주하지 않는 경우 외부 모드를 사용해야 합니다. (다음 다이어그램을 참조하세요.) 이 모드에서는 API Management 게이트웨이가 클러스터 가상 네트워크에 삽입되지만 외부 부하 분산 장치를 통해 공용 인터넷에서 액세스할 수 있습니다. 이 아키텍처는 외부 클라이언트가 마이크로 서비스를 사용할 수 있도록 허용하면서 클러스터를 완전히 숨기는 데 도움이 됩니다. 또한 NSG(네트워크 보안 그룹)와 같은 Azure 네트워킹 기능을 사용하여 네트워크 트래픽을 제한할 수 있습니다.
모든 API 소비자가 클러스터 가상 네트워크 내에 있는 경우 내부 모드를 사용할 수 있습니다. (다음 다이어그램을 참조하세요.) 이 모드에서는 API Management 게이트웨이가 클러스터 가상 네트워크에 삽입되고 내부 부하 분산 장치를 통해 이 가상 네트워크 내에서만 액세스할 수 있습니다. 공용 인터넷에서 API Management 게이트웨이 또는 AKS 클러스터에 연결할 수 있는 방법은 없습니다.
AKS 클러스터는 두 경우 모두 공개적으로 표시되지 않습니다. 옵션 2와 달리 수신 컨트롤러는 필요하지 않을 수 있습니다. 시나리오와 구성에 따라 API Management와 마이크로 서비스 사이에 인증을 계속해야 할 수 있습니다. 예를 들어 서비스 메시를 사용하는 경우 항상 상호 TLS 인증이 필요합니다.
장점:
- AKS 클러스터에 퍼블릭 엔드포인트가 없으므로 가장 안전한 옵션을 제공합니다.
- 공용 엔드포인트가 없으므로 클러스터 구성 간소화
- 내부 모드를 사용하여 가상 네트워크 내에서 API Management와 AKS를 모두 숨길 수 있는 기능을 제공합니다.
- NSG와 같은 Azure 네트워킹 기능을 사용하여 네트워크 트래픽을 제어하는 기능을 제공합니다.
단점:
- 가상 네트워크 내에서 작동하도록 API Management를 배포하고 구성하는 복잡성이 증가합니다.