[Azure] AZ-305 - 2 & Dumps 2 & 후기

결과

 

어찌저찌 AZ-900, AZ-104, AZ-305 취득을 완료했다.

난이도 순으로는 AZ-900 < AZ-305 < AZ-104 순으로 어려웠다.

• AZ-900, AZ-305는 Azure 서비스에 대해서 명확하게 구분할줄알고 305는 더 나아가서 서비스의 tier도 명확하게 구분지을줄 알면 취득하기가 수월했던것같다
• AZ-104 가 이 세개 자격증중에 제일 어려웠었는데, 턱걸이로 취득을하기도 해서 온라인 교육을 한번 더 들어보면 좋을것같다. 어떤 상황이 주어졌을때 이것을 해결하는 방법에 대해서 물어보는데 사실 선택지는 이해하는데 어렵지않은데 문제를 이해하기 어려웠던게 좀 있던것같다.

Design a migration solution

Design using Cloud Adoption Framework

다음과같은 순서로 migration 계획을 수립

- Define Strategy

- Plan

- Ready

- Adopt

- Govern

- Manage

 

Azure Migration Framework

Plan your migration strategy

Cloud로 이전하는데에는 아래와 같이 4가지 전략이 존재함 (4R)

Strategy	What?	When?
Rehost	Lift-and-shift process to move the workloads quickly without making any architecture/code changes	When you want to move to cloud quickly without any change - 기존 시스템/애플리케이션에 변경사항없이 이전을 원할경우
Refactor	Repackaging the application to leverage PaaS and cloud-native options available in the cloud	If you would like to leverage the features of the cloud by minimum architectural changes - 최소한의 변경이 있을경우
Rearchitect	Rearchitecting an application to extend the app functionality and code to optimize the app architecture for cloud scalability	Ideal when your application needs many changes to work effectively with the cloud - 클라우드에서 효율적으로 동작하기 위해 변경이 필요 할 경우 - 기존 시스템/애플리케이션이 클라우드 환경에서 동작하지 않을경우
Rebuild	Completeely rebuilding the application to use the app in Azure	You have EOL(End of Life) apps and would like to rapidly develop and onboard to cloud - Rearchitect보다 Rebuild가 비용적인 측면에서 저렴할경우 Rebuild를 선택

 

Assessing workloads

- Server Assessment - Azure Migrate Tool

- Database Assessment - DMA(Data Migration Assistant) Tool

- Webapp Assessment

Azure Migrate 페이지에서 현재 on-premise에서 갖고있는 서버에 대한 정보를 csv파일로 정보를 넘겨줘서 Azure가 해당 정보를 바탕으로 인프라에 대한 비용 및 migration시 발생하는 문제에 대해서 알려주는것으로 보임

 

Migration Tools

Server Migration

Database Migration - DMA를 사용하여 Database migration을 평가. migration에는 두가지 방식이 존재

- Online migration: Downtime 없이 이전작업 가능

- Offline migration: Offline migration은 시작할때 기존 DB의 서비스를 종료시켜둬야함(Downtime 발생).

실행 방법

- DB가 설치된 온프레미스 서버에 DMA를 설치 진행

- 먼저 Assessment project를 생성하여 온프레미스에 설치된 DB가 Azure로 이전할경우 발생하는 문제들에 대해서 검사

- 문제가 없다면 Azure에서 Database Migration Services(DMS)를 생성

- 이전하려는 DB의 접속정보를 DMS에 기입하여 DB정보를 가져옴

Data box - Migrate large amount of offline data to Azure Storage

Storage Migration에는 Database Migration과 동일하게 두가지 방식이 존재.

- Online Migration: Azure File Sync, AzCopy(Command 기반), Storage Explorer(GUI 기반), Window Server Storage Migration Service

- Offline Migration: Azure Import(On-prem to Azure)/Export, Azure Databox(오프라인으로 데이터가 저장된 디스크를 Microsoft로 전달)

  - Azure Import/Export는 사용자가 직접 디스크(SSD/HDD)를 준비해야하는 반면에 Azure Databox는 Azure에서 디스크를 제공함.

  - Databox Disk는 Databox disk(<40TB, 128bit encryption), Databox(<100TB, AES 256bit encryption), Databox heavy(<1PB, AES 256bit encryption ) 세가지 종류로 나뉨. Databox는 모든 region에서 제공하는 서비스는 아님.

