게이트웨이 라우팅 패턴

단일 엔드포인트를 사용하여 여러 서비스 또는 서비스 인스턴스로 요청을 라우팅합니다. 이 패턴은 다음을 수행하려는 경우에 유용합니다.

• 단일 엔드포인트에서 여러 서비스를 노출하고 요청에 따라 적절한 서비스로 라우팅
• 부하 분산 또는 가용성을 위해 단일 엔드포인트에 동일한 서비스의 여러 인스턴스 노출
• 단일 엔드포인트에 동일한 서비스의 다른 버전을 노출하고 다른 버전에서 트래픽을 라우팅

컨텍스트 및 문제점

클라이언트가 여러 서비스, 여러 서비스 인스턴스 또는 둘의 조합을 사용해야 하는 경우 서비스가 추가되거나 제거될 때 클라이언트를 업데이트해야 합니다. 다음과 같은 시나리오를 고려해 보세요.

• 여러 서로 다른 서비스 - 전자상거래 애플리케이션은 검색, 리뷰, 카트, 체크 아웃, 주문 기록과 같은 서비스를 제공할 수 있습니다. 서비스마다 클라이언트가 조작해야 하는 다른 API가 있으며 클라이언트는 서비스에 연결하기 위해 각 엔드포인트에 대해 알고 있어야 합니다. API가 변경되면 클라이언트도 업데이트해야 합니다. 두 개 이상의 개별 서비스로 서비스를 리팩터링하는 경우 서비스와 클라이언트 둘 다에서 코드를 변경해야 합니다.
• 동일한 서비스의 여러 인스턴스 - 시스템은 동일하거나 다른 지역에서 동일한 서비스의 여러 인스턴스를 실행해야 할 수 있습니다. 부하 분산을 위해 또는 가용성 요구 사항을 충족하기 위해 여러 인스턴스를 실행할 수 있습니다. 수요를 충족하기 위해 인스턴스가 실행되거나 다운될 때마다 클라이언트를 업데이트해야 합니다.
• 동일한 서비스의 여러 버전 - 배포 전략의 일부로 서비스의 새 버전을 기존 버전과 함께 배포할 수 있습니다. 이를 블루 그린 배포라고 합니다. 이러한 시나리오에서는 새 버전 및 기존 엔드포인트로 라우팅되는 트래픽의 백분율이 변경될 때마다 클라이언트를 업데이트해야 합니다.

해결 방법

애플리케이션, 서비스 또는 배포 집합 앞에 게이트웨이를 배치합니다. 애플리케이션 계층 7 라우팅을 사용하여 요청을 적절한 인스턴스로 라우트합니다.

이 패턴을 사용하면 클라이언트 애플리케이션이 단일 엔드포인트에 대해 알고 단일 엔드포인트와 통신하면 됩니다. 다음은 게이트웨이 라우팅 패턴이 컨텍스트 및 문제 섹션에 설명된 세 가지 시나리오를 해결하는 방법을 보여 줍니다.

여러 서로 다른 서비스

게이트웨이 라우팅 패턴은 클라이언트가 여러 서비스를 사용하는 이 시나리오에서 유용합니다. 서비스를 통합하거나 분해하거나 바꾸는 경우 클라이언트에 반드시 업데이트가 필요한 것은 아닙니다. 게이트웨이를 계속 요청할 수 있으며 라우팅만 변경됩니다.

또한 게이트웨이를 통해 클라이언트의 백 엔드 서비스를 추상화하여 게이트웨이 뒤에 있는 백 엔드 서비스의 변경을 허용하는 동시에 클라이언트 호출을 단순하게 유지할 수 있습니다. 예상 클라이언트 동작을 처리해야 하는 어떤 서비스로든 클라이언트 호출을 라우트할 수 있으므로 클라이언트를 변경하지 않고 게이트웨이 뒤에 서비스를 추가, 분할 및 재구성할 수 있습니다.

동일한 서비스의 여러 인스턴스

탄력성은 클라우드 컴퓨팅의 핵심입니다. 서비스를 증가하는 수요를 충족하기 위해 스핀 업하거나 수요가 낮을 때 비용을 절감하기 위해 스핀 다운할 수 있습니다. 서비스 인스턴스 등록 및 등록 취소의 복잡성은 게이트웨이에 캡슐화됩니다. 클라이언트는 서비스 수의 증가 또는 감소를 인식하지 못합니다.

