🐳 Docker study 5th

지난주까지 우리는 로컬과 가상머신의 연결을 통해 Dockerfile, Image, Container를 관리하는 방법을 배웠다. 독특하게 Microsoft Azure은 가상연결 방식 외에도 ADLS2(Azure Data Lake Storage Gen2)라는 일명 데이터 저장소 플랫폼을 운영하고 있다.

사실 ADLS2? 공부하기 전까지 들어본 적도 없는 친구였다. 혹시 오늘의 포스팅을 들어가기 앞서 “ADLS2? 꼭 알아야 되나?😬” 라고 떠올릴 수도 있다. ‘Data Lake’라는 개념이 등장하면서 빅데이터 분석, 머신러닝, IoT, 엔터프라이즈 데이터 관리 등 실제 이 ADLS를 채택하고 있는 기업들이 많아진 것을 생각해봤을 때, Docker같은 가상화 기술을 공부하는 입장에서 이는 분명 시너지가 될 수 있다고 생각한다!

오늘은 이 ADLS2가 도대체 어떤 역할을 하고, 왜 우리가 알아두면 좋을지, 그리고 Docker와의 연계가 어떻게 이루어지는지에 대해 이야기 해보도록 한다!🚀

1. Connecting Azure Storage Account with Blobfuse

Azure Storage Account는 Microsoft Azure에서 제공하는 클라우드 기반 스토리지 서비스로 데이터를 안전하고 확장 가능하게 저장할 수 있는 공간을 제공하고 있다. 이 저장소는 다양한 종류의 데이터를 처리할 수 있어 기업이나 개발자들이 필요에 따라 원하는 데이터를 손쉽게 저장하고 관리할 수 있도록 돕는 플랫폼 정도로 이해하면 된다.

나는 그 중 특히 ‘Blob Storage’를 이용해 데이터를 저장해 두었는데 생각보다 되게 좋았던 점은 이미지, 스크립트파일(python, c, c++ etc.), 텍스트파일, 엑셀파일 등 진짜 어떤 데이터든 모두 올려두고 내가 가상환경에서 작업을 하던, 로컬에서 작업을 하던 원하는 데이터를 가져올 수 있다는 것이다. (앞으로는 가져온다는 개념을 마운트(mount)라고 정리할게요!) 그리고 참고로 아직은 무엇인지 잘 감이 안잡히는 이 ‘Blob Storage’에 ‘Data Lake’ 기능을 추가해 만들어진 것이 바로 이번 포스팅의 키워드, ADLS인 것이다!

그럼 지금부터 단계별로 어떻게 Storage Account를 생성하고 가상환경과 연동할 수 있는지 이어서 이야기해보록 하겠다!

1.1 Creating a Storage Account

가장 먼저 해야 할 일은 Azure에서 Storage Account를 만드는 것이다. 아래 사진을 보면 500TB까지 데이터를 저장할 수 있다고 하니 웬만한 빅데이터 프로젝트를 사용하는데는 큰 무리가 없을 것 같다.

Storage Account를 초기 생성할 때 아래 사진처럼 세부적인 조건들을 설정할 수 있다. 나는 ‘kaggleaccountsh’라는 이름으로 생성해 주었다.

하단의 Review + create를 누르면 다음 페이지로 넘어가게 되고 해당 storage 접근 방식도 선택이 가능하고 나는 key 방식으로 선택해주었다. 여기서 한가지 중요한 포인트는 바로 Enable hierarchical namespace를 활성화 해주는 것이다. 이 옵션의 활성화 여부는 정확히 어떤 스토리지가 필요한지에 따라 다를 수 있지만, 대부분의 경우 스토리지 생성 과정에서 이 옵션을 선택해 주는 것이 일반적이다!

그 이유에 대해서 이해하고자 한다면 머릿속에 흩어져있는 여러 개념들을 선정리하고 가야한다. Blob Storage 부터 시작해보도록 한다!

🗂️ Blob Storage

#기본 중의 기본

Blob Storage는 비정형 데이터(이미지, 동영상, 로그 파일 등)를 저장하는 Azure의 기본 스토리지 서비스이다가장 큰 특징은 간단하고 확장 가능하다는 점인데, 데이터가 많아지더라도 언제든 쉽게 확장할 수 있고 여러 클라우드 서비스와도 잘 연동된다. 단순한 구조와 더불어 확장가능성이 가장 큰 메리트이지만 오히려 이 장점으로 인해 대규모 데이터를 관리할 때는 적합하지 않다.

