이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.
Apigee Edge 문서 보기
다음 섹션에서는 Apigee를 사용한 API 개발 수명 주기를 요약해서 보여줍니다.
API 프록시 개발
Apigee는 반복되는 API 프록시 개발을 위해 다음 옵션을 지원합니다.
API 프록시에 대한 자세한 내용은 API 및 API 프록시 이해를 참조하세요.
Apigee를 사용한 Cloud 개발
Apigee로 제공되는 API 프록시 수정 및 디버깅 도구를 사용하여 API 프록시를 개발합니다. API 프록시에서 작업할 때 Apigee는 구성 반복을 버전으로 저장합니다.
API 프록시를 배포할 때 배포할 특정 버전을 선택합니다. 일반적으로 최신 버전을 배포하고 필요에 따라 이전 버전으로 되돌립니다. API 프록시 배포를 참조하세요.
Apigee를 사용하여 API 프록시 개발을 시작하려면 간단한 API 프록시 빌드를 참조하세요.
VS Code로 Apigee를 사용한 로컬 개발
Visual Studio Code(VS Code)에서 Apigee를 사용하여 API 프록시를 개발하고 단위 및 수동 테스트를 통해 기능을 확인할 수 있습니다(예: 요청 보내기 및 결과 보기).
로컬 검증을 완료한 후 API 프록시 구성을 보관 파일로서 Apigee 환경에 배포합니다. API 프록시 배포를 참조하세요.
VS Code로 Apigee를 사용하여 로컬로 API 프록시 개발을 시작하려면 VS Code로 첫 번째 API 프록시 빌드를 참조하세요.
API 프록시 배포
API 프록시를 배포할 환경을 만듭니다. 서로 다른 환경 간의 차이점은 임의적입니다. 각 환경은 단순히 서로 다른 네트워크 주소(URL)로 식별됩니다. 목표는 API가 외부 개발자에게 노출되기 전에 API 프록시를 빌드하고 확인할 수 있는 도메인을 제공하는 것입니다. 자세한 내용은 환경 및 환경 그룹 정보를 참조하세요.
API를 여러 환경에 배포하면 테스트 환경에서 작업 중인 API 프록시 간 트래픽과 프로덕션 환경에서 런타임 시 외부 앱에서 액세스되는 트래픽을 구분할 수 있습니다.
Apigee는 환경에서 다음 배포 유형을 지원합니다.
| 유형 | 설명 |
| 프록시 | Apigee 개발 환경에서 API 프록시를 개발 및 테스트한 후 이를 Apigee 통합 테스트 및 프로덕션 환경에 배포합니다. API 프록시 배포를 참조하세요. |
| Archive | VS Code에서 Apigee를 사용하여 프로그래밍 가능한 API 프록시를 개발하고 테스트합니다. |
정책 추가
Apigee를 사용하면 코드를 작성하지 않고 정책을 사용하여 API 동작을 프로그래밍할 수 있습니다. 정책은 특정적으로 제한된 관리 기능을 구현하는 모듈과 같습니다. 정책을 사용하면 API에 일반적인 관리 기능을 쉽게 안정적으로 추가할 수 있습니다. 정책은 보안, 비율 제한, 변환, 중재와 같은 기능을 제공하므로 이러한 기능을 직접 코딩하고 유지할 필요가 없습니다. 또한 커스텀 스크립트와 코드(예: 자바스크립트 애플리케이션)를 작성하여 API 프록시 기능을 확장하고 Apigee 정책에서 지원하는 기본 관리 기능을 기반으로 혁신할 수 있습니다. Apigee 정책에 대한 자세한 내용은 정책이란 무엇인가요?를 참조하세요.
Apigee는 트래픽 관리, 보안, 중재, 확장 정책과 같은 여러 기능을 위해 즉시 사용 가능한 정책을 제공합니다. Apigee에서 사용 가능한 전체 정책 목록을 보려면 정책 참조 개요를 참조하세요.
프로덕션으로 승격
API를 배포할 위치를 선택합니다. 예를 들어 개발자가 API 작업을 시작할 수 있도록 버전을 프로덕션 환경으로 승격할 수 있습니다. 동시에 로컬 또는 테스트 환경에서 여러 버전을 반복할 수 있습니다. 여기에서 기능을 추가하거나 정책을 세부 조정할 수 있습니다. 그런 다음 준비가 되면 새 버전을 프로덕션 환경에 배포하여 해당 환경의 기존 버전을 덮어쓸 수 있습니다. 이 방법을 사용하면 새 기능을 개발 및 테스트할 때 항상 개발자에게 API의 라이브 버전을 제공할 수 있습니다.
Apigee API를 사용하여 배포 스크립팅
Apigee는 API 프록시 배포 및 관리를 조직의 소프트웨어 개발 수명 주기(SDLC)에 통합할 수 있는 RESTful API를 제공합니다. 예를 들어 보안, 안정성, 일관성 요구사항을 충족하기 위해 Apigee API는 프로그래매틱 방식으로 API 프록시를 배포하고 대규모 자동화 프로세스의 일환으로 한 환경에서 다른 환경으로 승격시키는 스크립트 또는 코드를 작성하는 용도로 흔히 쓰입니다.
자세한 내용은 Apigee API를 참조하세요.
환경 리소스 관리
환경은 데이터와 리소스의 분리를 제공합니다. 예를 들어 해당 환경에서 실행되는 API 프록시에서만 액세스할 수 있는 test 및 production 환경에서 다른 캐시를 설정할 수 있습니다. 또한 테스트 환경에서 발급되는 API 키는 프로덕션 환경에서 유효하지 않으며 그 반대의 경우도 마찬가지입니다.
승격 중에 제어를 강화하려면 테스트 환경에서 API 프록시를 반복하고 프로덕션 환경에 배포된 API 프록시를 가능한 변경하지 않는 것이 좋습니다.
이렇게 하려면 각 환경과 연결된 특정 리소스가 API 프록시 구성에서 정적 상태를 유지할 수 있도록 구성되어 있는지 확인해야 합니다.
- 키 값 맵(KVM): 환경으로 범위를 지정하는 경우 프로모션 도중 구성을 변경하지 않고 API 프록시를 통해 데이터를 저장할 수 있도록 이름 지정 규칙을 사용해야 합니다. 자세한 내용은 키 값 맵 사용을 참조하세요.
- 대상 URL: 테스트 및 프로덕션 중에 API 프록시가 다른 백엔드 URL을 호출하는 것이 일반적입니다. TargetServer 구성을 사용하여 환경에 독립적인 TargetEndpoint 구성을 만들 수 있습니다. 자세한 내용은 다음을 참조하세요.
- 백엔드 서버 간 부하 분산(Cloud 개발)
- 대상 서버 구성(로컬 개발)
- ServiceCallout 대상: 서비스 콜아웃은 환경에 따라 다른 대상을 사용할 수 있습니다. 예를 들어 테스트 환경의 ServiceCallout은 데모 서비스를 사용합니다. ServiceCallout 정책을 참조하세요.
API 프록시 구성을 환경과 독립적으로 만들려면 조건문을 사용할 수도 있습니다.
environment.name 변수로 빌드된 조건문은 정책을 시행하거나 백엔드의 URL로 라우팅하기 전에 현재 환경을 평가하는 데 사용할 수 있습니다. 자세한 내용은 흐름 변수가 있는 조건을 참조하세요.