Azure Cosmos DB

Azure CLI란?

Azure PowerShell 설명서

Azure 리소스 관리자 템플릿이란?

Azure Cosmos DB의 기본 제공 Jupyter 노트북

Azure 프라이빗 엔드포인트란 무엇인가요?

Azure 리소스 관리자 템플릿을 사용하여 Azure Cosmos DB Core(SQL) API 리소스 관리

Azure Storage 방화벽 및 가상 네트워크 구성

Azure 포털을 사용하여 Azure 사용자 지정 역할 만들기 또는 업데이트

Azure 포털을 사용하여 Azure 역할 할당 추가 또는 제거

Azure Active Directory란?

aZ 코스모스DB 만들기

새-AzCosmosDBAccount

Microsoft Azure에서 비관계형 데이터 서비스를 프로비저닝하고 배포하는 방법을 살펴봅니다. Microsoft Azure는 Azure 파일 스토리지, Azure Blob Storage, Azure 데이터 레이크 스토어 및 Azure Cosmos DB를 비롯한 다양한 비관계형 데이터 서비스를 지원합니다. 이러한 서비스는 다양한 유형의 비관계형 데이터를 지원합니다. 예를 들어 Cosmos DB를 사용하여 문서를 저장하고 Blob Storage를 비디오 및 오디오 데이터와 같은 대용량 바이너리 객체의 저장소로 사용할 수 있습니다.서비스를 사용하려면 먼저 해당 서비스의 인스턴스를 프로비전해야 합니다. 그런 다음 데이터를 저장 및 검색하고 이를 필요로 하는 사용자와 애플리케이션이 데이터에 액세스할 수 있도록 서비스를 구성할 수 있습니다. 대규모 제조 시설을 운영하는 조직인 Contoso에서 근무하는 데이터 엔지니어라고 가정해 보겠습니다. 조직은 생산 라인 기계 상태에 대한 실시간 데이터 모니터링, 제품 품질 관리 데이터, 과거 생산 로그, 제품 재고 수량, 원자재 재고 데이터 등 다양한 출처에서 정보를 수집하고 저장해야 합니다. 이 정보는 조직 운영에 매우 중요합니다. Contoso는 각 데이터 세트의 서로 다른 데이터 프로세스 또는 요구 사항에 따라 다양한 비관계형 데이터베이스에 이 정보를 저장하기로 결정했습니다. 애플리케이션이 정보를 저장하고 처리할 수 있도록 다양한 Microsoft Azure 데이터 서비스를 제공하라는 요청을 받았습니다. 이 단원에서는 비관계형 데이터 서비스를 제공하고, 비관계형 데이터 서비스를 구성하고, 기본 연결 문제를 살펴보고, 데이터 보안 구성 요소를 살펴봅니다.

