AKS(Azure Kubernetes Service)의 지속 가능한 소프트웨어 엔지니어링 사례

지속 가능한 소프트웨어 엔지니어링 원칙은 지속 가능한 애플리케이션을 정의, 빌드, 실행하는 데 도움이 되는 역량 집합입니다. 전반적인 목표는 애플리케이션의 모든 측면에 대한 탄소 발자국을 줄이는 것입니다. 지속 가능성을 위한 Azure Well-Architected Framework 지침은 Green Software Foundation의 지속 가능한 소프트웨어 엔지니어링 원칙과 일치하며 지속 가능한 소프트웨어 엔지니어링의 원칙에 대한 개요를 제공합니다.

지속 가능한 소프트웨어 엔지니어링은 우선 순위와 초점을 전환합니다. 대부분의 경우에는 소프트웨어를 설계하고 실행할 때 빠른 성능과 낮은 대기 시간이 강조됩니다. 지속 가능한 소프트웨어 엔지니어링은 최대한 탄소 배출량을 줄이는 데 초점을 둡니다.

• 지속 가능한 소프트웨어 엔지니어링 원칙을 적용하면 총 네트워크 이동 감소와 같은 더 빠른 성능이나 짧은 대기 시간을 제공할 수 있습니다.
• 탄소 배출량을 줄이기 위해서는 우선 순위가 낮은 워크로드를 지연시키는 등의 방식으로 성능이 느려지거나 대기 시간이 늘어날 수 있습니다.

다음 지침은 AKS(Azure Kubernetes Service)를 사용하여 Azure에서 빌드하거나 작동하는 서비스에 중점을 둡니다. 이 문서에는 디자인 및 구성 검사 목록, 권장 디자인 사례, 구성 옵션이 포함되어 있습니다. 지속 가능한 소프트웨어 엔지니어링 원칙을 자신의 애플리케이션에 적용하기 전에 해당 애플리케이션의 우선 순위, 요구, 장단점을 검토하세요.

필수 조건

• Well-Architected Framework 지속 가능성 지침을 이해하면 안정적이고 효율적인 고품질 클라우드 아키텍처를 생성하는 데 도움이 될 수 있습니다. 지속 가능한 워크로드에 대해 자세히 읽고 Microsoft Azure Well-Architected 검토 평가를 사용하여 워크로드를 검토하는 것으로 시작하는 것이 좋습니다.
• 비즈니스 요구 사항이 클러스터 및 워크로드 아키텍처와 구성 모두에 직접적으로 영향을 미칠 수 있으므로 애플리케이션을 빌드할 때 비즈니스 요구 사항을 명확하게 정의하는 것이 매우 중요합니다. 기존 애플리케이션을 빌드하거나 업데이트할 때 애플리케이션의 전체적인 수명 주기와 함께 Well-Architected Framework 지속 가능성 디자인 영역을 검토합니다.

공동 책임 모델 이해

지속 가능성은 플랫폼에서 AKS 클러스터를 설계하고 배포하는 고객 또는 파트너와 클라우드 공급자 간의 공동 책임입니다. 데이터 센터가 지속 가능성에 최적화되더라도 AKS를 배포하면 AKS가 자동으로 지속 가능해지지 않습니다. 올바르게 최적화되지 않은 애플리케이션은 여전히 필요 이상으로 많은 탄소를 배출할 수 있습니다.

지속 가능성을 위한 공동 책임 모델에 대해 자세히 알아봅니다.

설계 원칙

• 탄소 효율성: 가능한 한 최소한의 탄소를 배출합니다.

  탄소 효율적인 클라우드 애플리케이션은 최적화된 애플리케이션이며 시작점은 비용 최적화입니다.

• 에너지 효율: 가능한 최소한의 에너지를 사용합니다.

  에너지 효율성을 높이는 한 가지 방법은 가장 높은 활용률로 실행하며 하드웨어 효율성도 향상시키는 서버를 사용하여 가능한 적은 수의 서버에서 애플리케이션을 실행하는 것입니다.

