편집

다음을 통해 공유

마이크로 서비스에서 API 게이트웨이 사용

Azure Application Gateway
Azure API Management

마이크로 서비스 아키텍처에서 클라이언트는 둘 이상의 프런트 엔드 서비스와 상호 작용할 수 있습니다. 이 사실을 감안할 때 클라이언트는 호출할 엔드포인트를 어떻게 알 수 있나요? 새 서비스가 도입되거나 기존 서비스가 리팩터링되면 어떻게 되나요? 서비스는 SSL 종료, 상호 TLS, 인증 및 기타 문제를 어떻게 처리합니까? API 게이트웨이 이러한 문제를 해결하는 데 도움이 될 수 있습니다.

API 게이트웨이다이어그램

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

API 게이트웨이란?

API 게이트웨이는 클라이언트와 애플리케이션 서비스 간의 상호 작용을 관리하기 위한 중앙 집중식 진입점을 제공합니다. 역방향 프록시 역할을 하며 클라이언트 요청을 적절한 서비스로 라우팅합니다. 인증, SSL 종료, 상호 TLS 및 속도 제한과 같은 다양한 교차 절단 작업을 수행할 수도 있습니다.

API 게이트웨이를 사용하는 이유는 무엇인가요?

API 게이트웨이는 통신을 간소화하고, 클라이언트 상호 작용을 향상시키며, 일반적인 서비스 수준 책임의 관리를 중앙 집중화합니다. 이는 중개자 역할을 하며 애플리케이션 서비스가 클라이언트에 직접 노출되는 것을 방지합니다. API 게이트웨이가 없으면 클라이언트는 개별 애플리케이션 서비스와 직접 통신해야 하므로 다음과 같은 문제가 발생할 수 있습니다.

  • 복잡한 클라이언트 코드: 복잡한 클라이언트 코드가 발생할 수 있습니다. 클라이언트는 여러 엔드포인트를 추적하고 오류를 탄력적으로 처리해야 합니다.

  • 꽉 결합: 클라이언트와 백 엔드 간에 결합을 만듭니다. 클라이언트는 개별 서비스의 분해, 복잡한 서비스 유지 관리 및 리팩터링을 이해해야 합니다.

  • 대기 시간증가: 단일 작업을 수행하려면 여러 서비스에 대한 호출이 필요할 수 있습니다. 그 결과 클라이언트와 서버 간에 여러 네트워크 왕복이 발생할 수 있으므로 대기 시간이 상당히 늘어나게 됩니다.

  • 우려 사항의 중복 처리: 각 공용 서비스는 인증, SSL 및 클라이언트 속도 제한과 같은 문제를 처리해야 합니다.

  • 프로토콜 제한: 서비스는 HTTP 또는 WebSocket과 같은 클라이언트 친화적인 프로토콜을 노출해야 합니다. 이 노출은 통신 프로토콜 옵션을 제한합니다.

  • 확장된 공격 노출 영역: 퍼블릭 엔드포인트는 잠재적인 공격 표면을 증가시키고 강화가 필요합니다.

API 게이트웨이를 사용하는 방법

API 게이트웨이는 특정 디자인 패턴을 사용하여 애플리케이션의 요구 사항에 맞게 조정할 수 있습니다. 이러한 디자인 패턴은 라우팅, 요청 집계 및 교차 절단 문제와 같은 주요 기능을 해결합니다.

  • 게이트웨이 라우팅 . API 게이트웨이를 역방향 프록시로 사용하여 클라이언트 요청을 다른 애플리케이션 서비스로 라우팅할 수 있습니다. API 게이트웨이는 계층 7 라우팅을 사용하고 클라이언트가 사용할 단일 엔드포인트를 제공합니다. 애플리케이션 서비스에서 클라이언트를 분리하려는 경우 API 게이트웨이 라우팅을 사용합니다.

  • 게이트웨이 집계. API 게이트웨이를 사용하여 여러 클라이언트 요청을 단일 요청으로 집계할 수 있습니다. 단일 작업에서 여러 애플리케이션 서비스에 대한 호출이 필요한 경우 이 패턴을 사용합니다. API 집계에서 클라이언트는 API 게이트웨이에 하나의 요청을 보냅니다. 그런 다음, API 게이트웨이는 요청을 작업에 필요한 다양한 서비스로 라우팅합니다. 마지막으로, API 게이트웨이는 결과를 집계하고 클라이언트로 다시 보냅니다. 집계는 클라이언트와 애플리케이션 서비스 간의 대화 시간을 줄이는 데 도움이 됩니다.

  • 게이트웨이 오프로드. API 게이트웨이를 사용하여 교차 절단 기능을 제공할 수 있으므로 개별 서비스에서 제공할 필요가 없습니다. 모든 서비스를 책임지게 하는 대신 교차 절단 기능을 한 곳으로 통합하는 것이 유용할 수 있습니다. API 게이트웨이로 오프로드할 수 있는 기능의 예는 다음과 같습니다.

    • SSL 종료
    • 상호 TLS
    • 인증
    • IP 허용 목록 또는 차단 목록
    • 클라이언트 속도 제한(제한)
    • 로깅 및 모니터링
    • 응답 캐싱
    • 웹 애플리케이션 방화벽
    • GZIP 압축
    • 정적 콘텐츠 서비스

