Azure Container Instances에 대한 질문과 대답

Azure Container Instances에서 배포 가능한 컨테이너 이미지의 최대 크기는 15GB입니다. 배포 시점의 정확한 가용성에 따라 더 큰 이미지를 배포할 수 있지만 더 큰 이미지 크기가 보장되지는 않습니다.

컨테이너 이미지의 크기는 배포하는 데 걸리는 시간에 영향을 주므로 일반적으로는 컨테이너 이미지를 최대한 작게 유지합니다.

배포 시간의 주요 결정 요소 중 하나는 이미지 크기이므로 크기를 줄이는 방법을 찾아보세요. 필요하지 않은 레이어를 제거하거나 더 가벼운 기본 OS 이미지를 선택하여 이미지의 레이어 크기를 줄입니다. 예를 들어 Linux 컨테이너를 실행하는 경우 전체 Ubuntu 서버가 아닌 기본 이미지로 Alpine을 사용하는 것을 고려합니다. 마찬가지로 Windows 컨테이너의 경우 가능하면 Nano Server 기본 이미지를 사용합니다.

또한 캐시된 이미지 나열 API를 통해 사용할 수 있는 Azure Container Images에서 미리 캐시된 이미지 목록을 확인해야 합니다. 미리 캐시된 이미지 중 하나에 대한 이미지 레이어를 전환할 수 있습니다.

컨테이너 시작 시간을 줄이는 방법에 대한 자세한 지침을 참조하세요.

• Nano Server: sac2016, 10.0.14393.3568 이상
• Windows Server Core: ltsc2016, 10.0.14393.3568 이상

• Nano Server: 1809, 10.0.17763.1040 이상
• Windows Server Core: ltsc2019, 1809, 10.0.17763.1040 이상
• Windows: 1809, 10.0.17763.1040 이상

요구 사항에 맞는 가장 작은 이미지를 사용합니다. Linux의 경우 .NET Core 2.1의 릴리스 이후 지원된 런타임 알파인 .NET Core 이미지를 사용할 수 있습니다. Windows의 경우 전체 .NET Framework를 사용한다면 Windows Server Core 이미지(4.7.2-windowsservercore-ltsc2016와 같은 런타임 전용 이미지)를 사용해야 합니다. 런타임 전용 이미지는 작지만 .NET SDK가 필요한 워크로드를 지원하지 않습니다.

ACI는 ACR 및 DockerHub와 같은 Microsoft가 아닌 다른 컨테이너 레지스트리에서 이미지 끌어오기를 지원합니다. ACI는 인터넷에 공개적으로 노출된 엔드포인트를 사용하여 ACR 및 DockerHub와 같은 Microsoft OCI와 호환되지 않는 기타 컨테이너 레지스트리에서 이미지 끌어오기를 지원합니다.

1. 현재 사용 중인 Windows 기본 이미지를 식별합니다.

   MCR(Microsoft Container Registry)에서 직접 끌어온 경우에도 해당 이미지 이름은 기본 이미지입니다.

   프라이빗 레지스트리로 작업하는 경우 Dockerfile을 확인하여 기본 이미지를 식별해야 합니다. 이 이미지는 ‘FROM’ 줄 다음에 명시됩니다.

2. Windows Server 2019에서 사용할 새 기본 이미지를 선택합니다. 다음 예에서는 Azure Container Instances에서 일반적으로 사용되는 Windows Server 2016 이미지와 대체 Windows Server 2019 이미지에 대한 권장 사항을 보여 줍니다.

   Windows Server 2016 이미지	권장되는 Windows Server 2019 이미지
   mcr.microsoft.com/windows/servercore/iis	mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
   mcr.microsoft.com/windows/servercore:ltsc2016	mcr.microsoft.com/windows/servercore:ltsc2019

   자세히 알아보려면 이미지 검색에 대해 참조하세요.

   참고 항목

   새로운 기본 이미지를 선택하는 데 도움이 필요하면 Azure 지원 티켓을 만듭니다.

3. Azure Container Instances 방법 가이드의 컨테이너 업데이트에 따라 새 기본 이미지를 사용하도록 ACI 컨테이너 그룹을 업데이트합니다.

   컨테이너 레지스트리에 MCR을 사용하는 경우 MCR 이미지 이름을 컨테이너 그룹 이미지 매개 변수에 직접 전달할 수 있습니다.

   프라이빗 컨테이너 레지스트리를 사용하는 경우 컨테이너를 Windows 운영 체제의 새 버전으로 업그레이드하는 단계를 수행합니다. 컨테이너 그룹의 이미지 레지스트리 매개 변수를 변경한 경우 업데이트되었는지 확인합니다.