• 하드웨어 효율성: 내재된 탄소를 최대한 적게 사용합니다.

  하드웨어 효율성을 높이는 두 가지 주요 방식이 있습니다.

  • 최종 사용자 디바이스의 경우 하드웨어 수명을 연장합니다.
  • 클라우드 컴퓨팅의 경우 리소스 사용률을 높입니다.

• 탄소 인식: 전기가 깨끗할 때 더 많은 일을 하고 상대적으로 더러운 때는 일을 덜 합니다.

  탄소 사용을 인식한다는 것은 수요를 늘리거나 줄여서 탄소 집약도의 변화에 대응하는 것을 의미합니다.

디자인 패턴 및 사례

각 디자인 영역에서 자세한 권장 사항을 검토하기 전에 AKS에서 지속 가능한 워크로드를 빌드할 수 있도록 다음 디자인 패턴을 신중하게 고려하는 것이 좋습니다.

디자인 패턴	워크로드에 적용	클러스터에 적용
논리적 구성 요소의 독립적 크기 조정을 위한 디자인	✔️
이벤트 기반 크기 조정을 위한 디자인	✔️
상태 비저장 디자인 목표	✔️
클러스터 및 노드 자동 업데이트 사용		✔️
지원되는 추가 기능 및 확장 설치	✔️	✔️
해당하는 경우 워크로드 컨테이너화	✔️
에너지 효율적인 하드웨어 사용		✔️
확장성 요구 사항을 충족하고 자동 확장 및 버스팅 기능 활용		✔️
업무 시간 외에 워크로드 및 노드 풀 끄기	✔️	✔️
사용되지 않는 리소스 삭제	✔️	✔️
리소스 태그 지정	✔️	✔️
스토리지 활용 최적화	✔️	✔️
사용자에게 가장 가까운 지역 선택		✔️
노드 간 네트워크 순회 감소		✔️
서비스 메시를 사용하여 평가		✔️
로그 컬렉션 최적화	✔️	✔️
캐시 정적 데이터	✔️	✔️
TLS 종료 사용 여부 평가	✔️	✔️
클라우드 네이티브 네트워크 보안 도구 및 컨트롤 사용	✔️	✔️
취약성 검사	✔️	✔️

애플리케이션 설계

보다 지속 가능한 애플리케이션 디자인을 위해 애플리케이션을 최적화하는 방법에 대해 자세히 알아보려면 이 섹션을 살펴봅니다.

논리적 구성 요소의 독립적인 확장을 위한 디자인

마이크로 서비스 아키텍처는 논리 구성 요소의 독립적인 크기 조정을 허용하고 수요에 따라 크기가 조정될 수 있으므로 필요한 컴퓨팅 리소스를 줄일 수 있습니다.

• Dapr Framework 또는 기타 CNCF 프로젝트를 사용하면 애플리케이션 기능을 여러 마이크로 서비스로 분할하여 독립적으로 논리 구성 요소 크기를 조정할 수 있습니다.

이벤트 기반 확장을 위한 디자인

HTTP 요청, 큐 길이 및 클라우드 이벤트와 같은 관련 비즈니스 메트릭을 기반으로 워크로드 크기를 조정하면 리소스 사용률을 낮춰 탄소 배출량을 줄일 수 있습니다.

• 수요가 없을 때 0으로 스케일 다운할 수 있도록 이벤트 기반 애플리케이션을 빌드할 때 Keda를 사용합니다.

상태 비저장 디자인을 목표로 설정

디자인에서 상태를 제거하면 워크로드가 작동하는 데 필요한 인메모리 또는 온디스크 데이터가 줄어듭니다.

• 불필요한 네트워크 로드, 데이터 처리 및 컴퓨팅 리소스를 줄이려면 상태 비저장 디자인을 고려합니다.

