다음을 통해 공유

자체 호스팅 게이트웨이 개요

  • 아티클

적용 대상: 개발자 | 프리미엄

자체 호스팅 게이트웨이는 모든 API Management 서비스에 포함된 기본 관리 게이트웨이의 선택적 컨테이너화된 버전입니다. API를 호스팅하는 동일한 환경에 게이트웨이를 배치하는 것과 같은 시나리오에 유용합니다. 자체 호스팅 게이트웨이를 사용하여 API 트래픽 흐름을 개선하고 API 보안 및 규정 준수 요구 사항을 해결합니다.

이 문서에서는 Azure API Management의 자체 호스팅 게이트웨이 기능이 하이브리드 및 다중 클라우드 API 관리를 지원하고, 대략적인 아키텍처를 제공하고, 해당 기능을 강조 표시하는 방법을 설명합니다.

다양한 게이트웨이 제품의 기능에 대한 개요는 API Management의 API 게이트웨이를 참조하세요.

하이브리드 및 멀티클라우드 API 관리

자체 호스팅 게이트웨이 기능은 하이브리드 및 다중 클라우드 환경에 대한 API Management 지원을 확장하고 조직이 Azure의 단일 API Management 서비스에서 온-프레미스 및 클라우드 간에 호스트된 API를 효율적이고 안전하게 관리할 수 있도록 합니다.

자체 호스팅 게이트웨이를 통해 고객은 API를 호스트하는 환경에 컨테이너화된 버전의 API Management 게이트웨이 구성 요소를 유연하게 배포할 수 있습니다. 모든 자체 호스팅 게이트웨이는 페더레이션된 API Management 서비스에서 관리되므로 모든 내부 및 외부 API에서 고객에게 가시성 및 통합 관리 환경을 제공합니다.

각 API Management 서비스는 다음과 같은 주요 구성 요소로 구성됩니다.

  • API로 노출되는 관리 평면은 Azure Portal, PowerShell 및 기타 지원되는 메커니즘을 통해 서비스를 구성하는 데 사용됩니다.
  • API 요청 프록시, 정책 적용 및 원격 분석 수집을 처리해야 하는 게이트웨이(또는 데이터 평면)
  • 개발자가 API를 검색하고, 학습시키고, 온보딩하는 데 사용하는 개발자 포털

기본적으로 이러한 모든 구성 요소는 Azure에 배포되어 API를 구현하는 백 엔드가 호스트되는 위치에 관계없이 모든 API 트래픽(다음 그림에 검은색 실선 화살표로 표시)이 Azure를 통과하게 합니다. 이 모델은 운영 편의성을 제공하는 대가로 대기 시간 증가, 규정 준수 문제를 야기하며, 추가 데이터 전송 요금이 발생하는 경우도 있습니다.

자체 호스팅 게이트웨이가 없는 API 트래픽 흐름

백 엔드 API 구현이 호스트되는 환경에 자체 호스팅 게이트웨이를 배포하면 API 트래픽이 백 엔드 API로 직접 이동하므로 대기 시간이 감소하고, 데이터 전송 비용이 최적화되고, 규정 준수가 지원되며, 구현이 호스트되는 위치에 관계없이 조직 내 모든 API를 한 곳에서 관리하고, 관찰하고, 검색할 수 있는 이점을 유지할 수 있습니다.

자체 호스팅 게이트웨이가 있는 API 트래픽 흐름

패키징

자체 호스팅 게이트웨이는 Microsoft Artifact Registry에서 Linux 기반 Docker 컨테이너 이미지로 사용할 수 있습니다. 이 도구는 온-프레미스, 클라우드 인프라의 서버 클러스터에서 실행되거나 평가 및 개발 목적으로 개인용 컴퓨터에서 실행되는 Docker, Kubernetes 또는 다른 컨테이너 오케스트레이션 솔루션에 배포할 수 있습니다. 자체 호스팅 게이트웨이를 Azure Arc 지원 Kubernetes 클러스터에 클러스터 확장으로 배포할 수도 있습니다.

컨테이너 이미지