샘플 시나리오에서 Contoso는 조직에 여러 개의 서로 다른 비관계형 저장소가 필요하다고 결정했습니다. 데이터 엔지니어는 Azure Cosmos DB를 사용하여 데이터 저장소를 설정하라는 요청을 받습니다. 애저 블럽 스토리지. Azure 데이터 레이크 스토어 및 Azure 파일 스토리지 이제 프로비저닝 프로세스에 수반되는 사항과 서비스를 프로비저닝할 때 실제로 어떤 일이 발생하는지 자세히 알아봅니다. 프로비저닝은 Azure Cosmos DB와 같은 서비스 공급자가 백그라운드에서 서비스를 만들고 구성하기 위해 수행하는 일련의 작업을 실행하는 행위입니다. 서비스 공급자는 서비스를 실행하는 데 필요한 디스크, 메모리, CPU 네트워크 등과 같은 다양한 리소스를 설정합니다. 이러한 리소스는 사용자에게 할당되며 서비스를 삭제할 때까지 사용자에게 할당된 상태로 유지되고 요금이 청구됩니다. 서비스 제공업체가 리소스를 제공하는 방식은 불투명하므로 이 프로세스의 작동 방식에 대해 걱정할 필요가 없습니다. 필요한 리소스의 크기, 디스크 공간, 메모리 용량, 컴퓨팅 성능 및 네트워크 대역폭을 결정하는 매개 변수를 지정하기만 하면 됩니다. 이러한 매개 변수는 서비스를 사용하여 실행하려는 워크로드의 크기를 예측하여 결정됩니다. 대부분의 경우 서비스를 생성한 후에 이러한 매개 변수를 수정할 수 있으며, 이로 인해 저장 공간이나 메모리 용량이 늘어날 수 있습니다. 워크로드가 처음에 예상했던 것보다 많을 경우 서비스에 사용되는 리소스를 늘리거나 줄이는 작업을 스케일링이라고 합니다. Microsoft Azure가 수행하는 프로세스를 살펴보겠습니다. 서비스를 먼저 프로비전하면 사용자가 서비스 스토리지, 메모리 유형 및 컴퓨팅 파워와 같은 프로비저닝 매개 변수를 지정합니다. 그런 다음 프로비저닝 매개 변수가 Microsoft Azure로 전송되어 서비스를 프로비저닝합니다. Microsoft Azure는 서비스를 생성하는 데 필요한 리소스를 할당합니다. 이제 서비스를 사용할 준비가 된 것입니다. Microsoft Azure는 프로비전 서비스를 사용할 수 있는 몇 가지 도구를 제공합니다. Azure 포털은 대부분의 사용자에게 서비스를 제공하는 가장 편리한 방법입니다. Azure Portal에는 서비스를 실제로 프로비전하기 전에 필요한 설정을 입력하라는 메시지가 표시되고 이러한 설정의 유효성을 검사하는 일련의 서비스별 페이지가 표시됩니다. Azure 명령줄 인터페이스 (CLI) 는 운영 체제 명령 프롬프트 또는 클라우드 셸에서 실행할 수 있는 명령 집합을 제공합니다. Azure 포털에서 이러한 명령을 사용하여 Azure 리소스를 만들고 관리할 수 있습니다. CLI는 서비스 생성을 자동화해야 하는 경우에 적합합니다. CLI 명령 및 스크립트를 저장하고 프로그래밍 방식으로 스크립트를 실행할 수 있습니다. CLI는 윈도우, 맥 OS 및 리눅스 컴퓨터에서 실행할 수 있습니다.Azure CLI에 대한 자세한 내용은 Azure CLI란 무엇입니까? 를 참조하십시오. 이 단원의 마지막 부분에 나오는 추가 자료에서는 많은 관리자가 파워 셸 명령을 사용하여 관리 작업을 스크립팅하고 자동화하는 데 익숙합니다. Microsoft Azure는 Power Shell에서 만들고 관리하는 데 사용할 수 있는 Azure 전용 명령인 일련의 명령을 제공합니다. Azure 리소스는 Windows, macOS 및 Linux에서 CLI에 대한 파워 셸을 사용할 수 있습니다. Azure 파워 셸에 대한 자세한 내용은 이 강의 마지막 부분에 있는 추가 자료에 링크된 Azure 파워 셸 설명서에서 온라인으로 확인할 수 있습니다. Azure 리소스 관리자 템플릿은 Jason 또는 JavaScript 개체 표기법이라는 형식으로 텍스트 파일에 배포하려는 서비스를 설명합니다. 비전 및 Azure 스토리지가 고려되는 템플릿을 사용할 수 있습니다. 배포 그룹을 사용하여 Azure에 템플릿을 보내거나, Azure CLI에서 명령을 생성하거나, Azure Power Shell에서 리소스 그룹 배포 명령으로 새 템플릿을 생성합니다. Azure 리소스 관리자 템플릿을 만들고 사용하여 Azure 리소스를 프로비저닝하는 방법에 대한 자세한 내용은이 강의 마지막 부분에 나오는 추가 자료에서 Azure 리소스 관리자 템플릿에 대해 알아보세요.

 

Azure Cosmos DB는 다양한 애플리케이션에 적합한 문서 데이터베이스입니다. 샘플 시나리오에서 Contoso는 Cosmos DB를 데이터 저장 및 처리의 일부에 사용하기로 결정했습니다. Cosmos DB에서는 데이터를 컨테이너에 저장된 문서 모음으로 구성합니다. 컨테이너는 데이터베이스에 보관됩니다. 데이터베이스는 Cosmos DB 계정의 컨텍스트에서 실행됩니다. 데이터베이스를 설정하려면 먼저 계정을 만들어야 합니다. 이제 Cosmos DB 계정을 프로비저닝한 다음 이 계정에서 데이터베이스와 캠페인 담당자를 만드는 방법을 알아봅니다. Azure 포털을 사용하여 Cosmos DB 계정을 대화식으로 프로비전하는 방법을 이미 배웠습니다. Azure CLI, Azure PowerShell 또는 Azure 리소스 관리자 템플릿을 통해 프로그래밍 방식으로 이 작업을 수행할 수도 있습니다. Azure CLI 또는 Azure PowerShell을 사용하려는 경우 명령을 실행하여 Cosmos DB 계정을 만들 수 있습니다. 이러한 명령의 매개 변수는 Azure 포털을 사용하여 선택할 수 있는 여러 옵션에 해당합니다. 예를 들어 미국 동부와 서부 지역 간의 I/O 중복성을 제공하고 Azure CLI를 사용하여 다중 지역 쓰기를 지원하는 Core (SQL) API에 대한 계정을 만들 수 있습니다. 마찬가지로 PowerShell을 사용하여 동일한 목표를 달성할 수 있습니다. 이러한 명령에 대한 자세한 내용은 Azure CLI용 AZ Cosmos DB 생성 페이지, PowerShell용 새 AZ Cosmos DB 계정 페이지를 참조하십시오. 이 페이지는 이 단원의 마지막 부분에 있는 추가 자료에 링크되어 있습니다. Azure PowerShell을 사용하여 Cosmos DB 계정을 프로비전하려면 먼저 명령 설치 모듈 이름 AZ를 사용하여 AZ Cosmos DB PowerShell 모듈을 설치해야 한다는 점에 유의하십시오. 코스모스 DB. 다른 배포 옵션은 Azure 리소스 관리자 템플릿을 사용하는 것입니다. Cosmos DB의 템플릿은 매개 변수 수 때문에 다소 길 수 있습니다. 보다 편리하게 사용할 수 있도록 Microsoft는 다양한 구성을 처리하기 위한 여러 예제 템플릿을 게시했습니다. Microsoft 웹 사이트에 있는 이러한 템플릿에 대한 링크는 이 강의 마지막 부분에 있는 추가 자료에서 찾을 수 있습니다.

 

