여러 리전으로 Apigee 확장

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

Apigee Edge 문서 보기

여러 리전 간에 Apigee 조직을 확장할 수 있습니다. 멀티 리전 확장은 다음 영역을 개선할 수 있습니다.

고가용성: 리전 장애가 발생해도 나머지 리전에서 트래픽을 계속 제공할 수 있으므로 API의 전체 가용성이 증가합니다.
고용량: 추가 리전은 단일 환경에 큰 부담을 주지 않으면서 API 트래픽을 처리할 수 있는 추가 용량을 제공하고 트래픽의 예기치 않은 급증에 대비할 수 있는 여분을 제공하여 API의 전체 용량을 증가시킵니다.
짧은 지연 시간: 추가 리전은 지리적으로 더 가까운 리전에서 요청을 처리하여 클라이언트의 전체 트랜잭션 지연 시간을 줄일 수 있습니다.

이 문서에서는 Apigee를 새 리전에 추가하고 리전에서 Apigee를 삭제하는 방법을 설명합니다.

새 리전에 Apigee 추가

리전당 하나의 런타임 인스턴스를 가질 수 있으므로 새 리전을 추가하려면 해당 리전에서 완전히 새로운 인스턴스를 만들어야 합니다.

새 리전을 추가하는 일반적인 절차는 다음과 같습니다.

기본 요건의 설명에 따라 사용할 수 있는 피어링 네트워크에 적절한 IP 주소 범위가 있는지 확인. 또한 한도에 설명된 대로 계정이 새 리전을 지원할 수 있는지 확인합니다.
환경 변수 정의
새 키링 및 키 만들기
새 주소 범위 예약
새 인스턴스 만들기
새 인스턴스에 환경 연결
라우팅 구성

다음 섹션에서 각 단계를 설명합니다.

기본 요건

네트워크에 사용 가능한 중첩되지 않는 IP 주소 범위로 /22 및 /28이 있는지 확인합니다. 이 범위는 다른 리전에서 사용되는 범위에 추가됩니다.

한도

기본적으로 초기 조직은 보통 단일 리전을 사용하여 생성됩니다. 두 번째(또는 이후) 리전을 만들지 여부를 결정할 때는 라이선스 사용 권한에서 허용하는 경우에만 리전을 추가할 수 있다는 사실에 유의하세요. 원하는 경우 조직 팩을 구입할 수 있습니다.

구독 기반 가격 책정 모델을 사용하는 경우 여러 리전으로 확장을 허용하기 위해 조직 단위를 추가로 구매해야 할 수 있습니다. 구독 사용 권한을 참조하세요.
사용한 만큼만 지불 요금제 모델이 있는 경우 사용한 만큼만 지불 리전 추가에 설명된 대로 여러 리전으로 확장하면 추가 비용이 발생합니다.
평가 계정은 한 리전으로 제한되며 두 번째 리전으로 확장할 수 없습니다.

자세한 내용은 사용한 만큼만 지불 개요를 참조하세요.

조직에는 리전이 10개(하이브리드용 11)를 초과할 수 없습니다.

환경 변수 정의

이 문서 전체에서 명령어를 일관적으로 사용하려면 다음 환경 변수를 정의하는 것이 좋습니다.

export NEW_REGION_LOCATION="NEW_REGION_LOCATION"
export NEW_INSTANCE_NAME="NEW_INSTANCE_NAME"
export NETWORK_NAME"=NETWORK_NAME"
export DISK_KEY_RING_NAME="YOUR_DISK_KEY_RING_NAME"
export DISK_KEY_NAME="YOUR_DISK_KEY_NAME"
export PROJECT_ID=YOUR_PROJECT_ID
export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

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

