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