Azure Cosmos DB 계정 자체로는 몇 가지 정적 인프라 외에는 어떤 리소스도 제공하지 않습니다. 데이터베이스와 컨테이너는 주요 리소스 소비자입니다. 리소스는 데이터베이스와 컨테이너를 보관하는 데 필요한 스토리지 공간과 데이터를 저장하고 검색하는 데 필요한 처리 능력을 기준으로 할당됩니다. Azure Cosmos DB는 초당 요청 단위 또는 RU 개념을 사용하여 데이터베이스의 성능과 비용을 관리합니다. 이 측정값은 필요한 성능을 지원하기 위해 프로비저닝해야 하는 기본 물리적 리소스를 추상화합니다. 요청 단위는 데이터베이스에 대한 간단한 읽기 요청을 충족하는 데 필요한 계산 및 IO 리소스의 양이라고 생각할 수 있습니다. Microsoft에서는 필드가 10개인 1킬로바이트 문서를 읽는 데 필요한 리소스로 약 1RU를 측정합니다. 초당 1RU의 처리량은 초당 1킬로바이트의 문서를 하나씩 읽는 응용 프로그램을 지원합니다. 데이터베이스를 만들거나 데이터베이스에 개별 컨테이너를 만들 때 필요한 처리량 RU 수를 지정할 수 있습니다.데이터베이스의 처리량을 지정하면 해당 데이터베이스의 모든 컨테이너가 해당 처리량을 공유합니다.컨테이너의 처리량을 지정하면 컨테이너는 해당 처리량을 모두 가져옵니다. RU를 너무 적게 지정하여 과소 프로비저닝하면 Cosmos DB에서 성능 조절이 시작됩니다. 전송률 조절이 시작되면 요청을 충족할 수 있는 리소스가 있으면 나중에 요청을 다시 시도하라는 메시지가 표시됩니다. 애플리케이션이 병목 현상이 발생한 요청을 재시도하려고 너무 많이 시도하면 요청이 중단될 수 있습니다. 데이터베이스 또는 컨테이너에 할당할 수 있는 최소 처리량은 400RU입니다. 언제든지 컨테이너의 RU를 늘리거나 줄일 수 있습니다. 더 많은 RU를 할당하면 비용이 증가합니다. 하지만 데이터베이스나 컨테이너에 처리량을 할당하고 나면 사용 여부에 관계없이 프로비저닝된 리소스에 대한 요금이 부과됩니다. 참고로 Cosmos DB 계정에 프리 티어 할인을 적용하면 단일 데이터베이스 또는 컨테이너에 대해 처음 400RU를 무료로 받을 수 있습니다. 일반적으로 400RU는 대부분의 소규모에서 중간 규모의 데이터베이스를 위한 충분한 용량입니다. Azure Portal은 컨테이너에 데이터베이스를 더 쉽게 만들 수 있는 그래픽 사용자 인터페이스를 제공합니다. 이에 대해서는 다음 비디오에서 자세히 설명합니다. 하지만 Azure CLI 또는 Azure PowerShell을 사용하려는 경우 명령을 실행하여 컨테이너에 문서를 만들 수 있습니다. 이에 대해서는 지금부터 설명하겠습니다. Azure CLI에서는 AZ Cosmos DB SQL 데이터베이스 생성 명령을 사용하여 데이터베이스를 만들 수 있습니다. 그런 다음 계정 이름, 데이터베이스 이름, 리소스 그룹, 구독, 처리량과 같은 매개 변수를 지정합니다. AZ Cosmos DB SQL 컨테이너 생성 명령을 사용하여 컨테이너를 생성할 수 있습니다. 그런 다음 파라미터, 계정 이름, 데이터베이스 이름, 컨테이너 이름, 리소스 그룹, 파티션 키 경로를 지정합니다. Azure PowerShell에서는 새 AZ Cosmos DB SQL 데이터베이스 명령을 사용하여 데이터베이스를 만들 수 있습니다. 그런 다음 매개 변수, 리소스 그룹 이름, 계정 이름, 데이터베이스 이름 및 처리량을 지정합니다. 새 AZ Cosmos DB SQL 컨테이너 명령을 사용하여 매개 변수 파티션 키 종류와 파티션 키 경로를 지정하여 컨테이너를 생성할 수 있습니다.

* Cosmos DB에서는 데이터베이스 또는 컨테이너에 더 많은 처리량을 할당하면 사용 여부에 관계없이 프로비저닝된 리소스에 대해 요금이 부과됩니다.

 