NEW_REGION_LOCATION은 새 인스턴스의 물리적 위치입니다. 어떤 Compute Engine 리전이든 유효한 값입니다. 자세한 내용은 리전 및 영역을 참조하세요. 예를 들면 us-west1입니다.
NEW_INSTANCE_NAME은 새 리전의 이름입니다. 이는 조직에 고유해야 합니다. 예를 들면 my-instance-2입니다.
NETWORK_NAME은 조직의 피어링 네트워크 이름입니다. 예를 들면 my-network입니다. 서비스 네트워킹 구성을 참조하세요.
DISK_KEY_RING_NAME은 디스크 키링의 이름입니다.
DISK_KEY_NAME은 디스크 링의 이름입니다.
AUTH는 Bearer 토큰이 있는 Authentication 헤더를 정의합니다. Apigee API를 호출할 때 이 헤더를 사용합니다. 토큰은 일정 시간 후 만료됩니다. 만료 후에는 동일 명령어를 사용해서 다시 생성할 수 있습니다. 자세한 내용은 print-access-token 명령어의 참조 페이지를 확인하세요.
PROJECT_ID는 클라우드 프로젝트 ID입니다.
PROJECT_NUMBER는 클라우드 프로젝트의 클라우드 프로젝트 번호입니다.

새 키링 및 키 만들기

리전마다 네트워크에 고유한 디스크 암호화 키가 필요합니다. 또한 새 리전에는 별도의 키링도 만드는 것이 좋습니다. 조직의 모든 인스턴스가 동일한 데이터베이스 암호화 키를 공유하기 때문에 데이터베이스 암호화 키를 새로 만들 필요는 없습니다.

자세한 내용은 Apigee 암호화 키 정보를 참조하세요.

새 디스크 암호화 키링 및 키를 생성하려면 다음 안내를 따르세요.

gcloud 명령어를 사용하여 새 디스크 키링을 만듭니다.

gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

디스크 키링이 인스턴스와 동일한 위치에 설정되었는지 확인합니다. 각 인스턴스와 키링에 고유한 위치가 있어야 합니다.

gcloud kms keyrings list \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keyrings describe $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

kms keys create 명령어를 사용하여 새 디스크 키를 만듭니다. 예를 들면 다음과 같습니다.

gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

키 경로로 해당 키를 참조할 수 있습니다. 다음 명령어를 사용하여 키 경로를 가져올 수 있습니다.

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

키 경로는 다음과 같습니다.

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

gcloud kms keys add-iam-policy-binding 명령어를 실행하여 Apigee 서비스 에이전트에 새 키를 사용할 수 있는 액세스 권한을 부여합니다. 예를 들면 다음과 같습니다.

gcloud kms keys add-iam-policy-binding $DISK_KEY_NAME \
  --location $NEW_REGION_LOCATION \
  --keyring $DISK_KEY_RING_NAME \
  --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project $PROJECT_ID

키가 Apigee 서비스 에이전트에 결합되었는지 확인합니다.

gcloud kms keys get-iam-policy $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \  
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keys describe $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \  
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

새 주소 범위 예약

피어링 네트워크의 주소 범위에 IP 주소를 예약합니다. 또한 자세한 내용 및 중요한 고려사항은 피어링 범위 이해를 참조하세요.

다음 환경 변수를 만듭니다.
```
NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME
```
각 항목의 의미는 다음과 같습니다.
- NEW_RANGE_NAME_22는 만들려는 CIDR 길이 /22에 대한 IP 주소 범위 이름입니다. 범위 이름을 원하는 대로 지정할 수 있습니다. 예를 들면 google-svcs-new_22입니다.
- NEW_RANGE_NAME_28는 만들려는 CIDR 길이 /28에 대한 IP 주소 범위 이름입니다. 범위 이름을 원하는 대로 지정할 수 있습니다. 예를 들면 google-svcs-new_28입니다.
- NETWORK_NAME는 주소를 예약할 네트워크 리소스의 이름입니다.
  Google에서는 새 프로젝트마다 기본 네트워크(default)를 만들 수 있으므로 이를 사용할 수 있습니다. 하지만 테스트 용도 이외에는 기본 네트워크를 사용하지 않는 것이 좋습니다.
  
  참고: 이 설정 프로세스를 테스트하는 경우가 아니면 default를 사용하지 않는 것이 좋습니다. 프로덕션 단계의 기본 네트워크가 포함된 조직을 사용해서는 안 됩니다.

