이 문서에 설명된 솔루션은 Azure에서 호스트되는 애플리케이션에 대한 지속 가능성 모델을 만드는 데 도움이 될 수 있습니다. 이 모델은 시간이 지남에 따라 애플리케이션의 탄소 영향 및 효율성을 채점할 수 있는 프록시를 사용합니다. 점수를 SCI(소프트웨어 탄소 강도) 점수라고 합니다. 애플리케이션의 탄소 출력 변화를 측정하기 위한 기준을 제공합니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
데이터 흐름
- SCI 점수를 계산하는 데 사용할 애플리케이션 데이터 원본을 구성합니다. 데이터는 Azure Portal의 탄소 최적화 블레이드에서 제공하는 배출 측정값이거나 Microsoft가 아닌 원본 또는 시스템의 프록시 측정값일 수 있습니다.
- 탄소 배출 데이터를 데이터 레이크로 내보냅니다.
- Azure Functions 또는 Azure Logic Apps와 같은 이벤트 처리기를 사용하여 SCI 점수를 계산합니다. 출력은 단위당 그램으로 방출되는 탄소의 양이며, 여기서 단위 는 애플리케이션 배율 인수 또는 프록시를 기반으로 하는 근사치를 나타냅니다.
- Azure Functions, Logic Apps 또는 Azure Automation Runbook과 같은 기술을 사용하여 애플리케이션에서 수요 셰이핑을 트리거하거나 애플리케이션의 미리 정의된 에코 모드를 시작합니다.
- Power BI를 사용하여 시간에 따른 점수 및 해당 변형을 보고하고 시각화합니다.
구성 요소
- Azure Portal의 탄소 최적화 블레이드는 리소스 그룹 수준에서 Azure 워크로드의 탄소 배출 측정값을 제공합니다.
- 지속 가능성용 클라우드 API는 탄소 최적화를 위한 기본 데이터를 제공합니다. 구독의 배출에 대한 정보를 검색하는 데 사용할 수 있습니다.
- Application Insights 는 APM(애플리케이션 성능 관리)을 제공하는 Azure Monitor의 기능입니다. 사용자가 앱을 사용하는 방법에 대한 강력한 인사이트를 얻는 데 도움이 될 수 있습니다. 이 지식을 사용하여 애플리케이션의 효율성 향상에 대한 데이터 기반 결정을 내릴 수 있습니다.
- Azure Blob Storage 는 Azure 탄소 최적화, 사용자 지정 계산 또는 배출을 위한 다른 프록시의 배출 정보를 저장합니다.
- Azure Data Lake 는 대량의 데이터를 원래 형식으로 수집하고 저장하는 중앙 집중식 리포지토리입니다. 그런 다음 데이터를 처리하고 다양한 분석 요구 사항에 대한 기초로 사용할 수 있습니다.
- Azure Logic Apps 를 사용하면 코드가 거의 또는 전혀 없는 자동화된 워크플로를 만들고 실행할 수 있습니다. 비주얼 디자이너를 사용하고 미리 빌드된 작업에서 선택하여 프록시 원본, 데이터 스토리지 및 효율성 계산 시스템을 통합하고 관리하는 워크플로를 빠르게 만들 수 있습니다.
- Azure Functions 를 사용하면 작은 코드 단위를 실행할 수 있습니다. 필요에 따라 리소스 크기를 자동으로 조정하고 실제 실행 시간에 대해서만 비용을 지불합니다. 이를 사용하여 지속 가능성 계산을 수행하고 Blob Storage 또는 데이터 레이크에 저장할 수 있습니다.
- Azure Automation 은 Runbook을 통해 프로세스 자동화를 제공합니다. Runbook을 사용하여 효율성을 개선하기 위해 애플리케이션에 영향을 줄 수 있는 PowerShell 코드를 사용하여 복잡한 논리를 구현할 수 있습니다. 이 서비스는 오류 및 운영 비용을 줄여 비즈니스 가치를 추가할 수도 있습니다.
- Power BI 를 사용하면 데이터를 실시간 인사이트를 제공하는 분석 및 보고서로 전환할 수 있습니다.
대안
이 문서에 설명된 Azure 서비스는 유사한 서비스로 대체될 수 있습니다. 기존 리소스의 밀도와 사용률을 높이려면 환경에 이미 배포된 Azure 서비스 또는 도구를 사용하여 인프라에 미치는 영향을 최소화하여 계산을 수행합니다.
- Power BI 대시보드를 Azure Monitor 통합 문서 또는 Azure Managed Grafana 서비스로 대체할 수 있습니다.
- Application Insights를 Elasticsearch APM(애플리케이션 성능 관리) 또는 OpenAPM과 같은 다른 APM(애플리케이션 성능 관리) 도구로 대체할 수 있습니다.
- 테이블 또는 비정형 데이터 형식의 데이터는 MySQL 또는 MariaDB, Azure Cosmos DB 및 MongoDB와 같은 모든 레코드 시스템에 보존할 수 있습니다.
- 실행 중인 Azure Functions 또는 Logic Apps 공간이 있는 경우 기존 배포에서 정기적으로 계산을 실행할 수 있습니다.
- 애플리케이션 리소스가 여러 리소스 그룹에 분산된 경우 태그를 사용하여 비용 데이터의 상관 관계를 지정하고 애플리케이션에서 내보낸 탄소 양을 계산할 수 있습니다.
시나리오 정보
이 아키텍처는 Azure 및 기타 원본에서 탄소 최적화 데이터를 수집하여 애플리케이션의 환경 영향을 포괄적으로 볼 수 있도록 설계되었습니다. 데이터는 Azure 탄소 최적화에서 수집됩니다. 비 Azure 환경의 경우 프록시를 사용하여 관련 탄소 메트릭을 검색합니다. 데이터가 통합된 후 SCI 계산을 수행하여 전체 탄소 발자국을 평가합니다. 그런 다음, 결과는 장기 보존을 위해 Azure Storage 계정 또는 데이터 레이크에 저장되어 BI 분석 및 기록 보고를 가능하게 합니다. 이 접근 방식은 다양한 인프라에서 탄소 영향에 대한 중앙 집중식 추적을 보장하고 전략적 지속 가능성 노력을 지원합니다.
탄소 배출 정보는 Azure Portal 탄소 최적화 블레이드에서 부분적으로 수집되고 가능한 경우 프록시를 통해 부분적으로 계산됩니다.
다음 두 가지 주요 이유로 Azure 탄소 최적화 데이터를 수집하려면 별도의 아키텍처를 사용해야 합니다.
- Azure 탄소 최적화 데이터는 지난 12개월 동안만 저장되고 표시됩니다(롤링 창에서). 탄소 발자국의 장기 추적이 필요한 경우 전용 시스템은 자세한 기록 정보의 보존을 보장합니다.
- 애플리케이션은 여러 인프라에 걸쳐 있을 수 있으며 Azure는 하나의 구성 요소로만 사용됩니다. 별도의 아키텍처를 사용하면 모든 환경에서 탄소 영향을 중앙 집중식으로 모니터링하여 전체적인 관점을 제공하고 보다 포괄적인 지속 가능성 인사이트를 보장할 수 있습니다.
참고 항목
온실 가스는 이산화탄소로만 구성된 것이 아니며 모두 환경에 동일한 영향을 미치지는 않습니다. 예를 들어, 메탄 1톤은 80톤의 이산화탄소와 동일한 가열 효과를 나타냅니다. 이 문서에서는 모든 항목이 CO2와 동등한 측정값으로 정규화됩니다. 탄소에 대한 모든 참조는 CO2와 동등한 참조입니다.
데이터 원본
일반적으로 변수가 거의 없는 프록시 수식을 만들어야 합니다. 선택한 프록시 메트릭은 애플리케이션의 동작 및 성능을 나타내야 합니다.
이러한 메트릭은 다음 예제에서 사용됩니다.
- 탄소 배출 API에서 검색되는 인프라의 탄소 배출입니다 . 이 API는 Azure Portal의 배출 영향 대시보드 및 탄소 최적화 블레이드 모두에 대한 원본입니다. 데이터는 리소스 그룹 수준에서 사용할 수 있으므로 애플리케이션의 배출을 더 쉽게 추적할 수 있습니다.
- Application Insights에서 수집된 애플리케이션의 성능 및 크기 조정 메트릭:
- 애플리케이션에 대한 배율 인수(API 호출, 서버 요청 또는 기타 메트릭)
- CPU 사용량
- 메모리 사용량
- 응답 시간(보내기 및 받기)
필요한 메트릭을 가져오기 위해 Application Insights를 설정하는 방법에 대한 자습서는 ASP.NET Core 애플리케이션에 대한 Application Insights를 참조 하세요.
수식에 다음과 같은 다른 변수를 추가할 수 있습니다.
- 에지 서비스 및 인프라 탄소 배출.
- 전기 생산 및 수요는 시간에 따라 달라지므로 사용자가 연결하는 시간입니다.
- 시간이 지남에 따라 성능이 어떻게 변하는지 알려줄 수 있는 앱의 다른 메트릭입니다.
이 수식을 사용자 수를 반영할 수 있는 점수로 작성하면 탄소 점수에 가장 가까운 근사치를 만듭니다. 이 점수는 앱의 지속 가능성에 대한 추가 변경 및 개선에 대한 벤치마크입니다.
비용은 애플리케이션 성능과 관련된 또 다른 고려 사항입니다. 대부분의 경우 성능 효율성과 비용 및 탄소 절감 간의 직접적인 상관 관계를 설정할 수 있습니다. 이러한 상관 관계는 다음과 같은 가정으로 이어집니다.
- 성능이 더 높지만 비용이 동일하면 앱을 최적화하고 탄소 배출량을 줄입니다.
- 비용이 감소하지만 성능이 동일하면 앱을 최적화하고 탄소 배출량을 줄입니다.
- 성능과 비용이 모두 증가하면 앱을 최적화하지 않았고 탄소 배출량을 증가시켰습니다.
- 비용이 증가하지만 성능이 저하되거나 동일한 경우 앱을 최적화하지 않았고 탄소 배출량을 증가시켰습니다(또는 에너지 비용이 더 높아 탄소 배출량 증가의 원인이기도 합니다).
애플리케이션의 SCI 점수, 비용 및 성능 간의 상관 관계는 모든 애플리케이션에 대해 고유하며 여러 요인에 따라 달라집니다. 이러한 세 변수에 대한 데이터를 수집하여 세 가지의 변형을 예측하고 애플리케이션 아키텍처 및 패턴에 대한 정보에 입각한 결정을 내릴 수 있는 상관 관계 알고리즘을 만들 수 있습니다.
계산
여기에 설명된 시나리오에서는 사용되는 프록시에 대한 불연속 계산을 구성할 수 없습니다. 대신 배출 영향 대시보드 수집된 데이터가 시작점으로 처리됩니다. SCI 기준 계산은 다음과 같습니다.
SCI = C*R
이 수식에서는 다음을 수행합니다.
C
는 애플리케이션의 탄소 배출량입니다. 이 값은 애플리케이션이 Azure에 배포되는 방식의 영향을 받습니다. 예를 들어 모든 애플리케이션 리소스가 단일 리소스 그룹에 있는 경우 해당 리소스 그룹에C
대한 탄소 배출입니다.참고 항목
현재 애플리케이션에 대한 다른 배출원은 아키텍처 및 에지/사용자 동작에 따라 달라지므로 무시됩니다. 데이터에 프록시를 사용하는 경우 다음 단계에서 이러한 원본을 고려할 수 있습니다.
R
는 애플리케이션의 배율 인수입니다. 이는 기간, API 요청, 웹 요청 또는 기타 메트릭에 대한 평균 동시 사용자 수일 수 있습니다. 이 값은 배포 공간뿐만 아니라 애플리케이션 사용의 전반적인 영향을 고려하는 점수로 이어지기 때문에 중요합니다.
물론 이 계산의 또 다른 중요한 측면은 에너지 그리드에 재생 가능 또는 대체 에너지원(예: 태양광 발전)이 있을 수 있지만 다른 경우에는 없을 수 있기 때문에 시간이 지남에 따라 에너지 소비 장치 또는 시스템의 탄소 배출량이 달라집니다. 따라서 정밀도를 높이기 위해 가능한 가장 짧은 기간으로 시작하는 것이 중요합니다. 예를 들어 일별 또는 시간별 계산으로 시작할 수 있습니다.
탄소 배출 API는 현재 리소스 그룹 수준에서 구독 내의 서비스에 따라 월별 탄소 정보를 제공합니다. 제공된 REST API를 사용하여 애플리케이션에 대한 모든 지속 가능성 데이터를 보유하는 데이터 레이크로 배출 데이터를 내보낼 수 있습니다.
데이터 저장소
대시보드 또는 보고서에 연결할 수 있는 솔루션에 수집한 탄소 및 탄소 프록시 정보를 저장해야 합니다. 이렇게 하면 시간이 지남에 따라 탄소 점수를 시각화하고 정보에 입각한 선택을 할 수 있습니다. 지속 가능성을 개선하고 Azure Well-Architected Framework 모범 사례에 맞게 실행 가능한 최소 시스템을 사용하는 것이 좋습니다. (자세한 내용은 를 참조하세요 .Azure에서 지속 가능한 워크로드에 대한 데이터 및 스토리지 디자인 고려 사항 및 Azure 의 지속 가능한 워크로드에 대한 애플리케이션 플랫폼 고려 사항. Azure Data Lake Storage는 이 아키텍처에서 사용됩니다.
데이터 상관 관계
애플리케이션의 탄소, 성능 및 비용에 대한 데이터 수집을 시작하면 애플리케이션과 관련된 상관 관계 알고리즘을 만들 수 있고 비용, 성능 및 탄소 최적화를 계획할 때 지침을 제공하는 중요한 정보가 제공됩니다.
자세한 내용은 Azure Machine Learning에 대한 알고리즘을 선택하는 방법을 참조 하세요.
데이터 표시
사용자 지정된 Azure Monitor 대시보드 및 간단한 Power BI 대시보드를 포함하여 다양한 방법으로 데이터 및 계산을 표시할 수 있습니다.
SCI 점수는 무엇을 트리거할 수 있나요?
지속 가능성 점수를 알게 된 후에는 어떻게 개선할 수 있을지 궁금할 것입니다.
프록시를 사용하여 애플리케이션의 탄소 영향을 채점할 수 있는 경우 다음 단계는 점수에서 불리한 조건에 의해 트리거될 수 있는 작업을 정의하는 데 초점을 맞추는 것입니다. 이러한 조건의 몇 가지 예는 다음과 같습니다.
- 에너지 생산과 수요는 사상 최고치이며 따라서 생산비용이 많이 듭니다.
- 전기는 사용할 수 없습니다. 이 조건은 자연 재해 또는 지정학적 충돌로 인해 발생할 수 있습니다.
- 리소스 과다 사용 또는 공급망 문제로 인해 에지 인프라를 갑자기 사용할 수 없습니다.
애플리케이션에 영향을 줄 수 있는 실패 지점을 식별할 수 있는 경우 탄소 급증에 대한 애플리케이션 복원력을 위해 수행할 작업을 결정할 수 있습니다.
다음 작업 중 하나를 수행합니다.
Arcchitected Framework 설명서에 설명된 대로 앱의 서비스 및 기능의 정상적인 저하를 적용합니다.
애플리케이션의 에코 모드 버전을 만듭니다. 에코 모드는 최소한의 기능을 제공하는 애플리케이션의 더 간단하고, 작고, 저렴하고, 지속 가능한 버전입니다. 탄소 배출 급증 시 이 버전으로 되돌릴 수 있습니다. 최종 사용자가 선택한 에코 버전을 사용하도록 교육하기만 하면 됩니다. 탄소 배출을 줄이는 대가로 더 간결한 인터페이스, 적은 그래픽 및 제한된 기능을 사용할 수 있는 "녹색 단추"를 제공할 수 있습니다.
사용자를 참여시키는 경우 기술적 변화와 함께 문화적 변화를 주도할 수 있는 기회를 만들 수 있습니다. - "에코 버전을 사용하여 x 양의 탄소를 절약" 또는 "탄소 점수를 y 양으로 끌어올릴 수 있습니다." - 사용자 행동에 대한 이해를 얻고 선택 사항을 반영하도록 에코 버전을 수정할 수 있습니다. (기능의 10%를 사용하고 에코 버전의 이상적인 사용자일 수도 있습니다.) - 전체 버전이 배출에 최적화되어 있으므로 최종적으로 두 버전을 병합할 수 있습니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 핵심 요소 개요를 참조하세요.
추가 보안을 위해 Azure Virtual Network 서비스 엔드포인트를 사용하여 Azure 서비스 리소스에 대한 공용 인터넷 액세스를 제거하여 가상 네트워크의 트래픽만 허용합니다.
이 방법을 사용하여 Azure에서 가상 네트워크를 생성한 다음, Azure 서비스에 대한 프라이빗 서비스 엔드포인트를 생성합니다. 그러면 이러한 서비스는 해당 가상 네트워크의 트래픽으로 제한됩니다. 게이트웨이를 통해 온-프레미스 네트워크에서 연결할 수도 있습니다.
온-프레미스에서 Azure Storage로 데이터를 이동하려면 온-프레미스 또는 Azure ExpressRoute에서 공용 IP 주소를 허용해야 합니다. 자세한 내용은 가상 네트워크에 전용 Azure 서비스 배포를 참조하세요.
보안 솔루션 설계에 대한 일반적인 지침은 Azure 보안 설명서를 참조하세요.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조 하세요.
몇 가지 대체 Azure 서비스를 사용하여 이 아키텍처를 배포할 수 있습니다. 비용과 탄소 배출을 절약하기 위해 의도적으로 최소한으로 유지되었습니다.
애플리케이션 배포에 이미 있는 동등한 서비스를 사용하는 것이 좋습니다. 각 아키텍처 구성 요소에 대한 가격 책정 정보를 사용할 수 있습니다.
배출 영향 대시보드, Azure 탄소 최적화 및 Microsoft Cost Management 보고서는 무료입니다.
성능 효율성
성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조 하세요.
이 아키텍처의 주요 목적은 비용과 탄소에 미치는 영향을 최소화하는 프로세스를 통해 애플리케이션에 대한 지속 가능성 점수를 제공하는 것입니다. 대부분의 구성 요소는 사용 및 트래픽에 따라 독립적으로 확장할 수 있는 PaaS(Platform as a Service) 및 서버리스 Azure 서비스입니다.
이 시나리오에서는 대시보드 및 스토리지 인터페이스가 대규모 사용 및 상담을 위한 것이 아닙니다. 많은 수의 사용자에게 제공하려는 경우 다음 옵션 중 하나를 고려할 수 있습니다.
- 추출된 데이터를 변환하고 다른 시스템에 저장하여 분리합니다.
- Data Lake Storage 또는 Azure Table Storage를 Azure Cosmos DB와 같은 확장성 있는 데이터 구조 대안으로 대체합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Paola Annis | 수석 고객 환경 엔지니어링 관리자
- Davide Bedin | 선임 클라우드 솔루션 설계자, 애플리케이션 혁신
기타 기여자:
- Chad Kittel | 주 소프트웨어 엔지니어
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
이 문서는 Green Software Foundation의 원칙과 방법론에 부합합니다. 더 친환경적인 애플리케이션을 만드는 다음 단계는 특정 탄소 조건이 충족될 때 트리거를 실시간으로 자동화할 수 있도록 탄소 인식 SDK를 애플리케이션에 포함하는 것입니다.
Azure 워크로드를 최적화하기 위한 권장 사항은 지속 가능성 클라우드 워크로드 지침을 참조 하세요.