다운타임 없이 Apigee 인스턴스 다시 만들기

이 페이지는 Apigee에 적용되지만 Apigee Hybrid에는 적용되지 않습니다.

이 문서에서는 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 서비스에 영향을 주는 정기적인 업데이트를 중지할 수 있습니다.

인스턴스 생성 날짜 확인

Apigee 인스턴스 생성 날짜를 확인하려면 다음 안내를 따르세요.

조직의 모든 Apigee 인스턴스에 대한 세부정보를 나열합니다.

AUTH="Authorization: Bearer $(gcloud auth print-access-token)"

curl -i -X GET -H "$AUTH" \
"https://apigee.googleapis.com/v1/organizations/PROJECT_ID/instances"

각 항목의 의미는 다음과 같습니다.

AUTH는 Bearer 토큰이 있는 인증 헤더입니다. gcloud의 기본 프로젝트가 PROJECT_ID로 설정되었는지 확인합니다.
PROJECT_ID는 Apigee를 프로비저닝할 때 만든 Cloud 프로젝트 ID입니다.

샘플 결과:

{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.117.200.2",
      "port": "443",
      "createdAt": "1642698826000",
      "lastModifiedAt": "1655745226000",
      "diskEncryptionKeyName": "projects/myproject/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-8-0-apigee-33",
      "ipRange": "10.117.200.0/22,10.81.174.192/28",
      "consumerAcceptList": [
        "myproject"
      ],
      "serviceAttachment": "projects/z11f28c6f3104980e-tp/regions/us-west1/serviceAttachments/apigee-us-west1-lbko"
    }
  ]
}

각 인스턴스에서 Unix 타임스탬프를 디코딩하여 createdAt 필드의 값을 확인하여 날짜를 가져옵니다.
- 2022년 1월 25일 이후에 인스턴스가 생성된 경우 이 인스턴스에 대해 더 이상 조치를 취할 필요가 없습니다.
- 2022년 1월 25일 이전에 인스턴스가 생성된 경우 이 문서에 설명된 대로 인스턴스를 교체하는 것이 좋습니다.

재생성 절차 정보

다운타임이나 데이터 손실 없이 인스턴스를 다시 만들려면 먼저 새(확장된) 리전에 새 인스턴스를 만들고 새 인스턴스로 API 트래픽을 전달해야 합니다. 그런 다음 기존 인스턴스를 드레이닝하고 삭제한 뒤 삭제한 인스턴스와 동일한 리전에서 다시 만들 수 있습니다.

Apigee에서는 인스턴스를 다시 만들고 구성하는 데 필요한 모든 단계를 수행하는 일련의 스크립트를 제공합니다. 이 문서 뒷부분에 스크립트 링크가 제공됩니다.

기본 요건

인스턴스 재생성 단계를 시작하기 전에 다음 사항을 확인하세요.

먼저 Apigee 인스턴스가 생성된 방식을 잘 알고 있어야 합니다. 인스턴스를 다시 만드는 단계는 원래 인스턴스가 어떻게 구성되어 있는지에 대한 세부정보를 알고 있는 것에 따라 달라집니다.
2개 이상의 리전에서 Apigee를 프로비저닝할 수 있어야 합니다. 사용 권한이 충분한지 확실하지 않으면 다음 단계에 따라 새 리전에 인스턴스를 만듭니다. 적절한 사용 권한이 없는 경우 한도 오류와 함께 시도가 실패합니다. 이 경우 Apigee 지원팀에 문의하여 리전 한도를 늘리기 위한 임시 예외를 받습니다. 이미 2개 이상의 리전을 사용할 수 있는 경우 재생성 프로세스 중에 축소된 인스턴스로 프로덕션 워크로드를 실행하지 않도록 임시 예외를 받는 것이 좋습니다.
인스턴스 재생성 프로세스에는 이전 인스턴스 삭제가 포함됩니다. 확장된 리전에서 새 인스턴스를 만드는 단계를 따르지 않으면 KVM, 캐시 데이터, 할당량 데이터, KMS 데이터를 포함하여 다운타임 및 런타임 데이터 손실이 발생합니다. 따라서 다운타임이나 데이터 손실 없이 인스턴스를 다시 만들려면 리전 확장이 필요합니다.
새 인스턴스를 만들려면 /22 및 /28 블록의 추가 IP 범위를 위한 공간이 프로젝트에 있어야 합니다. 네트워크 크기 조정도 참조하세요. 인스턴스 재생성 완료 후 추가 리전이 삭제되면 이 범위를 해제할 수 있습니다. /22 블록은 사용자가 구성할 수 있습니다. Apigee가 사용할 /28 블록을 선택할 수 있습니다. 선택하지 않을 경우 사용 가능한 블록에서 Apigee가 자동으로 할당합니다.

인스턴스 다시 만들기

Apigee에서는 인스턴스를 다시 만드는 데 필요한 모든 단계를 수행하는 일련의 스크립트를 제공합니다.

기본 요건을 충족했는지 확인합니다.
GitHub에서 스크립트를 다운로드합니다.
Git 저장소의 README 파일에 있는 단계에 따라 새 인스턴스를 만듭니다.
새 Apigee 인스턴스를 가리키도록 Northbound 및 Southbound 연결을 다시 구성합니다. Northbound 변경 정보 및 Southbound 변경 정보를 참조하세요.

Northbound 변경사항 정보

Northbound는 외부 또는 내부 클라이언트에서 부하 분산기를 통해 Apigee로 이동하는 API 트래픽을 나타냅니다. 인스턴스가 삭제된 후 다시 생성되면 인스턴스의 Northbound IP 주소 및 Private Service Connect(PSC) 서비스 연결 ID가 새 인스턴스에 대해 변경됩니다.

제공된 스크립트는 부하 분산기의 백엔드를 다시 구성합니다. 인스턴스의 네트워크 라우팅이 관리형 인스턴스 그룹(MIG)으로 구성된 경우 제공된 스크립트는 트래픽을 Apigee 엔드포인트로 프록시하는 MIG를 다시 만들고 MIG를 기존 백엔드 서비스의 백엔드로 연결합니다. 라우팅이 Private Service Connect(PSC)로 구성된 경우 스크립트는 네트워크 엔드포인트 그룹(NEG)을 Apigee의 서비스 엔드포인트 연결에 다시 만들고 새 NEG를 기존 백엔드 서비스에 백엔드로 연결합니다.

이전 인스턴스와 연결된 환경 그룹에서 호스트 이름 레코드를 변경할 필요가 없습니다.

Southbound 변경사항

Southbound는 Apigee에서 API 프록시 대상 서비스로의 API 트래픽을 나타냅니다.

인스턴스가 삭제되고 다시 생성되면 전용 Southbound NAT IP 주소가 해제됩니다. 따라서 NAT에 대해 새 IP 주소를 예약 및 활성화하고 대상 엔드포인트에서 방화벽/허용 목록을 다시 구성해야 합니다. 필요한 경우 제공된 스크립트 중 하나가 이 NAT 재구성을 처리합니다.