Azure App Service

• Azure App Service : App Service Plan에 의해 실행되는 Application

• App Service Plan : Application에 대한 Azure 컴퓨팅 리소스 집합
  
  
  

• Azure App Service 이점

• App Service 사용 시, 정의되는 설정

1. 운영체제
2. region
3. 가격책정 계층 : 어떤 App Service를 이용할 수 있는지와 얼마를 지불해야 하는지에 대한 계층 -> 설정한 OS에 따라 달라짐
4. VM 인스턴스 수 : 3~30
5. VM 인스턴스 크기 : CPU, Memory, 원격 스토리지
   
   
   

• App Service Plan 사용 시, 고려사항

1. 비용 고려
2. 여러 App 실행 고려 : 동일 Plan내 컴퓨팅 자원을 공유할 여러 Application 실행 고려 -> 비용 절감 가능
3. 계획 용량 고려 : App이 사용할 컴퓨팅 리소스 사용계획 고려
4. App 격리 고려 : 다음의 경우 새 plan을 생성해야 함
   • 독립된 환경 필요
   • 서로 다른 지역의 리소스 필요
     
     
     

가격 책정 계층

1. 무료
2. 공유
3. 기본 : 트래픽 요구 사항이 낮고 고급 자동 크기 조정 및 트래픽 관리 기능이 필요하지 않은 애플리케이션
4. 표준 : 일반적인 프로덕션 워크로드를 실행, auto scaling 기능 포함, Web App for Containers 지원
5. 프리미엄 : 프로덕션 애플리케이션에 향상된 성능을 제공
6. 프리미엄v2
7. 프리미엄v3
8. 격리 : 가상 네트워크에서 실행해야 하는 중요 업무용 워크로드를 실행하도록 설계, 표준 계층에 비해 더 빠른 프로세서, SSD 스토리지 및 이중 메모리 대 코어 비율을 갖춘 Dv2 시리즈 가상 머신을 제공
9. 격리v2
   
   
   

• 가격책정 계층 그룹화

1. 공유 컴퓨팅
   • 무료, 공유 계층
   • 다른 고객의 앱을 비롯한 다른 App Service 앱과 동일한 Azure VM에서 앱을 실행 (Scale-out 불가)
   • 일반적으로 개발 및 테스트 목적으로 활용
2. 전용 컴퓨팅
   • 기본, 표준, 프리미엄, 프리미엄V2, 프리미엄V3 계층
   • 동일한 App Service 요금제에 속한 앱만 동일한 컴퓨팅 리소스
   • 계층이 높을수록 Scale-out 인스턴스 수 증가
3. 격리
   • 격리 및 격리V2 계층
   • 전용 Azure 가상 네트워크에서 전용 Azure VM을 실행
   • 앱에 대한 컴퓨팅 격리 + 네트워크 격리
     
     
     

Azure App Service 스케일링 방법

• App Service Application의 스케일링 단위는 App Service Plan 단위

• 가격 책정 계층에 따라 App 실행 방식과 Scaling 방식이 달라짐

• Scale-up 방법 : Azure App Service 플랜의 가격 책정 계층을 변경하여 강화

• Scale-out 방법 : 가상 머신 인스턴스 수가 증가, 가격 책정 계층에 따라 인스턴스 확장
  
  
  

• 고려사항

1. 수동조정 case 고려 : 무료 계층을 사용하여 웹앱 테스트를 시작하는 시나리오 (점진적으로 가격책정 계층 상향) -> 비용 절약
2. 사용자 지원, 가격 절감 고려 : Auto Scaling 설정, 부하에 따른 인스턴스 수 조절 -> 비용 절약
3. 스케일 설정 변경 시, 재배포 필요x
4. App Service Plan 외의 서비스는 Scaling 관여하지 않음
   
   
   

Auto Scaling

• 고려사항

1. 최소 인스턴스 수
2. 최대 인스턴스 수
3. 최소, 최대 인스턴스 수 간 적절한 gap 필요
4. 크기조정 규칙 조합
5. 메트릭 통계 : 진단 메트릭에 적합한 통계(평균, 최소, 최대, 합계)를 주의하여 선택
6. 기본 인스턴스 수 : 항상 안전한 기본 인스턴스 수를 선택
7. 알림 : 자동 스케일링 알림을 구성
   
   
   

CI/CD

