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