트래픽 분할

트래픽 분할을 사용하면 서비스 내 버전 두 개 이상에서 트래픽 분산 비율을 지정할 수 있습니다. 트래픽을 분할하면 버전 간 A/B 테스트를 수행할 수 있으며, 기능을 배포할 때 속도를 제어할 수 있습니다.

트래픽 분할은 특정 버전을 명시적으로 타겟팅하지 않는 URL에 적용됩니다. 예를 들어 다음 URL은 지정된 서비스 내에서 사용 가능한 모든 버전을 타겟팅하기 때문에 트래픽을 분할합니다.

  • [MY_PROJECT].appspot.com - 트래픽을 default 서비스의 여러 버전으로 분산합니다.
  • [MY_SERVICE].[MY_PROJECT].appspot.com - 트래픽을 [MY_SERVICE] 서비스의 여러 버전으로 분산합니다.

요청이 특정 버전에 도달하는 방법에 대한 자세한 내용은 요청 라우팅 방법을 참조하세요.

시작하기 전에

특정 버전에 대한 트래픽을 구성하려면 먼저 사용자 계정에 필수 권한이 있는지 확인합니다.

캐싱 문제 방지

트래픽 분할을 사용하기 전에 발생할 수 있는 캐싱 문제를 고려해야 합니다. 캐싱 문제는 특히 새 버전을 배포할 때 모든 App Engine 애플리케이션에서 발생할 수 있습니다. 트래픽 분할을 사용하면 감지하기 어려운 캐싱 문제가 명확하게 드러나는 경우가 많습니다.

예를 들어 A와 B의 두 버전 간에 트래픽을 분할하는 중이고, 두 버전 사이에 CSS 파일과 같이 외부의 캐싱할 수 있는 리소스가 약간 변경되었다고 가정합니다. 이제 클라이언트가 요청을 수행하고, 응답에는 캐싱된 파일에 대한 외부 참조가 포함된다고 가정합니다. 로컬 HTTP 캐시는 파일의 어떤 버전이 캐시되었는지, 애플리케이션의 어떤 버전이 응답을 보냈는지에 관계없이 파일이 캐시에 있다면 해당 파일을 가져옵니다. 따라서 캐싱된 리소스는 응답으로 전송된 데이터와 호환되지 않을 수 있습니다.

캐싱 문제를 방지하려면 다음 안내를 따르세요.

  • 동적 리소스의 경우 Cache-ControlExpires 헤더를 모두 설정합니다. 이러한 헤더는 리소스가 동적임을 프록시에 알립니다. 모든 프록시 서버가 HTTP/1.1 Cache-Control 헤더를 올바르게 지원하는 것은 아니므로 두 가지 헤더를 모두 설정하는 것이 가장 좋습니다.

    일반적인 캐싱에 대해 자세히 알아보려면 HTTP/1.1 RFC의 헤더 필드브라우저 보안 안내의 문서 캐싱을 참조하세요.

  • 캐시 가능한 정적 리소스가 버전마다 달라지는 경우 버전 간에 리소스의 URL을 변경합니다. 정적 리소스가 서로 다른 URL에서 제공되는 경우에는 두 버전 모두 프록시 서버와 브라우저 캐시에 문제 없이 공존할 수 있습니다.

요청의 쿠키와 URL을 조합하여 리소스의 고유성을 판정하도록 앱에서 Vary: Cookie 헤더를 설정할 수도 있습니다. 그러나 이 방식은 캐시 서버의 부담을 증가시킵니다. GOOGAPPUID는 가능한 값이 1,000개이므로 앱의 각 URL에 1,000개의 항목을 사용할 수 있습니다. 사용자와 앱 사이의 프록시 부하에 따라 캐시 적중률이 낮아질 수 있습니다. 새로운 사용자 배치를 특정 버전에 추가한 후 24시간 동안은 캐싱된 리소스가 계속 표시될 수도 있습니다. 그러나 Vary: Cookie를 사용하면 버전 간에 변경되는 정적 리소스의 이름을 바꾸기가 쉬워집니다.

Vary: Cookie 방법이 모든 상황에 적용되는 것은 아닙니다. 일반적으로 앱에서 다른 용도로 쿠키를 사용하는 경우 프록시 서버에 얼마나 부담을 주는지를 고려해야 합니다. codeninja에 자체 쿠키가 있으며 가능한 값이 100개라면 가능한 모든 캐시 항목의 공간이 매우 커집니다(100 x 1,000 = 100,000). 최악의 경우에는 사용자마다 고유한 쿠키가 존재할 수 있습니다. 이에 대한 일반적인 두 가지 예로는 Google 애널리틱스(__utma)와 SiteCatalyst(s_vi)가 있습니다. 이 경우 모든 사용자가 고유한 사본을 갖게 되어 캐시 성능이 심각하게 저하되고 앱이 소비하는 유료 인스턴스 시간도 늘어납니다.

여러 버전으로 트래픽 분할

분할할 버전을 두 개 이상 지정한 경우 트래픽 분할에 IP 주소를 사용할지 아니면 HTTP 쿠키를 사용할지를 선택해야 합니다. IP 주소 분할은 설정하기가 쉽지만, 쿠키 분할의 정밀도가 더 높습니다. 자세한 내용은 IP 주소 분할쿠키 분할을 참조하세요.

콘솔

