Apigee 아키텍처 개요

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee Edge 문서 보기

이 주제에서는 Apigee 시스템 아키텍처를 간략하게 설명합니다. 이 주제를 통해 프로비저닝 중에 생성되는 구성요소와 전체 시스템의 목적을 이해할 수 있습니다.

Apigee는 VPC 피어링 사용 및 VPC 피어링 없음이라는 두 가지 프로비저닝 옵션을 제공합니다. 다음 섹션에서는 두 옵션을 모두 설명합니다.

  • VPC 피어링이 사용 설정된 아키텍처
  • VPC 피어링이 사용 중지된 아키텍처

    • VPC 피어링이 사용 설정된 아키텍처

    이 섹션에서는 Apigee가 VPC 피어링 옵션으로 프로비저닝될 때 Apigee 시스템 아키텍처를 설명합니다.

    프로비저닝 개요

    프로비저닝 중에 개발자가 관리하는 virtual private cloud 네트워크(VPC)와 Apigee에서 관리하는 VPC 네트워크 간의 양방향 통신을 허용하는 구성요소가 구성되고 생성됩니다. 처음 몇 가지 프로비저닝 단계를 완료하면 VPC가 두 개 존재하지만 아직은 서로 통신할 수 없습니다. 양방향 통신을 허용하려면 추가 구성이 필요합니다. 그림 1을 참조하세요.

    그림 1: VPC와 Apigee의 VPC는 추가 구성이 없어 서로 통신할 수 없습니다.

    VPC 간의 통신을 사용 설정하려면 VPC 네트워크 피어링을 사용합니다. 네트워크 피어링은 Virtual Private Cloud(VPC) 네트워크 두 개가 동일한 프로젝트나 동일한 Google Cloud 조직에 속하는지 여부에 관계없이 두 네트워크에서 내부 IP 주소 연결을 허용합니다. 네트워크 피어링 단계가 완료되면 두 VPC 간에 통신할 수 있습니다. 그림 2를 참조하세요.

    그림 2: VPC 네트워크 피어링을 통해 VPC 간에 통신할 수 있습니다.

    인터넷의 클라이언트 앱에서 Apigee로 트래픽을 라우팅하려면 전역 외부 HTTPS 부하 분산기(XLB)를 사용합니다. XLB는 교차 프로젝트 서비스 참조를 사용하여 고객 Google Cloud 프로젝트와 Apigee Google Cloud 프로젝트 간에' 통신할 수 있습니다.

    네트워크 브리지 역할을 하는 가상 머신(VM)의 관리형 인스턴스 그룹(MIG)을 프로비저닝할 수도 있습니다. MIG VM은 피어링된 네트워크에서 양방향으로 통신할 수 있습니다. 프로비저닝이 완료되면 인터넷의 앱은 XLB와, XLB는 브리지 VM과, 브리지 VM은 Apigee 네트워크와 통신합니다. 그림 3과 그림 4를 참조하세요.

    그림 3: 관리형 VM을 사용하면 피어링된 네트워크 간에 요청 및 응답이 전송될 수 있습니다.

    이 구성에서 트래픽은 Apigee(예: MessageLogging 정책)에서 내부 VPC에서 실행되는 워크로드로 라우팅됩니다. 이 경우 내부 VPC와의 통신은 이그레스의 NAT IP를 거치지 않습니다. 대신 Apigee 인스턴스 IP 중 하나를 통해 트래픽을 라우팅할 수 있습니다.

    그림 4: 비공개로 내부 VPC의 워크로드로 라우팅되는 트래픽

    API 프록시 호출 수명 주기

    다음 이미지에서는 프로비저닝된 Apigee 시스템 구성요소를 통해 이동하는 API 프록시 호출의 수명 주기를 보여줍니다(그림 5).

    그림 5: 비공개로 내부 VPC의 워크로드로 라우팅되는 트래픽입니다.
    1. 클라이언트 앱에서 Apigee API 프록시를 호출합니다.
    2. 요청은 전역 L7 외부 HTTPS 부하 분산기(XLB)로 전송됩니다. XLB는 외부/공개 IP와 TLS 인증서로 구성됩니다.
    3. XLB는 요청을 가상 머신(VM)으로 전송합니다. VM은 VPC와 Apigee에서 관리하는 Google VPC 간의 브리지 역할을 합니다.
    4. VM이 API 프록시 요청을 처리하는 Apigee로 요청을 보냅니다.
    5. Apigee에서 요청을 백엔드 서비스로 보내고 응답은 클라이언트로 다시 전송됩니다.

    VPC 피어링이 사용 중지된 아키텍처

    이 섹션에서는 Apigee가 VPC 피어링 옵션으로 프로비저닝되지 않은 경우의 Apigee 시스템 아키텍처를 설명합니다.

    프로비저닝 중에 개발자가 관리하는 virtual private cloud 네트워크(VPC)와 Apigee에서 관리하는 VPC 네트워크 간의 양방향 통신을 허용하는 구성요소가 구성되고 생성됩니다. 처음 몇 가지 프로비저닝 단계를 완료하면 VPC가 두 개 존재하지만 아직은 서로 통신할 수 없습니다. 양방향 통신을 허용하려면 추가 구성이 필요합니다. 그림 6을 참조하세요.

    그림 6: VPC와 Apigee의 VPC는 추가 구성이 없어 서로 통신할 수 없습니다.

    VPC 간의 통신을 사용 설정하기 위해 northbound 트래픽을 Apigee로 라우팅하고 Southbound 트래픽을 Google Cloud 프로젝트에서 실행되는 대상 서비스로 라우팅하기 위해 Private Service Connect(PSC)를 사용합니다.

    PSC를 사용하면 서비스 프로듀서(Apigee)와 서비스 소비자(제어하는 하나 이상의 다른 Cloud 프로젝트) 간의 비공개 연결이 가능합니다. 이 방법(그림 7)을 사용하면 요청이 전역 외부 부하 분산기나 리전 외부 부하 분산기를 통해 서비스 연결이라는 단일 연결 지점으로 전달됩니다.

    Apigee를 백엔드 대상에 비공개로 연결하려면 다음 두 가지 항목을 만들어야 합니다. 즉, 대상이 배포되는 VPC 네트워크의 서비스 연결 및 Apigee VPC의 엔드포인트 연결입니다. 이 두 항목을 통해 Apigee는 대상 서비스에 연결할 수 있습니다. Southbound 네트워킹 패턴을 참조하세요.

    PSC로 VPC를 프로비저닝하는(VPC 피어링 없음) 단계는 VPC 피어링 없이 명령줄 프로비저닝에 설명되어 있습니다.

    그림 7. VPC 피어링이 없는 Apigee 아키텍처입니다. 이 아키텍처에 대한 자세한 내용은 Apigee 아키텍처 개요를 참조하세요.