Azure Container Apps의 컨테이너 앱 간 통신

Azure Container Apps 컨테이너 앱이 인프라를 관리하지 않고 서로 통신할 수 있도록 기본 제공 서비스 검색 및 라우팅을 제공합니다. 동일한 환경에 여러 컨테이너 앱을 배포하는 경우 플랫폼은 DNS 확인, 부하 분산 및 보안 트래픽 라우팅을 자동으로 처리합니다.

인그레스가 사용 설정된 경우 각 컨테이너 앱은 도메인 이름을 가져옵니다. 해당 엔드포인트를 공개적으로 사용 가능하게 만들거나 동일한 환경의 다른 컨테이너 앱으로 제한할 수 있습니다.

컨테이너 앱은 다음 방법 중 어느 것을 통해 서로 연결할 수 있습니다.

  • FQDN(정규화된 도메인 이름): 기본 생성된 도메인
  • 앱 이름: 내부 호출에 대한 짧은 양식 http://<APP_NAME> 주소
  • Dapr 서비스 호출: 기본 제공되는 재시도 기능과 관측성을 갖춘 사이드카 기반의 방식
  • 사용자 지정 도메인: 관리되는 인증서가 있는 사용자 고유의 도메인 이름

참고

FQDN 또는 앱 이름을 사용하여 동일한 환경에서 다른 컨테이너 앱을 호출하는 경우 네트워크 트래픽이 환경을 벗어나지 않습니다.

중요한 이유

마이크로 서비스 아키텍처에서 서비스는 서로를 안정적으로 호출해야 합니다. Azure Container Apps 서비스 검색 설정, DNS 레코드 관리 및 역방향 프록시 구성의 운영 부담을 제거합니다.

플랫폼이 자동으로 처리하는 항목은 다음과 같습니다.

  • 자동 DNS 등록: 모든 컨테이너 앱은 배포되는 즉시 확인 가능한 호스트 이름을 가져옵니다.
  • 프록시 관리 라우팅: 모든 앱 간 트래픽은 TLS 종료, 트래픽 분할 및 부하 분산을 처리하는 기본 제공 Envoy 프록시 계층을 통해 흐릅니다.
  • 환경 범위 격리: 내부 엔드포인트는 동일한 환경 내에서만 연결할 수 있으므로 자연 보안 경계가 생성됩니다.
  • 프로토콜 유연성: 워크로드 요구 사항에 따라 HTTP/1.1, HTTP/2(gRPC용) 또는 원시 TCP를 통한 통신

이러한 기능은 네트워킹 배관보다는 애플리케이션 논리에 집중할 수 있습니다.

컨테이너 앱 위치(FQDN)

각 컨테이너 앱의 정규화된 도메인 이름은 앱 이름, 고유한 환경 식별자 및 지역으로 구성됩니다. 이러한 도메인 조각은 모두 최상위 도메인에 azurecontainerapps.io 속합니다.

Azure Container Apps 컨테이너 앱의 정규화된 도메인 이름.

외부 및 내부 FQDN 정보

"인그레스 가시성 설정은 환경 외부에서 앱에 접근할 수 있는지를 제어합니다."

가시성 FQDN 패턴 다음 위치에서 연결할 수 있습니다.
External <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io 어디서나(공용 인터넷)
내부 <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io 동일한 환경만

수신 설정을 내부로 지정할 경우, FQDN에.internal. 세그먼트가 자동으로 포함됩니다. 동일한 환경의 다른 컨테이너 앱은 이 주소를 사용하여 앱에 연결할 수 있지만 환경 외부의 요청은 환경의 프록시로부터 응답을 받 404 습니다. DNS 이름은 환경의 공유 IP로 확인되지만 앱이 내부 전용이므로 프록시가 요청을 거부합니다.

정규화된 도메인 이름 가져오기

az containerapp show 명령은 컨테이너 앱의 정규화된 도메인 이름을 반환합니다.

az containerapp show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <CONTAINER_APP_NAME> \
  --query properties.configuration.ingress.fqdn