쉽게 설명해보면 이렇다. 만약 내가 특정 파일이 필요하다면 바로 해당 파일에 접근할 수 없고 맨 처음부터 하나씩 하나씩 그 파일을 찾으러 나서야 된다는 말이다. 그래서 Hierarchical Namespace 개념이 등장하게 된 것이고. 대규모의 데이터를 다루는 프로젝트라면 확장성의 강점인 Blob Storage에 이 Hierarchical Namespace 옵션을 추가해 사용해주면 된다.

🗂️ Hierarchical Namespace

#깔끔한 데이터 관리의 비결

Hierarchical Namespace(계층적 네임스페이스)는 말 그대로 데이터를 계층적인 폴더 구조로 정리해서 저장할 수 있는 기능이다. 컴퓨터 파일 시스템처럼 폴더를 만들어 그 안에 여러 파일들을 정리해 두는 것처럼 스토리지 공간 안에서도 폴더(여기서는 Container라고 부름. 단, 도커의 가상환경 Container와 이름만 똑같고 기능은 완전히 다름!)를 통해 데이터를 정리할 수 있다. 위에서 대부분의 경우 스토리지 생성 과정에서 해당 옵션을 선택한다고 했는데, 이게 왜 그럴까?

일반적인 Blob Storage에서는 파일들이 평면적인 구조로 저장됩니다. 이게 무슨 뜻이냐 하면 파일이 계층적인 폴더 구조로 저장되는 것이 아니라 파일 경로가 그저 하나의 문자열처럼 처리된다는 말이다. 예를 들어 /dockercourse/python/run.py라는 경로를 보면 python이 폴더처럼 보일 수 있지만, Blob Storage에서는 실제로 폴더가 아니다! 이 경로 전체가 파일 이름의 일부일 뿐, python이라는 디렉토리 자체가 존재하는 것은 아닌 점을 이해해야 한다.

위에서 언그한 것처럼 우리는 Hierarchical Namespace를 사용해 Blob Storge를 ADLS2처럼 폴더 구조로 관리할 수 있다. 아래 사진처럼 Microsoft Azure Storage Explorer을 이용해 시각적으로 폴더의 구조를 확인해 볼 수 있다. mounteddrive 폴더가 바로 Hierarchical Namespace를 활용해 만들어진 폴더인 것이다!

🗂️ ADLS2

#클라우드 스토리지의 게임 체인저 #자율주행 프로젝트

만약 우리가 한 자동차 회사의 자율주행 프로젝트를 진행하게 되었다고 생각해보자. 그 때 발생할 수 있는 가장 큰 고민은 무엇일까? 내가 생각하기에는 데이터 관리와 그에 따른 클라우드의 비용의 효율성, 이 두 가지일 것 같다.

자율주행 프로젝트처럼 대규모 데이터를 다루고 비용 관리와 데이터 보안까지 신경써야 되는 분야는 없다고 생각한다. 차량에서 수집되는 대용량의 센서 데이터, 비디오 스트림, 주행 기록 등을 효율적으로 저장하고 관리해야 하기 때문에 이를 확장 가능한 스토리지로 관리할 절대적인 필요가 있기 때문이다. 그런데 ADLS2 (Azure Data Lake Storage Gen2)는 이 두 가지 문제의 솔루션을 제공하고 있다.

ADLS2는 마치 자율주행 시스템의 정돈된 도로와 같다. Hierarchical Namespace 기능을 통해 수집된 데이터를 마치 도로 위의 교통 흐름처럼 체계적으로 저장할 수 있기 때문이다. 자율주행에서 다루는 데이터는 비디오 피드, 라이다(LiDAR) 데이터, 센서 값 등 매우 다양한데, ADLS2는 이 데이터를 폴더 기반으로 정리해 마치 도로 구역을 나누듯 데이터를 분류하고 체계적으로 관리할 수 있다.

기존의 방식에서는 데이터를 한 곳에 평면적으로 쌓아두어 찾는 데 시간이 걸렸다면 ADLS2는 계층적 폴더 구조 덕분에 데이터를 쉽게 검색하고 관리할 수 있어 폴더를 찾는 시간 절약을 기대할 수 있다.

