시간 경과에 따른 모니터링 및 최적화
 에코시스템에 따라 워크로드가 변화함에 따라 지속적으로 적정 규모의 투자를 유지합니다. |
|---|
이전에 중요했던 일이 지금은 중요하지 않을 수도 있습니다. 운영 워크로드를 평가하면서 학습하면 아키텍처, 비즈니스 요구 사항, 프로세스, 심지어 팀 구조까지 바뀔 것으로 예상합니다. SDLC(소프트웨어 개발 수명 주기) 사례가 발전해야 할 수도 있습니다. 클라우드 플랫폼, 리소스, 계약 등 외부 요인도 변경될 수 있습니다.
모든 변화가 비용에 미치는 영향을 신중하게 평가해야 합니다. 정기적으로 변화 사항과 ROI 추세를 모니터링하고 기능적, 비기능적 요구 사항을 조정해야 하는지 평가합니다.
예제 시나리오
Contoso Air는 항공사를 대상으로 수하물 추적 솔루션을 제공합니다. 워크로드는 Azure에서 호스트되고, 데이터베이스로 Cosmos DB를 사용하는 AKS에서 실행되며 메시징에는 Event Hubs를 사용합니다. 워크로드는 미국 서부와 미국 동부 지역에 배포됩니다.
지속적으로 환경과 지원 비용을 평가하고 최적화합니다.
비용 추적 시스템을 사용하여 리소스, 데이터 및 유료 지원 비용을 지속적으로 평가하고 최적화합니다. 사용 중지, 바꾸기, 다시 빌드 또는 리팩터링이 가능한 활용도가 낮은 리소스가 있나요?
완전히 활용되지 않은 리소스에 대한 비용을 지불하지 않으면 비용이 절감됩니다. 가격 책정 메트릭을 이해하면 비용 모델에 더 부합하는 결정을 내리는 데 도움이 될 수 있습니다. 이를 통해 불필요한 청구도 방지할 수 있습니다. 활용도가 낮은 리소스의 크기를 조정하거나 제거하거나, 심지어 SKU를 변경하는 것만으로도 비용을 절감할 수 있습니다.
기술 공급자와의 지원 계약 사용을 평가하고 적절한 규모로 조정하면 비용을 절감할 수도 있습니다.
Contoso의 과제
- 워크로드 팀은 항상 예산 이하로 업무를 처리했기 때문에 비용 효율성을 위한 최적화는 우선 순위가 아니었습니다.
- 내년에 워크로드의 안정성을 개선할 계획이지만, 그렇게 하면 Azure 비용이 늘어나 워크로드가 예산을 초과할 가능성이 높다는 것을 알고 있습니다. 내년 예산을 증액해 달라고 요청하는 것을 고려하고 있습니다.
접근 방식 및 결과 적용
- 팀에서는 추가 비용을 요청하기 전에 현재 Azure 및 지원 비용을 평가하여 잠재적인 절약 기회를 찾기로 결정했습니다. 기존 비용 추적 시스템에서 리소스별, 리소스 그룹별, 태그별 비용 내역을 살펴보고 예기치 못한 지출을 발견했습니다.
- 팀에서는 더 이상 사용되지 않는 빌드 시스템에 사용되던 VM이 환경에서 실행 중이라는 사실과 Azure Storage에 비용이 덜 드는 계층으로 옮길 수 있는 상당한 양의 오래된 데이터가 있다는 사실, 그리고 사용하지 않는 컨설팅 시간이 포함된 클라우드 공급자와의 지원 계약 비용을 지불하고 있다는 사실을 알게 되었습니다.
- 팀에서 사용하지 않는 VM을 삭제하고 이전 데이터를 보관 스토리지로 이동하여 Azure 비용을 최적화합니다. 컨설팅 서비스를 최대한 활용하기 위해 클라우드 공급자와 보다 긴밀하게 협력하기 시작했습니다.
- 팀은 향후 워크로드 비용을 평가하기 위해 백로그에 되풀이 작업을 추가합니다.
지속적으로 워크로드를 검토하고 개선
ROI 데이터를 기반으로 아키텍처 디자인 결정, 리소스, 코드 및 워크플로를 지속적으로 조정합니다.
정기적으로 메트릭, 성능 데이터, 청구 보고서 및 기능 사용을 검토하면 비용을 절감할 수 있는 미세 조정으로 이어질 수 있습니다.
Contoso의 과제
- 팀은 전통적으로 예산 내에서 운영되었기 때문에 기존 기능에 대한 대안적인 방식을 고려하지 않았습니다. 대신, 대부분의 계획은 새로운 기능을 빌드하는 데 집중되어 있습니다.
- 초기 평가를 통해 낭비를 발견한 후 나머지 현재 구성 요소를 살펴보고 최적화 기회를 찾기로 결정했습니다.
접근 방식 및 결과 적용
- 팀에서 낮은 우선 순위 흐름에 필요한 것보다 더 많은 리소스를 할당했으며, 성능 요구 사항을 유지하면서 할당된 처리량을 안전하게 줄일 수 있다는 것을 발견했습니다. 구체적으로, 최대 부하를 처리하기 위해 초과 프로비전에서 벗어나 대신 큐 기반 부하 평준화 시스템을 구현할 수 있습니다.
- 또한 컴퓨팅 플랫폼에서 선택한 SKU에 일부 인증 코드를 바꾸는 새로운 기능이 추가되었음을 발견했습니다. 이 기능을 사용하면 유지 관리하고 테스트해야 할 코드가 줄어듭니다.
배포 환경 최적화
다양한 SDLC 환경을 다르게 취급하고 적절한 수의 환경을 배포합니다. 프로덕션 환경은 주요 비용 요인이 되어야 합니다.
모든 환경에서 프로덕션을 시뮬레이션할 필요는 없다는 점을 이해하면 비용을 절감할 수 있습니다. 개발 및 테스팅 환경에는 기능, SKU, 인스턴스 수, 심지어 로깅까지 다를 수 있습니다.
필요에 따라 사전 프로덕션 환경을 만들고 더 이상 필요하지 않으면 제거함으로써 비용을 절감할 수도 있습니다.
Contoso의 과제
- 워크로드 팀은 프로덕션 환경보다 사전 프로덕션 환경에 더 많은 비용을 지출합니다. 이는 어떤 시나리오에서는 중요할 수 있지만, 이 워크로드에는 과도한 것으로 보입니다.
- 사전 프로덕션 환경은 프로덕션 환경과 매우 밀접하게 일치하도록 빌드되었습니다. 워크로드 팀은 하위 환경에서 프로덕션 환경과 매우 유사한 환경을 갖는 것을 높이 평가합니다. 이를 통해 프로덕션 환경에서의 동작이 하위 환경과 일치할 것이라는 높은 확신을 가질 수 있기 때문입니다.
접근 방식 및 결과 적용
- 팀은 신중한 평가 끝에 환경 간의 차이점으로 인해 발생하는 비용 절감을 실현하기 위해 약간의 추가 위험을 감수할 수 있다는 결정을 내렸습니다.
- 팀은 몇몇 테스트 환경을 동일한 인프라에 함께 배치하고, 사용하지 않는 환경은 밤새도록 종료하기로 결정했습니다.
- 또한 팀은 좌측으로 이동하여 로컬 개발자 워크스테이션에서 내부 루프 개발 및 테스트를 수행할 수 있는 기회도 찾습니다.
- 사전 프로덕션 환경과 개발 사례에서 작은 타협을 이루는 방법을 찾음으로써, 자동화 활동에 효과적으로 사용할 수 있는 예산을 확보했습니다.