Azure에서 중요 업무용 워크로드의 애플리케이션 디자인

애플리케이션을 디자인할 때 기능 및 비기능 애플리케이션 요구 사항은 모두 중요합니다. 이 디자인 영역에서는 애플리케이션을 오류에 대한 복원력을 높일 수 있는 아키텍처 패턴 및 크기 조정 전략에 대해 설명합니다.

중요

이 문서는 Azure Well-Architected Framework 중요 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.

배율 단위 아키텍처

솔루션의 모든 기능적 측면은 수요 변화에 맞게 스케일링할 수 있어야 합니다. 배율 단위 아키텍처를 사용하여 구획화를 통해 엔드 투 엔드 확장성을 최적화하고 용량 추가 및 제거 프로세스를 표준화하는 것이 좋습니다. 배율 단위는 독립적으로 스케일링할 수 있는 논리 단위 또는 함수입니다. 단위는 코드 구성 요소, 애플리케이션 호스팅 플랫폼, 관련 구성 요소를 포함하는 배포 스탬프 및 다중 테넌트 요구 사항을 지원하는 구독으로 구성될 수 있습니다.

개별 리소스 및 전체 애플리케이션의 확장 제한을 해결하므로 이 방법을 사용하는 것이 좋습니다. 배율 단위를 하나의 단위로 배포할 수 있으므로 복잡한 배포 및 업데이트 시나리오에 도움이 됩니다. 또한 사용자 트래픽을 전달하기 전에 단위에서 특정 버전의 구성 요소를 테스트하고 유효성을 검사할 수 있습니다.

중요 업무용 애플리케이션이 온라인 제품 카탈로그라고 가정합니다. 제품 주석 및 등급을 처리하기 위한 사용자 흐름이 있습니다. 흐름은 API를 사용하여 주석 및 등급을 검색 및 게시하고 OAuth 엔드포인트, 데이터 저장소 및 메시지 큐와 같은 구성 요소를 지원합니다. 상태 비정상 API 엔드포인트는 주문형 변경에 맞게 조정해야 하는 세분화된 기능 단위를 나타냅니다. 기본 애플리케이션 플랫폼도 그에 따라 크기를 조정할 수 있어야 합니다. 성능 병목 현상을 방지하려면 다운스트림 구성 요소 및 종속성도 적절한 수준까지 확장해야 합니다. 개별 배율 단위로 또는 단일 논리 단위의 일부로 독립적으로 스케일링할 수 있습니다.

배율 단위 예제

다음 이미지는 배율 단위에 대해 가능한 범위를 보여 줍니다. 범위는 마이크로 서비스 Pod에서 클러스터 노드 및 지역 배포 스탬프에 이르기까지 다양합니다.

디자인 고려 사항

• 범위. 배율 단위의 scope, 배율 단위와 해당 구성 요소 간의 관계는 용량 모델에 따라 정의되어야 합니다. 성능에 대한 비기능적 요구 사항을 고려합니다.

• 크기 조정 제한. Azure 구독 규모 제한 및 할당량은 애플리케이션 디자인, 기술 선택 사항 및 배율 단위 정의에 영향을 미칠 수 있습니다. 배율 단위는 서비스의 배율 제한을 우회하는 데 도움이 될 수 있습니다. 예를 들어 한 단위의 AKS 클러스터에 1,000개의 노드만 있을 수 있는 경우 두 단위를 사용하여 해당 제한을 2,000개 노드로 늘릴 수 있습니다.

• 로드가 필요합니다. 각 사용자 흐름에 대한 요청 수, 예상 최대 요청 속도(초당 요청 수) 및 일별/주별/계절 트래픽 패턴을 사용하여 핵심 규모 요구 사항을 알릴 수 있습니다. 또한 트래픽 및 데이터 볼륨 모두에 대한 예상 증가 패턴을 고려합니다.

• 성능이 저하될 수 있습니다. 응답 시간이 높은 성능 저하된 서비스가 로드 시 허용되는지 여부를 확인합니다. 필요한 용량을 모델링할 때 로드 중인 솔루션의 필수 성능은 중요한 요소입니다.