CIDR 길이가 /22인 네트워크 IP 범위를 만듭니다.

gcloud compute addresses create $NEW_RANGE_NAME_22 \
  --global \
  --prefix-length=22 \
  --description="Peering range for Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

성공하면 gcloud가 다음과 같이 응답합니다.

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs-new].

생성된 컴퓨팅 주소의 유효성을 검사합니다.

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

gcloud compute addresses describe $NEW_RANGE_NAME_22 \
  --global \
  --project=$PROJECT_ID

IP 주소 범위를 만든 후 주소는 해제할 때까지 프로젝트에 연결됩니다.

CIDR 길이가 /28인 네트워크 IP 범위를 만듭니다. 이 범위는 필수이며 Apigee에서 문제 해결 목적으로 사용되며 맞춤설정 또는 변경할 수 없습니다.

gcloud compute addresses create $NEW_RANGE_NAME_28 \
  --global \
  --prefix-length=28 \
  --description="Peering range for supporting Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

생성된 컴퓨팅 주소의 유효성을 검사합니다.

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

 gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID

피어링 범위 이름을 가져옵니다.

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

다음 명령어를 사용하여 피어링된 네트워크에 새로 예약된 범위를 추가합니다. 여기서 $NEW_RANGE_NAME_22 및 $NEW_RANGE_NAME_28은 새 범위 이름이고 ORIGINAL_RANGE_NAME_1 및 ORIGINAL_RANGE_NAME_n은 이전 명령어로 반환된 예약된 피어링 범위 이름입니다.
```
gcloud services vpc-peerings update --service=servicenetworking.googleapis.com \
  --network=$NETWORK_NAME \
  --ranges=$NEW_RANGE_NAME_22,$NEW_RANGE_NAME_28,ORIGINAL_RANGE_NAME_1,ORIGINAL_RANGE_NAME_n \
  --project=$PROJECT_ID
```

업데이트된 VPC 피어링 변경사항의 유효성을 검사합니다.

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

새 인스턴스를 생성합니다.

인스턴스 API를 사용하여 리전에 대해 새 인스턴스를 만듭니다.

VPC 피어링 사용

Apigee가 VPC 피어링을 사용하도록 설정된 경우 다음 API 호출을 사용하여 인스턴스를 만듭니다.

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$NEW_INSTANCE_NAME"'",
    "location":"'"$NEW_REGION_LOCATION"'",
    "diskEncryptionKeyName":"KEY_PATH",
    "ipRange":"IP_ADDRESS_1/28, IP_ADDRESS_2/22"  # OPTIONAL
  }'

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

KEY_PATH는 새 키링 및 키 만들기에서 만든 디스크 암호화 키의 키 경로입니다.
IP_ADDRESS_*는 Apigee 인스턴스를 만드는 데 사용되는 /22 및 /28 CIDR 범위의 CIDR IP 주소입니다. ipRange은 선택사항입니다. 이 필드를 제공하지 않으면 Apigee는 서비스 네트워킹에서 사용 가능한 /22 및 /28 CIDR 블록을 자동으로 요청합니다. Apigee instances API도 참조하세요.

Apigee가 새 Kubernetes 클러스터를 만들어 실행하고 해당 클러스터에 Apigee 리소스를 설치하며 부하 분산을 설정해야 하므로 이 요청을 완료하는 데는 최대 20분이 소요될 수 있습니다.

VPC 피어링 미사용

Apigee가 VPC 피어링을 사용하도록 설정되지 않은 경우 다음 API 호출을 사용하여 인스턴스를 만듭니다.

