비기능적 요구 사항으로서의 지속 가능성

비즈니스 요구 사항 목록에 지속 가능성을 추가하면 보다 경제적인 솔루션을 얻을 수 있습니다. 사용하는 리소스로부터 더 많은 가치를 얻고 더 적은 리소스를 사용하는 데 집중하면 사용한 만큼만 비용을 지불하므로 AWS에서 비용을 절감할 수 있습니다.

지속 가능성 목표를 달성하기 위해 가동 시간, 가용성 또는 반응 시간과 같은 다른 기존의 지표에서와 같은 절충은 요구되지 않습니다. 서비스 수준에 눈에 띄는 영향을 주지 않고도 지속 가능성을 상당한 수준으로 증진할 수 있습니다. 사소한 절충이 필요할 수 있지만 이러한 절충으로 얻은 지속 가능성의 개선 사항이 서비스 품질 변화보다 더 클 수 있습니다.

팀원이 기능 요구 사항을 개발할 때 지속적으로 지속 가능성 개선 사항을 실험하도록 독려하세요. 또한 팀에서는 목표를 수립할 때 프록시 지표를 포함하여 워크로드를 개발할 때 리소스 밀도를 평가하도록 해야 합니다.

다음은 소비하는 클라우드 리소스를 줄일 수 있는 장단점 예제입니다.

결과 품질 조정: 근사 컴퓨팅을 통해 결과 품질(QoR)을 낮추는 대신 탄소 집약도를 줄일 수 있습니다. 근사 컴퓨팅 관행에서는 고객에게 필요한 것과 실제로 생산 결과물 사이의 차이를 이용할 수 있는 기회를 모색합니다. 예를 들어 데이터를 정해진 데이터 구조에 배치하면 SQL에서 ORDER BY 연산자를 삭제하여 불필요한 처리를 제거해 리소스를 절감하면서도 적절한 답변을 제공할 수 있습니다.

응답 시간 조정: 질문에서 응답 시간을 다소 늦추면 공유 오버헤드를 최소화하여 탄소 배출량을 줄일 수 있습니다. 단기적인 임시 작업을 처리할 경우 시작 오버헤드가 발생할 수 있습니다. 작업이 수신될 때마다 오버헤드에 대한 비용을 지불하는 대신 작업을 배치 단위로 그룹화하여 처리합니다. 배치 처리는 응답 시간을 늘리는 대신 인스턴스 시작, 소스 코드 다운로드 및 프로세스 실행의 공유 오버헤드를 줄입니다.

가용성 조정: AWS에서는 클릭 몇 번으로 중복성을 추가하고 고가용성 목표를 달성할 수 있습니다. 언제나 활용률이 절감되는 유휴 리소스를 프로비저닝하여 정적 안정성과 같은 기법으로 중복성을 높일 수 있습니다. 목표를 설정할 때는 비즈니스의 요구 사항을 평가합니다. 가용성을 조금 절충하면 활용도에서 훨씬 더 큰 개선을 얻을 수 있습니다. 예를 들어 정적 안정성 아키텍처 패턴에는 구성 요소 장애 직후에 로드 처리를 담당할 유휴 장애 조치 용량의 프로비저닝이 포함됩니다. 가용성 요구 사항을 완화하면 자동화를 통해 대체 리소스를 배포할 시간이 있으므로 유휴 온라인 용량이 필요 없습니다. 온디맨드로 장애 조치 용량을 추가하면 정상 운영 중에는 비즈니스에 영향을 미치지 않고 전반적인 사용률이 높아지며 비용 절감이라는 부차적인 이점도 얻을 수 있습니다.