자율주행 프로젝트에서는 어떤 한 팀은 센서 데이터를 처리하고 다른 팀은 비디오 피드를 분석하는 것처럼 여러 팀이 동시에 작업을 진행한다. 하지만 분명한 건 모든 팀이 모든 데이터에 접근할 필요는 없다! ADLS2는 ‘Granular Access Control’ 기능을 통해 특정 데이터에 대한 접근 권한을 조절할 수 있다.

센서 데이터를 다루는 팀은 그 데이터에만 접근할 수 있고 비디오 데이터를 처리하는 팀은 해당 영역에만 접근하도록 설정해 데이터 보안이 강화되고 팀별로 필요한 정보만을 사용하게 되어 효율적인 협업이 가능해질 수 있다.

자율주행은 실시간으로 데이터를 처리해야 하는 만큼 언제든 데이터가 급증할 수 있어 저장 용량을 미리 예측하기 어려울 때가 많다. 기존 방식에서는 용량을 크게 설정해두고 사용하지 않은 공간에 대해서도 비용을 지불해야 했지만 ADLS2는 사용한 만큼만 비용을 지불하면 된다.

초기에는 비디오 데이터와 센서 데이터를 적게 수집하다가 차량 테스트가 진행되면서 데이터가 급격히 증가할 수도 있는데, 이럴 때 즉각적으로 스토리지의 추가 공간을 확보해 유동적으로 대응할 수 있다. 필요할 때만 스토리지를 확장해서 사용하면 되니 자율주행 프로젝트와 같은 대규모 데이터 처리 환경에서 비용 효율성이 크게 향상 될 수 있다!

다시 storage account 생성으로 돌아와 이야기를 이어나가보도록 하겠다. 최종적으로 생성 작업이 끝나면 아래와 같이 Storage accounts에 내가 만든 컨테이너가 생성됨을 확인할 수 있을 것이다. 그리고 다음 작업이 이 컨테이너 안에 위에서 정리한 Hierarchical Namespace 기능을 이용해 폴더들을 만들 수 있다.

나는 mountedrive라는 이름으로 폴더를 생성해 주었고, 실제로 로컬의 텍스트 파일을 해당 폴더에 업로드해주었다.

1.2 Connecting a Storage Account to a Virtual Machine

Blob Storage를 가상머신과 연결하기 위해서는 크게 세 단계가 필요하다.

1️⃣ 마이크로소프트에서 제공하고 있는 패키지를 설치해 주면 된다. 참고로 나는 Ubuntu 패키지(코드 참고 👉Configure the Microsoft package repository)로 진행했다.

그 전에 먼저 cat /etc/os-release 로 연동하고자 하는 가상머신의 운영체제를 확인해 주었다. 보면 나의 가상머신은 Ubuntu 22.04 버전으로 나온다. 이후 sudo wget https://packages.microsoft.com/config/ubuntu/<VERSION_ID 넣기>/packages-microsoft-prod.deb 로 패키지를 설치해주면 된다!

이어서 아래 코드를 각각 실행해주면 기본적인 패키지 설치는 완료된다.

sudo dpkg -i packages-microsoft-prod.deb , sudo apt-get update

2️⃣ 이후 가상머신에 Storage Account에 접근할 수 있는 권한을 부여해 주었다. mkdir mycontainer, mkdir blobfuse 로 먼저 폴더를 생성했고 이후 /blobfuse/ 하위 경로에 blobfuse.cfg 파일을 생성해 주었다.

blobfuse.cfg 파일은 Blob Storage에 연결하기 위해 필요한 설정 파일이다. 따라서 이 파일 안에 Storage Account와 Container에 접근할 수 있는 정보들을 담아 권한을 부여할 수 있다! ( 코드참고 👉 Authorize access to your storage account)

Storage Account 이름, 키, 컨테이너 이름을 설정해 주면 된다. 마지막 줄은 key 방식으로 인증한다는 뜻이니 수정할 필요가 없다. 두번째 account key같은 경우에는 Azure 에서 Storage accounts > 생성한 storage 로 접근 후 Security +networking > Access keys 카테고리에서 확인 가능하다. 보면 key 1,2가 있는데 첫번째 파랑색 줄로 표시해 놓은 키를 복사해서 nano 편집기에 붙여 넣으면 된다.

3️⃣ nano 편집기로 파일을 잘 저장 후 blobfuse 를 사용하여 Blob Storage를 로컬 파일 시스템에 마운트 해주었다. 해당 명령어는 아래 명령어를 참고하면 된다!