서비스 인스턴스는 단일 또는 여러 지역에 배포할 수 있습니다. 지오드 패턴은 여러 지역의 활성-활성 배포가 대기 시간을 개선하고 서비스의 가용성을 높이는 방법을 자세히 설명합니다.

동일한 서비스의 여러 버전

이 패턴은 업데이트가 사용자에게 롤아웃되는 방식을 관리할 수 있도록 하므로 배포에 사용될 수 있습니다. 새 버전의 서비스를 배포할 때 기존 버전과 함께 배포할 수 있습니다. 라우팅을 통해 클라이언트에게 제공되는 서비스 버전을 제어할 수 있으므로 증분, 병렬 또는 전체 업데이트 롤아웃 등 다양한 릴리스 전략을 유연하게 사용할 수 있습니다. 새 서비스를 배포한 후 문제가 발견될 경우 클라이언트에 영향을 주지 않고 게이트웨이에서 구성을 변경하여 빠르게 되돌릴 수 있습니다.

문제 및 고려 사항

• 게이트웨이 서비스에 단일 실패 지점이 발생할 수 있습니다. 가용성 요구 사항을 충족하도록 올바르게 설계되었는지 확인합니다. 구현 시 복원력과 내결함성 기능을 고려합니다.
• 게이트웨이 서비스로 인해 병목 상태가 발생할 수 있습니다. 게이트웨이가 부하를 처리할 수 있는 적절한 성능을 갖추고 있고 예상 증가량에 맞게 쉽게 확장될 수 있는지 확인합니다.
• 게이트웨이 부하 테스트를 수행하여 서비스가 연속으로 실패하지 않도록 합니다.
• 게이트웨이 라우팅은 수준 7입니다. IP, 포트, 헤더 또는 URL을 기반으로 할 수 있습니다.
• 게이트웨이 서비스는 전역적 또는 지역적일 수 있습니다. Azure Front Door는 전역 게이트웨이이지만 Azure Application Gateway는 지역 게이트웨이입니다. 솔루션에 서비스를 여러 지역에 배포해야 하는 경우 전역 게이트웨이를 사용합니다. 트래픽의 균형에 대한 세분화된 제어가 필요한 지역 워크로드가 있는 경우 Application Gateway를 사용하는 것이 좋습니다. 예를 들어 가상 머신 간에 트래픽의 균형을 맞추려고 합니다.
• 게이트웨이 서비스는 앞에 있는 서비스의 퍼블릭 엔드포인트입니다. 게이트웨이 또는 개인 가상 네트워크를 통해서만 서비스에 액세스할 수 있도록 하여 백 엔드 서비스에 대한 공용 네트워크 액세스를 제한하는 것이 좋습니다.

이 패턴을 사용해야 하는 경우

다음 경우에 이 패턴을 사용합니다.

• 클라이언트가 게이트웨이 뒤에서 액세스할 수 있는 여러 서비스를 이용해야 하는 경우.
• 단일 엔드포인트를 사용하여 클라이언트 애플리케이션을 간소화하려는 경우.
• VM의 포트를 클러스터 가상 IP 주소에 노출하는 경우와 같이 외부에서 주소 지정 가능한 엔드포인트에서 내부 가상 엔드포인트로 요청을 라우트해야 하는 경우.
• 클라이언트는 대기 시간 또는 가용성 이점을 위해 여러 지역에서 실행되는 서비스를 사용해야 합니다.
• 클라이언트는 다양한 수의 서비스 인스턴스를 사용해야 합니다.
• 클라이언트가 여러 버전의 서비스에 동시에 액세스하는 배포 전략을 구현하려고 합니다.

하나 또는 두 개의 서비스만 사용하는 단순 애플리케이션을 가진 경우에는 이 패턴이 적합하지 않을 수 있습니다.

워크로드 디자인

설계자는 게이트웨이 라우팅 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.

예시

Nginx를 라우터로 사용하는 다음 예는 다른 가상 디렉터리에 있는 애플리케이션에 대한 요청을 백 엔드의 다른 컴퓨터로 라우트하는 서버에 대한 단순한 예제 구성 파일입니다.

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

다음 Azure 서비스를 사용하여 게이트웨이 라우팅 패턴을 구현할 수 있습니다.

• 지역 계층-7 라우팅을 제공하는 Application Gateway 인스턴스.
• 전역 계층-7 라우팅을 제공하는 Azure Front Door 인스턴스.

관련 참고 자료

• 프런트 엔드에 대한 백 엔드 패턴
• 게이트웨이 집계 패턴
• 게이트웨이 오프로딩 패턴