데이터를 클라우드로 백업하는 솔루션은 이미 유행이 되었다. 그 이유는 비용 절감과 신속하게 데이터를 처리할 수 있는 클라우드의 매력 때문이다. 이전 포스팅에서 Azure File 에 대해서 자세히 다루어보았다. 오늘 포스팅은 Azure Blob 에 대해서 다뤄보려고 한다.
Azure File Share의 이전 포스팅은 아래 링크를 참조하기 바란다.
2022.05.31 - [미국 IT 이야기] - Azure File Share을 이용한 Network File Share 비용 절감
Azure File Share을 이용한 Network File Share 비용 절감
Azure File Share는 기존 Network File Share (SMB)을 클라우드로 옮기면서 동시에 비용 절감을 할 수 있는 대표적인 Microsoft Azure의 서비스이다. 클라우드의 장점중 하나는 바로 기존 인프라를 사용하지 않
washington.doniq.net
Azure Blob Storage와 Azure File Storage는 사용 목적이 다르다. 이것을 정확하게 이용하면, 어떤 경우에 Azure file 혹은 Azure blob을 사용해야 되는지 쉽게 구별할 수 있다. Azure File은 다른 Application과 연동없이 독립적으로 사용할 수 있다. 아마도 Network File Share (SMB)가 가장 큰 Azure File을 사용하는 목적일 것이다. 물론 백업 솔루션에도 Azure File이 사용된다. 반면 Azure Blob은 다른 백업 어플리케이션과 연동해서 사용되는 경우가 아주 흔하다. 즉, Blob 혼자만으로도 저장 공간으로 사용될 수 있지만, 다른 앱과 연동이 되어서 사용된다고 쉽게 생각하면 된다.
예를들어 보자. SQL 데이터를 백업할 경우, Redgate라는 어플리케이션이 자주 사용된다. RedGate 어플리케이션은 SQL DB을 로컬에 백업한 후, Azure Blob 으로 업로드 하는 솔루션이다. Virtual Machine을 클라우드로 백업할 경우, Veeam 이라는 어플리케이션을 사용할 수 있다. 이 Veeam 이라는 어플리케이션을 또한 SQL DB 백업 앱인 RedGate처럼 로컬에 일단 백업을 한 후, Azure Blob 으로 업로드하는 형식이다. 즉 데이터를 한번에 직접 Blob storage로 업로드하는 형식이 아닌, 로컬에 일단 백업을 하고, 이를 Blob storage로 옮기는 방식이 대부분의 솔루션들의 구현 방법이다. 이것이 Azure File가 가장 큰 차이가 있는 부분이다. 또한 Blob storage를 사용하는 이유는 Azure File에 비해서 비용면에서 더 저렴하기 때문이다.
Azure File과 Azure Blob을 Apple to Apple로 비교하기는 어렵지만, 간단히 1TB의 용량을 클라우드에서 사용한다고 가정할 경우 Azure File (Hot performance)의 경우 한달에 약 $87 정도가 들어가는 반면, Azure Blob일 경우 (Hot Tier) $21 정도가 예상되어진다. 즉, 비용 측면에서 Blob storage를 사용할 수 있는 경우라면 당연 Azure File 대신 Blob을 사용해야 할 것이다. 회사마다 File Retension Policy가 다르겠지만, 보통의 경우 10년 정도가 파일들을 지우지 않고 보관해야 할 기간이라고 할 경우, 이러한 파일들은 Azure Blob Storage에 저장함으로써 비용 절감을 할 수도 있다.
이외에도 Azure Table, Queue, SharePoint Online, OneDrive의 장,단점을 정확하게 이해할 경우, 최적의 성능과 비용 절감을 동시에 할 수 있다. 아래는 Azure Price Calcuator의 스크린샷이며, 이것을 이용해서 다른 Storage Solution등을 손쉽게 비교하며, 비용 예상을 할 수 있다.
이제부터 Azure Blob Storage를 어떻게 만드는지 Step by Step으로 알아보도록 하자.
1. Storage Account 만들기. Subscription, Resource Group, Storage Account Name, Region 을 설정한다. Performance는 Standard와 Premium이 있는데, Blob Storage의 경우 대부분 Standard을 선택하여서 비용 절감을 노릴 것이다. Redundancy에 관한 내용은 Azure File에서 자세히 설명했지만, 간단히 다시 설명하자면, 예상치 못한 장애가 발생했을 때, 동일한 데이터가 다른 Region에서도 접근할 수 있도록 옵션을 설정하는 것이다. 위에서 언급했지만, Blob을 사용하여 데이터를 클라우드로 백업할 경우 일단 로컬에 백업을 한 후에 Cloud로 올리는 형식이기에, 클라우드에 장애가 생겨도 로컬에 데이터가 있기에 LRS (Locally Redundant Storage)가 가장 적합할 것이다.
2. Security 설정하기. Blob storage가 인터넷에서 접속이 가능하게 하려면 Enable blob public access을 선택하면 된다. 만일 ExpressRoute 혹은 VPN으로 접속을 할 경우에는 외부로부터 접속을 차단하는 것이 바람직하다. Storage Account Key로 Blob storage에 접근할 경우 "Enable storage account key access"을 설정한다. SQL backup application의 경우 access key를 사용하기 때문에 이 기능을 활성화 해주어야 한다. 반면에 Veeam과 같은 VM backup의 경우에는 access key를 사용하지 않기 때문에 필요하지 않다. Access Key를 사용하지 않는 경우에는 이 기능을 꼭 disable 해주는 것이 외부 침입을 최소화할 수 있다.
Default to Azure Active Directory authorization in the Azure portal을 활성화 시켜주면, Portal 에 접속했을 때 자동으로 해당 어카운트의 RBAC (Role Based Access Control)이 적용되어서 권한이 있는 Resource만 접근을 할 수 있게 된다. 이 경우에는 Blob의 권한이 없을 경우에는 해당 user는 azure portal에서 조차 접근이 불가능하게 된다.
Minimum TLS version은 1.2 이며 (TLS 1.1은 이미 보안에 취약하여서 더 이상 사용해서는 안되는 버전이다), 마지막으로 Access Tier는 Hot과 Cool 중에 Cool을 선택한다. Hot은 일반적으로 백업한 데이터를 자주 복구하거나 액세스할 때 사용하며, Cool은 반대로 백업을 하고 난후, 필요해서 복구할 때가 아니면 데이터 접근이 불필요할 경우에 사용한다. Hot과 Cool의 테크니컬 성능은 동일하다. 즉, Hot Access Tier라고 해서 Cool 보다 더 빠른 속도의 저장 공간이 아니다. 단지 비용의 차이가 있기에 해당 Blob을 어떤식으로 사용할 지 (자주 접근, 혹은 간혹 접근)에 따라서 결정해주면 된다.
- Hot: Frequently accessed data and day-to-day usage scenarios (파일을 자주 수정하거나, 업데이트할 경우)
- Cool: Infrequently accessed data and backup scenarios (파일을 업데이트 한후, 자주 수정하지 않아도 되는 경우)
3. 네트워킹 설정하기. 인터넷으로 Blob을 액세스하기 위해서는 "Enable public access from all networks" 를 선택하고, Azure ExpressRoute 혹은 Azure IPsec Tunnel VPN을 이용하여 Blob를 접근할 경우에는 "Disable public access and use private access"를 선택하면 된다. 또한 미리 선택한 IP만 선별하여서 인터넷으로 접속할 수 있는 옵션도 있다 (Enable public access from selected virtual networks and IP addresses" Network routing은 Microsoft endpoint service (예를 들면, Azure SQL)를 Storage Account가 접속할 때 어떤 네트워크를 사용하는 지를 선택하는 것이다. 이를 위해서 Microsoft network routing을 추천한다.
4. Data Protection 설정하기. 첫번째 옵션은 Recovery (복구)에 관한 것이다. 아래와 같이 "Enable soft delete for blobs"을 선택하고 30일이라고 지정하면, blob를 실수로 삭제했을 경우 30일간은 복구가 가능하다는 의미이다. 마찬가지로 "Enable soft delete for containers" 30일은 container를 실수로 삭제했을 경우 30일간은 복구가 가능하다는 의미이다. 참고로 Blob storage가 Container의 상위 개념이다. 즉, blob 안에 container들이 존재하는 것이다. 한가지 명심해야 할 것은 blob 혹은 container를 삭제하여 복구했을 시에는 backup 된 것들은 자동으로 영구 삭제된다. 즉, blob와 container의 복구는 가능하나, 이들의 backup까지 복구할 수는 없다
Tracking 기능중 "Enable blob change feed"를 선택할 경우, 해당 blob에서 일어나는 모든 로그를 저장할 수 있다. "Enable versioning for blobs"은 사용하기에 따라서 아주 좋은 기능이 될 수 있다. 예를들어, VM을 백업할 경우, 백업한 파일 이름이 항상 동일할 경우 (예를들어 WebVM1), Version control이 가능하다. 즉 파일 이름은 동일하나, 백업할 내용이 다른 경우 "Enable versining for blobs"을 사용하면 바뀐 백업 내용도 Version별로 보관을 할 수 있다. 하지만, 백업을 하는 어플리케이션 자체에서 (예를들어 SQL 백업의 경우 Redgate, VM의 경우 Veeam) 파일 이름을 다르게 생성할 경우 (예를들어 WebVM1_YYYYMMDD)에는 이 기능이 필요하지 않는다. 왜냐하면 파일명이 다르기에 Version을 구지 control 하지 않아도 되기 때문이다.
5. Encryption 설정하기. Encryption은 MMK (Microsoft-Managed Keys)와 CMK (Customer-Managed Keys)가 있다. 결국 중요한 Key를 마이크로소프트에서 가지고 있을 것인지 아니면 고객이 소지하고 있을지 결정하는 것이다. 만약 SafeKey와 같은 Key들을 안전하게 보관하는 장소가 이미 있을 경우에는 CMK를 선택해도 되지만, 많은 경우 이러한 Key Vault을 따로 가지고 있지 않기에, MMK를 선택해준다. 참고로 "Enable infrastructure encryption"은 선택하면 Storage 에 한번 Encryption하는 것을 Infrastructure level에서 한번 더 Encryption을 해주는 것이다. 즉 이중으로 Encryption을 해서 더 안전하게 데이터를 보관할 때 사용하는 추가 기능이다.
6. Container 만들기. 위의 과정을 모두 마치면 Azure Blob Storage 를 생성할 수 있다. 이제 생성한 Storage Account을 선택하고 Container를 선택하면 아래와 같은 화면이 나온다. 위에서 설명했지만, Blob는 Container의 상위 개념이다. 즉, Blob storage가 만들어졌지만, 그 안에 Container 형태로 저장이 되는 것이다. 그렇기 때문에 여기서 Container를 생성해준다. Container를 생성할 때 public access level을 선택해준다. 만약 스텝 5에서 No public access를 선택했을 경우에는 아래의 스크린 샷처럼 private access only로 자동 선택 될 것이다. 만약 Internet을 통해서 blob storage를 access할 경우 여기에서 public access level을 조정해준다.
7. RBAC (Role Based Access Control) 조정하기. 많은 경우, Infrastructure 팀과 DBA 팀은 분리되어 있을 것이다. DBA 팀은 데이터를 백업하기 위해서 필요한 저장 공간을 Infrastructure팀에게 요청할 것이다. 즉, DBA 팀은 Infrastructure 팀에게 단순히 저장 공간만을 할당 받을 뿐이지, 저장 공간 자체의 설정은 할 필요가 없었다. 하지만, Cloud도 저장공간이 바뀌어지면서 이러한 구분선이 없어졌다. 만약 DBA 팀에서 Cloud의 Storage Account까지 관리할 경우에는 아래의 RBAC 조정이 필요하지 않을 것이다. 왜냐하면 DBA 팀 자체가 Storage Account Owner 혹은 Contributor 일 가능성이 높기때문이다. 하지만, Infrastrubture 팀과 같이 Resource를 따로 관리하는 팀이 있을 경우에는 Storage Account의 RBAC을 잘 설정해야지 불필요한 Access를 DBA 팀에게 주지 않을 수 있다.
DBA에게 필요한 Access는 Storage Account Reader 와 Storage Blob Data Contributor 가 보통의 RBAC 셋업이다. 즉 데이터 자체의 Write/Read/Execute는 Blob 레벨이기에 Blob Data Contributor Role이 필요하고, 그 이외의 셋업인 시큐리티, 네트워크, 백업, RBAC 등은 Infrastructure 팀이 관리하는 구조이다
이제 Blob storage 안에 Container까지 생성했기 때문에 RedGate 혹은 Veeam과 같은 어플리케이션을 통해서 Azure Blob Storage 백업이 가능한 상태가 되었다.
Azure Storage Explorer 사용해보기
만약에 Application으로 생성한 Blob Storage를 테스트할 여건이 안될 경우에는 Azure Storage Explorer를 사용하여서 해당 Storage account > Blob container > container 가 접속이 잘 되는 지 확인할 수 있다. 스텝 7에서 Blob data contributor의 롤을 부여했기 때문에 Blob Containers 아래에 새로운 Container를 만들 수 있고, 그리고 파일 업로드까지 된다면 Azure Blob Storage에 대한 모든 설정이 끝난 것이다.
Azure Blob Storage 에 대한 결론
Microsoft의 Blob, AWS의 S3와 같은 Storage는 이제 피해갈 수 없는 솔루션이 되어버렸다. 이와 함께 Cloud Storage 종류도 계속적으로 늘어나고 있다. 그러므로, 이러한 Storage의 장, 단점을 정확히 알아서, 최소의 비용과 최고의 성능의 Storage를 알맞게 선택해야 한다. 더불에 Storage Solution (Redgate, Veeam과 같은 어플리케이션)이 어떻게 Azure Blob와 연결이 되는지 (Access Key를 사용하는지, 아니면 Azure AD를 사용하는 지) 확인 한후, 이에 따라 보안 설정을 다르게 해주어야 할 것이다. 마지막으로 Cloud의 시대에 가장 중요한 것은 책임 권한의 분명화일 것이다. 어떤 팀이 어디까지 관리하며, 다른 팀은 어디까지 액세스가 가능하며, 누가 이를 관리하는지 정확한 구분이 없으면 클라우드 솔루션은 모두에게 오히려 혼동을 제공할 것이다.
'미국 IT 이야기' 카테고리의 다른 글
| UMGC 대학원 첫학기 마치면서 (미국 IT이야기 20) (0) | 2022.12.28 |
|---|---|
| UMGC 새롭게 시작하는 대학원 공부 (미국 IT이야기 19) (0) | 2022.12.14 |
| Cisco ISR 4451 Router을 이용한 Azure ExpressRoute Private Peering - Part2 (1) | 2022.08.06 |
| Cisco ISR 4451 Router을 이용한 Azure ExpressRoute Private Peering (0) | 2022.08.02 |
| 미국 회사로부터 학비 지원받기 (미국 IT이야기 18) (2) | 2022.07.15 |
