성장 준비

완료됨

준비는 성공의 핵심이라는 이야기를 들어보셨을 것입니다. 이 말은 원활하고 성공적이며 안정적인 성장에서 특히 중요합니다.

클라우드 컴퓨팅의 가장 큰 장점 중 하나는 크기를 조정하는 기능입니다. 이 기능은 클라우드 규모에 한계가 없으므로 성장을 준비하거나 계획할 필요가 없다는 잘못된 가정으로 이어졌습니다.

대부분의 경우 클라우드에 애플리케이션의 요구를 충족하기에 충분한 리소스가 있는 것은 사실입니다. 그러나 용량 요구 사항을 이해하는 것이 여전히 중요한 몇 가지 이유가 있습니다.

  • 클라우드에 요구 사항을 충족하기에 충분한 리소스가 있지만 모든 서비스가 자동으로 확장되거나 본질적으로 확장 가능한 것은 아닙니다. 따라서 서비스 제한을 파악하고 서비스 및 리소스를 스케일 업해야 할 때를 알아야 합니다.

  • 클라우드 리소스는 무제한일 수 있지만 예산은 그렇지 않을 것입니다. 비용을 고려해야 하며 재무 부서에서 근무하는 친구가 예상 클라우드 지출을 알고 싶어 할 것입니다.

유기적 성장 계획

비즈니스 세계에서 유기적 성장은 조직이 더 느리고 자연스러운 성장을 가속하도록 고유한 리소스와 기술에 의존하여 자체 수용력을 확장하는 프로세스를 말합니다.

비즈니스가 유기적으로 성장하면서 클라우드의 용량에 대한 계획을 찾고 있는 경우 가장 먼저 애플리케이션의 대용량 구성 요소를 위해 현재 리소스 요구 사항을 살펴보아야 합니다.

시나리오: 유기적 성장

이 모듈의 앞부분에서 검토해 본 아키텍처로 돌아가 보겠습니다. Tailwind Traders는 혁신적인 새 제품의 출시를 앞두고 있으며 결과적으로 급격한 성장을 예상하고 있습니다. 참고로 이 회사의 아키텍처 다이어그램은 다음과 같습니다.

Full architecture diagram of applications with frontend, backend and other components.

용량 계획을 시작하려면 대용량 구성 요소를 식별해야 합니다. 다음을 포함하는 이 예제에서 다음을 수행합니다.

  • Azure Kubernetes Service 클러스터
  • Azure App Service에서 실행되는 Rewards 앱
  • Cosmos DB, Azure SQL 및 이와 같은 다양한 데이터베이스

이러한 각 대용량 구성 요소에 대해 향후 사용량을 계획하는 데 도움이 되는 현재 리소스 사용량을 이해해야 합니다. 이러한 큰 구성 요소 중 하나에 대한 리소스 사용량을 살펴보겠습니다.

Cosmos DB의 용량 측정

Cosmos DB에서 스토리지는 기가바이트 단위로 측정되고 자동으로 크기가 조정되지만, 비용상의 이유로 측정값을 계속 알고 있어야 합니다.

처리량은 사전 프로비전되며, 요청 단위라는 메트릭을 사용하여 이 처리량을 측정합니다. RU(요청 단위)는 메모리, CPU 및 IOPS가 혼합되어 용량을 계획할 수 있는 단일 메트릭을 제공합니다. 초당 100RU 증분으로 RU를 프로비전합니다.

모든 DB 작업은 RU/초 단위로 측정됩니다. 읽기는 간단합니다. 1KB 읽기가 단일 요청 단위입니다. 다른 작업은 항목 크기, 데이터 일관성, 쿼리 패턴 등의 여러 요소에 따라 계산됩니다.

애플리케이션을 프로파일링할 때 Cosmos DB의 모든 응답에는 요청에서 사용한 RU의 양을 정확히 알려주는 요청 요금 헤더가 포함됩니다. 사용되는 RU의 수를 프로비전된 수와 비교하여 현재 용량이 충분한지 확인할 수 있습니다.

월간 활성 사용자 또는 수익과 같이 리소스 사용량에 비즈니스 메트릭과 상관 관계를 지정하는 것이 좋습니다. 이 상관 관계를 통해 비즈니스 성장에 따른 용량을 계획할 수 있습니다. Azure Monitor에서 이러한 용량 메트릭을 검색할 수 있습니다. 시스템의 리소스 사용량을 이해하면 스케일 업해야 하는 경우와 시간에 따라 발생할 비용을 파악하는 데 도움이 됩니다.

Tailwind Traders의 Cosmos DB 사용 데이터를 구체적으로 살펴보겠습니다. 여기에 사용량 그래프가 있습니다.

Graph of usage over time with users on the Y axis and months on the X axis, graph shows 2530 users in July and rises until 10081 users in October

이 예제에서 Tailwind Traders는 10,000명의 현재 사용자 기준으로 평균2,500명의 MAU(월간 활성 사용자)를 기록하며 성장하고 있습니다.

스토리지를 살펴보면 데이터베이스가 사용 가능한 5TB 중 300GB(6%)를 사용하고 있으며, 매월 50GB(1%)만큼 성장한다는 것을 알 수 있습니다.

Graph of storage over time with storage amounts on the Y axis and months on the X axis, graph shows two lines, one for storage at 151 in July and ending at 300 for October, the other for capacity which is flat at 5000 for all months

처리량 측면에서는 300/1000으로 매월 10%의 성장률을 보입니다.