코스모스 DB 외에도 Microsoft Azure는 다른 비관계형 데이터 서비스를 지원합니다. 이러한 서비스는 일반화된 문서 데이터베이스 저장소보다 더 구체적인 경우에 최적화되어 있습니다. 샘플 시나리오에서 Contoso는 Azure Blob Storage를 사용하여 비디오 및 오디오 파일을 저장하고, Azure Data Lake Storage를 사용하여 대용량 데이터를 지원하며, Azure 파일 스토리지를 사용하여 파일 공유를 만들려고 합니다. 이제 데이터 레이크 스토리지, Blob 스토리지 및 파일 스토리지를 프로비저닝하는 방법을 알아봅니다. Cosmos DB와 마찬가지로 Azure 포털을 사용하여 이러한 서비스를 프로비전할 수 있으며, Azure CLI, Azure PowerShell 및 Azure 리소스 관리자 템플릿, 데이터 레이크 스토리지, Blob 스토리지 및 파일 스토리지를 사용하려면 먼저 Azure 스토리지 계정을 만들어야 합니다. 저장소 계정 생성 페이지를 사용하여 Azure 포털을 사용하여 새 저장소 계정을 설정할 수 있습니다. 기본 탭에서 다음 세부 정보를 제공하십시오. 구독에서 Microsoft를 구독으로 선택하고 리소스 그룹에서 기존 리소스 그룹을 선택하거나 필요에 따라 새 리소스 그룹을 생성합니다. 저장소 계정 이름에서 Cosmos DB 계정과 마찬가지로 각 저장소 계정은 다른 사람이 아직 사용하지 않은 고유한 이름을 가져야 합니다. 해당 위치에서 새 애플리케이션을 개발 중인 경우 가장 가까운 지역을 선택하고, 기존 애플리케이션을 배포하는 경우 사용자와 가장 가까운 지역을 선택합니다. 성능 설정에는 두 가지 옵션이 있습니다. 표준 저장소 계정은 하드 디스크를 기반으로 합니다. 두 스토리지 옵션 중 비용이 가장 저렴하지만 지연 시간이 더 깁니다. 이 유형의 저장소 계정은 보관소와 같이 자주 액세스하지 않는 서점이 필요한 애플리케이션에 적합합니다. 솔리드 스테이트 드라이브를 사용하는 프리미엄 스토리지는 표준 스토리지보다 지연 시간이 훨씬 짧고 읽기-쓰기 성능이 뛰어납니다. 솔리드 스테이트 드라이브는 데이터베이스와 같이 I/O 집약적인 애플리케이션에 가장 적합합니다. Azure 가상 머신 디스크가 들어 있는 프리미엄 스토리지도 사용할 수 있습니다. 프리미엄 저장소 계정은 표준 계정보다 비쌉니다. Data Lake Storage는 프리미엄이 아닌 표준 스토리지 계정에서만 사용할 수 있다는 점에 유의하세요. 계정 종류에서 Azure Storage는 여러 유형의 계정을 지원한다는 것을 알 수 있습니다. Blob, 파일 , 큐 및 테이블에 범용 v2 저장소 계정을 사용할 수 있으며 Azure 저장소가 필요한 대부분의 시나리오에 권장됩니다. Azure 데이터 레이크 스토리지를 프로비전하려면 이 계정 유형을 지정해야 합니다. 범용 v1은 Blob, 파일, 큐 및 테이블에 대한 레거시 계정 유형입니다. 가능하면 범용 v2 계정을 사용하세요. 다른 유형의 계정으로는 블록 Blob 저장소, 파일 저장소, Blob 저장소가 있습니다. 블록 블럽 스토리지는 프리미엄 계정에만 사용할 수 있습니다. 블록 블롭과 블롭 추가에 이 계정 유형을 사용할 수 있습니다. 트랜잭션 속도가 높거나, 더 작은 객체를 사용하거나, 지속적으로 낮은 스토리지 지연 시간을 요구하는 시나리오에 사용하는 것이 좋습니다. 파일 스토리지는 프리미엄 계정에만 사용할 수 있습니다. 프리미엄 성능 특성을 가진 파일 전용 저장소 계정을 만드는 데 사용합니다. 엔터프라이즈 또는 고성능 규모의 애플리케이션에 권장됩니다. 파일 스토리지를 지원하는 계정을 만들려면 이 유형을 사용하십시오. Blob Storage는 Blob만 보관할 수 있는 또 다른 레거시 계정 유형입니다. 가능하면 범용 v2 계정을 대신 사용하세요. Azure Data Lake Storage에 이 계정 유형을 사용할 수 있지만 범용 v2 계정 유형을 사용하는 것이 좋습니다. Azure Storage 계정의 데이터는 계정의 기본 위치로 지정한 지역에 항상 세 번 복제됩니다. Azure Storage는 데이터를 기본 지역에 복제하는 방법에 대한 두 가지 옵션을 제공합니다. 로컬 중복 스토리지 (LRS) 는 지역 내 단일 물리적 위치에 데이터를 동기적으로 세 번 복사합니다. LRS는 가장 비용이 적게 드는 복제 옵션이지만 고가용성이 필요한 애플리케이션에는 권장되지 않습니다. GEO 중복 스토리지 (GRS) 는 LRS를 사용하여 주 지역의 단일 물리적 위치에 데이터를 동기적으로 세 번 복사합니다. 그런 다음 데이터를 보조 지역의 단일 물리적 위치에 비동기적으로 복사합니다. 이러한 형태의 복제를 통해 지역적 운영 중단으로부터 보호할 수 있습니다. 읽기 액세스 지역 중복 스토리지 또는 RA-GRS 복제는 보조 위치의 데이터에 대한 직접 읽기 전용 액세스를 제공하는 GRS의 확장입니다. 반면 GRS 옵션은 보조 위치의 데이터를 노출하지 않고 기본 위치의 장애 복구에만 사용됩니다. RA-GRS 복제를 사용하면 지리적으로 멀리 떨어진 위치에 있는 사용자와 가까운 곳에 데이터의 읽기 전용 사본을 저장할 수 있으므로 읽기 지연 시간을 줄일 수 있습니다. 영역 중복 저장소 (ZRS) 는 기본 지역의 Azure 가용성 영역 3개에서 Azure 저장소 데이터를 동기적으로 복제합니다. 각 가용 영역은 독립적인 전원, 냉각 및 네트워킹을 갖춘 별도의 물리적 위치입니다. 이는 고가용성이 필요한 애플리케이션에 유용합니다. 성능을 유지하기 위해 프리미엄 저장소 계정은 LRS 복제만 지원한다는 점에 유의하세요. 데이터 무결성을 유지하기 위해 복제가 동기적으로 수행되기 때문입니다. 데이터를 먼 지역으로 복제하면 지연 시간이 길어져 프리미엄 스토리지를 사용할 때의 이점을 모두 상실할 수 있습니다. 액세스 티어 옵션은 표준 스토리지 계정에만 사용할 수 있습니다. 핫과 쿨 중에서 선택할 수 있습니다. 핫 액세스 계층은 액세스 비용이 가장 낮은 쿨 및 아카이브 계층보다 스토리지 비용이 높습니다. 핫 액세스 계층의 사용 시나리오에는 현재 사용 중이거나 자주 액세스될 것으로 예상되는 데이터, 자주 읽고 쓰는 데이터, 처리 단계에 있는 데이터, 쿨 액세스 계층으로의 최종 마이그레이션 등이 포함됩니다. 쿨 액세스 티어는 핫 스토리지에 비해 높은 액세스 비용보다 스토리지 비용이 저렴합니다. 이 계층은 쿨 티어에 30일 이상 남아 있는 데이터를 위한 것입니다. Cool Access Tier의 사용 시나리오로는 단기 백업 및 재해 복구 데이터 세트, 더 이상 자주 보지는 않지만 액세스 즉시 사용할 수 있을 것으로 예상되는 오래된 미디어 콘텐츠, 향후 처리를 위해 더 많은 데이터를 수집하는 동시에 비용 효율적으로 저장해야 하는 대규모 데이터 세트 등이 있습니다. 제조 시설의 과학 데이터 또는 원시 원격 측정 데이터를 장기간 보관하는 경우를 예로 들 수 있습니다. Azure CLI를 사용하는 경우 AzStorageAccount 명령을 실행하여 새 저장소 계정을 만드세요. 세 가지 옵션을 사용할 수 있습니다. 먼저, SKU는 성능 등급과 복제 옵션의 조합입니다. 이는 프리미엄 LRS, 프리미엄 ZRS, 표준 GRS, 표준 GZRS, 표준 LRS, 표준 RA-GRS, 표준 RA-GZRS 또는 표준 CRS 중 하나일 수 있습니다. 다음으로 종류 매개변수는 블럽 스토리지, 블록 블럽 스토리지, 파일 스토리지, 스토리지 또는 스토리지 v2 중 하나여야 합니다. 마지막으로, 액세스 계층 매개변수는 쿨 파라미터일 수도 있고 핫 파라미터일 수도 있습니다. 새 AzStorageAccount PowerShell 명령어를 사용하여 다음 매개 변수를 사용하여 새 저장소 계정을 만들 수 있습니다. 이름, 리소스 그룹 이름, 위치, SKU 이름, 종류, 액세스 등급 sku 이름, 종류 및 액세스 등급의 값은 Azure CLI 명령의 값과 동일합니다.

