Azure API Management
Azure Monitor
Azure App Service
이 시나리오에서 여행 업계의 전자 상거래 회사는 Azure API Management를 사용하여 레거시 웹앱을 마이그레이션합니다. 이 회사는 Azure에서 새 UI를 PaaS(Platform as a Service) 앱으로 호스트합니다. 새 UI는 기존 및 새 HTTP API에 따라 달라집니다. 이러한 API는 성능을 향상시키고 통합을 간소화하며 향후 확장성을 허용하는 보다 효과적으로 설계된 인터페이스로 배포됩니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
다음 워크플로는 이전 다이어그램에 해당합니다.
기존 온-프레미스 웹앱은 기존 온-프레미스 웹 서비스를 계속 직접 사용합니다.
기존 웹앱에서 기존 HTTP 서비스로 보내는 호출은 변경되지 않습니다. 이러한 호출은 회사 네트워크 내부용입니다.
API Management는 Azure에서 기존 내부 서비스로 호출합니다.
보안 팀은 TLS(전송 계층 보안)를 통해 HTTPS(Hypertext Transfer Protocol Secure)와 같은 보안 전송 프로토콜을 사용하여 API Management 인스턴스의 트래픽이 회사 방화벽을 통해 기존 온-프레미스 서비스로 전달되도록 허용합니다.
운영 팀은 API 관리 인스턴스에서 서비스로 오는 인바운드 호출만 허용합니다. API Management 인스턴스의 IP 주소를 회사 네트워크 경계 내의 허용 목록에 추가하여 이 요구 사항을 충족합니다.
HTTP(Hypertext Transfer Protocol) 서비스에 대한 온-프레미스 요청 파이프라인의 새 모듈은 외부에서 발생하는 연결에서만 작동합니다. 파이프라인은 API Management에서 제공하는 인증서의 유효성을 검사합니다.
새 API에는 다음과 같은 특징이 있습니다.
API 외관을 제공하는 API Management 인스턴스만 새 API를 표시합니다. 새 API에 직접 액세스하지 않습니다.
Azure PaaS 웹 API 앱으로 새 API를 개발하고 게시합니다.
새 API를 Azure App Service의 Web Apps 기능에 대한 설정을 사용하여 API Management VIP(가상 IP)만 허용하도록 설정합니다.
Web Apps는 HTTPS 또는 TLS와 같은 보안 전송 프로토콜이 켜져 있는 새 API를 호스트합니다.
Azure App Service 는 Microsoft Entra ID 및 OAuth(Open Authorization) 2를 통해 권한 부여 기능을 제공합니다.
새 브라우저 기반 웹앱은 기존 HTTP API와 새 API 모두에 대한 API Management 인스턴스에 따라 달라집니다.
여행 전자 상거래 회사는 이전 UI와 기존 기능을 나란히 유지하면서 미리 보기 또는 테스트를 위해 일부 사용자를 새 UI로 보낼 수 있습니다.
레거시 HTTP 서비스를 새 API 계약에 매핑하도록 API Management 인스턴스를 설정합니다. 이 구성에서 새 웹 UI는 레거시 서비스 또는 API 및 새 API 집합과의 통합을 인식하지 못합니다.
나중에 프로젝트 팀은 점진적으로 기능을 새 API로 이동하고 원래 서비스를 사용 중지할 수 있습니다. 팀은 API Management 구성 내에서 이러한 변경 내용을 처리하여 프런트 엔드 UI에 영향을 받지 않고 재개발 작업을 방지합니다.
구성 요소
API Management 는 모든 환경에서 API를 위한 관리 플랫폼 및 게이트웨이입니다. 이 아키텍처에서는 기존 레거시 API 및 새 API의 외관 역할을 합니다. 새 클라이언트 앱은 일관된 단일 인터페이스를 사용하며, 팀은 프런트 엔드 개발에 미치는 영향을 최소화하면서 해당 외관 뒤에서 레거시 백 엔드를 증분 방식으로 현대화할 수 있습니다.
App Service 는 보안, 부하 분산, 자동 크기 조정 및 자동화된 관리와 같은 기본 기능을 제공하는 웹 호스팅용 턴키 PaaS 솔루션입니다. 이 아키텍처에서 App Service는 DevOps 팀이 기능 전달에 집중할 수 있도록 유연한 턴키 호스팅을 제공합니다.
대안
조직에서 레거시 앱을 호스트하는 VM(가상 머신)을 비롯한 인프라를 Azure로 완전히 이동하려는 경우 API Management는 주소 지정 가능한 HTTP 엔드포인트의 외관 역할을 할 수 있습니다.
조직에서 기존 엔드포인트를 비공개로 유지하고 공개적으로 노출하지 않는 경우 조직의 API Management 인스턴스는 Azure 가상 네트워크에 연결할 수 있습니다.
API Management가 Azure 가상 네트워크에 연결된 경우 조직은 개인 IP 주소를 통해 백 엔드 서비스를 직접 처리할 수 있습니다.
온-프레미스 시나리오에서 API Management 인스턴스는 Azure VPN Gateway 및 사이트 간 IPsec(인터넷 프로토콜 보안) VPN 연결 또는 Azure ExpressRoute를 통해 내부 서비스에 비공개로 연결할 수 있습니다. 그런 다음 이 시나리오는 Azure 및 온-프레미스의 하이브리드가 됩니다.
조직은 내부 모드로 배포하여 API Management 인스턴스를 비공개로 유지할 수 있습니다. 그러면 조직은 Azure Application Gateway 와 함께 배포를 사용하여 일부 API에 대한 공용 액세스를 허용하고 다른 API는 내부적으로 유지할 수 있습니다. 자세한 내용은 Application Gateway를 사용하여 내부 가상 네트워크에 API Management 통합을 참조하세요.
조직은 온-프레미스에서 API를 호스트하기로 결정할 수 있습니다. 이 변경의 한 가지 이유는 조직이 이 프로젝트의 범위에 있는 다운스트림 데이터베이스 종속성을 클라우드로 이동할 수 없기 때문일 수 있습니다. 이 시나리오에서 조직은 자체 호스팅 게이트웨이를 사용하여 API Management를 로컬로 활용할 수 있습니다.
자체 호스팅 게이트웨이는 아웃바운드 소켓에서 Azure에 연결하는 API Management 게이트웨이의 컨테이너화된 배포입니다. 자체 호스팅 게이트웨이를 사용하려면 다음 필수 조건을 충족해야 합니다.
Azure에서 부모 리소스를 사용하여 자체 호스팅 게이트웨이를 배포해야 하므로 추가 비용이 추가됩니다.
API Management의 프리미엄 계층을 사용해야 합니다.
시나리오 정보
여행 업계의 전자 상거래 회사는 레거시 브라우저 기반 소프트웨어 스택을 현대화하려고 합니다. 기존 스택은 대부분 모놀리식이지만 일부 SOAP(Simple Object Access Protocol) 기반 HTTP 서비스는 최근 프로젝트에서 존재합니다. 이 회사는 내부 지적 재산권의 일부를 수익을 창출하기 위해 추가 수익원을 만드는 것을 고려합니다.
이 프로젝트의 목표에는 기술적인 문제 해결, 지속적인 유지 관리 개선 및 회귀 버그가 적은 기능 개발 가속화가 포함됩니다. 프로젝트는 반복 프로세스를 사용하여 위험을 방지하고 다음 단계를 병렬로 수행합니다.
개발 팀은 VM에서 호스트되는 관계형 데이터베이스로 구성된 앱의 백 엔드를 현대화합니다.
사내 개발 팀은 새로운 비즈니스 기능을 작성하고 새 HTTP API를 통해 노출합니다.
계약 개발 팀은 Azure에서 호스트하는 새 브라우저 기반 UI를 빌드합니다.
이 회사는 새로운 앱 기능을 단계적으로 제공합니다. 이러한 기능은 회사의 전자 상거래 비즈니스를 구동하는 온-프레미스에서 호스트되는 기존 브라우저 기반 클라이언트 및 서버 UI 기능을 점진적으로 대체합니다.
관리 팀 멤버들은 불필요한 현대화를 원하지 않습니다. 범위 및 비용도 계속 제어할 수 있기를 원합니다. 이러한 목표를 달성하기 위해 기존 SOAP HTTP 서비스를 유지하기로 결정합니다. 또한 기존 UI 변경을 최소화하려 합니다. API Management를 사용하여 프로젝트의 많은 요구 사항 및 제약 조건을 해결할 수 있습니다.
잠재적인 사용 사례
이 시나리오에서는 레거시 브라우저 기반 소프트웨어 스택을 현대화하는 방법을 강조 표시합니다.
다음 작업에 이 시나리오를 사용할 수 있습니다.
- 비즈니스가 Azure 에코시스템을 사용하여 이익을 얻을 수 있는 방법을 알아봅니다.
- Azure로 서비스 마이그레이션을 계획합니다.
- Azure로의 전환이 기존 API에 미치는 영향을 알아봅니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.
안정성
안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.
API Management 인스턴스를 배포할 때 가용성 영역을 활성화합니다. 가용성 영역에 API Management를 배포하는 옵션은 프리미엄 서비스 계층에서만 사용할 수 있습니다.
다른 지역에 배포된 추가 게이트웨이 인스턴스가 있는 가용성 영역을 사용합니다. 이 조합은 한 지역이 오프라인 상태가 되면 서비스 가용성을 향상시킵니다. 멀티리전 배포는 프리미엄 서비스 계층에서만 사용할 수 있습니다.
모니터링을 위해 Azure Monitor를 통해 메트릭을 표시하는 Application Insights와 통합합니다. 예를 들어 용량 메트릭을 사용하여 API Management 리소스의 전체 부하와 더 많은 스케일 아웃 단위가 필요한지 여부를 결정할 수 있습니다. 리소스 용량 및 상태를 추적하여 안정성을 향상시킵니다.
API Management에서 다루는 API를 호스트하는 백 엔드 서비스와 같은 다운스트림 종속성도 복원력이 있는지 확인합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화에 대한 디자인 검토 검사 목록을 참조하세요.
API Management에는 8개의 계층이 있습니다.
- 소비
- 개발자
- 기본 및 기본 v2
- 표준 및 표준 버전 2
- 프리미엄 및 프리미엄 v2
이러한 계층의 차이점에 대한 자세한 내용은 API Management 가격 책정을 참조하세요.
단위를 추가하고 제거하여 API Management 크기를 조정할 수 있습니다. 각 단위의 용량은 해당 계층에 따라 다릅니다.
참고
개발자 계층을 사용하여 API Management 기능을 평가할 수 있습니다. 프로덕션에 사용하지 마세요.
배포 요구 사항에 대한 예상 비용을 보려면 Azure 가격 계산기에서 배율 단위 및 App Service 인스턴스 수를 수정할 수 있습니다.
참가자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
- Ben Gimblett | 선임 고객 엔지니어
기타 기여자:
- Andrew Cardy | 수석 소프트웨어 엔지니어
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.