Azure Container Apps의 Java 개요

Azure Container Apps는 클라우드에서 컨테이너화된 Java 애플리케이션을 실행하는 동시에 애플리케이션 배포 방법에 대한 유연한 옵션을 제공할 수 있습니다.

컨테이너화된 Java 애플리케이션에 Container Apps를 사용하면 다음과 같은 이점을 가져올 수 있습니다.

• 비용 효과적인 크기 조정: 사용량 플랜을 사용하면 Java 앱을 0으로 크기 조정할 수 있습니다. 앱에 대한 수요가 거의 없을 때 규모를 축소하면 프로젝트 비용이 자동으로 절감됩니다.

• 배포 옵션: Azure Container Apps는 Buildpacks와 통합되어 Maven 빌드에서 아티팩트 파일을 통해 또는 자체 Dockerfile을 통해 직접 배포할 수 있습니다.

  • JAR 배포(미리 보기): JAR 파일에서 직접 컨테이너 앱을 배포할 수 있습니다.

  • WAR 배포(미리 보기): WAR 파일에서 직접 컨테이너 앱을 배포할 수 있습니다.

  • IDE 지원: IntelliJ에서 직접 컨테이너 앱을 배포할 수 있습니다.

• 자동 메모리 맞춤(미리 보기): Container Apps는 JVM(Java Virtual Machine)이 메모리를 관리하는 방식을 최적화하여 Java 애플리케이션에서 최대한 많은 메모리를 사용할 수 있도록 합니다.

• 빌드 환경 변수(미리 보기): 사용자 지정 키-값 쌍을 구성하여 소스 코드에서 Java 이미지 빌드를 제어할 수 있습니다.

이 문서에서는 Azure Container Apps에서 Java 애플리케이션을 빌드할 때 알아야 할 정보를 자세히 설명합니다.

배포 형식

컨테이너화된 애플리케이션을 실행한다는 것은 일반적으로 애플리케이션에 대한 Dockerfile을 만들어야 함을 의미하지만, Container Apps에서 Java 애플리케이션을 실행하면 몇 가지 옵션이 제공됩니다.

애플리케이션 종류

다양한 애플리케이션 형식은 개별 Container Apps 또는 Container Apps 작업으로 구현됩니다. 다음 표를 사용하면 시나리오에 가장 적합한 애플리케이션 형식을 결정하는 데 도움이 됩니다.

이 표에 나열된 예는 완전하지는 않지만 이를 통해 다양한 애플리케이션 형식의 의도를 가장 잘 이해할 수 있습니다.

디버깅

Container Apps에서 Java 애플리케이션을 디버깅할 때 Java In Process 에이전트에서 로그 스트림 및 콘솔 디버깅 메시지를 검사해야 합니다.

문제 해결

Java 애플리케이션을 개발할 때 다음 항목을 염두에 둡니다.

• 기본 리소스: 기본적으로 앱에는 CPU의 절반과 1GB를 사용할 수 있습니다.

• 상태 비저장 프로세스: 컨테이너 앱이 크기 조정 및 크기 조정됨에 따라 새 프로세스가 만들어지고 종료됩니다. 데이터베이스 및 파일 시스템 공유와 같은 공유 스토리지에 데이터를 쓸 수 있도록 미리 계획을 세웁니다. 컨테이너 파일 시스템에 직접 작성된 파일을 다른 컨테이너에서 사용할 수 있을 것이라고 기대하지 마세요.

• 0으로 크기 조정이 기본값입니다.: 하나 이상의 애플리케이션 인스턴스가 계속 실행되도록 해야 하는 경우 요구 사항에 가장 적합한 크기 조정 규칙을 정의해야 합니다.

• 예기치 않은 동작: 컨테이너 앱이 빌드, 시작 또는 실행되지 않는 경우 아티팩트 경로가 컨테이너에 올바르게 설정되어 있는지 확인합니다.

• Buildpack 지원 문제: Buildpack이 필요한 종속성이나 Java 버전을 지원하지 않는 경우 자체 Dockerfile을 만들어 앱을 배포합니다. 참조용으로 샘플 Dockerfile을 볼 수 있습니다.

• SIGTERM 및 SIGINT 신호: 기본적으로 JVM은 SIGTERM 및 SIGINT 신호를 처리하고 사용자가 이러한 신호를 가로채 애플리케이션에서 적절하게 처리하지 않는 한 이를 애플리케이션에 전달하지 않습니다. Container Apps는 프로세스 제어를 위해 SIGTERM 및 SIGINT를 모두 사용합니다. 이러한 신호를 캡처하지 않고 애플리케이션이 예기치 않게 종료되는 경우 해당 신호를 스토리지에 유지하지 않으면 해당 신호가 손실될 수 있습니다.

