적용 대상: 개발자 | 프리미엄
자체 호스팅 게이트웨이는 모든 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에 대한 단일 관리 지점, 관찰 가능성 및 검색의 이점을 유지하면서 규정 준수를 가능하게 합니다.
패키징
자체 호스팅 게이트웨이는 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 |
✔️ | ❌ |
beta
1 |
미리 보기 버전의 자체 호스팅 게이트웨이를 평가하려면 이 태그를 사용합니다. | 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 이미지에 연결됩니다.
중요합니다
프로덕션 환경에서 특정 버전 태그를 사용하여 의도치 않게 최신 버전으로 업그레이드하지 않도록 하는 것이 좋습니다.
Azure 연결
자체 호스팅 게이트웨이에는 포트 443의 Azure에 대한 아웃바운드 TCP/IP 연결이 필요합니다. 각 자체 호스팅 게이트웨이는 단일 API Management 인스턴스와 연결되어야 하며 해당 관리 평면을 통해 구성되어야 합니다. 자체 호스팅 게이트웨이는 다음을 위해 Azure에 대한 연결을 사용합니다.
- 1분마다 하트비트 메시지를 전송하여 상태를 보고합니다.
- 사용할 수 있을 때마다 정기적으로(10초마다) 구성 업데이트를 확인하고 적용합니다.
- 이렇게 하도록 구성된 경우 Azure Monitor에 메트릭을 보냅니다.
- 이렇게 하도록 구성된 경우 Application Insights에 이벤트를 보냅니다.
FQDN 종속성
제대로 작동하려면 각 자체 호스팅 게이트웨이는 포트 443에서 클라우드 기반 API Management 인스턴스와 연결된 다음 엔드포인트에 대한 아웃바운드 연결이 필요합니다.
| 엔드포인트 | 필수? | 주의 |
|---|---|---|
| 구성 엔드포인트의 호스트 이름 |
<api-management-service-name>.configuration.azure-api.net
1 |
사용자 지정 호스트 이름도 지원되며 기본 호스트 이름 대신 사용할 수 있습니다. |
| 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 | 필요한 최소 엔드포인트는 rt.services.visualstudio.com:443, dc.services.visualstudio.com:443및 {region}.livediagnostics.monitor.azure.com:443. 자세한 내용은 Azure Monitor 설명서를 참조하세요. |
| Event Hubs 통합을 위한 엔드포인트 | 선택 사항5 | 자세한 내용은 Azure Event Hubs 설명서를 참조하세요. |
| 외부 캐시 통합을 위한 엔드포인트 | 선택 사항5 | 이 요구 사항은 사용 중인 외부 캐시에 따라 달라집니다. |
1내부 가상 네트워크의 API Management 인스턴스에 대한 자세한 내용은 내부 가상 네트워크의 연결을 참조하세요.
2API 검사기 또는 할당량이 정책에 사용되는 경우에만 v2에 필요합니다.
3Microsoft Entra 인증을 사용하여 RBAC 권한을 확인하는 경우에만 필요합니다.
4Microsoft Entra 인증 또는 Microsoft Entra와 관련된 정책을 사용하는 경우에만 필요합니다.
5개기능을 사용하고 공용 IP 주소, 포트 및 호스트 이름 정보가 필요한 경우에만 필요합니다.
중요합니다
- DNS 호스트 이름은 IP 주소로 확인할 수 있어야 하며 해당 IP 주소에 연결할 수 있어야 합니다.
- 연결된 스토리지 계정 이름은 Azure Portal의 서비스 네트워크 연결 상태 페이지에 나열됩니다.
- 연결된 스토리지 계정의 기본 공용 IP 주소는 동적이며 통지 없이 변경될 수 있습니다.
내부 가상 네트워크의 연결
프라이빗 연결. 자체 호스팅 게이트웨이가 가상 네트워크에 배포된 경우 자체 호스팅 게이트웨이의 위치에서 v2 구성 엔드포인트에 대한 프라이빗 연결을 사용하도록 설정합니다(예: 피어된 네트워크의 프라이빗 DNS 사용).
인터넷 연결. 자체 호스팅 게이트웨이가 인터넷을 통해 v2 구성 엔드포인트에 연결해야 하는 경우 구성 엔드포인트에 대한 사용자 지정 호스트 이름을 구성하고 Azure Application Gateway를 사용하여 엔드포인트를 노출합니다.
인증 옵션
게이트웨이 컨테이너의 구성 설정 은 자체 호스팅 게이트웨이와 클라우드 기반 API Management 인스턴스의 구성 엔드포인트 간의 연결을 인증하기 위한 다음 옵션을 제공합니다.
| 옵션 | 고려 사항 |
|---|---|
| Microsoft Entra 인증 | 게이트웨이에 액세스할 수 있도록 하나 이상의 Microsoft Entra 앱을 구성합니다. 앱별로 개별적으로 액세스를 관리합니다. 조직의 정책에 따라 비밀에 대한 더 긴 만료 시간을 구성합니다. 표준 Microsoft Entra 프로시저를 사용하여 앱에 사용자 또는 그룹 권한을 할당하거나 해지하고 비밀을 회전합니다. |
| 게이트웨이 액세스 토큰. (인증 키라고도 함) | 토큰은 적어도 30일마다 만료되며 컨테이너에서 갱신해야 합니다. 독립적으로 회전할 수 있는 게이트웨이 키(예: 액세스 취소)에 의해 지원됩니다. 게이트웨이 키를 다시 생성하면 게이트웨이 키를 사용하여 만든 모든 액세스 토큰이 무효화됩니다. |
팁 (조언)
게이트웨이 액세스 토큰이 거의 만료되거나 만료되었을 때 자체 호스팅 게이트웨이에서 생성되는 Event Grid 이벤트에 대한 자세한 내용은 Event Grid 원본으로 Azure API Management 를 참조하세요. 이러한 이벤트를 사용하여 배포된 게이트웨이가 항상 연결된 API Management 인스턴스로 인증할 수 있는지 확인합니다.
연결 실패
Azure에 대한 연결이 끊기면 자체 호스팅 게이트웨이가 구성 업데이트를 수신하거나, 상태를 보고하거나, 원격 분석을 업로드할 수 없습니다.
자체 호스팅 게이트웨이는 "일시적 장애에도 안정을 유지(fail static)"하도록 설계되었으며 Azure에 대한 연결이 일시적으로 끊겨도 안정을 유지할 수 있습니다. 로컬 구성 백업을 사용하거나 사용하지 않고 배포할 수 있습니다. 구성 백업을 사용하면 자체 호스팅 게이트웨이가 컨테이너 또는 Pod에 연결된 영구 볼륨에 다운로드한 최신 구성의 백업 복사본을 정기적으로 저장합니다.
구성 백업이 해제된 상태에서 Azure에 대한 연결이 중단되는 경우:
- 자체 호스팅 게이트웨이 실행은 구성의 메모리 내 복사본을 사용하여 계속 작동합니다.
- 중지된 자체 호스팅 게이트웨이는 시작할 수 없습니다.
구성 백업이 설정된 상태에서 Azure에 대한 연결이 중단되는 경우:
- 자체 호스팅 게이트웨이 실행은 구성의 메모리 내 복사본을 사용하여 계속 작동합니다.
- 중지된 자체 호스팅 게이트웨이는 구성의 백업 복사본을 사용하여 시작할 수 있습니다.
연결이 복원되면 중단의 영향을 받는 각 자체 호스팅 게이트웨이가 연결된 API Management 인스턴스와 자동으로 다시 연결되고 게이트웨이가 오프라인 상태일 때 발생한 모든 구성 업데이트를 다운로드합니다.
보안
제한 사항
관리되는 게이트웨이에서 사용할 수 있는 다음 기능은 자체 호스팅 게이트웨이에서 사용할 수 없습니다 .
- TLS 세션 재개.
- 클라이언트 인증서 재협상. 클라이언트 인증서 인증을 사용하려면 API 소비자가 초기 TLS 핸드셰이크의 일부로 인증서를 제시해야 합니다. 이 동작을 확인하려면 자체 호스팅 게이트웨이 사용자 지정 호스트 이름(도메인 이름)을 구성할 때 클라이언트 인증서 협상 설정을 사용하도록 설정합니다.
TLS(전송 계층 보안)
지원되는 프로토콜
자체 호스팅 게이트웨이는 기본적으로 TLS v1.2를 지원합니다.
사용자 지정 도메인을 사용하는 경우 컨트롤 플레인에서 TLS v1.0 및/또는 v1.1을 사용하도록 설정할 수 있습니다.
사용할 수 있는 암호화 도구 모음
자체 호스팅 게이트웨이는 클라이언트 및 서버 연결 모두에 다음 암호 그룹을 사용합니다.
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_DHE_RSA_WITH_AES_256_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256TLS_RSA_WITH_AES_128_CBC_SHA256TLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA
암호화 도구 모음 관리
v2.1.1 이상을 사용하면 구성을 통해 사용되는 암호화를 관리할 수 있습니다.
-
net.server.tls.ciphers.allowed-suites를 사용하면 API 클라이언트와 자체 호스팅 게이트웨이 간의 TLS 연결에 사용할 쉼표로 구분된 암호화 목록을 정의할 수 있습니다. -
net.client.tls.ciphers.allowed-suites를 사용하면 자체 호스팅 게이트웨이와 백 엔드 간의 TLS 연결에 사용할 쉼표로 구분된 암호화 목록을 정의할 수 있습니다.
관련 콘텐츠
- API 게이트웨이 개요
- 자체 호스팅 게이트웨이에 대한 지원 정책
- 하이브리드 및 다중 클라우드 세계의 API Management
- 프로덕션 환경에서 Kubernetes에서 자체 호스팅 게이트웨이를 실행하기 위한 지침
- Docker에 자체 호스팅 게이트웨이 배포
- Kubernetes에 자체 호스팅 게이트웨이 배포
- Azure Arc 지원 Kubernetes 클러스터에 자체 호스팅 게이트웨이 배포
- Azure Container Apps에 자체 호스팅 게이트웨이 배포
- 자체 호스팅 게이트웨이 구성 설정
- API Management의 관찰 기능
- 자체 호스팅 게이트웨이와 Dapr 통합