5. Azure Container Instances 구성

컨테이너와 가상머신 비교

하드웨어 가상화 << 하나의 물리 하드웨어에서 격리된 여러 운영체제 동시 실행 가능. 컨테이너 기반 가상화로 OS 가상화 가능. 이걸로 앱 사이 격리 유지하며 동일한 인스턴스 내 여러 앱 실행 가능. VM 내 컨테이너는 물리적 서버 VM과 유사한 기능 제공.

컨테이너와 VM에 대해 알아야 할 사항

비교해보쟈

비고	컨테이너	가상머신
격리	- 호스트, 기타 컨테이너로부터 격리 - 강력한 보안 경계 X	- 호스트 OS, VM으로부터 완벽한 격리 - 보안 경계 중요한 경우 유용
OS	- OS 사용자 모드 부분 실행 → 필요한 서비스만 포함하게 조정 가능 - 사용되는 시스템 리소스 줄이는데 유용	- (커널 등의) OS 전체 실행 - 더 많은 시스템 리소스(CPU, MEM 등) 필요
배포	- CLI를 통해 Docker로 개별 컨테이너 배포 - Azure k8s Service 등의 오케스트레이터로 여러 컨테이너 배포 가능	- Windows Admin Center, Hyper-V 등 관리자로 개별 VM 배포 가능 - PowerShell, System Center VM Manager로 여러 VM 배포 가능
영구 스토리지	- (단일 노드에서) 로컬 스토리지용 Azure 디스크 사용 - (여러 노드 || 서버 공유 스토리지에서) Azure Files(SMB 공유) 사용	- (단일 VM)VHD 사용 - (여러 서버 공유 스토리지) SMB 사용
내결함성	- 오류 발생 시, 다른 클러스터 노드의 오케스트레이터가, 모든 컨테이너를 다시 만듦	- 다른 서버에 대해 failover(장애 조치) 가능 - OS는 새로운 서버에서 재시작

컨테이너 사용 시 고려사항

• 유연성, 속도 고려
  • 컨테이너화 된 앱 코드 개발
  • 공유 시 유연성 + 속도 증가
• 테스트 고려
  • 앱 테스트 간소화
• 앱 배포 고려
  • 배포 간소화, 가속화
• 워크로드 밀도 고려
  • 더 높은 워크로드 밀도 지원
  • 리소스 사용률 개선

Azure Container Instances 검토

Container << 클라우드 앱 패키징, 배포, 관리를 위한 기본 방법으로 도입중임. Azure에서 (클라우드 원시 앱 && 컨테이너화 된 앱) 빌드, 배포 가능한 다양한 옵션 있음. 이 중 ACI(Azure Container Instances) 살펴보자.

Azure Container Instances << (VM 관리 없이 + 높은 수준 서비스 채택 없이) 컨테이너 실행 격리된 컨테이너에서 작동 가능한 모든 시나리오를 위해 좋단다.. 아래 그림을 참고해보자. ACI를 사용해 VNet의 VM에서 컨테이너 실행중인 웹 서버임.

컨테이너 이미지 이해

모든 컨테이너는 이미지에서 만들어짐. 이미지? << 앱 실행에 필요한 모든 것 캡슐화 함. 가볍고 독립적이고 실행 가능한 소프트웨어 패키지임. 이미지에 포함되는 것들은 다음과 같음.

• 코드: 앱의 코드
• 런타임: 앱 실행에 필요한 환경
• 시스템 도구: 앱 작동에 필요한 유틸리티
• 시스템 라이브러리: 앱에서 쓰는 공유 라이브러리
• 설정: 앱 관련 매개변수

이미지 생성하면 다양한 환경에서 일관적인 실행이 가능함. 이미지의 인스턴스인 컨테이너의 중요한 구성 요소임.

ACI에 대해 알아야 할 사항

• 빠른 시작 시간
  • VM 프로비저닝, 관리 필요 없이 몇 초 안에 시작 가능
• Public IP 연결 && DNS 이름
  • IP Addr, FQDN(정규화된 도메인 이름)으로 직접 노출될 수 있음