Design a business continuity solution

Design for backup and recovery

아래와 같은 요소를 고려하여 backup and recovery 를 설계

- Workloads

- Usage patterns: 사용하는 서비스의 동작 시간에 기반하여 설계

- Availability metrics

- Recovery metrics

- Workload availability and SLA: SLA에 위반되지않도록 backup을 설계

 

Azure Backup

Backup vault

- Azure DB for PostgreSQL servers

- Azure blobs

- Azure disks

Recovery services vault

- Azure VM

- SQL in Azure VM

- SAP HANA in Azure VM

- Azure Backup Server (Non-Azure workloads or On-prem)

- Azure Backup Agent (Non-Azure workloads or On-prem)

- DPM (Non-Azure workloads or On-prem)

Vault - Considerations

- Organizing vaults: 사용 목적에 따른 Vault분리. 예를들어, develop & production용으로 분리등

- Policy enforcement

- Region availability: Backup대상은 동일한 region에 있게끔 설정

- Access control: RBAC

- Data redundancy: LRS, GRS, ...

 

Design for Azure Blob Backup and Recovery

Soft Delete and versioning

실수로 데이터가 삭제되거나 수정되었을 때 이를 복구하기 위한 데이터 보호 기능. Azure Files, Blob Storage, Key Vault, Managed Disks등에서 기능을 제공.

- Soft Delete: 데이터를 삭제했을 때 즉시 영구 삭제하지않고, 일정 보류 기간동안 시스템에 데이터를 유지하는 기능. Container도 soft delete를 제공함.

- Versioning: 데이터에 변경이 발생했을경우 해당 시점의 데이터 상태를 별도 버전으로 자동 저장하는 기능. PITR(Point-In-Time Restore)을 할때 사용. PITR의 복원 기간은 Soft Delete 기간보다 같거나 짧아야함.

 

Design for Azure Files Backup and Recovery

Azure Files에서는 Snapshot이라는 서비스로 데이터 삭제/수정에서 보호함.

- Snapshot의 내용은 수정할수없음.

- Snapshot이 있는 Azure Files는 삭제가 불가능함, 만약 삭제를 원할경우 모든 Snapshot을 삭제해야함.

 

Design for Azure VM backup and Recovery

Azure VM은 백업을 시작하면 VM로컬에 Snapshot이 생성됨 (보존은 5일). Snapshot은 또한 Recovery Service Vault에도 전송되어 저장됨.

- VM로컬에 저장되는 Snapshot은 Instance Restore이라고 하기도함. Vault에 가서 굳이 복구할필요없이 VM내에서 복구작업이 가능함.

- Recovery Service Vault는 기본적으로 GRS로 데이터를 저장함.

 

Design for Azure SQL Backup and Recovery

Use Cases

1. Restore an existing DB to Point-In-Time in the Past: DB는 복원을 위해서 덮어씌우지않고, 이름이 다르게 DB를 생성하여 해당 DB에 데이터를 복원함. 복원작업이 완료되면 생성된 DB는 삭제가능함.

2. Restore a deleted database to the time of deletion: soft delete 지원?

3. Restore a database to another Azure region

4. Restore a database from a specific long-term backup: 자동 백업은 보관주기가 35일로 설정. 만약에 35일보다 길게 보관하고싶다면 LTR backup을 사용하여 최대 10년까지 보관이 가능함.

 

Design for Azure Site Recovery(ASR)

재해 복구(DR) 솔루션임. 서비스 장애가 발생한 특정 region에 떠있는 리소스들을 ASR을 사용하여 문제가 없는 region으로 이전할수있음. Test Failover(장애 테스트?)기능도 제공함.

- BCDR (Business Continuity and Disaster Recovery)

- Migration

- Replication

- Retention

Design an app architecture solution

Differentiate message and event

message: message에는 데이터가 담겨져있으며 누가 Message를 받아서 처리하는지 정해져있음. e.g. RESTful API

