요금 최적화를 위한 디자인
- 12분
디자인을 변경하거나, 거래를 재작업하거나, 필수 기능을 포기하지 않고 효율성을 높입니다. |
|---|
비용을 절감하기 위해 항상 재설계하거나 재협상할 필요는 없습니다. 경우에 따라 이미 가지고 있는 것을 더 잘 활용할 수 있습니다. 기존 리소스 및 작업을 최적화하지 않으면 실제 혜택을 않고 비용을 낭비할 수 있습니다.
예제 시나리오
Contoso의 BI(비즈니스 인텔리전스) 팀은 여러 부서가 데이터베이스를 직접 건드리지 않고 데이터에 액세스할 수 있도록 GraphQL API 제품군을 호스팅합니다. 시간이 지남에 따라 버전 관리를 추가하고 소비 계층의 단일 Azure API Management 게이트웨이를 통해 모든 것을 실행합니다.
AKS(Azure Kubernetes Service) 클러스터 3개는 API Management 인스턴스 뒤에 있습니다.
하나는 .NET 4.5로 작성된 API용 Windows 노드 풀을 실행합니다.
Java Spring로 작성된 API에 대한 하나의 Linux 클러스터입니다.
하나는 Linux의 .NET Core로 작성된 API용 Windows 노드 풀을 실행합니다. 이전 팀에서 이 클러스터를 상속했습니다.
이러한 클러스터는 API에만 사용되며 이제는 모두 BI 팀에서 관리합니다. 가장 깨끗한 설정은 아니지만 작동하므로 혼자 남겨 두었습니다.
BI 팀은 비즈니스의 비용 센터이므로 운영 비용을 절감하기 위해 요금을 최적화하는 방법을 찾고 있습니다.
적합한 인프라 결합
리소스, 워크로드 또는 팀 등 동일한 위치에서 작업을 실행해 보세요. 더 적은 공간으로 더 많은 공간을 압축하는 데 도움이 되는 서비스를 사용합니다. 특히 보안과 관련된 장만을 고려해 보세요.
더 적은 수의 시스템에 더 많은 유틸리티를 압축하는 경우 하드웨어를 적게 사용하고 모든 것을 관리하는 데 더 적은 비용을 지출합니다. 즉, 비용이 낮아지고 복잡성이 줄어듭니다.
Contoso의 과제
Contoso 팀은 Microsoft AKS 기준 아키텍처를 따랐습니다. 각각 3개의 시스템 노드가 있는 3개의 클러스터를 실행하므로 총 9개의 노드가 있습니다.
매월 세 번 모든 클러스터에 패치 및 업데이트를 적용합니다.
접근 방식 및 결과 적용
팀은 테스트를 수행한 후 모든 API를 3개의 사용자 노드 풀이 있는 단일 클러스터로 결합하는 동시에 원래 클러스터의 동일한 성능 및 OS 특성을 달성하기로 결정합니다.
또한 시스템 노드 풀에 대해 4개의 노드로 통합하여 5개의 가상 머신 비용을 절감합니다.
이제 패치 및 업데이트할 클러스터가 하나만 있으므로 시간이 훨씬 더 절약됩니다.
다음으로, 두 개의 Linux 노드 풀을 하나로 병합하여 작업을 더 간단하게 만드는 방법을 살펴봅니다.
예약 및 기타 인프라 할인 혜택 활용
시간이 지남에 따라 변경될 것으로 예상되지 않는 리소스 종류 및 비용 및 사용률을 예측할 수 있는 리소스 종류에 제공되는 할인을 활용하도록 커밋 및 사전 추적을 통해 최적화합니다. 또한 향후 구매 계약 프로그램과 갱신에 영향을 미치기 위해 라이선스 팀과 협력합니다.
Microsoft는 특정 리소스 및 리소스 범주에 대한 예측 가능하고 장기적인 약정에 대해 할인된 가격을 제공합니다. 사용 기간 동안에는 리소스 비용이 적게 들고 기간 동안 분할 상환이 가능합니다.
라이선스 팀이 리소스별 현재 및 예측 투자를 인식하도록 함으로써 조직이 계약에 서명할 때 약정 권한을 부여하도록 도울 수 있습니다. 어떤 경우에는 이러한 예측 및 약정이 조직의 가격표에 영향을 미쳐 워크로드 비용과 동일한 기술을 사용하는 다른 팀에게도 도움이 될 수 있습니다.
Contoso의 과제
이제 팀은 이전에 흡수했던 과도한 컴퓨팅 및 운영 부담 중 일부를 제거하고 하나의 클러스터로 통합했으므로 클러스터 비용을 낮추기 위한 추가 조치를 찾는 데 관심을 갖고 있습니다.
BI 팀은 AKS 플랫폼에 만족하고 있으므로 가까운 향후에도 계속 사용할 계획이며, 사용 범위도 확대될 가능성이 높습니다.
접근 방식 및 결과 적용
AKS는 Azure Virtual Machine Scale Sets를 기반으로 하므로 팀은 Azure 예약을 조사합니다. 사용자 노드에 필요한 예상 SKU와 배율 단위를 알고 있습니다.
사용자 노드 풀당 시스템 노드 풀과 최소 노드 인스턴스 수를 포함하는 3년 예약을 구매합니다.
이번 구매를 통해 팀은 시간이 지남에 따라 워크로드가 증가하는 것을 허용하면서도 컴퓨팅 요구 사항에 대한 최상의 거래를 얻고 있다는 사실을 알게 되었습니다.
실용적인 경우 고정 가격 청구 사용
사용률이 높고 예측 가능하며 비슷한 SKU 또는 청구 옵션을 사용할 수 있는 경우 리소스에 대한 소비 기반 청구 대신 고정 가격 청구로 전환합니다.
사용률이 높고 예측 가능한 경우, 고정 가격 모델은 일반적으로 비용이 적게 들고 더 많은 기능을 지원합니다. 이를 사용하면 ROI가 높아질 수 있습니다.
Contoso의 과제
- API Management 인스턴스는 현재 모두 소비 계층 SKU로 배포됩니다. API의 사용 패턴을 평가한 결과, API가 전 세계적으로 사용되고 때로는 매우 많이 사용된다는 것을 알게 되었습니다. 팀은 현재 청구 모델과 고정 가격 모델 간의 비용 차이를 분석하기로 결정했습니다.
접근 방식 및 결과 적용
팀은 비용 분석을 수행한 후, 현재 사용량 패턴을 고려할 때 사용량 계층에서 표준 계층으로 마이그레이션하는 것이 전반적으로 비용이 약간 더 저렴할 것이라는 것을 발견했습니다. 내년에 서비스가 확대되면 비용 차이도 더욱 두드러질 가능성이 높습니다. 고정 가격 책정 모델이 요청의 탄력성 특성을 반영하지는 않지만, 때로는 선구매 청구 모델이 올바른 선택일 수도 있습니다.
추가 보너스로, 표준 계층을 사용하면 인바운드 연결에 프라이빗 엔드포인트를 사용할 수 있으며, 팀은 워크로드에 대해 구현하고자 했습니다.
이 경우 SKU 전환은 사용 목적과 프라이빗 엔드포인트 구현에서 가능한 추가 네트워크 세분화의 추가적인 이점을 위해 적합합니다.