curl -X POST -H "$AUTH" \
  -H "Content-Type:application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]      
  }'

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

KEY_PATH는 새 키링 및 키 만들기에서 만든 디스크 암호화 키의 키 경로입니다. Apigee instances API도 참조하세요.
consumerAcceptList(선택사항) Apigee VPC의 서비스 연결에 비공개로 연결할 수 있는 Google Cloud 프로젝트 ID 목록을 지정합니다. 서비스 연결은 Google Cloud Private Service Connect와 사용되는 항목이며, 서비스 제작자(이 경우 Apigee)가 소비자(이 경우 하나 이상의 Cloud 프로젝트)에게 서비스를 노출할 수 있도록 합니다. 기본적으로 Apigee 조직과 이미 연결된 Cloud 프로젝트를 사용합니다. 예를 들면 "consumerAcceptList": ["project1", "project2", "project3"]입니다.

키 경로를 찾는 방법

다음 명령어를 사용하여 키 경로를 가져올 수 있습니다.

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

키 경로는 다음과 같습니다.

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

timer: 인스턴스 만들기 작업은 완료하는 데 약 30분이 걸립니다.

런타임 인스턴스 생성 요청의 상태를 확인하려면 다음 명령어를 실행합니다. 활성 상태이면 다음 단계로 넘어갈 수 있습니다.

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

추가 환경설정 및 문제 해결 정보를 포함하여 런타임 인스턴스 만들기에 대한 자세한 내용은 5단계: Apigee 런타임 인스턴스 만들기를 참조하세요.

새 인스턴스에 환경 연결

인스턴스를 만든 후 여기에 환경을 연결해야 합니다. 그렇지 않으면 API 요청에 응답할 수 없습니다.

환경은 인스턴스 간에 공유됩니다. 따라서 기존 환경을 새 리전에 연결해야 합니다. 새 리전의 환경을 새로 정의하지는 않습니다. 원래 환경과 동일한 호스트에 동일한 기본 경로를 제공하는 새 리전의 새 환경을 정의하면 런타임 호출에서 HTTP 503 오류가 반환될 수 있습니다.

환경으로 새 리전을 채우는 경우 환경이 해당 그룹에 이미 연결되어 있으므로 환경 그룹에 환경을 연결할 필요가 없습니다. 새 인스턴스에만 환경을 연결하면 됩니다.

새 리전에 환경을 연결하려면 다음 예시와 같이 Instances attachment API를 사용합니다.

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME/attachments \
  -d '{
    "environment":"ENVIRONMENT_NAME"
  }'

환경 목록을 가져오려면 다음 안내를 따르세요.

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

Instances Attachment API를 따로 호출하여 각 환경을 연결해야 합니다. 단일 호출로 둘 이상의 환경을 연결할 수는 없습니다.

라우팅 구성

관리형 인스턴스 그룹(MIG) 또는 Private Service Connect(PSC) 기반 구성을 사용하여 새 리전에서 네트워크 라우팅을 구성할 수 있습니다.

PSC 라우팅 구성

다음 단계에서는 PSC를 사용하여 새 리전에서 라우팅을 구성하는 방법을 설명합니다.

개요

다음 그림은 멀티 리전 PSC에 대한 고급 Northbound 아키텍처를 보여줍니다.

멀티 리전 PSC 라우팅 다이어그램

그림 1: PSC를 사용하는 Northbound 멀티 리전 아키텍처

그림 1에 표시된 것처럼 새 Apigee 인스턴스가 상주하는 리전에서 서비스 첨부파일과 통신하는 네트워크 엔드포인트 그룹(NEG)를 프로젝트에 만듭니다. 모든 리전에 대한 Apigee NEG가 Apigee 프로덕션 글로벌 외부 부하 분산기의 백엔드 서비스에 연결됩니다.

(선택사항) 임시 부하 분산기를 사용하여 테스트