핫 액세스 계층은 쿨 및 아카이브 계층보다 스토리지 비용이 높지만 액세스 비용이 가장 낮으며, 쿨 액세스 계층은 핫 스토리지에 비해 스토리지 비용은 낮고 액세스 비용은 높습니다

먼저 Azure 포털을 사용하여 스토리지 계정에서 Data Lake 스토리지를 프로비저닝하는 방법을 살펴보겠습니다. 하지만 계속 진행하기 전에 Data Lake 저장소를 프로비저닝하는 경우 저장소 계정을 만들 때 적절한 구성 설정을 지정해야 한다는 점에 유의해야 합니다. 스토리지 계정을 설정한 후에는 Data Lake 저장소를 구성할 수 없습니다. Azure 포털의 Data Lake Storage Gen2 섹션에 있는 스토리지 계정 생성 페이지의 고급 탭에 있는 계층적 네임스페이스 옵션에 대해 “활성화됨”을 선택합니다. 스토리지 계정을 생성한 후 계정에 Data Lake 스토리지 컨테이너를 하나 이상 추가할 수 있습니다. 각 컨테이너는 데이터 레이크 파일을 저장하기 위한 디렉터리 구조를 지원합니다. Azure CLI를 사용하여 Data Lake 저장소 및 저장소 계정을 프로비전하는 경우 AC 저장소 계정 명령을 실행하고 값이 true인 계층적 네임스페이스 활성화 매개 변수를 추가하여 데이터 레이크 저장소를 지원하는 새 저장소 계정을 만듭니다. Azure PowerShell을 사용하는 경우 새 AZ 저장소 계정 PowerShell 명령어를 실행합니다. 여기에서 값이 true인 활성화된 계층적 네임스페이스 매개 변수를 추가합니다. Blob은 컨테이너에 저장되며, 스토리지 계정을 생성한 후 컨테이너를 생성합니다. Azure Portal에서 저장소 계정의 개요 페이지에 있는 기능을 사용하여 컨테이너를 추가할 수 있습니다. 컨테이너 페이지에서는 컨테이너를 만들고 관리할 수 있습니다. 각 컨테이너는 저장소 계정 내에서 고유한 이름을 가져야 합니다. 액세스 수준을 지정할 수도 있습니다. 기본적으로 컨테이너에 보관된 데이터에는 컨테이너 소유자만 액세스할 수 있습니다. Blob에 대한 액세스 수준을 설정하여 컨테이너 또는 컨테이너에서 생성된 모든 Blob에 대한 공개 읽기 액세스를 허용하고 모든 Blob을 나열하는 기능을 포함하여 컨테이너의 전체 콘텐츠에 대한 읽기 액세스를 허용하도록 할 수 있습니다. 보다 세분화된 보안 수준이 필요한 경우 Blob에 대한 역할 기반 액세스 제어를 구성할 수도 있습니다. I 컨테이너를 프로비전하면 애플리케이션에서 Blob을 컨테이너에 업로드할 수 있습니다. Azure CLI에서 AZ 스토리지 컨테이너 생성 명령은 스토리지 계정에 새 로그 컨테이너를 설정합니다. 퍼블릭 액세스 파라미터는 블럽 컨테이너일 수도 있고 프라이빗 액세스만을 위한 오프 모드일 수도 있습니다. Azure PowerShell에서는 새 AZ 저장소 컨테이너 명령어를 사용하여 저장소 계정에 컨테이너를 추가할 수 있습니다. 먼저 AZ 저장소 계정 가져오기 명령줄을 사용하여 저장소 계정 개체를 검색한 다음 권한 매개 변수를 사용해야 합니다. 블럽 컨테이너 또는 오프 값을 허용합니다. 하나 이상의 파일 공유와 스토리지 계정을 생성하여 파일 스토리지를 프로비저닝합니다. Azure Portal의 경우 계정의 개요 페이지에서 “파일 공유”를 선택합니다. 파일 공유 페이지를 사용하여 새 파일 공유를 만들고 파일 공유에 이름을 지정하고 선택적으로 할당량을 설정하여 공유의 파일 크기를 제한할 수 있습니다. 저장소 계정의 모든 파일 공유에 있는 모든 파일의 총 크기는 5,120GB에서 5테라바이트를 초과할 수 없습니다.파일 공유를 생성한 후 애플리케이션은 파일 공유를 사용하여 공유 파일을 읽고 쓸 수 있습니다. Azure CLI는 저장소 계정에 새 파일 공유를 생성할 수 있는 AZ 저장소 공유 생성을 제공합니다. 그런 다음 공유 이름 및 계정 이름 매개 변수를 지정합니다. 새 AZ Storage 공유 명령어는 새 파일 공유 및 저장소 계정을 생성합니다. 먼저 스토리지 계정 세부 정보를 검색해야 합니다. 그런 다음 매개 변수, 리소스 그룹, 저장소 계정 이름 및 공유 이름을 지정합니다.

 

