트래픽 분할

트래픽 분할을 사용하면 서비스 내 버전 두 개 이상에서 트래픽 분산 비율을 지정할 수 있습니다. 트래픽을 분할하면 버전 간 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 * 1000 = 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의 클라우드 인프라 내에서 전송되는 모든 사용자 요청의 경우 각 요청과 함께 사용자의 쿠키를 전달해야 합니다. 예를 들어 앱에서 다른 앱으로 또는 해당 앱 자체로 전송되는 요청에 사용자의 쿠키를 전달해야 합니다. 이러한 요청이 사용자로부터 발생하지 않는다면 내부 요청을 전송하지 않는 것이 좋습니다.

트래픽 분할 중지

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

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

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

Go 1.11용 App Engine 표준 환경 문서