편집

Azure API Management를 사용하여 웹앱 마이그레이션

Azure API Management
Azure Monitor
Azure App Service

이 시나리오에서 여행 업계의 전자 상거래 회사는 Azure API Management를 사용하여 레거시 웹 애플리케이션을 마이그레이션합니다. 새 UI는 Azure에 PaaS(Platform as a Service) 애플리케이션으로 호스트되며, 기존 및 새 HTTP API를 모두 사용합니다. 이러한 API는 보다 우수한 성능, 보다 간편한 통합, 향후 확장성을 제공하도록 잘 설계된 인터페이스 집합을 제공합니다.

아키텍처

아키텍처 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

  1. 기존 온-프레미스 웹 애플리케이션은 기존 온-프레미스 웹 서비스를 계속 직접 사용합니다.
  2. 기존 웹앱에서 기존 HTTP 서비스로의 호출은 변경되지 기본. 이러한 호출은 회사 네트워크 내부용입니다.
  3. 인바운드 호출은 Azure에서 기존 내부 서비스로 수행됩니다.
  4. 새 API:
  5. 새 브라우저 기반 웹 애플리케이션은 기존 HTTP API와 새 API 모두에 대한 Azure API Management 인스턴스에 따라 달라집니다.

API Management 인스턴스는 레거시 HTTP 서비스를 새 API 계약에 매핑하도록 구성됩니다. 이 구성에서 새 웹 UI는 레거시 서비스/API 및 새 API 집합과의 통합을 인식하지 못합니다.

나중에 프로젝트 팀이 점진적으로 기능을 새 API로 이식하고 원래 서비스를 사용 중지할 것입니다. 팀은 API Management 구성 내에서 이러한 변경 내용을 처리하여 프런트 엔드 UI에 영향을 받지 않고 재개발 작업을 방지합니다.

구성 요소

대안

  • 조직이 레거시 애플리케이션을 호스트하는 VM(가상 머신)을 포함하여 인프라를 Azure로 완전히 이동하려는 경우 API Management는 주소 지정 가능한 HTTP 엔드포인트의 외관 역할을 할 수 있기 때문에 여전히 유용한 옵션입니다.

  • 조직에서 기존 엔드포인트를 비공개로 유지하고 공개적으로 노출하지 않기로 결정한 경우 조직의 API Management 인스턴스가 Azure 가상 네트워크에 연결될 수 있습니다.

  • 조직은 내부 모드로 배포하여 API Management 인스턴스를 비공개로 유지할 수 있습니다. 그런 다음 조직은 Azure 애플리케이션 Gateway와 함께 배포를 사용하여 일부 API에 대한 공용 액세스를 사용하도록 설정하고 다른 API는 내부로 다시 기본 수 있습니다. 자세한 내용은 내부 가상 네트워크의 API Management를 Application Gateway와 통합을 참조하세요.

  • 조직은 온-프레미스에서 API를 호스트하기로 결정할 수 있습니다. 이러한 변경의 한 가지 이유는 조직이 이 프로젝트의 범위에 있는 다운스트림 데이터베이스 종속성을 클라우드로 이동할 수 없기 때문일 수 있습니다. 이 경우 조직은 자체 호스팅 게이트웨이를 사용하여 API Management를 로컬로 활용할 수 있습니다.

    자체 호스팅 게이트웨이는 아웃바운드 소켓에서 Azure에 다시 연결하는 API Management 게이트웨이의 컨테이너화된 배포입니다. 첫 번째 필수 조건은 Azure에서 부모 리소스 없이는 자체 호스팅 게이트웨이를 배포할 수 없으므로 추가 요금이 부과됩니다. 두 번째 필수 구성 요소는 API Management 프리미엄 계층이 필요하다는 것입니다.

참고 항목

API Management를 가상 네트워크에 연결하는 방법에 대한 일반적인 내용은 이 문서를 참조 하세요.

시나리오 정보