계속하기 전에 새 리전에서 Apigee와 통신하도록 임시 부하 분산기(LB) 및 NEG를 설정하여 새 인스턴스를 테스트할 수 있습니다. API 트래픽을 테스트 LB로 성공적으로 전송한 후 임시 LB를 삭제하고 NEG를 Apigee 프로덕션 LB의 백엔드 서비스에 연결할 수 있습니다.

새 인스턴스를 테스트하려면 다음 단계를 수행합니다.

8단계: 라우팅 구성의 모든 외부 라우팅(PSC) 단계를 따라 새 리전에 병렬 전역 부하 분산기를 프로비저닝합니다. 이러한 단계에는 새 NEG를 만들고 이를 임시 LB의 백엔드 서비스에 추가하는 과정이 포함됩니다.
외부 클라이언트에서 API 프록시를 테스트합니다. 외부 라우팅을 사용하여 테스트하려면 샘플 프록시 배포를 참조하세요.
테스트가 완료되었으면 임시 부하 분산기를 삭제합니다. NEG를 삭제할 필요가 없습니다. 아래 설명에 따라 다시 사용할 수 있습니다. 부하 분산 설정 삭제를 참조하세요.

새 리전의 네트워크 엔드포인트 그룹 만들기

다음 단계에 따라 새 리전에 대해 네트워크 엔드포인트 그룹(NEG)을 사용하여 부하 분산기를 만들고 구성합니다.

새 NEG를 만듭니다.
참고: 테스트 중 생성된 NEG를 삭제하지 않았으면, 이를 다시 사용할 수 있습니다. 이 경우 이 단계를 건너뛰고 2단계로 이동합니다.
1. 이전에 만든 인스턴스에서 서비스 연결을 가져옵니다.
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
  다음 샘플 출력에서 serviceAttachment 값은 굵게 표시됩니다.
```
{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.82.192.2",
      "port": "443",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-7-0-20220228-190814",
      "ipRange": "10.82.192.0/22,10.82.196.0/28",
      "consumerAcceptList": [
        "875609189304"
      ],
      "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
    }
  ]
}
```
  참고: Apigee 조직을 만드는데 사용하는 프로젝트 ID는 항상 consumerAcceptList 목록에 표시됩니다. 위에 표시된 예시 출력에서는 목록에 하나의 프로젝트만 표시됩니다.
2. 이전 단계에서 인스턴스 응답 본문에서 가져온 서비스 첨부파일을 가리키는 NEG를 만듭니다.
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=TARGET_SERVICE \
  --region=$NEW_REGION_LOCATION \
  --network=NETWORK_NAME \
  --subnet=SUBNET_NAME \
  --project=PROJECT_ID
```
  다음을 바꿉니다.
  - NEG_NAME: 네트워크 엔드포인트 그룹의 이름입니다.
  - TARGET_SERVICE: 연결할 서비스 연결입니다. 예를 들면 projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7입니다.
  - NETWORK_NAME: (선택사항) NEG가 생성되는 네트워크의 이름입니다. 이 매개변수를 생략하면 default 프로젝트 네트워크가 사용됩니다.
  - SUBNET_NAME: 제작자에 대한 비공개 연결에 사용되는 서브넷의 이름입니다. 서브넷 크기는 작을 수 있습니다. PSC NEG에는 서브넷에서 하나의 IP만 있으면 됩니다. Apigee의 경우 리전당 하나의 PSC NEG만 필요합니다. 서브넷은 VM 또는 다른 항목에서 공유하고 사용할 수 있습니다. 서브넷이 지정되지 않은 경우 네트워크 엔드포인트는 네트워크 엔드포인트 그룹이 생성된 리전의 모든 서브네트워크에 속할 수 있습니다.
    참고: --network 매개변수를 지정하면 --subnet도 지정해야 합니다.
  - PROJECT_ID Apigee 조직과 이미 연결된 Cloud 프로젝트 또는 Apigee 런타임 인스턴스 생성 시 consumerAcceptlist에 포함된 Cloud 프로젝트입니다.
프로덕션 Apigee 부하 분산기에 대한 백엔드 서비스 이름을 가져옵니다.
```
gcloud compute backend-services list --project=$PROJECT_ID
```
NEG를 백엔드 서비스에 백엔드로 추가합니다.
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$NEW_REGION_LOCATION \
  --global --project=$PROJECT_ID
```
다음을 바꿉니다.
- BACKEND_SERVICE_NAME: 백엔드 서비스 이름입니다.
- NEG_NAME: 네트워크 엔드포인트 그룹의 이름입니다.
(선택사항) 장애 조치 시나리오를 자동으로 처리하기 위해 백엔드 서비스에서 외부 감지 트래픽 정책을 설정할 수 있습니다. 자세한 내용은 다음을 참조하세요.