이는 작업에 따라 크게 달라집니다. 소규모 및 테스트 성능을 시작하여 컨테이너의 성능을 확인하세요. CPU 및 메모리 리소스 사용량을 모니터링한 다음, 컨테이너에 배포하는 프로세스 종류에 따라 코어 또는 메모리를 추가합니다.

또한 CPU 코어의 상한 및 컨테이너 그룹당 사용 가능한 메모리에 대해 배포하는 지역의 리소스 가용성을 확인해야 합니다.

Azure Container Instances는 서버리스 주문형 컨테이너 서비스를 목표로 하므로 사용자는 인프라에 대한 걱정 없이 컨테이너 개발에 집중할 수 있습니다. 관심이 있거나 성능 비교를 원하는 사용자를 위해 ACI는 주로 F 및 D 시리즈의 다양한 SKU의 Azure VM 집합에서 실행됩니다. 이는 서비스를 지속적으로 개발하고 최적화하기 위해 향후 변경될 예정입니다.

예(경우에 따라). 현재 할당량에 대한 할당량 및 제한 문서와 요청에 따라 증가할 수 있는 제한을 참조하세요.

아직 아닙니다. 현재 이러한 값은 컨테이너 그룹의 최댓값입니다. 특정 요구 사항 또는 요청에 있는 경우 Azure 지원에 문의하세요.

현재 지역 가용성은 여기에 게시되어 있습니다. 특정 지역에 대한 요구 사항이 있는 경우 Azure 지원에 문의하세요.

현재 크기 조정은 컨테이너 또는 컨테이너 그룹에 사용할 수 없습니다. 더 많은 인스턴스를 실행해야 하는 경우 API를 사용하여 서비스에 대한 컨테이너 그룹 생성을 위한 더 많은 요청을 자동화하고 생성합니다.

선택한 Azure 가상 네트워크에 컨테이너 그룹을 배포하고 컨테이너 그룹에 개인 IP를 위임하여 Azure 리소스 전체의 가상 네트워크 내에서 트래픽을 라우팅할 수 있습니다. 네트워킹 시나리오 및 Azure Container Instances 제한 사항은 가상 네트워크 시나리오 및 리소스를 참조하세요.

예, ACI 서비스는 서비스 기능을 위해 22, 1025-1027, 3389-3399, 9999, 19000, 19080, 19390, 19100, 20000-30000, 49152-65534 포트를 예약합니다. 컨테이너 그룹 정의에서 이러한 포트를 사용하지 않습니다.

컨테이너 그룹 IP 주소는 만들거나 삭제한 후에 변경될 수 있습니다. 애플리케이션 코드는 컨테이너 그룹의 IP 주소에 종속되지 않는 것이 좋습니다. 또한 고정 IP 주소를 유지하려는 경우 NAT Gateway 또는 Application Gateway를 사용하는 것이 좋습니다.

컨테이너 그룹 할당 시간은 첫 번째 컨테이너의 이미지를 풀하기 시작하거나(새 배포의 경우), 컨테이너 그룹이 다시 시작된(이미 배포된 경우) 시간부터 컨테이너 그룹이 중지될 때까지의 시간에서 계산됩니다. Container Instances 가격 책정에서 세부 정보를 참조하세요.

전체 컨테이너 그룹이 중지된 후에는 측정기 실행이 중지됩니다. 컨테이너 그룹의 컨테이너가 실행 중일 때는 컨테이너를 다시 시작하려는 경우를 대비하여 리소스를 보유합니다.

