공유 또는 특수 서비스 기능을 게이트웨이 프록시에 오프로드합니다. 이 방법은 서비스 간에 복제하는 대신 게이트웨이에서 클라이언트 연결 TLS 인증서 종료와 같은 교차 커팅 문제를 중앙 집중화하여 애플리케이션 개발을 간소화합니다.
여러 서비스가 인증, 모니터링 또는 프로토콜 변환과 같은 책임을 공유하는 경우 이러한 문제를 단일 게이트웨이로 통합하면 서비스별 구성 오버헤드 및 배포 위험이 줄어듭니다.
컨텍스트 및 문제점
일부 기능은 일반적으로 여러 서비스에서 사용되며 이러한 기능에는 구성, 관리 및 유지 관리가 필요합니다. 모든 애플리케이션 배포와 함께 배포하는 공유 또는 특수 서비스는 관리 오버헤드를 추가하고 배포 오류의 가능성을 높입니다. 해당 기능을 공유하는 모든 서비스에서 공유 기능에 대한 업데이트를 배포해야 합니다.
토큰 유효성 검사, 암호화 및 TLS 인증서 관리와 같은 보안 문제를 해결하려면 팀 구성원이 고도로 특수화된 기술을 갖도록 요구할 수 있습니다. 예를 들어 게이트웨이가 없으면 모든 애플리케이션 인스턴스에서 클라이언트 연결 인증서를 구성하고 배포해야 할 수 있습니다. 해당 만료를 추적하고 해당 인스턴스에서 업데이트, 테스트 및 확인해야 합니다.
인증, 권한 부여, 로깅, 모니터링 또는 제한 과 같은 다른 일반적인 서비스는 많은 배포에서 구현하고 관리하기가 어려울 수 있습니다. 이러한 유형의 기능을 통합하면 오버헤드 및 오류 가능성이 줄어듭니다.
해결 방법
일부 기능을 게이트웨이로 오프로드합니다. 그런 다음 게이트웨이는 백엔드 서비스를 대신하여 클라이언트 대상 인증서 관리, 인증, TLS 종료 처리, 모니터링, 프로토콜 변환, 속도 제한과 같은 공통 관심사를 처리합니다.
다음 다이어그램에서는 인바운드 TLS 연결을 종료하고 공유 기능을 적용하는 게이트웨이를 보여 줍니다. 게이트웨이는 백 엔드 인증서의 유효성을 검사하고 백 엔드 서비스에 대한 별도의 TLS 연결을 통해 트래픽을 다시 암호화합니다.
이 패턴의 이점은 다음과 같습니다.
각 백 엔드 서비스에서 구현하는 대신 인증, 제한 및 요청 로깅과 같은 공유 구성을 중앙 집중화하여 서비스 개발을 간소화합니다. 중앙 집중화는 일관성을 향상시키고 서비스 업그레이드를 보다 간단하게 만듭니다.
전담 팀이 보안과 같은 전문 지식이 필요한 기능을 구현할 수 있도록 허용합니다. 그런 다음 핵심 팀은 애플리케이션 기능에 집중하고, 이러한 전문성이 필요하지만 여러 영역에 걸쳐 공통으로 발생하는 문제는 해당 전문가에게 맡길 수 있습니다.
요청 및 응답 로깅 및 모니터링에 대한 일관성을 제공합니다. 서비스가 올바르게 계측되지 않더라도 게이트웨이는 모니터링 및 로깅의 기준 수준을 제공할 수 있습니다.
탄소 인식 트래픽 관리를 중앙 집중화합니다. 게이트웨이는 실시간 탄소 강도 신호에 따라 캐싱, 속도 제한 및 로깅 동작을 조정할 수 있습니다. Azure API Management 일부 지역 및 클래식 계층(개발자, 기본, 표준 및 프리미엄)에서 제한된 미리 보기로 이러한 기능을 제공합니다. 가용성 및 구성 세부 정보는 Azure API Management 환경적으로 지속 가능한 API를 참조하세요.
정적 기존 URL에서 새 URL로의 매핑을 처리합니다. 게이트웨이는 백엔드를 호출하지 않고 리디렉션을 반환하여 각 서비스의 요청 파이프라인에서 레거시 URL 처리를 배제할 수 있습니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
고가용성 및 복원력. 게이트웨이가 높은 가용성을 유지하고 오류에 대해 복원력을 가지는지 확인합니다. 게이트웨이의 여러 인스턴스를 실행하여 단일 실패 지점을 방지합니다. 게이트웨이는 클라이언트 연결을 종료하고 요청 본문을 버퍼링할 수 있으므로 인스턴스 실패 시 플라이트 내 요청이 처리되는 방법을 고려합니다. 게이트웨이 인스턴스를 제거하거나 다시 시작해도 활성 세션이 삭제되지 않도록 연결 드레이닝 또는 정상 종료 메커니즘을 사용합니다.
용량 및 크기 조정. 게이트웨이가 애플리케이션 및 엔드포인트의 용량 및 크기 조정 요구 사항에 맞게 설계되었는지 확인합니다. 게이트웨이가 애플리케이션에 대한 병목 상태가 되지 않고 충분히 확장 가능한지 확인합니다. 게이트웨이는 평균 부하뿐만 아니라 최대 트래픽 버스트를 처리하도록 프로비전되어야 합니다. 비용을 줄이기 위해 게이트웨이를 과소 프로비전하면 그 뒤에 있는 모든 서비스의 성능이 직접 저하됩니다.
범위를 오프로드합니다. 여러 서비스 또는 경로에서 공유되는 기능을 중앙 집중화할 때 오프로드하면 중복된 구현 및 관리가 줄어듭니다.
리디렉션 일치 확인 의도한 레거시 URL만 일치시키고 일치하지 않는 요청에 대한 일반 라우팅을 유지합니다. 애플리케이션에서 비즈니스 상태 또는 애플리케이션별 권한 부여에 따라 달라지는 리디렉션을 유지하세요. 관련 지침은 콘텐츠가 이동할 때 링크 유지를 참조하세요.
비즈니스 논리 분리. 비즈니스 논리를 게이트웨이로 오프로드하지 마세요.
트랜잭션 추적. 트랜잭션을 추적해야 할 경우 로깅을 위한 상관 관계 ID를 생성하는 것이 좋습니다.
지연 시간 오버헤드. 게이트웨이는 모든 요청에 네트워크 홉을 추가합니다. TLS 종료, 인증 또는 요청 검사와 같이 게이트웨이가 수행하는 각 오프로드된 함수는 처리 시간을 요청 경로에 추가합니다. 게이트웨이 연결 풀링 및 백 엔드 서비스에 대한 연결 유지는 각 요청에 대해 새 연결을 설정하는 대신 연결을 다시 사용하여 대기 시간 비용을 부분적으로 상쇄할 수 있습니다. 게이트웨이 홉과 오프로드된 함수의 결합된 대기 시간이 워크로드의 성능 목표에 허용되는지 여부를 평가합니다.
운영 복잡성. 중앙 집중식 게이트웨이는 관리를 통합하지만 운영 책임도 집중합니다. 공유 관심사로 게이트웨이 구성, 인증서 수명 주기, 정책 업데이트 및 버전 업그레이드를 관리해야 합니다. 게이트웨이를 담당하는 팀이 게이트웨이에 의존하는 모든 서비스의 규모로 관리할 수 있는 용량과 도구를 가지고 있는지 확인합니다.
보안에 영향을 줍니다. 게이트웨이는 인증, TLS 종료 및 요청 검사와 같은 교차 절단 보안 기능을 중앙 집중화하기 때문에 높은 가치의 대상입니다. 게이트웨이의 손상은 모든 다운스트림 서비스를 노출할 수 있습니다. 게이트웨이를 강화하고, 관리 화면을 제한하고, 게이트웨이가 보호하는 백 엔드 서비스와 독립적으로 비정상적인 동작을 모니터링합니다.
게이트웨이 바이패스 방지. 의도한 게이트웨이 경로를 통해서만 요청을 수락하도록 백 엔드 서비스를 구성합니다. 그렇지 않으면 클라이언트는 백 엔드에 직접 연결하고 게이트웨이에서 인증, 제한, 요청 검사 및 로깅을 바이패스할 수 있습니다.
ID 정보 전파. 각 백 엔드가 원래 호출자, 게이트웨이의 워크로드 ID 또는 둘 다에 권한을 부여할지 여부를 정의합니다. 백 엔드에 위임된 사용자 컨텍스트가 필요한 경우에만 호출자 토큰 또는 신뢰할 수 있는 클레임을 유지합니다. 항상 백 엔드에 대한 게이트웨이를 별도로 인증합니다. 확인되지 않은 전달 헤더를 ID 증명으로 취급하지 마세요.
TLS 유지 관리. 게이트웨이가 TLS를 종료하는 경우 TLS를 백 엔드로 다시 설정합니다. 암호화되지 않은 HTTP를 통해 트래픽을 전달하지 마세요. 모든 네트워크를 신뢰할 수 없는 네트워크로 처리합니다. 이 토폴로지에서는 백 엔드 인증서를 발급, 회전 및 해지하는 프로세스가 여전히 필요합니다.
전달된 헤더 및 클라이언트 컨텍스트입니다. 게이트웨이가 클라이언트 연결을 종료하고 백 엔드 서비스에 대한 새 연결을 설정하면 게이트웨이가 명시적으로 전달하지 않는 한 클라이언트 IP 주소, 원래 프로토콜 및 호스트 이름과 같은 정보가 손실됩니다. 완화 전략은 역방향 프록시와 백 엔드 웹 애플리케이션 간에 원래 HTTP 호스트 이름 유지를 참조하세요.
이 패턴을 사용하는 경우
다음과 같은 경우 이 패턴을 사용합니다.
- 애플리케이션 배포에는 TLS 인증서 또는 암호화와 같은 공유 문제가 있습니다.
- 애플리케이션 배포에서 공통적인 기능에는 메모리 리소스, 스토리지 용량 또는 네트워크 연결과 같은 리소스 요구 사항이 다를 수 있습니다.
- 네트워크 보안, 제한 또는 기타 네트워크 경계 문제와 같은 문제에 대한 책임을 보다 특수한 팀으로 이동하려고 합니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
- 게이트웨이는 게이트웨이 구성 변경 내용에 백 엔드 서비스 변경 내용을 긴밀하게 결합하는 서비스별 논리 또는 라우팅 규칙을 포함해야 합니다. 게이트웨이 계층을 내부 서비스와 결합하면 백 엔드 업데이트가 게이트웨이를 강제로 다시 배포하여 배포 독립성 감소가 가능합니다.
- 오프로드된 작업은 경량이며, 워크로드는 지연 시간에 민감합니다. 오버헤드가 중앙 집중화의 이점보다 클 때 게이트웨이를 통한 추가 네트워크 홉이 정당화되지 않을 수 있습니다.
- 공유 게이트웨이로 문제를 중앙 집중화하면 변경 관리 병목 현상이 발생합니다. 게이트웨이 팀의 릴리스 주기가 서비스 팀보다 느린 경우 오프로드하면 인증서, 인증 정책 또는 네트워크 규칙에 대한 업데이트가 지연될 수 있습니다.
워크로드 디자인
설계자는 게이트웨이 오프로드 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 다음은 그 예입니다.
| 핵심 요소 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다. | 이 책임을 게이트웨이에 오프로드하면 백 엔드 노드에서 애플리케이션 코드의 복잡성이 줄어듭니다. 어떤 경우에는 오프로드가 기능을 신뢰할 수 있는 플랫폼 제공 기능으로 완전히 대체합니다. - RE:01 단순성 및 효율성 |
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 요청 흐름에 게이트웨이를 추가하면 웹 애플리케이션 방화벽 및 클라이언트 TLS 정책과 같은 컨트롤을 중앙 집중화할 수 있습니다. 플랫폼에서 제공하는 오프로드된 모든 기능은 이미 향상된 보안을 제공합니다. - SE:06 네트워크 컨트롤 - SE:08 강화 리소스 |
| 비용 최적화는 워크로드의 투자 수익률을 유지하고 개선하는 데 중점을 둡니다. | 이 패턴을 사용하면 노드당 지출되는 리소스의 비용을 게이트웨이 구현으로 리디렉션할 수 있습니다. 중앙 집중식 처리 모델의 비용은 분산 모델의 비용보다 낮은 경우가 많습니다. - CO:14 통합 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 이 패턴에서 오프로드된 기능의 구성 및 유지 관리는 여러 노드에서 관리를 요구하는 대신 단일 지점과 연결됩니다. 이 중앙 집중화는 교차 절단 문제가 적용되는 방식을 표준화하여 루틴 및 임시 운영 변경을 일관되고 예측 가능하게 만듭니다. - OE:02 작업 표준화 |
| 성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다. | 요청 프로세스에 오프로드 게이트웨이를 추가하면 기능이 게이트웨이에서 중앙 집중화되기 때문에 노드당 더 적은 리소스를 사용할 수 있습니다. 애플리케이션 코드와 독립적으로 오프로드된 기능의 구현을 최적화할 수 있습니다. 오프로드된 플랫폼 제공 기능은 이미 높은 성능을 발휘할 가능성이 높습니다. - PE:03 서비스 선택 |
이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.
Example
Azure Application Gateway WAF_v2 지역 웹 애플리케이션에 대해 이 패턴을 구현할 수 있습니다. 게이트웨이는 클라이언트 TLS 연결을 종료하고 WAF 및 라우팅 정책을 적용하며 백 엔드 서비스에 대한 새 TLS 연결을 설정합니다. 이 설계는 공통 요청 처리 로직을 백엔드 애플리케이션 코드에서 분리합니다.
TLS 오프로드가 있는 Application Gateway
다음 다이어그램에서는 Application Gateway가 인바운드 TLS 연결을 종료하고, 트래픽을 검사 및 필터링하고, TLS를 통해 백 엔드 풀로 전달하기 전에 트래픽을 다시 암호화하는 방법을 보여 줍니다.
이 아키텍처는 다음 Application Gateway 구성 요소를 사용하여 공유 기능을 오프로드하고 백 엔드 트래픽을 다시 암호화합니다.
- HTTPS 수신기입니다. 포트 443의 HTTPS 수신기는 클라이언트의 인바운드 TLS 연결을 허용합니다.
- TLS 인증서입니다. Azure Key Vault 원본인 PFX 인증서가 HTTPS 수신기에 연결됩니다. Application Gateway는 인바운드 트래픽의 암호를 해독하여 검사하고 라우팅한 다음 백 엔드 풀로 다시 암호화합니다. 백 엔드 서버에는 다시 암호화된 연결에 대한 인증서가 여전히 필요하지만 대부분의 경우 플랫폼 관리형 인증서를 사용할 수 있습니다.
- 백 엔드 풀. 백 엔드 풀은 다시 암호화된 트래픽을 수신하는 HTTPS 서버 집합을 정의합니다. 백 엔드 대상은 가상 머신, Azure Virtual Machine Scale Sets, IP 주소 또는 Azure App Service 인스턴스일 수 있습니다. 클라이언트가 직접 연결하여 Application Gateway 및 해당 WAF 정책을 바이패스할 수 없도록 백 엔드 액세스를 제한합니다.
- 백 엔드 HTTP 설정입니다. 백 엔드 프로토콜을 HTTPS로 설정하고 포트를 백 엔드의 TLS 포트(예: 443)로 설정합니다. 백 엔드 인증서와 일치하는 인증서 신뢰 및 호스트 이름을 구성합니다. 프라이빗 인증 기관의 경우 신뢰할 수 있는 루트 인증서를 구성합니다. 자세한 내용은 v2 SKU를 사용하는 엔드투엔드 TLS를 참조하세요.
- 라우팅 규칙입니다. 요청 라우팅 규칙은 수신기를 백 엔드 풀 및 백 엔드 HTTP 설정과 연결합니다. 경로 기반 규칙은 다른 URL 경로를 다른 백 엔드 풀로 라우팅할 수 있습니다.
- WAF 정책. 이 정책은 지오매치 규칙을 포함하여 요청을 검사하는 데 사용되는 관리 및 사용자 지정 규칙을 정의합니다.
Application Gateway는 트래픽의 암호를 해독하기 때문에 지능형 라우팅에 대한 요청 콘텐츠를 검사하고, HTTP 헤더 및 URL을 다시 작성하고, WAF 규칙을 적용할 수 있습니다. 그런 다음 백 엔드에 요청을 전달하기 전에 트래픽을 다시 암호화합니다.
구성 지침은 Application Gateway를 사용한 엔드투엔드 TLS 암호화를 참조하세요.
기술 지원
다음 Azure 서비스는 이 패턴을 구현하는 데 도움이 될 수 있습니다.
지역 웹 트래픽에 Application Gateway 를 사용합니다.
AKS 워크로드에 Kubernetes 네이티브 인그레스를 위해 Azure Application Gateway for Containers를 사용하세요.
전역 또는 다중 지역 웹 트래픽에는 Azure Front Door를 사용합니다.
인증, 제한, 변환 및 모니터링과 같은 API 관련 문제에 Azure API Management 사용합니다.