환경은 API 프록시를 실행하기 위한 격리된 컨텍스트 또는 '샌드박스'를 제공합니다. 단일 조직에서 여러 개의 환경을 만들 수 있습니다. 자세한 내용은 환경 및 환경 그룹 정보를 참조하세요.
기본 설치 중에 테스트를 위한 환경을 추가했습니다. 하지만 여러 환경을 만들고 제한된 수의 프록시를 각 환경에 배포하는 것이 좋습니다.
가상 호스트 및 환경 정보
Apigee Hybrid는 Istio 인그레스 게이트웨이를 사용하여 수신되는 API 트래픽을 처리합니다. MART 및 런타임 서비스는 클러스터 외부에 노출되는 연결을 관리하기 위해 Istio 인그레스 게이트웨이와 함께 구성됩니다. 예를 들어 API 프록시에 대한 모든 HTTP 및 HTTPS 요청은 먼저 Istio 인그레스 게이트웨이에서 처리됩니다.
하이브리드에서 하나 이상의 환경을 만들고 각 환경에 호스트 별칭을 할당합니다. 호스트 별칭은 DNS 이름입니다. 이 DNS 이름에서 수신되는 트래픽은 인그레스에 의해 해당 환경으로 라우팅됩니다. 내부적으로 각 환경은 프록시 요청 처리, 정책 적용, 대상 서비스와의 트래픽 라우팅 작업을 수행하는 단 하나의 메시지 프로세서에만 할당됩니다. 따라서 호스트 별칭은 특정 수신 요청을 수신할 메시지 프로세서를 결정합니다.
다음 코드는 여러 환경이 정의된 구성의 예시를 보여줍니다. 이러한 구성은 재정의 파일에 포함됩니다. dev1 및 prod1 환경의 호스트 별칭은 서로 다릅니다.
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
기본 경로가 /foo1인 프록시가 환경 dev1에 배포되었다고 가정해 보겠습니다. 다음과 같이 프록시를 호출할 수 있습니다.
curl -k https://apitest.mydomain.net/foo1
이 호출이 인그레스에 도달하면 인그레스는 요청을 처리하는 dev1 환경과 연결된 메시지 프로세서로 이를 전송합니다.
마찬가지로 foo1도 prod1 환경에 배포된 경우 호스트 별칭 apiprod.mydomain.net에 다음과 같은 프록시 요청을 보낼 수 있습니다.
curl -k https://apiprod.mydomain.net/foo1
그러면 인그레스가 이 호스트와 연결된 MP로 라우팅됩니다.
요약하면 생성한 각 환경에는 호스트 별칭이 할당되어 있어야 합니다. 각 환경은 단 하나의 메시지 프로세서에만 매핑되고 호스트 별칭은 특정 요청을 수신하는 메시지 프로세서를 결정합니다.
환경은 동일한 호스트 별칭을 공유할 수 있습니다.
Apigee Hybrid를 사용하면 원하는 방식으로 관리할 수 있는 여러 환경을 만들 수 있습니다. 예를 들어 dev1, dev2, dev3 등의 여러 개발 환경을 만들고 각 환경에 단일 호스트 별칭을 매핑해야 합니다. 또한 각 환경에 여러 프록시를 배포할 수 있습니다.
Antipattern: 모든 프록시를 하나의 하이브리드 환경에 배포합니다.
권장사항: 여러 환경을 만들고 각 환경에 제한된 수의 프록시를 배포하세요. 하이브리드가 프록시 호출을 호스트 별칭을 공유하는 올바른 환경으로 라우팅하는 방법을 관리하는 기술을 기본 경로 라우팅이라고 합니다.
예를 들어 다음 구성에서 dev1과 dev2 환경은 동일한 호스트 별칭을 공유합니다.
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
여러 환경이 동일한 호스트 별칭을 공유하는 경우 기본 경로 라우팅이라는 구성 기법을 사용하여 특정 프록시 기본 경로를 특정 환경에 매핑해야 합니다. 자세한 내용은 기본 경로 라우팅을 참조하세요.
프록시 배포 수 제한
하이브리드의 경우 많은 환경이 동일한 가상 호스트를 공유할 수 있기 때문에 특정 환경에 대한 프록시 배포를 관리하는 방법을 신중하게 생각해야 합니다. 하이브리드에서 권장사항은 여러 환경을 만들고 각 환경에 제한된 수의 프록시를 배포하는 것입니다.
환경에 몇 개의 프록시를 배포해야 하나요? 이 질문에 대한 답변 집합은 없습니다. 그러나 다음 표에서 각 환경에 배포된 프록시의 수를 제한하는 것이 좋은 이유와 프록시 배포를 관리할 때 고려해야 할 사항에 대한 일반적인 안내를 제공합니다.
| 고려할 문제 | 설명 |
|---|---|
| 메시지 프로세서 부팅 시간 | 메시지 프로세서(MP)의 부팅에 소요되는 시간과 해당 MP에 배포된 프록시 수 사이에는 직접적인 상관관계가 있습니다. 자동 확장 Kubernetes 환경에서 부팅 시간이 늘어나는 것은 문제가 될 수 있습니다. MP에 배포되는 프록시가 많을수록 확장이나 다시 만들기가 필요한 경우에는 MP가 준비될 때까지 더 오랜 시간이 걸립니다. |
| 확장 성능 | 환경에 배포된 프록시가 여러 개 있고 프록시 중 하나가 트래픽이 많아 빈번하게 자동 확장되는 경우, 해당 환경의 모든 프록시가 이 프록시와 함께 확장됩니다. 트래픽이 많은 단일 프록시가 포함된 복수의 프록시 확장이 성능에 미치는 영향은 문제가 될 수 있습니다. |
| 트래픽 많은 이웃 | 동일한 환경에 여러 프록시가 배포되어 있고 하나의 프록시가 비정상 종료되면 MP가 다시 시작되는 동안 환경의 모든 프록시가 다운됩니다. 환경에 배포된 프록시 수를 제한하여 단일 프록시 비정상 종료의 영향을 최소화할 수 있습니다. |
환경 구성 참조
환경 구성 요소의 전체 목록은 구성 속성 참조에서 envs를 참조하세요.
환경 다루기
구성에 대한 상세 내용은 다음 주제를 참조하세요.