애플리케이션 확장성 향상
이제 성장 준비의 기본 사항을 이해하고 용량 계획에서 고려해야 할 요소를 알고 있으므로 애플리케이션을 최대한 확장 가능하게 만드는 문제를 해결할 수 있습니다.
아키텍처 검토
기억해야 할 핵심 사항은 시스템에 대한 정기적인 아키텍처 검토를 수행해야 한다는 것입니다.
클라우드 리소스 배포 방법을 개선하기 위해 인프라와 같은 사례를 코드로 적용할 수 있습니다. 애플리케이션 코드를 정기적으로 업데이트하고 개선하며 기본 플랫폼 리소스를 사용하여 동일한 작업을 수행해야 합니다.
아키텍처 검토를 수행하면 향상이 필요한 영역을 식별할 수 있습니다.
Azure 아키텍처 센터에는 클라우드에서 애플리케이션을 설계하는 데 도움이 되는 다양한 리소스가 있으며, 다음 링크를 통해 많은 스케일링 성능 권장 사항을 애플리케이션 아키텍처 가이드에서 찾을 수 있습니다.
시나리오: Tailwind Traders 아키텍처
첫 번째 단계는 아키텍처 및 애플리케이션을 평가하여 약점이 있는 위치를 파악하고 강점을 인식하는 것입니다. 강점은 무엇인가요?
이전 단원에서 살펴본 시나리오를 다시 살펴보세요. 다시 조직의 아키텍처 다이어그램으로 돌아와 보겠습니다.
애플리케이션을 더 작은 마이크로 서비스로 분해했으며 이러한 서비스 중 일부는 Azure Kubernetes Service의 컨테이너로 있거나 VM 또는 App Service에서 실행할 수 있습니다. Functions 및 Logic Apps와 같은 본질적으로 스케일링 가능한 서비스를 사용하고 있습니다.
이러한 변경은 좋지만 애플리케이션의 확장성을 높일 수 있는 몇 가지 개선 사항이 있습니다. 예를 들어 이제 제품 서비스에 집중합니다. 다이어그램에서 제품 서비스는 Kubernetes에서 실행되지만 Azure의 VM에서 실행되는 제품 서비스에 대한 설명이 있다고 가정합니다. 서버, App Service 또는 컨테이너에서 실행되는지와 관계없이 약간 다른 구현을 사용하여 스케일링 개념을 애플리케이션에 적용할 수 있습니다.
현재 제품은 단일 Azure SQL 데이터베이스에 연결된 단일 VM에서 실행됩니다. 스케일 아웃하려면 이 VM을 사용하도록 설정해야 합니다. Azure Virtual Machine Scale Sets를 사용하여 부하 분산된 동일한 VM 그룹을 만들고 관리할 수 있습니다. 이제 두 개 이상의 VM이 있으므로 VM 간에 트래픽을 분산하는 부하 분산 장치를 도입해야 합니다.
가상 머신 크기 집합
단일 VM이 아닌 가상 머신 확장 집합을 활용하면 다음과 같은 몇 가지 이점이 있습니다.
- 호스트 메트릭, 게스트 내 메트릭, Application Insights 또는 일정에 따라 자동 크기 조정할 수 있습니다.
- Azure 영역 내의 독립 실행형 데이터 센터인 가용성 영역(AZ)을 사용할 수 있습니다. AZ 지원을 사용하면 여러 AZ에 VM을 분산시켜 애플리케이션의 안정성을 높이고 데이터 센터 오류로부터 VM을 보호할 수 있습니다. 확장 집합 내의 새 인스턴스는 자동으로 균등하게 AZ에 배포됩니다.
- 부하 분산 장치를 추가하는 것이 쉬워집니다. 가상 머신 확장 집합은 기본 계층 4 트래픽 분석에 Azure Load Balancer 사용을 지원합니다. 또한 고급 L7 트래픽 배포 및 SSL 종료를 위해 Azure Application Gateway를 지원합니다.
확장 집합을 구현하기 전에 고려해야 할 몇 가지 중요한 요인이 있습니다. 특히 다음에 대해 주의하세요.
- 클라이언트가 특정 백 엔드에 걸리지 않도록 인스턴스 연결을 피하세요.
- VM에서 영구 데이터를 제거하고 Azure Storage 또는 데이터베이스와 같은 다른 위치에 저장합니다.
- 축소를 위해 디자인합니다. 애플리케이션이 다시 쉽게 스케일 다운할 수 있는 것도 중요합니다. 트래픽을 처리하는 서버 풀에 더 많은 인스턴스가 추가되는 문제뿐만 아니라 부하가 감소하면 인스턴스가 갑작스럽게 종료되는 문제도 정상적으로 처리해야 합니다. 크기 조정의 스케일 다운 측면은 종종 간과됩니다.
분리
확장 집합을 사용하여 더 많은 VM을 추가했습니다. 스케일 아웃은 “스케일링이 필요함”에 대한 일반적인 대답입니다. 하지만 단일 메트릭에서만 확장할 수 없으며, 이 대답은 제품 서비스에서 수행하는 모든 작업과 관련이 없을 수도 있습니다.
이 시나리오에서는 제품 서비스에 작업이 있습니다. 제품 이미지를 가져와서 해당 이미지가 업로드된 후 사용합니다. 이것은 해당 이미지를 트랜스코딩하고 썸네일, 카탈로그의 그림 등을 위한 여러 가지 크기로 저장합니다. 이미지 처리는 CPU를 많이 사용하지만 일반 사용에서는 메모리를 많이 사용합니다.
이미지 처리는 백그라운드 작업으로 분할될 수 있는 비동기 작업입니다. 큐를 사용하여 이미지 처리 서비스를 분리하여 이 작업을 수행할 수 있습니다. 분리를 통해 메모리(제품 서비스)의 서비스 및 CPU 또는 큐 길이의 기타 서비스(이미지 처리 서비스)와 같은 두 가지 서비스를 독립적으로 스케일링하고 다른 확장 집합이 해당 메시지를 사용하고 이미지를 처리하도록 할 수 있습니다.
큐로 크기 조정
Azure에는 두 가지 유형의 큐 기능이 있습니다.
- Azure Service Bus 큐 더 광범위한 Azure Service Bus 제품의 일부이며, pub/sub 및 고급 통합 패턴을 제공하는 고급 큐 기능입니다.
- Azure Storage 큐 Azure Storage 위에 구축된 단순 REST 기반 큐 인터페이스입니다. 이 기능은 안정적이고 영구적인 메시징을 제공합니다.
이 시나리오의 요구 사항은 간단하므로 Azure Storage 큐를 사용할 수 있습니다. 이 백그라운드 작업을 완전히 분리했기 때문에 제품 계층을 모두 스케일링할 필요는 없습니다.
메모리 내 캐싱
애플리케이션의 성능을 향상하는 다른 방법은 메모리 내 캐싱을 구현하는 것입니다.
이제 성능이 확장성과 정확히 일치하지 않음을 알았지만 애플리케이션의 성능을 향상하여 다른 리소스의 부하를 줄일 수 있습니다. 이 개선 사항은 곧 확장할 필요가 없다는 의미입니다.
Azure Cache for Redis는 관리되는 Redis 기능입니다. Redis는 많은 패턴 및 사용 사례에 사용할 수 있습니다. 이 시나리오에 있는 제품 서비스의 경우 캐시 배제 패턴을 구현할 가능성이 높습니다. 이 패턴에서는 필요에 따라 데이터베이스에서 캐시로 항목을 로드하여 애플리케이션의 성능을 높이고 데이터베이스의 부하를 줄입니다.
캐싱 웹 콘텐츠 또는 사용자 세션 캐싱에 메시징 큐로 Redis를 사용할 수도 있습니다. 이러한 유형의 캐싱은 쇼핑 카트 서비스와 같은 시스템의 다른 서비스에 더 적합할 수 있습니다. 이 서비스에서는 쿠키를 사용하는 대신 Redis의 세션당 쇼핑 카트 데이터를 저장할 수 있습니다.
데이터베이스 크기 조정
컴퓨팅 리소스의 확장성을 향상했으므로 이제 데이터베이스를 살펴보세요. 이 시나리오에서는 Azure에서 관리되는 SQL Server 기능인 Azure SQL 데이터베이스를 사용합니다.
관계형 데이터베이스는 비관계형 데이터베이스보다 스케일 아웃하기가 더 어렵습니다. 데이터베이스 크기를 스케일 업하기 위해 가장 먼저 할 일은 데이터베이스 크기를 조정하는 것입니다. 이 크기 조정은 평균 가동 중지 시간이 4초 미만일 때 쉽게 수행될 수 있습니다. Azure SQL에서 간단한 API 호출을 사용하거나 포털에서 슬라이더를 사용합니다.
이 크기 조정이 트래픽 특성에 따라 요구 사항을 충족하지 못할 경우 데이터베이스에 대한 읽기를 스케일 아웃하는 것이 적합할 수 있습니다. 읽기 트래픽을 읽기 복제본으로 라우팅할 수 있게 하기.
참고
Azure SQL을 통해 프리미엄 또는 중요 비즈니스용 계층을 사용하는 경우 기본적으로 읽기 스케일 아웃이 사용하도록 설정됩니다. 기본 또는 표준 계층에서는 사용하도록 설정할 수 없습니다.
이 변경 내용은 코드로 구현해야 합니다. 방법은 다음과 같습니다.
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
연결하려는 서버를 지정하도록 데이터베이스 연결 문자열의 ApplicationIntent 특성을 업데이트합니다. 복제본에 연결하려면 ReadOnly를 사용하고 마스터에 연결하려면 ReadWrite를 사용합니다.
이 명령은 코드로 구현해야 하므로 상황에 적합한 솔루션이 아닐 수도 있습니다. 모든 단일 제품 서비스에서 읽고 쓰는 기능이 필요한 경우 어떻게 해야 합니까?
이 경우 분할을 사용하여 SQL DB를 스케일 아웃하는 경우를 볼 수 있습니다.
데이터베이스 분할
읽기 복제본을 확장하거나 구현한 후에도 데이터베이스 리소스가 시스템의 요구 사항을 충족하지 못하면 다음 옵션은 분할입니다.
분할이란 동일하게 구조화된 대량의 데이터를 독립적인 많은 데이터베이스에 분산하는 기술입니다. 분할은 많은 이유로 필요할 수 있습니다. 예를 들면 다음과 같습니다.
- 총 데이터 양이 너무 커서 개별 데이터베이스의 제약 조건에 맞지 않습니다.
- 전체 워크로드의 트랜잭션 처리량이 개별 데이터베이스의 기능을 초과합니다.
- 규정 준수를 위해 별도의 테넌트가 서로 다른 물리적 데이터베이스에 있어야 합니다(이 요구 사항은 크기 조정에 대한 것이 아니라 분할이 사용된 다른 상황임).
애플리케이션은 관련 데이터를 관련 분할에 추가하므로 개별 데이터베이스의 제약 조건을 넘어서 시스템의 확장성을 높일 수 있습니다.
Azure SQL은 Azure Elastic Database 도구를 제공합니다. 이러한 도구는 애플리케이션 논리에서 Azure의 분할된 SQL 데이터베이스를 만들고, 유지 관리하고, 쿼리하는 데 유용합니다.