• 비기능적 요구 사항. 기술 및 비즈니스 시나리오에는 복원력, 가용성, 대기 시간, 용량 및 가시성에 대한 고유한 고려 사항이 있습니다. 주요 엔드 투 엔드 사용자 흐름의 컨텍스트에서 이러한 요구 사항을 분석합니다. 사용자 흐름 수준에서 디자인, 의사 결정 및 기술 선택에 상대적으로 유연성이 있습니다.

디자인 권장 사항

• 배율 단위의 scope 크기를 조정하도록 단위를 트리거하는 제한을 정의합니다.

• 모든 애플리케이션 구성 요소가 독립적으로 또는 다른 관련 구성 요소를 포함하는 배율 단위의 일부로 확장할 수 있는지 확인합니다.

• 용량 모델과 비기능적 요구 사항에 따라 배율 단위 간의 관계를 정의합니다.

• 지역별 배포 스탬프를 정의하여 지역 애플리케이션 리소스의 프로비저닝, 관리 및 작업을 다른 유형이지만 상호 종속적인 배율 단위로 통합합니다. 부하가 증가함에 따라 동일한 Azure 지역 또는 다른 지역 내에 추가 스탬프를 배포하여 솔루션을 수평적으로 확장할 수 있습니다.

• 단일 구독 내의 확장 제한이 확장성을 제한하지 않도록 Azure 구독을 배율 단위로 사용합니다. 이 방법은 트래픽 볼륨이 큰 대규모 애플리케이션 시나리오에 적용됩니다.

• 서비스 저하를 방지하기 위해 사용량이 많은 시간에 충분한 용량이 프로비전되도록 식별된 트래픽 패턴을 중심으로 필요한 용량을 모델링합니다. 또는 사용량이 많은 시간 동안 용량을 최적화합니다.

• 스케일 아웃 및 스케일 인 작업을 수행하는 데 필요한 시간을 측정하여 트래픽의 자연스러운 변화가 허용할 수 없는 수준의 서비스 저하를 일으키지 않도록 합니다. 크기 조정 작업 기간을 운영 메트릭으로 추적합니다.

참고

Azure 랜딩 존에 배포하는 경우 랜딩 존 구독이 명확한 관리 경계를 제공하고 노이즈 네이버 안티패턴을 방지하기 위해 애플리케이션 전용인지 확인합니다.

글로벌 분포

고도로 분산된 환경에서는 오류를 방지할 수 없습니다. 이 섹션에서는 많은 오류 시나리오를 완화하는 전략을 제공합니다. 애플리케이션은 지역 및 영역 오류를 견딜 수 있어야 합니다. 부하가 모든 지역에 분산되도록 활성/활성 모델에 배포해야 합니다.

이 비디오를 시청하여 중요 업무용 애플리케이션의 오류를 계획하고 복원력을 최대화하는 방법에 대한 개요를 알아봅니다.

디자인 고려 사항

• 중복성. 애플리케이션을 여러 지역에 배포해야 합니다. 또한 지역 내에서 가용성 영역을 사용하여 데이터 센터 수준에서 내결함성을 허용하는 것이 좋습니다. 가용성 영역에는 가용성 영역 간의 대기 시간 경계가 2밀리초 미만입니다. 영역 간에 "번잡한" 워크로드의 경우 이 대기 시간은 성능 저하를 초래하고 영역 간 데이터 전송에 대한 대역폭 요금이 발생할 수 있습니다.

• 활성/활성 모델. 가용성을 최대화하고 더 높은 복합 SLA(서비스 수준 계약)를 제공하기 때문에 활성/활성 배포 전략을 사용하는 것이 좋습니다. 그러나 많은 애플리케이션 시나리오에서 데이터 동기화 및 일관성에 대한 문제가 발생할 수 있습니다. 비용 및 엔지니어링 노력 증가의 장만을 고려하면서 데이터 플랫폼 수준에서 문제를 해결합니다.

  여러 클라우드 공급자에 대한 활성/활성 배포는 단일 클라우드 공급자 내의 글로벌 리소스에 대한 종속성을 잠재적으로 완화하는 방법입니다. 그러나 다중 클라우드 활성/활성 배포 전략은 CI/CD에 상당한 복잡성을 도입합니다. 또한 클라우드 공급자 간의 리소스 사양 및 기능의 차이점을 고려할 때 각 클라우드에 대한 특수 배포 스탬프가 필요합니다.