요구 사항에 맞게 자체 호스팅 게이트웨이에 대한 다양한 컨테이너 이미지를 제공합니다.

태그 규칙 권장 예시 롤링 태그 프로덕션에 권장되는지 여부
{major}.{minor}.{patch} 이 태그를 사용하여 항상 동일한 버전의 게이트웨이를 실행합니다. 2.0.0 ❌ ✔️
v{major} 이 태그를 사용하여 항상 모든 새로운 기능과 패치를 사용하여 주 버전의 게이트웨이를 실행합니다. v2 ✔️ ❌
v{major}-preview 항상 최신 미리 보기 컨테이너 이미지를 실행하려는 경우 이 태그를 사용합니다. v2-preview ✔️ ❌
latest 자체 호스팅 게이트웨이를 평가하려면 이 태그를 사용합니다. latest ✔️ ❌
beta1 미리 보기 버전의 자체 호스팅 게이트웨이를 평가하려면 이 태그를 사용합니다. beta ✔️ ❌

사용 가능한 태그의 전체 목록은 여기에서 찾을 수 있습니다.

1미리 보기 버전은 공식적으로 지원되지 않으며 실험용으로만 사용됩니다. 자체 호스팅 게이트웨이 지원 정책을 참조하세요.

공식 배포 옵션에서 태그 사용

Azure Portal 배포 옵션은 v2 태그를 사용하여 고객이 모든 기능 업데이트 및 패치와 함께 최신 버전의 자체 호스팅 게이트웨이 v2 컨테이너 이미지를 사용하도록 합니다.

참고 항목

명령 및 YAML 코드 조각을 참조로 제공하므로 원하는 경우 보다 구체적인 태그를 자유롭게 사용하세요.

Helm 차트를 사용하여 설치하면 이미지 태그 지정이 최적화됩니다. Helm 차트의 애플리케이션 버전은 게이트웨이를 지정된 버전에 고정하며 latest를 사용하지 않습니다.

Helm을 사용하여 Kubernetes에 API Management 자체 호스팅 게이트웨이를 설치하는 방법에 대해 자세히 알아봅니다.

롤링 태그 사용의 위험

롤링 태그는 새 버전의 컨테이너 이미지가 릴리스될 때 잠재적으로 업데이트되는 태그입니다. 이를 사용하면 컨테이너 사용자는 배포를 업데이트하지 않고도 컨테이너 이미지에 대한 업데이트를 받을 수 있습니다.

즉, v2 태그가 업데이트된 후 스케일링 작업을 수행하는 경우와 같이 알지 못한 상태로 여러 버전을 병렬로 실행할 수 있습니다.

예제 - v2 태그가 2.0.0 컨테이너 이미지와 함께 릴리스되었지만 2.1.0가 릴리스될 때 v2 태그가 2.1.0 이미지에 연결됩니다.

Important

의도치 않게 최신 버전으로 업그레이드되는 일이 없도록 프로덕션에서 특정 버전 태그를 사용하는 것이 좋습니다.

Azure 연결

자체 호스팅 게이트웨이에는 포트 443의 Azure에 대한 아웃바운드 TCP/IP 연결이 필요합니다. 각 자체 호스팅 게이트웨이는 단일 API Management 서비스와 연결되어야 하며 해당 관리 평면을 통해 구성됩니다. 자체 호스팅 게이트웨이는 다음을 위해 Azure에 대한 연결을 사용합니다.

  • 1분마다 하트비트 메시지를 전송하여 상태 보고
  • 구성 업데이트를 정기적으로 확인하고(10초 간격) 사용할 수 있을 때마다 적용
  • 메트릭을 Azure Monitor에 보내기(보내도록 구성된 경우)
  • 이벤트를 Application Insights로 전송(전송하도록 구성된 경우)

FQDN 종속성

제대로 작동하려면 각 자체 호스팅 게이트웨이는 포트 443에서 클라우드 기반 API Management 인스턴스와 연결된 다음 엔드포인트에 대한 아웃바운드 연결이 필요합니다.

