이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.
Apigee Edge 문서 보기
Apigee를 사용하는 개발자의 주요 개발 활동에는 API 또는 백엔드 서비스의 프록시로 작동하는 API 프록시를 구성하는 작업이 포함됩니다. 이 문서는 API 프록시를 빌드할 때 사용할 수 있는 모든 구성 요소에 대한 참고 자료입니다.
API 프록시를 빌드하는 방법을 알아보려면 간단한 API 프록시 빌드 주제로 시작하는 것을 추천합니다.
다음 방법 중 하나를 사용하여 API 프록시 구성을 수정합니다.
- Apigee UI 또는 API를 사용합니다.
- API 프록시 구성 번들 다운로드 및 업로드에 설명된 대로 API 프록시 구성 번들을 다운로드하고 수동으로 수정하며 새 구성을 Apigee에 업로드합니다.
API 프록시 구성 디렉터리 구조
API 프록시 구성 디렉터리 구조는 다음과 같습니다.
API 프록시 구성은 다음 콘텐츠로 구성됩니다.
| 기본 구성 | API 프록시의 기본 구성 설정입니다. |
| ProxyEndpoint | 인바운드 HTTP 연결(요청 앱부터 Apigee의 연결), 요청 및 응답 흐름, 정책 연결 설정. |
| TargetEndpoint | 아웃바운드 HTTP 연결(Apigee에서 백엔드 서비스의 연결), 요청 및 응답 흐름, 정책 연결 설정. |
| 흐름 | ProxyEndpoint 및 TargetEndpoint 요청과 응답 파이프라인을 정책에 연결할 수 있습니다. |
| 정책 | Apigee 정책 스키마를 준수하는 XML 형식의 구성 파일입니다. |
| 리소스 | 커스텀 로직을 실행하기 위해 정책에서 참고하는 스크립트, JAR 파일 및 XSLT 파일입니다. |
기본 구성
/apiproxy/weatherapi.xml
API 프록시의 기본 구성으로, API 프록시의 이름을 정의합니다. 이름은 조직 내에서 고유해야 합니다.
샘플 구성:
<APIProxy name="weatherapi"> </APIProxy>
기본 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
APIProxy |
|||
name |
API 프록시의 이름으로, 조직 내에서 고유해야 합니다. 이름에 사용할 수 있는 문자는 A-Za-z0-9_-로 제한됩니다. |
해당 사항 없음 | 예 |
revision |
API 프록시 구성의 버전 번호입니다. Apigee는 API 프록시의 현재 버전을 자동으로 추적하므로 버전 번호를 명시적으로 설정할 필요가 없습니다. | 해당 사항 없음 | 아니요 |
ConfigurationVersion |
이 API 프록시가 준수하는 API 프록시 구성 스키마의 버전입니다. 현재 majorVersion 4 및 minorVersion 0만 지원됩니다. 이 설정은 향후에 API 프록시 형식에 만드는 데 사용될 수 있습니다. | 4.0 | 아니요 |
Description |
API 프록시의 텍스트 설명입니다. 이 설명을 제공하면 Apigee UI에 설명이 표시됩니다. | 해당 사항 없음 | 아니요 |
DisplayName |
사용자 친화적인 이름으로, API 프록시 구성의 name 속성과 다를 수 있습니다. |
해당 사항 없음 | 아니요 |
Policies |
API 프록시의 /policies 디렉터리에 있는 정책 목록입니다. 일반적으로 Apigee UI를 사용해 API 프록시가 생성된 경우에만 이 요소가 표시됩니다.
이 설정은 그야말로 API 프록시의 콘텐츠를 볼 수 있도록 설계된 매니페스트 설정입니다. |
해당 사항 없음 | 아니요 |
ProxyEndpoints |
API 프록시의 /proxies 디렉터리에 있는 프록시 엔드포인트 목록입니다. 일반적으로 Apigee UI를 사용해 API 프록시가 생성된 경우에만 이 요소가 표시됩니다. 이 설정은 그야말로 API 프록시의 콘텐츠를 볼 수 있도록 설계된 매니페스트 설정입니다. |
해당 사항 없음 | 아니요 |
Resources |
이 API 프록시의 /resources 디렉터리에 있는 리소스(자바스크립트, Python, 자바, XSLT) 목록입니다. 일반적으로 Apigee UI를 사용해 API 프록시가 생성된 경우에만 이 요소가 표시됩니다. 이 설정은 그야말로 API 프록시의 콘텐츠를 볼 수 있도록 설계된 매니페스트 설정입니다. |
해당 사항 없음 | 아니요 |
Spec |
API 프록시와 연결된 OpenAPI 사양을 식별합니다. 값은 사양 저장소의 경로 또는 URL로 설정됩니다. |
해당 사항 없음 | 아니요 |
TargetServers |
이 API 프록시의 모든 대상 엔드포인트에서 참조되는 대상 서버의 목록입니다. 일반적으로 Apigee를 사용해 API 프록시가 생성된 경우에만 이 요소가 표시됩니다. 이 설정은 그야말로 API 프록시의 콘텐츠를 볼 수 있도록 설계된 매니페스트 설정입니다. | 해당 사항 없음 | 아니요 |
TargetEndpoints |
이 API 프록시의 /targets 디렉터리에 있는 대상 엔드포인트 목록입니다. 일반적으로 Apigee UI를 사용해 API 프록시가 생성된 경우에만 이 요소가 표시됩니다. 이 설정은 그야말로 API 프록시의 콘텐츠를 볼 수 있도록 설계된 매니페스트 설정입니다. |
해당 사항 없음 | 아니요 |
ProxyEndpoint
다음 이미지에서는 요청/응답 흐름을 보여줍니다.
/apiproxy/proxies/default.xml
ProxyEndpoint 구성은 API 프록시의 인바운드(클라이언트 연결) 인터페이스를 정의합니다. 프록시 엔드포인트를 구성할 때 네트워크 구성을 설정하여 클라이언트 애플리케이션(앱)이 프록시된 API를 호출하는 방법을 정의합니다.
다음의 ProxyEndpoint 구성 샘플은 /apiproxy/proxies에 저장됩니다.
<ProxyEndpoint name="default">
<PreFlow/>
<Flows/>
<PostFlow/>
<HTTPProxyConnection>
<BasePath>/weather</BasePath>
<Properties/>
</HTTPProxyConnection>
<FaultRules/>
<DefaultFaultRule/>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>기본 프록시 엔드포인트의 필수 구성 요소는 다음과 같습니다.
ProxyEndpoint 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ProxyEndpoint |
||||||||||||||||||
name |
프록시 엔드포인트 이름입니다. 드물지만 프록시 엔드포인트가 여러 개 정의된 경우 API 프록시 구성 내에서 고유해야 합니다. 이름에 사용할 수 있는 문자는 A-Za-z0-9._\-$ %로 제한됩니다. |
해당 사항 없음 | 예 | |||||||||||||||
PreFlow |
요청 또는 응답의 PreFlow 흐름에서 정책을 정의합니다. | 해당 사항 없음 | 예 | |||||||||||||||
Flows |
요청 또는 응답의 조건부 흐름에 정책을 정의합니다.
|
해당 사항 없음 | 예 | |||||||||||||||
PostFlow |
요청 또는 응답의 PostFlow 흐름에서 정책을 정의합니다.
|
해당 사항 없음 | 예 | |||||||||||||||
HTTPProxyConnection |
API 프록시와 연결된 네트워크 주소와 URI 경로를 정의합니다. | |||||||||||||||||
BasePath |
Apigee에서 수신 메시지를 적절한 API 프록시로 라우팅하는 데 사용되는 URI 경로를 고유하게 식별하는 필수 문자열입니다. BasePath는 API 프록시의 기본 URL(예: 기본 경로에 와일드 카드 사용 API 프록시 기본 경로에서 하나 이상의 '*' 와일드 카드를 사용할 수 있습니다. 예를 들어 중요: Apigee는 와일드 카드 '*'로 시작하는 기본 경로를 지원하지 않습니다. 예를 들어 |
/ | 예 | |||||||||||||||
Properties |
선택적 HTTP 구성 설정 집합을 <ProxyEndpoint>의 속성으로 정의할 수 있습니다.
요청 URL을 처리할 때 <Property name= \ "request.queryparams.ignore.content.type.charset">true</>
다음 표에서는
|
해당 사항 없음 | 아니요 | |||||||||||||||
FaultRules |
프록시 엔드포인트가 오류에 반응하는 방식을 정의합니다. 오류 규칙은 두 가지 항목을 지정합니다.
오류 처리를 참고하세요. |
해당 사항 없음 | 아니요 | |||||||||||||||
DefaultFaultRule |
다른 오류 규칙에서 명시적으로 처리되지 않는 오류(시스템, 전송, 메시지 또는 정책)를 처리합니다. 오류 처리를 참고하세요. |
해당 사항 없음 | 아니요 | |||||||||||||||
RouteRule |
ProxyEndpoint 요청 파이프라인에서 처리한 후에 인바운드 요청 메시지의 대상을 정의합니다. 일반적으로 RouteRule은 명명된 대상 엔드포인트, IntegrationEndpoint, URL을 가리킵니다. | |||||||||||||||||
Name |
RouteRule 이름을 제공하는 필수 속성입니다. 이름에 사용할 수 있는 문자는 A-Za-z0-9._\-$ %로 제한됩니다. 예를 들어 Cat2 %_는 법적 이름입니다. |
해당 사항 없음 | 예 | |||||||||||||||
Condition |
런타임 시 동적 라우팅에 사용되는 선택적 조건문입니다. 예를 들어 조건부 RouteRule은 백엔드 버전 관리를 지원하도록 콘텐츠 기반 라우팅을 사용 설정하는 데 유용합니다. | 해당 사항 없음 | 아니요 | |||||||||||||||
TargetEndpoint |
명명된 TargetEndpoint 구성을 식별하는 선택적 문자열입니다. 명명된 대상 엔드포인트는 대상 엔드포인트의 이름을 지정하면 ProxyEndpoint 요청 파이프라인에서 처리한 후 요청 메시지를 전달할 위치를 지정합니다. 이 설정은 선택사항입니다. 프록시 엔드포인트는 URL을 직접 호출할 수 있습니다. 예를 들어 HTTP 클라이언트 역할에서 작동하는 JavaScript 또는 Java 리소스는 요청을 백엔드 서비스로 전달하는 대상 엔드포인트의 기본 작업을 수행할 수 있습니다. |
해당 사항 없음 | 아니요 | |||||||||||||||
URL |
프록시 엔드포인트에서 호출한 아웃바운드 네트워크 주소를 정의하는 선택적 문자열이며, /targets에 저장할 수 있는 TargetEndpoint 구성을 우회합니다. |
해당 사항 없음 | 아니요 | |||||||||||||||
RouteRule 구성 방법
명명된 대상 엔드포인트는 /apiproxy/targets 아래 구성 파일을 나타내며, RouteRule은 프록시 엔드포인트에서 요청을 처리한 후 구성 파일로 전달합니다.
예를 들어 다음 RouteRule은 /apiproxy/targets/myTarget.xml 구성을 나타냅니다.
<RouteRule name="default"> <TargetEndpoint>myTarget</TargetEndpoint> </RouteRule>
직접 URL 호출
프록시 엔드포인트는 백엔드 서비스를 직접 호출할 수도 있습니다. 직접 URL 호출은 /apiproxy/targets에 있는 명명된 TargetEndpoints 구성을 우회합니다. 따라서 TargetEndpoint는 선택적 API 프록시 구성이지만 실제로는 프록시 엔드포인트의 직접 호출은 권장되지 않습니다.
예를 들어 다음 RouteRule은 http://api.mycompany.com/v2에 대한 HTTP 호출을 수행합니다.
<RouteRule name="default"> <URL>http://api.mycompany.com/v2</URL> </RouteRule>
조건부 경로
RouteRule을 체인으로 연결하여 런타임 시 동적 라우팅을 지원할 수 있습니다. HTTP 헤더, 메시지 콘텐츠, 쿼리 매개변수 또는 시간, 로케일 등의 문맥 정보를 기반으로 명명된 TargetEndpoint 구성, URL 또는 두 개의 조합에 인바운드 요청을 라우팅할 수 있습니다.
조건부 RouteRule은 Apigee에서 다른 조건문처럼 작동합니다. 조건 참조와 흐름 변수 참조를 확인하세요.
예를 들어 다음 RouteRule 조합은 먼저 인바운드 요청을 평가하여 HTTP 헤더 값을 확인합니다. HTTP 헤더 routeTo의 값이 TargetEndpoint1인 경우 요청은 TargetEndpoint1이라는 대상 엔드포인트로 전달됩니다. 그렇지 않으면 요청이 http://api.mycompany.com/v2로 전달됩니다.
<RouteRule name="MyRoute"> <Condition>request.header.routeTo = "TargetEndpoint1"</Condition> <TargetEndpoint>TargetEndpoint1</TargetEndpoint> </RouteRule> <RouteRule name="default"> <URL>http://api.mycompany.com/v2</URL> </RouteRule>
null 경로
요청 메시지를 대상 엔드포인트로 전달할 필요가 없는 시나리오를 지원하려면 null RouteRule을 정의할 수 있습니다. 예를 들어 프록시 엔드포인트가 JavaScript를 사용하여 외부 서비스를 호출하거나 Apigee 키/값 저장소 조회를 통해 데이터를 검색하는 등 필요한 모든 처리를 수행할 때 유용합니다.
예를 들어 다음은 null 경로를 정의합니다.
<RouteRule name="GoNowhere"/>
조건부 null 경로가 유용할 수 있습니다. 다음 예시에서 HTTP 헤더 request.header.X-DoNothing가 null 외의 값이 있는 경우 null 경로를 구성하여 실행합니다.
<RouteRule name="DoNothingOnDemand"> <Condition>request.header.X-DoNothing != null</Condition> </RouteRule>
RouteRule은 연결할 수 있으므로 조건부 null 경로는 일반적으로 조건부 라우팅을 지원하도록 설계된 RouteRule 집합의 한 가지 구성요소가 됩니다.
조건부 null 경로를 실무에서 사용할 경우 캐싱이 지원됩니다. 캐시 정책으로 설정한 변수 값을 사용하면 캐시에서 항목을 제공할 때 null 경로를 실행하도록 API 프록시를 구성할 수 있습니다.
<RouteRule name="DoNothingUnlessTheCacheIsStale"> <Condition>lookupcache.LookupCache-1.cachehit is true</Condition> </RouteRule>
TargetEndpoint
대상 엔드포인트는 프록시 엔드포인트의 아웃바운드 버전입니다. 대상 엔드포인트는 백엔드 서비스 또는 API에 대한 클라이언트 역할을 하며 요청을 전송하고 응답을 수신합니다.
API 프록시에는 대상 엔드포인트가 필요하지 않습니다. 프록시 엔드포인트는 URL을 직접 호출하도록 구성할 수 있습니다. 대상 엔드포인트가 없는 API 프록시에는 일반적으로 백엔드 서비스를 직접 호출하거나 Java 또는 JavaScript를 사용하여 서비스를 호출하도록 구성된 프록시 엔드포인트가 포함되어 있습니다.
TargetEndpoint 구성
/targets/default.xml
대상 엔드포인트는 Apigee에서 다른 서비스 또는 리소스로의 아웃바운드 연결을 정의합니다.
다음은 TargetEndpoint 구성 샘플입니다.
<TargetEndpoint name="default">
<PreFlow/>
<Flows/>
<PostFlow/>
<HTTPTargetConnection>
<URL>http://mocktarget.apigee.net</URL>
<SSLInfo/>
<Authentication/>
</HTTPTargetConnection>
<FaultRules/>
<DefaultFaultRule/>
<ScriptTarget/>
<LocalTargetConnection/>
</TargetEndpoint>TargetEndpoint 구성 요소
대상 엔드포인트는 다음 방법 중 한 가지로 대상을 호출할 수 있습니다.
- HTTP 또는 HTTPS 호출을 위한 HTTPTargetConnection
- 프록시와 프록시 간의 로컬 연결을 위한 LocalTargetConnection
이 중 하나만 대상 엔드포인트에서 구성합니다.
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
TargetEndpoint |
|||
name |
API 프록시 구성 내에서 고유해야 하는 대상 엔드포인트 이름입니다. 대상 엔드포인트 이름은 ProxyEndpoint RouteRule에서 아웃바운드 처리 요청을 전달하는 데 사용됩니다. 이름에 사용할 수 있는 문자는 A-Za-z0-9._\-$ %로 제한됩니다. |
해당 사항 없음 | 예 |
PreFlow |
요청 또는 응답의 PreFlow 흐름에서 정책을 정의합니다. | 해당 사항 없음 | 예 |
Flows |
요청 또는 응답의 조건부 흐름에 정책을 정의합니다.
|
해당 사항 없음 | 예 |
PostFlow |
요청 또는 응답의 PostFlow 흐름에서 정책을 정의합니다.
|
해당 사항 없음 | 예 |
HTTPTargetConnection |
하위 요소를 사용하여 HTTP를 통한 백엔드 리소스 도달범위를 지정합니다. HTTPTargetConnection을 사용하는 경우 다른 유형의 대상 연결(ScriptTarget 또는 LocalTargetConnection)을 구성하지 마세요.
|
||
URL |
대상 엔드포인트가 요청 메시지를 전달할 백엔드 서비스의 네트워크 주소를 정의합니다. | 해당 사항 없음 | 아니요 |
LoadBalancer |
명명된 TargetServer 구성을 한 개 이상 정의합니다. 명명된 TargetServer 구성을 엔드포인트 구성 연결을 2개 이상 정의하는 부하 분산에 사용할 수 있습니다. 또한 대상 서버를 사용하여 API 프록시 구성을 구체적 백엔드 서비스 엔드포인트 URL에서 분리할 수 있습니다. |
해당 사항 없음 | 아니요 |
Properties |
선택적 HTTP 구성 설정 집합을 <TargetEndpoint>의 속성으로 정의할 수 있습니다. |
해당 사항 없음 | 아니요 |
SSLInfo |
선택 사항으로 대상 엔드포인트에 TLS/SSL 설정을 정의하여 API 프록시와 대상 서비스 간의 TLS/SSL 연결을 제어합니다. TLS/SSL TargetEndpoint 구성을 참고하세요. | 해당 사항 없음 | 아니요 |
LocalTargetConnection |
하위 요소를 사용하여 부하 분산 및 메시지 프로세서와 같은 네트워크 특성을 우회하여 로컬로 연결되는 리소스를 지정합니다.
대상 리소스를 지정하려면 APIProxy 하위 요소(ProxyEndpoint 요소 포함) 또는 경로 하위 요소를 포함합니다. 자세한 내용은 API 프록시 함께 연결하기를 참고하세요. LocalTargetConnection을 사용하는 경우 다른 유형의 대상 연결(HTTPTargetConnection 또는 ScriptTarget)을 구성하지 마세요. |
||
APIProxy |
요청의 대상으로 사용할 API 프록시의 이름을 지정합니다. 대상 프록시는 요청을 보내는 프록시와 동일한 조직 및 환경에 있어야 합니다. 이는 경로 요소 대신 사용할 수 있습니다. | 해당 사항 없음 | 아니요 |
ProxyEndpoint |
APIProxy에서 대상 프록시의 프록시 엔드포인트 이름을 지정하는 데 사용됩니다. | 해당 사항 없음 | 아니요 |
Path |
요청의 대상으로 사용할 API 프록시의 엔드포인트 경로를 지정합니다. 대상 프록시는 요청을 보내는 프록시와 동일한 조직 및 환경에 있어야 합니다. 이는 APIProxy 대신 사용할 수 있습니다. | 해당 사항 없음 | 아니요 |
FaultRules |
대상 엔드포인트가 오류에 반응하는 방식을 정의합니다. 오류 규칙은 두 가지 항목을 지정합니다.
오류 처리를 참고하세요. |
해당 사항 없음 | 아니요 |
DefaultFaultRule |
다른 FaultRule에서 명시적으로 처리하지 않은 모든 오류(시스템, 전송, 메시징 또는 정책)를 처리합니다. 오류 처리를 참고하세요. |
해당 사항 없음 | 아니요 |
<Authentication> 요소 사용
<TargetEndpoint>의 <Authentication> 요소 사용은 ServiceCallout 정책의 <Authentication> 요소 사용과 동일합니다. <TargetEndpoint> 및 ServiceCallout 모두에서 <Authentication>는 <HttpTargetConnection>의 하위 요소입니다. 자세한 내용은 ServiceCallout 정책 참조의 인증 요소를 참고하세요.
<Authentication> 요소 오류 참조
<Authentication> 요소를 사용하는 경우 ServiceCallout 정책 문서의 오류 섹션에서 배포 및 런타임 오류에 대한 가능한 오류 메시지와 문제 해결 팁을 확인할 수 있습니다.
<Authentication> 요소 예시
다음 예시에서는 Authentication 요소를 사용하여 Cloud Run에 배포된 서비스를 대상으로 호출하여 호출을 인증하는 데 필요한 OpenID Connect 토큰을 생성하는 방법을 보여줍니다.
<TargetEndpoint name="TargetEndpoint-1">
<HTTPTargetConnection>
<Properties/>
<URL>https://cloudrun-hostname.a.run.app/test</URL>
<Authentication>
<GoogleIDToken>
<Audience>https://cloudrun-hostname.a.run.app/test</Audience>
</GoogleIDToken>
</Authentication>
</HTTPTargetConnection>
</TargetEndpoint>
다음 예시에서는 Authentication 요소를 사용하여 Cloud Run을 가리키는 TargetService를 호출하여 호출을 인증하는 데 필요한 OpenID Connect 토큰을 생성하는 방법을 보여줍니다. HeaderName 요소가 생성된 Bearer 토큰을 대상 시스템으로 전송되는 X-Serverless-Authorization이라는 헤더에 추가합니다. Authorization 헤더가 있는 경우 수정되지 않은 상태로 유지되며 요청에도 전송됩니다.
<TargetEndpoint name="TargetEndpoint-1"> <HTTPTargetConnection> <Authentication> <HeaderName>X-Serverless-Authorization</HeaderName> <GoogleIDToken> <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience> </GoogleIDToken> </Authentication> <LoadBalancer> <Server name="cloud-run-target" /> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
다음 예시에서는 Google Secret Manager 서비스를 가리키는 TargetService를 호출하는 방법을 보여줍니다. 이 예시에서 GoogleAccessToken 요소는 대상 요청을 인증하기 위해 Google 인증 토큰을 생성하도록 구성됩니다.
<HTTPTargetConnection>
<Authentication>
<GoogleAccessToken>
<Scopes>
<Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
</Scopes>
</GoogleAccessToken>
</Authentication>
<URL>
https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
</URL>
</HTTPTargetConnection>
다음 예시에서는 GoogleIDToken의 대상을 자동으로 설정하는 방법을 보여줍니다. useTargetUrl이 true이고 참조된 변수가 유효한 변수로 확인되지 않으면 대상의 URL(쿼리 매개변수 제외)이 대상으로 사용됩니다.
요청 경로가 /foobar이고 대상 서버 URL이 https://xyz.com인 경우 GoogleIDToken의 대상이 자동으로 https://xyz.com/foobar으로 설정됩니다.
<TargetEndpoint name="TargetEndpoint-1"> <HTTPTargetConnection> <Authentication> <GoogleIDToken> <Audience ref='myvariable' useTargetUrl="true"/> </GoogleIDToken> </Authentication> <LoadBalancer> <Server name="TS" /> </LoadBalancer> </HTTPTargetConnection> </TargetEndpoint>
TLS/SSL TargetEndpoint 구성
대상 엔드포인트에서 이기종 백엔드 인프라로 HTTPS 연결을 관리해야 하는 경우가 많습니다. 따라서 다양한 TLS/SSL 구성 설정이 지원됩니다.
TLS/SSL TargetEndpoint 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
SSLInfo |
|
||
Enabled |
그러나 괄호로 묶인
반대로 |
거짓 | 아니요 |
Enforce |
Apigee와 대상 백엔드 간에 엄격한 SSL을 적용합니다.
설정하지 않거나 |
false |
아니요 |
TrustStore |
신뢰할 수 있는 루트 서버 인증서가 포함된 키 저장소 Apigee는 전송하는 인증서 체인이 이 키 저장소에 포함된 인증서로 종료되는 경우 원격 피어를 신뢰할 수 있는 것으로 간주합니다. |
해당 사항 없음 | 아니요 |
ClientAuthEnabled |
양방향 TLS를 사용 설정하려면 일반적으로 Apigee에서 트러스트 저장소와 키 저장소를 모두 설정해야 합니다. |
false |
아니요 |
KeyStore |
아웃바운드 클라이언트 인증에 사용되는 비공개 키가 포함된 키 저장소 | 해당 사항 없음 | 예(ClientAuthEnabled가 true인 경우) |
KeyAlias |
아웃바운드 클라이언트 인증에 사용되는 비공개 키의 키 별칭 | 해당 사항 없음 | 예(ClientAuthEnabled가 true인 경우) |
IgnoreValidationErrors |
유효성 검사 오류 무시 여부를 나타냅니다. 백엔드 시스템이 SNI를 사용하고 호스트 이름과 일치하지 않는 주체 고유 이름(DN)이 있는 인증서를 반환하면 오류를 무시할 수 없으며 연결이 실패합니다. 참고: |
false |
아니요 |
Ciphers |
아웃바운드 TLS/SSL에 지원되는 암호화입니다. 암호화를 지정하지 않으면 JVM에 사용 가능한 모든 암호화가 허용됩니다. 암호화를 제한하려면 지원되는 암호화를 나열하는 다음 요소를 추가합니다. <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers> |
해당 사항 없음 | 아니요 |
Protocols |
아웃바운드 TLS/SSL에 지원되는 프로토콜입니다. 프로토콜을 지정하지 않으면 JVM에 사용 가능한 모든 프로토콜이 허용됩니다. 프로토콜을 제한하려면 명시적으로 지정합니다. 예를 들어 TLS v1.2 또는 TLS v1.3만 허용하려면 다음 안내를 따르세요. <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols> |
해당 사항 없음 | 아니요 |
CommonName |
Apigee는 여기서 값을 원격 피어 인증서의 CN(일반 이름) 또는 SAN(주체 대체 이름)과 대조합니다. |
해당 사항 없음 | 아니요 |
아웃바운드 클라이언트 인증을 사용하는 샘플 대상 엔드포인트
<TargetEndpoint name="default">
<HttpTargetConnection>
<URL>https://myservice.com</URL>
<SSLInfo>
<Enabled>true</Enabled>
<Enforce>true</Enforce>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>myKeystore</KeyStore>
<KeyAlias>myKey</KeyAlias>
<TrustStore>myTruststore</TrustStore>
</SSLInfo>
</HttpTargetConnection>
</TargetEndpoint>자세한 안내는 TLS 구성 옵션을 참조하세요.
흐름 변수를 사용하여 동적으로 TLS/SSL 값 설정
TLS/SSL 세부정보를 동적으로 설정하여 유연한 런타임 요구사항을 지원할 수도 있습니다. 예를 들어 프록시가 잠재적으로 상이한 두 개의 대상(테스트 대상 및 프로덕션 대상)에 연결하는 경우 API 프록시를 통해 호출 중인 환경을 프로그래매틱 방식으로 감지하고 적절한 키 저장소 및 트러스트 저장소에 대한 참조를 동적으로 설정할 수 있습니다. 변수 참조를 사용하는 TargetEndpoint용 동적 SSLInfo Apigee 커뮤니티 문서에서는 이 시나리오를 자세히 설명하고 배포할 수 있는 API 프록시 예시를 제공합니다.
TargetEndpoint 구성에서 <SSLInfo> 태그가 설정되는 방식에 대한 다음 예시에서는 가령 자바 콜아웃, 자바스크립트 정책, AssignMessage 정책 등으로 런타임 시에 값을 제공할 수 있습니다. 설정하려는 값이 포함된 메시지 변수를 사용하세요.
변수는 다음 요소에서만 허용됩니다.
<SSLInfo> <Enabled>{myvars.ssl.enabled}</Enabled> <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled> <KeyStore>{myvars.ssl.keystore}</KeyStore> <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias> <TrustStore>{myvars.ssl.trustStore}</TrustStore> </SSLInfo>
참조를 사용하여 동적으로 TLS/SSL 값 설정
HTTPS를 사용하는 대상 엔드포인트를 구성할 때 TLS/SSL 인증서가 만료되거나 시스템 구성을 변경해야 인증서를 업데이트해야 하는 경우를 고려해야 합니다.
자세한 내용은 만료된 인증서 처리를 참조하세요.
그러나 원하는 경우 키 저장소 또는 트러스트 저장소에 대한 참조를 사용하도록 대상 엔드포인트를 구성할 수 있습니다. 참조를 사용하면 메시지 프로세서를 다시 시작하지 않고도 다른 키 저장소 또는 트러스트 저장소를 가리키는 참조를 업데이트하여 TLS/SSL 인증서를 업데이트할 수 있다는 이점이 있습니다.
예를 들어 아래 대상 엔드포인트는 키 저장소에 대한 참조를 사용합니다.
<SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>false</ClientAuthEnabled> <KeyStore>ref://keystoreref</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> </SSLInfo>
다음 POST API 호출을 사용하여 keystoreref라는 참조를 만드세요.
curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
-X POST \
-H "Authorization: Bearer $TOKEN" \
-d '<ResourceReference name="keystoreref">
<Refers>myTestKeystore</Refers>
<ResourceType>KeyStore</ResourceType>
</ResourceReference>'$TOKEN를 OAuth 2.0 액세스 토큰 가져오기에 설명된 대로 OAuth 2.0 액세스 토큰으로 설정합니다. 이 예시에서 사용된 curl 옵션에 대한 자세한 내용은 curl 사용을 참조하세요. 사용된 환경 변수에 대한 설명은 Apigee API 요청에 대한 환경 변수 설정을 참조하세요.
참조는 키 저장소의 이름과 유형을 지정합니다.
참조를 보려면 다음 GET API 호출을 사용하세요.
curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
-H "Authorization: Bearer $TOKEN"
$TOKEN를 OAuth 2.0 액세스 토큰 가져오기에 설명된 대로 OAuth 2.0 액세스 토큰으로 설정합니다. 이 예시에서 사용된 curl 옵션에 대한 자세한 내용은 curl 사용을 참조하세요. 사용된 환경 변수에 대한 설명은 Apigee API 요청에 대한 환경 변수 설정을 참조하세요.
curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
-H "Authorization: Bearer $TOKEN"
$TOKEN를 OAuth 2.0 액세스 토큰 가져오기에 설명된 대로 OAuth 2.0 액세스 토큰으로 설정합니다. 이 예시에서 사용된 curl 옵션에 대한 자세한 내용은 curl 사용을 참조하세요. 사용된 환경 변수에 대한 설명은 Apigee API 요청에 대한 환경 변수 설정을 참조하세요.
다른 키 저장소를 가리키도록 나중에 참조를 변경하여 별칭의 이름을 동일하게 하려면 다음 PUT 호출을 사용합니다.
curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
-X PUT \
-H "Authorization: Bearer $TOKEN" \
-d '<ResourceReference name="keystoreref">
<Refers>myNewKeystore</Refers>
<ResourceType>KeyStore</ResourceType>
</ResourceReference>'$TOKEN를 OAuth 2.0 액세스 토큰 가져오기에 설명된 대로 OAuth 2.0 액세스 토큰으로 설정합니다. 이 예시에서 사용된 curl 옵션에 대한 자세한 내용은 curl 사용을 참조하세요. 사용된 환경 변수에 대한 설명은 Apigee API 요청에 대한 환경 변수 설정을 참조하세요.
대상 부하 분산을 사용하는 TargetEndpoint
대상 엔드포인트는 세 개의 부하 분산 알고리즘을 사용하여 명명된 여러 개의 대상 서버에서 부하 분산을 지원합니다.
자세한 안내는 백엔드 서버의 부하 분산을 참조하세요.
IntegrationEndpoint
IntegrationEndpoint는 특히 Apigee Integration을 실행하는 대상 엔드포인트입니다. IntegrationEndpoint를 구성한 경우 Apigee가 요청 객체를 실행하도록 Apigee의 통합 플랫폼으로 전송합니다. 통합을 실행하려면 IntegrationEndpoint 구성 외에도 프록시 흐름에 SetIntegrationRequest 정책을 추가해야 합니다.
IntegrationEndpoint 구성에서 <AsyncExecution> 요소를 설정하여 동기적 또는 비동기적으로 실행할 통합을 구성할 수 있습니다. 자세한 내용은 동기적 실행 및 비동기적 실행 비교를 참조하세요.
통합을 실행한 후에는 Apigee가 응답을 응답 메시지에 저장합니다.
IntegrationEndpoint 구성
통합 엔드포인트를 대상 엔드포인트로 구성하려면 ProxyEndpoint 구성에 IntegrationEndpoint 요소를 추가합니다. 다음은 샘플 ProxyEndpoint 구성입니다.
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>my-set-integration-request-policy</Name>
</Step>
</Request>
</PreFlow>
<Flows/>
<PostFlow name="PostFlow"/>
<HTTPProxyConnection>
<BasePath>/integration-endpoint-test</BasePath>
<Properties/>
</HTTPProxyConnection>
<RouteRule name="default">
<IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
</RouteRule>
</ProxyEndpoint>샘플 ProxyEndpoint 구성에서 Apigee는 다음 태스크를 수행합니다.
- PreFlow에서
my-set-integration-request-policy라는 정책을 실행합니다. 이 정책은 통합 요청 객체 및 통합 흐름 변수를 설정합니다. RouteRule에 지정된 대로my-int-endpoint를 대상 엔드포인트로 사용합니다.my-set-integration-request-policy로 생성된 통합 요청 객체를 읽습니다.- SetIntegrationRequest 정책에 의해 설정된 요청 객체 및 흐름 변수를 사용하여 Apigee의 통합 플랫폼에 요청을 전송합니다.
- 통합 응답을 응답 메시지에 저장합니다.
<IntegrationEndpoint> 선언을 포함하는 XML 파일은 APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/ 디렉터리에서 사용할 수 있습니다. Develop > API Proxies > CREATE NEW > Integration target 옵션을 사용하여 API 프록시를 만드는 경우 Apigee가 /apiproxy/integration-endpoints/default.xml 파일에 선언을 저장합니다. UI에서 통합 엔드포인트 XML을 만든 경우 XML 파일에 대해 커스텀 이름을 제공할 수 있습니다.
다음 예시는 XML 파일에서 <IntegrationEndpoint> 요소의 선언을 보여줍니다.
<IntegrationEndpoint name="my-int-endpoint">
<AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>IntegrationEndpoint 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
IntegrationEndpoint |
|||
name |
IntegrationEndpoint의 이름입니다. 이름에 사용할 수 있는 문자는 A-Za-z0-9._\-$ %로 제한됩니다. |
해당 사항 없음 | 예 |
AsyncExecution |
통합을 동기 또는 비동기 모드로 실행할지 여부를 지정하는 불리언 값입니다. 자세한 내용은 동기적 실행 및 비동기적 실행 비교를 참조하세요. | false | 아니요 |
동기적 실행 및 비동기적 실행 비교
통합이 동기 또는 비동기 모드에서 실행되도록 구성할 수 있습니다. 동기 실행 모드와 비동기 실행 모드의 차이점은 <AsyncExecution>을 참조하세요.
</IntegrationEndpoint> 내의 <AsyncExecution> 요소를 사용하여 동기적 또는 비동기적 실행을 지정합니다. <AsyncExecution>을 true로 설정하면 통합이 비동기적으로 실행됩니다. false로 설정하면 통합이 동기적으로 실행됩니다.
다음 예시에서는 AsyncExecution을 true로 설정합니다.
<IntegrationEndpoint name="my-int-endpoint">
<AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>정책
API 프록시의 /policies 디렉터리에는 API 프록시의 흐름에 연결할 수 있는 모든 정책이 포함됩니다.
정책 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
Policy |
|||
name |
정책의 내부 이름입니다. 이름에 사용할 수 있는 문자는 원하는 경우 |
해당 사항 없음 | 예 |
enabled |
정책을 시행하려면 정책을 중지하려면 |
true |
아니요 |
continueOnError |
정책이 실패할 경우 오류가 반환되도록 하려면 정책이 실패해도 흐름 실행이 계속되도록 하려면 |
false |
아니요 |
async |
API 프록시에서 비동기 동작을 사용하려면 자바스크립트 객체 모델을 참고하세요. |
false |
아니요 |
정책 연결
다음 이미지에서는 API 프록시 흐름 실행 시퀀스를 보여줍니다.
다음은 위 그림에 대한 설명입니다.
정책은 흐름의 처리 단계로 연결됩니다. 정책 이름은 처리 단계에서 적용할 정책을 참조하는 데 사용됩니다. 정책 연결 형식은 다음과 같습니다.
<Step><Name>MyPolicy</Name></Step>
정책은 흐름에 연결된 순서대로 적용됩니다. 예를 들면 다음과 같습니다.
<Step><Name>FirstPolicy</Name></Step> <Step><Name>SecondPolicy</Name></Step>
정책 연결 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
Step |
|||
Name |
이 단계 정의로 실행할 정책의 이름입니다. | 해당 사항 없음 | 예 |
Condition |
정책 적용 여부를 결정하는 조건문입니다. 정책에 연결된 조건이 있으면 조건문이 true로 평가될 때만 정책이 실행됩니다. | 해당 사항 없음 | 아니요 |
흐름
ProxyEndpoint 및 TargetEndpoint는 요청 및 응답 메시지 처리를 위한 파이프라인을 정의합니다. 처리 파이프라인은 요청 흐름과 응답 흐름으로 구성됩니다. 각 요청 흐름과 응답 흐름은 PreFlow, 하나 이상의 선택적 조건부 또는 이름이 지정된 흐름, PostFlow로 세분화됩니다.
- PreFlow: 항상 실행됩니다. 조건부 흐름 전에 실행됩니다.
- PostFlow: 항상 실행됩니다. 조건부 흐름 후에 실행됩니다.
또한 요청 클라이언트 앱에 응답이 반환된 후에 실행되는 PostClientFlow를 프록시 엔드포인트에 추가할 수 있습니다. 이 흐름에는 MessageLogging 정책만 연결할 수 있습니다. PostClientFlow는 API 프록시 지연 시간을 줄이고, 응답이 클라이언트에 반환될 때까지 계산하지 않는 로깅 정보(예: client.sent.start.timestamp 및 client.sent.end.timestamp)를 제공합니다. 이 흐름은 주로 응답 메시지의 시작 타임스탬프와 종료 타임스탬프 사이의 시간 간격을 측정하는 데 사용됩니다.
다음은 메시지 로깅 정책이 연결된 PostClientFlow의 예시입니다.
...
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<PostClientFlow>
<Request/>
<Response>
<Step>
<Name>Message-Logging-1</Name>
</Step>
</Response>
</PostClientFlow>
...API 프록시 처리 파이프라인은 다음 순서로 흐름을 실행합니다.
요청 파이프라인:
- 프록시 요청 PreFlow
- 프록시 요청 조건부 흐름(선택사항)
- 프록시 요청 PostFlow
- 대상 요청 PreFlow
- 대상 요청 조건부 흐름(선택사항)
- 대상 요청 PostFlow
응답 파이프라인:
- 대상 응답 PreFlow
- 대상 응답 조건부 흐름(선택사항)
- 대상 응답 PostFlow
- 프록시 응답 PreFlow
- 프록시 응답 조건부 흐름(선택사항)
- 프록시 응답 PostFlow
- PostClientFlow 응답(선택사항)
정책이 연결된 흐름만 ProxyEndpoint 또는 TargetEndpoint 구성에서 구성해야 합니다. PreFlow 및 PostFlow는 PreFlow 또는 PostFlow 처리 중에 정책을 적용해야 하는 경우 ProxyEndpoint 또는 TargetEndpoint 구성에서만 지정해야 합니다.
조건부 흐름과 달리 PreFlow 및 PostFlow 요소의 순서는 중요하지 않습니다. API 프록시는 엔드포인트 구성에서 나타나는 위치와 관계없이 항상 파이프라인의 적절한 지점에서 실행됩니다.
조건부 흐름
프록시 엔드포인트 및 대상 엔드포인트는 제한된 수의 조건부 흐름(이름이 지정된 흐름이라고도 함)을 지원합니다.
API 프록시는 조건부 흐름에서 지정된 조건을 테스트하고, 조건이 충족되면 조건부 흐름의 처리 단계가 API 프록시에 의해 실행됩니다. 조건이 충족되지 않으면 조건부 흐름의 처리 단계가 우회됩니다. 조건부 흐름은 API 프록시에 정의된 순서대로 평가되며 조건이 충족되는 첫 번째 흐름이 실행됩니다.
조건부 흐름을 정의하면 다음을 기준으로 API 프록시에 처리 단계를 적용할 수 있습니다.
- 요청 URI
- HTTP 동사(
GET/PUT/POST/DELETE) - 쿼리 매개변수, 헤더, 양식 매개변수의 값
- 기타 여러 유형의 조건
예를 들어 다음 조건부 흐름은 요청 리소스 경로가 /accesstoken일 때만 실행되도록 지정합니다. 경로가 /accesstoken인 인바운드 요청으로 인해 흐름에 연결된 정책과 함께 이 흐름이 실행됩니다. 요청 경로에 /accesstoken 서픽스가 포함되어 있지 않으면 흐름은 실행되지 않습니다(다른 조건부 흐름이 있을 수 있음).
<Flows>
<Flow name="TokenEndpoint">
<Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
<Request>
<Step>
<Name>GenerateAccessToken</Name>
</Step>
</Request>
</Flow>
</Flows> 흐름 구성 요소
| 이름 | 설명 | 기본값 | 필수 여부 |
|---|---|---|---|
Flow |
프록시 엔드포인트 또는 대상 엔드포인트에서 정의한 요청 또는 응답 처리 파이프라인 | ||
Name |
흐름의 고유한 이름입니다. | 해당 사항 없음 | 예 |
Condition |
하나 이상의 변수를 평가하여 true 또는 false로 평가되는 조건문입니다. 사전 정의된 PreFlow 및 PostFlow 유형을 제외한 모든 흐름이 실행 조건을 정의해야 합니다. 하지만 흐름 순서 끝에 조건 없이 단일 흐름을 포함하면 흐름 순서의 끝에서 "Else" 문으로 작동합니다. | 해당 사항 없음 | 예 |
Request |
요청 메시지 처리와 관련된 파이프라인 | 해당 사항 없음 | 아니요 |
Response |
응답 메시지 처리와 관련된 파이프라인 | 해당 사항 없음 | 아니요 |
단계 처리
Apigee는 조건부 흐름의 순차적 순서를 적용합니다. 조건부 흐름은 하향식으로 실행됩니다. 조건이 true로 평가되는 첫 번째 조건부 흐름이 실행되며, 단 하나의 조건부 흐름만 실행됩니다.
예를 들어 다음 흐름 구성에서 경로 서픽스 /first 또는 /second를 포함하지 않는 모든 인바운드 요청은 ThirdFlow를 실행하여 Return404라는 정책을 적용합니다.
<Flows>
<Flow name="FirstFlow">
<Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
<Request>
<Step><Name>FirstPolicy</Name></Step>
</Request>
</Flow>
<Flow name="SecondFlow">
<Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
<Request>
<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>
</Request>
</Flow>
<Flow name="ThirdFlow">
<Request>
<Step><Name>Return404</Name></Step>
</Request>
</Flow>
</Flows>리소스
'리소스'(API 프록시에서 사용할 리소스 파일)는 정책을 사용하여 흐름에 연결할 수 있는 스크립트, 코드, XSL 변환입니다. 이는 Apigee UI의 API 프록시 편집기에 있는 스크립트 섹션에 나타납니다.
지원되는 리소스 유형은 리소스 관리를 참조하세요.
리소스는 API 프록시, 환경, 조직에 저장될 수 있습니다. 각각의 경우 리소스는 정책의 이름을 기준으로 참조됩니다. Apigee는 API 프록시로부터 환경, 조직 수준으로 이동하여 이름을 확인합니다.
조직 수준에 저장된 리소스는 모든 환경의 정책을 기준으로 참조될 수 있습니다. 환경 수준에 저장된 리소스는 이 환경의 정책을 기준으로 참조될 수 있습니다. API 프록시 수준에 저장된 리소스는 이 API 프록시의 정책을 기준으로만 참조될 수 있습니다.