Azure Container Instances에 대한 질문과 대답

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

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

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

캐시된 이미지 목록 API를 통해 사용할 수 있는 Azure Container Images의 미리 캐시된 이미지 목록을 검사 합니다. 미리 캐시된 이미지 중 하나에 대한 이미지 계층을 전환할 수 있습니다.

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

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

• Nano 서버: 1809이상 10.0.17763.1040
• Windows Server Core: ltsc2019또는 180910.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와 같은 다른 타사 컨테이너 레지스트리에서 이미지 끌어오기를 지원합니다. ACI는 인터넷에 공개적으로 노출되는 엔드포인트를 사용하여 ACR 및 DockerHub와 같은 다른 타사 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 리소스를 통해 VNet 내에서 트래픽을 라우팅할 수 있습니다. Azure Container Instances의 네트워킹 시나리오 및 제한 사항은 가상 네트워크 시나리오 및 리소스를 참조 하세요.

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

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

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

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

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

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

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

GPU 기반 ACI 컨테이너 배포, Windows 컨테이너, 가용성 영역 및 전용 인스턴스는 기밀 컨테이너에서 지원되지 않습니다.

Azure Container Instances의 기밀 컨테이너는 공개 미리 보기 동안 일부 지역에서만 사용할 수 있습니다. 현재 지역 가용성은 여기에 게시되어 있습니다.

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

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

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

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

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

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

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

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

다음 단계

• Azure Container Instances에 대해 자세히 알아봅니다.
• Azure Container Instances의 일반적인 문제 해결