애플리케이션 플랫폼

이 섹션을 탐색하여 지속 가능성에 대해 더 나은 정보에 입각한 플랫폼 관련 결정을 내리는 방법을 알아봅니다.

클러스터 및 노드 자동 업데이트 사용

최신 클러스터는 불필요한 성능 문제를 방지하고 최신 성능 개선 및 컴퓨팅 최적화의 이점을 보장합니다.

• 클러스터 자동 업그레이드를 사용하도록 설정하고 GitHub Actions를 사용하여 보안 업데이트를 자동으로 노드에 적용하여 클러스터에 최신 개선 사항을 적용합니다.

지원되는 추가 기능 및 확장 설치

AKS 지원 정책이 적용되는 추가 항목과 확장은 클러스터에 지원되는 추가 기능을 제공하는 동시에 클러스터 수명 주기 전반에 걸쳐 최신 성능 개선 및 에너지 최적화의 이점을 활용할 수 있게 해줍니다.

• KEDA를 추가 항목으로 설치합니다.
• GitOps Dapr를 확장으로 설치합니다.

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

컨테이너를 사용하면 계급구간 패킹이 가능하고 가상 머신보다 적은 컴퓨팅 리소스가 필요하므로 불필요한 리소스 할당을 줄이고 배포된 리소스를 더 잘 활용할 수 있습니다.

• Dockerfile 및 Kubernetes 매니페스트를 생성하여 애플리케이션 컨테이너화를 단순화하려면 Draft를 사용합니다.

에너지 효율적인 하드웨어 사용

Ampere의 클라우드 네이티브 프로세서는 클라우드의 고성능 및 전력 효율성 요구 사항을 모두 충족하도록 고유하게 설계되었습니다.

• Ampere Altra Arm 기반 프로세서가 있는 노드가 워크로드에 적합한 옵션인지 평가합니다.

확장성 요구 사항을 충족하고 자동 확장 및 버스팅 기능 활용

너무 큰 클러스터는 컴퓨팅 리소스 사용률을 극대화하지 않으며 이로 인해 에너지가 낭비될 수 있습니다. 애플리케이션 요구 사항에 따라 올바른 클러스터 크기 조정 및 독립적 확장이 가능하도록 애플리케이션을 서로 다른 노드 풀로 분할합니다. AKS 클러스터 용량이 부족해지면 추가 Pod를 서버리스 노드로 스케일 아웃하도록 AKS에서 ACI로 확장하고 워크로드에서 할당된 모든 리소스를 효율적으로 사용하도록 보장합니다.

• 애플리케이션의 확장성 요구 사항에 맞게 클러스터 크기를 조정합니다. 가상 노드에서 클러스터 자동 크기 조정기를 사용하여 컴퓨팅 리소스 사용률을 빠르게 스케일링하고 극대화합니다.
• 또한 네임스페이스 수준에서 리소스 할당량을 적용하고 수요가 없을 때 사용자 노드 풀 크기를 0으로 조정할 수 있습니다.

업무 시간 외에 워크로드 및 노드 풀 끄기

워크로드를 지속적으로 실행할 필요는 없으며 에너지 낭비와 탄소 배출량을 줄이기 위해 끌 수 있습니다. AKS 클러스터에서 노드 풀을 완전히 해제(중지)하여 컴퓨팅 비용도 절감할 수 있습니다.

• 노드 풀 중지/시작을 사용하여 업무 시간 외에는 노드 풀을 끕니다.
• KEDA CRON 배율 조정기를 사용하여 시간에 따라 워크로드(Pod)를 스케일 다운합니다.

운영 프로시저

워크로드 비용 및 탄소 효율성을 측정하고 지속적으로 개선하기 위한 환경을 설정하려면 이 섹션을 살펴봅니다.

사용하지 않는 리소스 삭제