• 사용자 지정 크기
  • 컨테이너 노드 동적 스케일링 가능
• 영구 스토리지
  • Azure Files 파일 공유의 직접 탑재 지원
• Linux, Windows 컨테이너
  • 두 컨테이너 모두 예약 가능
  • 컨테이너 그룹 생성 시 OS 유형 지정해야 함
• 공동 예약된 그룹
  • 호스트 머신 리소스 공유하는 다중 컨테이너 그룹 예약 지원함
• VNet 배포
  • Azure VNet에 컨테이너 인스턴스 배포 가능

컨테이너 그룹 구현

ACI 최상위 리소스 << 컨테이너 그룹 동일한 호스트 PC에서 예약되는 컨테이너의 컬렉션임. 그룹 내 컨테이너들은 수명 주기, 리소스, 로컬 스토리지 볼륨을 공유함.

컨테이너 그룹에 대해 알아야 할 사항

• K8S Pod와 유사함.
  • Pod는 일반적으로 컨테이너와 1:1 매핑됨
  • 하지만 Pod는 여러 컨테이너 포함될 수 있음
  • 다중 컨테이너 Pod에 포함된 여러 컨테이너는 관련 리소스 공유 가능
• ACI << 그룹 내 모든 컨테이너 리소스 요청 함께 추가, 리소스를 다중 컨테이너 그룹에 할당
  • 리소스 << CPU, MEM, GPU 등 포함
  • 예시로 각각 CPU 리소스가 필요한 컨테이너 두 개 있는 그룹 생각해보자..
    • 각 컨테이너는 CPU 하나 요청함
    • 그러면 리소스를 공유한댔으니까.. ACI는 해당 그룹에 CPU 두 개를 할당함
• 다중 컨테이너 그룹 배포 방법
  • ARM(Azure Resource manager) Template
    • (Azure Files 파일 공유 등의) 컨테이너 인스턴스 배포 시, 다른 Azure 서비스 리소스 배포하는데 권장됨.
  • YAML
    • YAML 파일이 더 간결함
    • 따라서, 배포에 컨테이너 인스턴스만 포함됐다면 YAML 파일 쓰는게 더 좋음
• 외부 연결 IP Addr, 해당 IP’s 1개 이상 port, FQDN이 포함된 DNS 레이블 공유 가능
  • 외부 클라이언트 액세스
    • 외무에서 그룹의 컨테이너에 연결하려면 IP Addr 공유 + 컨테이너에서 포트 노출해야 함
  • 포트 매핑
    • 그룹의 컨테이너는 포트 네임스페이스 공유함 → 포트 매핑 지원되지 않음
  • 삭제된 그룹
    • 컨테이너 그룹 삭제되면 IP Addr, FQDN 해제됨

구성 예시

• 단일 호스트 컴퓨터에서 예약되며 DNS 이름 레이블 할당됨
• 하나의 노출된 포트로 단일 Public IP Addr 노출함
• 그룹 내 한 컨테이너가 80번 포트에서 수신 대기
  • 나머지는 1433 포트에서 수신 대기
• 위 예시에서, Azure Files 파일 공유 두 개가 볼륨 탑재로 포함됨.
  • 그룹 내 각 컨테이너는 파일 공유 중 하나를 로컬로 탑재

컨테이너 그룹을 사용할 때 고려해야 할 사항

다중 컨테이너 그룹 << 단일 기능 작업을 여러 개(의 이미지)로 분할하려 할 때 유용함. 여러 팀이 이미지를 제공하거나… 이미지마다 리소스 요구사항 달라질 수 있음.

• 웹앱 업데이트 고려
  • 그룹 내 하나의 컨테이너가 웹 앱 제공
  • 다른 컨테이너는 소스 제어에서 최신 컨텐츠 pull
• 로그 데이터 수집 고려
  • 앱에 대한 로깅, 메트릭 데이터 캡쳐
  • 앱 컨테이너가 로그, 메트릭 출력
  • 로깅 컨테이너가 출력 데이터 수집, 장기 스토리지에 데이터 씀