blobfuse <Blob Storage를 마운트할 로컬 경로> --tmp-path=<blobfuse가 사용할 임시 저장 경로> --config-file=/<위에서 생성한 nano.cfg 파일 경로>

앞의 세 단계를 무사히 진행했다면 가상머신에서도 ‘ADSL2 파일 업로드 실습 중 .txt’ 라는 폴더를 확인할 수 있다. 이 파일은 우리가 앞서 Azure Storage Account > mounteddrive 폴더에 업로드 해둔 파일이다! 연동이 최종적으로 잘 되었다! 😆

2. Using Azure Storage Explorer

Azure Storage Explorer를 사용하면 클라우드 스토리지 관리를 GUI를 통해 더 쉽게 컨트롤할 수 있다. 나는 맥북을 사용하기에 macOS arm64로 설치해 주었다. 윈도우, 리눅스도 있으니 본인의 로컬 운영체제에 맞게 설치해 주면 된다. 설치 방법은 쉬우니 천천히 하면 큰 어려움 없이 진행될 것이다. 아래는 설치 후 초기 화면이다!

<1.2 Connecting a Storage Account to a Virtual Machine> 에서는 Storage Account와 가상머신 간의 연동을 진행했었다. 이번에는 이 Azure Storage Explorer와 Storage Account간의 연동을 해보았다. Explorer 연동 방식은 1️⃣ KEY 방식, 2️⃣ SAS(Shared Access Signature) 방식, 3️⃣ RBAC(Role Based Access Control) 방식 총 세가지로 진행했다.(사실 더 많다! 👉 Authorization mechanisms)

‘연동하는데 꼭 세가지나 알아야 되나?’ 라고 생각할 수 있다. 이해한다. 나역시 일단 하나라도 정확히 알자 주의니까 말이다. 그럼에도 불구하고 세가지 방식을 모두 소개하는 이유는 각각의 방식들이 가진 장단점이 명확하기 때문이다. 내가 어떤 환경환경에서 Storage Account를 사용하게 될지 사실 아무도 모른다. 데이터 권한 문제도 있을 수 있고, 보안 문제, 어쩌면 최대한 빨리 이 데이터를 다른 팀에 넘겨야 하는 시간 문제도 있을 수 있다. 그러니 무조건 하나의 방법만 고집하는 것보다는 여러 방식을 알아두고 상황에 맞게 유연하게 대처하는 것이 더 센스있는 개발자가 되는 길이 아닐까?

2.1 Key

첫번째는 1️⃣ KEY 방식이다. 말 그대로 Storage 계정의 Access key를 사용하여 연결하는 방식으로 키를 사용하면 해당 스토리지 계정에 대해 전체 권한을 부여 받을 수 있다. 이 방식의 최대 장점은 빠르고 간단하다는 것이다. 어느 환경에서든 해당 스토리지의 키만 알고 있다면 누구든 접근할 수 있다. 하지만 이 방식에는 보안 리스크가 따른다. Access Key와 스토리지 계정이 일대일로 대응되기 때문에 키가 유출될 경우 계정 전체의 보안이 위험해질 수 있다.

그렇다면 장점보다 단점이 더 커보이는 이 방식을 그럼 대체 왜 사용하는 걸까? 주로 테스트나 개발 환경처럼 시간 효율성이 중요한 경우 유용하기 때문이다. 분명 빠르게 연결이 필요한 상황에서는 유리하지만, 생산 환경에서는 권장되지 않는 방식이다. 그러니 보안이 중요한 곳에서는 다른 방식을 선택하면 된다!

연동 방법도 꽤 간단한 편이다. 아래 사진처럼 원하는 Storage Account를 우클릭(Connect to Azure Storage) 하면 팝업창이 뜨는데 ‘Storage account or service’ 옵션을 선택해주면 된다.

연결 방식은 당연히 ‘Connection string(Key or SAS)’를 선택해 주면 된다.

그러면 ‘Connecting String’ 키를 입력하라는 팝업이 뜨게 되는데, 해당 키는 아래 사진을 참고해 붙여 넣어주면 된다! 참고로 Display name은 키를 입력하면 자동 생성되니 사용자가 원하는대로 수정해 주면 된다.

👇 summary(Key)