기밀 컴퓨팅은 기밀 컴퓨팅의 채택을 정의 및 가속화하기 위한 기반인 CCC(기밀 컴퓨팅 컨소시엄)에서 정의한 업계 용어입니다. CCC는 하드웨어 기반 TEE(신뢰할 수 있는 실행 환경)에서 계산을 수행하여 사용 중인 데이터 보호로 기밀 컴퓨팅을 정의합니다. ACI 기밀 컨테이너는 하드웨어 기반 보호, 코드 무결성 및 TEE(신뢰할 수 있는 실행 환경)의 확인을 도입합니다. 기밀 컨테이너는 고객이 하드웨어 기반 데이터 보호를 활용하면서 수정 없이 기존 애플리케이션을 배포할 수 있도록 하는 최신 기밀 컴퓨팅 하드웨어를 적용합니다. 코드 무결성 및 TEE 확인은 배포 시 컨테이너 그룹에 연결된 기밀 컴퓨팅 적용 정책의 증명을 통해 수행됩니다. 컨테이너 그룹의 속성 중 하나라도 기밀 컴퓨팅 적용 정책의 속성과 다른 경우 TEE가 손상되지 않도록 환경이 시작되지 않습니다.

기밀 컨테이너는 다양하고 탄력적인 워크로드에 사용할 수 있지만, 특히 강력한 데이터 보호 보장이 필요한 워크로드에 적합합니다. 이러한 워크로드의 몇 가지 예로는 개인 데이터를 포함하는 데이터 세트 또는 지적 재산권으로 간주되는 알고리즘을 활용하는 기계 학습 워크로드가 있습니다. 의료 고객은 이를 환자 데이터 분석 및 연구에 사용할 수 있습니다. 금융 서비스 고객은 신용 분석 위험 계산 및 포트폴리오 분산에 사용할 수 있습니다.

Azure CLI에서 confcom 확장을 사용하여 기밀 컴퓨팅 적용 정책을 생성할 수 있습니다. 자세한 내용은 confcom 확장을 참조하세요.

GPU 기반 ACI 컨테이너 배포 및 Windows 컨테이너는 기밀 컨테이너에서 지원되지 않습니다.

기밀 컨테이너의 현재 지역 가용성은 여기에 게시됩니다.

Azure Container Instances의 기밀 컨테이너는 표준 SKU 컨테이너 그룹에 비해 추가 비용이 발생합니다. 자세한 내용은 가격 책정 페이지를 참조하세요.

ACI 스폿 컨테이너는 고객이 일반 우선 순위 ACI 컨테이너에 비해 최대 70% 할인된 가격으로 사용되지 않는 Azure 용량에서 중단 가능하고 컨테이너화된 워크로드를 실행할 수 있는 새로운 기능입니다.

Azure에 잉여 용량이 부족하고 고객에게 초당 메모리/코어 사용량에 대한 요금이 청구되는 경우 ACI 스폿 컨테이너가 선점될 수 있습니다. ACI 스폿 컨테이너를 사용하면 이제 기존 ACI 가격 책정 비용의 일부로 Azure에서 중단을 허용할 수 있는 일괄 처리, Monte Carlo 시뮬레이션, 개발/테스트 워크로드 및 병렬 처리 가능한 오프라인 워크로드와 같은 컨테이너화된 워크로드를 실행할 수 있습니다. 이 제품은 엄격한 가용성 요구 사항 없이 중단 가능한 워크로드를 실행하려는 고객을 대상으로 합니다.

GPU 기반 ACI 컨테이너 배포, 가용성 영역, 공용 IP를 사용한 ACI 배포 지원 및 개인 IP가 있는 사용자 지정 가상 네트워크 뒤에 있는 ACI 배포는 스폿 컨테이너에서 지원되지 않습니다.

모든 고객은 10개의 vCPU 코어와 10개의 컨테이너 그룹의 기본 할당량을 받습니다.

고객은 요청된 세부 정보를 입력하라는 요청을 받으면 문제 유형을 "서비스 및 구독 제한(할당량)"으로 선택하고 ACI 스폿 컨테이너 제품에 대해 추가된 "StandardSpotCores"로 새 할당량 유형을 선택하여 스폿 컨테이너의 용량을 늘리기 위한 지원 요청을 제출할 수 있습니다.

ACI(Azure Container Instances) 스폿 컨테이너는 공개 미리 보기 동안 일부 지역에서만 사용할 수 있습니다. 자세한 내용은 리소스 및 지역 가용성을 참조하세요.

ACI 스폿 컨테이너는 할인된 가격으로 제공되며, 일반 우선 순위 ACI 컨테이너에 비해 최대 70% 할인을 제공합니다. 할인은 지역마다 매월 다릅니다. 자세한 내용은 가격 책정 페이지를 참조하십시오.

다음 단계

• Azure Container Instances에 대해 자세히 알아보기
• Azure Container Instances의 일반적인 문제 해결