사용량 최적화를 위한 디자인
 리소스와 운영의 사용 최대화 이를 솔루션의 협상된 기능적, 비기능적 요구 사항에 적용합니다. |
|---|
서비스와 제품은 다양한 기능과 가격 책정 계층을 가지고 있습니다. 기능 집합을 구매한 후에는 사용하지 않도록 합니다. 해당 계층에 대한 투자를 최대화할 수 있는 방법을 찾습니다. 마찬가지로, 현재 프로덕션 워크로드를 기반으로 사용량에 더 잘 맞는 청구 모델을 찾기 위해 지속적으로 청구 모델을 평가합니다.
예제 시나리오
Contoso University는 현재 대학 교직원이 학년도에 맞춰 수업을 만들고 업데이트할 수 있는 COTS(상업용 제품 및 서비스) 솔루션을 호스팅하고 있으며, 학생이 해당 수업을 등록하는 데 사용하는 기본 등록 포털입니다. 이 솔루션은 SaaS(서비스 제공 소프트웨어) 교육 관리 시스템과 사용자 지정식으로 통합되었으며, 회사는 몇 년 내에 모든 기능을 이 시스템으로 마이그레이션할 계획입니다. 그동안 사용자 지정 통합 구성 요소에 대한 비용을 최적화하고자 합니다.
COTS 제품의 기술 솔루션은 일반적으로 블랙 박스처럼 취급되지만, 데이터베이스는 Azure Database for MySQL입니다. 사용자 지정 통합은 Azure App Service의 표준 서비스 계획에 따라 분산 실행되는 Azure 지속성 함수입니다. 이 App Service는 이전에 대학 웹 사이트를 호스트했지만 더 이상 그렇지 않습니다. 이 내구성 있는 함수는 전용 Azure Storage 계정으로 지원되는 Python 애플리케이션으로, MySQL 데이터베이스에서 SaaS API로 매일 밤 동기화를 수행합니다.
실용적인 경우 사용량 기반 가격 책정 사용
사용량 기반 가격 책정을 제시하는 서비스가 있을 수 있습니다. 즉, 서비스 사용량에 대해서만 비용이 청구되고, 비용 발생을 중단하기 위해 필요하지 않을 때는 서비스를 종료할 수 있습니다. 가끔씩만 활용되는 워크로드 구성 요소가 있는 경우, 24시간 연중무휴로 구성 요소를 실행하는 데 비용을 지불하는 것에 비해 낭비되는 비용을 최소화하는 데 도움이 될 수 있습니다.
사용량 기반 가격 책정을 사용하면 사용한 만큼만 비용을 지불하면 됩니다. 이 옵션은 워크로드 컴퓨팅이 풀타임으로 활용되지 않을 것으로 예상되는 경우 좋은 선택입니다.
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에 경고를 설정하여 사용되지 않는 리소스를 알립니다.
- 팀에서는 사전 프로덕션 환경에 대한 월별 전체 검토와 프로덕션 환경에 대한 분기별 전체 검토를 수행하여 중단된 리소스를 파악하도록 요구하는 새로운 정책을 구현했습니다. 중단된 리소스가 발견되면 해제를 위한 백로그에 추가됩니다.