여행 업계의 전자 상거래 회사가 레거시 브라우저 기반 소프트웨어 스택을 현대화하고 있습니다. 기존 스택은 대부분 모놀리식이지만 일부 SOAP 기반 HTTP 서비스는 최근 프로젝트에서 존재합니다 . 이 회사는 개발 한 내부 지적 재산권의 일부를 수익을 창출하기 위해 추가 수익원을 만드는 것을 고려하고 있습니다.

프로젝트의 목표는 기술적인 문제를 해결하고, 지속적인 유지 관리를 개선하고, 회귀 버그를 줄여 기능 개발 속도를 높이는 것입니다. 프로젝트에서는 위험을 피하기 위해 반복 프로세스를 사용하고, 일부 단계가 병렬로 수행됩니다.

  • 개발 팀은 VM에서 호스트되는 관계형 데이터베이스로 구성된 애플리케이션의 백 엔드를 현대화합니다.
  • 사내 개발 팀은 새 HTTP API를 통해 공개될 새 비즈니스 기능을 개발할 예정입니다.
  • 계약 개발 팀은 Azure에 호스트되는 새로운 브라우저 기반 UI를 빌드할 예정입니다.

새 애플리케이션 기능은 단계별로 제공될 예정입니다. 이러한 기능은 이제 회사의 전자 상거래 비즈니스를 지원하는 기존 브라우저 기반 클라이언트/서버 UI 기능(온-프레미스에서 호스트됨)을 점진적으로 대체합니다.

관리 팀의 구성원은 불필요하게 현대화하고 싶지 않습니다. 범위 및 비용도 계속 제어할 수 있기를 원합니다. 이를 위해 기존 SOAP HTTP 서비스를 유지하기로 결정했습니다. 또한 기존 UI 변경을 최소화하려 합니다. Azure API Management를 사용하여 프로젝트의 많은 요구 사항 및 제약 조건을 해결할 수 있습니다.

잠재적인 사용 사례

이 시나리오에서는 레거시 브라우저 기반 소프트웨어 스택 현대화를 강조합니다.

이 시나리오를 사용하여 다음을 수행할 수 있습니다.

  • 비즈니스가 Azure 에코시스템을 사용하여 어떻게 이점을 얻을 수 있는지 알아보세요.
  • 서비스를 Azure로 마이그레이션할 계획을 세웁니다.
  • Azure로의 전환이 기존 API에 미치는 영향에 대해 알아봅니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 개선하는 데 도움이 되는 일련의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

가용성 및 확장성

  • 가격 책정 계층을 선택한 다음 단위를 추가하여 Azure API Management를 확장할 수 있습니다.
  • 크기 조정은 자동 크기 조정을 통해 자동으로 발생할 수도 있습니다.
  • 여러 지역에 배포하면 장애 조치(failover) 옵션을 사용할 수 있으며 프리미엄 계층에서 수행할 수 있습니다.
  • Azure Application Insights와 통합하는 방안을 고려해 보세요. 이렇게 하면 모니터링용 Azure Monitor을 통해 메트릭이 표시됩니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

API Management는 개발자, 기본, 표준 및 프리미엄의 네 가지 계층으로 제공됩니다. 이러한 계층의 차이점에 대한 자세한 지침은 Azure API Management 가격 책정 지침을 참조 하세요.

단위를 추가하고 제거하여 API Management의 크기를 조정할 수 있습니다. 각 단위의 용량은 해당 계층에 따라 다릅니다.

참고 항목

개발자 계층을 사용하여 API Management 기능을 평가할 수 있습니다. 프로덕션에 사용하지 마세요.

예상 비용을 보고 배포 요구 사항에 맞게 사용자 지정하려면 Azure 가격 계산기에서 배율 단위 및 App Service 인스턴스 수를 수정할 수 있습니다.

시나리오 배포

시작하려면 포털에서 Azure API Management 인스턴스를 만듭니다.

또는 해당 사용 사례와 일치하는 기존 Azure Resource Manager 빠른 시작 템플릿에서 선택할 수도 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

제품 설명서:

학습 모듈: