이 페이지에서는 Cloud Endpoints API 버전 관리 기능을 설명하고 Endpoints API 버전 관리 및 스테이징의 권장사항을 제공합니다. 이 페이지의 정보는 OpenAPI 사양을 사용하는 API에 적용됩니다. App Engine 표준 환경용 Cloud Endpoints 프레임워크를 사용하는 API는 API 버전 관리 처리: 자바 또는 API 버전 관리 처리: Python을 참조하세요.
API 버전 관리 및 서비스 스테이징을 위해 Google에서 사용되는 동일한 기본 원칙을 따르는 것이 좋습니다.
최초 버전을 배포하기 전에 OpenAPI 구성 파일에 다음을 포함합니다.
info.version필드에서 버전 번호를 설정합니다. 주 버전과 부 버전이 포함된 버전 문자열(예:1.0)을 사용하는 것이 좋습니다.- 주 버전 번호를 포함하도록
basePath필드를 설정합니다.v문자 뒤에 주 버전 번호가 있는 기본 경로 형식(예:/v1)을 사용하는 것이 좋습니다.
새 메서드 추가와 같이 이전 버전과 호환되는 변경을 수행해야 하는 경우에는
info.version필드에서 부 버전 번호(예: 1.2, 1.3)를 증가시키고 다시 배포합니다. 자세한 내용은 API 버전 관리를 참조하세요.기존 메서드에 대한 변경사항이 클라이언트 코드에 문제를 일으키는 경우에는 OpenAPI 구성 파일을 복사하고 다음과 같이 변경합니다.
info.version필드에서 주 버전 번호(예: 2.0, 3.0)를 증가시킵니다.basePath필드에서 주 버전 번호(예: /v2, /v3)를 증가시킵니다.
OpenAPI 구성 파일의 두 버전을 배포하고 백엔드를 다시 배포합니다. 이제 메서드의 두 버전이 모두 포함됩니다. 자세한 내용은 API 버전 관리를 참조하세요.
단일 백엔드에서 모든 주 API 버전을 구현합니다. 권장사항은 다음과 같습니다.
- 특정 버전에 대한 요청은 경로를 토대로 하므로 위 예와 같이 라우팅을 간소화합니다.
- 구성 및 배포를 간소화합니다. API의 모든 주 버전에 동일한 Google Cloud 프로젝트와 백엔드를 사용하고 모든 API 버전을 동시에 배포합니다.
- 너무 많은 백엔드 실행을 방지하여 비용을 줄입니다.
프로덕션 Google Cloud 프로젝트에 배포하기 전에 개별 Google Cloud 프로젝트에서 API를 스테이징합니다. 자세한 내용은 서비스 스테이징을 참조하세요.
Endpoints에서 사용되는 주 버전 번호 및 부 버전 번호는 체계적인 버전 관리에 있는 정의를 따릅니다. Endpoints는 백엔드 코드의 버그 수정을 배포할 때 OpenAPI 구성 파일의 패치 버전 번호를 높이고 구성을 배포하도록 규정하지 않지만, 필요하다면 그렇게 할 수 있습니다.
Cloud Endpoints API 버전 관리 기능
Extensible Service Proxy(ESP)에는 API의 경로가 겹치지 않는 한 단일 Google Cloud 프로젝트와 백엔드에 속한 API의 여러 주 버전을 동시에 관리하는 기능이 있습니다. 예를 들면 다음과 같습니다.
http://echo-api.endpoints.my-project.cloud.goog/v1/echo
http://echo-api.endpoints.my-project.cloud.goog/v2/echo
따라서 고객은 사용할 버전을 자유롭게 선택하고 새 버전으로 이전하는 시점을 제어할 수 있습니다. ESP는 백엔드의 해당 메소드로 요청을 라우팅하기 전에 각 요청에 버전 번호를 태그로 지정합니다. 각 요청에 버전 번호가 태그로 지정되었으므로, 다음이 수행됩니다.
Endpoints > 서비스의 그래프와 로그에 주 API 버전 각각에서 들어오는 요청 및 모든 버전을 집계한 합이 표시됩니다. 보기를 특정 버전으로 필터링할 수 있습니다. 그러면 각 버전이 사용 중인 트래픽 양을 명확하게 확인할 수 있습니다. 로그에서 어떤 클라이언트가 어떤 버전을 사용하는지도 확인할 수 있습니다.
부 버전 번호를 업데이트하여 API를 다시 배포하면 그래프 및 로그에서 이후 작업에 새 버전 번호로 라벨이 지정됩니다. 이를 통해 라벨로 표시된 배포 기록을 확인할 수 있습니다.
API 버전을 삭제하면 해당 API가 사용된 시간 범위의 데이터가 그래프 및 로그에 계속 표시됩니다.
API 수명 주기 예
이 섹션에서는 서비스의 일반적인 발전 과정을 설명합니다.
버전 1
My Awesome Echo API 서비스의 버전 1을 최초로 배포합니다. API는 my-api.endpoints.my‐awesomeproject.cloud.goog/v1/echo에서 제공됩니다. Endpoints > 서비스의 그래프 및 로그에서 모든 트래픽이 1.0으로 확인됩니다.
버전 1.1
고객이 새로운 기능을 요청하여 새 메서드를 추가합니다. OpenAPI 구성 파일에서 새 메서드를 추가하고 info.version 필드를 1.1로 증가시킵니다. 이 변경사항은 클라이언트 코드에 문제를 일으키지 않으므로 부 버전 번호를 증가시킵니다. 스테이징 환경에서 변경 사항을 배포하고 테스트하여 작동하는지 확인합니다.
그런 다음 OpenAPI 구성과 API 백엔드를 프로덕션 환경에 배포합니다. API가 여전히 my-api.endpoints.my‐awesomeproject.cloud.goog/v1/echo에서 제공되지만 호출자는 이제 새 메서드에 요청을 수행할 수 있습니다. 이전 메서드에 대한 인터페이스를 변경하지 않았으므로 고객은 클라이언트를 변경하여 재배포할 필요가 없습니다. 클라이언트는 이전과 동일하게 이전 메서드로 요청을 계속 보낼 수 있습니다.
Endpoints > 서비스에서 제공되는 트래픽이 이제 1.1 버전으로 표시됩니다. 이전 시간 범위를 선택하여 표시하면 그래프 및 로그에 이전 버전이 표시되므로 라벨이 지정된 배포 기록을 확인할 수 있습니다.
버전 2.0
시간이 경과하면 이전 버전과 호환되지 않는 방식으로 기존 메서드를 변경해야 한다는 것을 알게 됩니다. 고객의 클라이언트 코드가 손상되지 않는 것이 중요하므로 API를 두 가지 버전으로 유지보수하기로 결정합니다. 이전 메서드는 그대로 놔두고 새 버전의 메서드를 구현합니다. 버전 2.0에 또 다른 OpenAPI 구성 파일을 만들고 새 버전이 my-api.endpoints.my‐awesomeproject.cloud.goog/v2/echo에서 제공되도록 구성합니다. 원래 OpenAPI 구성 파일은 여전히 이전 버전의 메서드에 연결되지만 새로운 OpenAPI 구성 파일은 새 버전의 메서드에 연결됩니다.
버전 1 및 버전 2의 OpenAPI 구성 파일을 동시에 배포하고, 백엔드를 다시 배포하여 두 버전의 메소드가 포함되도록 합니다. 자세한 내용은 API 버전 관리를 참조하세요.
배포 후에는 Endpoints > 서비스에 두 가지 버전의 API가 제공되고 있는 것으로 표시되고, 각 버전이 사용하는 트래픽 양을 확인할 수 있습니다. v1 클라이언트는 /v1을 계속 호출할 수 있지만 /v2를 호출하여 새 버전의 메서드를 사용할 수도 있습니다. 백엔드 코드에서 버전 관리를 처리하는 방법은 사용 중인 API 프레임워크에 따라 다릅니다. 서블릿을 사용하는 예시는 여러 버전이 포함된 Endpoints 및 자바 샘플을 참조하세요.
버전 1 중지
시간이 지나서 클라이언트가 이전되고 v1에 대한 모든 트래픽이 중지된 것으로 확인되면, v1 제공을 중지할 수 있습니다. 버전 1의 API를 삭제하려면 버전 2 OpenAPI 구성 파일만 배포하고 백엔드를 다시 배포합니다. 이제 백엔드에서 버전 1을 구현했던 코드를 안전하게 삭제할 수 있습니다. Endpoints > 서비스에는 버전 1.x의 기록 데이터가 보존됩니다.
서비스 스테이징
고객에게 서비스를 배포하기 전에 테스트할 수 있도록 Endpoints 서비스에 대한 업데이트를 스테이징하는 것이 좋습니다. 또한 프로덕션과의 격리를 위해 서비스 스테이징용 Google Cloud 프로젝트를 별도로 만드는 것이 좋습니다. 예를 들어 Google 할당량은 일반적으로 프로젝트 내의 리소스를 통해 공유됩니다. 따라서 스테이징 서비스를 프로덕션 서비스와 동일한 프로젝트에 넣으면 잘못된 루프 등으로 인해 프로덕션 서비스가 중단될 수 있습니다.
Google Cloud 프로젝트 이름을 스테이징용임을 명확하게 나타내는 이름으로 지정하는 것이 좋습니다. 일반적인 명명법은 프로덕션 Google Cloud 프로젝트 이름을 그대로 사용하면서 뒤에 -staging을 붙이는 방법입니다.
또한 프로젝트에 프로덕션 서비스가 포함되었음을 명시하기 위해 프로덕션 프로젝트에 -prod를 붙일 수도 있습니다.
Google Cloud의 서비스 이름은 고유해야 합니다. OpenAPI 구성 파일에서 서비스 이름을 지정하므로 스테이징 및 프로덕션 프로젝트에 별도의 API 구성 파일을 유지보수하거나, API 구성 파일 집합 한 개를 사용하고 배포 중인 프로젝트의 이름과 일치하도록 서비스 이름을 변경하는 프로세스를 고안해야 합니다.