설명 v1에 필요 v2에 필요 주의
구성 엔드포인트의 호스트 이름 <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 사용자 지정 호스트 이름도 지원되며 기본 호스트 이름 대신 사용할 수 있습니다.
API Management 인스턴스의 공용 IP 주소 ✔️ ✔️ 기본 위치의 IP 주소로 충분합니다.
Azure Storage 서비스 태그의 공용 IP 주소 ✔️ 선택 사항2 IP 주소는 API Management 인스턴스의 기본 위치에 해당해야 합니다.
Azure Blob Storage 계정의 호스트 이름 ✔️ 선택 사항2 인스턴스와 연결된 계정(<blob-storage-account-name>.blob.core.windows.net)
Azure Table Storage 계정의 호스트 이름 ✔️ 선택 사항2 인스턴스와 연결된 계정(<table-storage-account-name>.table.core.windows.net)
Azure Resource Manager에 대한 엔드포인트 ✔️ 선택 사항3 필수 엔드포인트는 management.azure.com입니다.
Microsoft Entra 통합을 위한 엔드포인트 ✔️ 선택 사항4 필수 엔드포인트는 <region>.login.microsoft.com 및 login.microsoftonline.com입니다.
Azure Application Insights 통합을 위한 엔드포인트 선택 사항5 선택 사항5 필요한 최소 엔드포인트는 다음과 같습니다.
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Azure Monitor 설명서에서 자세히 알아보기
Event Hubs 통합을 위한 엔드포인트 선택 사항5 선택 사항5 Azure Event Hubs 설명서에서 자세히 알아보기
외부 캐시 통합을 위한 엔드포인트 선택 사항5 선택 사항5 이 요구 사항은 사용 중인 외부 캐시에 따라 달라집니다.

1내부 가상 네트워크의 API Management 인스턴스에 대해서는 내부 가상 네트워크의 연결을 참조하세요.
2API 검사기 또는 할당량이 정책에 사용되는 경우에만 v2에 필요합니다.
3Microsoft Entra 인증을 사용하여 RBAC 권한을 확인하는 경우에만 필요합니다.
4Microsoft Entra 인증 또는 Microsoft Entra 관련 정책을 사용하는 경우에만 필요합니다.
5기능을 사용하고 공용 IP 주소, 포트 및 호스트 이름 정보가 필요한 경우에만 필요합니다.

Important

  • DNS 호스트 이름은 IP 주소로 확인할 수 있어야 하며 해당 IP 주소에 연결할 수 있어야 합니다.
  • 연결된 스토리지 계정 이름은 Azure Portal에서 서비스의 네트워크 연결 상태 페이지에 나열됩니다.
  • 연결된 스토리지 계정의 기본 공용 IP 주소는 동적이며 통지 없이 변경될 수 있습니다.

내부 가상 네트워크의 연결

  • 프라이빗 연결 - 자체 호스팅 게이트웨이가 가상 네트워크에 배포된 경우 피어링된 네트워크의 프라이빗 DNS를 사용하여 자체 호스팅 게이트웨이 위치에서 v2 구성 엔드포인트에 대한 프라이빗 연결을 사용하도록 설정합니다.

  • 인터넷 연결 - 자체 호스팅 게이트웨이가 인터넷을 통해 v2 구성 엔드포인트에 연결해야 하는 경우 구성 엔드포인트에 대한 사용자 지정 호스트 이름을 구성하고 Application Gateway를 사용하여 엔드포인트를 노출합니다.

인증 옵션

자체 호스팅 게이트웨이와 클라우드 기반 API Management 인스턴스의 구성 엔드포인트 간 연결을 인증하기 위해 게이트웨이 컨테이너의 구성 설정에 다음 옵션이 있습니다.

옵션 고려 사항
Microsoft Entra 인증 게이트웨이에 액세스할 수 있도록 하나 이상의 Microsoft Entra 앱 구성

앱마다 개별적으로 액세스 관리

조직의 정책에 따라 비밀 만료 시간을 더 길게 구성

표준 Microsoft Entra 프로시저를 사용하여 앱에 사용자 또는 그룹 권한을 할당하거나 해지하고 비밀 바꾸기
게이트웨이 액세스 토큰(인증 키라고도 함) 토큰이 최대 30일마다 만료되며 컨테이너에서 갱신해야 함