이 예제에서는 <>로 둘러싸인 자리 표시자를 값으로 바꿉니다.

이 명령에서 반환되는 값은 다음 예제와 같은 도메인 이름과 유사합니다.

myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io

리비전 레이블 FQDN

특정 수정 버전에 레이블을 할당하면 각 레이블은 삼중 대시 구분 기호를 사용하여 고유한 FQDN을 가져옵니다.

<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

내부 앱의 경우, 패턴에 .internal. 세그먼트(구간)가 포함됩니다.

<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

레이블 FQDN을 사용하면 특정 수정 버전으로 트래픽을 직접 보낼 수 있습니다. 이 방법은 새 버전을 테스트하거나, A/B 실험을 실행하거나, 특정 수정 버전 배포에 안정적인 엔드포인트를 제공하는 데 유용합니다.

이름으로 컨테이너 앱 호출

동일한 환경 내에서 다른 컨테이너 앱을 호출하는 가장 간단한 방법은 이름입니다. 요청을 http://<CONTAINER_APP_NAME>보내면 환경의 기본 제공 DNS가 이름을 자동으로 확인합니다.

http://my-backend-api

DNS 확인 작동 방식

백그라운드에서 Azure Container Apps 컨테이너 앱 이름을 라우팅 가능한 주소로 변환하는 사용자 지정 DNS 구성을 사용합니다. 앱이 다른 앱의 이름 또는 FQDN을 요청하는 경우:

  1. 환경의 DNS 서버는 호스트 이름을 Envoy 프록시 서비스 주소로 확인합니다.
  2. Envoy 프록시는 원래 호스트 이름에서 대상 앱을 식별합니다.
  3. 프록시는 트래픽 구성에 따라 요청을 올바른 수정 버전으로 라우팅합니다.

이 아키텍처는 컨테이너 앱이 서로의 Pod와 직접 통신하지 않음을 의미합니다. 모든 트래픽은 TLS 종료, 부하 분산 및 트래픽 분할을 제공하는 프록시 계층을 통과합니다.

팁 (조언)