• 지리적 분포. 워크로드에는 지리적 데이터 보존, 데이터 보호 및 데이터 보존에 대한 규정 준수 요구 사항이 있을 수 있습니다. 데이터가 상주해야 하는 특정 지역이 있는지 또는 리소스를 배포해야 하는지 여부를 고려합니다.

• 요청 원본. 사용자 또는 종속 시스템의 지리적 근접성과 밀도는 글로벌 배포에 대한 디자인 결정을 알려야 합니다.

• 연결. 사용자 또는 외부 시스템에서 워크로드에 액세스하는 방식이 디자인에 영향을 미칩니다. VPN 또는 Azure ExpressRoute 회로를 사용하는 공용 인터넷 또는 프라이빗 네트워크를 통해 애플리케이션을 사용할 수 있는지 여부를 고려합니다.

플랫폼 수준의 디자인 권장 사항 및 구성 선택은 애플리케이션 플랫폼: 글로벌 배포를 참조하세요.

느슨하게 결합된 이벤트 기반 아키텍처

결합 은 잘 정의된 인터페이스를 통해 서비스 간 통신을 가능하게 합니다. 느슨한 결합을 사용하면 애플리케이션 구성 요소가 독립적으로 작동할 수 있습니다. 마이크로 서비스 아키텍처 스타일은 중요 업무용 요구 사항과 일치합니다. 연속 오류를 방지하여 고가용성을 용이하게 합니다.

느슨한 결합의 경우 이벤트 기반 디자인을 통합하는 것이 좋습니다. 중간자를 통한 비동기 메시지 처리는 복원력을 구축할 수 있습니다.

일부 시나리오에서 애플리케이션은 비즈니스 목표에 따라 느슨하고 긴밀한 결합을 결합할 수 있습니다.

디자인 고려 사항

• 런타임 종속성. 느슨하게 결합된 서비스는 동일한 컴퓨팅 플랫폼, 프로그래밍 언어, 런타임 또는 운영 체제를 사용하도록 제한해서는 안 됩니다.

• 크기 조정. 서비스는 독립적으로 확장할 수 있어야 합니다. 인프라 및 플랫폼 리소스 사용을 최적화합니다.

• 내결함성. 오류는 별도로 처리해야 하며 클라이언트 트랜잭션에 영향을 주지 않아야 합니다.

• 트랜잭션 무결성. 별도의 서비스에서 발생하는 데이터 생성 및 지속성의 영향을 고려합니다.

• 분산 추적. 엔드 투 엔드 추적에는 복잡한 오케스트레이션이 필요할 수 있습니다.

디자인 권장 사항

• 마이크로 서비스 경계를 중요한 사용자 흐름에 맞춥니다.

• 가능한 경우 이벤트 기반 비동기 통신을 사용하여 지속 가능한 규모와 최적의 성능을 지원합니다.

• 아웃박스 및 트랜잭션 세션과 같은 패턴을 사용하여 모든 메시지가 올바르게 처리되도록 일관성을 보장합니다.

예: 이벤트 기반 접근 방식

중요 업무용 온라인 참조 구현은 마이크로 서비스를 사용하여 단일 비즈니스 트랜잭션을 처리합니다. 메시지 브로커 및 작업자를 사용하여 쓰기 작업을 비동기적으로 적용합니다. 읽기 작업은 동기적이며 결과는 호출자에게 직접 반환됩니다.

애플리케이션 코드의 복원력 패턴 및 오류 처리

중요 업무용 애플리케이션은 가능한 한 많은 오류 시나리오를 처리할 수 있도록 복원력이 있도록 설계되어야 합니다. 이 복원력은 서비스 가용성 및 안정성을 최대화합니다. 애플리케이션에는 백오프 및 회로 차단기와함께 다시 시도와 같은 디자인 패턴을 사용하여 구현할 수 있는 자체 복구 기능이 있어야 합니다.

애플리케이션 논리에서 완전히 완화할 수 없는 일시적이지 않은 오류의 경우 상태 모델 및 운영 래퍼가 수정 작업을 수행해야 합니다. 애플리케이션 코드는 적절한 계측 및 로깅을 통합하여 상태 모델을 알리고 필요에 따라 후속 문제 해결 또는 근본 원인 분석을 용이하게 해야 합니다. 오류가 발생할 때 상관 관계 ID를 포함하는 포괄적인 오류 메시지를 호출자에게 제공하려면 분산 추적 을 구현해야 합니다.

