AKS(Azure Kubernetes Service)의 지속 가능한 소프트웨어 엔지니어링 사례
지속 가능한 소프트웨어 엔지니어링 원칙은 지속 가능한 애플리케이션을 정의, 빌드, 실행하는 데 도움이 되는 역량 집합입니다. 전반적인 목표는 애플리케이션의 모든 측면에 대한 탄소 발자국을 줄이는 것입니다. 지속 가능성을 위한 Azure 잘 설계된 프레임워크 지침은 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 요청, 큐 길이 및 클라우드 이벤트와 같은 관련 비즈니스 메트릭을 기반으로 워크로드를 확장하는 경우 리소스 사용률 및 탄소 배출을 줄이는 데 도움이 될 수 있습니다.
- 요청이 없는 경우 이벤트 기반 애플리케이션을 빌드할 때 Keda를 사용하여 0으로 축소할 수 있습니다.
상태 비저장 디자인을 목표로 설정
디자인에서 상태를 제거하면 워크로드가 작동하는 데 필요한 인메모리 또는 온디스크 데이터가 줄어듭니다.
- 불필요한 네트워크 로드, 데이터 처리 및 컴퓨팅 리소스를 줄이려면 상태 비저장 디자인을 고려합니다.
애플리케이션 플랫폼
이 섹션을 탐색하여 지속 가능성에 대해 더 나은 정보에 입각한 플랫폼 관련 결정을 내리는 방법을 알아봅니다.
클러스터 및 노드 자동 업데이트 사용
최신 클러스터는 불필요한 성능 문제를 방지하고 최신 성능 개선 및 컴퓨팅 최적화의 이점을 보장합니다.
- 클러스터 자동 업그레이드를 사용하도록 설정하고 GitHub Actions를 사용하여 노드에 보안 업데이트를 자동으로 적용하여 클러스터에 최신 개선 사항이 있는지 확인합니다.
지원되는 추가 기능 및 확장 설치
AKS 지원 정책에서 다루는 추가 기능 및 확장은 클러스터에 지원되는 추가 기능을 제공하는 동시에 클러스터 수명 주기 내내 최신 성능 향상 및 에너지 최적화를 활용할 수 있도록 합니다.
- KEDA를 추가 기능으로 설치합니다.
- GitOps 및 Dapr을 확장으로 설치합니다.
해당하는 경우 워크로드 컨테이너화
컨테이너를 사용하면 계급구간 패킹이 가능하고 가상 머신보다 적은 컴퓨팅 리소스가 필요하므로 불필요한 리소스 할당을 줄이고 배포된 리소스를 더 잘 활용할 수 있습니다.
- Dockerfile 및 Kubernetes 매니페스트를 생성하여 애플리케이션 컨테이너화를 단순화하려면 Draft를 사용합니다.
에너지 효율적인 하드웨어 사용
Ampere의 클라우드 네이티브 프로세서는 클라우드의 고성능 및 전력 효율성 요구 사항을 모두 충족하도록 고유하게 설계되었습니다.
- Ampere Altra Arm 기반 프로세서가 있는 노드가 워크로드에 적합한 옵션인지 평가합니다.
확장성 요구 사항을 일치시키고 자동 크기 조정 및 버스트 기능을 활용합니다.
대형 클러스터는 컴퓨팅 리소스의 사용률을 최대화하지 않으며 에너지 낭비로 이어질 수 있습니다. 애플리케이션 요구 사항에 따라 클러스터 오른쪽 크기 조정 및 독립적인 크기 조정을 허용하도록 애플리케이션을 다른 노드 풀로 분리합니다. AKS 클러스터의 용량이 부족하면 AKS에서 ACI로 확장하여 추가 Pod를 서버리스 노드로 확장하고 워크로드가 할당된 모든 리소스를 효율적으로 사용하도록 합니다.
- 애플리케이션의 확장성 요구 사항에 맞게 클러스터 크기를 조정합니다. 가상 노드와 함께 클러스터 자동 크기 조정기를 사용하여 컴퓨팅 리소스 사용률을 빠르게 조정하고 최대화합니다.
- 또한 네임스페이스 수준에서 리소스 할당량을 적용하고 수요가 없는 경우 사용자 노드 풀을 0 으로 확장할 수 있습니다.
업무 시간 외에 워크로드 및 노드 풀 끄기
워크로드를 지속적으로 실행할 필요가 없으며 에너지 폐기물 및 탄소 배출을 줄이기 위해 꺼질 수 있습니다. AKS 클러스터에서 노드 풀을 완전히 해제(중지)하여 컴퓨팅 비용도 절감할 수 있습니다.
- 노드 풀 중지/시작을 사용하여 업무 시간 외에 노드 풀을 끕니다.
- KEDA CRON 스케일러를 사용하여 시간에 따라 워크로드(Pod)를 축소합니다.
운영 프로시저
워크로드 비용 및 탄소 효율성을 측정하고 지속적으로 개선하기 위한 환경을 설정하려면 이 섹션을 살펴봅니다.
사용하지 않는 리소스 삭제
하드웨어 및 에너지 효율성에 직접적인 영향을 주므로 참조되지 않은 이미지 및 스토리지 리소스와 같은 사용되지 않는 리소스를 식별하고 삭제해야 합니다. 지속적인 에너지 최적화를 보장하려면 사용되지 않는 리소스 식별 및 삭제를 지정 시간 활동이 아닌 프로세스로 처리해야 합니다.
리소스 태그 지정
적시에 올바른 정보와 인사이트를 얻는 것은 성능 및 리소스 사용률에 대한 보고서를 생성하는 데 중요합니다.
- 클러스터에 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 Front Door 및 Application Gateway는 웹 애플리케이션의 트래픽을 관리하는 데 도움이 되며, Azure Web Application Firewall은 OWASP 상위 10개 공격에 대한 보호를 제공하고 네트워크 에지에서 잘못된 봇을 로드합니다. 이러한 기능은 불필요한 데이터 전송을 제거하고 낮은 대역폭 및 적은 인프라 요구 사항으로 클라우드 인프라에 대한 부담을 줄이는 데 도움이 됩니다.
- AKS의 AGIC(Application Gateway 수신 컨트롤러)를 사용하여 네트워크 에지에서 원본에 도달하는 트래픽을 필터링하고 오프로드하여 에너지 사용량과 탄소 배출을 줄입니다.
취약성 검사
클라우드 인프라에 대한 대부분의 공격은 공격자의 직접적인 이익을 위해 배포된 리소스를 오용하여 사용량과 비용이 불필요하게 급증하도록 합니다. 취약성 검사 도구는 공격자의 기회 창을 최소화하고 잠재적인 악의적 리소스 사용을 완화하는 데 도움이 됩니다.
- 클라우드용 Microsoft Defender 권장 사항을 따릅니다.
- 불필요한 리소스 사용을 방지하기 위해 Defender for Containers와 같은 자동화된 취약성 검사 도구를 실행합니다. 이러한 도구는 이미지의 취약성을 식별하고 공격자에게 기회의 창을 최소화하는 데 도움이 됩니다.