# SUS 6 조직의 프로세스가 지속 가능성 목표를 어떻게 지원하고 있습니까?
개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다.
**Topics**
+ [SUS06-BP01 지속 가능성 개선을 신속하게 도입할 수 있는 방법 채택](sus_sus_dev_a2.md)
+ [SUS06-BP02 워크로드를 최신 상태로 유지](sus_sus_dev_a3.md)
+ [SUS06-BP03 구축 환경의 사용률 제고](sus_sus_dev_a4.md)
+ [SUS06-BP04 테스트에 관리형 Device Farm 사용](sus_sus_dev_a5.md)
# SUS06-BP01 지속 가능성 개선을 신속하게 도입할 수 있는 방법 채택
잠재적인 개선 사항을 검증하고, 테스트 비용을 최소화하며, 경미한 개선 사항을 제공하는 방법과 프로세스를 채택합니다.
**일반적인 안티 패턴:**
+ 지속 가능성을 위한 애플리케이션 검토는 프로젝트 시작 시 1번만 수행합니다.
+ 릴리스 프로세스가 너무 번거로워 리소스 효율성을 위해 사소한 변경 사항을 적용할 수 없어 워크로드가 오래되었습니다.
+ 지속 가능성을 위한 워크로드를 개선할 수 있는 메커니즘이 없습니다.
**이 모범 사례 확립의 이점:** 지속 가능성 개선 사항을 도입하고 추적하기 위한 프로세스를 수립함으로써 새로운 기능을 꾸준히 채택하고, 문제를 제거하고, 워크로드 효율성을 개선할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간
## 구현 가이드
잠재적인 지속 가능성 개선 사항을 프로덕션에 배포하기 전에 테스트하고 검증합니다. 개선 사항으로 실현될 미래의 잠재적 이익을 계산할 때 테스트 비용을 고려합니다. 적은 비용으로 경미한 개선 사항을 적용할 수 있는 테스트 방법을 개발합니다.
**구현 단계**
+ 지속 가능성 개선 사항을 위한 요구 사항을 개발 백로그에 추가합니다.
+ 반복적인 [개선 프로세스](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)를 사용하여 이러한 개선 사항을 식별, 평가, 우선순위 지정, 테스트 및 배포합니다.
+ 개발 프로세스를 지속적으로 개선하고 간소화합니다. 예를 들어, [지속적 통합(CI) 및 지속적 전달(CD) 파이프라인을 통해 소프트웨어 전송 프로세스를 자동화함으로써](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/) 잠재적인 개선 사항을 테스트하고 배포하여 작업량을 줄이고 수동 프로세스로 인한 오류를 제한합니다.
+ 테스트 비용을 줄이기 위해 최소 기능 구성 요소를 사용하여 잠재적인 개선 사항을 개발하고 테스트합니다.
+ 개선의 영향을 지속적으로 평가하고 필요에 따라 조정합니다.
## 리소스
**관련 문서:**
+ [AWS가 지원하는 지속 가능성 솔루션](https://aws.amazon.com/sustainability/)
+ [ Scalable agile development practices based on AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)(AWS CodeCommit에 기반한 확장 가능한 민첩한 개발 관행)
**관련 동영상:**
+ [Delivering sustainable, high-performing architectures(지속 가능한 고성능 아키텍처 제공)](https://www.youtube.com/watch?v=FBc9hXQfat0)
**관련 예시:**
+ [Well-Architected Lab - Turning cost & usage reports into efficiency reports](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/)(Well-Architected 실습 - 비용 및 사용량 보고서를 효율성 보고서로 전환)
# SUS06-BP02 워크로드를 최신 상태로 유지
워크로드를 최신 상태로 유지하여 효율적인 기능을 채택하고, 문제를 제거하며, 워크로드의 전반적인 효율성을 개선합니다.
**일반적인 안티 패턴:**
+ 시간이 지나면 현재 아키텍처가 정적 아키텍처가 되고 업데이트되지 않는다고 가정합니다.
+ 업데이트된 소프트웨어 및 패키지가 워크로드와 호환되는지 평가하는 시스템 또는 정기적인 주기가 없습니다.
**이 모범 사례 확립의 이점:** 워크로드를 최신 상태로 유지하기 위한 프로세스를 확립하면 새로운 기능을 도입하고 문제를 해결하며 워크로드 효율성을 개선할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
최신 운영 체제, 런타임, 미들웨어, 라이브러리 및 애플리케이션을 사용하면 워크로드 효율성을 개선하고 보다 효율적인 기술을 쉽게 채택할 수 있습니다. 공급업체가 자체적인 지속 가능성 목표를 충족할 수 있는 기능을 제공함에 따라, 최신 소프트웨어에는 워크로드의 지속 가능성에 미치는 영향을 보다 정확하게 측정하는 기능이 포함될 수도 있습니다. 정기적인 주기로 최신 기능 및 릴리스와 함께 워크로드를 최신 상태로 유지합니다.
**구현 단계**
+ 워크로드를 위한 새로운 기능 또는 인스턴스를 평가하기 위한 프로세스 및 일정을 정의합니다. 클라우드에서 민첩성을 활용하여 새 기능이 다음 작업을 수행하도록 워크로드를 어떻게 개선할 수 있는지 신속하게 테스트합니다.
+ 지속 가능성 영향 줄이기
+ 성능 효율성을 높이기
+ 계획된 개선 작업의 장애 요인 제거
+ 지속 가능성에 미치는 영향을 측정 및 관리할 수 있는 능력 증진
+ 워크로드 소프트웨어 및 아키텍처를 조사하여 업데이트하는 데 필요한 구성 요소를 식별합니다.
+ [AWS Systems Manager 인벤토리](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)를 사용하여 Amazon EC2 인스턴스에서 운영 체제(OS), 애플리케이션, 인스턴스 메타데이터를 수집하고 소프트웨어를 실행 중인 인스턴스, 소프트웨어 정책에 필요한 구성, 업데이트해야 할 인스턴스를 신속하게 파악합니다.
+ 워크로드 구성 요소의 업데이트 방법을 파악합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/sus_sus_dev_a3.html)
+ 업데이트 프로세스에 자동화를 사용하여 새 기능 배포에 필요한 작업 수준을 줄이고 수동 프로세스로 인한 오류를 제한합니다.
+ [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/)를 사용하면 클라우드 애플리케이션과 관련된 AMI, 컨테이너 이미지 및 기타 아티팩트를 자동으로 업데이트할 수 있습니다.
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)와 같은 도구를 사용하여 시스템 업데이트 프로세스를 자동화하고, [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)를 사용하여 활동을 예약할 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS 아키텍처 센터](https://aws.amazon.com/architecture)
+ [AWS의 새로운 소식](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
**관련 예시:**
+ [Well-Architected 실습 - 인벤토리 및 패치 관리](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
+ [실습: AWS Systems Manager](https://mng.workshop.aws/ssm.html)
# SUS06-BP03 구축 환경의 사용률 제고
워크로드를 개발, 테스트 및 구축하기 위한 리소스 활용도를 높입니다.
**일반적인 안티 패턴:**
+ 구축 환경을 수동으로 프로비저닝하거나 종료합니다.
+ 테스트, 구축 또는 릴리스 작업과 별개로 구축 환경을 계속 실행 중인 상태로 유지합니다(예: 개발 팀원이 근무 시간 외에 환경을 실행).
+ 구축 환경에 리소스를 과도하게 프로비저닝합니다.
**이 모범 사례 확립의 이점:** 빌드 환경의 활용률을 높임으로써 클라우드 워크로드의 전반적인 효율성을 개선하는 동시에 효과적으로 개발, 테스트 및 구축 작업을 수행하도록 빌더에 리소스를 할당할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
자동화와 코드형 인프라를 사용하여 필요 시 빌드 환경을 가동하고 사용하지 않을 때는 해당 환경을 종료합니다. 일반적인 패턴은 개발 담당 팀원의 근무 시간과 일치하는 가용 기간을 예약하는 것입니다. 테스트 환경은 프로덕션 구성과 매우 유사해야 합니다. 그러나 버스트 용량, Amazon EC2 스팟 인스턴스, 자동 확장 데이터베이스 서비스, 컨테이너 및 서버리스 기술과 함께 인스턴스 유형을 사용하여 개발 및 테스트 용량을 용도에 맞게 조정할 수 있는 기회를 찾아야 합니다. 테스트 요구 사항만 충족하도록 데이터 볼륨을 제한합니다. 테스트에서 프로덕션 데이터를 사용하는 경우 프로덕션 데이터를 공유하고, 데이터를 이동하지 않을 수 있는지 알아봅니다.
**구현 단계**
+ 코드형 인프라를 사용하여 구축 환경을 프로비저닝합니다.
+ 자동화를 사용하여 개발 및 테스트 환경의 수명 주기를 관리하고 구축 리소스의 효율성을 극대화합니다.
+ 전략을 사용하여 개발 및 테스트 환경의 활용도를 극대화합니다.
+ 현실적인 최소한의 재현 환경을 사용하여 잠재적 개선 사항을 개발 및 테스트합니다.
+ 가능한 경우 서버리스 기술을 사용합니다.
+ 온디맨드 인스턴스를 사용하여 개발자 디바이스를 보완합니다.
+ 버스트 용량이 포함된 인스턴스 유형, 스팟 인스턴스 및 기타 기술을 사용하여 사용량에 맞게 구축 용량을 조정합니다.
+ 배스천 호스트 플릿을 배포하는 대신 네이티브 클라우드 서비스를 도입하여 보안 인스턴스 셸에 액세스합니다.
+ 구축 작업에 따라 구축 리소스를 자동으로 확장합니다.
## 리소스
**관련 문서:**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 버스트 가능 성능 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeBuild란 무엇인가요? ](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
**관련 동영상:**
+ [ Continuous Integration Best Practices](https://www.youtube.com/watch?v=77HvSGyBVdU)(지속적 통합 모범 사례)
# SUS06-BP04 테스트에 관리형 Device Farm 사용
관리형 Device Farm을 사용하여 대표적인 하드웨어 집합에서 새 기능을 효율적으로 테스트합니다.
**일반적인 안티 패턴:**
+ 물리적 개별 디바이스에서 애플리케이션을 수동으로 테스트하고 배포합니다.
+ 앱 테스트 서비스를 사용하여 실제 물리적 디바이스에서 앱(예: Android, iOS 및 웹 앱)을 테스트하고 상호 작용하지 않습니다.
**이 모범 사례 확립의 이점:** 관리형 Device Farm을 사용하여 클라우드 지원 애플리케이션을 테스트하면 다음과 같은 여러 이점을 얻을 수 있습니다.
+ 여기에는 다양한 디바이스에서 애플리케이션을 테스트할 수 있는 보다 효율적인 기능이 포함되어 있습니다.
+ 테스트를 위한 사내 인프라가 필요하지 않습니다.
+ 비교적 널리 사용되지 않는 구형 하드웨어를 포함하여 다양한 디바이스 유형을 제공하므로 불필요한 디바이스 업그레이드가 필요하지 않습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
관리형 Device Farm을 사용하면 대표적인 하드웨어 집합에서 새 기능에 대한 테스트 프로세스를 간소화할 수 있습니다. 관리형 Device Farm은 사용 빈도가 낮은 오래된 하드웨어를 포함하여 다양한 디바이스 유형을 제공하며, 불필요한 디바이스 업그레이드로 인해 고객의 지속 가능성이 영향을 받지 않도록 합니다.
**구현 단계**
+ 테스트 요구 사항 및 플랜(예: 테스트 유형, 운영 체제 및 테스트 일정)을 정의합니다.
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)을 사용하여 클라이언트 측 데이터를 수집 및 분석하고 테스트 플랜을 구체화할 수 있습니다.
+ 테스트 요구 사항을 지원할 수 있는 관리형 Device Farm을 선택합니다. 예를 들어, [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)을 사용하여 변경 사항이 대표적인 하드웨어 집합에 미치는 영향을 테스트하고 이해할 수 있습니다.
+ 지속적 통합(CI) 및 지속적 전달(CD)을 사용하여 테스트를 예약하고 실행합니다.
+ [ Integrating AWS Device Farm with your CI/CD pipeline to run cross-browser Selenium tests](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)(CI/CD 파이프라인과 AWS Device Farm을 통합하여 교차 브라우저 Selenium 테스트 실행)
+ [ Building and testing iOS and iPadOS apps with AWS DevOps and mobile services](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)(AWS DevOps 및 모바일 서비스로 iOS 및 iPadOS 앱 구축 및 테스트)
+ 테스트 결과를 지속적으로 검토하고 필요한 개선을 수행합니다.
## 리소스
**관련 문서:**
+ [AWS Device Farm device list](https://awsdevicefarm.info/)(AWS Device Farm 디바이스 목록)
+ [ CloudWatch RUM 대시보드 보기 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)
**관련 예시:**
+ [ Android용 AWS Device Farm 샘플 앱 ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [ iOS용 AWS Device Farm 샘플 앱 ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [AWS Device Farm용 Appium Web 테스트 ](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)
**관련 동영상:**
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)(Amazon CloudWatch RUM을 통해 최종 사용자 인사이트로 애플리케이션 최적화)