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