event: 주로 broadcasting에서 사용되며 해당 통신은 처리가 안될수도있음. 즉, 특정 상황을 알리기 위함. e.g. 특정 사이트를 구독하면 마케팅 메일이 모든 유저들에게 발송되는것처럼...

 

만약에, "수신자가 원하는 특정 방식으로 통신이 처리되길 원한다면?" Message를 사용해야하고 아닐경우엔 Event를 사용.

 

Design a messaging solution

Azure에는 두가지 Messaging solution이 존재함. 둘다 message를 받을때까지 Queue에 저장함.

Azure Queue Storage

- HTTP/HTTPS 호출 가능

- Size of message can be up to 64KB

- Queue 크기는 Storage account에 따라서 설정 가능

- Queue에는 수백만개의 message가 존재 할 수 있음

- Pull model

Azure Service Bus

- Service Bus Queue, Service Bus Topics 두개의 서비스가 존재함

- 수신자(subscribor)가 한명일 경우엔 Bus Queue, 수신자가 여러명일 경우엔 Bus Topics

- Size of message can be up to 256KB(standard)/1MB(Premium)

- Queue 크기는 Queue storage에 비해 제한적임 (일반적으론 80GB)

- Messaging Session을 통한 엄격한  순서를 보장함.

- Pull model

 

Design a event solution

Azure Event Hub (이벤트 파이프라인)

- Anomaly detection and live visualization in dashboards

- Events(Streaming) > Events Hub(Ingest) > Blob Storage(Store) > Stream Analytics > Power BI

  - 위와같은 구조를 설계할수있음.

- 실시간 시나리오에서 이벤트를 수집하기 위한 서비스

- Pull model

- 수만 대의 기기에서 발생하는 로그를 실시간으로 수집하고 싶을 때 사용

Azure Event Grid (이벤트 라우터)

- 이벤트 기반 반응(Reactive)

- 개별적인 상태 변화 알림(e.g. 파일 생성, VM 시작)

- Push model

- 어디선가 발생한 이벤트를 감지하여 필요한 곳으로 배달하는 통로 역할. 이벤트 라우팅 기능. 특정 코드를 실행하는것이 아님 (Azure Functions과는 다름)

- Azure Event Hub > (Azure Event Grid) > Azure Function같은 흐름으로 구축.

 

Design an application optimization solution

Azure Redis Cache

자주 사용되는 데이터에 대해서 Redis Cache에 저장하여 서비스 요청에 빠르게 반응

Azure API Management

AWS의 API Gateway와 동일하며 하나의 API 주소에서 특정 서비스로 라우팅이 가능함

Design a logging and monitoring solution

Design for Azure Monitor

Data Source

- Application: Application Insight를 사용하여 로그/메트릭 수집

- Guest OS: Diagnostic Extension), Log Analytics Agent, Dependency Agent(VM Insights)

- Azure Tenant: Azure Entra ID(Audit logs, Sigh-in Logs)

- Azure Resource

- Azure Subscription

Data Source에서 수집된 요소들을 Log Analytics Workspace에서 Kusto 쿼리(KQL)을 사용하여 분석이 가능함.

 

리소스에 따라서 별도 설정이 필요할때가 있음.

- 예를들어서 VM같은 경우에는 머신에대한 Metrics은 기본제공되지만 더 많은 정보는 Insight에서 Agent를 활성화 해야함.

- 또는 DB같은 경우에는 Diagnostic configuration을 진행하여 필요한 정보를 수집하게할수있음.

 

Design for Log Analytics

- Kusto 쿼리를 이용해서 로그 분석가능

- 너무많은 양의 데이터를 저장할경우 그만큼 지불해야하는 비용또한 증가하게됨

  - Data capping을 이용하여 하루에 수집하는 로그양을 제한할수있음

- Log Analytics workspace에 대해서는 목적에 따라서 나눌수도 중앙식으로 관리할수도있음. 예를들어 팀에따른 workspace제한이 필요하다면 workspace를 따로두고 권한을 설정할수있음

 

Design for Azure workbooks and Insights

- Azure workbooks은 Data Visualization Tool같이 직접 화면을 구성하여 데이터를 시각화할수있음