• Azure Portal에서 CI/CD 설정 제공

• 소스코드가 변경되면 자동으로 배포되어 웹/앱에 동기화 됨

• Azure DevOps 서비스를 사용하면 고유한 빌드 및 릴리스 프로세스를 정의할 수도 있음
  
  
  

• 제공되는 소스코드 저장소

1. GitHub
2. Bitbucket
3. 로컬 Git
4. Azure Repos
   
   
   

• 배포 슬롯

1. 표준, 프리미엄 및 격리된 App Service 가격 책정 계층에서 사용 가능
2. 앱 콘텐츠와 구성 요소는 프로덕션 슬롯을 포함한 두 배포 슬롯 간에 교환 가능 -> 버전 up/down 기능

App Service App Security

• 코드를 최소한으로 작성하거나 작성하지 않고 사용자를 로그인하고 데이터에 액세스할 수 있음
  
  
  

• 특징

1. Azure App Service의 인증 및 권한 부여 보안 모듈 은 애플리케이션 코드와 동일한 환경에서 실행되지만 별도로 실행
2. 앱 설정을 사용하여 구성
3. 들어오는 모든 HTTP 요청이 애플리케이션 코드에서 처리되기 전에 Security 모듈을 통과
   
   
   

사용자 지정 도메인

1. 도메인 이름을 예약 : Azure Portal에서 직접 구입 -> Azure Portal에서 직접 웹앱의 도메인 이름을 관리
2. 도메인을 Azure 웹앱에 매핑하는 DNS 레코드를 만듦
   • 웹앱의 경우 A(주소) 레코드 또는 CNAME(Canonical 이름) 레코드를 만듦
   • IP 주소가 변경되면 CNAME 항목은 여전히 유효하지만 A 레코드를 업데이트 필요
3. Azure Portal에서 사용자 지정 도메인을 사용하도록 설정
   
   
   

백업 및 복원

1. 표준 또는 프리미엄 계층 App Service 요금제가 필요
2. 동일한 구독에 Azure Storage 계정 및 컨테이너가 필요
3. 백업 정보
   • 앱 구성 설정
   • 파일 콘텐츠
   • 앱에 연결된 모든 데이터베이스
4. 백업은 Zip 파일과 XML 파일로 구성
5. 백업을 수동으로 또는 일정에 따라 구성 가능
6. 부분 백업이 지원됩니다. 백업에서 제외할 파일 및 폴더를 지정 가능
7. 최대 10GB의 앱과 데이터베이스 콘텐츠를 저장 가능
8. Azure Portal에서 스토리지 계정 및 앱(또는 사이트)의 컨테이너 페이지에 표시
   
   
   

• 복원 시 고려사항

1. 전체 백업을 고려 -> 해당 사이트의 모든 콘텐츠가 백업에 있는 항목들로 대체
2. 부분 백업을 고려 -> 제외된 폴더 또는 파일에 있는 모든 콘텐츠가 있는 그대로 남아 있음
3. 백업 파일 검색을 고려 -> 앱 또는 사이트 복원을 수행하지 않고도 콘텐츠를 볼 수 있음
4. 백업 대상에 대한 방화벽을 고려 -> 방화벽 설정 시, 스토리지 계정을 백업의 대상으로 사용할 수 없음
   
   
   

Azure Application Insights

• Azure Application Insights : 라이브 애플리케이션을 모니터링할 수 있는 Azure Monitor의 기능 -> 사용자가 문제를 진단하고 사용자가 실제로 앱을 사용하여 수행할 작업을 이해하는 데 도움이 되는 강력한 분석 도구를 제공
  
  
  

• 특성

1. 온-프레미스, 하이브리드 환경 또는 퍼블릭 클라우드에서 호스트되는 구성에 사용 가능
2. Azure 파이프라인 프로세스와 통합되며, 다양한 개발 도구에 대한 연결점이 있음
3. Visual Studio App Center를 통합하여 모바일 앱에서 데이터를 모니터링하고 분석

• 모니터링 대상

