확장성이란?
비즈니스 세계에서는 성장이 유용할 수 있습니다. 그러나 성장이 너무 빨리 이뤄지고 적절하게 준비하지 않은 경우 성장으로 인해 문제가 발생할 수 있습니다. 이러한 문제 중 하나는 성장이 대규모의 트래픽 증가를 처리하도록 디자인되지 않은 애플리케이션 및 서비스의 안정성에 미치는 영향입니다.
고객과 사용자는 중단 현상에만 집중합니다. 사이트에 액세스할 수 없는 이유가 버그가 있는 코드 때문인지 아니면 너무 많은 사용자가 완전히 코딩된 사이트를 동시에 사용하려고 하기 때문인지 알 수 없으며 관심도 없습니다.
확장성은 증가하는 요구 또는 변경 요구를 조정하는 기능입니다. 애플리케이션 및 서비스는 성장을 수용하기 위해 더 많은 워크로드 양을 처리할 수 있어야 합니다. 확장 가능한 애플리케이션은 가용성 또는 성능에 부정적인 영향을 주지 않고 시간 경과에 따라 확장된 요청 수를 처리할 수 있습니다.
이 단원에서는 확장성과 안정성 간의 관계와 확장성을 달성할 때 용량 계획의 중요성에 대해 알아보고 크기 조정과 관련된 몇 가지 기본 개념과 용어를 간략하게 설명합니다.
확장성/안정성 관계
좋은 소식은 앱을 확장 가능하게 만들면 안정성이 향상될 수도 있다는 것입니다. 예를 들어 시스템의 크기가 자동으로 조정된 다음 단일 가상 머신에서 구성 요소 오류가 발생한 경우, 자동 스케일링 서비스는 다른 인스턴스를 프로비전하여 최소 가상 머신(VM) 수 요구 사항을 충족합니다. 시스템의 안정성이 향상됩니다. 또 다른 예제에서는 기본적으로 스케일링 가능한 Azure Storage와 같은 상위 수준 서비스를 사용하고 있습니다. 스토리지 문제가 있는 경우 서비스는 신뢰할 수 있도록 빌드되었으므로 데이터가 복제됩니다.
비유를 사용하자면 다음과 같습니다. 처음부터 휠체어에 탄 사람들을 수용하기 위해 디자인된 건물 외부에 자주 보이는 접근성 램프를 생각해보세요. 이 접근성 램프가 그러한 용도입니다. 그러나, 유모차에 아기를 태운 부모님이나 계단이 너무 가파르거나 높은 어린이들도 이 램프를 사용할 수 있습니다. 이 사용은 이차 혜택입니다.
안정성은 종종 확장성의 보조 혜택입니다. 시스템을 스케일링 가능하도록 디자인하면 시스템의 안정성도 향상될 수 있습니다.
확장성 및 용량 계획
용량 계획에는 현재 및 향후 수요를 충족하는 데 필요한 리소스를 파악하는 작업이 포함됩니다. 현재 리소스 사용량을 분석한 다음 향후 성장을 대비하여 이 계획을 수행합니다.
향후 용량 요구를 예측하려면 다음과 같은 요인을 고려해야 합니다.
- 예상되는 비즈니스 성장
- 주기적인 변동(계절 등)
- 애플리케이션 제약 조건
- 병목 상태 및 제한 요인 식별
또한 서비스 수준 목표를 설정하여 워크로드와 환경이 변화하면서 이러한 목표를 안정적으로 충족하거나 초과할 용량 관리 계획을 만들 수 있습니다.
용량 계획은 반복 프로세스입니다. 이 모듈을 진행하면서 애플리케이션 구성 요소에 대한 리소스 요구 사항을 살펴보는 방법을 배웁니다.
개념 및 용어
이 모듈에서 사용할 개념과 전략을 완전히 이해하려면 스케일링과 관련된 몇 가지 기본적인 개념과 기본 용어에 대한 사전 지식이 필요합니다.
- 스케일 업: 증가하는 워크로드를 처리하기 위해 구성 요소의 크기를 확장합니다. 수직 스케일링이라고도 합니다.
- 스케일 아웃: 분산 아키텍처를 통해 부하를 분배하기 위해 더 많은 구성 요소 또는 리소스를 추가합니다. 예를 들어 프런트 엔드 집합 뒤에 여러 개의 백 엔드가 있는 간단한 아키텍처를 사용합니다. 부하가 증가하면서 처리할 더 많은 백 엔드(및 프런트 엔드) 서버를 추가합니다. 수평 스케일링이라고도 합니다.
- 수동으로 크기 조정: 리소스의 양을 늘리려면 인적 작업이 필요합니다.
- 자동 스케일링: 시스템은 부하에 따라 리소스 양을 자동으로 조정합니다. 명확하게 말하자면 리소스 양은 증가하거나 감소하는 부하에 따라 위아래로 조정됩니다.
- DIY 크기 조정: 자동 크기 조정을 구성해야 하는 셀프 크기 조정입니다.
- 내재적 크기 조정: 확장 가능하도록 설계되어 사용자가 개입하지 않아도 뒤에서 이 크기 조정을 처리할 수 있는 시스템입니다. 사용자 관점에서 보면 수동으로 프로비전할 필요 없이 더 많은 리소스를 사용할 수 있으므로 거의 무한하게 확장 가능한 것처럼 보입니다.
Tailwind Traders 아키텍처
이 모듈에서는 Tailwind Traders라는 가상 하드웨어 회사의 예제 아키텍처를 사용하겠습니다. 이 전자 상거래 플랫폼은 다음과 같습니다.
이 다이어그램은 언뜻 보면 상당히 복잡하므로 함께 진행해 보겠습니다. 웹 사이트에는 프런트 엔드가 있습니다. 즉, tailwindtraders.com으로 이동할 경우 이야기할 상대입니다.
프런트 엔드는 백 엔드 서비스 집합과 통신합니다. 이러한 백 엔드 서비스에는 쿠폰 서비스, 쇼핑 카트 서비스, 재고 서비스 등의 일반적인 항목이 포함됩니다. 모두 Azure Kubernetes Service에서 실행됩니다. 이 애플리케이션을 사용하여 다른 분야와 기술을 사용할 수 있습니다. Kubernetes에서 실행되는 프런트 엔드 및 백 엔드 서비스에 꼭 집중해야 합니다.
단일 실패 지점
이제 전체 아키텍처를 살펴보았으므로 크기 조정을 고려할 때 주목해야 할 단일 실패 지점과 위치를 검토해보겠습니다.
이러한 서비스는 모두 단일 실패 지점이며 복원력 또는 크기 조정을 위한 용도가 아닙니다. 이러한 서비스 중 하나가 오버로드되면 충돌할 가능성이 높으며, 현재 이 문제를 해결할 쉬운 방법은 없습니다.
이 모듈의 뒷부분에서는 이러한 서비스를 더욱 확장 가능하고 안정적으로 디자인하는 다른 방법을 살펴봅니다.
사전 프로비전된 용량
문제가 있는 것으로 입증될 수 있는 다른 문제를 살펴보겠습니다. 사전 프로비전 용량을 요구하는 서비스/구성 요소:
예를 들어 Cosmos DB를 사용하여 처리량을 사전 프로비전합니다. 이러한 제한을 초과하면 고객에게 오류 메시지를 반환하기 시작합니다. Azure AI 서비스를 사용하여 계층을 선택하면 해당 계층에는 초당 최대 요청 수가 있습니다. 제한 중 하나에 도달하면 클라이언트는 제한됩니다.
새 제품을 출시하는 것과 같이 트래픽이 크게 급증하면 한계에 도달하나요? 현재로서는 알 수 없습니다. 이 문제는 모듈의 뒷부분에서 살펴봅니다.
비용
적절한 작업을 수행하더라도 여전히 성장을 계획해야 합니다. 종량제 서비스:
여기에서는 둘 다 서버리스 기술의 예제인 Azure Logic Apps 및 Azure Functions를 사용합니다. 이러한 서비스는 자동으로 스케일링되며 요청당 요금을 지급합니다. 청구서는 고객 기반에 따라 증가합니다. 적어도 제품 출시와 같은 예정된 이벤트가 클라우드 지출에 미치는 영향은 인지하고 있어야 합니다. 이 모듈의 뒷부분에서는 클라우드 지출도 이해하고 예측합니다.