용량 계획 관련 고려 사항
- 5분
기본 용량 계획은 몇 가지 간단한 계산으로 시작하지만 프로세스를 복잡하게 만들 수 있는 요인이 있습니다. 간단한 현재 및 예측 사용량 번호 외에도 다음 고려 사항도 고려해야 합니다.
- 서비스 제한 및 할당량
- 비용 제한 사항
- 코드 및 구성 비효율성
- 종속성
이 단원에서는 이러한 고려 사항이 용량 계획에 어떤 영향을 미칠 수 있는지와 각 고려 사항을 해결하는 방법을 살펴봅니다.
서비스 제한 및 할당량
클라우드 컴퓨팅을 무제한 리소스로 보는 경향이 있습니다. 기존 서버/데이터 센터 모델에 비해 클라우드의 용량은 무한해 보입니다. 클라우드는 완전히 새로운 수준의 규모를 제공합니다. 그러나 다른 모든 것과 마찬가지로 몇 가지 제한이 있습니다. 용량 계획에는 이러한 서비스 제한에 도달할 시기를 이해하는 것이 포함됩니다.
시스템 및 해당 아키텍처를 살펴볼 때 사용 중인 클라우드 서비스에 대한 제한을 이해해야 합니다. 예를 들어 기본적으로 Azure에서 VM 가용성 집합당 최대 200개의 VM을 가질 수 있습니다. 이 제한은 방금 시작하는 경우 충분한 VM보다 더 많은 것처럼 보일 수 있습니다. 그러나 해당 제한에 도달하면 더 이상 VM을 프로비전할 수 없으므로 잠재적으로 중단이 발생할 수 있습니다.
마찬가지로 기본적으로 구독당 지역당 250개의 스토리지 계정을 가질 수 있습니다. 이러한 제한은 모두 늘릴 수 있는 소프트 제한의 예입니다. 그러나 일부 서비스에는 최대 제한이 있으며 다음 링크에서 찾을 수 있습니다.
Azure 구독 및 서비스 제한, 할당량 및 제약 조건
이러한 제한 및 할당량은 인식하고 모니터링해야 합니다. 그렇게 하는 방법을 살펴보겠습니다.
Azure Portal
탐색 창의 아래의 > 섹션에서 서비스 할당량 및 해당 제한과 관련된 위치를 볼 수 있습니다. 네트워크/컴퓨팅 및 Azure 지역과 같은 서비스 범주를 필터링할 수 있습니다. 당신이 한계에 얼마나 가까운지를 보여줍니다.
코드 사용
이 잘린 예제와 같이 모든 Azure 서비스에 대한 엔드포인트를 사용하여 Usage - List 현재 리소스 사용량 정보와 구독에서 컴퓨팅 리소스에 대한 제한을 가져올 수 있습니다.
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{
"currentValue": 124,
"/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
"limit": 1000,
"name": {
"localizedValue": "Virtual Networks",
"value": "VirtualNetworks"
},
"unit": "Count"
}
현재 사용 중인 Azure VNet(Virtual Network)의 수는 1000으로 제한되는 124개임을 알 수 있습니다. 제한을 늘리려면 지원 요청이 필요하므로 임계값에 근접할 수 있는 시기를 미리 알고 있어야 합니다.
비용 제한 사항
크기 조정은 문제에 더 많은 리소스를 던지는 것만이 아닙니다. 조직에서 클라우드 환경의 비용을 이해하고 리소스를 더 추가하는 것이 일반적으로 더 많은 비용과 동일하다는 것을 이해하는 것이 중요합니다. 이 비용을 인식하고 재무 팀과 협력하여 현재 및 예상 클라우드 지출에 대해 합의하는지 확인합니다.
처음에 시스템을 설계할 때와 이미 실행 중인 시스템에 대한 정기적인 검토를 수행할 때 모두 비용을 예측해야 합니다. Azure는 다음을 도울 수 있는 도구를 제공합니다.
- Azure 계산기를 사용하여 환경 비용을 계획합니다.
- Azure Portal에서 현재 및 예상 월별 지출을 검토합니다.
- Microsoft Cost Management에서 예산을 설정합니다. 이 도구를 사용하면 관리 그룹, 리소스 그룹 및 구독을 비롯한 다양한 범위에서 비용을 검사할 수 있습니다.
코드 및 구성 비효율성
경우에 따라 더 많은 리소스를 지시하면 문제를 해결할 수 있지만 비용이 많이 듭니다. 크기 조정이 솔루션이 아니거나 전체 솔루션이 아닌 경우도 있습니다. 경우에 따라 크기 조정이 필요한 것처럼 보이는 것은 실제로 잘못된 코딩 또는 구성으로 인한 문제일 수 있습니다.
리소스를 확장하기 전에 먼저 버그를 찾아서 비용 및 시간을 절약할 수 있습니다. 이 방법의 몇 가지 예는 다음과 같습니다.
- 대규모 noSQL 데이터베이스에서 하나의 파티션만 사용하는 등 핫 파티션이 있는 잘못 디자인된 데이터베이스가 있는 경우 크기 조정에 관계없이 속도가 느립니다.
- 비효율적인 데이터베이스 쿼리가 있는 경우, 데이터베이스에 추가적인 리소스를 투입하기 전에 쿼리를 더욱 효율적으로 최적화하세요. 경우에 따라 일반적인 쿼리를 기반으로 데이터베이스에 올바른 인덱스를 추가하면 비용이 100배 떨어질 수 있습니다.
- 시간 제한이 잘못 설정된 경우 서버와 데이터베이스 간의 일관되지 않은 시간 제한으로 인한 재시도로 인해 데이터베이스 연결이 포화 상태가 될 수 있습니다. 이 경우 데이터베이스 크기를 조정하기 전에 설정을 수정해야 합니다.
- 개발자의 코드가 비효율적인 경우 문제를 해결하기 위해 보다 효율적인 코드를 작성할 수 있나요? 코드에서 메모리를 해제할 수 없으므로 필요하지 않은 경우 더 큰 메모리 VM을 사용하고 있을 수 있습니다. 이러한 수정은 상당한 비용 절감을 제공할 수 있습니다.
종속성
이 모듈에 설명된 몇 가지 문제를 해결하는 데 필요한 변경 내용은 애플리케이션 개발자에 대한 종속성이 있는 경우가 많습니다. 여기에 권장되는 몇 가지 솔루션 및 모범 사례는 사용자와 개발자 간의 협업이 필요합니다.
이러한 권장 사항을 모두 직접 구현하지 못할 수 있습니다. 그러나 클라우드 시스템과 해당 기능 및 특성을 이해하면 시스템 및 확장성 및 안정성을 개선하는 변화의 원동력이 될 수 있습니다.