- Azure Insights는 각 리소스에 대한 정보를 볼수있음. (e.g. VM같은 경우에는 성능방면, Container Insight같은경우엔 AKS의 메모리 성능 조회등...)

 

Dumps

• Premium storage tier는 GRS(Geo-Redundant Storage) 데이터 복제 정책을 제공하지않음. (AZ-305 Topic3 #5)
• SAS(shared access signature)은 특정 사용자에게 부여하는것이 아닌 토큰만 갖고있다면 접근이 되는거라 만일 특정 사용자에게 서비스 접근을 설정한다고하면 IAM role assignment를 해줘야함 (AZ-305 Topic4 #60)
• Azure Analysis Service는 OLAP(Online Analytical Processing) 을 지원함 (AZ-305 Topic2 #36)
• 여러 NVA(Network Virtual Appliance)에 부하 분산을 하려면 Gateway Load Balancer를 사용하는것이 좋음. (AZ-305 Topic3 #21)
•  
• VM backup을 위해서 서로 다른 두개(Sub1, Sub2)의 Subscription이 존재한다하고 User1이 Sub1에 위치되어있을때, Sub2에 대한 역할을 할당받고싶을경우엔. Sub1에는 VM 백업을 위해 Recovery Service Vault 리소스를 생성하고, Sub2에는 권한을 받기 위한 Resource Guard를 생성해서 둘을 연결하면됨. (AZ-305 Topic3 #22)
• Azure pipeline agent는 Azure DevOps에서 사용되는 구성 요소 (AZ-305 Topic4 #31)
• RG1에 있는 VM1을 RG2에 있는 VM2로 옮기려면, VM2에는 Azure Migrate를 사용하고, VM1에는 이전작업을 위한 Azure Resource Mover를 사용해야함. (AZ-305 Topic4 #34) - 사실 문제 내용이 완전하게 나와있지않은것 같음...
  • Azure Resource Mover는 Azure 리소스를 한 Azure 지역에서 다른 지역으로 옮기기 위해 계획하고 준비하며 이동시키는 것을 도와주는 단일 허브 서비스.
• Log에 대한 Caching method는 설정하지않고, Data에 대한 Caching method는 ReadOnly로 설정함 (AZ-305 Topic4 #48)
  • Log는 일반적으로 한번 저장하면 다시 읽는 경우가 드물어서 캐싱하는경우 오히려 무의미하게 메모리공간이 낭비 될수있음.
  • 반면에 Data같은경우엔 읽는 경우가 빈번하게 일어나서 ReadOnly로 캐싱을하여 데이터를 읽는것에 대해 성능을 높힐수있음.
• Azure MFA에 사용자를 등록하려면 Azure AD Identity Protection을 사용하고, MFA사용을 강제화 하려면 Grant control설정해야한다. (AZ-104에서도 나옴) (AZ-305 Topic5 #1)
• Azure Policy에서 deployIfNotExists & Modify Effect가 존재하는데. 각각 아래와같이 효과가 다름.
  • deployIfNotExists는 만일 리소스가 없을경우 생성하는것이고, Modify는 이미 존재하는 리소스에 대한 수정을 가하는 정책 액션을 보여줌.
  • AZ-305 Topic5 #8 문제에서는 TDE를 활성화 해야하니, 만약에 TDE가 없으면 배포를 해줘야해서 Policy의 Effect를 deployIfNotExists로 설정하고 Azure policy assignment한다음 task에 대해 수정을 적용한다(Invoke a remediation task).
• Identity Requirements를 충족했는지는 확인하려면 Azure AD Identity Governance 를 사용함. (문제 전체가 포함되어있는지 모르겠음. AZ-305 Topic10 #1)
• Azure Web Application은 autoscaling을 지원하며, Traffic Manager는 region failover기능을 제공함(이전 문서에도 기록했듯이 region장애가 발생하면 다른 가까운 지역으로 트래픽을 전송시키게끔) (AZ-305 Topic16 #1)
  • 문제에서 마지막 질문이 "추가적인 region failover" 를 설계해야하는지 인데, Traffic Manager가 존재해서 추가로 설계할 필요가 없음 (답:  No)