용량 계획 관련 고려 사항

완료됨

기본 용량 계획은 몇 가지 간단한 계산으로 시작하지만 프로세스를 복잡하게 할 수 있는 몇 가지 요소가 있습니다. 간단한 현재 및 예상 사용량 수치 외에도 다음 요인도 고려해야 합니다.

• 서비스 제한 및 할당량
• 비용 제한
• 코드 및 구성 비효율성
• 종속성

이 단원에서는 이러한 고려 사항이 어떻게 용량 계획에 영향을 미치는지와 각 영향을 해결하는 방법에 대해 알아봅니다.

서비스 제한 및 할당량

클라우드 컴퓨팅을 무제한 리소스로 표시하는 경향이 있습니다. 기존의 서버/데이터 센터 모델과 비교하면 클라우드의 용량은 무제한인 것처럼 보입니다. 클라우드는 완전히 새로운 수준의 규모를 제공합니다. 그러나 이 클라우드 역시 제한은 있습니다. 용량 계획에는 해당 서비스 제한에 도달하는 시기를 이해하는 과정이 포함됩니다.

시스템 및 아키텍처를 살펴볼 때 사용 중인 클라우드 서비스의 제한을 이해해야 합니다. 예를 들어 기본적으로 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 VM(Virtual Network) 수가 124개이며 제한이 1,000개인 것을 확인할 수 있습니다. 제한이 증가하면 지원 요청이 필요하므로 임계값에 근접할 수 있는 시기를 미리 알고 있어야 합니다.

비용 제한

스케일링은 단순히 문제가 발생한 리소스를 더 많이 throw하는 것이 아닙니다. 조직에서 클라우드 환경의 비용을 이해하는 것이 중요하며 더 많은 리소스를 추가하면 일반적으로 더 많은 비용이 소모됩니다. 이 비용을 인식하고 현재 및 예상 클라우드 지출에 대한 의견이 일치하도록 재무 팀과 협력해야 합니다.

처음 시스템을 디자인할 때와 이미 실행 중인 시스템을 정기적으로 검토할 때의 비용을 예측해야 합니다. Azure는 다음 작업에 도움을 줄 수 있는 도구를 제공합니다.

• Azure 계산기를 사용하여 환경 비용 계획.
• Azure Portal에서 현재 및 예상 월별 비용을 검토합니다.
• Microsoft Cost Management에서 예산을 설정합니다. 이 도구를 사용하여 관리 그룹, 리소스 그룹 및 구독을 비롯한 다양한 범위에서 비용을 검사할 수 있습니다.

코드 및 구성 비효율성

경우에 따라 더 많은 리소스를 전달하여 문제를 해결할 수 있지만 이 방법은 비용이 발생합니다. 때로는 크기 조정이 솔루션이 아니거나 완벽한 솔루션이 아닐 수 있습니다. 경우에 따라 크기 조정이 필요한 것처럼 보이지만 실제로는 잘못된 코딩이나 구성으로 발생한 문제일 수 있습니다.

리소스를 스케일 아웃하기 전에 먼저 버그를 찾아서 비용과 시간을 절약할 수 있습니다. 이 방법의 몇 가지 예는 다음과 같습니다.

• 대용량 noSQL 데이터베이스에서 하나의 파티션만 사용하는 등 핫 파티션이 있는 데이터베이스를 잘못 디자인한 경우 크기와 상관없이 속도가 느려집니다.
• 데이터베이스 쿼리가 비효율적인 경우 데이터베이스에 더 많은 리소스를 throw하기 전에 데이터베이스를 더 효율적으로 만드세요. 경우에 따라 일반적인 쿼리에 따라 데이터베이스에 올바른 인덱스를 추가하는 것만으로 비용을 100배 절약할 수 있습니다.
• 시간 제한이 올바르게 설정되지 않은 경우 서버와 데이터베이스 간의 시간 제한 불일치로 인한 재시도로 데이터베이스 연결이 포화 상태가 될 수 있습니다. 이 경우 데이터베이스를 스케일링하기 전에 설정을 수정해야 합니다.
• 개발자 코드가 비효율적이면 문제를 해결하는 더 효율적인 코드를 쓸 수 있나요? 아마도 코드는 가능한 경우에도 메모리를 확보하지 않으므로 필요하지 않은 대용량 메모리 VM을 사용하고 있었을 것입니다. 이런 사항을 수정하면 상당한 비용을 절약할 수 있습니다.

종속성

이 모듈에 설명된 일부 문제를 해결하는 데 필요한 변경 사항은 종종 애플리케이션의 개발자에 대한 종속성이 있습니다. 여기에서 권장하는 몇 가지 솔루션과 모범 사례를 수행하려면 사용자와 해당 개발자 간의 협업이 필요합니다.

이러한 권장 사항을 모두 직접 구현하지 못할 수 있습니다. 그러나 클라우드 시스템과 해당 기능 및 특성을 이해하면 시스템과 시스템의 확장성 및 안정성을 개선하는 변화의 원동력이 될 수 있습니다.