Azure에서 지속 가능한 워크로드에 대한 애플리케이션 플랫폼 고려 사항

지속 가능한 워크로드를 설계하고 빌드하려면 애플리케이션을 배포하는 플랫폼을 이해해야 합니다. 이 섹션의 고려 사항 및 권장 사항을 검토하여 지속 가능성에 대해 더 잘 정보에 입각한 플랫폼 관련 결정을 내리는 방법을 알아 보세요.

플랫폼 및 서비스 업데이트

플랫폼 및 서비스를 최신 상태로 유지하여 최신 성능 향상 및 에너지 최적화를 활용합니다.

정기적으로 플랫폼 및 서비스 업데이트 검토

플랫폼 업데이트를 사용하면 최신 기능 및 기능을 사용하여 효율성을 높일 수 있습니다. 오래된 소프트웨어에서 실행하면 불필요한 성능 문제가 있는 최적이 않은 워크로드를 실행할 수 있습니다. 새 소프트웨어는 일반적으로 더 효율적인 경향이 있습니다.

Green Software Foundation 맞춤: 에너지 효율성

권장 사항:

• 사용할 수 있게 되면 더 새롭고 효율적인 서비스로 업그레이드합니다.
• 이전 버전과의 호환성 및 하드웨어 재사용 가능성을 고려합니다. 하드웨어 또는 OS가 지원되지 않는 경우 업그레이드가 가장 효율적인 솔루션이 아닐 수 있습니다.
• Azure Automation 업데이트 관리를 사용하여 소프트웨어 업데이트가 Azure VM에 배포되도록 합니다.

지역별 차이점

Microsoft Azure 데이터 센터는 지리적으로 전 세계로 분산되어 있으며 다양한 에너지원을 사용하여 구동됩니다. 워크로드를 배포할 위치를 결정하면 솔루션이 생성하는 배출에 상당한 영향을 미칠 수 있습니다.

Azure를 사용하여 데이터 센터에서 클라우드로의 지속 가능성에 대해 자세히 알아봅니다. Microsoft 데이터 센터 지속 가능성 팩트 시트에서 지역별 지속 가능성 정보를 참조하세요.

저탄소 지역에 배포

워크로드가 데이터를 처리하는 위치와 방법에 대해 더 나은 정보를 제공하는 결정을 내리기 위해 다른 지역보다 탄소 발자국이 낮은 Azure 지역에 대해 알아봅니다.

녹색 소프트웨어 파운데이션 맞춤: 탄소 효율성

권장 사항:

• 워크로드를 배포하는 데이터 센터가 재생 가능 및 저탄소 에너지원으로 구동될 가능성이 높기 때문에 탄소를 적게 사용합니다.
• 다음과 같은 잠재적 절충을 고려합니다.
  • 저탄소 지역으로 이동하는 데 걸리는 노력과 시간입니다.
  • 데이터 센터 간에 데이터를 마이그레이션하는 것은 탄소 효율적이지 않을 수 있습니다.
  • 저탄소 지역을 포함한 새로운 지역의 비용을 고려하면 비용이 더 많이 들 수 있습니다.
  • 워크로드가 대기 시간에 민감한 경우 더 낮은 탄소 지역으로 이동하는 것은 옵션이 아닐 수 있습니다.

탄소 강도가 낮을 때 처리

지구상의 일부 지역은 다른 지역보다 탄소가 더 강렬합니다. 따라서 워크로드를 배포하고 이를 다른 비즈니스 요구 사항과 결합하는 위치를 고려해야 합니다.

녹색 소프트웨어 재단 맞춤: 탄소 효율성, 탄소 인식

권장 사항:

• 사용 가능한 데이터가 있는 경우 에너지 조합이 주로 재생 가능 에너지원에서 온다는 것을 알 때 워크로드를 최적화하는 것이 좋습니다.
• 애플리케이션이 허용하는 경우 에너지 조건이 변경될 때 워크로드를 동적으로 이동하는 것이 좋습니다.
  • 예를 들어, 야간에 특정 워크로드를 실행하는 것이 재생 가능 에너지가 최고조에 달할 때 더 유익할 수 있습니다.

고객과 가까운 데이터 센터 선택