독립적으로 바꿀 수 있는 게이트웨이 키에 의해 지원됨(예: 액세스 권한 해지)

게이트웨이 키를 다시 생성하면 게이트웨이 키를 사용하여 만든 모든 액세스 토큰이 무효화됨

연결 실패

Azure에 대한 연결이 끊기면 자체 호스팅 게이트웨이가 구성 업데이트를 수신하거나, 상태를 보고하거나, 원격 분석을 업로드할 수 없습니다.

자체 호스팅 게이트웨이는 "일시적 장애에도 안정을 유지(fail static)"하도록 설계되었으며 Azure에 대한 연결이 일시적으로 끊겨도 안정을 유지할 수 있습니다. 로컬 구성 백업을 사용하거나 사용하지 않고 배포할 수 있습니다. 구성 백업을 사용하면 자체 호스팅 게이트웨이가 컨테이너 또는 Pod에 연결된 영구 볼륨에 다운로드한 최신 구성의 백업 복사본을 정기적으로 저장합니다.

구성 백업이 해제된 상태에서 Azure에 대한 연결이 중단되는 경우:

  • 실행 중인 자체 호스팅 게이트웨이가 구성의 메모리 내 복사본을 사용하여 계속 작동합니다.
  • 중지된 자체 호스팅 게이트웨이는 시작할 수 없습니다.

구성 백업이 설정된 상태에서 Azure에 대한 연결이 중단되는 경우:

  • 실행 중인 자체 호스팅 게이트웨이가 구성의 메모리 내 복사본을 사용하여 계속 작동합니다.
  • 중지된 자체 호스팅 게이트웨이가 구성의 백업 복사본을 사용하여 시작할 수 있습니다.

연결이 복원되면 가동 중단의 영향을 받는 각 자체 호스팅 게이트웨이가 연결된 API Management 서비스에 자동으로 다시 연결되고 게이트웨이가 "오프라인" 상태였을 때 발생한 모든 구성 업데이트를 다운로드합니다.

보안

제한 사항

관리형 게이트웨이에 있는 다음 기능은 자체 호스팅 게이트웨이에서 사용할 수 없습니다.

  • TLS 세션 재개.
  • 클라이언트 인증서 재협상. 클라이언트 인증서 인증을 사용하려면 API 소비자가 초기 TLS 핸드셰이크의 일부로 인증서를 제시해야 합니다. 이 동작을 확인하려면 자체 호스팅 게이트웨이 사용자 지정 호스트 이름(도메인 이름)을 구성할 때 클라이언트 인증서 협상 설정을 사용하도록 설정합니다.

TLS(전송 계층 보안)

Important

이 개요는 자체 호스팅 게이트웨이 v1과 v2에만 적용됩니다.

지원되는 프로토콜

자체 호스팅 게이트웨이는 기본적으로 TLS v1.2를 지원합니다.

사용자 지정 도메인을 사용하는 고객은 컨트롤 플레인에서 TLS v1.0 및/또는 v1.1을 사용하도록 설정할 수 있습니다.

사용할 수 있는 암호화 도구 모음

Important

이 개요는 자체 호스팅 게이트웨이 v2에만 적용됩니다.

자체 호스팅 게이트웨이는 클라이언트 및 서버 연결 모두에 다음 암호화 도구 모음을 사용합니다.

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

암호화 도구 모음 관리

v2.1.1 이상부터 구성을 통해 사용되는 암호화를 관리할 수 있습니다.

  • net.server.tls.ciphers.allowed-suites를 사용하면 API 클라이언트와 자체 호스팅 게이트웨이 간의 TLS 연결에 사용할 쉼표로 구분된 암호화 목록을 정의할 수 있습니다.
  • net.client.tls.ciphers.allowed-suites를 사용하면 자체 호스팅 게이트웨이와 백 엔드 간의 TLS 연결에 사용할 쉼표로 구분된 암호화 목록을 정의할 수 있습니다.

다음 단계