애플리케이션을 확장성 있게 만들기
- 8분
이제 성장 준비의 기본 사항을 이해하고, 용량 계획에서 고려해야 할 요소들을 잘 알고 있으니, 애플리케이션을 최대한 확장성 있게 만드는 도전 과제를 맡을 수 있습니다.
건축 설계 검토
기억해야 할 핵심은 시스템에 대한 정기적인 아키텍처 검토를 수행해야 한다는 것입니다.
인프라와 같은 사례를 코드로 적용하여 클라우드 리소스를 배포하는 방법을 개선할 수 있습니다. 애플리케이션 코드를 정기적으로 업데이트하고 개선하면 기본 플랫폼 리소스에서 동일한 작업을 수행해야 합니다.
아키텍처 검토를 수행하면 개선이 필요한 영역을 식별하는 데 도움이 됩니다.
Azure 아키텍처 센터에는 클라우드에서 애플리케이션을 설계하는 데 도움이 되는 다양한 리소스가 있으며, 다음 링크의 애플리케이션 아키텍처 가이드에서 찾을 수 있는 다양한 확장성 권장 사항이 있습니다.
Azure 아키텍처 센터
시나리오: Tailwind Traders 아키텍처
첫 번째 단계는 아키텍처 및 애플리케이션의 평가를 수행하여 약점이 있는 위치를 결정할 뿐만 아니라 강점을 인식하는 것입니다. 그것에 대해 좋은 무엇입니까?
이전 단원에서 본 시나리오를 다시 살펴보세요. 다음은 조직의 아키텍처에 대한 다이어그램입니다.
애플리케이션을 더 작은 마이크로 서비스로 분해했으며, 이러한 서비스 중 일부는 Azure Kubernetes Service의 컨테이너로 사용되거나 VM 또는 App Service에서 실행될 수 있습니다. Functions 및 Logic Apps와 같은 일부 본질적으로 확장 가능한 서비스를 사용하고 있습니다.
이 변경은 좋지만 애플리케이션의 확장성을 높일 수 있는 몇 가지 개선 사항이 있습니다. 예를 들어 이제 Products 서비스에 집중합니다. 다이어그램에서 제품 서비스는 Kubernetes에서 실행되고 있지만 이 설명은 Azure의 VM에서 실행되고 있다고 가정합니다. 약간 다른 구현을 사용하는 크기 조정 개념은 서버, App Service 또는 컨테이너에서 실행 중이든 애플리케이션에 적용할 수 있습니다.
이 제품은 현재 단일 Azure SQL 데이터베이스에 연결된 단일 VM에서 실행됩니다. 확장하려면 이 VM을 사용하도록 설정해야 합니다. 동일한 부하 분산 VM 그룹을 만들고 관리할 수 있는 Azure 가상 머신 확장 집합을 사용하여 이 작업을 수행할 수 있습니다. 이제 둘 이상의 VM이 있으므로 VM 간에 트래픽을 분산하는 부하 분산 장치를 도입해야 합니다.
가상 머신 스케일 세트
단일 VM에 가상 머신 확장 집합을 적용하면 다음과 같은 몇 가지 이점이 있습니다.
- 호스트 메트릭, 게스트 내 메트릭, 애플리케이션 인사이트 또는 일정에 따라 자동 크기 조정을 수행할 수 있습니다.
- Azure 지역 내에서 독립 실행형 데이터 센터인 AZ(가용성 영역)를 사용할 수 있습니다. AZ 지원을 통해 여러 AZ에 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 Database를 사용합니다.
관계형 데이터베이스는 비관계형 데이터베이스보다 스케일 아웃하기가 더 어렵습니다. 데이터베이스 크기를 조정하기 위해 가장 먼저 수행할 수 있는 작업은 데이터베이스 크기를 확장하는 것입니다. 이 크기 조정은 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 데이터베이스를 만들고, 유지 관리하고, 쿼리할 수 있습니다.