• Description : Storage Account에 대한 권한 접근.
• Pros: 빠르고 간단하게 설정할 수 있음. 키만 있으면 어느 환경에서든 스토리지에 접근 가능함!
• Cons: 보안 위험이 큼. Access Key가 전체 Storage 계정과 직접 연결되어 있어 키가 유출되면 계정 전체가 위험해질 수 있음.
• When to Use? : 테스트나 개발 환경에서 빠르게 연결이 필요할 때 유용하지만 그외(운영)의 환경에서는 권장되지 않음.

2.2 SAS

2️⃣ SAS(Shared Access Signature)은 토큰을 이용해 Storage Account 전체가 아닌 내부의 폴더 즉 Container 별로 제한된 접근을 허용하는 방식이다. 특정 Container에 대해 읽기, 쓰기 등의 수정 여부를 지정해줄 수 있어 꽤 유용하게 사용된다. 효율성 측면에서도 좋은 것 뿐만 아니라 당연히 Key 방식과 달리 Container 하나하나를 원하는 대로 제어할 수 있어 보안성 측면에서 훨씬 안전한 것이 사실이다. 단점은 토큰의 특성 상 기간 만료를 신경 써야 하지만 보안 측면의 장점이 더 커보이는 것 같다.

아래는 ‘mounteddrive2’라는 새로운 Container를 만들어 SAS 방식을 실습해 본 사진이다. Settomgs > Shared access tockens 카테고리로 들어가면 토큰의 기간을 지정해 줄 수 있다. 만약 회사 외부 파트너 혹은 임시 테스트 프로그램 상 일부 데이터에 접근해야 할 필요가 있을 때, 그 때 상황에 맞게 일시적으로 권한을 부여해 주는 방식으로 사용된다. (해당 페이지 하단의 ‘Blob SAS URL’로 연결 진행!)

Azure Storage Explorer에서는 ‘ADLS Gen2 container or directory’ 옵션을 선택해주면 된다.

이후에 나오는 ‘Enter Connection Innfo’ 페이지의 경우에는 ‘Blob SAS URL’을 복사해서 그대로 붙여 넣어주었다.

아래 사진으로 Key 방식과 SAS 방식의 차이점을 쉽게 이해할 수 있다. 컨테이너 별 우측에 괄호로 어떤 방식으로 연결되었는지 표시가 되어있긴 하지만, 폴더 구조 측면에서 보면 SAS의 경우 Storage Account/Blob Container/mounteddrive2 로 연동되어 있고 Key의 경우 Storage Account/kaggleaccountsh/Blob Containers 경로로 접근 되었음을 확인 할 수 있다.

추가로 토큰을 이용한 SAS 연결 방식에서 꽤 신기한 점도 배웠다. 바로 웹에서 컨테이너 내 파일을 확인할 수 있는 방식으로 아래 웹 주소를 이용하면 된다!

✅ https://Storage account.blob.core.windows.net/container/folder/file?Blob SAS token

지금 보면 mounteddrive2/testdrive/connect with token feat.SAS.txt 경로로 텍스트 파일이 위치해 있다.

본인의 Storage, Container 경로에 맞게 주소를 수정해서 실행하면 신기하게도 웹에서 해당 파일을 직접 확인 할 수 있다. (나는 이 부분이 꽤 신기했다. 그리고 엄청 유용하게 쓰일 수도 있을 거라 생각한다! 😲 )

✅ https://kaggleaccountsh.blob.core.windows.net/mounteddrive2/testdrive/connect with token feat.SAS.txt?Blob SAS token

👇 summary(SAS)

• Description : Storage Account 내 Container에 대한 권한 접근.
• Pros: 권한 기간을 제어할 수 있어 key 방식보다 더 안전함.
• Cons: SAS 토큰이 만료되면 새로 발급해야 함.
• When to Use? : 특정 사용자 프로그램이 제한된 리소스에 일시적으로 접근해야 할 때 유용함!

2.3 RBAC

3️⃣ RBAC(Role Based Access Control)은 이름은 어려워 보이는데 사실 세 가지 방식 중에서 아마 가장 익숙한 방식일 것이다. 구글 드라이브를 사용해 본적이 있다면 더욱 쉽게 이해가 가능한데, 특정 데이터(폴더, 컨테이너, 드라이브)에 특정 사용자만이 권한을 부여 받는 방식이다.