데이터 센터에 클라우드 워크로드를 쉽게 배포할 수 있습니다. 그러나 데이터 센터에서 고객까지의 거리를 고려합니다. 데이터 센터가 소비자와 더 먼 거리에 있으면 네트워크 순회가 증가합니다.

Green Software Foundation 맞춤: 에너지 효율성

권장 사항:

• 소비자와 가까운 데이터 센터에 배포하는 것이 좋습니다.

저탄소 강도 기간 동안 일괄 처리 워크로드 실행

워크로드의 일괄 처리를 사전에 설계하면 저탄소 기간 동안 집약적인 작업을 예약하는 데 도움이 될 수 있습니다.

Green Software Foundation 맞춤: 탄소 인식

권장 사항:

• 사용 가능한 데이터가 있는 경우 저탄소 강도 기간 동안 일괄 처리 워크로드 실행에 대한 컴퓨팅 사용률을 최대화하도록 배포를 계획합니다.
• 잠재적인 절충에는 저탄소 지역으로 이동하는 데 걸리는 노력과 시간이 포함될 수 있습니다. 또한 데이터 센터 간에 데이터를 마이그레이션하는 것은 탄소 효율적이지 않을 수 있으며 저탄소 지역을 포함한 새로운 지역의 비용은 더 비쌀 수 있습니다.

현대화

워크로드를 운영하는 방법을 선택할 때 이러한 플랫폼 디자인 결정을 고려합니다. Azure에서 관리되는 서비스 및 고도로 최적화된 플랫폼을 활용하면 본질적으로 더 나은 지속 가능성 태세에 기여하는 클라우드 네이티브 애플리케이션을 빌드하는 데 도움이 됩니다.

해당하는 경우 워크로드 컨테이너화

불필요한 리소스 할당을 줄이고 배포된 리소스를 더 잘 활용하기 위해 워크로드를 컨테이너화하는 옵션을 고려합니다.

Green Software Foundation 맞춤: 하드웨어 효율성

권장 사항:

• 컨테이너로 앱을 배포하면 Bin 압축을 수행하고 VM에서 더 많은 항목을 가져올 수 있으므로 궁극적으로 호스트 OS에서 라이브러리를 복제할 필요가 줄어듭니다.
• 전체 VM 관리의 오버헤드를 제거하고 물리적 컴퓨터당 더 많은 앱을 배포할 수 있습니다. 또한 컨테이너화는 서버 사용률을 최적화하고 서비스 안정성을 개선하여 운영 비용을 낮춥니다. 필요한 서버 수가 줄어들고 기존 서버를 더 잘 활용할 수 있습니다.
• 이러한 장단점 고려: 컨테이너화의 이점은 사용률이 높은 경우에만 실현됩니다. 또한 몇 개의 컨테이너에 대해서만 AKS( Azure Kubernetes Services ) 또는 Azure Red Had OpenShift (ARO)와 같은 오케스트레이터를 프로비전하면 전체 배출량이 더 높아질 수 있습니다.

PaaS 및 서버리스 워크로드로의 이동 평가

관리형 서비스는 다른 옵션보다 고도로 최적화되고 더 효율적인 하드웨어에서 작동하므로 탄소 영향이 줄어듭니다.

Green Software Foundation 맞춤: 하드웨어 효율성, 에너지 효율성

권장 사항:

• 완전히 관리되고 본질적으로 최적화된 플랫폼을 사용하여 인프라를 관리하지 않고 클라우드 네이티브 앱을 빌드합니다. 플랫폼은 크기 조정, 가용성 및 성능을 처리하여 궁극적으로 하드웨어 효율성을 최적화합니다.
• PaaS(Platform as a Service) 워크로드에 대한 디자인 원칙을 검토합니다.

가능한 경우 스폿 VM 사용

Azure 데이터 센터에서 사용되지 않는 용량을 생각해 보세요. 낭비되는 용량을 대폭 할인된 가격으로 활용하면 워크로드는 보다 지속 가능한 플랫폼 설계에 기여합니다.

Green Software Foundation 맞춤: 하드웨어 효율성

권장 사항:

• 스폿 VM을 활용하면 Azure 데이터 센터에서 사용되지 않는 용량을 활용하는 동시에 VM에서 상당한 할인을 받을 수 있습니다.
• 단점 고려: Azure에서 용량을 다시 필요로 하면 VM이 제거됩니다. 스폿 VM 제거 정책에 대해 자세히 알아봅니다.