Graph of throughput over time with RUs on the Y axis and months on the X axis, graph shows two lines, one for storage at 0 in July and ending at 300 for October, the other for provisioned RUs which is flat at 1000 for all months

이제 시스템 리소스 메트릭을 이해하며, 처리량을 스케일링해야 하는 경우와 시간에 따라 발생하는 비용도 알 수 있습니다.

이제 용량 계획에 도움이 되는 그래프를 생성할 수 있습니다.

Graph of RUs over time with RUs on the Y axis and months on the X axis. The graph shows two lines. One for storage at 0 in July and ending at 1000 next may. The other for capacity, which is flat at 1000 for all months. The two lines intersect at 1000 and there's an arrow emphasizing their intersection point.

이제 5월에는 데이터베이스의 RU 용량에 도달하게 되므로 먼저 스케일링해야 합니다. 흥미로운 또 다른 정보는 지금은 사용량이 사전 프로비전된 용량 근처에도 미치지 못하므로 현재 CosmosDB 데이터베이스를 스케일 다운할 수도 있다는 것입니다.

무기적 성장 계획

이전 예제에서는 유기적 성장을 계획했습니다. 무기적 성장은 회사의 자체 비즈니스 활동이 증가하는 것이 아니라 외부 요인에서 발생합니다. 자연스러운 진행보다 갑작스럽게 많이 증가한 사용량을 포함하는 경향이 있습니다.

간혹 트래픽, 사용자 등이 증가하는 시간을 미리 알 수 없는 경우가 있습니다. 이러한 경우를 대비하여 시스템을 가능하면 자동으로 확장 가능하도록, 가능하지 않으면 정상적으로 실패하도록 구축해야 합니다. 자세한 내용은 이 모듈 뒷부분에서 다루겠습니다.

신제품 출시와 같은 경우 계획하고 준비할 수 있는 무기적 성장을 경험할 수 있습니다. 팀이 엔지니어링, 제품, 마케팅 및 재무 전반에 걸쳐 함께 작업하는 경우 리소스 사용량 및 성장 패턴을 얻는 방법을 알고 있습니다. 이러한 이벤트가 리소스 요구 사항에 미치는 영향을 예측하고 그에 따라 변경을 구현하기 위해 합리적인 노력을 기울일 수 있습니다.

조직과 특정 이벤트에 따라 이러한 영향을 정확히 파악합니다. 언제나 정확하게 파악할 수는 없지만 준비를 통해 유리한 위치에서 출발할 수 있습니다.

시나리오: 무기적 성장

무기적 성장 계획에 대한 다른 가정 상황을 살펴보겠습니다. Tailwind Traders에서 세간의 이목을 끄는 혁신적인 신제품 출시를 앞두고 마케팅 이벤트를 진행하려고 합니다. 판매 사이트에 5,000명 이상의 사용자가 몰릴 것으로 예상하고 있습니다.

유기적 성장의 이전 예제의 데이터를 사용하고 가능하면 인과 관계로 제품/마케팅 팀(예: 사용자 수)에서 얻은 비즈니스 메트릭과 상관 관계를 지정합니다. 무기적 성장을 계획하기 시작할 수 있습니다.

아시다시피 이전 시나리오에서 2,500명의 사용자에게는 대략 50GB의 스토리지와 100개의 RU가 필요합니다. 이제 해당 데이터를 사용하여 이 이벤트에 대한 준비가 되었는지를 확인할 수 있습니다. 5000명의 사용자를 예상하는 경우 스토리지 100GB와 200개의 RU가 필요합니다.

Graph of storage usage over time with storage units on the Y axis and months on the X axis. The graph shows two lines. One for storage at 151 in July and ending at 400 in November, and the other for capacity that is flat at 5000 for all months. There's an arrow labeled with 'After marketing event' pointing at the November data point.

스토리지 용량이 이벤트로 인해 예상한 성장에 비해 충분한지 확인할 수 있습니다. 이러한 용량은 자동으로 스케일링되므로, 이제 새로운 비용을 파악하고 해결할 방법에만 집중하면 됩니다.

또한 이벤트 후에는 RU가 50% 용량에 불과할 것으로 예측할 수 있습니다. 따라서 이 이벤트에 대한 Cosmos DB 용량 측면에서는 걱정할 필요가 없습니다.

그러나 비용에는 영향을 줄 수 있습니다.

Bar Graph with three sets of bars: Storage, Throughput, and Total. The Y axis shows dollar amounts. For each set, there's a bar for before event (USD) and a bar for after event (USD). The values are 75 and 100 for Storage, 59.52 and 59.52 for Throughput, and 134.52 and 159.52 for total.

100GB의 스토리지를 추가하면 $25/월 비용이 추가로 발생합니다. 처리량 가격은 고객이 프로비전된 RU에 비용을 지불한 것과 동일하게 유지되며 이미 충분합니다. 요점은 이 마케팅 이벤트로 인해 CosmosDB 청구서가 $25USD로 증가할 수 있다는 사실입니다.

지식 점검

1.

비즈니스의 자체 용량이 자연스럽고 예측 가능한 방식으로 확장될 때, 다음과 같이 부릅니다.

2.

Cosmos DB를 사용하면 요청 단위에 통합되는 메트릭은 무엇인가요?

3.

다음 중 용량을 계획할 때 리소스 사용량과 상관 관계를 지정해야 하는 비즈니스 메트릭이 아닌 옵션은 무엇입니까?