사용 최적화를 위한 디자인
 리소스 및 작업의 사용을 최대화합니다. 솔루션의 협상된 기능 및 비기능적 요구 사항에 적용합니다. |
|---|
서비스 및 제품은 다양한 기능과 가격 책정 계층을 제공합니다. 기능 집합을 구매한 후에는 사용하지 않도록 합니다. 계층에 대한 투자를 최대화하는 방법을 찾습니다. 마찬가지로 청구 모델을 지속적으로 평가하여 현재 프로덕션 워크로드에 따라 사용량에 더 잘 맞는 모델을 찾습니다.
예제 시나리오
Contoso University는 현재 대학 교수진이 학년도에 대한 과정을 만들고 업데이트할 수 있도록 하는 상용 COTS(상용 COTS) 솔루션을 호스팅하고 있으며, 이러한 과정에 대해 학생들이 사용하는 기본 등록 포털입니다. 이 솔루션은 SaaS(Software-as-a-Service) 교육 관리 시스템과 사용자 지정 통합을 통해 결국 모든 기능을 몇 년 안에 마이그레이션할 수 있기를 희망합니다. 그 동안 사용자 지정 통합 구성 요소에 대한 비용을 최적화하려고 합니다.
COTS 제품의 기술 솔루션은 일반적으로 Azure Database for MySQL인 데이터베이스를 제외하고 블랙박스처럼 처리됩니다. 사용자 지정 통합은 Azure 앱 Service의 표준 서비스 계획에서 실행되는 Azure Durable Function입니다. 이 App Service는 이전에 대학 웹 사이트를 호스팅했지만 더 이상 그렇지 않습니다. 이 지속성 함수는 MySQL 데이터베이스에서 SaaS의 API로 야간 동기화를 수행하는 전용 Azure Storage 계정에서 지원되는 Python 애플리케이션입니다.
실용적일 때 소비 기반 가격 책정 사용
사용량 기반 가격 책정을 제공하는 서비스가 있을 수 있습니다. 즉, 서비스 사용량에 대해서만 요금이 청구되며 비용 발생을 중지할 필요가 없는 경우 서비스를 종료할 수 있습니다. 산발적으로만 사용되는 워크로드 구성 요소가 있는 경우 24/7/365를 실행하는 구성 요소에 대한 비용을 지불하는 것과 비교할 때 낭비되는 비용을 최소화하는 데 도움이 될 수 있습니다.
소비 기반 가격 책정을 사용하면 사용하는 항목에 대해서만 요금을 지불합니다. 이 옵션은 워크로드 컴퓨팅이 풀 타임으로 활용되지 않을 때 적합합니다.
Contoso의 과제
- 동기화 작업은 일반적으로 특정 시간에 매일 밤 약 1시간 동안 실행됩니다. 그것의 성능은 역사적으로 만족되었습니다. 오작동은 드물며 일시적인 오류는 현재 구성에서 잘 처리됩니다.
- 동기화 작업에 필요한 컴퓨팅은 하루에 약 1시간만 사용되며 사용률에 관계없이 24시간 동안 비용을 지불하므로 워크로드 팀은 현재 디자인의 대안에 관심이 있습니다.
- 팀은 동기화가 실행된 후 매일 밤 서비스를 종료하고 다음 날 다시 배포하는 스크립트를 작성하는 것을 고려했지만, 이 솔루션은 높은 수준의 위험과 복잡성을 수반합니다.
접근 방식 및 결과 적용
- 팀은 작업 기록을 분석하고 함수가 실행된 가장 긴 시간이 2시간 미만이라는 것을 발견했습니다. 전용 계획의 비용을 최악의 시나리오에 대한 Azure Functions 사용 계획의 비용과 비교하고 소비 계획이 더 저렴하다는 결론을 내립니다.
- 팀은 성능이 충분한지 확인하기 위해 성능 테스트를 실행하며 런타임이 약간 증가하지만 여전히 허용 가능한 한도 내에 있습니다.
- 작업이 실행될 때만 비용이 발생하므로 사용 계획을 사용하여 워크로드의 전체 비용이 절감됩니다.
고가용성 디자인 최적화
리소스에 대해 이미 지불한 경우 복구 계획의 일부로 활성-수동 모델보다 활성-활성 또는 활성 전용 배포 우선 순위를 지정합니다.
디자인이 기본적으로 활성-수동 모델을 사용하는 경우, 그렇지 않으면 사용할 수 있는 유휴 리소스가 있을 수 있습니다. 활성-활성으로 변환하면 부하 평준화 및 확장 버스트 요구 사항을 초과 지출 없이 충족할 수 있습니다. 활성 전용 모델을 사용하여 복구 대상을 충족할 수 있는 경우 해당 리소스의 비용을 완전히 제거할 수 있습니다.
Contoso의 과제
- COTS 애플리케이션은 동일한 영역 고가용성을 위해 구성된 Azure Database for MySQL 유연한 서버를 사용합니다. 이 서버는 주 서버와 동일한 가용성 영역에 대기 서버를 제공합니다. 또한 자동 백업을 사용하도록 설정했습니다.
- 워크로드의 RPO는 12시간으로 비교적 길며, RTO는 학교 일 중 3시간입니다.
- 이전 복구 테스트에 따라 팀은 대기 서버에 대한 자동 장애 조치(failover)를 통해 RPO 및 RTO 대상을 충족할 수 있음을 알고 있습니다. 또한 백업에서 데이터베이스 복구를 테스트했으며 이 시나리오에서 대상을 충족할 수 있습니다.
접근 방식 및 결과 적용
- 워크로드 팀은 고가용성 디자인의 이점과 단일 인스턴스의 두 배에 달하는 서비스 비용을 다시 평가합니다.
- 팀은 새 인스턴스를 빌드하고 백업에서 데이터베이스를 복구하는 것을 테스트하고 복구 대상을 계속 준수하므로 대기 인스턴스를 제거하기로 결정합니다.
- 팀은 새로운 복구 전략을 반영하고 새 구성을 통해 비용 절감을 실현하도록 DR 계획을 업데이트합니다.
사용하지 않는 리소스 및 데이터의 클라우드 환경 클린 유지
사용하지 않는 리소스 및 데이터에 대한 배포를 정기적으로 엄격하게 검토하고 서비스를 해제합니다. 시간이 지남에 따라 과거에 일부 용도로 필요했지만 더 이상 사용되지 않는 리소스 및 데이터는 클라우드 환경에 남아 불필요하게 비용이 발생할 수 있습니다. 비용 효율성을 최적화하는 데 도움이 되도록 환경을 클린 유지합니다.
사용되지 않는 리소스를 종료하고 더 이상 필요하지 않을 때 데이터를 삭제하면 낭비가 줄어들고 자금을 확보하여 다른 곳에 투자할 수 있습니다.
Contoso의 과제
- 대학은 역사적으로 솔루션을 서비스 해제에 보수적 인 접근 방식을 촬영하고있다, 그들은 이전 구성에 되돌리기 할 필요가있을 수 있습니다 두려워. 이러한 신중함으로 인해 일부 경우에는 잊어버린 몇 달 동안 하나 이상의 환경에서 서비스를 중단했습니다.
- 중단된 서비스가 발견되면 이러한 서비스에 대한 환경을 검토하는 공식적인 프로세스가 없기 때문에 일반적으로 우연히 발생합니다.
접근 방식 및 결과 적용
- 팀은 App Service에서 지속성 함수에 대한 소비 호스팅으로 마이그레이션의 일환으로 App Service의 서비스 해제를 백로그에 추가합니다. 다음 스프린트의 일환으로 모든 환경에서 App Service 배포를 종료합니다.
- 팀은 중단된 리소스를 사전에 검색하는 데 도움이 되도록 Azure Advisor에 경고를 설정하여 사용하지 않는 리소스를 알립니다.
- 팀은 팀이 중단된 리소스를 식별하기 위해 프로덕션 환경의 월별 전체 검토 및 프로덕션 환경에 대한 분기별 전체 검토를 수행해야 하는 새로운 정책을 구현합니다. 발견된 모든 중단된 리소스는 서비스 해제를 위해 백로그에 추가됩니다.