리소스를 프로비저닝한 후에는 애플리케이션과 환경의 요구 사항에 맞게 구성해야 하는 경우가 많습니다. 예를 들어 애플리케이션이 리소스에 연결할 수 있도록 네트워크 액세스를 설정하거나 방화벽 포트를 열어야 할 수 있습니다. 이제 리소스에 대한 네트워크 액세스를 활성화하는 방법과 리소스가 제3자에게 우발적으로 노출되는 것을 방지하는 방법을 알아봅니다. 인증 및 액세스 제어를 사용하여 리소스에서 관리하는 데이터를 보호하는 방법을 알아봅니다. Azure, cosmos DB 및 Azure 스토리지의 기본 연결은 전 세계에 대한 액세스를 가능하게 하는 것입니다. 온프레미스 네트워크, 인터넷 또는 Azure 가상 네트워크 내에서 이러한 서비스에 연결할 수 있습니다. 이 수준의 액세스는 위험해 보이지만 대부분의 Microsoft Azure 서비스에서는 액세스 인증을 허용하기 전에 인증을 요구하여 이러한 위험을 완화합니다. 이에 대해서는 이 단원의 뒷부분에서 설명합니다. Azure 가상 네트워크는 클라우드에 있는 사용자 자신의 네트워크를 표현한다는 점에 유의해야 합니다. 가상 네트워크를 사용하면 Microsoft 온-프레미스의 물리적 네트워크를 사용하는 것과 거의 같은 방식으로 가상 컴퓨터와 Azure 서비스를 함께 연결할 수 있습니다. Azure는 각 가상 네트워크가 다른 사용자가 만든 다른 가상 네트워크 및 인터넷으로부터 격리되도록 합니다. Microsoft Azure를 사용하면 가상 네트워크의 리소스에 액세스할 수 있는 실제 및 가상 컴퓨터와 서비스가 사용할 수 있는 포트를 지정할 수 있습니다. 연결을 제한하려면 서비스의 네트워킹 페이지를 사용해야 합니다. 연결을 제한하려면 선택한 네트워크를 선택합니다.가상 네트워크 섹션에는 가상 네트워크 방화벽 및 예외라는 레이블이 붙은 세 개의 섹션이 추가로 표시됩니다. 이 경우 서비스에 트래픽을 라우팅할 수 있는 가상 네트워크를 지정할 수 있습니다. 웹 응용 프로그램 및 가상 컴퓨터와 같은 항목을 만들 때 이러한 응용 프로그램 및 가상 컴퓨터가 허용된 네트워크 목록에 포함된 가상 네트워크의 리소스에 액세스해야 하는 경우 해당 항목을 가상 네트워크에 추가할 수 있습니다. 온프레미스 컴퓨터에서 서비스에 연결해야 하는 경우 방화벽 섹션에서 컴퓨터의 IP 주소를 추가합니다. 이 설정은 해당 주소의 트래픽이 서비스에 도달하도록 허용하는 방화벽 규칙을 만듭니다. 예외 설정을 통해 Azure 구독에서 만든 다른 모든 서비스에 대한 액세스를 활성화할 수 있습니다. 프라이빗 엔드포인트는 Azure Private Link를 통해 제공되는 서비스에 비공개로 안전하게 연결하는 네트워크 인터페이스이므로 자세한 내용은 이 강의 마지막 부분의 추가 자료에서 Azure 스토리지, 방화벽 및 가상 네트워크 구성을 참조하세요. 프라이빗 엔드포인트는 Vnet의 프라이빗 IP 주소를 사용하여 Vnet에 서비스를 효과적으로 제공합니다. 이 서비스는 Cosmos dB 속편 스토리지나 자체 사설 링크 서비스와 같은 Azure 서비스일 수 있습니다. 자세한 내용은 이 강의 마지막 부분에 있는 추가 자료에서 링크된 Azure 프라이빗 엔드포인트가 무엇인지 읽어보세요.서비스의 프라이빗 엔드포인트 연결 페이지에서는 서비스에 액세스할 수 있는 프라이빗 엔드포인트 (있는 경우) 를 지정할 수 있습니다. 이 페이지의 설정을 방화벽 및 가상 네트워크와 함께 사용할 수 있습니다. 2페이지는 사용자와 애플리케이션이 퍼블릭 엔드포인트에 액세스하여 Cosmos DB 계정에 연결하는 것을 완전히 차단합니다. 액세스 키를 포함한 많은 서비스는 서비스에 연결하려고 할 때 지정할 수 있습니다. 잘못된 키를 입력하면 Azure 저장소 계정의 액세스 키를 찾을 수 있는 액세스가 거부됩니다. 계정의 기본 페이지에 있는 해당 설정의 액세스 키를 선택합니다. 다른 많은 서비스를 통해 Azure Portal에서 동일한 방식으로 액세스 키를 볼 수 있습니다.키가 손상된 경우 새 액세스 키를 생성할 수 있습니다. 참고로 Azure 서비스는 실제로 키 1이라는 레이블이 붙은 키 두 개를 제공하며 응용 프로그램의 키는 두 키 중 하나를 사용하여 서비스에 연결할 수 있습니다.리소스의 액세스 키를 아는 모든 사용자 또는 애플리케이션은 해당 리소스에 연결할 수 있습니다. 하지만 액세스 키는 다소 세분화된 수준의 인증을 제공합니다. 또한 예를 들어 실수로 액세스 키를 공개한 후 액세스 키를 다시 생성해야 하는 경우 해당 키를 Active Directory 또는 Azure로 사용하여 연결하는 모든 응용 프로그램을 업데이트해야 할 수 있습니다. AD는 액세스 키 인증보다 뛰어난 보안과 사용 편의성을 제공합니다. Microsoft는 AD가 별도의 Azure 서비스이므로 액세스 키 사용에 내재된 잠재적 보안 취약성을 최소화하기 위해 가능하면 Azure AD 인증을 사용할 것을 권장합니다. Azure AD에서 관리하는 보안 도메인에 사용자 및 기타 보안 원칙 (예: 응용 프로그램) 을 추가합니다.이제 Microsoft Azure에서 인증이 작동하는 방식을 좀 더 자세히 살펴보겠습니다. 사용자 애플리케이션은 인증을 시도할 때 인증할 도메인을 AD로 지정합니다. 일반적으로 사용자나 애플리케이션은 자격 증명을 제공해야 하며, 신원을 증명하기 위한 비밀번호도 필요합니다. 암호를 도용한 부정 사용자가 인증을 받을 가능성을 줄이기 위해 다단계 인증을 구성할 수도 있습니다. 예를 들어, 사용자가 암호를 제공할 뿐만 아니라 인증 전에 모바일 장치로 전송되는 문자나 전화 메시지에 응답해야 하도록 지정할 수 있습니다. 인증에 성공하면 Azure AD는 보안 원칙이 인증된 후 사용자 또는 응용 프로그램에 대한 인증 토큰을 생성하여 리소스에 액세스를 시도할 수 있습니다. 인증 토큰은 요청의 일부로 서비스에 전달됩니다. 토큰은 서비스에서 지정된 리소스 Azure AD에 대한 액세스를 승인하는 데 사용됩니다. 리소스에 액세스할 수 있는 사용자 또는 대상을 지정할 수 있습니다. 액세스 제어는 사용자 애플리케이션이 인증된 후 리소스로 수행할 수 있는 작업을 정의합니다. 클라우드 리소스에 대한 액세스 관리는 클라우드를 사용하는 모든 조직의 중요한 기능입니다. Azure 역할 기반 액세스 제어 Azure OBAC를 사용하면 Azure 리소스에 액세스할 수 있는 사용자와 해당 리소스로 수행할 수 있는 작업을 관리할 수 있습니다. 예를 들어 OBAC를 사용하면 구독에서 한 사용자는 가상 컴퓨터를 관리하고 다른 사용자는 가상 네트워크를 관리하도록 허용하고, 데이터베이스 관리자 그룹은 구독에서 SQL 데이터베이스를 관리하도록 허용할 수 있습니다. 사용자가 가상 컴퓨터, 웹 사이트 및 서브넷과 같은 리소스 그룹의 모든 리소스를 관리하고 응용 프로그램이 리소스 그룹의 모든 리소스에 액세스할 수 있도록 허용합니다. Azure OBAC를 사용하여 리소스에 대한 액세스를 제어하고 역할 할당을 만들 수 있습니다. 역할 할당은 보안 원칙, 역할 정의 및 범위라는 세 가지 요소로 구성됩니다. 보안 원칙은 Azure 리소스에 대한 액세스를 요청하는 사용자 그룹 서비스 또는 관리형 ID를 나타내는 개체입니다. 종종 Roll로 약칭되는 역할 정의는 권한 모음입니다. 역할 정의에는 읽기, 쓰기, 삭제 등 수행할 수 있는 작업이 나열되어 있습니다. 역할에는 소유자와 같은 상위 수준 이름이나 가상 컴퓨터 판독기와 같은 특정 이름을 지정할 수 있습니다. Microsoft Azure에는 최소 권한 집합으로 시작하는 것을 포함하여 사용할 수 있는 여러 기본 역할이 포함되어 있습니다. 리소스 기여자가 모든 유형의 Azure 리소스를 만들고 관리할 수 있지만 다른 사용자에게 액세스 권한을 부여할 수는 없으므로 Reader는 기존 리소스를 볼 수 있습니다. 소유자는 다른 사람에게 액세스 권한을 위임할 권한을 포함하여 모든 리소스에 대한 전체 액세스 권한을 가집니다. 사용자 액세스 관리자를 사용하면 Azure 리소스에 대한 사용자 액세스를 관리할 수 있습니다.Microsoft 웹 사이트의 Azure 포털을 사용하여 Azure 사용자 지정 역할을 만들거나 업데이트할 수 있으므로 자세한 정보에 대한 사용자 지정 역할을 직접 만들 수도 있습니다. 범위에는 역할을 할당할 때 액세스가 적용되는 리소스 집합이 나열되며, 범위를 정의하여 허용되는 작업을 추가로 제한할 수 있습니다. 이는 예를 들어 한 리소스 그룹에만 해당하는 사용자를 웹 사이트 기여자로 지정하려는 경우에 유용합니다. 액세스 제어 또는 I am 페이지를 사용하여 Azure Portal의 리소스에 역할 할당을 추가합니다. 역할 할당 탭을 사용하면 역할의 리소스 액세스 수준을 정의하는 보안 원칙에 역할을 연결할 수 있습니다. 자세한 내용은 Azure Portal을 사용하여 역할 할당을 제거할 때 읽어보세요. 인증 및 권한 부여 외에도 많은 서비스가 보안을 통해 추가 보호를 제공합니다. 보안은 서비스 전반에 걸쳐 위협 보호 및 평가, 위협 방지, 보안 사고 추적 및 경고를 구현합니다. 이 인텔리전스는 서비스를 모니터링하고 서비스에서 관리하는 데이터에 해를 끼치거나 손상시킬 수 있는 비정상적인 활동 패턴을 텍스트로 전송합니다. 권장 사항은 잠재적 보안 취약성을 식별하고 이를 완화하기 위한 조치를 권장합니다. Azure Storage의 보안 페이지에서 보안 설정을 제어할 수 있습니다. Cosmos DB와 같은 다른 비관계형 서비스의 해당 페이지도 비슷합니다.

샘플 시나리오에서는 다음과 같은 데이터 저장소를 만들기로 결정했습니다:

• 재고 품목의 수량에 대한 정보를 저장하기 위한 Cosmos DB. 시간이 지남에 따라 재고 수준이 어떻게 변하는지 추적할 수 있도록 재고 수준에 대한 현재 및 과거 정보를 저장해야 합니다. 데이터는 매일 기록됩니다.
• 생산 및 품질 데이터를 저장하기 위한 데이터 레이크 저장소.
• 회사에서 제조하는 제품의 이미지를 저장하기 위한 블롭 컨테이너.
• 보고서 공유를 위한 파일 저장소.