문서에는 ‘Azure AD의 역할 기반 권한 관리’ 이정도로 정의되고 있는데, ‘Azure AD(Azure Active Directory)’는 회사 내 모든 사용자와 리소스에 대한 권한을 중앙에서 관리하는 도구라고 생각하면 된다. 이를 통해 각 사용자나 그룹에 필요한 권한만 부여할 수 있게 되고 역할별로 관리할 수 있게 된다. 예를 들어 회사 내에서 어떤 사람은 데이터에 읽기만 할 수 있게 하고 어떤 사람은 쓰기나 수정 권한까지 가지게 할 수 있을 것이다!

중앙 관리 방식의 큰 장점은 일관된 보안 정책을 유지하면서도 빠르게 권한을 조정할 수 있다는 것인데 만약 새로운 팀원이 들어오면 해당 역할에 맞는 권한만 한 번에 할당할 수 있고 또 팀을 옮기거나 퇴사할 때도 권한을 바로 회수할 수 있어 앞선 Key, SAS의 장점을 합쳐 놓은 것 같다는 생각이 든다.

일단 이 RBAC 방식을 사용하기 위해서는 Microsoft Entra ID 카테고리에서 유저를 등록해 주어야 한다.

‘DataEngineer’라는 이름으로 유저를 하나 생성해 주었고 패스워드도 설정해 주었다.(추후 변경 가능)

이후 접근을 필요로 하는 컨테이너로 들어가 Access Control(IAM) > +ADD > Storage Blob Data Contributor > +select memerbers 순서대로 진행하면 된다. (아래 사진 참고!)

최종적으로 확인해 보면 DataEngineer라는 새로운 유저에게 해당 컨테이너에 대한 권한(Role)이 부여된 것을 확인 할 수 있다. 이런 방식으로 다른 유저들 혹은 그룹들에게도 권한을 부여하면 된다!

권한 부여가 완료 되었으니 Azure Storage Explorer에서도 잘 작동하는지 확인해보도록 하자. 새로 등록한 유저로 로그인하게 되면 OAuth와 관련해서 OTP를 요구할 수 있는데 본인이 원하는 것으로 진행해주면 된다. (나는 Google OTP로 진행했다!) “Authenticated. You can return to Storage Explorer” 문구가 뜨면 제대로 진행된 것이니 참고하면 좋겠다!

이후 Azure Storage Explorer에서 앞선 방식과 유사하게 진행해주면 된다. (하단 사진 참고!)

이후 접속에 필요한 URL은 해당 컨테이너의 Properties 카테고리에서 확인 가능하다!

👇 summary(RBAC)

• Description : Azure AD의 역할 기반 권한 관리를 통해 스토리지 계정에 대한 접근을 제어함. 사용자는 할당된 역할에 따라 필요한 권한만 가지게 됨!
• Pros: Azure AD를 통해 중앙 관리가 가능하고 세부적인 권한 설정이 가능함. 조직 차원에서 관리하는 데 유용함.
• Cons: 관련 설정이 복잡함.
• When to Use? : 여러 사용자가 있는 환경에서 각 사용자나 그룹의 접근 권한을 관리할 때 유용함.

이번 주차는 폴더를 관리하는 측면에서 특히 권한에 대해 다루었다. 종류도 다양하고 덕분에 포스팅 양도 상대적으로 길었던 것 같다. 처음 강의를 듣고 공부할때는 ‘이게 내가 지금 이해한게 맞나? ㅎㅎ..’ 라고 생각이 들 정도로 꽤 난해 하다고 느꼈다. 아마 이 내용을 처음 접해본 사람이라면 나와 비슷하게 느낄 거라고 생각한다. 혹시 조금이라도 애매 하다고 느낀다면 오늘의 글을 처음부터 다시 읽어보길 바란다! 나도 글로 정리해보니 그제야 정리와 함께 이해가 되었기 때문이다. 아마 익숙함의 문제인 것 같다.

Microsoft에서 ‘Identity and Access Administrator Associate’ 라는 역량 검증 인증서도 발급하고 있는 것 같다. 나 역시 생각보다 이쪽에 흥미를 느끼는 것 같은데 겨울방학에 한번 도전해 볼까 생각이 든다!✌️

Reference

Azure Data Lake (ADL) Gen 2 Implementation Best Practices

How to mount Azure Blob Storage as a file system with BlobFuse v1

Azure Storage Explorer in Desktop

Microsoft Certified: Identity and Access Administrator Associate

Access control model in Azure Data Lake Storage