최종 설정 테스트

API 프록시를 호출합니다. 샘플 프록시 배포를 참조하세요.

MIG 라우팅 구성

다음 단계에서는 관리형 인스턴스 그룹(MIG)을 사용하여 새 리전에서 라우팅을 구성하는 방법을 설명합니다.

개요

다음 그림은 관리형 인스턴스 그룹(MIG)을 사용하는 멀티 리전에 대한 고급 Northbound 아키텍처를 보여줍니다.

멀티 리전 PSC의 Northbound 아키텍처 다이어그램

그림 2: MIG를 사용하는 Northbound 멀티 리전 아키텍처

그림 2에 표시된 것처럼 새 Apigee 인스턴스가 있는 리전에서 배포된 부하 분산기와 통신하도록 프로젝트에서 MIG를 만듭니다. 모든 리전의 MIG 프록시가 Apigee 프로덕션 전역 외부 부하 분산기의 백엔드에 연결됩니다.

(선택사항) 임시 부하 분산기를 사용하여 테스트

계속하기 전에 새 리전에서 Apigee와 통신하도록 임시 부하 분산기 및 MIG를 설정하여 새 인스턴스를 테스트할 수 있습니다. API 트래픽을 테스트 LB로 성공적으로 전송한 후 임시 LB를 삭제하고 MIG를 Apigee 프로덕션 LB의 백엔드 서비스에 연결할 수 있습니다.

새 인스턴스를 테스트하려면 다음 단계를 수행합니다.

8단계: 라우팅 구성의 모든 외부 라우팅(MIG) 단계를 따라 새 리전에 병렬 전역 부하 분산기를 프로비저닝합니다.
외부 클라이언트에서 API 프록시를 테스트합니다. 외부 라우팅을 사용하여 테스트하려면 샘플 프록시 배포를 참조하세요.
테스트가 완료되었으면 임시 부하 분산기를 삭제합니다. MIG를 삭제할 필요가 없습니다. 아래 설명에 따라 다시 사용할 수 있습니다. 부하 분산 설정 삭제를 참조하세요.

새 리전의 관리형 인스턴스 그룹(MIG) 만들기

이 단계에 따라 새 리전에 대해 MIG를 만들고 구성합니다.

VPC 네트워크의 서브넷에 대해 비공개 Google 액세스 사용 설정합니다.

VPC 네트워크의 서브넷에 비공개 Google 액세스를 사용 설정하려면 비공개 Google 액세스 사용 설정에 나와 있는 단계를 따르세요.
환경 변수를 설정합니다.