1. 요청 속도, 응답 시간 및 실패율을 확인 : 어떤 페이지가 가장 성능이 우수한지 확인, 응답 시간과 실패율이 높아지면 아마도 리소스 문제
2. 종속성 비율, 응답 시간 및 실패율을 확인 : 외부 서비스가 앱 성능을 저하시키는지 조사
3. 예외를 확인 : 서버 및 브라우저 예외가 전부 보고
4. 페이지 보기 및 로드 성능을 확인 : 페이지 보기 숫자를 수집하고 로드 성능을 분석
5. 성능 지표 확인 : CPU, 메모리, 네트워크 사용량 등에 대한 성능 출력을 모니터링
6. Docker 또는 Azure의 진단을 앱 Application Insights에 통합
7. 진단 추적 로그를 확인 : 제를 진단하는 데 도움
8. 사용자 지정 이벤트 및 메트릭을 확인 : 클라이언트 또는 서버 코드로 작성, 비즈니스 이벤트를 추적

가용성 계획에 포함되어야 하는 전략

1. 계획되지 않은 하드웨어 유지 관리 : 물리적 컴퓨터에 연결된 하드웨어 또는 플랫폼 구성 요소가 실패할 것으로 예측하는 경우에 발생 -> 실시간 마이그레이션 기술을 사용하여 오류가 발생한 하드웨어에서 정상적인 물리적 컴퓨터로 가상 머신을 마이그레이션 -> 성능저하 우려 있음
2. 예기치 않은 가동 중지 시간 : 로컬 네트워크 오류, 로컬 디스크 오류 또는 기타 랙 수준의 오류가 포함 -> 가상 머신을 동일한 데이터 센터의 정상적인 물리적 컴퓨터로 자동으로 마이그레이션(복구) -> 임시 드라이브가 손실 우려 있음
3. 계획된 유지 관리 : 플랫폼 인프라의 전반적인 안정성, 성능 및 보안을 개선하기 위해 Microsoft에서 기본 Azure 플랫폼으로 정기적으로 업데이트

• 가상 머신 운영 체제 또는 기타 소프트웨어를 자동으로 업데이트하지 않습니다. 이러한 업데이트는 전적으로 사용자의 제어와 책임 하에 실시됩니다. 그러나 기본 소프트웨어 호스트 및 하드웨어는 안정성과 고성능을 보장하기 위해 정기적으로 패치
  
  
  

가용성 집합

• 특징

1. 동일 가용성 집합의 가상 머신은 모두 동일한 기능을 수행
2. 동일 가용성 집합의 가상 머신은 모두 동일 소프트웨어 설치
3. 동일 가용성 집합의 가상 머신은 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치에 나눠 실행
4. 가용성 집합을 변경하려면 가상 머신을 삭제한 다음, 다시 만들어야 함
5. 단일 실패 지점이 모든 컴퓨터에 영향을 주지 않도록 하는 데 도움 -> 호스트 운영 체제를 업그레이드하는 동안 모든 컴퓨터가 동시에 업그레이드되지 않도록 함
   
   
   

• 고려 사항

1. 중복 고려
2. 애플리케이션 계층의 분리를 고려 : 각 애플리케이션 계층은 별도의 가용성 집합 필요 -> 실패지점 확산 방지
3. 부하 분산을 고려 : Azure Load Balancer를 사용
4. 관리 디스크를 고려 : 블록 수준 스토리지
   
   
   

업데이트 도메인 및 장애 도메인

• 업데이트 도메인 : 서비스 업그레이드(또는 롤아웃) 프로세스 중에 함께 업그레이드되는 노드 그룹 -> Azure가 배포 전체에서 증분 또는 롤링 업그레이드를 수행

• 장애 도메인 : 실패의 물리적 단위를 나타내는 노드 그룹 -> 동일한 물리적 랙에 속하는 노드로 간주 -> 장애 도메인은 단일 실패 지점을 공유하는 공통된 하드웨어(또는 스위치) 집합
  
  
  

• 가용성 집합내 VM은 각각 업데이트 도메인과 장애 도메인에 배치됨

• 업데이트 도메인은 기본 5개, 최대 20개까지 구성 가능

• 한 번에 한 개의 업데이트 도메인만 다시 부팅

• 두 개의 장애 도메인이 함께 동작되어 하드웨어 오류, 네트워크 중단, 전원 중단 또는 소프트웨어 업데이트에 따른 상황을 완화
  
  
  

• 장애 도메인과 가용성 집합 구성

가용성 영역

• 가용성 영역 : 데이터 센터 오류에서 애플리케이션 및 데이터를 보호하는 고가용성 기능 (장애 도메인과 업데이트 도메인의 조합)
  
  
  