API 게이트웨이 옵션

애플리케이션에서 API 게이트웨이를 구현하기 위한 몇 가지 옵션은 다음과 같습니다.

  • 역방향 프록시 서버. Nginx 및 HAProxy는 오픈 소스 역방향 프록시 제품입니다. 부하 분산, SSL 종료 및 계층 7 라우팅과 같은 기능을 지원합니다. 추가 기능 및 지원 옵션을 제공하는 무료 버전 및 유료 버전이 있습니다. 이러한 제품은 풍부한 기능 집합, 고성능 및 확장성으로 완성도를 높입니다.

  • 서비스 메시 수신 컨트롤러. 서비스 메시를 사용하는 경우 해당 서비스 메시와 관련된 수신 컨트롤러의 기능을 평가합니다. Istio 및 Open Service Mesh와 같은 AKS 지원 추가 기능을 확인합니다. 링커드 또는 Consul Connect와 같은 타사 오픈 소스 프로젝트를 찾습니다. 예를 들어 Istio 수신 컨트롤러는 계층 7 라우팅, HTTP 리디렉션, 재시도 및 기타 기능을 지원합니다.

  • Azure Application Gateway. Application Gateway는 관리되는 부하 분산 서비스입니다. 계층 7 라우팅, SSL 종료 및 WAF(웹 애플리케이션 방화벽)를 제공합니다.

  • Azure Front Door. Azure Front Door는 CDN(콘텐츠 배달 네트워크)입니다. 전역 및 로컬 POP(현재 상태 지점)를 사용하여 애플리케이션의 정적 및 동적 웹 콘텐츠에 대한 빠르고 안정적이며 안전한 액세스를 전역적으로 제공합니다.

  • Azure API Management. API Management는 외부 및 내부 고객에게 API를 게시하기 위한 관리되는 솔루션입니다. Microsoft Entra ID 또는 기타 ID 공급자를 사용하여 속도 제한, IP 제한 및 인증을 포함하여 공용 API를 관리하는 기능을 제공합니다. API Management는 부하 분산을 수행하지 않으므로 Azure Application Gateway 또는 역방향 프록시와 같은 부하 분산 장치에서 사용해야 합니다. 자세한 내용은 Azure Application Gateway API Management를 참조하세요.

API 게이트웨이 기술 선택

API 게이트웨이를 선택할 때 다음 요소를 고려합니다.

  • 모든 요구 사항을 지원합니다. 필요한 기능을 지원하는 API 게이트웨이를 선택합니다. 이전의 모든 API 게이트웨이 옵션은 계층 7 라우팅을 지원할 있습니다. 그러나 인증, 속도 제한 및 SSL 종료와 같은 다른 기능에 대한 지원은 다를 수 있습니다. 단일 게이트웨이가 요구 사항을 충족하는지 또는 여러 게이트웨이가 필요한지 평가합니다.

  • 기본 제공 제품을 선호합니다. 보안 및 제어 요구 사항을 충족할 때마다 Azure Container Apps 및 AKS와 같은 플랫폼에서 제공하는 기본 제공 API 게이트웨이 및 수신 솔루션을 사용합니다. 기본 제공 옵션에 필요한 유연성이 부족한 경우에만 사용자 지정 게이트웨이를 사용합니다. 사용자 지정 솔루션의 수명 주기를 효과적으로 관리하려면 GitOps와 같은 거버넌스 모델이 필요합니다.

  • 올바른 배포 모델을 선택합니다. 운영 오버헤드를 줄이기 위해 Azure Application Gateway 및 Azure API Management와 같은 관리되는 서비스를 사용합니다. 범용 역방향 프록시 또는 부하 분산 장치를 사용하는 경우 아키텍처에 맞는 방식으로 배포합니다. 범용 API 게이트웨이를 전용 가상 머신에 배포하거나 수신 컨트롤러 제품의 AKS 클러스터 내에 배포할 수 있습니다. 워크로드에서 API 게이트웨이를 격리하려면 클러스터 외부에 배포할 수 있지만, 이 배포로 관리 복잡성이 증가합니다.

  • 변경 내용을 관리합니다. 서비스를 업데이트하거나 새 서비스를 추가할 때 게이트웨이 라우팅 규칙을 업데이트해야 할 수 있습니다. 서비스, SSL 인증서, IP 허용 목록 및 보안 구성을 추가하거나 수정할 때 라우팅 규칙을 관리하는 프로세스 또는 워크플로를 구현합니다. 코드로서의 인프라 및 자동화 도구를 사용하여 API 게이트웨이 관리를 간소화합니다.

다음 단계

이전 문서에서는 마이크로 서비스와 마이크로 서비스 및 클라이언트 애플리케이션 간의 인터페이스를 살펴보했습니다. 이러한 인터페이스는 각 서비스를 자체 포함된 불투명 단위로 처리합니다. 마이크로 서비스 아키텍처의 중요한 원칙은 서비스가 데이터를 관리하는 방법에 대한 내부 세부 정보를 노출해서는 안 된다는 것입니다. 이 방법은 다음 문서의 주제인 데이터 무결성 및 일관성을 유지하는 데 상당한 영향을 미칩니다.

마이크로 서비스 대한 데이터 고려 사항