이 섹션의 절차에서는 환경 변수를 사용하여 반복적으로 사용되는 문자열을 참조합니다. 계속하기 전에 이를 설정하는 것이 좋습니다.
```
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=YOUR_VPC_NAME       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=YOUR_SUBNET_NAME     # Private Google Access must be enabled for this subnet
NEW_REGION_LOCATION=YOUR_NEW_REGION      # The same region as your new Apigee runtime instance
APIGEE_ENDPOINT=APIGEE_INSTANCE_IP        # See the tip below for details on getting this IP address value
```
팁: 올바른 Apigee 인스턴스 IP 주소를 가져오려면 다음 예시와 같이 Instances API를 사용합니다.
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
Apigee가 인스턴스에 대한 세부정보를 사용하여 응답합니다. 예를 들면 다음과 같습니다.
```
{
  "instances": [
    {
      "name": "my-runtime-instance",
      "location": "us-west1",
      "host": "10.16.0.2",
      "port": "443"
    },
    ...
  ]
}
```
$APIGEE_ENDPOINT 환경 변수에 할당할 수 있는 인스턴스 IP 주소는 host 필드의 값입니다. 이 예시에서 값은 10.16.0.2입니다.

멀티 리전 설치에서 API 호출은 각 리전 위치의 인스턴스 세부정보를 반환합니다.
관리형 인스턴스 그룹을 만듭니다. 이 단계에서는 관리형 인스턴스 그룹(MIG)을 만들고 구성합니다.
참고: 테스트 중 생성된 MIG를 삭제하지 않았으면, 이를 다시 사용할 수 있습니다. 이 경우 이 단계를 건너뛰고 3단계로 이동합니다.
1. 다음 명령어를 실행하여 인스턴스 템플릿을 만듭니다.
```
gcloud compute instance-templates create $MIG_NAME \
  --project $PROJECT_ID \
  --region $NEW_REGION_LOCATION \
  --network $VPC_NAME \
  --subnet $VPC_SUBNET \
  --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
  --machine-type e2-medium --image-family debian-12 \
  --image-project debian-cloud --boot-disk-size 20GB \
  --no-address \
  --metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh
```
  이 명령어에서 볼 수 있듯이 머신은 e2-medium 유형입니다. 이러한 머신은 Debian 12를 실행하며 20GB의 디스크를 보유하고 있습니다. startup-script.sh 스크립트는 MIG가 부하 분산기에서 Apigee 인스턴스로 인바운드 트래픽을 라우팅하도록 MIG를 구성합니다.
2. 다음 명령어를 실행하여 관리형 인스턴스 그룹을 만듭니다.
```
gcloud compute instance-groups managed create $MIG_NAME \
  --project $PROJECT_ID --base-instance-name apigee-mig \
  --size 2 --template $MIG_NAME --region $NEW_REGION_LOCATION
```
3. 다음 명령어를 실행하여 그룹의 자동 확장을 구성합니다.
  참고: e2-medium 인스턴스가 있는 리전 MIG는 최대 6Gbps를 지원할 수 있습니다. 요구사항에 비해 처리량이 충분하지 않다면 VM 크기 및 복제본 수를 늘려 보세요.
```
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --max-num-replicas 3 \
  --target-cpu-utilization 0.75 --cool-down-period 90
```
4. 다음 명령어를 실행하여 이름이 지정된 포트를 정의합니다.
```
gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
```
프로덕션 Apigee 부하 분산기에 대한 백엔드 서비스 이름을 가져옵니다.
```
gcloud compute backend-services list --project=$PROJECT_ID
```
다음 명령어를 사용하여 MIG를 백엔드 서비스에 추가합니다.
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --project $PROJECT_ID --instance-group $MIG_NAME \
  --instance-group-region $NEW_REGION_LOCATION \
  --balancing-mode UTILIZATION --max-utilization 0.8 --global
