공개 IP 주소가 있는 대상 백엔드와 Apigee 간의 Southbound 트래픽은 Cloud NAT를 사용하여 Apigee 인스턴스의 비공개 IP 주소를 공개 IP 주소로 변환합니다. 각 Apigee 인스턴스에는 자체 Cloud NAT 게이트웨이가 있습니다. 이 주제에서는 Cloud NAT를 사용할 때 Apigee 성능에 영향을 미치는 요소를 설명합니다.
개요
Apigee 인스턴스와 대상 백엔드 간에 형성되는 각각의 새 TCP 세션은 다음을 포함하는 고유한 4튜플에 매핑되어야 합니다.
NAT IP 주소
NAT 포트
백엔드 IP 주소
백엔드 포트
Cloud NAT가 Apigee 인스턴스에서 지원할 수 있는 초당 트랜잭션 수(TPS)를 결정하는 세 가지 주요 요소가 있습니다.
할당된 NAT IP 수(동적 또는 정적)
구성된 고유 백엔드 IP 주소 및 포트 조합의 수
타겟 백엔드에서 연결 재사용을 허용하는지 여부
이 주제에서는 Cloud NAT를 사용할 때 이러한 각 요소가 Apigee 성능에 미치는 영향을 설명하고 예상 트래픽을 지원하는 데 필요한 고정 IP 수를 계산하는 방법을 설명합니다.
NAT IP 할당
할당된 NAT IP 수는 NAT 구성에서 임시 또는 고정 IP의 사용에 따라 달라집니다.
자세한 내용은 Cloud NAT 한도에서 게이트웨이당 NAT IP 주소를 참조하세요.
임시 IP
임시 IP를 사용하는 기본 NAT 구성에서는 대상 백엔드에 연결하기 위한 고유한 소스 포트를 제공하기 위해 필요에 따라 IP가 자동으로 할당됩니다.
고정 IP
대상 백엔드의 IP를 허용 목록에 포함할 수 있도록 고정 IP가 필요한 경우에는 IP가 Apigee 인스턴스용으로 수동으로 예약됩니다.
고유 백엔드 IP 및 포트 조합
고유 대상 백엔드 IP 및 포트 조합 수를 늘려 TPS를 늘릴 수 있습니다. 각 대상 백엔드 IP 및 소스 포트에 동일한 NAT IP 및 포트를 사용하는 것이 가능합니다. 이렇게 하면 허용 목록에 추가되어야 하는 IP를 추가할 필요 없이 NAT IP를 더 추가하는 것과 동일한 결과를 얻을 수 있습니다.
고유한 대상 백엔드 IP와 포트 쌍을 만들려면 IP 또는포트가 달라야 합니다. 예를 들어 하나의 부하 분산기에 단일 IP 주소가 있지만 4개의 서로 다른 포트에서 리슨하여 4개의 고유 백엔드 IP와 포트 조합을 Apigee에 만드는 것이 가능합니다.
연결 재사용
HTTP 연결을 재사용하면 새 TCP 연결을 열 필요가 없어 NAT의 효율적인 사용도 늘어납니다. 대상 백엔드는 응답에서 HTTP의 기본 설정인 Connection 헤더를 keep-alive로 설정함으로써 이 기능을 사용할 수 있는데, 이것이 HTTP/1.1의 기본 설정입니다. 타겟 백엔드 서버에서 connection timeout 및 max reuse 매개변수를 설정하여 효율성을 개선할 수도 있습니다.
이론적으로는 응답에서 keep-alive를 사용 설정하여 연결 재사용을 지원할 수 있지만 실제로는 연결 재사용이 다음 사항에 따라 달라집니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-19(UTC)"],[[["\u003cp\u003eThis document details how Cloud NAT impacts Apigee performance, specifically in scenarios involving southbound traffic to target backends with public IP addresses.\u003c/p\u003e\n"],["\u003cp\u003eCloud NAT's transactions per second (TPS) capacity in Apigee instances is determined by the number of NAT IPs, the uniqueness of backend IP and port combinations, and whether target backends allow connection reuse.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing unique combinations of backend IP addresses and ports can enhance TPS without the need for additional NAT IPs, which may be significant when dealing with allow-lists.\u003c/p\u003e\n"],["\u003cp\u003eConnection reuse, achieved through the \u003ccode\u003eConnection: keep-alive\u003c/code\u003e header, can improve the efficiency of NAT usage by reducing the need for new TCP connections, though its effectiveness depends on various connection factors.\u003c/p\u003e\n"],["\u003cp\u003eThe number of NAT IPs can be varied based on whether ephemeral or static IPs are utilized, with static IPs being necessary when IP allow-listing is needed at the target backend.\u003c/p\u003e\n"]]],[],null,["# Performance considerations for Apigee Cloud NAT\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nSouthbound traffic between Apigee and a target backend with a public IP address uses [Cloud NAT](https://cloud.google.com/nat/docs/overview) to translate\nthe private IP address of the Apigee instance into a public IP address. Each Apigee\ninstance has its own Cloud NAT gateway. This topic explains the factors that impact Apigee performance when using\nCloud NAT.\n\nOverview\n--------\n\n\nEach new TCP session formed between an Apigee instance and a target backend must be mapped to a unique 4-tuple that includes the following:\n\n- The NAT IP address\n- The NAT port\n- The backend IP address\n- The backend port\n\nThere are three key factors that determine the transactions per second (TPS) that Cloud NAT can support in an Apigee instance:\n\n1. The number of NAT IPs allocated (dynamically or statically)\n2. The number of unique backend IP address and port combinations configured\n3. Whether or not connection reuse is allowed by the target backend\n\n\nThis topic explains how each of these factors impacts Apigee performance when using Cloud NAT and describes how to calculate the number of static IPs that may be required to support anticipated traffic.\n\nNAT IP Allocations\n------------------\n\n\nThe number of NAT IPs allocated will vary depending on the use of *ephemeral* or *static* IPs in the NAT configuration.\nSee the **NAT IP addresses per gateway** in the [Cloud NAT Limits](/nat/quota#limits) for more information.\n\n### Ephemeral IPs\n\n\nIn the default NAT configuration using ephemeral IPs, the IPs are automatically allocated as needed to provide unique source ports for connections to target backends.\n\n### Static IPs\n\n\nIf static IPs are required so that the IPs can be allow-listed for the target backend, the IPs are manually reserved for an Apigee instance.\n\nUnique Backend IP and Port Combinations\n---------------------------------------\n\n\nYou can increase TPS by increasing the number of unique target backend IP and port combinations. The same NAT IP and source port can be used for each of the target backend IPs and ports. This achieves the same result as adding more NAT IPs without requiring additional IPs that must be allow-listed.\n\n\nTo create a unique target backend IP and port pair, the IP *or*the port must be different. For example, it is possible to have a single load balancer with one IP address, but listening on 4 different ports, to make 4 unique backend IP and port combinations for Apigee.\n| **Note**: If the backend is a Network Load Balancer (NLB) at another Cloud Provider, make sure it supports concurrent usage of the same NAT IP and source port against multiple IP addresses of that NLB. You might need to disable features like \"cross-zone load balancing\" or \"client IP address preservation\" to make it work. Otherwise, you might encounter variety of connectivity errors related to connection reuse. Please reach out to the relevant Cloud Provider for assistance.\n\nConnection Reuse\n----------------\n\nReusing HTTP connections also increases the efficient use of NAT by removing the\nneed to open a new TCP connection. Target backends can use this feature by setting the\n**`Connection`** header to**`keep-alive`** in the response,\nwhich is the default setting for HTTP/1.1. The target backend server can also set `connection timeout`\nand `max reuse` parameters to improve efficiency.\n\nWhile connection reuse can theoretically be supported by enabling **`keep-alive`**\nin the response, in practice, connection reuse depends on the following:\n\n- If the Apigee instance has an existing connection to the target backend\n- If the existing connection has pending responses\n- If the existing connection is near the end of its lifecycle\n\nEach of these factors will affect the extent to which the target backend can reuse connections."]]