• 컨테이너 이미지에 대한 액세스: 기본 레지스트리와 함께 아티팩트 또는 소스 코드 배포를 사용하는 경우 컨테이너 이미지에 직접 액세스할 수 없습니다.

모니터링

모든 표준 관찰 도구는 Java 애플리케이션에서 작동합니다. Container Apps에서 실행할 Java 애플리케이션을 빌드할 때 다음 항목에 유의해야 합니다.

• 메트릭: JVM(Java Virtual Machine) 메트릭은 Java 애플리케이션의 상태 및 성능을 모니터링하는 데 매우 중요합니다. 수집된 데이터에는 메모리 사용량, 가비지 수집, JVM의 스레드 수에 대한 인사이트가 포함되어 있습니다. 메트릭을 확인하여 애플리케이션의 상태와 안정성을 확인할 수 있습니다.

• 로깅: 로그 스트림에 표시될 수 있도록 애플리케이션 및 오류 메시지를 stdout 또는 stderror에 보냅니다. 널리 사용되는 로깅 서비스를 사용할 때 일반적인 것처럼 컨테이너의 파일 시스템에 직접 로깅하지 마세요.

• 성능 모니터링 구성: 애플리케이션에 직접 액세스할 수 있도록 성능 모니터링 서비스를 Container Apps 환경에 별도의 컨테이너로 배포합니다.

진단

Azure Container Apps는 Java 개발자만을 위한 기본 제품 진단 도구를 제공합니다. 이 지원은 향상된 효율성과 용이성을 위해 Azure Container Apps에서 실행되는 Java 애플리케이션의 디버깅 및 문제 해결을 간소화합니다.

• 동적 로거 수준: 코드를 수정하거나 앱을 다시 시작하지 않고도 다양한 수준의 로그 세부 정보에 액세스하고 확인할 수 있습니다. 참고용으로 동적 로거 수준 설정을 참조하세요.

확장

프런트 엔드 애플리케이션의 요청이 동일한 서버에 도달하는지 확인해야 하거나 프런트 엔드 앱이 여러 컨테이너로 분할되어 있는 경우 고정 세션을 사용하도록 설정해야 합니다.

보안

Container Apps 런타임은 Container Apps 환경 내에서 SSL을 종료합니다.

메모리 관리

Java 애플리케이션에서 메모리 관리를 최적화하려면 앱에서 JVM 메모리 피팅을 사용하도록 설정합니다.

메모리는 Gi(기비바이트) 및 CPU 코어 쌍으로 측정됩니다. 다음 표에서는 컨테이너 앱에서 사용할 수 있는 리소스 범위를 보여 줍니다.

Core는 0.25Core 증분으로 제공되며 메모리는 2:1 비율로 제공됩니다. 예를 들어, 1.25개의 코어가 필요한 경우 컨테이너 앱에 2.5Gi의 메모리를 사용할 수 있습니다.

스프링 구성 요소 지원

Azure Container Apps는 다음 Spring 구성 요소를 관리되는 서비스로 지원합니다.

• Spring용 Eureka Server: 서비스 등록 및 검색은 라이브 애플리케이션 인스턴스 목록을 유지하기 위한 핵심 요구 사항입니다. 애플리케이션은 인바운드 요청을 라우팅하고 부하 분산하기 위해 이 목록을 사용합니다. 각 클라이언트를 수동으로 구성하면 시간이 걸리고 인적 오류가 발생할 가능성이 있습니다. Eureka Server는 마이크로 서비스가 스스로 등록하고 시스템 내에서 다른 서비스를 발견할 수 있는 서비스 레지스트리 역할을 하여 서비스 검색 관리를 간소화합니다.

• Spring용 Config Server: Config Server는 분산 시스템에 대한 중앙 집중식 외부 구성 관리를 제공합니다. 이 구성 요소는 클라우드 기반 환경에서 여러 마이크로 서비스의 구성 설정을 관리하는 문제를 해결하도록 설계되었습니다.

• Spring용 관리자: Spring용 관리자 관리 구성 요소는 Actuator 엔드포인트가 있는 Spring Boot 웹 애플리케이션용으로 설계된 관리 인터페이스를 제공합니다. 관리 구성 요소는 컨테이너 앱을 Spring용 관리자 구성 요소에 바인딩할 수 있도록 하여 컨테이너 앱에 대한 통합 및 관리 기능을 제공합니다.

다음 단계