• 특징

1. Azure 지역 내의 고유한 물리적 위치
2. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터
3. 모든 지역에서 최소한 세 개의 별도 영역이 필요
4. 가용성 영역을 물리적으로 구분하면 애플리케이션 및 데이터를 데이터 센터 오류로부터 보호 가능
5. 영역 중복 서비스는 단일 실패 지점으로부터 보호하기 위해 가용성 영역 전체에서 애플리케이션과 데이터를 복제
   
   
   

Scaling

• 스케일링 기능 : VM 처리량에 하드웨어 리소스를 맞추는 기능
  
  
  

• 수직 스케일링(Scale up/down) : VM의 크기를 늘리거나 줄임

1. 활용률이 낮을 때 비용 절감을 위해 VM크기 줄임
2. 더 많은 처리를 위해 VM크기 늘림
   
   
   

• 수평 스케일링(Scale out/in) : VM 수 조정
  
  
  

• 고려사항

1. 일반적으로 수평 스케일링은 수직 스케일링보다 제한 사항이 적음 : 수직은 지역별로 달라질 수 있음, 수평은 데이터에 대한 액세스가 일시적으로 제한될 수 있음
2. 유연성 고려 : 수평 스케일링이 더 유연
3. 재설정 고려 : 다시 프로비저닝이 필요할 수 있는 경우와 서비스 중단 계획을 고려
   
   
   

Scale Sets

• Azure Virtual Machine Scale Sets : 동일한 VM 세트를 배포 및 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스 -> auto scaling 가능
  
  
  

• 특징

1. 모든 가상 머신 인스턴스는 동일한 기본 운영 체제 이미지 및 구성
2. 기본 레이어 4 트래픽 배포를 위해 Azure Load Balancer 사용을 지원하고 고급 L7 트래픽 배포 및 TLS/SSL 종료를 위해 Azure Application Gateway 사용을 지원
3. 중단을 최소화하면서 다른 가상 머신 인스턴스를 통해 애플리케이션에 계속 액세스
4. 고객의 요구를 충족하기 위해 Virtual Machine Scale Sets는 자동 스케일링을 구현
5. 최대 1,000개의 가상 머신 인스턴스를 지원 (사용자 지정 가상 머신 이미지인 경우 최대 600개)
   
   
   

• Scale Sets을 만들기 위한 설정

1. 오케스트레이션 모드 : 가상 머신을 관리하는 방법을 선택 -> 가상 머신 모델을 수동 정의 -> Azure는 해당 모델을 기반으로 동일한 인스턴스를 생성
2. 이미지 : VM의 기본 운영 체제 또는 애플리케이션
3. VM 아키텍처 : x64 또는 Arm64 기반 가상 머신을 선택 가능
4. VM 크기 : 처리 성능, 메모리 및 스토리지 용량 등의 요소를 결정
5. 크기조정 모드
   • 자동 크기 조정 설정
     • 기본 인스턴스 수 : 초기 가상 머신 수(0~1000)
     • 인스턴스 제한 : 스케일 다운하려는 최소 인스턴스 수, 스케일 업하려는 최대 인스턴스 수
     • 스케일 아웃 : 스케일 아웃 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 아웃할 인스턴스 수
     • 스케일 인 : 스케일 인 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 인할 인스턴스 수
     • 쿼리 기간 : 이 기간은 자동 크기 조정 엔진이 메트릭 사용량 평균을 다시 조회하는 시간.
     • 일정: 시작 및 종료 날짜를 지정. 특정 요일에 일정을 반복할 수도 있음
       
       
       

Auto Scaling

• 고려사항

1. 자동 조정된 용량 : 정의된 임계값이 충족되면 자동 크기 조정 규칙이 작동
2. 스케일 아웃 : 구현된 가상 머신 인스턴스의 수를 늘리도록 자동 크기 조정 규칙을 구성
3. 스케일 인 : 감소된 로드가 일정 기간 동안 일관성 있게 유지될 경우 구현된 가상 머신 인스턴스 수를 줄이도록 자동 크기 조정 규칙을 구성
4. 예약 이벤트 : 정해진 시간에 구현의 용량을 자동으로 늘리거나 줄이도록 이벤트를 예약
5. 오버헤드 : 자동 크기 조정과 함께 Azure Virtual Machine Scale Sets를 사용하면 애플리케이션의 성능을 모니터링하고 최적화하는 데 드는 관리 오버헤드 감소 가능