```
BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.

참고: 참고: VPC 피어링으로 유료 조직 프로비저닝: 8e단계 '전역 부하 분산기 만들기', 하위 단계 1 '상태 점검 만들기'에 설명된 대로 부하 분산기 상태 점검이 구성되었는지 확인하세요.

최종 설정 테스트

API 프록시를 호출합니다. 샘플 프록시 배포를 참조하세요.

리전 추가

Apigee 환경에 여러 리전을 추가하면 API의 가용성을 높이고, 용량을 늘리고, 지연 시간을 줄일 수 있습니다. 멀티 리전 배포에서는 XLB가 각 리전의 상태 점검을 하므로 수동 장애 조치가 필요하지 않기 때문에 고가용성을 지원합니다. 여러 리전에서 동일한 API를 동시에 제공하는 경우 더 높은 용량이 제공됩니다. 또한 API 클라이언트가 여러 리전에 있는 경우 클라이언트와 가까운 리전에서 API를 제공하면 지연 시간을 줄이고 성능을 개선할 수 있습니다.

예시: 멀티 리전 배포로 가용성, 용량, 지연 시간 개선

활성-활성 멀티 리전 배포에서 트래픽은 동시에 두 리전에서 처리됩니다. 8단계: 라우팅 구성 섹션의 외부 라우팅(MIG) 탭 아래의 8e(3) 단계에 설명된 것처럼, 각 리전 MIG의 백엔드 서비스를 동일한 외부 HTTPS 부하 분산기(XLB)에 추가합니다. 자세한 내용은 새 리전의 관리형 인스턴스 그룹(MIG) 만들기를 참조하세요.

요청 수가 특정 백엔드에 설정된 한도를 초과하지 않는 한 XLB는 각 요청에 대해 클라이언트에 가장 가까운 리전을 선택합니다. 외부 부하 분산기가 트래픽을 라우팅하는 방법에 대한 자세한 내용은 전역 부하 분산으로 애플리케이션 용량 최적화를 참조하세요.

사용한 만큼만 지불 리전 추가

Pay-as-you-go 가격 책정 모델을 사용하면 환경에 대한 최소 Apigee 게이트웨이 노드 수를 설정할 수 있습니다. 이렇게 하면 리전 장애 발생 시 장애 조치 트래픽을 즉시 지원할 수 있도록 리전이 항상 추가 용량으로 실행되도록 할 수 있습니다.

최소 Apigee 게이트웨이 노드 수 설정

각각 4개의 Apigee 게이트웨이 노드가 있는 활성 리전 2곳에서 모든 일반 API 트래픽을 제공할 수 있는 경우 각 지역에는 노드가 8개 이상 있어야 합니다. 이는 한 리전의 손실을 즉시 지원하기 위함입니다. API 트래픽을 처리하는 데 필요한 노드 수를 결정하는 방법에 대한 자세한 내용은 Apigee 노드 정보를 참조하세요. 최소 노드 수는 환경별로 설정되지만 리전별로 적용됩니다. 예를 들어 최솟값을 8로 설정하면 각 리전에 최소 8개의 노드가 있습니다.

비용

위의 예시에서는 Apigee 게이트웨이 노드 16개(노드 8개 x 리전 2개)를 실행하는 비용이 발생합니다. 추가 트래픽을 처리하기 위해 노드 수가 최대값까지 자동으로 증가함에 따라 비용이 증가할 수 있습니다.

리전에서 Apigee 삭제

Apigee 인스턴스가 API 트래픽을 제공하지 않도록 하려면 다음 단계에 따라 서비스 중단을 방지합니다(API의 다운타임 없음).

백엔드 서비스에서 연결 드레이닝을 사용 설정합니다. 연결 드레이닝은 백엔드 서비스에서 백엔드가 삭제될 때 기존의 진행 중인 요청이 완료될 수 있는 시간을 부여하는 프로세스입니다.
가중치가 적용된 라운드 로빈 라우팅 정책을 통해 이 Apigee 리전으로 트래픽을 라우팅하도록 Cloud DNS를 구성한 경우 DNS 라우팅 정책 및 상태 점검 관리의 설명대로 DNS 구성을 삭제합니다.
백엔드 서비스에서 MIG 백엔드를 분리합니다. 그러면 연결 드레이닝과 함께 Apigee 인스턴스가 새 트래픽을 수신하지 않지만 처리 중인 요청을 완료할 수 있습니다.
Apigee 인스턴스와 해당 MIG를 삭제합니다. 인스턴스 삭제를 참조하세요.