GCP 콘솔에서 트래픽을 분할하려면 버전 페이지로 이동합니다.

버전 페이지로 이동

  1. 트래픽을 분할할 버전을 하나 이상 선택합니다.
  2. 트래픽 분할을 클릭한 후 다음을 지정합니다.
    • 트래픽 분할에 사용할 방법
    • 각 버전이 수신해야 하는 트래픽 비율

gcloud

Google Cloud SDK를 설치한 후 다음 명령어를 실행하여 트래픽을 여러 버전으로 분할합니다. 예:

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

자세한 내용 및 추가 옵션은 gcloud app services set-traffic 참조를 확인하세요.

API

트래픽을 프로그래매틱 방식으로 이전하려면 Admin API를 사용하면 됩니다. 자세한 내용은 트래픽 이전 및 분할을 참조하세요.

IP 주소 분할

애플리케이션에 대한 트래픽을 IP 주소에 따라 분할하는 경우 애플리케이션은 요청을 수신할 때 IP 주소를 0~999 사이의 값으로 해시하고 이 숫자를 사용하여 요청을 라우팅합니다.

IP 주소 분할에는 몇 가지 중요한 제한사항이 있습니다.

  • IP 주소는 어느 정도 고정되어 있지만 영구적이지 않습니다. 사용자가 휴대전화에서 연결하는 경우 단일 세션 중에 IP 주소가 변동될 수 있습니다. 마찬가지로 노트북 사용자가 작업하면서 집에서 카페로 이동했다면 IP 주소가 변동됩니다. 따라서 IP 주소가 바뀜에 따라 사용자의 앱 사용 환경이 달라질 수 있습니다.
  • IP 주소는 여러 버전에 독립적으로 할당되므로 트래픽 분할 결과는 사용자가 지정한 비율과 약간 달라집니다. 하지만 애플리케이션이 트래픽을 많이 수신할수록 실제 분할이 목표와 더 가까워집니다. 예를 들어 트래픽의 5%가 대체 버전으로 전달되도록 요청하는 경우 해당 버전에 대한 초기 트래픽 비율이 실제로는 3~7% 사이일 수 있지만 결국 평균은 목표인 5%에 가깝습니다.
  • 앱 간에 내부 요청을 전송해야 하는 경우 쿠키 분할을 대신 사용해야 합니다. Google의 클라우드 인프라에서 실행되는 앱 간에 전송되는 요청은 적은 수의 IP 주소에서 발생하므로 모두 동일한 버전에 할당될 가능성이 높습니다. 즉, 모든 내부 요청이 단일 IP 주소에서 전송되는 요청과 비슷하게 작동하여 모두 동일한 버전으로 라우팅될 수 있습니다. 이로 인해 내부 요청에는 사용자가 IP 기반 트래픽 분할에 설정한 비율이 정확히 반영되지 않습니다. 예를 들어 특정 버전이 앱에 대한 모든 트래픽 중 1%를 수신하도록 설정했는데 Google 클라우드 인프라 주소가 우연히 해당 버전에 할당되었다면, 모든 내부 요청이 항상 해당 버전으로 라우팅되므로 실제 결과는 1%를 크게 초과할 수 있습니다. Google의 클라우드 인프라 외부에서 앱으로 전송하는 요청은 다양하게 분포된 IP 주소에서 발생하므로 예상대로 작동합니다.

애플리케이션에 대한 트래픽을 쿠키에 따라 분할하는 경우 애플리케이션은 HTTP 요청 헤더에서 이름이 GOOGAPPUID인 쿠키를 찾으며, 이 쿠키에는 0~999 사이의 값이 포함됩니다.

  • 쿠키가 있으면 이 값을 사용하여 요청을 라우팅합니다.
  • 해당 쿠키가 없으면 요청이 무작위로 라우팅됩니다.

응답에 GOOGAPPUID 쿠키가 없으면 앱은 먼저 0~999 사이의 무작위 값으로 GOOGAPPUID 쿠키를 추가한 후 응답을 전송합니다.

쿠키에 따라 트래픽을 분할하면 사용자를 각 버전에 정확히 할당하기가 쉬워집니다. 트래픽 라우팅의 정밀도는 목표 분할에 0.1%까지 근접할 수 있습니다. 그러나 쿠키 분할에는 다음과 같은 제한사항이 있습니다.

  • 모바일 앱을 작성하거나 데스크톱 클라이언트를 실행하는 경우 GOOGAPPUID 쿠키를 관리해야 합니다. 예를 들어 Set-Cookie 응답 헤더가 사용된 경우 쿠키를 저장한 후 모든 후속 요청에 포함해야 합니다. 브라우저 기반 앱은 이미 이러한 방식으로 쿠키를 자동으로 관리합니다.

  • 내부 요청을 분할하려면 추가 작업을 수행해야 합니다. Google의 클라우드 인프라 내에서 사용자 요청을 보내는 경우 항상 각 요청과 함께 사용자 쿠키를 전달해야 합니다. 예를 들어 앱에서 다른 앱으로, 또는 앱 자체로 요청을 전송할 때 사용자의 쿠키를 전달해야 합니다. 사용자가 보낸 요청이 아니라면 내부 요청을 전송하지 않는 것이 좋습니다.

트래픽 분할 중지

트래픽 분할을 중지하려면 모든 트래픽을 단일 버전으로 이전합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Node.js 문서용 App Engine 가변형 환경