Azure 컴퓨팅 리소스

1. VM (Virtual Machine)
2. 스토리지용 디스크
3. 가상 네트워크
4. 네트워크 인터페이스
5. 네트워크 보안 그룹 (네트워크 트래픽 보호)
6. IP주소
   
   
   

VM (Virtual Machine)

• VM 생성 시, 고려해야할 사항

1. 네트워크
2. VM 이름
3. 생성 위치
4. VM 크기
5. 디스크
6. 운영 체제
   
   
   

네트워크

• 동일 VNet(가상 네트워크)에서 Azure 서비스간 연결 가능 (프라이빗 연결) -> VNet 외부와 연결하도록 구성 가능
• 가상 네트워크 설정 내용

1. 사용 가능한 주소
2. 서브넷 : 서로 다른 VNet간에 서브넷이 겹치면 안됨
3. 보안 : 서브넷 및 VM간에 NSG(네트워크 보안 그룹)를 설정하여 트래픽 제어 가능 (방화벽 역할)
   
   
   

VM 이름

• VM에서 수행하는 작업을 쉽게 식별할 수 있도록 의미 있고 일관성 있는 이름을 선택
• 이름에 포함시키길 권장하는 정보 (ex. deveus-webvm01 : 미국 동부 지역에서 호스트되는 첫 번째 개발 웹 서버)

VM 생성위치

• 고려사항

1. 위치에 따른 사용가능 옵션 제한
2. 위치 간의 가격 차이
   
   
   

VM 크기

• 원하는 작업에 적합한 컴퓨팅, 메모리 및 스토리지의 적절한 조합 선택 가능
• VM 크기는 변경 가능 -> 크기 조정 시에 VM이 자동으로 부팅되어 일시적으로 서비스가 중단될 수 있음
• 작업 옵션에 따른 설명

VM 스토리지

• VM당 둘 이상의 VHD(가상 하드 디스크)가 있음

1. 운영체제 저장
2. 임시 스토리지
3. 추가 스토리지 : 애플리케이션 데이터 저장 용도
   
   
   

• 최대 디스크 수는 VM크기에 따라 결정
  
  
  

• 특정 시나리오에 따른 5가지 디스크 유형

운영체제

• Azure에서 VM 구성을 위한 다양한 OS 이미지 제공 -> 원하는 이미지가 없을 경우, 커스텀 가능
• Azure Marketplace에서 다양한 이미지 선택 가능
• OS 라이선스 비용이 컴퓨팅 가격에 영향을 미침
  
  
  

VM 가격책정 방식

1. 종량제
   • 컴퓨팅 비용 : 분당 요금으로 청구 (VM크기와 OS에 따라 다름)
   • 스토리지 비용 : VM 중지 및 할당 취소에 관계없이 디스크를 사용중이라면 별도 요금 지속 청구
2. 예약 인스턴스 : 1년 or 3년 동안 VM을 사전 구매하는 방식 (약정) -> 종량제에 비해 최대 72% 가격 절감 효과
   
   
   

Azure VM을 만드는 방법

1. Azure 리소스 관리자 템플릿
   • 배포 리소스를 정의한 JSON 파일
   • 기존 VM에서 템플릿 내보내기 활용
2. Azure PowerShell
3. Azure CLI
   • az vm create
4. Azure REST API
   • 프로그래밍 방식 REST API 호출
5. Azure 클라이언트 SDK
   • 프로그래밍 방식 SDK 활용
6. Azure VM 확장
7. Azure Automation 서비스
   • 시간 소모적이고 오류가 발생하기 쉬운 관리 작업을 자동화하는 서비스들을 통합
   • 프로세스 자동화 (ex. 발생 이벤트에 대해 응답해주는 감시자 작업 등)
   • 구성 관리 (ex. OS에서 사용할 수 있는 소프트웨어 업데이트 추적 등)
   • 업데이트 관리 (ex. VM에 대한 업데이트 및 패치 관리, 사용 가능한 업데이트 상태 확인->설치 예약->배포 결과 검토 등)
8. Terraform
   • 클라우드 인프라의 정의, 미리보기 및 배포 사용
   • HCL구문의 구성 파일로 실행계획 작성 및 적용 후 인프라 배포
     
     
     

