서버리스 기술을 사용하여 클라우드에서 워크플로 및 반복 작업을 자동화하면 조직의 DevOps 팀 생산성을 크게 높일 수 있습니다. 서버리스 모델은 이벤트 기반 접근 방식에 어울리는 자동화 시나리오에 가장 적합합니다.
아키텍처
시나리오
이 문서에서는 다음과 같은 두 가지 주요 클라우드 자동화 시나리오를 보여 줍니다.
비용 센터 태그 지정: 이 구현은 각 Azure 리소스의 비용 센터를 추적합니다. Azure Policy 서비스는 그룹의 모든 새 리소스에 기본 비용 센터 ID를 태그로 지정합니다. Azure Event Grid는 리소스 생성 이벤트를 모니터링한 다음, Azure 함수를 호출합니다. 이 함수는 Microsoft Entra ID와 상호 작용하고 새 리소스에 대한 비용 센터 ID의 유효성을 검사합니다. ID가 다르면 태그를 업데이트하고 리소스 소유자에게 이메일을 보냅니다. Microsoft Entra ID에 대한 REST 쿼리는 단순성을 위해 모의됩니다. Microsoft Entra ID는 Microsoft Graph PowerShell 모듈 또는 Python용 MSAL(Microsoft 인증 라이브러리)을 사용하여 통합할 수도 있습니다.
제한 응답: 이 예제에서는 Azure Cosmos DB 데이터베이스의 제한을 모니터링합니다. Azure Monitor 경고는 Azure Cosmos DB에 대한 데이터 액세스 요청이 RU(요청 단위)의 용량을 초과할 때 트리거됩니다. Azure Monitor 작업 그룹은 이러한 경고에 대한 응답으로 자동화 함수를 호출하도록 구성됩니다. 함수는 RU를 더 높은 값으로 스케일링하여 용량을 늘리고 경고를 중지합니다.
참고
이러한 솔루션 외에도 이러한 작업을 수행할 수 있는 다른 솔루션이 더 있으며, 다음 그림은 서버리스 기술이 환경 신호(이벤트)에 어떻게 반응하고 환경 변화에 영향을 줄 수 있는지 보여줍니다. 네이티브 솔루션이 실용적인 경우 사용자 지정 솔루션보다 플랫폼 네이티브 솔루션을 사용합니다. 예를 들어 Azure Cosmos DB는 기본적으로 제한 응답 시나리오의 기본 대안으로 자동 크기 조정 처리량을 지원합니다.
이 시나리오에 대한 참조 구현은 GitHub에서 사용할 수 있습니다.
이러한 서버리스 클라우드 자동화 시나리오의 함수는 시스템 자동화에 가장 많이 사용되는 두 가지 스크립팅 언어인 PowerShell 및 Python으로 작성되는 경우가 많습니다. 이러한 함수는 Azure CLI의 Azure Functions Core Tools를 사용하여 배포됩니다. 또는 Az.Functions PowerShell cmdlet을 사용하여 Azure Functions를 배포 및 관리할 수도 있습니다.
워크플로
이벤트 기반 자동화 시나리오는 Azure Functions를 사용하여 구현하는 것이 가장 좋습니다. 이벤트 기반 자동화 시나리오는 다음과 같은 일반적인 패턴을 따릅니다.
리소스의 이벤트에 응답. Azure 리소스 또는 리소스 그룹 만들기, 삭제, 변경 등과 같은 이벤트에 대한 응답입니다. 이 패턴은 Event Grid를 사용하여 이러한 이벤트에 대한 함수를 트리거합니다. 비용 센터 태그 지정 시나리오는 이 패턴의 예입니다. 기타 일반적인 시나리오는 다음과 같습니다.
- DevOps 팀에게 새로 만든 리소스 그룹에 대한 액세스 권한 부여
- 리소스가 삭제되면 DevOps 팀에게 알림 보내기
- Azure VM(Virtual Machines)과 같은 리소스에 대한 유지 관리 이벤트에 응답
예약된 작업. 일반적으로 타이머 트리거 함수를 사용하여 실행되는 유지 관리 작업입니다. 이 패턴의 예는 다음과 같습니다.
- 밤에 리소스를 중지하고 아침에 시작
- 정기적으로 Blob Storage 콘텐츠를 읽고 Azure Cosmos DB 문서로 변환
- 더 이상 사용되지 않는 리소스를 주기적으로 검사하여 제거
- 자동화된 백업
Azure 경고 처리. 이 패턴은 Azure Monitor 경고 및 작업 그룹을 Azure Functions와 쉽게 통합하는 데 사용됩니다. 이 함수는 일반적으로 애플리케이션 및 인프라에서 발생하는 메트릭, 로그 분석 및 경고에 대한 응답으로 수정 작업을 수행합니다. 제한 응답 시나리오는 이 패턴의 예입니다. 기타 일반적인 시나리오는 다음과 같습니다.
- SQL Database가 최대 크기에 도달하면 테이블 자르기
- VM의 서비스가 잘못 중지된 경우 다시 시작
- 함수가 실패하면 알림 보내기
외부 시스템과 오케스트레이션. 이 패턴을 사용하면 워크플로를 오케스트레이션하는 Logic Apps를 사용하여 외부 시스템과 통합할 수 있습니다. Logic Apps 커넥터는 Microsoft 365와 같은 Microsoft 서비스뿐만 아니라 여러 타사 서비스와 쉽게 통합할 수 있습니다. Azure Functions는 실제 자동화에 사용할 수 있습니다. 비용 센터 태그 지정 시나리오는 이 패턴을 보여줍니다. 기타 일반적인 시나리오는 다음과 같습니다.
- 변경 요청 또는 승인과 같은 IT 프로세스 모니터링
- 자동화 작업이 완료되면 이메일 알림 보내기
webhook 또는 API로 노출. Azure Functions를 사용하는 자동화 작업은 HTTP 트리거를 사용하여 함수를 webhook/API로 노출하여 타사 애플리케이션 또는 명령줄 도구에 통합할 수 있습니다. PowerShell과 Python에서 제공하는 여러 인증 방법을 사용하여 함수에 대한 외부 액세스를 보호할 수 있습니다. 자동화는 앱별 외부 이벤트(예: Power Apps 또는 GitHub와 통합)에 대한 응답으로 발생합니다. 일반적인 시나리오는 다음과 같습니다.
- 서비스 오류에 대한 자동화 트리거
- 사용자를 조직의 리소스에 온보딩
ChatOps 인터페이스 만들기. 이 패턴을 사용하면 고객이 채팅 기반 운영 인터페이스를 만들고, 사람 협업에 따라 개발 및 운영 함수와 명령을 실행할 수 있습니다. 이를 통해 Azure Bot Framework와 통합하고 배포, 모니터링, 일반적인 질문 등에 Microsoft Teams 또는 Slack 명령을 사용할 수 있습니다. ChatOps 인터페이스는 프로덕션 인시던트 관리를 위한 실시간 시스템을 만들며, 각 단계는 채팅에 자동으로 문서화됩니다. 자세한 내용은 ChatOps가 DevOps에 도움이 되는 방법을 읽어보세요.
하이브리드 자동화. 이 패턴은 Azure App Service 하이브리드 연결을 사용하여 로컬 머신에 소프트웨어 구성 요소를 설치합니다. 이 구성 요소를 통해 해당 머신의 리소스에 안전하게 액세스할 수 있습니다. 하이브리드 환경을 관리하는 기능은 현재 Windows 기반 시스템에서 PowerShell 함수를 통해 사용할 수 있습니다. 일반적인 시나리오는 다음과 같습니다.
- 온-프레미스 머신 관리
- 점프 서버를 통해 방화벽으로 보호되는 다른 시스템(예: 온-프레미스 SQL Server) 관리
구성 요소
이 아키텍처는 다음과 같은 구성 요소로 구성됩니다.
Azure Functions. Azure Functions는 이 아키텍처에서 이벤트 기반의 서버리스 컴퓨팅 기능을 제공합니다. 함수는 이벤트 또는 경고에 의해 트리거될 때 자동화 작업을 수행합니다. 두 가지 시나리오에서 함수는 HTTP 요청을 통해 호출됩니다. 상태 비저장 및 멱등 함수를 개발하여 코드 복잡성을 최소화해야 합니다.
멱등 함수는 여러 차례 실행해도 같은 결과가 생성됩니다. 멱등성을 유지하기 위해 제한 시나리오에서 함수 크기 조정은 단순하게 유지됩니다. 실제 자동화에서는 적절하게 스케일 업 또는 다운해야 합니다. 함수를 작성할 때 Azure Functions의 성능 및 안정성 최적화를 읽고 모범 사례를 알아보세요.
Azure Logic Apps. Logic Apps는 기본 제공 커넥터를 사용하여 쉽게 구현할 수 있는 간단한 작업을 수행하는 데 사용할 수 있습니다. 이러한 작업은 이메일 알림부터 외부 관리 애플리케이션과의 통합에 이르기까지 다양할 수 있습니다. 타사 애플리케이션에서 Logic Apps를 사용하는 방법을 알아보려면 Azure의 기본 엔터프라이즈 통합을 읽어보세요.
Logic Apps는 코드 없는 또는 코드가 적은 비주얼 디자이너를 제공하며, 일부 자동화 시나리오에서는 단독으로 사용할 수 있습니다. 시나리오에 적합한 서비스를 알아보려면 Azure Functions와 Logic Apps 비교를 참조하세요.
Event Grid. Event Grid는 사용자 지정 이벤트(사용자 지정 토픽이라고도 함)뿐만 아니라 다른 Azure 서비스의 기본 제공 이벤트 지원도 제공합니다. 리소스 만들기와 같은 운영 이벤트는 Event Grid의 기본 제공 메커니즘을 사용하여 자동화 함수로 쉽게 전파할 수 있습니다.
Event Grid는 게시-구독 모델을 사용하여 이벤트 기반 자동화를 간소화하므로, HTTPS를 통해 전달되는 이벤트를 안정적으로 자동화할 수 있습니다.
Azure Monitor Azure Monitor 경고는 중요한 조건을 모니터링하다가 Azure Monitor 작업 그룹을 사용하여 수정 작업을 수행할 수 있습니다. 이러한 작업 그룹은 Azure Functions와 쉽게 통합됩니다. 데이터베이스 제한과 같은 인프라의 오류 조건을 감시하고 수정하는 데 유용합니다.
자동화 작업. 이 광범위한 블록은 자동화 기능을 제공하기 위해 함수가 상호 작용할 수 있는 다른 서비스를 나타냅니다. 예를 들어 첫 번째 시나리오와 같이 태그 유효성 검사에 대한 Microsoft Entra ID 또는 두 번째 시나리오와 같이 프로비전할 데이터베이스입니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
복원력
Azure Functions
HTTP 시간 제한 처리
더 긴 자동화 작업에 대한 HTTP 시간 제한을 방지하려면 이 이벤트를 Service Bus의 큐에 추가하고, 다른 함수에서 실제 자동화를 처리합니다. 제한 응답 자동화 시나리오에서는 이 패턴을 보여주며, 실제 Azure Cosmos DB RU 프로비전은 빠르게 이루어집니다.
Durable Functions는 호출 간의 상태를 유지하며, 위의 접근 방식을 대신하는 대안을 제공합니다. Durable Functions는 특정 언어만 지원합니다.
오류 로깅
자동화 작업을 수행할 때 발생하는 모든 오류를 이 함수가 기록하는 것이 모범 사례입니다. 이렇게 하면 오류 조건을 적절하게 해결할 수 있습니다. Azure Functions는 원격 분석 시스템인 Application Insights와의 통합을 기본적으로 지원합니다.
동시성
자동화 함수의 동시성 요구 사항을 확인합니다. 동시성은 host.json 파일에서 maxConcurrentRequests 변수를 설정하여 제한됩니다. 이 설정은 함수 앱에서 실행되는 동시 함수 인스턴스의 수를 제한합니다. 모든 인스턴스가 CPU 및 메모리를 사용하므로, CPU를 많이 사용하는 작업에서는 이 값을 조정해야 합니다. 함수 호출이 너무 느리거나 완료되지 않으면 maxConcurrentRequests를 낮춥니다. 자세한 내용은 동시성을 처리하도록 호스트 동작 구성 섹션을 참조하세요.
멱등원
자동화 함수가 멱등이어야 합니다. Azure Monitor와 Event Grid는 구독하는 이벤트가 확인됨, 발생함, 진행 중, 리소스가 프로비저닝 중, 성공적으로 만들어짐 등과 같은 진행 상황을 나타내는 경고 또는 이벤트를 내보내거나 잘못된 구성으로 인해 잘못된 경고를 보낼 수도 있습니다. 잘못된 이벤트 또는 잘못 구성된 이벤트가 원치 않는 결과를 초래하지 않도록 함수가 관련 경고 및 이벤트에 대해서만 작동하고 나머지는 무시하도록 해야 합니다. 자세한 내용은 동일한 입력에 대한 Azure Functions 디자인을 참조하세요.
Event Grid
워크플로에서 Event Grid를 사용하는 경우 시나리오에서 그리드를 막을 만큼 대량의 이벤트를 생성할 수 있는지 확인합니다. 전송이 승인되지 않을 때 이벤트를 처리하는 방법을 알아보고 그에 따라 논리를 수정하려면 Event Grid 메시지 배달 및 다시 시도를 참조하세요. 비용 센터 워크플로는 리소스 그룹의 리소스 생성 이벤트만 감시하므로 이에 대한 추가 검사를 구현하지 않습니다. 구독 전체에서 만들어지는 리소스를 모니터링하면 더 많은 이벤트가 생성될 수 있으므로 보다 복원력 있는 처리가 필요합니다.
Azure Monitor
대량의 경고가 생성되고 자동화에서 Azure 리소스를 업데이트하는 경우 Azure Resource Manager의 제한 한도에 도달할 수 있습니다. 이렇게 되면 해당 구독의 나머지 인프라에 부정적인 영향을 미칠 수 있습니다. Azure Monitor에서 생성되는 경고의 빈도를 제한하여 이 상황을 방지해야 합니다. 특정 오류에 대해 생성되는 경고를 제한할 수도 있습니다. 자세한 내용은 Azure Monitor 경고에 대한 설명서를 참조하세요.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
함수에 대한 액세스 제어
권한 부여 수준을 설정하여 HTTP 트리거 함수에 대한 액세스를 제한합니다. 익명 인증을 사용하면 http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>과 같은 URL을 사용하여 함수에 쉽게 액세스할 수 있습니다. 함수 수준 인증은 URL에 함수 키를 요구하여 http 엔드포인트를 난독 처리할 수 있습니다. 이 수준은 function.json 파일에서 설정합니다.
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "Request",
"methods": [
"get",
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "Response"
}
]
}
프로덕션 환경의 경우 함수를 보호하기 위한 추가 전략이 필요할 수 있습니다. 이러한 시나리오의 함수는 Azure 플랫폼 내에서 다른 Azure 서비스에 의해 실행되며, 인터넷에 노출되지 않습니다. webhook로 액세스되는 함수에는 함수 권한 부여로 충분할 때가 있습니다.
다음과 같이 함수 인증 위에 보안 계층을 추가하는 것이 좋습니다.
- 클라이언트 인증서로 인증
- App Service 인증을 사용하도록 설정하여 호출자가 함수를 호스트하는 디렉터리의 일부이거나 액세스 권한을 갖도록 합니다.
함수 수준 인증은 Azure Functions를 사용하는 Azure Monitor 작업 그룹에 사용할 수 있는 유일한 옵션입니다.
타사 애플리케이션 또는 서비스에서 함수를 호출해야 하는 경우 API Management 계층을 사용하여 함수에 대한 액세스를 제공하는 것이 좋습니다. 이 계층은 인증을 적용해야 합니다. API Management에는 Azure Functions와 통합된 소비 계층이 있으므로, API가 실행되는 경우에만 비용을 지불하면 됩니다. 자세한 내용은 OpenAPI를 사용하여 함수를 만들고 노출을 참조하세요.
호출하는 서비스에서 서비스 엔드포인트 또는 프라이빗 링크를 지원하는 경우 다음과 같은 비용이 많이 드는 옵션을 고려할 수 있습니다.
- 가상 네트워크의 함수를 잠그고 액세스를 제한할 수 있는 전용 App Service 요금제를 사용합니다. 사용량 기반 서버리스 모델에서는 불가능합니다.
- 함수 앱에서 사용할 전용 가상 네트워크가 있는 Azure Functions Premium 요금제를 사용합니다.
이러한 옵션의 가격 책정 및 기능을 비교하려면 Azure Functions 스케일링 및 호스팅을 참조하세요.
함수가 액세스할 수 있는 항목 제어
Microsoft Entra 기능인 Azure 리소스에 대한 관리 ID는 함수가 다른 Azure 리소스 및 서비스를 인증하고 액세스하는 방법을 간소화합니다. 코드는 Microsoft Entra ID로 관리되므로 인증 자격 증명을 관리할 필요가 없습니다.
두 가지 종류의 관리 ID가 있습니다.
시스템이 할당한 관리 ID: Azure 리소스의 일부로 생성되며 여러 리소스 간에 공유할 수 없습니다. 리소스가 삭제되면 같이 삭제됩니다. Azure 리소스가 하나이거나 독립적인 ID가 필요한 시나리오에 사용합니다. 두 시나리오 모두 단일 리소스만 업데이트하므로 시스템이 할당한 ID를 사용합니다. 관리 ID는 또 다른 리소스를 업데이트할 때만 필요합니다. 예를 들어 함수는 관리 ID 없이 리소스 태그를 읽을 수 있습니다. 시스템이 할당한 ID를 함수에 추가하려면 다음 지침을 참조하세요.
사용자가 할당한 관리 ID: 독립 실행형 Azure 리소스로 만들어집니다. 여러 리소스에서 공유할 수 있으며, 더 이상 필요 없으면 명시적으로 삭제해야 합니다. 사용자가 할당한 ID를 함수에 추가하는 방법은 다음 지침을 참조하세요. 다음가 같은 시나리오에 사용합니다.
- 단일 ID를 공유할 수 있는 여러 리소스에 액세스해야 합니다.
- 프로비저닝하는 동안 리소스를 보호할 수 있도록 사전 권한 부여가 필요합니다.
- 자주 재활용되는 리소스가 있지만 권한을 일관적으로 유지해야 합니다.
ID가 Azure 함수에 할당되었으면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 리소스에 액세스할 수 있는 역할을 ID에 할당합니다. 예를 들어 리소스를 업데이트하려면 기여자 역할을 함수의 ID에 할당해야 합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
Azure 가격 계산기를 사용하여 비용을 예측합니다. 다음은 비용 절감을 위해 고려해야 하는 사항입니다.
Azure Logic Apps
논리 앱에는 종량제 가격 책정 모델이 있습니다. 논리 앱이 실행될 때마다 트리거, 작업 및 커넥터 실행이 측정됩니다. 트리거를 포함하여 성공적이거나 실패한 모든 작업은 실행으로 간주됩니다.
논리 앱에는 고정 가격 책정 모델도 있습니다. Azure 가상 네트워크의 보안 리소스와 통신하는 논리 앱을 실행해야 하는 경우 ISE(통합 서비스 환경)에서 만들 수 있습니다.
자세한 내용은 Azure Logic Apps용 가격 책정 모델을 참조하세요.
이 아키텍처의 논리 앱은 비용 센터 태그 지정 시나리오에서 워크플로를 오케스트레이션하는 데 사용됩니다.
기본 제공 커넥터는 자동화 작업이 완료되면 Azure Functions에 연결하고 이메일 알림을 보내는 데 사용됩니다. 함수는 HTTP 트리거를 사용하여 webhook/API로 노출됩니다. 논리 앱은 HTTPS 요청이 발생할 때만 트리거됩니다. 함수가 지속적으로 특정 기준을 폴링하고 확인하는 디자인에 비해 비용 효율적인 방법입니다. 모든 폴링 요청은 작업으로 계량됩니다.
자세한 내용은 Logic Apps 가격 책정을 참조하세요.
Azure Functions
Azure Functions는 다음 세 가지 가격 책정 요금제로 제공됩니다.
사용 플랜. 함수가 실행되는 시간에만 요금을 지불하는 가장 비용 효율적인 서버리스 요금제입니다. 이 요금제에서는 함수를 한 번에 최대 10분 동안 실행할 수 있습니다.
프리미엄 플랜. 전용 가상 네트워크, 긴 실행 기간 등과 같은 추가 요구 사항이 있는 자동화 시나리오에는 Azure Functions 프리미엄 플랜을 사용하는 것이 좋습니다. 이러한 함수는 최대 1시간 동안 실행할 수 있으며 백업 실행, 데이터베이스 인덱싱 또는 보고서 생성과 같은 더 긴 자동화 작업에 대해 선택해야 합니다.
App Service 계획. Azure App Service 하이브리드 연결을 사용하는 하이브리드 자동화 시나리오에는 App Service 요금제를 사용해야 합니다. 이 요금제에서 만든 함수는 웹앱과 마찬가지로 제한 없이 실행할 수 있습니다.
이러한 자동화 시나리오에서 Azure Functions는 Microsoft Entra ID에서 태그를 업데이트하거나 RU를 더 높은 값으로 확장하여 Azure Cosmos DB 구성을 변경하는 등의 작업에 사용됩니다. 사용 플랜은 작업이 대화형이며 오래 실행되지 않는 이 사용 사례에 적합합니다.
Azure Cosmos DB
Azure Cosmos DB는 프로비저닝된 처리량 및 사용된 스토리지에 대한 시간당 요금을 청구합니다. 프로비저닝된 처리량은 초당 요청 단위(RU/s)로 표현되며 삽입, 읽기와 같은 일반적인 데이터베이스 작업에 사용할 수 있습니다. 스토리지는 저장된 데이터 및 인덱스에 사용되는 GB당 요금이 청구됩니다. 자세한 내용은 Azure Cosmos DB 가격 책정 모델을 참조하세요.
이 아키텍처에서 Azure Cosmos DB에 대한 데이터 액세스 요청이 RU(요청 단위)의 용량을 초과하면 Azure Monitor가 경고를 트리거합니다. Azure Monitor 작업 그룹은 이러한 경고에 대한 응답으로 자동화 함수를 호출하도록 구성됩니다. 함수는 RU를 더 높은 값으로 스케일링합니다. 이렇게 하면 워크로드에 필요한 리소스 요금만 시간 단위로 지불하면 되므로 비용을 절감할 수 있습니다.
워크로드 비용을 빠르게 예상하려면 Azure Cosmos DB 용량 계산기를 사용합니다.
자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.
배포 고려 사항
애플리케이션의 동작을 관리하는 중요한 자동화 워크플로의 경우 효율적인 DevOps 파이프라인을 사용하여 가동 중지 시간 제로 배포를 달성해야 합니다. 자세한 내용은 서버리스 백 엔드 배포를 참조하세요.
자동화에서 여러 애플리케이션을 다루는 경우 자동화에 필요한 리소스를 별도의 리소스 그룹에 유지합니다. 자동화에서 단일 애플리케이션을 다루는 경우 자동화와 애플리케이션 리소스 간에 단일 리소스 그룹을 공유할 수 있습니다.
워크플로에 여러 자동화 함수가 포함된 경우 한 시나리오에 맞는 함수를 단일 함수 앱으로 그룹화합니다. 자세한 내용은 함수 앱 관리를 참조하세요.
애플리케이션을 배포할 때 애플리케이션을 모니터링해야 합니다. Application Insights를 사용하여 개발자가 성능을 모니터링하고 문제를 검색할 수 있도록 하는 것이 좋습니다.
자세한 내용은 Microsoft Azure Well-Architected Framework의 DevOps 섹션을 참조하세요.
Azure 리소스에 대한 명령적 작업
위의 두 시나리오에서 최종적으로 직접 Azure Resource Manager 상호 작용을 통해 Azure 리소스 상태가 변경되었습니다. 이는 의도된 결과이지만, 수정된 리소스가 처음에 Bicep 또는 Terraform 템플릿과 같이 선언적으로 배포된 경우 환경에 미치는 영향을 고려해야 합니다. 이러한 변경 내용이 원본 템플릿에 다시 복제되지 않는 한, 해당 템플릿을 다음에 사용하면 이 자동화를 통해 수행된 변경 작업이 실행 취소될 수 있습니다. 템플릿을 통해 정기적으로 배포되는 Azure 리소스에 명령적 변경 내용을 혼합할 때 미치는 영향을 고려해야 합니다.
시나리오 배포
비용 센터 시나리오를 배포하려면 GitHub의 배포 단계를 참조하세요.