동일한 환경에서 컨테이너 앱 간의 호출에 짧은 앱 이름(http://<APP_NAME>)을 사용합니다. 전체 FQDN보다 간단하며 DNS가 동일한 프록시를 통해 두 패턴을 모두 해결하기 때문에 동일한 방식으로 작동합니다.

전송 프로토콜

Azure Container Apps는 수신을 위한 세 가지 전송 모드를 지원하며, 이를transport 속성을 통해 구성할 수 있습니다.

Transport 사용 사례 세부 정보
자동 (기본값) 표준 웹 API 및 서비스 자동으로 HTTP/1.1 및 HTTP/2 협상
HTTP/2 gRPC 서비스 gRPC에 필요한 HTTP/2 엔드 투 엔드를 사용하도록 설정
TCP 비 HTTP 프로토콜(데이터베이스, 사용자 지정 프로토콜) 포트 매핑을 사용하는 원시 TCP 연결

참고

외부 TCP 수신에는 사용자 지정 VNet이 필요합니다. 사용자 지정 VNet 없이 외부 TCP 앱을 만들려고 하면 오류가 발생합니다 ContainerAppTcpRequiresVnet . 내부 TCP 수신은 사용자 지정 VNet 없이 작동합니다.

TCP 전송을 사용하는 경우 기본 수신 포트 이외의 추가 포트를 노출할 수도 있습니다. 각 추가 포트는 환경의 다른 앱이 연결할 수 있는 별도의 TCP 엔드포인트를 만듭니다.

트래픽 분할 및 수정 라우팅

Azure Container Apps 컨테이너 앱 간에 트래픽이 분산되는 방식에 영향을 주는 세 가지 수정 모드를 지원합니다.

모드 작동 방식
Single 모든 트래픽은 최신 활성 수정 버전으로 이동합니다.
복수 트래픽은 트래픽 규칙에 따라 수정 버전 간에 백분율로 분할됩니다.
레이블 레이블이 지정된 각 수정 버전은 직접 액세스를 위한 고유한 FQDN을 가져옵니다.

여러 모드에서 다른 컨테이너 앱이 앱의 FQDN을 호출할 때 프록시는 구성된 가중치에 따라 수정 버전 간에 요청을 자동으로 분산합니다. 레이블 모드에서 호출자는 레이블FQDN을 사용하여 특정 수정 버전을 대상으로 지정할 수 있습니다.

자세한 내용은 Azure Container Apps의 개정 사항을 참조하세요.

Dapr 서비스 호출

Dapr (분산 애플리케이션 런타임)은 앱 간 통신에 대한 사이드카 기반 접근 방식을 제공합니다. Dapr을 사용하도록 설정하면 컨테이너 앱은 상호 TLS를 사용하여 기본 제공 서비스 호출, 자동 재시도 및 Azure Application Insights를 통한 분산 추적을 얻습니다.

Dapr을 사용하는 Azure Container Apps 컨테이너 앱 위치를 보여주는 다이어그램입니다.

Dapr 호출의 작동 방식

각 Dapr 지원 컨테이너 앱은 애플리케이션과 함께 사이드카 프로세스를 실행합니다. 다른 Dapr 지원 앱을 호출하려면 서비스 검색 및 라우팅을 처리하는 Dapr 사이드카에 로컬 HTTP 요청을 수행합니다.

http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>

예를 들어, Dapr 앱 ID catalog가 있는 앱에서 order-processor 메서드를 호출하려면:

http://localhost:3500/v1.0/invoke/order-processor/method/catalog

사이드카는 전용 DNS 도메인을 통해 대상 앱을 확인하고 Envoy 프록시 계층을 통해 요청을 라우팅합니다. FQDN 기반 라우팅을 처리하는 동일한 인프라입니다.

참고

Dapr은 표준 FQDN 확인과 별도로 자체 DNS 확인 경로( .dapr 도메인)를 사용합니다. 두 경로 모두 환경의 프록시 인프라를 통해 라우팅됩니다.

Dapr 앱 ID

Dapr 앱 ID는 다른 앱이 서비스를 호출하는 데 사용하는 ID입니다. 명시적 앱 ID를 설정하지 않으면 Dapr 런타임은 기본적으로 컨테이너 앱 이름으로 설정됩니다. ARM API는 사용자 지정 ID를 구성하지 않을 경우 appId: null가 표시되며, 런타임은 앱 이름을 자동으로 적용합니다. 다른 식별자가 필요한 경우 Dapr 구성에서 사용자 지정 앱 ID를 설정합니다.

Dapr 앱 ID는 환경 내에서 고유해야 합니다. 다른 앱에서 이미 사용 중인 Dapr 앱 ID를 사용하여 컨테이너 앱을 배포하려고 하면 컨테이너 앱 리소스가 만들어지지만 수정 버전이 프로비전되지 않습니다(provisioningState: Failed). 오류 메시지는 충돌하는 앱 ID와 해당 ID를 소유한 앱을 식별합니다.

Dapr 전용 앱(HTTP 수신 없음)

HTTP 수신을 구성하지 않고 컨테이너 앱에서 Dapr을 사용하도록 설정할 수 있습니다. 이 경우 앱은 FQDN 또는 앱 이름을 통해 연결할 수 없지만 다른 Dapr 지원 앱은 여전히 Dapr 서비스 호출을 통해 호출할 수 있습니다. 이 패턴은 메시의 다른 서비스에서만 호출을 수신해야 하는 백그라운드 작업자 또는 이벤트 프로세서에 유용합니다.

팁 (조언)

Azure CLI를 사용하여 인그레스 없는 애플리케이션을 만들 때는 --ingress 및 --target-port 플래그를 모두 생략합니다. --target-port가 --ingress 없이 포함되면 사용 오류를 반환합니다.

Dapr 사이드카 구성

컨테이너 앱의 속성을 통해 Dapr 사이드카를 구성합니다. 주요 설정은 다음과 같습니다.

설정 설명
appId Dapr 앱 ID(기본값은 컨테이너 앱 이름)
appPort 앱이 수신 대기할 포트(기본적으로 수신 대상 포트로 대체됨)
appProtocol Dapr-to-app 통신을 위한 프로토콜(예: http, grpc)
logLevel Dapr 사이드카의 로그 출력 상세 수준 정보
enableApiLogging Dapr API 호출을 기록할지 여부
httpMaxRequestSize Dapr의 HTTP 서버에 대한 최대 요청 본문 크기(MB)
httpReadBufferSize HTTP 읽기 버퍼의 최대 크기(KB)

Azure Container Apps와 함께 Dapr을 구성하는 방법에 대한 자세한 내용은 Azure Container Apps와 Dapr 통합을 참조하세요.

앱 간 통신을 위한 보안

Azure Container Apps 컨테이너 앱이 통신하는 방식에 영향을 주는 몇 가지 보안 기능을 포함합니다.

  • 기본적으로 TLS: 컨테이너 앱 간의 모든 트래픽은 TLS 종료를 처리하는 Envoy 프록시를 통해 라우팅됩니다. allowInsecure을 false(기본값)으로 설정하여 HTTPS 리디렉션을 적용합니다.
  • 클라이언트 인증서 모드 (mTLS): 클라이언트 인증서 모드를 require, accept, 또는 ignore로 설정하여 상호 TLS를 구성합니다.
  • IP 제한: 앱에 연결할 수 있는 IP 주소를 제한하는 허용 또는 거부 규칙을 정의합니다.
  • CORS 정책: 컨테이너 앱을 호출하는 브라우저 기반 클라이언트에 대한 원본 간 리소스 공유 규칙을 구성합니다.

참고

Dapr 서비스 호출을 사용하는 경우 Dapr 사이드카가 서비스 간 상호 TLS와의 통신을 자동으로 보호합니다. Dapr-to-Dapr 호출에 대해 mTLS를 별도로 구성할 필요가 없습니다.

자세한 내용은 Azure Container Apps의 Ingress를 참조하세요.

사용자 지정 도메인

인그레스 설정에서 사용자 지정 도메인을 구성하여 자신의 도메인 이름을 컨테이너 앱에 매핑할 수 있습니다. 각 사용자 지정 도메인은 관리 또는 업로드된 TLS 인증서를 참조할 수 있습니다.

사용자 지정 도메인은 기본 FQDN과 함께 등록되므로 앱이 두 주소에 모두 응답합니다. 환경의 다른 컨테이너 앱이 앱에 도달해야 하는 경우 기본 FQDN, 앱 이름 또는 사용자 지정 도메인을 사용할 수 있습니다.

자세한 내용은 Azure Container Apps의 사용자 지정 도메인을 참조하세요.

샘플 솔루션

FQDN과 Dapr을 둘 다 사용하여 컨테이너 간에 호출하는 방법을 보여 주는 샘플은 Azure 샘플 사용할 수 있습니다.

Azure Container Apps 앱 간 통신을 이해하면 다음과 같은 여러 관련 항목에 연결됩니다.

  • Azure Container Apps 환경: 컨테이너 앱들이 서로 발견하고 소통하는 공용 경계 영역
  • Azure Container Apps의 Ingress: 외부 및 내부 엔드포인트, TLS 및 라우팅 규칙을 구성하는 방법
  • Dapr과 Azure Container Apps 통합: Dapr 구성 요소, pub/sub, 상태 관리 및 서비스 호출에 대한 심층적인 설명
  • Azure Container Apps에서의 네트워킹: 환경에 대한 VNet 통합, 프라이빗 엔드포인트 및 네트워크 보안
  • Azure Container Apps의 수정: 개정 모드 및 트래픽 분할이 앱 간 라우팅에 미치는 영향

다음 단계:

컨테이너 앱의 인그레스 구성

  • Last updated on