Azure VM 가용성 관리

• 지속 가능한 서비스, 데이터 안전 유지를 위한 가용성 관리 -> 비즈니스 연속성 및 재해 복구 전략 고민
• 가용성 영역 (AWS의 AZ?) : 동일 Azure 지역 내에서 물리적으로 별도의 영역
• VM 크기 집합 (Scale Group?) : 부하 분산 VM 그룹, VM 인스턴스의 수를 자동으로 확장or축소
• Azure Load Balancer : 트래픽을 여러 VM에 분산 -> 가용성 영역 or 가용성 집합(크기집합?)과 결합하여 복원력 극대화
• Azure Storage 복사본 : 데이터 보호를 위해 여러 복사본 저장 (기본 지역 데이터 복제, 보조 지역 복제, 보조 지역으로의 액세스 권한 여부 등 옵션 선택)
• 장애 조치 (failover) : Azure Site Recovery 활용, 워크로드를 기본 위치에서 보조 위치로 복제(장애조치)
  
  
  

VM 백업

• Azure Backup 활용
• Azure Backup : 온-프레미스 or 클라우드 등으로 가상 머신을 보호하는 서비스 기반 백업 제품

• Azure Backup 장점

1. 자동 스토리지 관리
2. 무제한 크기 조정
3. 여러 스토리지 옵션 (ex. 로컬 중복 스토리지, 지역 중복 스토리지 등)
4. 무제한 데이터 전송
5. 데이터 암호화
6. 보존 시간 제한 없음
   
   
   

• Recovery Services 자격 증명 모음을 사용하여 백업 데이터 저장 (백업 머신 선택 및 백업 정책 정의 가능) -> Azure Storage Blob으로 백업

Azure Files

• Azure Files : 완전 관리형 파일 공유를 제공
  
  
  

• 접근 방법

1. SMB(서버 메시지 블록)
2. NFS(네트워크 파일 시스템)
3. HTTP 프로토콜
   
   
   

• 특성

1. 인프라를 필요로 하지 않는 완전 관리형 파일 공유의 PaaS 제품 (VM, 운영체제 등 자동 업데이트)
2. 최대 100TiB(테비바이트)의 파일을 저장
3. 온-프레미스 파일 서버와 동일한 방식으로 계층 구조의 폴더 구조
4. 데이터 미사용 시 암호화, 전송중 암호화 지원
5. 인터넷에 연결된 경우 어디서나 Azure 파일 공유에 액세스
6. 사용자가 온-프레미스 파일 서버에 액세스할 때와 동일한 방식으로 Azure 파일 공유에 액세스 (동기화되는 Microsoft Entra ID 또는 AD DS ID 등 활용)
7. 이전 버전 기능과 통합되는 Azure 파일 공유 스냅샷 생성 가능
8. Azure Backup을 통한 파일 백업 가능
9. 여러 Azure 데이터 센터의 여러 위치에 복제 (Azure 스토리지 계정의 복제 설정)
   
   
   

• 사용 시나리오

1. 기존 온-프레미스 파일 서버 또는 NAS 디바이스를 대체하거나 보완
2. 전 세계 어디서나 접근
3. 애플리케이션을 쉽게 리프트 앤 시프트할 수 있음 (옮기는 것)
4. Azure 파일 동기화를 사용하여 Azure 파일 공유를 Windows Server에 복제
5. 로그, 메트릭 및 크래시 덤프와 같은 진단 데이터를 공유 위치에 저장
6. 개발하거나 관리하는 데 필요한 도구 및 유틸리티를 저장하는 데 좋은 옵션
   
   
   

• Azure Files vs Azure Blob Storage

Azure Files 공유

• SMB(서버 메시지 블록) 프로토콜과 NFS(네트워크 파일 시스템) 프로토콜을 모두 제공하지만, 동일 파일 공유에서 동시에는 제공하지 않음
• Azure Files 공유 유형
  
  
  

1. 프리미엄 스토리지 계층
   • SSD에 데이터 저장
   • FileStorage 계정 유형
   • 일관된 고성능, 짧은 대기시간
2. 스탠다드 스토리지 계층
   • HDD에 데이터 저장
   • GPv2(범용 버전 2) 스토리지 계정 유형
     
     
     

• 인증 형식

