Azure API Management는 하이브리드 및 다중 클라우드를 비롯한 모든 환경에서 API를 위한 관리 플랫폼 및 게이트웨이입니다. PaaS(Platform as a Service) 솔루션인 API Management는 워크로드의 API 수명 주기를 지원합니다.
이 문서에서는 설계자로서 통합 서비스 의사 결정 트리를 검토하고 워크로드에 대한 통합 서비스로 API Management를 선택했다고 가정합니다. 이 문서의 지침은 Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.
중요합니다
이 가이드를 사용하는 방법
각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 중요한 아키텍처 영역을 제공하는 디자인 검사 목록이 있습니다.
또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 API Management 또는 워크로드의 백 엔드 API 서버에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.
주요 권장 사항을 보여 주는 기본 아키텍처: API Management 랜딩 존 아키텍처.
기술 범위
이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.
- Azure API Management
이 가이드의 범위는 주로 게이트웨이 구성 요소(데이터 평면)인 API Management 서비스로, 클라이언트 애플리케이션에서 다양한 플랫폼 또는 크로스-프레미스 위치에서 호스트되는 백 엔드 API로 API 요청을 프록시합니다. 워크로드의 아키텍처는 API Management 컨트롤 플레인 및 게이트웨이에 액세스하는 클라이언트 애플리케이션 및 라우트된 요청을 처리하는 백 엔드 API와 같은 관련 구성 요소를 고려해야 합니다. 또한 네트워킹, 모니터링, ID 관리 및 기타 기능을 비롯한 지원 Azure 서비스를 통합합니다.
이 가이드에서는 Azure API 센터에 대해 다루지 않습니다. API 디자인 고려 사항에 대해 잘 설계된 관점을 제공하는 대신 API Management와 관련된 API 수준 토픽을 다룹니다.
비고
모든 권장 사항이 API Management의 모든 서비스 계층에 적용되는 것은 아닙니다. 이 가이드의 많은 권장 사항은 대부분의 엔터프라이즈 워크로드에 권장되는 프로덕션 계층인 API Management의 표준 v2 및 클래식 프리미엄 계층에 초점을 맞춥니다.
중요합니다
엔터프라이즈 기능이 있는 프리미엄 v2 계층은 미리 보기로 제공됩니다. 디자인이 초기 액세스 기능 또는 일반 공급 기능에 의존해야 하는지 여부를 확인하려면 Premium v2의 릴리스 및 마이그레이션 경로에 대한 사용 가능한 정보와 관련하여 디자인 및 구현 타임라인을 평가합니다.
신뢰도
안정성 핵심 요소의 목적은 충분한 복원력을 구축하고 오류로부터 빠르게 복구할 수 있는 능력을 개발하여 지속적인 운영을 제공하는 것입니다.
안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공합니다.
디자인 검사 목록
안정성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. API Management의 계층 및 기능 및 종속성을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
안정성 및 중복성을 위해 게이트웨이 기능을 평가합니다. 각 환경에 대한 워크로드의 안정성 요구 사항을 충족하는 데 필요한 API Management 계층 및 기능을 결정합니다.
가용성 영역, 여러 게이트웨이 단위, 여러 지역 및 작업 영역을 비롯한 게이트웨이 중복 기능을 평가합니다. 이러한 기능은 모두 프리미엄 계층에서 지원됩니다. SLA(서비스 수준 계약)를 포함하지 않는 개발자 계층은 프로덕션 워크로드에 적합하지 않습니다. 잠재적인 실패 지점 및 성능 병목 상태를 발생시킬 수 있는 외부 캐싱과 같은 기능을 채택할 때의 장단점을 고려합니다.
관찰 기능 검토: Azure Monitor 로그 및 메트릭, Application Insights, 기본 제공 분석 및 기본 제공 진단을 비롯한 서비스의 가시성 기능을 고려합니다. 이러한 기능을 사용하여 워크로드의 안정성 신호를 모니터링합니다.
예를 들어 Azure Monitor 경고를 사용하여 API Management 게이트웨이 또는 해당 종속성에 대한 잠재적인 문제를 알리는 것이 좋습니다.
크기 조정 전략을 검토합니다. 서비스 안정성을 유지하기 위해 단위를 추가하여 게이트웨이 를 확장 하기 위한 조건을 정의합니다. 요청, 예외 또는 둘 다에 따라 크기를 조정할지 여부를 고려합니다. 게이트웨이 구성 요소 크기 조정이 워크로드의 다른 구성 요소에 미치는 영향을 평가합니다. 예를 들어 네트워크 주소 공간 및 백 엔드의 크기 조정 기능에 미치는 영향입니다.
중요한 워크로드 격리: API에서 데이터 주권 또는 성능 최적화와 같은 워크로드 요구 사항을 충족하는 데 컴퓨팅 격리가 필요한지 확인합니다. 중요 API에 전용 게이트웨이를 사용하고 덜 중요한 API의 경우 공유 게이트웨이를 사용합니다.
전용 작업 영역 게이트웨이 또는 별도의 API Management 인스턴스를 사용하는 것과 같은 격리 방법을 선택합니다. 여러 인스턴스의 경우 안전한 배포 방법의 일부로 환경을 동기화된 상태로 유지합니다.
SLO(서비스 수준 목표) 맞춤: 워크로드의 SLO를 설정할 때 게이트웨이의 SLA 범위를 고려합니다. 서비스는 자체 SLA를 제공하지만 API 백 엔드와 같은 다른 워크로드 구성 요소의 예상 안정성도 고려해야 합니다.
백 엔드 오류 해결: 예상된 백 엔드 오류와 예기치 않은 백 엔드 오류를 모두 계획합니다. 이러한 시나리오에서 클라이언트 환경을 테스트합니다. 게이트웨이 정책을 평가하여 복원력을 향상시키고 클라이언트 환경을 향상시킵니다. API 사양에 설명된 대로 할당량, 속도 제한, 재시도 정책, 백 엔드 회로 차단기, 부하 분산 및 예외 처리에 집중합니다.
테스트 전략 정의: 네트워크 내에서 Azure Load Testing 과 같은 테스트 솔루션을 사용하여 실제 프로덕션 워크로드를 반영합니다. 게시된 처리량 또는 워크로드에 적용되지 않을 수 있는 기타 예상치를 사용하지 마세요.
DR(재해 복구) 계획: 게이트웨이 인프라 및 API를 백업하고 복원하기 위한 옵션을 검토합니다. 기본 제공 백업 및 복원 기능은 일부 시나리오에서 유용할 수 있습니다. 그러나 APIOps 도구 및 IaC(Infrastructure as Code) 솔루션과 같은 고객 관리형 옵션도 고려할 수 있습니다. 사용자 구독을 포함하여 다른 시스템 데이터를 유지 관리하기 위한 전략을 개발합니다.
권장 사항
이러한 안정성 권장 사항은 서비스 자체 또는 API 및 해당 정책을 통해 흐르는 트래픽에 적용할 수 있습니다. (서비스) 또는 (API) 지정자는 권장 사항이 서비스 또는 API를 대상으로 하는지 여부를 나타냅니다.
| 추천 | 이익 |
|---|---|
| (서비스) 프리미엄 계층에서 영역 중복성을 사용하도록 설정하고 최소 3개 단위를 배포합니다. 이 구성에서는 정상적인 작동 조건에서 구성된 모든 영역의 모든 배율 단위가 활성 상태이며 게이트웨이 트래픽을 제공합니다. 모든 활성-활성 시나리오에서, 장애가 발생한 영역의 단위들이 원래 처리한 트래픽을 처리할 수 있도록 나머지 활성 영역에서 스케일 아웃을 지원할 계획을 세워야 합니다. |
복원력은 지역 내의 데이터 센터 가동 중단 중에 보장됩니다. 데이터 센터가 완전히 손실되는 동안 API 트래픽은 다른 영역에 배포된 나머지 단위를 통해 계속 흐릅니다. |
| (서비스) 트래픽 요구에 따라 자동 스케일 아웃 을 사용하도록 설정합니다. 다중 리전 배포에서 보조 지역에는 자동 스케일 아웃 또는 스케일 인 기능이 없습니다. 수요에 따라 단위 조정을 관리하려면 Azure Monitor 메트릭 경고에 대한 응답으로 활성화되는 사용자 지정 함수 또는 논리 앱을 구현해야 합니다. |
충분한 리소스가 API 클라이언트의 수요를 충족하도록 보장되므로 용량 부족으로 인한 오류를 방지할 수 있습니다. |
| (서비스) 다중 리전 토폴로지를 사용하여 전체 지역 장애에 대한 복원력을 지원합니다. 이 방법을 사용하려면 워크로드의 다른 구성 요소와 조정하고 계획된 장애 조치(failover) 특성을 이해해야 합니다. 활성-활성 시나리오에서는 현재 비활성 지역이 원래 처리한 트래픽을 처리하기 위해 나머지 활성 지역에서 스케일 아웃을 지원하도록 계획합니다. 다중 지역 토폴로지가 전송 중 데이터 또는 캐시 상주 데이터에 대한 규정 준수 요구 사항을 충족하는지 확인합니다. |
완전한 지역 가동 중단 시 강력한 복원력이 제공되므로 다른 지역에 배포된 단위를 통해 중단 없는 API 트래픽을 보장합니다. |
| (서비스) 작업 영역 또는 추가 API Management 인스턴스 를 사용하여 관련 없는 API를 격리합니다. | 구성 오류 또는 중단으로 인한 오류의 영향은 여러 컴퓨팅 인스턴스에서 API를 분리하여 최소화됩니다. |
| (API) 정책 식 및 논리를 철저히 테스트하고 API 관리 정책의 복원력 있는 오류 처리 기술과 쌍을 이뤄줍니다 . | 클라이언트 환경은 게이트웨이에서 새로운 오류 원본을 방지하고 정상적인 성능 저하 또는 안전한 일시적인 오류 처리를 제공하여 향상됩니다. |
| (서비스 및 API) 안정성 메트릭을 수집합니다. 일반적인 API 안정성 메트릭은 다음과 같습니다. - 속도 제한 및 할당량 위반. - HTTP 상태 코드를 기반으로 하는 오류 비율입니다. - 기준선에서 요청 속도 편차를 요청하십시오. - 종속성 상태를 포함한 건강 상태 점검 |
예상된 동작과 과거 기준선의 편차가 식별됩니다. 이 데이터를 사용하여 사용자 동작 변경, 일상적인 작업의 간섭, 새 기능의 예기치 않은 영향 또는 워크로드의 계획되지 않은 오류와 같은 근본 원인을 추적할 수 있습니다. |
| (서비스 및 API) DR 플레이북의 일부로 API Management에 기본 제공되는 백업 및 복원 기능을 사용합니다. 이러한 기능을 IaC 아티팩트 및 APIOps 프로세스로 보완하여 종속성 및 백 엔드와의 복구 조정을 포함하여 다양한 시나리오를 처리할 수 있는 강력한 솔루션을 제공합니다. | 전체 시스템 손실 후 API 게이트웨이의 복구 및 정의된 API 복원을 허용하여 비즈니스 연속성을 보장합니다. |
안전
보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보장을 제공하는 것입니다.
보안 디자인 원칙은 API Management 게이트웨이를 보호하는 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
비고
이 섹션의 검사 목록 및 권장 사항은 API Management 게이트웨이 리소스를 보호하는 데 중점을 줍니다. API 자체 보안은 간략하게 해결됩니다. 자세한 내용은 API Management에서 OWASP API 보안 상위 10개 완화를 참조하세요.
디자인 검사 목록
보안에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 상태를 개선합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
보안 기준을 설정합니다.API Management에 대한 보안 기준을 검토하고 해당 측정값을 기준에 통합합니다.
배포 파이프라인 보호: 서비스 플랫폼, CI/CD(지속적인 통합 및 지속적인 배포) 파이프라인 및 개별 API를 관리하는 데 필요한 개인 및 역할 기반 액세스 제어 역할을 식별합니다. 권한 있는 개인만 서비스와 해당 API를 관리할 수 있는 액세스 권한이 있는지 확인합니다.
데이터 민감도 평가: 중요한 데이터가 API Management 게이트웨이에서 API 요청 및 응답을 통해 흐르는 경우 전체 수명 주기 동안 해당 보호를 보장합니다. 여러 지역에 걸쳐 다양한 데이터 보호 요구 사항을 고려합니다. 여러 지역과 같은 서비스 기능을 평가하여 특정 데이터를 격리합니다. 또한 캐싱 전략이 이러한 격리 요구 사항에 부합하는지 확인합니다.
공유 게이트웨이에서 세분화 전략을 개발합니다. API Management 인스턴스가 여러 워크로드 팀에 대한 API를 호스트하는 경우 작업 영역을 사용하여 역할, 네트워크 및 게이트웨이를 분리합니다. 이 방법을 사용하면 각 팀이 다른 팀의 API에 대한 액세스를 제한하면서 관리하는 API에 대한 적절한 액세스 및 제어가 보장됩니다.
네트워크 컨트롤을 고려합니다.가상 네트워크를 사용하여 인바운드 및 아웃바운드 게이트웨이 트래픽을 격리 또는 필터링하기 위한 요구 사항 및 옵션을 식별합니다. Azure Private Link를 통해 게이트웨이에 대한 액세스를 제한할 수 있는지 또는 게이트웨이에 대한 공용 액세스가 필요한지 여부를 결정합니다. 필요한 네트워크 격리를 달성하고 네트워크 트래픽을 필터링하기 위해 아키텍처에 Azure Application Gateway 또는 Azure Front Door의 Azure 웹 애플리케이션 방화벽과 같은 웹 애플리케이션 방화벽이 포함되어야 하는지 여부를 평가합니다.
API 인증 및 권한 부여에 대한 기능을 고려합니다. 기본 제공 그룹을 포함하는 Microsoft Entra ID 또는 Microsoft Entra 외부 ID 와 같은 ID 공급자의 사용을 평가하여 게이트웨이 요청을 차단하고 백 엔드 API에 대해 OAuth 권한 부여를 사용하도록 설정합니다.
네트워크 트래픽 암호화: 워크로드에서 지원할 수 있는 가장 안전한 TLS(전송 계층 보안) 프로토콜 버전 및 암호화 를 식별합니다. 안전하지 않은 TLS 버전은 필요하지 않습니다. 클라이언트에서 지원되는 경우 TLS 1.3을 사용합니다.
API Management에서 위협 모델링을 수행하고 노출 영역을 줄입니다 . 직접 관리 API 또는 개발자 포털에 대한 공용 액세스와 같은 특정 API Management 구성 요소를 비활성화, 제한 또는 제거할 수 있는지 여부를 결정합니다.
워크로드에 필요한 비밀을 식별합니다. 게이트웨이 작업에는 인증서, API 키 또는 기타 비밀 값이 필요할 수 있습니다. 비밀 및 인증서를 저장하려면 Azure Key Vault의 요구 사항 및 기능을 검토합니다. 또는 명명된 값 및 관리되는 인증서와 같은 기본 제공 API Management 기능을 검토합니다.
권장 사항
이러한 보안 권장 사항은 서비스 자체 또는 API 및 해당 정책을 통해 흐르는 트래픽에 적용할 수 있습니다. (서비스) 또는 (API) 지정자는 권장 사항이 서비스 또는 API를 대상으로 하는지 여부를 나타냅니다.
| 추천 | 이익 |
|---|---|
| (서비스) 사용되지 않는 직접 관리 API를 사용하지 않도록 설정합니다. Azure Resource Manager를 컨트롤 플레인으로 사용합니다. | 컨트롤 플레인 액세스 지점을 제거하여 서비스의 노출 영역을 줄입니다. |
| (서비스) 합법적인 클라이언트가 연결하는 위치에만 기반하여 게이트웨이의 노출을 제한합니다. - 모든 클라이언트 가 가상 네트워크를 통해 트래픽을 라우팅할 수 있는 경우 공용 IP 주소 없이 가상 네트워크 주입을 사용합니다. NSG(네트워크 보안 그룹)를 사용하여 트래픽을 예상된 클라이언트 원본 IP 주소로만 추가로 제한합니다. - 트래픽이 인터넷에서 들어오야 하는 경우 Application Gateway 또는 Azure Front Door와 가상 네트워크 통합 을 사용합니다. 단일 진입점의 트래픽만 허용하도록 NSG 를 구성합니다. |
네트워크 트래픽의 기밀성은 합법적인 클라이언트를 포함할 것으로 예상되는 원본 IP 주소 범위에 대한 노출을 제한하여 보호됩니다. 이러한 제한은 합법적인 클라이언트 통신을 시작해서는 안 되는 원본의 액세스를 차단합니다. 합법적인 트래픽 원본에 대한 노출을 제한하면 서비스의 기밀성, 무결성 및 가용성이 향상됩니다. |
| (서비스) 사용하지 않는 경우 개발자 포털 을 사용하지 않도록 설정합니다. 포털이 사용 중인 경우 등록 환경을 사용하지 않도록 설정하고, 익명 액세스를 사용하지 않도록 설정하고, 신뢰할 수 있는 네트워크 위치로만 액세스를 제한합니다. | 서비스의 노출 영역과 잘못된 구성 또는 방치 가능성이 줄어듭니다. |
| (서비스) 클라이언트 및 백 엔드에 대해 지원되는 가장 좁은 TLS 버전, 프로토콜 및 암호화 를 명시적으로 설정합니다. | 버전 및 지원되는 암호는 클라이언트와 백 엔드가 지원하는 옵션으로만 축소됩니다. 이 방법은 연결이 기밀성을 위해 가능한 최고 등급 연결의 우선 순위를 지정하는 데 도움이 됩니다. |
| (서비스) Key Vault에 사용자 지정 인증서를 저장합니다. | 인증서 관리 기능은 일상적인 회전을 지원하고 인증서에 대한 액세스를 감사하는 Key Vault를 사용하여 제공됩니다. |
| (서비스) 백 엔드는 API 게이트웨이의 트래픽만 허용해야 하며 다른 모든 트래픽을 차단해야 합니다. | 악의적인 트래픽은 게이트웨이에 오프로드된 보안 및 기타 교차 차단 문제를 우회할 수 없습니다. |
| (서비스) 여러 팀 또는 분할된 워크로드에 대한 API를 호스트하는 API Management 인스턴스의 경우 강력한 액세스 제어 격리 전략을 설계해야 합니다.
작업 영역을 사용하거나 엄격한 APIOps 프로세스를 구현하여 이 전략을 달성합니다. Teams는 자신이 소유한 API에만 액세스할 수 있어야 합니다. 동일한 인스턴스에서 호스트될 수 있는 다른 API에 액세스할 수 없어야 합니다. |
한 손상된 API 세트에서 관련 없는 다른 API로 공격자가 가로 이동하는 것이 줄어듭니다. |
| (API) Key Vault에 비밀을 저장 하고 명명된 값을 통해 정책에 노출합니다. Key Vault를 비밀이 아닌 데이터를 저장하는 데 사용하지 마세요. 해당 값에 대해 명명된 값 속성을 직접 사용합니다. | 비밀 회전은 인증서에 사용되는 접근 방식과 유사하게 Key Vault의 단일 관리 평면을 통해 권장됩니다. 이 프로세스는 API Management가 그에 따라 업데이트되도록 합니다. 또한 명명된 값은 비밀 및 비보안 모두에 대한 정책 구성에 대한 일관된 환경을 보장합니다. 모든 비밀 액세스는 액세스 기록을 제공하기 위해 Key Vault에서도 감사됩니다. Key Vault에 비밀만 저장하면 Key Vault에 대한 종속성이 최소화되고 Key Vault가 애플리케이션 구성 서비스로 전환되지 않습니다. |
| (API) 인증 관리 ID 정책을 사용하여 다른 API에 대해 다른 사용자 할당 관리 ID를 사용합니다. | 각 API는 각 API에 대한 최소 권한 액세스를 통해 세분화 목표를 지원하는 독립적인 ID를 사용하도록 설정됩니다. 또한 백 엔드 시스템에서 더 나은 감사 기능을 제공합니다. |
| (API) 가능하면 구독 키 또는 클라이언트 인증서를 포함하여 미리 공유된 키만 사용하는 대신 클라이언트가 OAuth 2.0 흐름으로 인증하도록 요구합니다. | 감사 목적으로 클라이언트 식별이 개선되고, 키 회전이 제거되며, 사전 공유 키를 사용하는 것에 비해 비밀을 보호하는 클라이언트의 부담이 줄어듭니다. |
| (API) 구현 세부 정보를 노출할 수 있는 set-header 정책을 사용하여 API 응답에서 HTTP 헤더를 표시하지 않습니다. | 구현 정보를 제공하지 않음으로써 공격자에게 드는 비용이 증가합니다. |
| (API) 프로덕션 환경에서 API 추적을 사용하지 마세요. | 중요한 데이터는 요청 추적에서 노출되지 않습니다. |
| (API) Defender for API를 사용합니다. | API 보안 인사이트, 권장 사항 및 위협 검색이 제공됩니다. |
| (API) validate-jwt, ip-filter, validate-headers, validate-content와 같은 API 정책의 주요 보안 검사를 위임하여 백 엔드 리소스를 보호합니다. | 게이트웨이에서 보안 검사를 수행하여 백 엔드 서비스에 도달하는 불법 트래픽의 양이 줄어듭니다. 이 오프로드 접근 방식은 해당 리소스의 무결성 및 가용성을 보호하는 데 도움이 됩니다. |
| (API) 워크로드의 애플리케이션 코드에 제안된 변경 내용을 적용하는 것과 동일한 방식으로 API 정책 변경에 SDL(보안 개발 수명 주기) 사례를 적용합니다. 정책은 API 트래픽의 높은 권한 보기로 실행됩니다. | 손상된 API 게이트웨이의 기밀성, 무결성 및 가용성에 대한 백 엔드 보호를 우회할 수 없습니다. |
| (서비스 및 API) 서비스 및 API 종속성에 관리 ID 를 사용합니다. | Key Vault, Azure Event Hubs 및 인증서 및 명명된 값과 같은 기타 종속성에 대한 연결은 미리 공유된 비밀에 의존하지 않고 설정됩니다. |
| (서비스 및 API) 가능한 경우 프라이빗 네트워크 연결을 통해 Key Vault, Event Hubs 및 백 엔드와 같은 종속성에 연결합니다. | 트래픽의 기밀성은 프라이빗 네트워크 이외의 트래픽을 노출하지 않음으로써 보호됩니다. |
| (서비스 및 API) 인터넷에 노출된 API를 대상으로 하는 클라이언트 트래픽은 API Management에 도달하기 전에 먼저 웹 애플리케이션 방화벽(예: 웹 애플리케이션 방화벽)을 통과해야 합니다. 또한 Azure DDoS Protection을 사용하여 퍼블릭 엔드포인트를 보호합니다. | 웹 애플리케이션 방화벽을 사용하여 보안 검사를 수행하여 게이트웨이 및 백 엔드 서비스에 도달하는 불법 트래픽의 양이 줄어듭니다. 이 트래픽을 줄이면 해당 리소스의 무결성 및 가용성을 보호할 수 있습니다. |
| (서비스 및 API) 워크로드와 관련된 모든 Azure Policy 규정 준수 컨트롤을 평가하고 사용하도록 설정합니다. | API Management 인스턴스는 원하는 상태와 일치하며 보안 정책을 마련하여 워크로드가 진화함에 따라 조정된 상태를 유지합니다. |
비용 최적화
비용 최적화는 비즈니스 요구 사항을 충족 하면서 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.
비용 최적화 디자인 원칙은 이러한 목표를 달성하고 API Management 및 해당 환경과 관련된 기술 설계에서 필요에 따라 장단위를 만들기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
API Management 비용 모델을 고려합니다 . Azure 가격 계산기를 조직의 계정 이점과 SLA에 대한 기준 및 확장성을 사용하여 API Management 서비스 계층을 사용하는 정확한 비용 예측값을 개발합니다. 차지백 모델이 필요한지 여부를 확인하고 메트릭, 태그 및 토큰을 기반으로 계산하는 방법을 결정합니다.
서비스 비용 모델은 주로 서비스 계층, 단위 수 및 게이트웨이 수의 영향을 받습니다. 예약 단위를 유지 관리하거나 활성-수동 DR 구성을 구현하는 것과 관련된 추가 비용을 평가합니다.
작업 영역을 구현하는 경우 별도의 작업 영역과 공유 작업 영역 게이트웨이를 사용하는 비용을 평가하여 다양한 API 팀 또는 관련자의 고유한 API 흐름 요구 사항을 해결합니다.
크기 조정 비용 예측: 게이트웨이 리소스의 높은 사용량을 유지하기 위해 크기 조정 조건을 개발합니다. 사전 프로덕션 환경에서 기준 비용을 평가하고 예상 워크로드 트래픽에 따라 스케일 아웃 비용을 모델링하기 위한 테스트를 수행합니다.
게이트웨이 오용을 방지하고, 예측된 사용량 이상으로 확장하여 발생할 수 있는 높은 비용을 피하기 위한 완화 전략을 설계하세요.
서비스 구성 및 정책 평가:속도 제한 및 제한 동시성과 같은 기능을 비용 최적화 기술로 사용하여 요청 부하를 관리할 수 있습니다.
논리 배치 최적화: 백 엔드 서버가 논리 처리에 더 비용 효율적인지 또는 게이트웨이가 리소스 사용을 처리해야 하는지 여부를 평가합니다. 게이트웨이는 교차 절단 문제를 구현하기 위한 강력한 구성 요소이지만 특정 시나리오에서 과도한 기능을 수행할 수 있습니다. 게이트웨이가 수행하는 리소스가 많은 요청 처리 작업을 식별하고 해당 논리를 백 엔드 서버로 이동하면 비용이 절감될 수 있는지 여부를 결정합니다.
권장 사항
이러한 비용 최적화 권장 사항은 서비스 자체 또는 API 및 해당 정책을 통해 흐르는 트래픽에 적용할 수 있습니다. (서비스) 또는 (API) 지정자는 권장 사항이 서비스 또는 API를 대상으로 하는지 여부를 나타냅니다.
| 추천 | 이익 |
|---|---|
| (서비스) 워크로드 요구 사항을 지원하는 가장 저렴한 계층 을 사용합니다. 예를 들어 워크로드가 ROI(투자 수익률)를 정당화하는 방식으로 추가된 기능의 이점을 얻지 못하는 경우 프리미엄 계층 대신 표준 계층을 선택합니다. | 사용되지 않거나 사용되지 않는 기능 구매는 방지됩니다. |
| (서비스) 개발 환경, 개념 증명 배포 및 초기 비용 모델링 활동과 같은 하위 환경에서 비프로덕션 계층 또는 임시 인프라를 사용합니다. | 리소스 비용은 프로덕션의 정확한 구성 또는 작동 시간 요구 사항을 완전히 미러링하지 않고도 유용하게 유지될 수 있는 환경에 대해 저장됩니다. |
| (서비스) 수요가 감소할 때 규모를 조정합니다. 게이트웨이 용량이 정의된 임계값 아래로 떨어질 때 단위를 줄이도록 자동 크기 조정 규칙 또는 기타 자동화된 프로세스를 구성합니다. | 수요에 맞게 용량을 일치시켜 불필요한 비용이 절감됩니다. |
| (서비스) 작업 영역을 사용하여 API를 제공하는 동시에 팀 격리를 제공하여 API 관리에 대한 페더레이션된 모델의 비용 이점을 계산합니다. | 배포 및 관리 화면이 줄어듭니다. 이 접근 방식은 시간과 자원 구매에서 규모의 경제를 달성하는 것을 목표로합니다. |
| (서비스) 작업 영역이 더 이상 사용되지 않는 경우 서비스 해제 | 사용하지 않는 리소스에 대한 지출은 방지됩니다. |
| (서비스) 워크로드의 캐시된 데이터가 계층에 있는 기본 제공 캐시의 제약 조건에 맞는 경우 기본 제공 캐시를 사용합니다. | 외부 Redis 호환 캐시 구매 및 유지 관리와 관련된 비용은 피할 수 있습니다. |
| (서비스) 네트워크 제어, DDoS 보호 및 웹 애플리케이션 방화벽을 사용하여 게이트웨이에 도달하기 전에 악성 트래픽을 차단합니다. API Management의 특정 계층은 게이트웨이가 처리하는 HTTP 요청 작업 수에 따라 요금이 발생합니다. 따라서 봇에서 생성된 요청과 같은 바람직하지 않은 트래픽은 비용을 증가시킬 수 있습니다. 차단 메커니즘의 비용과 HTTP 작업 감소의 예상 비용을 평가하여 이 접근 방식에 ROI가 있는지 여부를 평가합니다. |
게이트웨이에 대한 과도한 악성 또는 성가신 HTTP 작업으로 인해 발생하는 요금이 줄어듭니다. |
| (API) 프로세서, 네트워킹 또는 메모리와 같은 과도한 컴퓨팅 리소스 사용을 방지하도록 정책 식과 처리 및 코드를 최적화합니다. | 단순화되지 않은 정책 구현 및 코드에 대한 용량을 제공하기 위해 더 많은 단위를 불필요하게 배포하지 않습니다. |
| (API) 게이트웨이, 백 엔드 또는 공용 진입점(예: Azure Front Door) 간의 논리 배치 비용을 평가합니다. 동일한 처리는 각각 자체 절충이 있는 이러한 계층에서 발생할 수 있습니다. 그러나 일부 계층은 해당 수준에서 사용할 수 있는 사용되지 않는 용량으로 인해 비용을 절감할 수 있습니다. 예를 들어 원래 백 엔드에서 구현된 캐싱 논리는 기본 제공 캐시를 사용하여 게이트웨이 수준에서 보다 비용 효율적으로 구현될 수 있습니다. 이 방법은 백 엔드 서비스의 추가 네트워크 및 컴퓨팅 오버헤드를 줄입니다. | 가장 비용 효율적인 계층에 기능을 배치하여 고비용 리소스에 대한 부하를 최소화합니다. 이 방법은 워크로드를 여분의 용량 또는 저렴한 컴퓨팅 옵션이 있는 계층으로 이동합니다. |
운영 우수성
운영 우수성은 주로 개발 관행, 관찰성 및 릴리스 관리를 위한 절차에 중점을 둡니다.
운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
API Management와 관련된 관찰성, 테스트 및 배포에 대한 프로세스를 정의하기 위한 운영 우수성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.
디자인 검사 목록
서비스를 운영하는 데 필요한 주요 지식 및 기술을 검토합니다 . 영역에는 API 수명 주기, DevOps 프로세스, 네트워킹 및 연결, 모니터링 및 관찰성 및 소프트웨어 개발이 포함됩니다. 이 방법은 정책 구성, 단위 테스트 및 CI/CD 파이프라인 생성을 포함합니다.
설명서 요구 사항을 고려합니다. 조직은 서비스 수준 및 API 수준 구성, 수명 주기 작업 및 API 팀의 다양한 액세스 패턴에 대한 문서화 프로세스를 커밋해야 합니다.
표준 도구를 평가 하여 서비스 작업을 지원합니다. 예를 들어 GitOps 및 CI/CD와 같은 APIOps 메서드를 채택하여 API를 게시하고 API 구성을 관리합니다. 서비스 수준 구성 변경에 IaC 도구를 사용합니다. 개발 환경에서 프로덕션 환경으로 원활하게 전환할 수 있는 재사용 가능한 아티팩트 디자인 자체 관리형 또는 Azure API 센터와 같은 Azure 서비스에 통합된 Spectral과 같은 Linter를 API 승인 파이프라인에 통합하는 것이 좋습니다.
주요 운영 메트릭 및 로그를 확인합니다. 프로덕션에 대한 메트릭을 검토합니다 . 이러한 메트릭에는 게이트웨이 용량, CPU 사용량, 메모리 사용량 및 요청 수가 포함됩니다. Azure Monitor 및 Application Insights와 같은 로그 및 관찰 가능 도구를 검토합니다. 프로덕션 환경에서 대량의 관찰 데이터를 효과적으로 관리하는 데 필요한 전략 및 도구를 결정합니다. 게이트웨이 운영자와 특정 호스트된 API를 모니터링하는 관련자 모두에 대해 실행 가능한 인사이트를 제공하는 쿼리를 결정합니다.
부하 테스트를 사용하여 프로덕션 워크로드의 정기적인 테스트를 계획합니다.
자동화가 필요한 CI/CD 또는 IaC 프로세스 이외의 운영 작업을 식별합니다. API Management 정책 원본 관리, Azure 정책 및 특정 개발자 포털 구성과 같은 영역에서 자동화를 계획합니다.
권장 사항
이러한 운영 우수성 권장 사항은 서비스 자체 또는 API 및 해당 정책을 통해 흐르는 트래픽에 적용할 수 있습니다. (서비스) 또는 (API) 지정자는 권장 사항이 서비스 또는 API를 대상으로 하는지 여부를 나타냅니다.
| 추천 | 이익 |
|---|---|
| (서비스) API Management에 대한 Azure 진단 리소스 로그를 구성합니다. | 플랫폼 생성 로그는 일상적인 작업, 주문형 요구 사항 또는 보안 감사와 같은 긴급한 시나리오를 쿼리하는 데 사용할 수 있습니다. |
(서비스) API Management 인스턴스에서 발생시키는 의미 있는 이벤트(예: APICreated)를 기반으로 자동화에 Azure Event Grid를 사용합니다. |
API Management 인스턴스에서 발생하는 주요 수명 주기 이벤트를 중심으로 자동화 또는 알림 작업을 빌드할 수 있습니다. |
| (서비스) 시나리오에서 Microsoft 호스팅 게이트웨이 단위가 작동하는 경우 자체 호스팅 게이트웨이를 사용하지 않습니다. | API Management 인스턴스에서 발생하는 주요 수명 주기 이벤트를 중심으로 자동화 또는 알림 작업을 빌드할 수 있습니다. |
| (서비스) 인스턴스를 관리하고 보안 요구 사항을 포함하여 워크로드 요구 사항에 맞게 제한하는 데 도움이 되는 모든 기본 제공 Azure Policy 정책을 적용합니다. 예를 들어 거부 정책을 사용하여 API가 HTTP를 통해 노출되지 않도록 방지하거나 직접 관리 REST API를 사용하도록 설정하지 않도록 합니다. 거부 정책을 사용할 수 없는 경우 감시 정책을 사용하십시오. 워크로드에 중요하다면 사용자 지정 거부 정책을 만드십시오. | API Management 인스턴스는 디자인에 맞게 조정되며 워크로드가 진화함에 따라 정렬된 상태로 유지됩니다. |
| (서비스) Azure Portal에서 진단 및 문제 해결 기능을 숙지합니다. 포털의 네트워크 상태 블레이드 를 사용하여 네트워크 연결 문제를 해결합니다. |
사이트 안정성 엔지니어링 개인은 모든 환경에서 게이트웨이 성능, 서비스 가용성 및 네트워크 연결 문제를 식별하고 해결할 수 있습니다. |
| (API) Event Hubs 를 사용하여 거의 실시간 반응 또는 짧은 기간 기간의 작업이 필요한 API 호출에서 로그 또는 이벤트 스트림을 처리합니다. | 로그 항목의 거의 실시간 가용성이 제공됩니다. API 내에서 Azure Monitor에 로깅할 때 발생하는 로그 데이터 수집 지연 을 방지합니다. |
| (API) 개발에서 API 추적 을 사용하여 개발자가 정책 구현을 이해할 수 있도록 지원합니다. | 개발자 생산성은 API 내에서 정책 구현에 대한 인사이트를 제공하여 최적화됩니다. 이 기능이 없으면 개발자는 정보를 얻기 위해 정책 구현에 해킹을 도입해야 합니다. |
| (API) 항상 API Management의 백 엔드 기능을 사용하여 백 엔드를 정의합니다 . set-backend-service를 사용하여 정책에서 ID별로 이러한 백 엔드를 참조합니다. 부하 분산된 백 엔드는 백 엔드 풀로 정의해야 합니다. | 백 엔드 연결 변경 내용은 개별 정책 코드를 업데이트할 필요 없이 백 엔드를 사용하는 모든 API에 적용됩니다. 잘못 구성되거나 간과된 API 정책 변경의 위험이 줄어들고 여러 API가 동일한 백 엔드를 공유하는 시나리오는 이 구성 추상화 계층을 통해 적합합니다. |
| (API) API Management의 버전 관리 및 수정 기능에 맞게 API의 버전 관리 접근 방식을 디자인합니다. 이 접근 방식을 API 배포 작업에 고려합니다. | API Management에서 기본적으로 지원되는 API 버전 관리 전략은 사용자 지정 솔루션을 빌드하는 대신 기본 제공 기능을 활용하는 데 사용됩니다. |
| (서비스 및 API) API를 추가, 수정 및 삭제하기 위한 일관되고 지속 가능한 운영 프로세스를 정의합니다. 포털을 통해 이 환경을 수동으로 관리할지 아니면 APIOps 프로세스를 통해 구현할지 결정합니다. 포털 기반 접근 방식 대신 IaC 기반 접근 방식을 사용하는 것이 좋습니다. Resource Manager API에서 API Management의 표현은 많은 자식 리소스로 구성되므로 이 리소스 컬렉션의 IaC 기반 관리를 위한 계층화된 접근 방식을 채택하는 것이 중요합니다. |
API 사양 및 해당 게이트웨이 구현은 워크로드의 변경 제어 프로세스에 통합됩니다. 이 방법을 사용하면 백 엔드 API에 대한 변경 내용이 게이트웨이를 통해 API 클라이언트에 노출되는 방식과 다르게 처리되지 않습니다. |
성능 효율성
성능 효율성은 용량 을 관리하여 부하가 증가하는 경우에도 사용자 환경을 유지하는 것입니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.
성능 효율성 디자인 원칙은 예상된 사용량에 대해 이러한 용량 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
API Management의 주요 성과 지표를 기반으로 기준을 정의하기 위한 성능 효율성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.
디자인 검사 목록
성능 목표 정의: API Management 게이트웨이의 성능을 평가하는 주요 메트릭에는 게이트웨이 인프라, 요청 기간 및 요청 처리량에 대한 CPU 및 메모리 사용 비율과 같은 용량 메트릭이 포함됩니다. 다중Region 배포에서 각 지역에 대한 성능 목표를 정의합니다. 고객은 트래픽 패턴, API 워크로드 및 크기 조정 시간에 따라 적절한 크기 조정 임계값을 정의해야 합니다.
성능 데이터 수집: 기본 제공 분석, Azure Monitor 메트릭, Azure Monitor 로그, Application Insights 및 Event Hubs의 기능을 검토하여 다양한 수준의 세분성에서 성능을 수집하고 분석합니다.
라이브 성능 문제를 식별하는 방법을 검토합니다. 라이브 성능 문제에 대한 지표에는 Azure 서비스 가용성, HTTP 응답 오류 및 포털의 진단 및 문제 해결 섹션에서 발생한 오류가 포함됩니다. Azure Portal의 API Management Diagnostics에서 Application Insights, Kusto 쿼리 및 권장 사항을 사용하여 성능 및 가용성 문제를 해결합니다.
테스트 성능: 부하 테스트를 사용하여 프로덕션 조건에서 성능을 테스트합니다.
성능을 향상시킬 수 있는 인접 서비스를 평가합니다 . 정책 또는 외부 캐시를 캐싱하면 특정 API 작업의 성능이 향상될 수 있습니다. Azure Front Door 및 Application Gateway는 TLS 오프로드에 대한 일반적인 선택 사항입니다.
문서화된 제한 및 제약 조건을 검토합니다.API Management에는 제한과 제약 조건이 있습니다. 문서화된 제약 조건을 검토하고 워크로드 요구 사항과 비교하여 이러한 제약 조건을 방지하는 솔루션을 설계해야 하는지 확인합니다.
권장 사항
이러한 성능 효율성 권장 사항은 서비스 자체 또는 API 및 해당 정책을 통해 흐르는 트래픽에 적용할 수 있습니다. (서비스) 또는 (API) 지정자는 권장 사항이 서비스 또는 API를 대상으로 하는지 여부를 나타냅니다.
| 추천 | 이익 |
|---|---|
| (서비스) 수요에 맞게 동적으로 확장합니다. 대상 사용량 용량에 맞게 게이트웨이 단위를 조정하도록 자동 크기 조정 규칙 또는 기타 자동화된 프로세스를 구성합니다. | 탄력성은 현재 배포된 단위의 리소스 고갈 또는 용량 초과 할당을 방지하는 동시 사용량에 따라 달성됩니다. |
| (API) 대규모 요청 본문에서 유효성 검사-콘텐츠 정책을 사용하거나 많은 수의 활성 WebSocket을 유지 관리하여 버퍼링된 큰 페이로드 크기 생성과 같은 비용이 많이 드는 처리 작업을 최소화합니다. | 스케일 단위의 부하가 줄어들어, 확장하기 전에 동시에 더 많은 요청을 처리할 수 있습니다. |
| (서비스 및 API) 성능 메트릭을 수집합니다. 일반적인 API 성능 메트릭은 다음과 같습니다. - 게이트웨이 자체 및 전체 작업에 대한 처리 시간을 요청합니다. - 게이트웨이 단위 리소스 사용 메트릭 - 초당 요청 또는 초당 메가비트와 같은 처리량 측정입니다. - 캐시 적중 비율 |
실제 성능은 워크로드의 대상에 대해 측정됩니다. |
| (서비스 및 API) 성능에 영향을 주지 않고 충분한 가시성 을 제공하는 Application Insights에 대한 샘플링 비율을 정의합니다 . | 관찰성 데이터 요구 사항은 전반적인 성능에 영향을 주지 않고 충족됩니다. |
| (서비스 및 API) 게이트웨이, 백 엔드 또는 공용 진입점(예: Azure Front Door) 간의 논리 배치의 성능 영향을 평가합니다. 이러한 계층에서 동일한 처리 작업이 발생할 수 있으며, 각 계층에 대한 최적화 기회의 성능 절충 및 제한 사항이 있습니다. API 관리 API 정책과 같은 태스크에 너무 많은 대기 시간이 발생하는 경우 해당 작업이 더 최적화된 방식으로 다른 곳에서 실행될 수 있는지 여부를 고려합니다. | API에 대기 시간을 추가하는 작업은 워크로드 요구 사항을 충족하도록 최적화된 컴퓨팅에서 실행됩니다. |
Azure 정책
Azure는 API Management 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 이전 권장 사항 중 일부는 Azure Policy를 통해 감사할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.
- 게이트웨이는 영역 중복성을 위해 구성됩니다.
- 가상 네트워크의 배포와 같은 API Management 게이트웨이에 적절한 네트워크 제어가 있습니다.
- 서비스 구성 엔드포인트는 공개적으로 액세스할 수 없습니다.
- 직접 관리 REST API를 사용할 수 없습니다.
포괄적인 거버넌스를 위해 API Management 게이트웨이의 보안에 영향을 줄 수 있는 Azure Policy 기본 제공 정의 및 기타 정책을 검토합니다.
Azure Advisor 권장 사항
Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다.
자세한 내용은 Azure Advisor를 참조하세요.
Advisor는 다음과 같은 프로덕션 시스템의 다른 권장 사항도 표시할 수 있습니다.
- validate-jwt 정책에서 긴 JWT 키 크기를 요구하지 않습니다.
- 레거시 Resource Manager API 버전을 사용하여 리소스를 배포했습니다.
- API 키 토큰은 만료 날짜에 가깝습니다.
- 인증서 회전 작업에서 오류가 발생했습니다.
장단점
기둥 검사 목록의 접근 방식을 사용하는 경우 디자인 측면에서 타협이 필요할 수 있습니다. 다음은 장점과 단점의 몇 가지 예입니다.
중복성 및 격리를 통한 고가용성
고가용성. 아키텍처에 중복성을 추가하면 비용에 영향을 줍니다. 예를 들어 영역 중단을 방지하기 위해 3개 이상의 단위를 프로비전하는 것은 워크로드에 재정적으로 불가능할 수 있습니다. 지역당 6개 이상의 단위 또는 3개 단위가 필요한 다중 리전 아키텍처를 사용하면 비용이 더 증가합니다. 다중 지역 설정은 안전한 배포, 신뢰할 수 있는 크기 조정, 백 엔드와의 장애 조치(failover) 조정을 위한 운영 비용이 추가됩니다.
격리. 작업 영역 또는 API Management 인스턴스 간에 워크로드를 격리하면 컴퓨팅 격리가 있는 다중 테넌트 시스템 관리가 포함되므로 운영 복잡성이 추가됩니다.
수요에 맞게 크기 조정
잘 동작하는 클라이언트의 요구를 충족하기 위해 자동으로 스케일 아웃하는 경우 이러한 비용은 이미 비용 모델에 고려됩니다. 그러나 이 크기 조정 기능을 사용하면 성가신 트래픽과 악의적인 트래픽의 트래픽을 처리하도록 서비스를 확장할 수 있습니다.
원치 않는 트래픽을 완화하면 비용이 발생합니다. 웹 애플리케이션 방화벽 및 DDoS 보호와 같은 서비스를 추가하면 비용이 증가합니다. 트래픽을 처리하도록 서비스를 확장하면 단위가 추가되어 비용이 증가합니다. 상한 크기 조정 한도를 설정하면 지출이 제한될 수 있지만 악의적이거나 유해한 트래픽이 API를 압도하는 경우 합법적인 사용자에게 안정성 문제가 발생할 수 있습니다.
페더레이션 및 분산 방식
API Management의 기본 결정은 단일 API Management 인스턴스 내에서 서로 다른 워크로드를 공동 배치할지 또는 완전 자율 토폴로지에서 여러 인스턴스 간에 워크로드를 격리할지 여부입니다.
API Management 작업 영역을 사용하면 여러 API 팀을 위한 다중 테넌트 공동 배치 플랫폼으로 효율적인 작업을 수행할 수 있습니다. 계층화된 가격 책정 모델은 게이트웨이를 사용하는 모든 테넌트에서 서비스 비용을 공유할 수 있도록 설계되었습니다. 그러나 공동 배치 플랫폼과 마찬가지로 중단 또는 잘못된 구성으로 인해 동일한 인프라를 공유하는 관련 없는 워크로드에 광범위한 영향을 미칠 수 있습니다.
각 워크로드 팀이 자체 인스턴스를 관리하는 완전히 분산된 모델은 일상적인 작업에서 중복 비용과 중복성을 도입합니다. 그러나 안정성, 보안 및 성능 관련 인시던트에 대한 내재된 폭발 반경 완화를 제공합니다.
다음 단계
API Management는 종종 다음 서비스와 결합됩니다. 워크로드에 다음 서비스가 포함된 경우 해당 서비스 가이드 또는 제품 설명서를 검토해야 합니다.
- 응용 프로그램 게이트웨이
- Azure Cache for Redis
- Azure 정문
- 키 볼트
- Azure OpenAI 서비스
- Azure Virtual Network
- 웹 애플리케이션 방화벽
다음 문서에서는 이 문서에서 설명하는 몇 가지 권장 사항을 보여 줍니다.