오른쪽 크기 조정

워크로드가 할당된 모든 리소스를 사용하도록 보장하면 보다 지속 가능한 워크로드를 제공하는 데 도움이 됩니다. 대형 서비스는 더 많은 탄소 배출의 일반적인 원인입니다.

업무 시간 외 워크로드 끄기

유휴 작업 운영은 에너지를 낭비하고 탄소 배출을 추가하는 데 기여합니다.

Green Software Foundation 맞춤: 에너지 효율성, 하드웨어 효율성

권장 사항:

• 사용하지 않을 때는 개발 및 테스트 워크로드를 해제하거나 축소해야 합니다. 실행 중인 상태로 두는 대신 정기적인 업무 시간 외에 종료하는 것이 좋습니다.
  • 근무 시간 외 VM 시작/중지에 대해 자세히 알아봅니다.

자동 크기 조정 및 버스트 기능 활용

대부분의 용량이 활용되지 않는 대형 컴퓨팅 워크로드에서는 드물지 않으므로 궁극적으로 에너지 낭비가 발생합니다.

Green Software Foundation 맞춤: 하드웨어 효율성

권장 사항:

• Azure 워크로드 에 대한 자동 크기 조정 지침을 검토합니다.
• B 시리즈 버스트 가능 가상 머신 크기를 검토합니다.
• 수요의 정적 증가가 아니라 수요가 짧은 버스트 동안 불필요한 크기 조정을 방지하기 위해 튜닝이 필요할 수 있습니다.
• 애플리케이션 아키텍처를 크기 조정 고려 사항의 일부로 고려합니다. 예를 들어 논리적 구성 요소는 구성 요소의 일부만 크기 조정이 필요한 경우 전체 애플리케이션의 크기를 조정하는 것이 아니라 해당 구성 요소의 수요에 맞게 독립적으로 크기 조정해야 합니다 .

확장성 요구 사항 일치

플랫폼과 플랫폼이 솔루션의 확장성 요구 사항을 충족하는지 여부를 고려합니다. 예를 들어 전용 할당을 사용하여 리소스를 프로비전하면 사용되지 않거나 사용량이 부족한 컴퓨팅 리소스가 발생할 수 있습니다.

예:

• App Service 계획을 통해 ASE(Azure App Service Environment)를 프로비전하면 사용 여부에 관계없이 프로비전된 컴퓨팅이 발생할 수 있습니다.
• 소비 계층 대신 Azure API Management 프리미엄 계층을 선택하면 리소스를 완전히 활용하지 않는 경우 사용되지 않는 리소스가 발생합니다.

Green Software Foundation 맞춤: 하드웨어 효율성

권장 사항:

• 확장성과 관련된 플랫폼 디자인 결정을 검토하고 워크로드가 프로비전된 리소스를 최대한 많이 활용하는지 확인합니다.
• 이 장단점 고려: 일부 서비스는 리소스 사용률에 관계없이 특정 기능 및 기능에 액세스하기 위해 더 높은 계층이 필요합니다.
• 가능한 경우 동적 계층 크기 조정을 허용하는 서비스를 고려하고 선호합니다.

Virtual Machines 대한 Ampere Altra Arm 기반 프로세서 평가

Arm 기반 VM은 필요한 성능을 손상시키지 않는 비용 효율적이고 전력 효율적인 옵션을 나타냅니다.

Green Software Foundation 맞춤: 에너지 효율성

권장 사항:

• Ampere Altra Arm 기반 VM이 워크로드에 적합한 옵션인지 평가합니다.
• Azure에서 Ampere Altra Arm 기반 프로세서를 사용하는 Azure Virtual Machines 대해 자세히 알아보세요.

좀비 워크로드 삭제

사용하지 않는 워크로드 및 리소스를 검색하고 구독에 분리된 리소스가 있는 경우를 고려합니다.

녹색 소프트웨어 재단 맞춤: 하드웨어 효율성, 에너지 효율성

권장 사항:

• 분리된 워크로드 또는 리소스가 더 이상 필요하지 않은 경우 삭제합니다.

다음 단계

배포 및 테스트에 대한 디자인 고려 사항을 검토합니다.