• 앱 모니터링 고려
  • 모니터링 컨테이너 << 앱 상태 확인을 위해 컨테이너에 주기적으로 요청 보냄
  • 문제 식별 시 경고 발생
• FE, BE 지원 고려
  • FE 컨테이너, BE 컨테이너 보관할 다중 컨테이너 그룹 생성
  • FE 컨테이너는 웹 앱 제공
  • BE 컨테이너는 데이터 검색하는 서비스 실행 가능 (데이터 검색은 예시임)

Azure Container Apps 검토

Azure Container Apps에 대해 알아야 할 사항

Azure Container Apps << 컨테이너화 된 앱 실행, 인프라 덜 유지, 비용 절감. 안정적, 안전한 앱 유지에 필요한 최신 서버 리소스 제공.

Azure Container Apps 일반적인 용도

• API 엔드포인트 배포
• 후순위 처리 작업 호스팅
• 이벤트 기반 처리 수행
• 마이크로서비스 실행

Azure Container Apps에 빌드된 앱의 동적 확장

동적 확장을 가능하게 하는 특성들임

• HTTP 트래픽
• 이벤트 기반 처리
• CPU || MEM 로드
• 모든 KEDA 지원 스케일러

Azure Container Apps 고려해야 할 사항

= Container App의 고유 기능들임

• 범용 컨테이너 실행에 최적화
  • (많은 컨테이너가 배포된) 마이크로 서비스 앱에 특화
• K8s, Dapr, KEDA, envoy 등 오픈소스 기술로 제공됨
• 서비스검색, 트래픽분할 >> K8S 스타일 앱, 마이크로 서비스 지원
• 트래픽에 따라 크기 비율 조정 지원
  • 크기 비율 조정에 0 포함
  • 큐 등의 이벤트 원본에서 이벤트 기반 앱 아키텍처 사용하게 설정함
• 요청 시 예약된 작업 || 이벤트 기반 작업 실행 지원

Azure Container Apps << 기본 K8S API 직접 액세스 제공 X. (K8S 스타일 앱 빌드), (모든 네이티브 K8S API, 클러스터) 관리에 직접 접근할 필요 없다면? Container Apps가 전부 관리 해 줄거임. 그래서 Azure Container Apps로 마이크로서비스 빌드 많이 시작함.

컨테이너 관리 솔루션 비교

ACI << 여러 방법으로 관리 가능. 그 중 ACA(Azure Conainer Apps) 또한 한 가지 방법임. AKS(Azure K8S Service)는 또 다른 방법임. 이 둘을 비교해보자.

기능	ACA	AKS
개요	기본 인프라 추상화, 마이크로서비스 기반 앱의 배포, 관리 간소화. 서버리스 플랫폼.	운영 오버헤드를 Azure로 오프로드. → 관리형 K8S 클러스터 배포 간소화. 오케스트레이션 필요한 복잡한 앱에 적합.
배포	빠른 배포, 관리 제공하는 PaaS 환경 제공.	K8S 환경에 대한 더 많은 제어, 사용자 지정 옵션 제공.
관리	AKS 기반, 간소화된 PaaS 환경 제공.	K8S 환경에 대한 세부 제어 제공.
확장성	HTTP 기반 자동 크기 조정, 이벤트 기반 크기 조정 지원 → 수요 변화에 신속 대응 필요한 앱에 적합.	수평 Pod 자동 크기 조정, 클러스터 자동 크기 조정 제공 → 강력한 확장성, 옵션 제공.
사용 사례	빠른 크기 조정, 간소화된 관리 활용하는 마이크로서비스, 서버리스 앱	복잡하고 장기적으로 실행되는 앱에 적합. K8S와 Azure 서비스의 긴밀한 통합 필요.
통합	(이벤트 기반 아키텍처 위해)Azure Logic Apps, Functions, Event Grid	(포괄적 보안, 거버넌스를 위해) Azure Policy, (컨테이너용) Azure Monitor, (K8S용) Azure Defender