문제 216
문제:
다음 Azure Resource Manager(ARM) 템플릿을 사용하여 Azure Container Instance를 배포하려고 합니다.
템플릿에 제시된 정보를 바탕으로 각 설명을 완성하는 답변을 드롭다운 메뉴에서 선택하세요.
| 설명 | 선택 사항 |
| 인터넷 사용자들은 | a) 모든 장치에서 컨테이너에 연결할 수 있습니다. |
| b) 컨테이너에 연결할 수 없습니다. | |
| c) Windows에서 실행되는 장치에서만 컨테이너에 연결할 수 있습니다. |
|
| 컨테이너에서 IIS(Internet Information Services)가 실패하면 ( ). |
a) 컨테이너가 자동으로 다시 시작됩니다. |
| b) 컨테이너는 수동으로만 다시 시작할 수 있습니다. | |
| c) 컨테이너는 반드시 다시 배포되어야 합니다. |
정답:
- 인터넷 사용자들은 a) 모든 장치에서 컨테이너에 연결할 수 있습니다. 컨테이너에 연결할 수 있습니다.
- 컨테이너에서 IIS(Internet Information Services)가 실패하면 a) 컨테이너가 자동으로 다시 시작됩니다.
해설:
- 첫 번째 설명: ARM 템플릿에서 OS Type이 "Windows"로 설정되어 있지만, 이는 컨테이너가 실행되는 노드의 운영체제를 정의하는 것입니다. 따라서 컨테이너 자체는 네트워크를 통해 접근할 수 있으며, 운영체제 유형에 관계없이 인터넷을 통해 연결할 수 있습니다. 마이크로소프트는 시험에서 이러한 점을 이용하여 혼란을 줄 수 있으니 주의해야 합니다.
- 두 번째 설명: ARM 템플릿의 restartPolicy가 "OnFailure"로 설정되어 있습니다. 이는 컨테이너 내에서 실행되는 프로세스가 **실패 (종료 코드가 0이 아닌 경우 등)**할 때만 컨테이너가 자동으로 다시 시작된다는 의미입니다. "Always"로 설정하면 항상 재시작되고, "Never"로 설정하면 실패해도 재시작되지 않습니다.
Azure 관련 용어 해설:
- Azure Container Instance (ACI): Azure에서 서버를 관리할 필요 없이 Docker 컨테이너를 실행할 수 있는 서비스입니다. 빠르고 간편하게 컨테이너를 배포하고 실행할 수 있습니다.
- Azure Resource Manager (ARM) 템플릿: Azure 인프라를 코드로 정의하고 배포하기 위한 JSON 형식의 파일입니다. 템플릿을 사용하면 인프라 배포를 자동화하고 일관성을 유지할 수 있습니다.
- Container Group: Azure Container Instance에서 함께 배포되고 동일한 호스트 및 네트워크 리소스를 공유하는 컨테이너의 모음입니다.
- Restart Policy: 컨테이너 그룹 내의 컨테이너가 종료될 때 Azure가 자동으로 다시 시작할지 여부와 시기를 결정하는 설정입니다. "Always", "OnFailure", "Never" 세 가지 옵션이 있습니다.
- OS Type: 컨테이너 그룹을 실행하는 기본 운영 체제(Windows 또는 Linux)를 지정합니다. 컨테이너 이미지 자체의 운영 체제와는 다를 수 있습니다.
문제 217
문제: App1이라는 Azure Web App이 있습니다. App1 에는 다음 표와 같은 배포 슬롯이 있습니다.
스테이징 환경인 web app 1 test에서 App 1 에 대한 여러 변경 사항을 테스트했습니다.
그런 다음 App1 을 백업합니다. web app1 test를 web app 1 prod로 스왑하면 App1에 성능 문제가 발생하는 것을 발견했습니다. 이전 버전의 App1 으로 최대한 빨리 되돌리려면 어떻게 해야 할까요?
| 이름 | 기능 |
| webapp 1 prod | Production |
| webapp 1 test | Staging |
옵션:
- a) App1을 다시 배포합니다.
- b) 슬롯을 스왑합니다.
- c) App1을 복제합니다.
- d) App1의 백업을 복원합니다.
정답: b) 슬롯을 스왑합니다.
해설:
배포 슬롯을 스왑하면 Azure는 소스 슬롯과 대상 슬롯의 가상 IP 주소를 서로 바꿉니다.
즉, 스테이징 환경(web app one test)이 프로덕션 환경(web app one prod)의 IP 주소를 가지게 되고,
이전의 프로덕션 환경은 스테이징 환경의 IP 주소를 가지게 됩니다.
따라서 실제 배포 없이 즉시 이전 버전으로 롤백하는 효과를 얻을 수 있습니다.
이는 비즈니스 중단 없이 변경 사항을 프로덕션 환경에 적용하고 문제가 발생했을 때 빠르게 되돌릴 수 있는 가장 좋은 방법입니다.
Azure 관련 용어 해설:
- Azure Web App: 웹 애플리케이션, RESTful API, 백엔드 프로세스와 같은 웹 기반 콘텐츠를 호스팅하기 위한 PaaS(Platform as a Service) 오퍼링입니다. 서버를 관리할 필요 없이 애플리케이션을 쉽게 배포하고 확장할 수 있습니다.
- 배포 슬롯 (Deployment Slots): Azure App Service의 기능으로, 프로덕션 환경과 별도로 스테이징, 테스트 또는 개발 환경을 만들 수 있도록 합니다. 슬롯 간에 트래픽을 쉽게 전환하거나 (스왑) 이전 상태로 롤백할 수 있습니다.
- 스왑 (Swap): 두 개의 배포 슬롯 간에 애플리케이션 버전을 교환하는 작업입니다. 실제 콘텐츠를 이동하는 대신 가상 IP 주소를 변경하므로 다운타임 없이 빠르게 배포 또는 롤백할 수 있습니다.
- 스테이징 환경 (Staging Environment): 프로덕션 환경에 배포하기 전에 변경 사항을 테스트하는 데 사용되는 환경입니다.
문제 218
문제: 다음 표와 같이 4개의 Azure 가상 머신이 있습니다.
복구 서비스 자격 증명 모음이 VM 1 과 VM 2를 보호하고 있습니다.
이제 동일하거나 다른 복구 서비스 자격 증명 모음을 사용하여 VM 3 과 VM 4를 보호하려고 합니다.
가장 먼저 무엇을 해야 할까요?
| Virtual machine Name | Azure Region |
| VM 1 | 서유럽 |
| VM 2 | 서유럽 |
| VM 3 | 동유럽 |
| VM 4 | 동유럽 |
옵션:
- a) 새 백업 정책 (Backup Policy) 을 만듭니다.
- b) 새 복구 서비스 자격 증명 모음(Recovery Services Vault) 을 만듭니다.
- c) 스토리지 계정을 만듭니다.
- d) VM 3 과 VM 4에 대한 확장(Extensions) 을 구성합니다.
정답: b) 새 복구 서비스 자격 증명 모음을 만듭니다.
해설:
Azure 복구 서비스 자격 증명 모음은 백업 데이터 및 구성 정보를 저장하는 스토리지 엔터티입니다. 가상 머신을 보호하려면 먼저 해당 가상 머신을 연결할 복구 서비스 자격 증명 모음이 있어야 합니다. 문제에서 가상 머신 3과 4는 가상 머신 1과 2와 **다른 Azure 지역 (동유럽)**에 있습니다. 일반적으로 복구 서비스 자격 증명 모음은 특정 Azure 지역에 생성되며, 다른 지역의 리소스를 보호할 수 없습니다. 따라서 가상 머신 3과 4를 보호하려면 해당 지역 (동유럽)에 새로운 복구 서비스 자격 증명 모음을 만들어야 합니다.
Azure 관련 용어 해설:
- Azure 가상 머신 (Virtual Machines): Azure에서 제공하는 IaaS(Infrastructure as a Service) 오퍼링으로, 클라우드에서 사용자 지정 가능한 가상 컴퓨터를 실행할 수 있습니다.
- Azure 지역 (Azure Regions): 전 세계에 분산된 Microsoft Azure 데이터 센터의 지리적 위치입니다. 각 지역은 하나 이상의 가용성 영역으로 구성됩니다.
- 복구 서비스 자격 증명 모음 (Recovery Services Vault): Azure Backup 및 Azure Site Recovery와 같은 서비스를 사용하여 백업 데이터, 복구 지점 및 복제 구성을 저장하는 Azure 리소스입니다. 데이터를 안전하게 보관하고 재해 복구 기능을 제공합니다.
- 백업 정책 (Backup Policy): 백업을 수행하는 빈도와 보존 기간을 정의하는 규칙 집합입니다.
- 확장 (Extensions): Azure 가상 머신에 배포 후 기능을 추가하거나 관리 작업을 수행하는 데 사용되는 작은 애플리케이션입니다. Azure Backup 에이전트와 같은 확장이 백업 및 복구 기능을 위해 필요합니다.
문제 219
문제: 다음 표와 같은 리소스가 포함된 Azure 구독이 있습니다. 방화벽을 사용하여 VNET1에서 나가는 트래픽을 관리해야 합니다. 가장 먼저 무엇을 해야 할까요?
옵션:
- a) Virtual Network Watcher를 만듭니다.
- b) 경로 테이블을 만듭니다.
- c) asp1 (App Service Plan)을 Premium SKU로 업그레이드합니다.
- d) 하이브리드 연결 관리자를 구성합니다.
정답: b) 경로 테이블을 만듭니다.
해설:
Azure 가상 네트워크를 만들면 Azure는 각 서브넷에 대한 기본 경로 테이블을 자동으로 생성하고 시스템 경로를 추가합니다. 아웃바운드 트래픽을 특정 방화벽으로 보내려면 **사용자 정의 경로 테이블 (User-Defined Route Table)**을 만들어야 합니다. 이 경로 테이블에는 모든 트래픽을 Azure Firewall로 보내는 경로를 정의하고, 이를 VNET1 과 통합된 App Service의 서브넷에 연결해야 합니다. 이렇게 하면 App Service에서 발생하는 모든 아웃바운드 트래픽이 Azure Firewall을 거치도록 강제하여 트래픽을 검사하고 제어할 수 있습니다.
Azure 관련 용어 해설:
- Azure Virtual Network (VNet): Azure에서 생성하는 사설 네트워크로, Azure 리소스 간, 인터넷 및 온-프레미스 네트워크 간의 안전한 통신을 가능하게 합니다.
- 가상 네트워크 통합 (Virtual Network Integration): Azure App Service를 Azure Virtual Network에 연결하여 App Service에서 VNet 내의 리소스에 액세스하거나 VNet을 통해 아웃바운드 트래픽을 라우팅할 수 있도록 하는 기능입니다.
- Azure Firewall: Azure Virtual Network 리소스를 보호하는 클라우드 기반의 관리형 네트워크 보안 서비스입니다. 인바운드 및 아웃바운드 트래픽을 제어하고 위협으로부터 보호할 수 있습니다.
- 경로 테이블 (Route Table): 가상 네트워크 내에서 네트워크 트래픽이 이동하는 경로를 정의하는 규칙 집합입니다. Azure에서 기본 경로 테이블을 제공하지만, 사용자 정의 경로 테이블을 만들어 트래픽 흐름을 제어할 수 있습니다.
- 서브넷 (Subnet): Azure Virtual Network를 논리적으로 분할한 것입니다. 각 서브넷 내에 Azure 리소스를 배포하고 서브넷 간에 네트워크 보안 규칙을 적용할 수 있습니다.
- App Service Plan: Azure App Service가 실행될 물리적 리소스의 크기 및 기능을 정의합니다. SKU (Standard, Premium 등)에 따라 제공되는 기능과 가격이 달라집니다.
- Virtual Network Watcher: Azure 네트워크를 모니터링하고 진단하는 데 사용되는 서비스입니다.
- 하이브리드 연결 관리자 (Hybrid Connection Manager): Azure App Service, Azure Functions 등에서 온-프레미스 리소스에 안전하게 액세스할 수 있도록 하는 데 사용되는 서비스입니다.
문제 220
문제: storage1이라는 범용 v1 Azure Storage 계정이 로컬 중복 스토리지 (LRS)를 사용하고 있습니다. 영역 오류가 발생해도 스토리지 계정의 데이터를 보호해야 하며, 솔루션은 비용과 관리 노력을 최소화해야 합니다. 가장 먼저 무엇을 해야 할까요?
옵션:
- a) 새 스토리지 계정을 만듭니다.
- b) 개체 복제 규칙을 구성합니다.
- c) 범용 v2로 업그레이드합니다.
- d) storage one의 복제 설정을 수정합니다.
정답: c) 범용 v2로 업그레이드합니다.
해설:
문제는 영역 오류로부터 데이터를 보호하면서 비용과 관리 노력을 최소화하는 방법을 묻고 있습니다. 현재 스토리지 계정은 범용 v1이며 **LRS (로컬 중복 스토리지)**를 사용하고 있습니다. LRS는 단일 데이터 센터 내에서 데이터를 복제하므로 영역 오류가 발생하면 데이터가 손실될 수 있습니다.
**영역 중복 스토리지 (ZRS)**는 여러 가용성 영역에 데이터를 동기적으로 복제하여 영역 오류로부터 데이터를 보호합니다. 하지만 범용 v1 스토리지 계정은 ZRS를 지원하지 않습니다. ZRS를 사용하려면 스토리지 계정을 범용 v2로 업그레이드해야 합니다. 범용 v2는 비용 효율적인 스토리지 옵션을 제공하며 ZRS를 포함한 다양한 중복 옵션을 지원하므로 문제의 요구 사항을 충족하는 가장 적절한 해결책입니다.
GRS (지리적 중복 스토리지) 또는 RA-GRS (읽기 액세스 지리적 중복 스토리지)도 영역 오류로부터 보호하지만, 비용이 더 많이 들고 관리 노력이 증가할 수 있습니다. 새 스토리지 계정을 만드는 것도 가능하지만 기존 데이터를 마이그레이션해야 하므로 추가적인 관리 노력이 필요합니다. 개체 복제 규칙은 다른 스토리지 계정으로 데이터를 복제하는 기능이므로, 기본 스토리지 계정의 영역 오류 문제를 직접적으로 해결하지 못합니다. 따라서 범용 v2로 업그레이드하는 것이 가장 비용 효율적이고 관리 노력을 최소화하면서 영역 오류로부터 데이터를 보호하는 첫 번째 단계입니다.
Azure 관련 용어 해설:
- Azure Storage 계정: Azure에서 Blob, File, Queue, Table, Disk 등의 데이터 서비스를 사용하기 위한 기본 단위입니다.
- 범용 v1 (General Purpose v1): 이전 버전의 Azure Storage 계정 유형으로, 최신 기능 및 중복 옵션 (예: ZRS)에 대한 지원이 제한적일 수 있습니다.
- 범용 v2 (General Purpose v2): 최신 버전의 Azure Storage 계정 유형으로, 모든 Azure Storage 서비스에 대한 통합 액세스를 제공하며 최신 기능과 비용 최적화를 지원합니다. ZRS, GRS, RA-GRS 등 다양한 중복 옵션을 제공합니다.
- 로컬 중복 스토리지 (LRS - Locally Redundant Storage): 단일 물리적 위치 (데이터 센터 내의 단일 스탬프) 내에서 데이터를 세 번 복제합니다. 가장 저렴한 중복 옵션이지만, 데이터 센터 오류 발생 시 데이터 손실 위험이 있습니다.
- 영역 중복 스토리지 (ZRS - Zone-Redundant Storage): 동일한 Azure 지역 내의 세 개의 가용성 영역에 데이터를 동기적으로 복제합니다. LRS보다 높은 가용성과 내구성을 제공하며, 데이터 센터 오류로부터 보호합니다.
- 지리적 중복 스토리지 (GRS - Geo-Redundant Storage): 주 지역 외에 수백 마일 떨어진 보조 지역에 데이터를 비동기적으로 복제합니다. 주 지역 전체에 오류가 발생해도 데이터를 복구할 수 있지만, 쓰기 액세스는 주 지역으로만 제한됩니다.
- 읽기 액세스 지리적 중복 스토리지 (RA-GRS - Read-Access Geo-Redundant Storage): GRS와 동일하게 데이터를 복제하지만, 보조 지역에서 데이터를 읽을 수 있는 기능을 제공합니다. 읽기 작업에 대한 성능 향상과 가용성을 높일 수 있습니다.
- 가용성 영역 (Availability Zones): 각 Azure 지역 내에서 오류가 발생하지 않도록 격리된 물리적 위치입니다. 각 영역은 독립적인 전원, 냉각 및 네트워킹 인프라를 갖추고 있습니다. ZRS는 여러 가용성 영역에 데이터를 복제하여 고가용성을 제공합니다.
Legacy(레거시)란?
Legacy(레거시)란 IT 분야에서 주로 사용되는 용어로, 더 이상 최신 기술은 아니지만 여전히 사용되고 있는 오래된 시스템, 소프트웨어, 하드웨어, 기술, 또는 애플리케이션을 의미합니다. 즉, "레거시 시스템"은 구식이지만 현재의 비즈니스나 운영에 중요한 역할을 하고 있는 시스템을 가리킵니다.
주요 특징
- 오래된 기술: 레거시 시스템은 일반적으로 더 이상 공식적인 지원, 업데이트, 또는 유지보수가 제공되지 않는 구 버전의 기술, 소프트웨어, 하드웨어 등을 포함합니다.
- 여전히 사용됨: 기술적으로는 구식이지만, 조직 내에서 중요한 데이터나 프로세스를 담당하고 있어 계속 사용됩니다.
- 호환성 문제: 최신 시스템과의 연동이 어렵거나, 새로운 표준 및 보안 요구사항을 충족하지 못하는 경우가 많습니다.
- 유지보수의 어려움: 관련 기술을 아는 인력이 부족하고, 문서화가 미흡하거나, 부품이나 소프트웨어가 더 이상 구할 수 없는 경우가 많아 유지보수가 어렵습니다.
- 교체의 어려움: 데이터 이전, 비용, 운영 중단 위험, 기존 투자 회수 등의 이유로 쉽게 교체하지 못하는 경우가 많습니다.
Data redundancy - Azure Storage
Understand data redundancy in Azure Storage. Data in your Microsoft Azure Storage account is replicated for durability and high availability.
learn.microsoft.com
'인공지능,프로그래밍 > MS Azure' 카테고리의 다른 글
| Azure 104 연습 문제 39 (2) | 2025.04.18 |
|---|---|
| Azure 104 연습 문제 38 (0) | 2025.04.18 |
| Azure 104 연습 문제 36 (1) | 2025.04.17 |
| Azure 104 연습 문제 35 (1) | 2025.04.17 |
| Azure 104 연습 문제 34 (2) | 2025.04.17 |
