이 문서에서는 API 관리 다운타임이나 데이터 손실 없이 Apigee 인스턴스를 다시 만드는 방법을 설명합니다.
소개
2022년 1월 25일 전에 생성된 Apigee 인스턴스는 증가하는 API 트래픽을 처리하거나 인스턴스에 10개가 넘는 환경을 추가할 수 있도록 Apigee 워크로드를 확장하는 데 충분한 인터넷 프로토콜(IP) 주소 공간을 가지고 있지 않습니다.
2022년 1월 24일, Apigee는 이 문제를 해결하기 위해 개선 사항을 소개했습니다. 개선 사항은 Apigee로 VPC 네트워크를 피어링하는 데 필요한 IP 범위를 줄이고, 비공개로 사용되는 공개 IP(PUPI)를 사용하여 워크로드가 더 높은 한도로 확장할 수 있도록 합니다.
필요한 작업
2022년 1월 25일 이전에 생성된 Apigee 인스턴스가 있으면 이 문서에 설명된 대로 Apigee 인스턴스를 새 인스턴스로 교체하는 것이 좋습니다. 이전 인스턴스를 다시 만들지 않으면 확장 문제가 발생할 수 있으며 인스턴스에 추가할 수 있는 환경 수가 계속 10개로 제한됩니다. 또한 인스턴스의 정기 업데이트가 중단되어 API 서비스가 영향을 받을 수 있습니다.
각 인스턴스에서 Unix 타임스탬프를 디코딩하여 createdAt 필드의 값을 확인하여 날짜를 가져옵니다.
2022년 1월 25일 이후에 인스턴스가 생성된 경우 이 인스턴스에 대해 더 이상 조치를 취할 필요가 없습니다.
2022년 1월 25일 이전에 인스턴스가 생성된 경우 이 문서에 설명된 대로 인스턴스를 교체하는 것이 좋습니다.
재생성 절차 정보
다운타임이나 데이터 손실 없이 인스턴스를 다시 만들려면 먼저 새(확장된) 리전에 새 인스턴스를 만들고 새 인스턴스로 API 트래픽을 전달해야 합니다. 그런 다음 기존 인스턴스를 드레이닝하고 삭제한 뒤 삭제한 인스턴스와 동일한 리전에서 다시 만들 수 있습니다.
Apigee에서는 인스턴스를 다시 만들고 구성하는 데 필요한 모든 단계를 수행하는 일련의 스크립트를 제공합니다. 이 문서 뒷부분에 스크립트 링크가 제공됩니다.
기본 요건
인스턴스 재생성 단계를 시작하기 전에 다음 사항을 확인하세요.
먼저 Apigee 인스턴스가 생성된 방식을 잘 알고 있어야 합니다. 인스턴스를 다시 만드는 단계는 원래 인스턴스가 어떻게 구성되어 있는지에 대한 세부정보를 알고 있는 것에 따라 달라집니다.
2개 이상의 리전에서 Apigee를 프로비저닝할 수 있어야 합니다. 사용 권한이 충분한지 확실하지 않으면 다음 단계에 따라 새 리전에 인스턴스를 만듭니다. 적절한 사용 권한이 없는 경우 한도 오류와 함께 시도가 실패합니다. 이 경우 Apigee 지원팀에 문의하여 리전 한도를 늘리기 위한 임시 예외를 받습니다. 이미 2개 이상의 리전을 사용할 수 있는 경우 재생성 프로세스 중에 축소된 인스턴스로 프로덕션 워크로드를 실행하지 않도록 임시 예외를 받는 것이 좋습니다.
새 인스턴스를 만들려면 /22 및 /28 블록의 추가 IP 범위를 위한 공간이 프로젝트에 있어야 합니다. 네트워크 크기 조정도 참조하세요.
인스턴스 재생성 완료 후 추가 리전이 삭제되면 이 범위를 해제할 수 있습니다. /22 블록은 사용자가 구성할 수 있습니다. Apigee가 사용할 /28 블록을 선택할 수 있습니다. 선택하지 않을 경우 사용 가능한 블록에서 Apigee가 자동으로 할당합니다.
인스턴스 다시 만들기
Apigee에서는 인스턴스를 다시 만드는 데 필요한 모든 단계를 수행하는 일련의 스크립트를 제공합니다.
Northbound는 외부 또는 내부 클라이언트에서 부하 분산기를 통해 Apigee로 이동하는 API 트래픽을 나타냅니다. 인스턴스가 삭제된 후 다시 생성되면 인스턴스의 Northbound IP 주소 및 Private Service Connect(PSC) 서비스 연결 ID가 새 인스턴스에 대해 변경됩니다.
제공된 스크립트는 부하 분산기의 백엔드를 다시 구성합니다. 인스턴스의 네트워크 라우팅이 관리형 인스턴스 그룹(MIG)으로 구성된 경우 제공된 스크립트는 트래픽을 Apigee 엔드포인트로 프록시하는 MIG를 다시 만들고 MIG를 기존 백엔드 서비스의 백엔드로 연결합니다. 라우팅이 Private Service Connect(PSC)로 구성된 경우 스크립트는 네트워크 엔드포인트 그룹(NEG)을 Apigee의 서비스 엔드포인트 연결에 다시 만들고 새 NEG를 기존 백엔드 서비스에 백엔드로 연결합니다.
Southbound는 Apigee에서 API 프록시 대상 서비스로의 API 트래픽을 나타냅니다.
인스턴스가 삭제되고 다시 생성되면 전용 Southbound NAT IP 주소가 해제됩니다. 따라서 NAT에 대해 새 IP 주소를 예약 및 활성화하고 대상 엔드포인트에서 방화벽/허용 목록을 다시 구성해야 합니다. 필요한 경우 제공된 스크립트 중 하나가 이 NAT 재구성을 처리합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-18(UTC)"],[[["\u003cp\u003eThis document guides Apigee users with instances created before January 25, 2022, to replace them due to IP scaling limitations and to ensure continued updates and full API service functionality.\u003c/p\u003e\n"],["\u003cp\u003eRecreating an older Apigee instance is recommended to resolve scaling issues and environment limitations, otherwise, there is potential to experience scaling issues or limitations on the number of environments.\u003c/p\u003e\n"],["\u003cp\u003eThe recreation process involves creating a new instance in an expanded region, directing traffic to it, draining the old instance, and then recreating it in the original region, which enables zero downtime and no data loss.\u003c/p\u003e\n"],["\u003cp\u003eApigee provides a set of scripts to automate the instance recreation and reconfiguration process, including managing load balancers and, if needed, southbound NAT IP addresses.\u003c/p\u003e\n"],["\u003cp\u003ePrior to starting the recreation, users must be familiar with their instance's initial configuration, have entitlements to provision Apigee in multiple regions, and ensure sufficient IP ranges are available.\u003c/p\u003e\n"]]],[],null,["# Recreating an Apigee instance with zero downtime\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Important:** This topic only applies to organizations that were created with VPC peering enabled. See also [Apigee networking options](/apigee/docs/api-platform/get-started/networking-options).\n\n\nThis document explains how to recreate an Apigee\n[instance](/apigee/docs/api-platform/get-started/basic-concepts#instance)\nwithout incurring API management downtime or data loss.\n\nIntroduction\n------------\n\n\nApigee instances created before January 25, 2022, do not have sufficient internet protocol (IP)\naddress space to allow Apigee workloads to scale to handle increasing API traffic and/or\nto allow you to add more than 10 environments to an instance.\n\n\nOn January 24, 2022, Apigee [introduced\nan enhancement](/apigee/docs/release-notes#January_24_2022) to address this problem. The enhancement reduces the IP range required\nto peer your VPC network with Apigee and uses\n[privately\nused public IPs](https://cloud.google.com/architecture/configuring-privately-used-public-ips-for-GKE) (PUPI) to allow workloads to scale to higher limits.\n\nWhat you need to do\n-------------------\n\n\nIf you have an Apigee instance that was created before January 25, 2022, Apigee recommends\nthat you replace it with a new instance, as explained in this document. If you do not\nrecreate the older instance, you may experience scaling issues and the number of environments\nyou can add to an instance will continue to be limited to 10. Also, your instance may stop\ngetting regular updates which will impact the API services.\n\nDetermining an instance's creation date\n---------------------------------------\n\n\nTo determine the creation date of an Apigee instance:\n\n1. List details for all of the Apigee instances in your organization: \n\n AUTH=\"Authorization: Bearer $(gcloud auth print-access-token)\"\n\n curl -i -X GET -H \"$AUTH\" \\\n \"https://apigee.googleapis.com/v1/organizations/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/instances\"\n\n\n Where:\n - `AUTH` is the Authentication header with a bearer token. Be sure the default project for `gcloud` is set to the `PROJECT_ID`.\n - `PROJECT_ID` is the Cloud project ID that you created when you provisioned Apigee.\n\n\n Sample output: \n\n ```verilog\n {\n \"instances\": [\n {\n \"name\": \"us-west1\",\n \"location\": \"us-west1\",\n \"host\": \"10.117.200.2\",\n \"port\": \"443\",\n \"createdAt\": \"1642698826000\",\n \"lastModifiedAt\": \"1655745226000\",\n \"diskEncryptionKeyName\": \"projects/myproject/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key\",\n \"state\": \"ACTIVE\",\n \"peeringCidrRange\": \"SLASH_22\",\n \"runtimeVersion\": \"1-8-0-apigee-33\",\n \"ipRange\": \"10.117.200.0/22,10.81.174.192/28\",\n \"consumerAcceptList\": [\n \"myproject\"\n ],\n \"serviceAttachment\": \"projects/z11f28c6f3104980e-tp/regions/us-west1/serviceAttachments/apigee-us-west1-lbko\"\n }\n ]\n }\n ```\n2. For each instance, check the value of the `createdAt` field by decoding the Unix timestamp to get the date.\n - If an instance was created on or after January 25, 2022, then you do not have to do anything further for that instance.\n - If an instance was created before January 25, 2022, we recommend you replace the instance, as discussed in this document.\n\nAbout the recreation procedure\n------------------------------\n\n\nTo recreate an instance with zero downtime and no data loss, you need to first create a new\ninstance in a new (expanded) region and direct API traffic to that new instance. Then, you\ncan drain down the existing instance, delete it, and recreate it in the same region as the\none you deleted.\n\n\nApigee has provided a set of scripts that perform all of the required steps to recreate and configure\nan instance. We provide a link to the scripts later in this document.\n\nPrerequisites\n-------------\n\n\nBefore you begin the instance recreation steps:\n\n- You must be familiar with how the Apigee instance was created in the first place. The steps for recreating the instance depend on you knowing details about how the original instance was configured.\n- You must be entitled to provision Apigee in at least two regions. If you aren't sure if you have sufficient entitlement, follow the steps to create an instance in a new region. If you do not have the proper entitlement the attempt will fail with a limit error. In that case, contact Apigee support to get a temporary exception to increase your region limit. If you are already entitled for two or more regions, we recommend you reach out to get the temporary exception to avoid running your production workload with a reduced instance during the recreation process. The process of recreating an instance includes deleting the old instance. If you do not follow the step to create a new instance in an expanded region, you will incur downtime and runtime data loss, including KVMs, cache data, quota data, and KMS data. Therefore, region expansion is mandatory to recreate an instance without downtime or data loss.\n- You must have room in your project for additional IP ranges of **/22** and **/28** blocks to create the new instance. See also [Network sizing](https://cloud.google.com/apigee/docs/api-platform/system-administration/peering-ranges#sizing). You can release these ranges when the additional region is deleted after instance recreation is complete. Note that the **/22** block is configurable by you. You can choose which **/28** block Apigee will use, or if you don't choose, it is auto-assigned by Apigee from any available block.\n\nRecreating the instance\n-----------------------\n\n\nApigee has provided a set of scripts that perform all of the required steps to recreate an instance.\n\n1. Be sure you have met the [prerequisites](#prerequisites).\n2. [Download the scripts](https://github.com/apigee/apigee-x-pupi-migration) from GitHub.\n3. Follow the steps in the Git repository's [README](https://github.com/apigee/apigee-x-pupi-migration#readme) file to create the new instance.\n4. Reconfigure the northbound and southbound connections to point to the new Apigee instance. See [About northbound changes](#about-northbound-changes) and [About southbound changes](#about-southbound-changes).\n\n### About northbound changes\n\n\nNorthbound refers to API traffic from external or internal clients to Apigee through a load\nbalancer. When an instance is deleted and recreated, the northbound IP address and\n[Private\nService Connect](/apigee/docs/api-platform/system-administration/northbound-networking-psc) (PSC) service attachment ID of the instance will change for the new instance.\n\n\nThe provided scripts reconfigure the load balancer's\nbackend for you. If the instance's [network routing](/apigee/docs/api-platform/get-started/install-cli#configure-routing)\nwas configured with a managed instance\ngroup (MIG), a provided script recreates the MIG that proxies traffic to the Apigee endpoint,\nand attaches the MIG as a backend to the existing backend service. If routing was configured\nwith private service connect (PSC), a script recreates the network endpoint group (NEG) to\nApigee's service endpoint attachment and attaches the new NEG as a backend to the existing\nbackend service.\n\nNote that you will not have to change the hostname records in any\n[environment groups](/apigee/docs/api-platform/fundamentals/environments-overview)\nassociated with the old instance.\n\n### Southbound changes\n\n\nSouthbound refers to API traffic from Apigee to your API proxy target services.\n\n\n| **Note:** Southbound changes are only needed if you used NAT IPs for Apigee instances, as described in [Provisioning\n| NAT IPs](/apigee/docs/api-platform/security/nat-provisioning).\n\n\nWhen an instance is deleted and recreated, any dedicated southbound NAT IP addresses will be\nreleased. So, you must reserve and activate new IP addresses for your NAT and reconfigure\nyour firewalls/allowlisting on your target endpoints. One of the provided scripts handles\nthis NAT reconfiguration for you, if needed."]]
