# 지속 가능성
지속 가능성 원칙에는 클라우드 워크로드를 구축할 때 사용된 서비스의 영향을 이해하고, 전체 워크로드 수명 주기에 걸쳐 영향을 정량화하고, 이러한 영향을 줄이기 위한 설계 원칙과 모범 사례를 적용하는 작업이 포함됩니다. 구현 방법에 대한 선제적인 가이드는 [지속 가능성 원칙 백서에 나와 있습니다](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)단축할 수 있습니다.
**Topics**
+ [에 설명되어 있습니다](a-region-selection.md)
+ [수요에 맞춘 조정](a-alignment-to-demand.md)
+ [소프트웨어 및 아키텍처](a-sus-software-architecture.md)
+ [데이터](a-sus-data.md)
+ [하드웨어 및 서비스](a-sus-hardware-and-services.md)
+ [프로세스 및 문화](a-sus-process-and-culture.md)
# 에 설명되어 있습니다
**Topics**
+ [SUS 1 워크로드에 적합한 리전을 선택하려면 어떻게 해야 합니까?](w2aac19c17b7b5.md)
# SUS 1 워크로드에 적합한 리전을 선택하려면 어떻게 해야 합니까?
워크로드 리전의 선택은 성능, 비용 및 탄소 배출량을 포함한 KPI에 큰 영향을 미칩니다. 이러한 KPI를 효과적으로 개선하려면 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 워크로드의 리전을 선택해야 합니다.
**Topics**
+ [SUS01-BP01 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 리전 선택](sus_sus_region_a2.md)
# SUS01-BP01 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 리전 선택
비즈니스 요구 사항과 지속 가능성 목표를 기준으로 워크로드의 리전을 선택하여 성능, 비용 및 탄소 배출량을 비롯한 KPI를 최적화할 수 있습니다.
**일반적인 안티 패턴:**
+ 자신의 고유한 위치를 기준으로 워크로드의 리전을 선택합니다.
+ 모든 워크로드 리소스를 하나의 지리적 위치로 통합합니다.
**이 모범 사례 수립의 이점:** Amazon 재생 에너지 프로젝트와 가까운 곳이나 탄소 집약도가 낮은 리전에 워크로드를 배치하면 클라우드 워크로드의 탄소 배출량을 줄일 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간
## 구현 가이드
글로벌 네트워크 인프라가 함께 연결됨에 따라 AWS 클라우드는 리전 네트워크와 접속 지점(PoP)을 지속적으로 확장하고 있습니다. 워크로드 리전의 선택은 성능, 비용 및 탄소 배출량을 포함한 KPI에 큰 영향을 미칩니다. 이러한 KPI를 효과적으로 개선하려면 비즈니스 요구 사항과 지속 가능성 목표를 기준으로 워크로드의 리전을 선택해야 합니다.
**구현 단계**
+ 규정 준수, 사용 가능한 기능, 비용 및 지연 시간을 비롯한 비즈니스 요구 사항을 기준으로 다음 단계를 따라 워크로드의 잠재적 리전을 평가하고 후보 명단에 추가할 수 있습니다.
+ 필수 지역 규정에 따라 해당 리전이 이를 준수하는지 확인합니다.
+ [AWS 리전 서비스 목록](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)을 사용하여 해당 리전에 워크로드를 실행하는 데 필요한 서비스와 기능이 있는지 확인합니다.
+ [AWS Pricing Calculator](https://calculator.aws/)를 사용하여 각 리전의 워크로드 비용을 계산합니다.
+ 최종 사용자 위치와 각 AWS 리전 사이의 네트워크 지연 시간을 테스트합니다.
+ Amazon 재생 에너지 프로젝트 근처의 리전 및 그리드의 탄소 집약도가 다른 위치(또는 리전)보다 낮은 리전을 선택합니다.
+ 관련 지속 가능성 지침을 파악하여 [온실 가스 협약](https://ghgprotocol.org/)(시장 기반 및 위치 기반 방법)을 기준으로 매년 탄소 배출량을 추적 및 비교합니다.
+ 탄소 배출량을 추적하는 데 사용하는 방법을 기준으로 리전을 선택합니다. 지속 가능성 지침에 따른 리전 선택에 대한 자세한 내용은 [지속 가능성 목표를 기준으로 워크로드의 리전을 선택하는 방법](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)을 참조하세요.
## 리소스
**관련 문서:**
+ [탄소 배출량 추정치의 이해](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html)
+ [세계 속의 Amazon](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true)
+ [재생 에너지 방법론](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology)
+ [워크로드의 리전을 선택할 때 고려해야 할 사항](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
**관련 동영상:**
+ [지속 가능성 설계와 AWS 탄소 배출량 절감](https://www.youtube.com/watch?v=jsbamOLpCr8)
# 수요에 맞춘 조정
**Topics**
+ [SUS 2 클라우드 리소스를 비즈니스 요구에 어떻게 맞추시겠습니까?](sus-02.md)
# SUS 2 클라우드 리소스를 비즈니스 요구에 어떻게 맞추시겠습니까?
사용자 및 애플리케이션이 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 인프라를 지속적으로 확장하여 수요를 충족하고 사용자를 지원하는 데 필요한 최소 리소스만 활용하는지 확인합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용되지 않는 자산을 제거합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.
**Topics**
+ [SUS02-BP01 워크로드 인프라를 동적으로 확장](sus_sus_user_a2.md)
+ [SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정](sus_sus_user_a3.md)
+ [SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지](sus_sus_user_a4.md)
+ [SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화](sus_sus_user_a5.md)
+ [SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화](sus_sus_user_a6.md)
+ [SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화](sus_sus_user_a7.md)
# SUS02-BP01 워크로드 인프라를 동적으로 확장
클라우드의 탄력성을 활용하고 인프라를 동적으로 확장하여, 클라우드 리소스 공급을 수요에 맞게 조정하고 워크로드의 용량 초과 프로비저닝을 방지할 수 있습니다.
**일반적인 안티 패턴:**
+ 사용자 로드에 따라 인프라를 확장하지 않습니다.
+ 항상 인프라를 수동으로 확장합니다.
+ 조정 이벤트 후에 다시 축소하는 대신 증가된 용량을 그대로 둡니다.
**이 모범 사례 실천의 이점:** 워크로드 탄력성을 구성하고 테스트하면 클라우드 리소스 공급을 수요에 효율적으로 일치시키고 용량 초과 프로비저닝을 방지할 수 있습니다. 클라우드의 탄력성을 활용하여 수요가 급증하는 도중과 그 이후에 용량을 자동으로 확장하여 비즈니스 요구 사항을 충족하는 데 필요한 리소스만큼만 사용할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간
## 구현 가이드
클라우드는 수요 변화에 맞춰 다양한 메커니즘을 통해 리소스를 동적으로 확장 또는 축소할 수 있는 유연성을 제공합니다. 공급과 수요를 최적으로 일치시키면 워크로드 환경에 미치는 영향이 최소화됩니다.
수요는 고정되거나 가변적일 수 있으므로 관리에 부담이 되지 않도록 측정 기준과 자동화가 필요합니다. 애플리케이션은 인스턴스 크기를 수정하여 수직(위로 또는 아래로)으로 확장하거나 인스턴스 수를 수정하여 수평(안 또는 밖으로)으로 확장하거나 둘을 모두 조합하여 확장할 수 있습니다.
다양한 접근 방식을 사용하여 리소스 공급과 수요를 일치시킬 수 있습니다.
+ **타겟 추적 접근법:** 스케일링 지표를 모니터링하고 필요에 따라 용량을 자동으로 늘리거나 줄입니다.
+ **예측 확장:** 일일 및 주간 추세를 예상하여 확장할 수 있습니다.
+ **일정 기반 접근법:** 예측 가능한 부하 변화에 따라 직접 스케일링 일정을 설정합니다.
+ **서비스 스케일링:** 기본적으로 설계별로 확장되는 서버리스와 같은 서비스를 선택하거나 자동 스케일링 기능을 제공합니다.
활용률이 낮거나 없는 기간을 식별하고 리소스의 크기를 조정하여 초과 용량을 제거하고 효율성을 개선합니다.
## 구현 단계
+ 탄력성은 보유한 리소스의 공급을 해당 리소스의 수요에 맞춥니다. 인스턴스, 컨테이너 및 함수는 자동 스케일링과 함께, 또는 서비스의 기능을 사용하여 탄력성을 지원하는 메커니즘을 제공합니다. AWS는 사용자 로드가 적은 기간에 워크로드를 빠르고 쉽게 축소할 수 있도록 다양한 자동 스케일링 메커니즘을 제공합니다. 자동 스케일링 메커니즘의 예시는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_user_a2.html)
+ 확장은 대개 Amazon EC2 인스턴스나 AWS Lambda 함수 등의 컴퓨팅 서비스와 관련하여 설명하는 경우가 많습니다. [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 읽기/쓰기 용량 단위나 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 샤드와 같은 컴퓨팅 외의 서비스를 구성할 때는 수요에 일치시키는 것이 좋습니다.
+ 스케일 업 또는 스케일 다운 대한 지표가 배포 중인 워크로드 유형에 대해 검증되었는지 확인합니다. 동영상 트랜스코딩 애플리케이션을 배포하는 경우 100%의 CPU 활용률이 예상되므로, 기본 지표로 사용해서는 안 됩니다. 필요한 경우 [맞춤형 지표](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/)(예: 메모리 사용률)을 스케일링 정책에 사용할 수 있습니다. 올바른 지표를 선택하려면 Amazon EC2에 대한 다음 지침을 고려하세요.
+ 지표는 유효한 사용률 지표여야 하며 인스턴스가 얼마나 많이 사용되는지를 설명해야 합니다.
+ 지표 값은 Auto Scaling 그룹 내 인스턴스 수에 비례하여 늘거나 줄어야 합니다.
+ Auto Scaling 그룹에는 [수동 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) 대신 [동적 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)을 사용합니다. 또한, 동적 스케일링에는 [타겟 추적 스케일링 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)을 사용할 것을 권합니다.
+ 워크로드 배포에서 확장 및 축소 이벤트를 모두 처리할 수 있는지 확인합니다. 축소 이벤트에 대한 테스트 시나리오를 생성하여 워크로드가 예상대로 작동하고 사용자 환경에 영향(예: 스티키 세션 손실)을 미치지 않는지 확인합니다. [활동 기록](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)을 사용하여 Auto Scaling 그룹의 스케일링 활동을 확인할 수 있습니다.
+ 워크로드의 예측 가능한 패턴을 평가하고 예측 및 계획된 수요 변화에 따라 사전 예방적으로 확장합니다. 예측 스케일링에서는 용량을 과도하게 프로비저닝할 필요가 없습니다. 자세한 내용은 [Amazon EC2 Auto Scaling을 사용한 예측 스케일링](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)을 참조하세요.
## 리소스
**관련 문서:**
+ [Amazon EC2 Auto Scaling 시작하기](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and Kibana(Amazon OpenSearch Service, Amazon Kinesis Data Firehose 및 Kibana를 사용하여 사용자 행동 분석)](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [What is Amazon CloudWatch?(CloudWatch란 무엇인가요?)](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Monitoring DB load with Performance Insights on Amazon RDS(Amazon RDS의 성능 개선 도우미로 DB 로드 모니터링)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling(Amazon EC2 Auto Scaling을 사용한 예측 확장에 대한 기본 지원 소개)](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler(Karpenter - 고성능 오픈 소스 Kubernetes Cluster Autoscaler 소개)](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Deep Dive on Amazon ECS Cluster Auto Scaling(Elastic Container Service 클러스터 자동 스케일링 심층 분석)](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**관련 동영상:**
+ [Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2(더 정확하고, 더 빠르고, 더 저렴한 컴퓨팅: Amazon EC2 비용 최적화)(CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw)
**관련 예시:**
+ [실습: Amazon EC2 Auto Scaling 그룹 예시](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [실습: Karpenter를 사용하여 오토스케일링 구현](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정
지속 가능성 목표를 기준으로 서비스 수준에 관한 계약(SLA)을 검토 및 최적화하여 계속해서 비즈니스 필요를 충족하면서 워크로드를 지원하는 데 필요한 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 워크로드 SLA가 알려져 있지 않거나 모호합니다.
+ 가용성 및 성능에 대해서만 SLA를 정의합니다.
+ 모든 워크로드에 대해 동일한 설계 패턴(예: 다중 AZ 아키텍처)을 사용합니다.
**이 모범 사례 확립의 이점:** 지속 가능성 목표에 맞춰 SLA를 조정하면 비즈니스 요구 사항을 충족하면서 리소스 사용을 최적화할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
SLA는 클라우드 워크로드에서 예상되는 서비스 수준(예: 응답 시간, 가용성, 데이터 보존 등)을 정의합니다. SLA는 클라우드 워크로드의 아키텍처, 리소스 사용 및 환경 영향에 영향을 미칩니다. 주기적으로 SLA를 검토하여 허용 가능한 수준으로 서비스를 줄여 리소스 사용을 크게 줄이는 절충안을 제시합니다.
**구현 단계**
+ 비즈니스 요구 사항을 충족하되 초과하지는 않으면서 지속 가능성 목표를 지원하는 SLA를 정의 또는 재설계합니다.
+ 허용 가능한 수준으로 서비스를 줄여 지속 가능성에 미치는 영향을 크게 줄이는 절충안을 제시합니다.
+ **지속 가능성 및 신뢰성:** 가용성이 뛰어난 워크로드는 리소스를 더 많이 사용하는 경향이 있습니다.
+ **지속 가능성 및 성능:** 성능을 높이기 위해 리소스를 더 많이 사용하면 환경에 미치는 영향이 커질 수 있습니다.
+ **지속 가능성 및 보안:** 지나치게 안전한 워크로드는 환경에 미치는 영향이 커질 수 있습니다.
+ 비즈니스에 중요한 기능에 우선순위를 두고 중요하지 않은 기능에 대해 더 낮은 서비스 수준(예: 응답 시간 또는 복구 시간 목표)을 허용하는 설계 패턴(예: [AWS의 마이크로서비스](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html))을 사용합니다.
## 리소스
**관련 문서:**
+ [AWS 서비스 수준에 관한 계약(SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)
+ [SaaS 공급자의 서비스 수준 계약 중요성](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**관련 동영상:**
+ [Delivering sustainable, high-performing architectures(지속 가능한 고성능 아키텍처 제공)](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지
워크로드에서 사용되지 않는 자산을 폐기하여 수요를 지원하는 데 필요한 클라우드 리소스 수를 줄이고 낭비를 최소화합니다.
**일반적인 안티 패턴:**
+ 중복되거나 더 이상 필요하지 않은 자산에 대해 애플리케이션을 분석하지 않습니다.
+ 중복되거나 더 이상 필요하지 않은 자산을 제거하지 않습니다.
**이 모범 사례 확립의 이점:** 사용되지 않는 자산을 제거하면 리소스가 확보되고 워크로드의 전체 효율성이 향상됩니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
사용되지 않는 자산은 스토리지 공간 및 컴퓨팅 전력과 같은 클라우드 리소스를 소비합니다. 이러한 자산을 식별하고 제거함으로써 리소스를 확보하여 클라우드 아키텍처의 효율성을 높일 수 있습니다. 애플리케이션 자산(예: 사전 컴파일된 보고서, 데이터 세트, 정적 이미지 등)과 자산 액세스 패턴을 정기적으로 분석하여 중복된 자산, 활용률이 낮은 자산 및 잠재적 폐기 대상을 식별합니다. 이러한 중복 자산을 제거하여 워크로드의 리소스 낭비를 줄이세요.
**구현 단계**
+ 모니터링 도구를 사용하여 더 이상 필요하지 않은 정적 자산을 식별합니다.
+ 자산을 제거하기 전에 제거로 인해 아키텍처가 받는 영향을 평가합니다.
+ 플랜을 세우고 더 이상 필요하지 않은 자산을 제거합니다.
+ 중복 생성 자산을 통합하여 중복 처리를 제거합니다.
+ 애플리케이션을 업데이트하여 더 이상 필요 없는 자산을 생성하고 저장하지 않습니다.
+ 더 이상 필요하지 않은 관리 자산의 생산 및 저장을 중단하도록 제3자에게 지시합니다.
+ 생성된 중복 자산을 통합하도록 제3자에게 지시합니다.
+ 워크로드를 정기적으로 검토하여 사용되지 않는 자산을 식별하고 제거합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)(지속 가능성을 위한 AWS 인프라 최적화, 파트 II: 스토리지)
+ [AWS 계정에서 더 이상 필요하지 않은 활성 리소스를 종료하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**관련 동영상:**
+ [ How do I check for and then remove active resources that I no longer need on my AWS 계정?](https://www.youtube.com/watch?v=pqg9AqESRlg)(AWS 계정에서 더 이상 필요하지 않은 활성 리소스를 확인하고 제거하려면 어떻게 해야 하나요?)
# SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화
네트워크 트래픽이 이동해야 하는 거리를 단축하고 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄일 수 있는 워크로드의 클라우드 위치 및 서비스를 선택합니다.
** 일반적인 안티 패턴: **
+ 자신의 고유한 위치를 기준으로 워크로드의 리전을 선택합니다.
+ 모든 워크로드 리소스를 하나의 지리적 위치로 통합합니다.
+ 모든 트래픽이 기존 데이터 센터를 통과합니다.
**이 모범 사례 확립의 이점:** 사용자에게 가깝게 워크로드를 배치하면 지연 시간을 최대한 단축할 수 있고 동시에 네트워크 간 데이터 이동을 줄이고 환경에 미치는 영향을 줄일 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
AWS 클라우드 인프라는 리전, 가용 영역, 배치 그룹, 엣지 로케이션(예: [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 및 [AWS 로컬 영역)과](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)같은 위치 옵션을 중심으로 구축됩니다. 이러한 위치 옵션은 애플리케이션 구성 요소, 클라우드 서비스, 엣지 네트워크, 온프레미스 데이터 센터 간의 연결을 유지합니다.
워크로드의 네트워크 액세스 패턴을 분석하여 이러한 클라우드 위치 옵션을 사용하는 방법을 식별하고 네트워크 트래픽이 이동해야 하는 거리를 줄이십시오.
## 구현 단계
+ 워크로드의 네트워크 액세스 패턴을 분석하여 사용자가 애플리케이션을 사용하는 방법을 식별합니다.
+ 예를 들어 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 및 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)같은 모니터링 도구를 사용하여 네트워크 활동에 대한 데이터를 수집합니다.
+ 데이터를 분석하여 네트워크 액세스 패턴을 식별합니다.
+ 다음과 같은 주요 요소를 토대로 하여 워크로드 배포용 리전을 선택합니다.
+ **지속 가능성 목표:** 리전 선택 [에 설명되어 있습니다](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html).
+ **데이터 위치:** 데이터를 많이 사용하는 애플리케이션의 경우(예: 빅 데이터 및 기계 학습) 애플리케이션 코드는 최대한 데이터와 가까운 위치에서 실행되어야 합니다.
+ **사용자의 위치:** 사용자가 직접 사용하는 애플리케이션의 경우 워크로드의 사용자와 가까운 리전(또는 리전들)을 선택합니다.
+ **기타 제약 조건:** AWS 아키텍처 블로그 [워크로드의 리전을 선택할 때 고려해야 할 사항](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)에서 설명한 것처럼 비용 및 규정 준수 등의 제약을 고려해야 합니다.
+ 자주 사용되는 자산에 로컬 캐싱 또는 [AWS 캐싱 솔루션을](https://aws.amazon.com/caching/aws-caching/) 사용하여 성능을 개선하고 데이터 이동을 줄이며 환경에 미치는 영향을 줄입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+ 워크로드 사용자에게 더 가까운 위치에서 코드를 실행할 수 있는 서비스를 사용합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+ 연결 풀을 사용하여 연결을 재사용하고 필요한 리소스를 줄입니다.
+ 지속적 연결 및 동기식 업데이트에 의존하지 않는 분산 데이터 스토어를 사용하여 리전별 사용자 집단을 일관되게 지원합니다.
+ 사전 프로비저닝된 정적 네트워크 용량을 공유 동적 용량으로 교체하고 네트워크 용량의 지속 가능성에 미치는 영향을 다른 구독자와 공유합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking(지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 네트워킹)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache 설명서](https://docs.aws.amazon.com/elasticache/index.html)
+ [Amazon CloudFront란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
**관련 동영상:**
+ [Demystifying data transfer on AWS(AWS에서의 데이터 전송 알아보기)](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ 차세대 Amazon EC2 인스턴스의 네트워크 성능 확장 ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
**관련 예시:**
+ [AWS 네트워킹 워크숍](https://catalog.workshops.aws/networking/en-US)
+ [ 지속 가능성을 위한 설계 - 네트워크 간 데이터 이동 최소화 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화
팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 환경 지속 가능성에 미치는 영향을 최소화합니다.
**일반적인 안티 패턴:**
+ 팀원이 사용하는 디바이스가 클라우드 애플리케이션의 전반적인 효율성에 미치는 영향을 무시합니다.
+ 팀원이 사용하는 리소스를 수동으로 관리하고 업데이트합니다.
**이 모범 사례 확립의 이점:** 팀원 리소스를 최적화하면 클라우드 지원 애플리케이션의 전반적인 효율성이 향상됩니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
팀원이 서비스를 사용하는 데 활용하는 리소스, 예상 수명 주기, 재무 및 지속 가능성에 미치는 영향을 이해합니다. 이러한 리소스를 최적화하기 위한 전략을 구현합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 확장 가능한 인프라에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.
**구현 단계**
+ 사용 방식에 맞게 워크스테이션 및 기타 디바이스를 프로비저닝합니다.
+ 가상 데스크톱 및 애플리케이션 스트리밍을 사용하여 업그레이드 및 디바이스 요구 사항을 제한합니다.
+ 프로세서 또는 메모리 집약적인 태스크를 클라우드로 옮겨 탄력성을 활용합니다.
+ 디바이스 수명 주기에 대한 프로세스 및 시스템의 영향을 평가하고 비즈니스 요구 사항을 충족하면서 디바이스 교체 요구 사항을 최소화하는 솔루션을 선택합니다.
+ 디바이스에 대한 원격 관리를 구현하여 필요한 출장을 줄입니다.
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html)는 AWS 또는 온프레미스에서 실행 중인 노드를 원격으로 관리하는 데 도움이 되는 통합 사용자 인터페이스(UI) 환경입니다.
## 리소스
**관련 문서:**
+ [Amazon WorkSpaces란 무엇인가요?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [ Amazon WorkSpaces용 Cost Optimizer](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**관련 동영상:**
+ [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE)(AWS에서 Amazon Workspaces의 비용 관리)
# SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화
버퍼링 및 제한은 수요 곡선을 완화하고 워크로드에 필요한 프로비저닝 용량을 줄입니다.
**일반적인 안티 패턴:**
+ 클라이언트 요청은 필요하지 않아도 즉시 처리합니다.
+ 클라이언트 요청에 대한 요구 사항을 분석하지 않습니다.
**이 모범 사례 확립의 이점:** 수요 곡선을 완화하면 워크로드에 필요한 프로비저닝 용량이 줄어듭니다. 프로비저닝 용량을 줄이면 에너지 소비와 환경에 미치는 영향도 줄어듭니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
워크로드 수요 곡선을 완화하면 워크로드에 프로비저닝된 용량을 줄이고 환경에 미치는 영향도 줄일 수 있습니다. 아래 그림에 표시된 수요 곡선을 바탕으로 워크로드를 가정합니다. 이 워크로드에는 2개의 정점이 있으며, 이러한 정점을 처리하기 위해 주황색 선으로 표시된 리소스 용량이 프로비저닝됩니다. 이 워크로드에 사용되는 리소스와 에너지는 수요 곡선 아래의 영역이 아니라 프로비저닝된 용량 선 아래의 영역으로 표시됩니다. 이 2가지 정점을 처리하려면 프로비저닝된 용량이 필요하기 때문입니다.
![\[높은 프로비저닝 용량을 필요로 하는 2개의 고유한 정점이 있는 프로비저닝된 용량 파형입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)
버퍼링 또는 제한을 사용하여 수요 곡선을 수정하고 정점을 완화할 수 있습니다. 이렇게 되면 프로비저닝된 용량과 소비되는 에너지가 줄어듭니다. 클라이언트가 재시도를 수행할 때 제한을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다.
![\[버퍼링 또는 제한을 사용하여 만든 정점이 완화된 워크로드를 표시하는 파형 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/provisioned-capacity-2.png)
**구현 단계**
+ 클라이언트 요청을 분석하여 응답 방법을 결정합니다. 고려해야 할 질문은 다음과 같습니다.
+ 이 요청을 비동기식으로 처리할 수 있는가?
+ 클라이언트에 재시도 기능이 있는가?
+ 클라이언트에 재시도 기능이 있는 경우 현재 요청을 처리할 수 없으면 나중에 다시 시도해야 함을 소스에 알려주는 제한 기능을 구현할 수 있습니다.
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)를 사용하여 제한을 구현할 수 있습니다.
+ 재시도를 수행할 수 없는 클라이언트의 경우 수요 곡선을 완화하려면 버퍼를 구현해야 합니다. 버퍼는 서로 다른 속도로 실행되는 애플리케이션이 효과적으로 통신할 수 있도록 요청 처리를 연기합니다. 버퍼 기반 접근 방식은 대기열 또는 스트림을 사용하여 생산자의 메시지를 수락합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/)는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공하는 관리형 서비스입니다.
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)에서는 여러 소비자가 같은 메시지를 읽을 수 있는 스트림을 제공합니다.
+ 전체 수요, 변경률 및 필수 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 적절하게 조정합니다.
## 리소스
**관련 문서:**
+ [Amazon SQS 시작하기](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Application integration Using Queues and Messages](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)(대기열 및 메시지를 사용한 애플리케이션 통합)
**관련 동영상:**
+ [ Choosing the Right Messaging Service for Your Distributed App](https://www.youtube.com/watch?v=4-JmX6MIDDI)(분산형 앱에 적합한 메시징 서비스 선택)
# 소프트웨어 및 아키텍처
**Topics**
+ [SUS 3 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?](sus-03.md)
# SUS 3 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?
로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다.
**Topics**
+ [SUS03-BP01 비동기식 및 예약된 작업을 위한 소프트웨어 및 아키텍처 최적화](sus_sus_software_a2.md)
+ [SUS03-BP02 사용 빈도가 낮거나 전혀 없는 워크로드 구성 요소 제거 또는 리팩터링](sus_sus_software_a3.md)
+ [SUS03-BP03 가장 많은 시간 또는 리소스를 소모하는 코드 영역 최적화](sus_sus_software_a4.md)
+ [SUS03-BP04 디바이스 및 장비에 대한 영향 최적화](sus_sus_software_a5.md)
+ [SUS03-BP05 데이터 액세스 및 스토리지 패턴을 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처 사용](sus_sus_software_a6.md)
# SUS03-BP01 비동기식 및 예약된 작업을 위한 소프트웨어 및 아키텍처 최적화
배포된 리소스의 일관되고 높은 사용률을 유지할 수 있도록 대기열 기반과 같은 효율적인 소프트웨어 및 아키텍처 패턴을 사용합니다.
**일반적인 안티 패턴:**
+ 클라우드 워크로드의 리소스를 과다하게 프로비저닝하여 예상치 못한 수요 급증이 발생합니다.
+ 아키텍처가 메시징 구성 요소에 의한 비동기식 메시지의 발신자와 수신자를 분리하지 않습니다.
**이 모범 사례 확립의 이점:**
+ 효율적인 소프트웨어 및 아키텍처 패턴이 워크로드의 사용되지 않는 리소스를 최소화하고 전체적인 효율성을 개선합니다.
+ 비동기식 메시지 수신과 관계없이 처리를 확장할 수 있습니다.
+ 메시징 구성 요소를 통해 가용성 요구 사항이 완화되어 더 적은 리소스로 이를 충족할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
[이벤트 기반 아키텍처](https://aws.amazon.com/event-driven-architecture/)와 같은 효율적인 아키텍처 패턴을 사용하면 구성 요소의 사용률이 균등해지고 워크로드의 과다한 프로비저닝을 최소화할 수 있습니다. 효율적인 아키텍처 패턴을 사용하면 시간 경과에 따른 수요 변화로 인해 사용하지 않는 유휴 리소스를 최소화할 수 있습니다.
워크로드 구성 요소의 요구 사항을 이해하고 리소스의 전체 사용률을 높이는 아키텍처 패턴을 도입합니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다.
**구현 단계**
+ 워크로드에 대한 수요를 분석하여 이에 대한 대응 방법을 결정합니다.
+ 동기식 응답이 필요하지 않은 요청이나 작업의 경우 대기열 기반 아키텍처 및 오토 스케일링 작업자를 사용하여 사용률을 극대화합니다. 대기열 기반 아키텍처를 고려해야 하는 몇 가지 예는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+ 언제든 처리할 수 있는 요청이나 작업의 경우 더 높은 효율을 위해 예약 메커니즘을 사용하여 작업을 일괄 처리합니다. AWS의 예약 메커니즘의 예는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+ 아키텍처에서 폴링과 웹후크 메커니즘을 사용하는 경우 이를 이벤트로 바꿉니다. [이벤트 기반 아키텍처](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html)를 사용하여 고효율 워크로드를 구축합니다.
+ [AWS의 서버리스](https://aws.amazon.com/serverless/)를 활용하여 과다하게 프로비저닝된 인프라를 제거합니다.
+ 입력 대기 중인 유휴 리소스를 방지하기 위해 아키텍처의 개별 구성 요소의 적절한 크기를 지정합니다.
## 리소스
**관련 문서:**
+ [Amazon Simple Queue Service란 무엇인가요?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Amazon MQ란 무엇인가요?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [Amazon SQS 기반 크기 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [AWS Step Functions란 무엇인가요?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda란 무엇인가요?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Amazon SQS에서 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [Amazon EventBridge란 무엇인가요?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**관련 동영상:**
+ [이벤트 기반 아키텍처로의 전환](https://www.youtube.com/watch?v=h46IquqjF3E)
# SUS03-BP02 사용 빈도가 낮거나 전혀 없는 워크로드 구성 요소 제거 또는 리팩터링
사용되지 않아 더 이상 필요하지 않은 구성 요소를 제거하고 활용률이 낮은 구성 요소를 리팩터링하여 워크로드에서 낭비되는 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 워크로드의 개별 구성 요소 사용률 수준을 정기적으로 확인하지 않습니다.
+ AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/))에서 권장 사항을 확인하고 분석하지 않습니다.
**이 모범 사례 확립의 이점:** 사용되지 않는 구성 요소를 제거하면 낭비를 최소화하고 클라우드 워크로드의 전반적인 효율성을 향상할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
워크로드를 검토하여 유휴 상태이거나 사용하지 않는 구성 요소를 식별합니다. 이는 수요 변화 또는 새로운 클라우드 서비스 출시로 촉발될 수 있는 반복적인 개선 프로세스입니다. 예를 들어, [AWS Lambda](https://docs.aws.amazon.com/lambda/) 함수 실행 시간의 급격한 저하는 메모리 크기를 줄여야 하는 필요성을 나타내는 지표가 될 수 있습니다. 또한, AWS에서 새로운 서비스와 기능을 출시함에 따라 워크로드에 맞는 최적의 서비스와 아키텍처가 변경될 수 있습니다.
워크로드 활동을 지속적으로 모니터링하고 개별 구성 요소의 활용률 수준을 개선할 수 있는 기회를 찾아보세요. 유휴 상태인 구성 요소를 제거하고 적절한 크기 조정 작업을 수행하면 클라우드 리소스를 최소화하여 비즈니스 요구 사항을 충족할 수 있습니다.
**구현 단계**
+ 워크로드의 중요한 구성 요소(예: [Amazon CloudWatch 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)의 CPU 활용률, 메모리 활용률 또는 네트워크 처리량)에 대한 활용률 지표를 모니터링하고 캡처합니다.
+ 안정적인 워크로드를 위해 정기적으로 AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/))를 확인하여 유휴 상태이거나, 사용되지 않거나, 활용도가 낮은 구성 요소를 식별합니다.
+ 일시적인 워크로드의 경우 활용률 지표를 평가하여 유휴 상태이거나, 사용되지 않거나, 활용도가 낮은 구성 요소를 식별합니다.
+ 더 이상 필요하지 않은 구성 요소 및 관련 자산(예: Amazon ECR 이미지)을 사용 중지합니다.
+ 사용률이 낮은 구성 요소를 리팩터링하거나 다른 리소스와 통합하여 사용 효율성을 개선합니다. 예를 들어, 사용률이 낮은 개별 인스턴스에서 데이터베이스를 실행하는 대신 단일 [Amazon RDS](https://aws.amazon.com/rds/) 데이터베이스 인스턴스에 여러 개의 소규모 데이터베이스를 프로비저닝할 수 있습니다.
+ [작업 단위를 완료하기 위해 워크로드에서 프로비저닝한 리소스](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)를 파악합니다.
## 리소스
**관련 문서:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [What is Amazon CloudWatch?(CloudWatch란 무엇인가요?)](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Amazon ECR에서 사용되지 않는 이미지 자동 정리](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/)
**관련 예시:**
+ [ Well-Architected 실습 - AWS Compute Optimizer로 적정 크기 조정 ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [Well-Architected 실습 - 하드웨어 패턴 최적화 및 지속 가능성 KPI 관찰 ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
# SUS03-BP03 가장 많은 시간 또는 리소스를 소모하는 코드 영역 최적화
아키텍처의 여러 구성 요소 내에서 실행되는 코드를 최적화하여 리소스 사용을 최소화하고 성능을 극대화할 수 있습니다.
**일반적인 안티 패턴:**
+ 리소스 사용에 대한 코드 최적화를 무시합니다.
+ 일반적으로 리소스를 늘리는 방법으로 성능 문제에 대응합니다.
+ 코드 검토 및 개발 프로세스에서 성능 변경을 추적하지 않습니다.
**이 모범 사례 확립의 이점:** 효율적인 코드를 활용하면 리소스 사용을 최소화하고 성능을 향상할 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
리소스 사용 및 성능을 최적화하려면 클라우드 아키텍처 기반 애플리케이션의 코드를 포함한 모든 기능 영역을 검사해야 합니다. 빌드 환경 및 프로덕션에서 워크로드의 성능을 지속적으로 모니터링하고 리소스 사용량이 특히 높은 코드 스니펫을 개선할 기회를 식별합니다. 코드 내에서 리소스를 비효율적으로 사용하는 버그 또는 안티 패턴을 식별하기 위해 정기적인 검토 프로세스를 채택합니다. 사용 사례에 대해 동일한 결과를 생성하는 간단하고 효율적인 알고리즘을 활용합니다.
## 구현 단계
+ 워크로드를 개발하는 동안 자동화된 코드 검토 프로세스를 채택하여 품질을 개선하고 버그와 안티 패턴을 식별합니다.
+ [ Amazon CodeGuru Reviewer를 사용한 코드 검토 자동화 ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Amazon CodeGuru를 통한 동시성 버그 탐지 ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
+ [ Amazon CodeGuru를 사용한 Python 애플리케이션의 코드 품질 향상 ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+ 워크로드를 실행할 때 리소스를 모니터링하여 작업 단위당 리소스 요구 사항이 높은 구성 요소를 코드 검토 대상으로 구분합니다.
+ 코드 검토의 경우 코드 프로파일러를 사용하여 가장 많은 시간 또는 리소스를 사용하는 코드 영역을 최적화 대상으로 파악합니다.
+ [ Amazon CodeGuru Profiler를 사용한 조직의 탄소 배출량 감소 ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
+ [ Amazon CodeGuru Profiler를 통한 Java 애플리케이션 메모리 사용량 이해 ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
+ [ Amazon CodeGuru Profiler를 사용한 고객 경험 개선 및 비용 절감 ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+ 워크로드에 가장 효율적인 운영 체제 및 프로그래밍 언어를 사용합니다. 에너지 효율적인 프로그래밍 언어(Rust 포함)에 대한 자세한 내용은 [Rust를 통한 지속 가능성을](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/)참조하십시오.
+ 컴퓨팅 집약적인 알고리즘을 동일한 결과를 내는 보다 단순하고 효율적인 버전으로 대체합니다.
+ 정렬 및 서식 지정과 같은 불필요한 코드를 제거합니다.
## 리소스
**관련 문서:**
+ [Amazon CodeGuru Profiler란 무엇인가요?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [AWS에서의 구축을 위한 도구의 AWS SDK](https://aws.amazon.com/tools/)
**관련 동영상:**
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler(Amazon CodeGuru Profiler를 사용하여 코드 효율성 향상) ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru(Amazon CodeGuru를 사용하여 코드 검토 및 애플리케이션 성능 권장 사항 자동화) ](https://www.youtube.com/watch?v=OD8H63C0E0I)
# SUS03-BP04 디바이스 및 장비에 대한 영향 최적화
아키텍처에 사용되는 디바이스와 장비를 이해하고 전략을 바탕으로 사용량을 줄입니다. 이를 통해 클라우드 워크로드의 전반적인 환경 영향을 최소화할 수 있습니다.
**일반적인 안티 패턴:**
+ 고객이 사용하는 디바이스가 환경에 미치는 영향을 무시합니다.
+ 고객이 사용하는 리소스를 수동으로 관리하고 업데이트합니다.
**이 모범 사례 확립의 이점:** 고객 디바이스에 최적화된 소프트웨어 패턴 및 기능을 구현하면 클라우드 워크로드의 전반적인 환경 영향을 줄일 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
고객 디바이스에 최적화된 소프트웨어 패턴 및 기능을 구현하면 다음과 같은 여러 가지 방법으로 환경에 미치는 영향을 줄일 수 있습니다.
+ 이전 버전과 호환되는 새 기능을 구현하면 하드웨어 교체 횟수를 줄일 수 있습니다.
+ 디바이스에서 효율적으로 실행되도록 애플리케이션을 최적화하면 에너지 소비를 줄이고 배터리 수명을 연장할 수 있습니다(배터리로 작동하는 경우).
+ 디바이스의 애플리케이션을 최적화하면 네트워크를 통한 데이터 전송도 줄일 수 있습니다.
아키텍처에 사용되는 디바이스와 장비, 예상 수명 주기 및 이러한 구성 요소 교체의 영향을 이해합니다. 디바이스 에너지 소비와 고객이 디바이스를 교체해야 하는 필요성, 수동 업그레이드를 최소화하는 소프트웨어 패턴과 기능을 구현합니다.
**구현 단계**
+ 아키텍처에 사용되는 디바이스의 인벤토리를 구성합니다. 디바이스는 모바일, 태블릿, IOT 디바이스, 스마트 라이트 또는 공장의 스마트 디바이스일 수 있습니다.
+ 디바이스에서 실행 중인 애플리케이션을 최적화합니다.
+ 백그라운드에서 태스크를 실행하는 것과 같은 전략을 사용하여 에너지 소비를 줄입니다.
+ 페이로드를 구축할 때 네트워크 대역폭과 지연 시간을 고려하고 애플리케이션이 지연 시간이 긴 저대역폭 링크에서 잘 작동하도록 지원하는 기능을 구현합니다.
+ 페이로드 및 파일을 디바이스에 필요한 최적화된 형식으로 변환합니다. 예를 들어, [Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) 또는 [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/)를 사용하여 대용량의 고품질 디지털 미디어 파일을 사용자가 모바일 디바이스, 태블릿, 웹 브라우저 및 연결된 TV에서 재생할 수 있는 형식으로 변환합니다.
+ 서버 측에서 계산 집약적인 활동(예: 이미지 렌더링)을 수행하거나 애플리케이션 스트리밍을 사용하여 구형 디바이스에서 사용자 경험을 개선합니다.
+ 페이로드를 관리하고 로컬 스토리지 요구 사항을 제한하기 위해 특히 대화형 세션의 경우 출력을 분할하고 페이지 번호를 매깁니다.
+ 자동화된 무선 업데이트(OTA) 메커니즘을 사용하여 하나 이상의 디바이스에 업데이트를 배포합니다.
+ [CI/CD 파이프라인](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/)을 사용하여 모바일 애플리케이션을 업데이트할 수 있습니다.
+ [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/)를 사용하여 연결된 디바이스를 규모에 맞게 원격으로 관리할 수 있습니다.
+ 새로운 기능 및 업데이트를 테스트하려면 대표적인 하드웨어 집합과 함께 관리형 Device Farm을 사용하고 개발을 반복하여 지원되는 디바이스를 최대화하세요. 자세한 내용은 [SUS06-BP04 테스트에 관리형 Device Farm 사용](sus_sus_dev_a5.md) 페이지를 참조하세요.
## 리소스
**관련 문서:**
+ [AWS Device Farm이란 무엇인가요?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [ OTA tutorial for updating firmware on devices running FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)(FreeRTOS를 실행하는 디바이스에서 펌웨어를 업데이트하기 위한 OTA 튜토리얼)
**관련 동영상:**
+ [ Introduction to AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)(AWS Device Farm 소개)
# SUS03-BP05 데이터 액세스 및 스토리지 패턴을 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처 사용
데이터가 워크로드 내에서 사용되고, 사용자가 소비하고, 전송 및 저장되는 방식을 이해합니다. 데이터 액세스 및 스토리지를 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처를 사용하여 워크로드를 지원하는 데 필요한 컴퓨팅, 네트워킹 및 스토리지 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 모든 워크로드의 데이터 스토리지 및 액세스 패턴이 비슷하다고 가정합니다.
+ 모든 워크로드가 해당 계층 내에서 적합하다고 가정하고 하나의 스토리지 계층만 사용합니다.
+ 시간이 지나면 데이터 액세스 패턴이 일관되게 유지될 것이라고 가정합니다.
+ 아키텍처는 높을 가능성이 있는 데이터 액세스 버스트를 지원하므로, 리소스가 대부분 유휴 상태로 유지됩니다.
**이 모범 사례 확립의 이점:** 데이터 액세스 및 스토리지 패턴을 기반으로 아키텍처를 선택하고 최적화하면 개발 복잡성을 줄이고 전체 활용률을 높일 수 있습니다. 글로벌 테이블, 데이터 파티셔닝 및 캐싱을 사용해야 하는 시기를 파악하면 워크로드 요구 사항에 따라 운영 오버헤드를 줄이고 규모를 확장할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
데이터 특성 및 액세스 패턴에 가장 적합한 소프트웨어 및 아키텍처 패턴을 사용합니다. 예를 들어, [AWS 기반 최신 데이터 아키텍처](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/)를 통해 고유한 분석 사용 사례에 최적화된 목적별 서비스를 사용할 수 있습니다. 이러한 아키텍처 패턴은 효율적인 데이터 처리를 가능하게 하고 리소스 사용을 줄여줍니다.
**구현 단계**
+ 데이터 특성 및 액세스 패턴을 분석하여 클라우드 리소스에 적합한 구성을 식별합니다. 고려해야 할 주요 특성은 다음과 같습니다.
+ **데이터 형식:** 정형, 반정형 및 비정형
+ **데이터 증가:** 제한, 무제한
+ **데이터 내구성:** 영구, 임시, 일시적
+ **액세스 패턴**(읽기 또는 쓰기, 업데이트 빈도, 급증 또는 일관성 여부)
+ 데이터 액세스 및 스토리지 패턴을 가장 잘 지원하는 아키텍처 패턴을 사용합니다.
+ [ 아키텍트를 시작하겠습니다\$1 현대적 데이터 아키텍처 ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
+ [ Databases on AWS: The Right Tool for the Right Job](https://www.youtube.com/watch?v=-pb-DkD6cWg)(AWS 기반 데이터베이스: 작업에 맞는 적절한 도구)
+ 기본적으로 압축된 데이터와 함께 작동하는 기술을 사용합니다.
+ 아키텍처의 데이터 처리에 목적별 [분석 서비스](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a)를 사용합니다.
+ 가장 많이 나타나는 쿼리 패턴을 가장 효과적으로 지원하는 데이터베이스 엔진을 사용합니다. 데이터베이스 인덱스를 관리하여 효율적인 쿼리 실행을 보장합니다. 자세한 내용은 [AWS 데이터베이스](https://aws.amazon.com/products/databases/)를 참조하세요.
+ 아키텍처에 사용되는 네트워크 용량을 줄이는 네트워크 프로토콜을 선택합니다.
## 리소스
**관련 문서:**
+ [Athena 압축 지원 파일 형식](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [Amazon Redshift를 사용한 열 기반 데이터 형식에서 COPY 명령](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [Converting Your Input Record Format in Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)(Kinesis Data Firehose Firehose에서 입력 레코드 형식 변환)
+ [AWS Glue에서 ETL 입력 및 출력의 포맷 옵션](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [열 형식으로 변환하여 Amazon Athena에서 쿼리 성능 향상](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [Amazon Redshift를 사용하여 Amazon S3에서 압축된 데이터 파일 로드](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Monitoring DB load with Performance Insights on Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)(Amazon Aurora의 성능 개선 도우미로 DB 로드 모니터링)
+ [Monitoring DB load with Performance Insights on Amazon RDS(Amazon RDS의 성능 개선 도우미로 DB 로드 모니터링)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [ Amazon S3 Intelligent-Tiering storage class](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)(Amazon S3 Intelligent-Tiering 스토리지 클래스)
**관련 동영상:**
+ [ Building modern data architectures on AWS(AWS에서 현대적 데이터 아키텍처 구축) ](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
# 데이터
**Topics**
+ [SUS 4 데이터 관리 정책 및 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?](sus-04.md)
# SUS 4 데이터 관리 정책 및 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?
데이터 관리 원칙을 구현하여 워크로드를 지원하는 데 필요한 프로비저닝된 스토리지와 이를 사용하는 데 필요한 리소스를 줄입니다. 데이터를 이해하고 데이터의 비즈니스 가치와 데이터 사용 방식을 가장 효과적으로 지원하는 스토리지 기술과 구성을 사용합니다. 요구 사항이 감소하면 데이터를 더 효율적이고 성능이 낮은 스토리지로 수명 주기를 변경하고 더 이상 필요하지 않은 데이터는 삭제합니다.
**Topics**
+ [SUS04-BP01 데이터 분류 정책 구현](sus_sus_data_a2.md)
+ [SUS04-BP02 데이터 액세스 및 스토리지 패턴을 지원하는 기술 사용](sus_sus_data_a3.md)
+ [SUS04-BP03 정책을 사용하여 데이터 세트의 수명 주기 관리](sus_sus_data_a4.md)
+ [SUS04-BP04 탄력성 및 자동화 기능을 사용하여 블록 스토리지 또는 파일 시스템 확장](sus_sus_data_a5.md)
+ [SUS04-BP05 불필요하거나 중복된 데이터 제거](sus_sus_data_a6.md)
+ [SUS04-BP06 공유 파일 시스템 또는 스토리지를 사용하여 공용 데이터에 액세스](sus_sus_data_a7.md)
+ [SUS04-BP07 네트워크 간 데이터 이동 최소화](sus_sus_data_a8.md)
+ [SUS04-BP08 다시 생성하기 어려운 경우에만 데이터 백업](sus_sus_data_a9.md)
# SUS04-BP01 데이터 분류 정책 구현
데이터를 분류하여 비즈니스 성과에 대한 중요도를 파악하고 데이터를 저장할 에너지 효율적인 적절한 스토리지 티어를 선택합니다.
**일반적인 안티 패턴:**
+ 처리 중이거나 저장된 데이터 자산 중 특성(예: 민감도, 비즈니스 중요도 또는 규제 요구 사항)이 유사한 데이터 자산을 식별하지 않습니다.
+ 데이터 자산의 인벤토리 등록을 위한 데이터 카탈로그를 구현하지 않았습니다.
**이 모범 사례 확립의 이점:** 데이터 분류 정책을 구현하면 가장 에너지 효율성이 높은 데이터 스토리지 티어를 확인할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
데이터 분류에는 처리 중인 데이터 유형과 조직에서 소유하거나 운영하는 정보 시스템에 저장되는 데이터 유형을 식별하는 작업이 포함됩니다. 또한 데이터의 중요도와 데이터 손상, 손실 또는 남용의 영향을 확인하는 작업도 포함됩니다.
데이터의 상황별 사용에서부터 시작하여 거꾸로 작업하고 조직 운영에 대한 제공된 데이터 세트의 중요도 수준을 고려하는 분류 체계를 만들어 데이터 분류 정책을 구현합니다.
**구현 단계**
+ 워크로드에 존재하는 다양한 데이터 유형의 인벤토리를 수행합니다.
+ 데이터 분류 범주에 대한 자세한 내용은 [데이터 분류 백서](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html)를 참조하세요.
+ 조직에 대한 위험을 기준으로 데이터의 중요도, 기밀성, 무결성 및 가용성을 확인합니다. 이러한 요구 사항을 확인하여 채택한 데이터 분류 티어 중 하나로 데이터를 그룹화합니다.
+ 예시는 [Four simple steps to classify your data and secure your startup(데이터를 분류하고 스타트업을 보호하기 위한 네 가지 간단한 단계)](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/)을 참조하세요.
+ 환경에 태그가 지정되지 않은 데이터와 분류되지 않은 데이터가 있는지 주기적으로 감사하고 데이터를 적절하게 분류하고 태그를 지정합니다.
+ 예시는 [AWS Glue의 데이터 카탈로그 및 크롤러](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)를 참조하세요.
+ 감사 및 거버넌스 기능을 제공하는 데이터 카탈로그를 설정합니다.
+ 각 데이터 클래스의 처리 절차를 결정하여 문서화합니다.
+ 태그가 지정되지 않은 데이터와 분류되지 않은 데이터를 식별하여 데이터를 적절하게 분류하고 태그를 지정하기 위해 자동화를 사용하여 환경을 지속적으로 감사합니다.
## 리소스
**관련 문서:**
+ [Leveraging AWS 클라우드 to Support Data Classification(AWS 클라우드를 활용하여 데이터 분류 지원)](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html)
+ [AWS Organizations의 태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
**관련 동영상:**
+ [Enabling agility with data governance on AWS(AWS에 대한 데이터 거버넌스를 사용하여 민첩성 지원)](https://www.youtube.com/watch?v=vznDgJkoH7k)
# SUS04-BP02 데이터 액세스 및 스토리지 패턴을 지원하는 기술 사용
데이터 액세스 및 저장 방법을 가장 잘 지원하는 스토리지 기술을 사용하여 워크로드를 지원하면서 프로비저닝된 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 모든 워크로드의 데이터 스토리지 및 액세스 패턴이 비슷하다고 가정합니다.
+ 모든 워크로드가 해당 계층 내에서 적합하다고 가정하고 하나의 스토리지 계층만 사용합니다.
+ 시간이 지나면 데이터 액세스 패턴이 일관되게 유지될 것이라고 가정합니다.
**이 모범 사례 확립의 이점:** 데이터 액세스 및 스토리지 패턴을 기반으로 스토리지 기술을 선택하고 최적화하면 비즈니스 요구 사항을 충족하는 데 필요한 클라우드 리소스를 줄이고 클라우드 워크로드의 전반적인 효율성을 향상시킬 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 낮음
## 구현 가이드
따라서 성능 효율성을 극대화하려면 액세스 패턴에 가장 적합한 스토리지 솔루션을 선택하거나, 스토리지 솔루션에 따라 액세스 패턴을 변경하는 것이 좋습니다.
+ 데이터 특성 및 액세스 패턴을 평가하여 스토리지 요구 사항의 주요 특성을 수집합니다. 고려해야 할 주요 특성은 다음과 같습니다.
+ **데이터 유형:** 정형, 반정형 및 비정형
+ **데이터 증가:** 제한, 무제한
+ **데이터 내구성:** 영구, 임시, 일시적
+ **액세스 패턴:** 읽기 또는 쓰기, 빈도, 급증하는지 또는 일관적인지
+ 데이터 특성 및 액세스 패턴을 지원하는 적절한 스토리지 기술로 데이터를 마이그레이션합니다. AWS 스토리지 기술의 몇 가지 예와 주요 특성은 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_data_a3.html)
+ 크기가 고정된 스토리지 시스템(예: Amazon EBS 또는 Amazon FSx)의 경우 사용 가능한 스토리지 공간을 모니터링하고 임계값에 도달 시 스토리지 할당을 자동화합니다. Amazon CloudWatch를 활용하여 [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) 및 [Amazon FSx에](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html)대한 다양한 지표를 수집 및 분석할 수 있습니다.
+ Amazon S3 스토리지 클래스는 객체 수준에서 구성할 수 있으며 단일 버킷에는 모든 스토리지 클래스 전체에 걸쳐 저장된 객체를 포함할 수 있습니다.
+ 또한 Amazon S3 수명 주기 정책을 사용하여 애플리케이션 변경 없이 스토리지 클래스 간에 객체를 자동으로 전환하거나 데이터를 제거할 수 있습니다. 이러한 스토리지 메커니즘을 고려할 때 리소스 효율성, 액세스 지연 시간 및 신뢰성 간에 절충해야 합니다.
## 리소스
**관련 문서:**
+ [Amazon EBS 볼륨 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+ [Amazon EC2 인스턴스 스토어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [ Amazon EBS I/O 특성 ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Amazon S3 스토리지 클래스 사용 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [Amazon Glacier란 무엇인가요?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**관련 동영상:**
+ [AWS의 데이터 레이크용 아키텍처 패턴](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
+ [ Amazon EBS 심층 분석(STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Amazon S3를 사용하여 스토리지 성능 최적화(STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [AWS에서 현대적 데이터 아키텍처 구축 ](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
**관련 예시:**
+ [ Amazon EFS CSI 드라이버 ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Amazon EBS CSI 드라이버 ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Amazon EFS 유틸리티 ](https://github.com/aws/efs-utils)
+ [ Amazon EBS 오토 스케일링 ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Amazon S3 예시 ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
# SUS04-BP03 정책을 사용하여 데이터 세트의 수명 주기 관리
모든 데이터의 수명 주기를 관리하고 삭제를 자동으로 적용하여 워크로드에 필요한 총 스토리지를 최소화합니다.
**일반적인 안티 패턴:**
+ 데이터를 수동으로 삭제합니다.
+ 워크로드 데이터를 삭제하지 않습니다.
+ 보존 및 액세스 요구 사항에 따라 데이터를 더 에너지 효율적인 스토리지로 이동하지 않습니다.
**이 모범 사례 확립의 이점:** 데이터 수명 주기 정책을 사용하여 워크로드에서 데이터에 효율적으로 액세스하고 보존할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
데이터 세트는 일반적으로 수명 주기 동안 보존 및 액세스 요구 사항이 각각 다릅니다. 예를 들어, 애플리케이션이 한정된 기간 동안 일부 데이터 세트에 자주 액세스해야 할 수 있습니다. 그 후 해당 데이터 세트에 자주 액세스하지 않습니다.
전체 수명 주기 동안 데이터 세트를 효율적으로 관리하려면 수명 주기 정책을 구성해야 하며, 이것은 데이터 세트를 처리하는 방법을 정의하는 규칙입니다.
수명 주기 구성 규칙을 통해, 데이터 세트를 보다 에너지 효율적인 스토리지 계층으로 전환하고 아카이브하거나 삭제하도록 특정 스토리지 서비스에 요청할 수 있습니다.
**구현 단계**
+ [워크로드의 데이터 세트를 분류합니다.](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html)
+ 각 데이터 클래스의 처리 절차를 정의합니다.
+ 수명 주기 규칙을 적용하는 자동화된 수명 주기 정책을 설정합니다. 다양한 AWS 스토리지 서비스에 대한 자동화된 수명 주기 정책을 설정하는 몇 가지 예는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_data_a4.html)
+ 사용되지 않은 볼륨, 스냅샷 및 보존 기간이 지난 데이터를 삭제합니다. 삭제할 Amazon DynamoDB Time To Live 또는 Amazon CloudWatch 로그 보존과 같은 네이티브 서비스 기능을 활용합니다.
+ 수명 주기 규칙에 따라 관련 데이터를 집계 및 압축합니다.
## 리소스
**관련 문서:**
+ [Amazon S3 스토리지 클래스 분석을 통해 Amazon S3 수명 주기 규칙 최적화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)
+ [AWS Config 규칙으로 리소스 평가](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
**관련 동영상:**
+ [Amazon S3 수명 주기로 데이터 수명 주기 간소화 및 스토리지 비용 최적화](https://www.youtube.com/watch?v=53eHNSpaMJI)
+ [Amazon S3 스토리지 렌즈를 사용한 스토리지 비용 절감](https://www.youtube.com/watch?v=A8qOBLM6ITY)
# SUS04-BP04 탄력성 및 자동화 기능을 사용하여 블록 스토리지 또는 파일 시스템 확장
데이터가 늘어나면서 블록 스토리지 또는 파일 시스템을 확장하여 프로비저닝된 총 스토리지를 최소화하는 탄력성 및 자동화 기능을 사용합니다.
**일반적인 안티 패턴:**
+ 향후 필요에 따라 대규모 블록 스토리지 또는 파일 시스템을 조달합니다.
+ 파일 시스템의 초당 입출력 작업 처리량(IOPS)을 초과 프로비저닝합니다.
+ 데이터 볼륨의 사용률을 모니터링하지 않습니다.
**이 모범 사례 확립의 이점:** 스토리지 시스템에 대한 초과 프로비저닝을 최소화하면 유휴 리소스가 줄어들고 워크로드의 전반적인 효율성이 향상됩니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
워크로드에 적합한 크기 할당, 처리량 및 지연 시간으로 블록 스토리지 및 파일 시스템을 생성합니다. 이러한 스토리지 서비스를 과도하게 프로비저닝하지 않고도 데이터 증가에 따라 블록 스토리지 또는 파일 시스템을 확장할 수 있는 탄력성 및 자동화 기능을 사용합니다.
**구현 단계**
+ [Amazon EBS](https://aws.amazon.com/ebs/)와 같이 크기가 고정된 스토리지의 경우 전체 스토리지 크기 대비 사용된 스토리지의 양을 모니터링해야 하며, 가능하다면 임계값에 도달할 때 스토리지 크기를 늘릴 수 있는 자동화 기능을 생성해야 합니다.
+ 탄력적 볼륨 및 관리형 블록 데이터 서비스를 사용하여 영구 데이터의 증가에 따른 추가 스토리지 할당을 자동화합니다. 예를 들어, [Amazon EBS 탄력적 볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)을 사용하면 볼륨 크기와 볼륨 유형을 변경하거나 Amazon EBS 볼륨의 성능을 조정할 수 있습니다.
+ 파일 시스템에 적합한 스토리지 클래스, 성능 모드 및 처리량 모드를 선택하여 비즈니스 요구 사항을 충족하세요. 초과할 필요는 없습니다.
+ [ Amazon EFS 성능 ](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [ Amazon EBS volume performance on Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)(Linux 인스턴스의 Amazon EBS 볼륨 성능)
+ 데이터 볼륨의 목표 사용률 수준을 설정하고 예상 범위를 벗어나는 볼륨 크기를 조정합니다.
+ 데이터에 적합하도록 읽기 전용 볼륨의 크기를 알맞게 조정합니다.
+ 블록 스토리지의 고정 볼륨 크기로 초과 용량을 프로비저닝하지 않도록 데이터를 객체 스토어로 마이그레이션합니다.
+ 탄력적인 볼륨 및 파일 시스템을 정기적으로 검토하여 유휴 볼륨을 종료하고 과도하게 프로비저닝된 리소스를 현재 데이터 크기에 맞게 축소합니다.
## 리소스
**관련 문서:**
+ [Amazon FSx 설명서](https://docs.aws.amazon.com/fsx/index.html)
+ [What is Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)(Amazon Elastic File System이란 무엇일까요?)
**관련 동영상:**
+ [ Deep Dive on Amazon EBS Elastic Volumes](https://www.youtube.com/watch?v=Vi_1Or7QuOg)(Amazon EBS 탄력적 볼륨 심층 분석)
+ [ Amazon EBS and Snapshot Optimization Strategies for Better Performance and Cost Savings](https://www.youtube.com/watch?v=h1hzRCsJefs)(성능 향상 및 비용 절감을 위한 Amazon EBS 및 스냅샷 최적화 전략)
+ [ Optimizing Amazon EFS for cost and performance, using best practices](https://www.youtube.com/watch?v=9kfeh6_uZY8)(모범 사례를 사용하여 Amazon EFS의 비용 및 성능 최적화)
# SUS04-BP05 불필요하거나 중복된 데이터 제거
불필요하거나 중복된 데이터를 제거하여 데이터 세트를 저장하는 데 필요한 스토리지 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 쉽게 얻을 수 있거나 다시 생성할 수 있는 데이터를 중복합니다.
+ 데이터의 중요도를 고려하지 않고 모든 데이터를 백업합니다.
+ 데이터를 불규칙하게 또는 운영 이벤트에만 삭제하거나 전혀 삭제하지 않습니다.
+ 스토리지 서비스의 내구성에 관계없이 데이터를 중복 저장합니다.
+ 업무상 타당한 이유 없이 Amazon S3 버전 관리를 활성화합니다.
**이 모범 사례 확립의 이점:** 불필요한 데이터를 제거하면 워크로드 및 워크로드의 환경 영향에 필요한 스토리지 크기를 줄일 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
필요하지 않은 데이터를 저장하지 않습니다. 불필요한 데이터의 삭제를 자동화합니다. 파일 및 블록 수준에서 데이터 중복을 제거하는 기술을 사용합니다. 서비스의 네이티브 데이터 복제 및 중복성 기능을 활용합니다.
**구현 단계**
+ [AWS Data Exchange](https://aws.amazon.com/data-exchange/)의 기존 공개 데이터 세트 및 [AWS의 개방형 데이터](https://registry.opendata.aws/)를 사용하여 데이터 저장을 방지할 수 있는지 여부를 평가합니다.
+ 블록 및 객체 수준에서 데이터 중복을 제거할 수 있는 메커니즘을 사용합니다. 다음은 AWS의 데이터 중복을 제거하는 방법의 몇 가지 예입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_data_a6.html)
+ 데이터 액세스를 분석하여 불필요한 데이터를 식별합니다. 수명 주기 정책을 자동화합니다. 삭제할 [Amazon DynamoDB Time To Live](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html), [Amazon S3 수명 주기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) 또는 [Amazon CloudWatch 로그 보존](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html)과 같은 네이티브 서비스 기능을 활용합니다.
+ AWS의 데이터 가상화 기능을 사용하여 소스의 데이터를 유지 관리하고 데이터 중복을 방지합니다.
+ [AWS의 클라우드 네이티브 데이터 가상화](https://www.youtube.com/watch?v=BM6sMreBzoA)
+ [실습: Amazon Redshift 데이터 공유를 사용하여 데이터 패턴 최적화](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ 증분식 백업을 만들 수 있는 백업 기술을 사용합니다.
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html)의 내구성 및 [Amazon EBS의 복제](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)를 활용하여 자체 관리형 기술(예: 독립 디스크의 이중화 어레이(RAID)) 대신 내구성 목표를 달성합니다.
+ 로그 및 추적 데이터를 중앙 집중화하고, 동일한 로그 항목을 중복 제거하며, 필요에 따라 세부적으로 조정하는 메커니즘을 설정합니다.
+ 적절한 경우에만 캐시를 미리 채웁니다.
+ 캐시 모니터링 및 자동화를 설정하여 그에 따라 캐시 크기를 조정합니다.
+ 새 버전의 워크로드를 푸시할 때 객체 스토어 및 엣지 캐시에서 오래된 배포 및 자산을 제거합니다.
## 리소스
**관련 문서:**
+ [CloudWatch Logs에서 로그 데이터 보존 변경](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server에서 데이터 중복 제거](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [데이터 중복 제거를 포함한 Amazon FSx for ONTAP의 기능](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [Amazon CloudFront에서의 파일 무효화](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html)
+ [AWS Backup을 사용하여 Amazon EFS 파일 시스템 백업 및 복구](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon CloudWatch Logs란 무엇인가요?](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html)
+ [Amazon RDS의 백업 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**관련 동영상:**
+ [AWS Lake Formation의 ML 변환을 통한 퍼지 매칭 및 데이터 중복 제거](https://www.youtube.com/watch?v=g34xUaJ4WI4)
**관련 예시:**
+ [Amazon Athena를 사용하여 Amazon S3 서버 액세스 로그를 분석하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
# SUS04-BP06 공유 파일 시스템 또는 스토리지를 사용하여 공용 데이터에 액세스
공유 파일 시스템 또는 스토리지를 채택하여 데이터 중복을 방지하고 워크로드를 위한 보다 효율적인 인프라를 지원합니다.
**일반적인 안티 패턴:**
+ 각 개별 클라이언트에 대해 스토리지를 프로비저닝합니다.
+ 비활성 클라이언트에서 데이터 볼륨을 분리하지 않습니다.
+ 플랫폼 및 시스템 전반에 걸쳐 스토리지에 액세스할 권한을 제공하지 않습니다.
**이 모범 사례 확립의 이점:** 공유 파일 시스템 또는 스토리지를 사용하면 데이터를 복사하지 않고도 1명 이상의 소비자에게 데이터를 공유할 수 있습니다. 이를 통해 워크로드에 필요한 스토리지 리소스를 줄일 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
여러 사용자 또는 애플리케이션이 동일한 데이터 세트에 액세스하는 경우 워크로드에 효율적인 인프라를 지원하려면 공유 스토리지 기술을 사용해야 합니다. 공유 스토리지 기술은 데이터 세트를 저장 및 관리하고 데이터 중복을 방지할 수 있는 중앙 위치를 제공합니다. 또한 여러 시스템에 걸쳐 데이터의 일관성을 적용합니다. 나아가 공유 스토리지 기술을 사용하면 여러 컴퓨팅 리소스가 동시에 데이터에 액세스하고 이를 처리할 수 있으므로 컴퓨팅 성능을 보다 효율적으로 사용할 수 있습니다.
이러한 공유 스토리지 서비스에서 필요한 경우에만 데이터를 가져오고 사용하지 않는 볼륨을 분리하여 리소스를 확보하세요.
**구현 단계**
+ 데이터의 소비자가 다수인 경우 데이터를 공유 스토리지로 마이그레이션합니다. AWS 기반 공유 스토리지 기술의 몇 가지 예는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_data_a7.html)
+ 필요한 경우에만 공유 파일 시스템에 데이터를 복사하거나 데이터를 가져옵니다. 예를 들어, [Amazon S3를 바탕으로 하는 Amazon FSx for Lustre 파일 시스템을 생성하고](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/) 작업을 처리하는 데 필요한 데이터의 하위 집합만 Amazon FSx로 로드할 수 있습니다.
+ [SUS04-BP03 정책을 사용하여 데이터 세트의 수명 주기 관리](sus_sus_data_a4.md)에 나와 있는 사용 패턴에 따라 데이터를 삭제합니다.
+ 자주 사용하지 않는 클라이언트에서 볼륨을 분리합니다.
## 리소스
**관련 문서:**
+ [ Linking your file system to an Amazon S3 bucket](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)(파일 시스템을 S3 버킷에 연결)
+ [ Using Amazon EFS for AWS Lambda in your serverless applications](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)(서버리스 애플리케이션에서 AWS Lambda용 Amazon EFS 사용)
+ [ Amazon EFS Intelligent-Tiering Optimizes Costs for Workloads with Changing Access Patterns](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)(Amazon EFS Intelligent-Tiering을 통해 액세스 패턴 변화에 따른 워크로드 비용 최적화)
+ [ Using Amazon FSx with your on-premises data repository](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)(온프레미스 데이터 리포지토리에 Amazon FSx 사용)
**관련 동영상:**
+ [ Storage cost optimization with Amazon EFS](https://www.youtube.com/watch?v=0nYAwPsYvBo)(Amazon EFS를 사용하여 스토리지 비용 최적화)
# SUS04-BP07 네트워크 간 데이터 이동 최소화
공유 파일 시스템 또는 객체 스토리지를 사용하여 공통 데이터에 액세스하고 워크로드의 데이터 이동을 지원하는 데 필요한 총 네트워킹 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 데이터 사용자의 위치에 관계없이 모든 데이터를 동일한 AWS 리전에 저장합니다.
+ 네트워크를 통해 데이터를 이동하기 전에 데이터 크기와 형식을 최적화하지 않습니다.
**이 모범 사례 확립의 이점:** 네트워크 간 데이터 이동을 최적화하면 워크로드에 필요한 총 네트워킹 리소스가 줄어들고 환경에 미치는 영향도 줄어듭니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
조직 전체에서 데이터를 옮기려면 컴퓨팅, 네트워킹 및 스토리지 리소스가 필요합니다. 기술을 사용하여 데이터 이동을 최소화하고 워크로드의 전반적인 효율성을 개선합니다.
## 구현 단계
+ 데이터 또는 사용자와의 근접성을 [워크로드 리전 선택 시](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)결정 요소로 고려하십시오.
+ 리전별 사용 서비스를 분할하여 해당 리전별 데이터가 사용되는 리전 내에 저장되도록 합니다.
+ 네트워크를 통해 데이터를 이동하기 전에 효율적인 파일 형식(예: Parquet 또는 ORC)을 사용하고 데이터를 압축합니다.
+ 사용하지 않는 데이터는 옮기지 마십시오. 사용하지 않는 데이터의 이동을 방지하는 데 도움이 되는 몇 가지 예는 다음과 같습니다.
+ 관련 데이터에 대해서만 API 응답을 줄입니다.
+ 상세한 경우 데이터를 집계합니다(레코드 수준 정보는 필요하지 않음).
+ 자세한 내용은 [Well-Architected 실습 - Amazon Redshift 데이터 공유를 사용하여 데이터 패턴 최적화](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)를 참조하십시오.
+ 교차 계정 데이터 공유를 [AWS Lake Formation에서](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html)고려하십시오.
+ 워크로드 사용자에게 더 가까운 위치에서 코드를 실행할 수 있는 서비스를 사용합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_data_a8.html)
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking(지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 네트워킹)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [CloudFront 글로벌 엣지 네트워크를 포함한 Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
+ [Amazon OpenSearch Service에서 HTTP 요청 압축](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Amazon EMR을 사용한 중간 데이터 압축](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [Amazon S3에서 Amazon Redshift로 압축 데이터 파일 로딩](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon CloudFront를 사용하여 압축된 파일 제공](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
**관련 동영상:**
+ [ Demystifying data transfer on AWS(AWS에서의 데이터 전송 알아보기) ](https://www.youtube.com/watch?v=-MqXgzw1IGA)
**관련 예시:**
+ [ 지속 가능성을 위한 설계 - 네트워크 간 데이터 이동 최소화 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS04-BP08 다시 생성하기 어려운 경우에만 데이터 백업
비즈니스 가치가 없는 데이터는 백업하지 않으면서 워크로드의 스토리지 리소스 요구 사항을 최소화합니다.
**일반적인 안티 패턴:**
+ 데이터에 대한 백업 전략이 없습니다.
+ 쉽게 다시 생성할 수 있는 데이터를 백업합니다.
**이 모범 사례 확립의 이점:** 중요하지 않은 데이터를 백업하지 않으면 워크로드에 필요한 스토리지 리소스를 줄이고 환경에 미치는 영향도 줄일 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
불필요한 데이터를 백업하지 않으면 비용을 절감하고 워크로드에 사용되는 스토리지 리소스를 줄일 수 있습니다. 비즈니스 가치가 있거나 규정 준수 요구 사항을 충족하는 데 필요한 데이터만 백업합니다. 백업 정책을 검토하고 복구 시나리오에서 가치를 제공하지 않는 임시 스토리지는 제외합니다.
**구현 단계**
+ [SUS04-BP01 데이터 분류 정책 구현](sus_sus_data_a2.md)에 나와 있는 대로 데이터 분류 정책을 구현합니다.
+ 데이터 분류 중요도를 바탕으로 [Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)) 기반 백업 전략을 설계합니다. 중요하지 않은 데이터는 백업하지 마세요.
+ 쉽게 다시 생성할 수 있는 데이터는 제외합니다.
+ 백업 대상에서 임시 데이터를 제외합니다.
+ 공용 위치에서 데이터를 복원하는 데 필요한 시간이 서비스 수준에 관한 계약(SLA)을 초과하지 않는 한, 데이터의 로컬 사본을 제외합니다.
+ 자동화된 솔루션 또는 관리형 서비스를 사용하여 비즈니스 크리티컬 데이터를 백업합니다.
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)은 완전관리형 서비스로, AWS 서비스 전반, 클라우드 및 온프레미스에서 데이터 보호를 쉽게 중앙 집중화하고 자동화할 수 있습니다. AWS Backup을 사용하여 자동화된 백업을 생성하는 방법에 대한 실습 지침은 [Well-Architected Labs - Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected 실습 - 데이터 백업 및 복원 테스트)를 참조하세요.
+ [AWS Backup을 사용하여 Amazon EFS용 백업을 자동화하고 백업 비용을 최적화합니다](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/).
## 리소스
**관련 모범 사례:**
+ [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 자동으로 데이터 백업 수행](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
**관련 문서:**
+ [AWS Backup을 사용하여 Amazon EFS 파일 시스템 백업 및 복구](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon Relational Database Service의 백업 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품 ](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [ Amazon EFS 백업 ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [ Backing Up Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)(Amazon FSx for Windows File Server 백업)
+ [ Amazon ElastiCache (Redis OSS) 백업 및 복구 ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
**관련 동영상:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)(AWS re:Invent 2021 - AWS를 통한 백업, 재해 복구, 랜섬웨어 보호)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE)(AWS Backup 데모: 계정 간 및 리전 간 백업)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://www.youtube.com/watch?v=av8DpL0uFjc)(AWS re:Invent 2019: AWS Backup에 대한 심층 분석(Rackspace 소개))
**관련 예시:**
+ [ Well-Architected Lab - Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected 실습 - 데이터 백업 및 복원 테스트)
+ [ Well-Architected Lab - Backup and Restore with Failback for Analytics Workload](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)(Well-Architected 실습 - 분석 워크로드에 대한 백업 및 페일백으로 복원)
+ [ Well-Architected Lab - Disaster Recovery - Backup and Restore](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)(Well-Architected 실습 - 재해 복구 - 백업 및 복원)
# 하드웨어 및 서비스
**Topics**
+ [SUS 5 지속 가능성 목표를 지원하기 위해 아키텍처에서 클라우드 하드웨어 및 서비스를 어떻게 선택하고 사용합니까?](sus-05.md)
# SUS 5 지속 가능성 목표를 지원하기 위해 아키텍처에서 클라우드 하드웨어 및 서비스를 어떻게 선택하고 사용합니까?
하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어 및 서비스를 선택합니다.
**Topics**
+ [SUS05-BP01 요구 사항을 충족하는 데 필요한 최소한의 하드웨어 사용](sus_sus_hardware_a2.md)
+ [SUS05-BP02 영향이 가장 적은 인스턴스 유형 사용](sus_sus_hardware_a3.md)
+ [SUS05-BP03 관리형 서비스 사용](sus_sus_hardware_a4.md)
+ [SUS05-BP04 하드웨어 기반 컴퓨팅 액셀러레이터의 사용 최적화](sus_sus_hardware_a5.md)
# SUS05-BP01 요구 사항을 충족하는 데 필요한 최소한의 하드웨어 사용
비즈니스 요구 사항을 효율적으로 충족하기 위해 워크로드에 필요한 최소한의 하드웨어를 사용합니다.
**일반적인 안티 패턴:**
+ 리소스 사용률을 모니터링하지 않습니다.
+ 아키텍처의 사용률 수준이 낮은 리소스가 있습니다.
+ 크기 조정이 필요한지 여부를 결정하기 위해 정적 하드웨어의 사용률 검토를 수행하지 않습니다.
+ 비즈니스 KPI를 기반으로 컴퓨팅 인프라의 하드웨어 사용률 목표를 설정하지 않습니다.
**이 모범 사례 확립의 이점:** 클라우드 리소스의 크기를 적절하게 조정하면 워크로드의 환경 영향을 줄이고, 비용을 절감하며, 성능 벤치마크를 유지하는 데 도움이 됩니다.
**이 모범 사례를 따르지 않을 경우 노출 위험도:** 보통
## 구현 가이드
워크로드에 필요한 총 하드웨어 수를 최적으로 선택하여 전반적인 효율성을 개선합니다. AWS 클라우드는 다양한 메커니즘(예: [AWS Auto Scaling](https://aws.amazon.com/autoscaling/))을 통해 리소스 수를 동적으로 확장하거나 줄일 수 있는 유연성을 제공하고 수요 변화에 대응합니다. 또한, 최소한의 노력으로 리소스를 수정할 수 있는 [API 및 SDK](https://aws.amazon.com/developer/tools/)도 제공합니다. 이러한 기능을 사용하여 워크로드 구현을 자주 변경할 수 있습니다. 또한 AWS 도구의 적정 크기 조정 지침을 바탕으로 클라우드 리소스를 효율적으로 운영하고 비즈니스 요구 사항을 충족할 수 있습니다.
**구현 단계**
+ 필요에 가장 적합한 인스턴스 유형을 선택합니다.
+ [워크로드에 적합한 Amazon EC2 인스턴스 유형을 선택하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [ Amazon EC2 플릿에 대한 속성 기반 인스턴스 유형 선택 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [ 속성 기반 인스턴스 유형 선택을 사용하여 Auto Scaling 그룹 생성 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+ 가변 워크로드의 경우 작은 증분 단위로 크기를 조정합니다.
+ 여러 컴퓨팅 구매 옵션을 사용하여 인스턴스 유연성, 확장성 및 비용 절감의 균형을 맞춥니다.
+ [온디맨드 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)는 인스턴스 유형, 위치 또는 시간을 유연하게 지정할 수 없는 최신 상태 저장 급증 워크로드에 가장 적합합니다.
+ [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)는 내결함성 및 유연성이 뛰어난 애플리케이션을 위한 다른 옵션을 보완하는 데 유용한 방법입니다.
+ 안정적인 상태의 워크로드에는 [컴퓨팅 절감형 플랜](https://aws.amazon.com/savingsplans/compute-pricing/)을 활용하여 변화하는 요구 사항(예: AZ, 리전, 인스턴스 제품군 또는 인스턴스 유형)에 유연성을 제공합니다.
+ 인스턴스 및 가용 영역 다양성을 활용하여 애플리케이션 가용성을 극대화하고 가능한 경우 초과 용량을 활용할 수 있습니다.
+ AWS 도구에서 적정 크기 조정 권장 사항을 사용하여 워크로드를 조정합니다.
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ 자동화가 대체 리소스를 배포하는 동안 일시적으로 용량을 줄일 수 있는 서비스 수준에 관한 계약(SLA)을 협상합니다.
## 리소스
**관련 문서:**
+ [ Optimizing your AWS Infrastructure for Sustainability, Part I: Compute](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)(지속 가능성을 위한 AWS 인프라 최적화, 파트 I: 컴퓨팅)
+ [Amazon EC2 플릿의 Auto Scaling을 위한 속성 기반 인스턴스 유형 선택](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [AWS Compute Optimizer 설명서 ](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [Operating Lambda: Performance optimization](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/)(Lambda 운영: 성능 최적화)
+ [Auto Scaling 설명서](https://docs.aws.amazon.com/autoscaling/index.html)
**관련 동영상:**
+ [Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**관련 예시:**
+ [Well-Architected 실습 - AWS Compute Optimizer 및 메모리 사용률을 활성화하여 적정 크기 조정(레벨 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
# SUS05-BP02 영향이 가장 적은 인스턴스 유형 사용
새로운 인스턴스 유형을 지속적으로 모니터링하고 사용하여 에너지 효율 개선을 활용합니다.
**일반적인 안티 패턴:**
+ 인스턴스 패밀리는 하나만 사용합니다.
+ x86 인스턴스만 사용합니다.
+ Amazon EC2 Auto Scaling 구성에서 인스턴스 유형을 하나만 지정합니다.
+ AWS 인스턴스를 설계되지 않은 방식으로 사용합니다(예: 컴퓨팅에 최적화된 인스턴스를 메모리 집약적 워크로드에 사용).
+ 새 인스턴스 유형을 정기적으로 평가하지 않습니다.
+ AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer)의 권장 사항을 확인하지 않습니다.](https://aws.amazon.com/compute-optimizer/)
**이 모범 사례 확립의 이점:** 적정 크기로 조정된 에너지 효율적인 인스턴스를 사용하면 환경 영향 및 워크로드 비용을 크게 줄일 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
클라우드 워크로드에서 효율적인 인스턴스를 사용하는 것은 리소스 사용량을 줄이고 비용 효율성을 높이는 데 매우 중요합니다. 새로운 인스턴스 유형의 릴리스를 지속적으로 모니터링하고 기계 학습 훈련 및 추론, 동영상 트랜스코딩과 같은 특정 워크로드를 지원하도록 설계된 인스턴스 유형을 포함하여 에너지 효율성 개선의 이점을 활용합니다.
## 구현 단계
+ 워크로드의 환경 영향을 줄일 수 있는 인스턴스 유형을 알아보고 탐색합니다.
+ 최신 [AWS의 새로운 소식](https://aws.amazon.com/new/) 을 구독하여 최신 AWS 기술 및 인스턴스 소식을 파악합니다.
+ 다양한 AWS 인스턴스 유형에 대해 알아봅니다.
+ 다음 동영상을 보고 Amazon EC2에서 와트당 에너지 사용 대비 최고 성능을 제공하는 AWS Graviton 기반 인스턴스에 대해 살펴봅니다. [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances(AWS Graviton2 프로세서 기반 Amazon EC2 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=NLysl0QvqXU) 및 [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances(AWS Graviton3 및 Amazon C7g 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents).
+ 워크로드를 영향이 가장 적은 인스턴스 유형으로 전환하도록 계획합니다.
+ 워크로드를 위한 새로운 기능 또는 인스턴스를 평가하기 위한 프로세스를 정의합니다. 클라우드에서 민첩성을 활용하여 새 인스턴스 유형이 워크로드 환경 지속 가능성을 어떻게 개선할 수 있는지 신속하게 테스트합니다. 프록시 지표를 사용하여 작업 단위를 완료하는 데 필요한 리소스를 측정합니다.
+ 가능한 경우 다양한 vCPU 수와 다양한 메모리 용량으로 작동하도록 워크로드를 수정하여 인스턴스 유형 선택의 폭을 극대화합니다.
+ 워크로드의 성능 효율성을 개선하려면 워크로드를 Graviton 기반 인스턴스로 전환할 것을 고려합니다.
+ [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/)
+ [AWS Graviton 기반 Amazon Elastic Compute Cloud 인스턴스로 워크로드를 전환할 때의 고려 사항](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)
+ [AWS Graviton2 for ISVs](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)
+ AWS Graviton 옵션 선택을 [AWS 관리형 서비스 사용에 고려하세요. ](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)
+ 지속 가능성에 미치는 영향이 가장 적고 비즈니스 요구 사항을 충족하는 인스턴스를 제공하는 리전으로 워크로드를 마이그레이션합니다.
+ 기계 학습 워크로드의 경우 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)및 [Amazon EC2 DL1과 같이 워크로드에 따라 다른 특별히 구축된 하드웨어의 장점을 활용합니다.](https://aws.amazon.com/ec2/instance-types/dl1/) Inf2 인스턴스와 같은 AWS Inferentia 인스턴스는 동급 Amazon EC2 인스턴스에 비해 최대 50% 더 우수한 와트당 성능을 제공합니다.
+ 또한 [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) 를 사용하여 ML 추론 엔드포인트의 크기를 적정하게 조정합니다.
+ 급증하는 워크로드의 경우(추가 용량에 대한 요구 사항이 적은 워크로드) [버스트 가능한 성능 인스턴스를 사용합니다.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ 상태 비저장 또는 내결함성 워크로드의 경우 [Amazon EC2 스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 를 사용하여 클라우드의 전반적인 활용률을 높이고 사용하지 않는 리소스가 지속 가능성에 미치는 영향을 줄입니다.
+ 워크로드 인스턴스를 운영 및 최적화합니다.
+ 임시 워크로드의 경우 [인스턴스 Amazon CloudWatch 지표](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) (예: `CPUUtilization` )를 사용하여 인스턴스가 유휴 상태이거나 사용률이 적은지 파악합니다.
+ 안정적인 워크로드의 경우 AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) )를 정기적으로 사용하여 인스턴스를 최적화하고 크기를 적정하게 조정할 기회를 파악합니다.
+ [ Well-Architected 실습 - 적정 크기 조정 권장 사항 ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [ Well-Architected 실습 - Compute Optimizer로 적정 크기 조정 ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Well-Architected 실습 - 하드웨어 패턴 최적화 및 지속 가능성 KPI 관찰 ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part I: Compute(지속 가능성을 위한 AWS 인프라 최적화, 파트 I: 컴퓨팅)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton](https://aws.amazon.com/ec2/graviton/)
+ [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon EC2 용량 예약 플릿](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [Amazon EC2 스팟 플릿](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [함수: Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [ Amazon EC2 플릿에 대한 속성 기반 인스턴스 유형 선택 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [AWS에서 지속 가능하고 효율적이며 비용 최적화된 애플리케이션 구축](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ Contino 지속 가능성 대시보드가 고객의 탄소 발자국 줄이기를 지원하는 방법 ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)
**관련 동영상:**
+ [Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances(AWS Graviton2 프로세서 기반 Amazon EC2 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=NLysl0QvqXU)
+ [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances(AWS Graviton3 및 Amazon C7g 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
+ [ Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축) ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**관련 예시:**
+ [ 솔루션: AWS에서 지속 가능성을 위해 딥 러닝 워크로드를 최적화하기 위한 지침 ](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+ [Well-Architected 실습 - 적정 크기 조정 권장 사항](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [Well-Architected 실습 - Compute Optimizer로 적정 크기 조정](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [Well-Architected 실습 - 하드웨어 패턴 최적화 및 지속 가능성 KPI 관찰](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
+ [ Well-Architected Lab - Migrating Services to Graviton(Well-Architected 실습 - Graviton으로 서비스 마이그레이션) ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)
# SUS05-BP03 관리형 서비스 사용
관리형 서비스를 사용하여 클라우드에서 보다 효율적으로 운영합니다.
**일반적인 안티 패턴:**
+ 활용률이 낮은 Amazon EC2 인스턴스를 사용하여 애플리케이션을 실행합니다.
+ 사내 팀이 혁신이나 단순화에 집중할 시간 없이 워크로드만 관리합니다.
+ 관리형 서비스에서 보다 효율적으로 실행할 수 있는 태스크를 위한 기술을 배포하고 유지 관리합니다.
**이 모범 사례 확립의 이점:**
+ 관리형 서비스를 사용하면 새로운 혁신과 효율성을 추진하는 데 도움이 될 수 있는 수백만 명의 고객 인사이트를 보유한 AWS에 책임을 맡길 수 있습니다.
+ 관리형 서비스는 멀티 테닛 컨트롤 플레인으로 인해 많은 사용자에게 서비스의 환경 영향을 분산시킵니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
관리형 서비스는 배포된 하드웨어의 높은 사용률과 지속 가능성 최적화를 유지하는 책임을 AWS로 이전합니다. 또한 관리형 서비스를 사용하면 서비스를 유지 관리해야 하는 운영 및 관리 부담이 줄어들기 때문에 팀이 혁신에 더 많은 시간을 할애하고 집중할 수 있습니다.
워크로드를 검토하여 AWS 관리형 서비스로 대체할 수 있는 구성 요소를 식별합니다. 예를 들어, [Amazon RDS](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/), [Amazon ElastiCache](https://aws.amazon.com/elasticache/)에서는 관리형 데이터베이스 서비스를 제공합니다. [Amazon Athena](https://aws.amazon.com/athena/), [Amazon EMR](https://aws.amazon.com/emr/), [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/)에서는 관리형 분석 서비스를 제공합니다.
**구현 단계**
1. 서비스 및 구성 요소에 대한 워크로드 인벤토리를 작성합니다.
1. 관리형 서비스로 대체할 수 있는 구성 요소를 평가하고 식별합니다. 관리형 서비스 사용을 고려할 수 있는 몇 가지 예는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/sus_sus_hardware_a4.html)
1. 종속성을 식별하고 마이그레이션 플랜을 생성합니다. 그에 따라 런북과 플레이북을 업데이트합니다.
+ [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)는 애플리케이션 종속성 및 활용에 대한 세부적인 정보를 자동으로 수집하고 제공하여 마이그레이션을 계획할 때 보다 정확한 결정을 내릴 수 있도록 합니다.
1. 관리형 서비스로 마이그레이션하기 전에 서비스를 테스트합니다.
1. 마이그레이션 플랜을 바탕으로 자체 호스팅 서비스를 관리형 서비스로 교체합니다.
1. 마이그레이션이 완료된 후 서비스를 지속적으로 모니터링하여 필요에 따라 조정하고 서비스를 최적화합니다.
## 리소스
**관련 문서:**
+ [AWS 클라우드 제품 ](https://aws.amazon.com/products/)
+ [AWS 총 소유 비용(TCO) 계산기 ](https://calculator.aws/#/)
+ [Amazon DocumentDB](https://aws.amazon.com/documentdb/)
+ [Amazon Elastic Kubernetes Service(EKS)](https://aws.amazon.com/eks/)
+ [Amazon Managed Streaming for Apache Kafka(Amazon MSK)](https://aws.amazon.com/msk/)
**관련 동영상:**
+ [ Cloud operations at scale with AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)(AWS Managed Services를 사용하여 적절한 규모의 클라우드 운영)
# SUS05-BP04 하드웨어 기반 컴퓨팅 액셀러레이터의 사용 최적화
가속 컴퓨팅 인스턴스의 사용을 최적화하여 워크로드의 물리적 인프라 요구를 줄입니다.
**일반적인 안티 패턴:**
+ GPU 사용을 모니터링하지 않습니다.
+ 특별히 구축된 인스턴스가 더 높은 성능, 더 낮은 비용 및 더 나은 와트당 성능을 제공함에도 불구하고 워크로드에 범용 인스턴스를 사용합니다.
+ CPU 기반 대안을 사용하는 것이 더 효율적인 작업에 하드웨어 기반 컴퓨팅 액셀러레이터를 사용합니다.
**이 모범 사례 확립의 이점:** 하드웨어 기반 액셀러레이터의 사용을 최적화하여 워크로드의 물리적 인프라 요구를 줄일 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
높은 처리 용량이 필요한 경우, 그래픽 처리 장치(GPU) 및 필드 프로그래밍 가능 게이트 어레이(FPGA)와 같은 하드웨어 기반 컴퓨팅 액셀러레이터에 대한 액세스를 제공하는 가속 컴퓨팅 인스턴스 사용의 이점을 활용할 수 있습니다. 이러한 하드웨어 액셀러레이터는 CPU 기반 대안보다 더 효율적인 그래픽 처리 또는 데이터 패턴 일치와 같은 특정 기능을 수행합니다. 렌더링, 트랜스코딩, 기계 학습 등 많은 가속 워크로드는 리소스 사용 면에서 매우 가변적입니다. 필요한 시간 동안만 이 하드웨어를 실행하고 필요하지 않은 경우 자동화를 통해 이를 폐기하여 리소스 사용을 최소화합니다.
## 구현 단계
+ 요구 사항을 해결할 수 있는 [가속 컴퓨팅 인스턴스를](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) 식별합니다.
+ 기계 학습 워크로드의 경우 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)및 [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)같이 워크로드에 따라 특별히 구축된 다른 하드웨어의 장점을 활용합니다. Inf2 인스턴스와 같은 AWS Inferentia 인스턴스는 [동급 Amazon EC2 인스턴스에 비해 최대 50% 더 우수한 와트당 성능을](https://aws.amazon.com/machine-learning/inferentia/)제공합니다.
+ 가속 컴퓨팅 인스턴스의 사용량 지표를 수집합니다. 예를 들어 GPU의 경우 CloudWatch 에이전트를 사용하여 `utilization_gpu` 및 `utilization_memory` 같은 지표를 수집할 수 [있습니다(Amazon CloudWatch를 사용하여 NVIDIA GPU 지표 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html)참조).
+ 코드, 네트워크 운영, 하드웨어 액셀러레이터 설정을 최적화하여 기본 하드웨어가 반드시 제대로 활용되도록 해야 합니다.
+ [GPU 설정 최적화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html)
+ [딥 러닝 AMI에서 GPU 모니터링 및 최적화](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html)
+ [Amazon SageMaker AI에서 딥 러닝 훈련의 GPU 성능 튜닝을 위한 I/O 최적화](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/)
+ 최신 고성능 라이브러리 및 GPU 드라이버를 사용합니다.
+ 자동화를 사용하여 사용하지 않는 GPU 인스턴스 사용을 해제합니다.
## 리소스
**관련 문서:**
+ [가속화된 컴퓨팅](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [ 아키텍트를 시작하겠습니다\$1 맞춤형 칩과 액셀러레이터를 사용한 아키텍팅 ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ 워크로드에 적합한 Amazon EC2 인스턴스 유형을 선택하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 VT1 인스턴스](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [ Amazon SageMaker AI을 통해 컴퓨터 비전 추론을 위한 최고의 AI 액셀러레이터 및 모델 컴파일 선택 ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)
**관련 동영상:**
+ [ 딥 러닝을 위한 Amazon EC2 GPU 인스턴스 선택 방법 ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+ [비용 효과적인 딥 러닝 추론 배포](https://www.youtube.com/watch?v=WiCougIDRsw)
# 프로세스 및 문화
**Topics**
+ [SUS 6 조직의 프로세스가 지속 가능성 목표를 어떻게 지원하고 있습니까?](sus-06.md)
# 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-10-03/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을 통해 최종 사용자 인사이트로 애플리케이션 최적화)