Application Insights와 같은 도구는 애플리케이션 추적을 쿼리, 상관 관계 및 시각화하는 데 도움이 될 수 있습니다.

디자인 고려 사항

• 적절한 구성. 일시적인 문제로 인해 연속 오류가 발생하는 것은 드문 일이 아닙니다. 예를 들어 적절한 백오프 없이 다시 시도하면 서비스가 제한될 때 문제가 악화됩니다. 재시도 지연을 선형적으로 간격을 지정하거나 기하급수적으로 늘려 지연이 증가하는 것을 통해 되돌릴 수 있습니다.

• 상태 엔드포인트. 외부 솔루션이 애플리케이션 구성 요소 상태 상태 검색하기 위해 폴링할 수 있는 상태 엔드포인트를 사용하여 애플리케이션 코드 내에서 기능 검사를 노출할 수 있습니다.

디자인 권장 사항

복원력 있는 애플리케이션에 대한 몇 가지 일반적인 소프트웨어 엔지니어링 패턴 은 다음과 같습니다.

패턴	요약
큐 기반 부하 평준화	일관된 부하 수준을 보장하기 위해 소비자와 요청된 리소스 간에 버퍼를 도입합니다. 소비자 요청이 큐에 대기되면 작업자 프로세스는 작업자가 설정한 속도와 요청을 처리하는 요청된 리소스의 기능에 따라 요청된 리소스에 대해 처리합니다. 소비자가 요청에 대한 회신을 기대하는 경우 별도의 응답 메커니즘을 구현해야 합니다. 우선 순위가 지정된 순서를 적용하여 가장 중요한 작업이 먼저 수행되도록 합니다.
회로 차단기	복구를 기다리거나 사용할 수 없는 원격 서비스 또는 리소스를 기다리는 동안 차단하지 않고 요청을 신속하게 거부하여 안정성을 제공합니다. 또한 이 패턴은 원격 서비스 또는 리소스에 연결할 때 복구하는 데 가변적인 시간이 걸릴 수 있는 오류를 처리합니다.
격벽	서비스 인스턴스를 부하 및 가용성 요구 사항에 따라 그룹으로 분할하여 서비스 기능을 유지하기 위한 오류를 격리하려고 시도합니다.
Saga	서비스가 정의된 이벤트 또는 메시지 채널을 통해 서로 업데이트되도록 하여 독립적인 데이터 저장소가 있는 마이크로 서비스에서 데이터 일관성을 관리합니다. 각 서비스는 로컬 트랜잭션을 수행하여 자체 상태를 업데이트하고 사가에서 다음 로컬 트랜잭션을 트리거하는 이벤트를 게시합니다. 서비스 업데이트가 실패하면 Saga는 이전 서비스 업데이트 단계를 중화하기 위해 보상 트랜잭션을 실행합니다. 개별 서비스 업데이트 단계는 다시 시도와 같은 복원력 패턴을 직접 구현할 수 있습니다.
상태 엔드포인트 모니터링	외부 도구가 정기적으로 노출된 엔드포인트를 통해 액세스할 수 있는 애플리케이션의 기능 검사를 구현합니다. 주요 운영 메트릭을 사용하여 애플리케이션 상태를 알리고 경고 발생 또는 보상 롤백 배포 수행과 같은 운영 응답을 트리거하여 엔드포인트의 응답을 해석할 수 있습니다.
다시 시도	일시적인 오류를 우아하고 투명하게 처리합니다. - 오류가 일시적일 가능성이 낮고 작업을 다시 시도하면 성공할 가능성이 낮으면 취소합니다. - 오류가 비정상적이거나 드물고 즉시 다시 시도하면 작업이 성공할 가능성이 있는 경우 다시 시도합니다. - 네트워크 연결 또는 높은 부하 오류와 같이 복구하는 데 짧은 시간이 필요할 수 있는 조건으로 인해 오류가 발생하는 경우 지연 후 다시 시도합니다. 재시도 지연이 증가함에 따라 적절한 백오프 전략을 적용합니다.
제한	애플리케이션 구성 요소에서 사용하는 리소스의 사용을 제어하여 과도하게 방해받지 않도록 보호합니다. 리소스가 부하 임계값에 도달하면 우선 순위가 낮은 작업을 연기하고 필수적이지 않은 기능을 저하하므로 정상 작업으로 돌아갈 수 있는 충분한 리소스가 있을 때까지 필수 기능을 계속할 수 있습니다.