참조되지 않은 이미지 및 스토리지 리소스와 같은 사용되지 않은 리소스는 하드웨어 및 에너지 효율성에 직접적인 영향을 미치므로 이러한 리소스를 식별하고 삭제해야 합니다. 지속적인 에너지 최적화가 보장되도록 특정 시점 작업이 아닌 프로세스로 사용하지 않는 리소스를 식별하고 삭제해야 합니다.

• Azure Advisor를 사용하여 사용되지 않은 리소스를 식별합니다.
• ImageCleaner를 사용하여 오래된 이미지를 정리하고 클러스터에서 위험 영역을 제거합니다.

리소스 태그 지정

적시에 올바른 정보와 인사이트를 얻는 것은 성능 및 리소스 사용률에 대한 보고서를 생성하는 데 중요합니다.

• 클러스터에 Azure 태그를 설정하여 워크로드를 모니터링할 수 있습니다.

스토리지

보다 지속 가능한 데이터 스토리지 아키텍처를 설계하고 기존 배포를 최적화하는 방법을 알아보려면 이 섹션을 살펴봅니다.

스토리지 사용률 최적화

데이터 검색 및 데이터 저장 작업은 에너지 및 하드웨어 효율성 모두에 상당한 영향을 미칠 수 있습니다. 올바른 데이터 액세스 패턴으로 솔루션을 설계하면 에너지 사용량과 내재된 탄소를 줄일 수 있습니다.

• 적절한 스토리지를 선택하고 스토리지 클래스를 사용하여 스토리지를 정의하여 스토리지 사용률이 낮은 애플리케이션의 요구 사항을 이해합니다.
• 볼륨을 동적으로 프로비전하여 스토리지 리소스 수 규모를 자동으로 조정하는 것이 좋습니다.

네트워크 및 연결

불필요한 탄소 배출량을 줄이기 위해 네트워크 효율성을 향상하고 최적화하는 방법을 알아보려면 이 섹션을 살펴봅니다.

사용자에게 가장 가까운 지역 선택

데이터 센터에서 사용자까지의 거리는 에너지 사용량과 탄소 배출량에 상당한 영향을 미칩니다. 네트워크 패킷이 이동하는 거리를 줄이면 에너지와 탄소 효율성이 모두 개선됩니다.

• 애플리케이션 요구 사항과 Azure 지역을 검토하여 대부분의 네트워크 패킷이 이동하는 지역과 가장 가까운 지역을 선택합니다.

노드 간 네트워크 순회 감소

단일 지역 또는 단일 가용성 영역에 노드를 배치하면 인스턴스 간의 실제 거리가 줄어듭니다. 그러나 중요 비즈니스용 워크로드의 경우 클러스터가 여러 가용성 영역에 분산되어 있어야 합니다. 이렇게 하면 더 많은 네트워크 순회가 발생하고 탄소 공간이 증가할 수 있습니다.

• 근접 배치 그룹 내에 노드를 배포함으로써 컴퓨팅 리소스가 실제로 서로 가까이 위치하도록 하여 네트워크 순회를 줄이는 것을 고려합니다.
• 중요한 워크로드의 경우 가용성 영역이 있는 근접 배치 그룹을 구성합니다.

서비스 메시를 사용하여 평가

서비스 메시는 일반적으로 사이드카 패턴에서 통신할 수 있도록 추가 컨테이너를 배포하여 더 많은 운영 기능을 제공합니다. 이로 인해 CPU 사용량과 네트워크 트래픽이 증가합니다. 그럼에도 불구하고 애플리케이션 레이어에서 인프라 레이어로 이동할 때 이를 통해 이러한 기능에서 애플리케이션을 분리할 수 있습니다.

• 사용 결정을 내리기 전에 서비스 메시 통신 구성 요소에서 생성되는 CPU 사용량 및 네트워크 트래픽의 증가를 신중하게 고려합니다.

로그 컬렉션 최적화

