리전 ID
REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google에서 할당하는 축약된 코드입니다. 일부 리전 ID는 일반적으로 사용되는 국가 및 주/도 코드와 비슷하게 표시될 수 있지만 코드는 국가 또는 주/도와 일치하지 않습니다. 2020년 2월 이후에 생성된 앱의 경우 REGION_ID.r이 App Engine URL에 포함됩니다. 이 날짜 이전에 만든 기존 앱의 경우 URL에서 리전 ID는 선택사항입니다.
리전 ID에 대해 자세히 알아보세요.
트래픽 분할을 사용하면 서비스 내 버전 두 개 이상에 트래픽 분산 비율을 지정할 수 있습니다. 트래픽을 분할하면 버전 간 A/B 테스트를 할 수 있으며, 기능을 배포할 때 속도를 제어할 수 있습니다.
트래픽 분할은 특정 버전을 명시적으로 대상으로 하지 않는 URL에 적용됩니다. 예를 들어 다음 URL은 지정된 서비스 내에서 사용할 수 있는 모든 버전을 타겟팅하므로 트래픽을 분할합니다.
https://PROJECT_ID.REGION_ID.r.appspot.com- 트래픽을default서비스의 여러 버전으로 분산합니다.https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com- 트래픽을[SERVICE_ID]서비스의 여러 버전으로 분산합니다.
요청이 버전에 도달하는 방법에 대한 자세한 내용은 요청 라우팅 방법을 참조하세요.
시작하기 전에
트래픽이 특정 버전으로 이동하도록 구성하려면 먼저 사용자 계정에 필수 권한이 있는지 확인해야 합니다.
캐싱 문제 방지
트래픽 분할을 설정하기 전에 잠재적인 캐싱 문제가 있는지 확인해야 합니다. 특히 App Engine 앱의 새 버전을 배포할 때 캐싱 문제가 발생할 수 있습니다. 트래픽 분할을 통해 숨겨진 캐싱 문제가 더 분명하게 드러나기도 합니다.
예를 들어 A와 B라는 두 버전 사이의 트래픽을 분할하는 중에 외부의 캐싱 가능한 리소스(예: CSS 파일)가 두 버전 간에 변경되었다고 가정해 보겠습니다. 그런 다음 클라이언트가 요청을 실행하면 응답에 캐시된 파일에 대한 외부 참조가 포함된다고 가정합니다. 캐시된 파일 버전과 응답을 전송한 애플리케이션 버전에 관계없이 로컬 HTTP 캐시는 파일이 캐시에 있는 경우 해당 파일을 검색합니다. 따라서 캐시된 리소스가 응답에 전송된 데이터와 호환되지 않을 수 있습니다.
캐싱 문제를 방지하려면 다음 안내를 따르세요.
동적 리소스의 경우 Cache-Control 및 Expires 헤더를 모두 설정합니다. 이러한 헤더는 리소스가 동적임을 프록시에 알립니다. 모든 프록시 서버가 HTTP/1.1
Cache-Control헤더를 제대로 지원하는 것은 아니므로 두 헤더 모두 설정하는 것이 가장 좋습니다.일반적인 캐싱에 대한 자세한 내용은 HTTP/1.1 RFC의 헤더 필드 및 웹 기초의 HTTP 캐싱 개요를 참조하세요.
버전마다 다른 캐싱 가능한 정적 리소스의 경우 버전 간에 리소스 URL을 변경합니다. 정적 리소스가 서로 다른 URL로 제공되는 경우에는 두 버전이 모두 프록시 서버와 브라우저 캐시에 문제 없이 공존할 수 있습니다.
또한 요청에서 쿠키와 URL을 조합하여 리소스의 고유성을 계산할 수 있도록 앱에서 Vary: Cookie 헤더를 설정할 수 있습니다. 하지만 이러한 접근 방식은 캐시 서버에 부담을 가중시킵니다. GOOGAPPUID 값이 1,000개까지 있을 수 있으므로 앱의 각 URL마다 항목이 1000개까지 있을 수 있습니다. 따라서 사용자와 앱 사이의 프록시 부하에 따라 캐시 적중률이 낮아질 수 있습니다. 또한 새로운 사용자 배치를 버전에 추가하면 캐시된 리소스가 해당 사용자에게 24시간 동안 계속 표시될 수 있습니다. 하지만 Vary: Cookie를 사용하면 버전 간 변경되는 정적 리소스의 이름을 보다 쉽게 바꿀 수 있습니다.
Vary: Cookie 기법이 모든 상황에서 적용되는 것은 아닙니다. 일반적으로 앱이 다른 목적으로 쿠키를 사용할 경우에는 프록시 서버가 받는 영향을 고려해야 합니다. codeninja에 값이 100개까지 있을 수 있는 고유한 쿠키가 포함된 경우 가능한 모든 캐시 항목의 공간이 매우 커집니다(100 * 1,000 = 100,000). 최악의 경우에는 모든 사용자마다 고유한 쿠키가 있을 수 있습니다. 이에 대한 두 가지 일반적인 예시로 Google 애널리틱스(__utma)와 SiteCatalyst(s_vi)가 있습니다. 이러한 경우 모든 사용자가 고유한 복사본을 갖게 되어 캐시 성능이 심각하게 저하되고 앱에서 소비되는 청구될 수 있는 인스턴스 시간도 늘어납니다.
여러 버전 간 트래픽 분할
분할하기 위해 버전을 두 개 이상 지정한 경우에는 트래픽을 분할하는 데 발신자 IP 주소나 HTTP 쿠키를 사용할지 여부를 선택합니다. IP 주소 분할을 설정하는 것이 더 쉽지만 쿠키 분할이 더 정확합니다. 자세한 내용은 IP 주소 분할과 쿠키 분할을 참조하세요.
콘솔
Google Cloud 콘솔에서 트래픽을 분할하려면 버전 페이지로 이동합니다.
- 트래픽을 분할할 버전을 한 개 이상 선택합니다.
- 트래픽 분할을 클릭한 후 다음을 지정합니다.
- 트래픽 분할에 사용할 메서드
- 각 버전이 수신하는 트래픽 백분율
gcloud
Google Cloud CLI를 설치한 후 다음 명령어를 실행하여 여러 버전 간에 트래픽을 분할합니다. 예를 들면 다음과 같습니다.
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 클라우드 인프라 내에서 전송되는 모든 사용자 요청은 각 요청에 사용자의 쿠키를 전달해야 합니다. 예를 들어 다음과 같이 앱에서 다른 앱으로 또는 앱 자체로 전송되는 요청에서 사용자의 쿠키를 전달해야 합니다. 내부 요청이 사용자로부터 발생하지 않는다면 이러한 요청을 전송하지 않는 것이 좋습니다.
트래픽 분할 중지
트래픽 분할을 중지하려면 모든 트래픽을 단일 버전으로 마이그레이션합니다.