다음은 몇 가지 추가 권장 사항입니다.

• Azure SDK와 같이 공급업체에서 제공하는 SDK를 사용하여 종속 서비스에 연결합니다. 사용자 지정 기능을 구현하는 대신 기본 제공 복원력 기능을 사용합니다.

• 실패한 종속성 호출을 다시 시도할 때 적절한 백오프 전략을 적용하여 자해된 DDoS 시나리오를 방지합니다.

• 애플리케이션 수준 복원력 패턴을 사용하여 일관성과 속도를 높이기 위해 모든 애플리케이션 마이크로 서비스 팀에 대한 일반적인 엔지니어링 기준을 정의합니다.

• C#용 Polly 또는 Java용 Sentinel 과 같은 검증된 표준화된 패키지를 사용하여 복원력 패턴을 구현합니다.

• 모든 추적 이벤트 및 로그 메시지에 상관 관계 ID를 사용하여 지정된 요청에 연결합니다. 실패한 요청뿐만 아니라 모든 호출에 대해 호출자에게 상관 관계 ID를 반환합니다.

• 모든 로그 메시지에 구조적 로깅을 사용합니다. 애플리케이션 추적, 메트릭 및 로그에 대한 통합 운영 데이터 싱크를 선택하여 운영자가 문제를 쉽게 디버그할 수 있도록 합니다. 자세한 내용은 클라우드 애플리케이션에 대한 모니터링 데이터 수집, 집계 및 저장을 참조하세요.

• 운영 데이터가 비즈니스 요구 사항과 함께 사용하여 애플리케이션 상태 모델을 알리는지 확인합니다.

프로그래밍 언어 선택

올바른 프로그래밍 언어 및 프레임워크를 선택하는 것이 중요합니다. 이러한 결정은 종종 organization 기술 세트 또는 표준화된 기술에 의해 결정됩니다. 그러나 다양한 언어 및 프레임워크의 성능, 복원력 및 전반적인 기능을 평가하는 것이 중요합니다.

디자인 고려 사항

• 개발 키트 기능. 다양한 언어로 Azure 서비스 SDK에서 제공하는 기능에는 차이가 있습니다. 이러한 차이는 Azure 서비스 또는 프로그래밍 언어 선택에 영향을 줄 수 있습니다. 예를 들어 Azure Cosmos DB가 가능한 옵션인 경우 Go는 자사 SDK가 없으므로 적절한 개발 언어가 아닐 수 있습니다.

• 기능 업데이트. 선택한 언어에 대한 새 기능으로 SDK가 업데이트되는 빈도를 고려합니다. .NET 및 Java 라이브러리와 같이 일반적으로 사용되는 SDK는 자주 업데이트됩니다. 다른 언어에 대한 다른 SDK 또는 SDK는 덜 자주 업데이트될 수 있습니다.

• 여러 프로그래밍 언어 또는 프레임워크. 여러 기술을 사용하여 다양한 복합 워크로드를 지원할 수 있습니다. 그러나 관리 복잡성 및 운영 문제를 발생하므로 스프롤을 피해야 합니다.

• 컴퓨팅 옵션. 레거시 또는 독점 소프트웨어는 PaaS 서비스에서 실행되지 않을 수 있습니다. 또한 레거시 또는 독점 소프트웨어를 컨테이너에 포함하지 못할 수도 있습니다.

디자인 권장 사항

• 필요한 기능 및 선택한 프로그래밍 언어에 대한 모든 관련 Azure SDK를 평가합니다. 비기능적 요구 사항과의 맞춤을 확인합니다.

• 마이크로 서비스 수준에서 프로그래밍 언어 및 프레임워크 선택을 최적화합니다. 여러 기술을 적절하게 사용합니다.

• .NET SDK의 우선 순위를 지정하여 안정성 및 성능을 최적화합니다. .NET Azure SDK는 일반적으로 더 많은 기능을 제공하며 자주 업데이트됩니다.

다음 단계

애플리케이션 플랫폼에 대한 고려 사항을 검토합니다.

애플리케이션 플랫폼