가능한 모든 원본(워크로드, 서비스, 진단 및 플랫폼 작업)에서 모든 로그를 전송하고 저장하면 스토리지와 네트워크 트래픽이 증가할 수 있으며 이로 인해 비용과 탄소 배출량이 영향을 받게 됩니다.

• 요구 사항을 지원하는 데 필요한 로그 데이터만 수집하고 유지하고 있는지 확인합니다. AKS 워크로드에 대한 데이터 수집 규칙을 구성하고 Log Analytics 비용 최적화를 위한 디자인 고려 사항을 구현합니다.

정적 데이터 캐시

CDN(Content Delivery Network)을 사용하면 네트워크를 통한 데이터 이동이 줄어들기 때문에 지속 가능한 방식으로 네트워크 트래픽을 최적화할 수 있습니다. 자주 읽는 정적 데이터를 사용자에게 더 가깝게 저장하여 대기 시간을 최소화하고 네트워크 트래픽 및 서버 부하를 줄이는 데 도움이 됩니다.

• CDN의 모범 사례를 준수해야 합니다.
• Azure CDN을 사용하여 사용된 대역폭을 줄이고 비용을 낮추는 것이 좋습니다.

보안

지속 가능하고 적절한 규모의 보안 태세로 이어지는 권장 사항에 대해 자세히 알아보려면 이 섹션을 살펴봅니다.

TLS 종료 사용 여부 평가

TLS(전송 계층 보안)는 웹 서버와 웹 브라우저 간에 전달되는 모든 데이터가 프라이빗하게 암호화된 상태로 유지되도록 합니다. 그러나 TLS를 종료하고 다시 설정하면 CPU 사용률이 증가하고 특정 아키텍처에서는 필요하지 않을 수 있습니다. 균형 잡힌 수준의 보안은 보다 지속 가능하고 에너지 효율적인 워크로드를 제공할 수 있는 반면, 높은 수준의 보안은 컴퓨팅 리소스 요구 사항을 증가시킬 수 있습니다.

• Application Gateway 또는 Azure Front Door 사용 시 TLS 종료에 대한 정보를 검토합니다. 보더 게이트웨이에서 TLS를 종료하고 비 TLS를 워크로드 부하 분산 장치와 워크로드에 계속 사용할 수 있는지 확인합니다.

클라우드 네이티브 네트워크 보안 도구 및 컨트롤 사용

Azure Font Door 및 Application Gateway는 웹 애플리케이션의 트래픽을 관리하는 데 도움이 되며 Azure Web Application Firewall은 네트워크 에지에서 OWASP 상위 10개 공격과 부하 차단 악성 봇에 대한 보호를 제공합니다. 이러한 기능을 사용하면 불필요한 데이터 전송을 제거하고 대역폭과 인프라 요구 사항을 줄여 클라우드 인프라에 대한 부담을 줄일 수 있습니다.

• AKS의 AGIC(Application Gateway 수신 컨트롤러)를 사용하여 네트워크 에지에서 원본에 도달하는 트래픽을 필터링하고 오프로드하여 에너지 사용량과 탄소 배출을 줄입니다.

취약성 검사

클라우드 인프라에 대한 대부분의 공격은 공격자의 직접적인 이익을 위해 배포된 리소스를 오용하여 사용량과 비용이 불필요하게 급증하도록 합니다. 취약성 검사 도구는 공격자의 기회 창을 최소화하고 잠재적인 악의적 리소스 사용을 완화하는 데 도움이 됩니다.

• 클라우드용 Microsoft Defender에 대한 권장 사항을 따릅니다.
• 불필요한 리소스 사용이 방지되도록 컨테이너용 Defender와 같은 자동화된 취약성 검사 도구를 실행합니다. 이러한 도구는 이미지에서 취약성을 식별하고 공격자의 공격 기회를 최소화하는 데 도움이 됩니다.

다음 단계

AKS의 Azure Well-Architected Framework 검토