1. SMB를 통한 ID 기반 인증 : 온-프레미스 파일 공유에 액세스할 때와 동일한 SSO(Single Sign-On) 환경 제공
2. 액세스 키
   • Azure Files를 포함하여 스토리지 계정에 대한 요청을 할 때 사용할 수 있는 두 개의 액세스 키에 해당
   • 모든 액세스 제어 제한을 우회하므로 사용자와 공유하지 않고 액세스 키를 보호해야 함
   • ID기반 인증 권장
3. SAS(공유 액세스 서명 토큰)
   • 액세스 키 기반으로 동적으로 생성하는 URI로 인증
   • 제한된 권한과 시간
   • Azure Files를 사용하면 SAS 토큰은 코드에서 REST API 액세스를 제공하는 데만 사용
     
     
     

• SMB Azure File 공유 만들기

1. 포트 445를 엽니다 : SMB는 445 TCP 포트를 통해 통신함
2. 보안 전송을 사용하도록 설정합니다 : 보안 연결로만 스토리지 계정에 대한 요청을 제한하여 스토리지 계정의 보안을 향상 (REST API 활용 고려, HTTPS)
   
   
   

• 파일 공유 스냅샷 만들기 (데이터의 읽기 전용 시점 복사본 캡처)

1. 스냅샷 기능은 파일 공유 수준에서 제공
2. 최근 공유 스냅샷 이후 변경된 데이터만 저장
3. 시간을 최소화하고 스토리지 비용을 절감 가능
4. 공유를 복원하려면 가장 최근의 공유 스냅샷만 유지해야 함
5. 파일 공유 또는 스토리지 계정에서 키보드 입력 실수로 인한 삭제를 방지하지 않음
   
   
   

• Azure Files 일시 삭제

1. 파일공유 수준에서 활성화
2. 영구적이 아닌 일시 삭제 상태로 전환
3. 보존 기간 설정 가능 (보존 기간 : 다시 복구하여 사용할 수 있는 기간, 1~365일)
   
   
   

Azure Storage Explorer

• Azure Storage Explorer : Windows, macOS 및 Linux에서 Azure Storage 데이터를 쉽게 사용할 수 있는 독립 실행형 애플리케이션, 여러 계정 및 구독에 액세스하고 모든 스토리지 콘텐츠를 관리 가능

• 특징

1. 모든 권한을 허용을 위해 Azure Storage Explorer에 관리 권한(Azure Resource Manager)과 데이터 계층 권한이 모두 필요
2. 스토리지 계정, 계정의 컨테이너, 컨테이너의 데이터에 액세스하려면 Microsoft Entra ID 권한이 필요
3. 다른 스토리지 계정에 연결 가능
   • Azure 구독과 연결된 스토리지 계정에 연결
   • 다른 Azure 구독에서 공유되는 스토리지 계정 및 서비스에 연결
   • Azure Storage 에뮬레이터를 사용하여 로컬 스토리지에 연결하고 관리

• 사용 시나리오

Azure Files 동기화

• Azure Files 동기화

1. 온-프레미스 Windows Server 또는 클라우드 가상 머신에 여러 Azure 파일 공유를 캐시할 수 있음
2. Azure Files에서 조직의 파일 공유를 중앙 집중화
   
   
   

• 클라우드 계층화

1. 클라우드 계층화는 Azure 파일 동기화의 선택적 기능
2. 자주 액세스하는 파일은 서버에서 로컬로 캐시되고 다른 모든 파일은 정책 설정에 따라 Azure Files로 계층화
   • 파일이 계층화되면 Azure 파일 동기화는 로컬에서 파일을 포인터로 바꿈
   • 포인터를 일반적으로 재분석 지점이라고 함
   • 구문 분석 지점은 Azure Files의 파일에 대한 URL
     
     
     

• 동기화 사용 시나리오

1. 애플리케이션 리프트 앤 시프트를 고려 (애플리케이션 이동시키기, Windows Server와 Azure Files 간에 동일한 데이터에 대해 쓰기 액세스를 제공)
2. 서비스를 사용하여 Azure Storage에 연결하는 새 서버를 설정
3. Azure 파일 동기화를 구현하면 Azure Backup이 온-프레미스 데이터를 백업
4. Azure 파일 동기화는 최근에 액세스한 데이터만 로컬 서버에 저장합니다. 이전 데이터가 Azure Files로 이동하도록 클라우드 계층을 구현 (클라우드 계층화)