하이브리드 앱 디자인 고려 사항
Microsoft Azure는 유일하게 일관된 하이브리드 클라우드입니다. 이를 통해 개발 투자를 다시 사용할 수 있으며, 데이터 센터에서 Azure의 확장인 글로벌 Azure, 소버린 Azure 클라우드 및 Azure Stack에 걸쳐 있을 수 있는 앱을 사용할 수 있습니다. 클라우드를 아우르는 앱을
Azure 애플리케이션 아키텍처 가이드 확장 가능하고 복원력이 뛰어나며 고가용성 앱을 디자인하기 위한 구조적 접근 방식을 설명합니다. Azure 애플리케이션 아키텍처 가이드에 설명된 고려 사항은 단일 클라우드용으로 설계된 앱과 클라우드에 걸쳐 있는 앱에 동일하게 적용될 있습니다.
이 문서에서는 하이브리드 앱 디자인에 중점을 두는
하이브리드 시나리오는 개발에 사용할 수 있는 리소스와 지리, 보안, 인터넷 액세스 및 기타 고려 사항과 같은 고려 사항에 따라 크게 다릅니다. 이 가이드는 특정 고려 사항을 열거할 수는 없지만 몇 가지 주요 지침과 모범 사례를 제공할 수 있습니다. 하이브리드 앱 아키텍처를 성공적으로 디자인, 구성, 배포 및 유지 관리하는 데는 기본적으로 알려지지 않은 많은 디자인 고려 사항이 포함됩니다.
이 문서에서는 하이브리드 앱을 구현할 때 발생할 수 있는 가능한 질문을 집계하고 고려 사항(이러한 핵심 요소) 및 모범 사례를 제공합니다. 디자인 단계에서 이러한 질문을 해결하면 프로덕션에서 발생할 수 있는 문제를 방지할 수 있습니다.
기본적으로 하이브리드 앱을 만들기 전에 고려해야 할 질문입니다. 시작하려면 다음 작업을 수행해야 합니다.
- 앱 구성 요소를 식별하고 평가합니다.
- 핵심 요소에 대해 앱 구성 요소를 평가합니다.
앱 구성 요소 평가
앱의 각 구성 요소는 더 큰 앱 내에서 고유한 특정 역할을 가지며 모든 디자인 고려 사항을 검토해야 합니다. 각 구성 요소의 요구 사항 및 기능은 앱 아키텍처를 결정하는 데 도움이 되도록 이러한 고려 사항에 매핑되어야 합니다.
앱의 아키텍처를 연구하고 구성 요소를 결정하여 앱을 구성 요소로 분해합니다. 구성 요소에는 앱이 상호 작용하는 다른 앱도 포함될 수 있습니다. 구성 요소를 식별할 때 다음 질문을 하여 해당 특성에 따라 의도한 하이브리드 작업을 평가합니다.
- 구성 요소의 용도는 무엇인가요?
- 구성 요소 간의 상호 종속성은 무엇인가요?
예를 들어 앱은 프런트 엔드와 백 엔드를 두 구성 요소로 정의할 수 있습니다. 하이브리드 시나리오에서 프런트 엔드는 하나의 클라우드에 있고 백 엔드는 다른 클라우드에 있습니다. 앱은 프런트 엔드와 사용자 간의 통신 채널과 프런트 엔드와 백 엔드 간의 통신 채널을 제공합니다.
앱 구성 요소는 여러 양식 및 시나리오에 의해 정의됩니다. 가장 중요한 작업은 해당 위치와 해당 클라우드 또는 온-프레미스 위치를 식별하는 것입니다.
인벤토리에 포함할 일반적인 앱 구성 요소는 표 1에 나열됩니다.
표 1. 일반적인 앱 구성 요소
| 구성 요소 | 하이브리드 앱 지침 |
|---|---|
| 클라이언트 연결 | 앱(모든 디바이스)은 다음 방법을 포함하여 단일 진입점에서 다양한 방법으로 사용자에 액세스할 수 있습니다. - 사용자가 앱을 사용하기 위해 클라이언트를 설치해야 하는 클라이언트-서버 모델입니다. 브라우저에서 액세스하는 서버 기반 앱입니다. - 클라이언트 연결에는 연결이 끊어진 경우 알림 또는 로밍 요금이 적용될 수 있는 경우 경고가 포함될 수 있습니다. |
| 인증 | 앱에 연결하는 사용자 또는 다른 구성 요소에 연결하는 한 구성 요소에서 인증이 필요할 수 있습니다. |
| API | API 집합 및 클래스 라이브러리를 사용하여 앱에 대한 프로그래밍 방식 액세스를 개발자에게 제공하고 인터넷 표준에 따라 연결 인터페이스를 제공할 수 있습니다. API를 사용하여 앱을 독립적으로 작동하는 논리 단위로 분해할 수도 있습니다. |
| 서비스 | 간결한 서비스를 사용하여 앱에 대한 기능을 제공할 수 있습니다. 서비스는 앱이 실행되는 엔진일 수 있습니다. |
| 큐 | 큐를 사용하여 앱 구성 요소의 수명 주기 및 상태 상태를 구성할 수 있습니다. 이러한 큐는 구독 당사자에게 메시징, 알림 및 버퍼링 기능을 제공할 수 있습니다. |
| 데이터 스토리지 | 앱은 상태 비 상태 또는 상태 저장일 수 있습니다. 상태 저장 앱에는 다양한 형식 및 볼륨에서 충족할 수 있는 데이터 스토리지가 필요합니다. |
| 데이터 캐싱 | 디자인의 데이터 캐싱 구성 요소는 대기 시간 문제를 전략적으로 해결하고 클라우드 버스팅을 트리거하는 역할을 할 수 있습니다. |
| 데이터 수집 | 웹 양식에서 사용자가 제출한 값부터 지속적으로 대용량 데이터 흐름에 이르기까지 다양한 방법으로 데이터를 앱에 제출할 수 있습니다. |
| 데이터 처리 | 데이터 처리 작업(예: 보고서, 분석, 일괄 처리 내보내기 및 데이터 변환)은 원본에서 처리하거나 데이터 복사본을 사용하여 별도의 구성 요소에서 오프로드할 수 있습니다. |
핵심 요소에 대한 앱 구성 요소 평가
각 구성 요소에 대해 각 핵심 요소에 대한 특성을 평가합니다. 모든 핵심 요소를 사용하여 각 구성 요소를 평가할 때 고려하지 않았을 수 있는 질문은 하이브리드 앱의 디자인에 영향을 주는 것으로 알려질 수 있습니다. 이러한 고려 사항에 따라 작업하면 앱 최적화에 가치를 더할 수 있습니다. 표 2에서는 하이브리드 앱과 관련된 각 핵심 요소에 대한 설명을 제공합니다.
표 2. 기둥
| 기둥 | 설명 |
|---|---|
| 배치 | 하이브리드 앱에서 구성 요소의 전략적 위치 지정 |
| 확장성 | 증가된 부하를 처리하는 시스템의 기능입니다. |
| 가용도 | 하이브리드 앱이 작동하고 작동하는 시간의 비율입니다. |
| 복구 | 하이브리드 앱이 복구할 수 있는 기능입니다. |
| 관리 | 프로덕션 환경에서 시스템을 계속 실행하는 운영 프로세스입니다. |
| 안전 | 위협으로부터 하이브리드 앱 및 데이터 보호 |
배치
하이브리드 앱에는 기본적으로 데이터 센터와 같은 배치 고려 사항이 있습니다.
배치는 하이브리드 앱을 가장 잘 서비스할 수 있도록 구성 요소를 배치하는 중요한 작업입니다. 정의에 따라 하이브리드 앱은 온-프레미스에서 클라우드로, 그리고 다양한 클라우드와 같은 위치에 걸쳐 있습니다. 다음과 같은 두 가지 방법으로 클라우드에 앱의 구성 요소를 배치할 수 있습니다.
수직 하이브리드 앱
앱 구성 요소는 여러 위치에 분산됩니다. 각 개별 구성 요소는 단일 위치에만 여러 인스턴스를 배치할 수 있습니다.가로 하이브리드 앱
앱 구성 요소는 여러 위치에 분산됩니다. 각 개별 구성 요소에는 여러 위치에 걸쳐 있는 여러 인스턴스가 있을 수 있습니다.일부 구성 요소는 위치를 인식할 수 있지만 다른 구성 요소는 위치 및 배치에 대한 지식이 없습니다. 이러한 선순환은 추상화 계층을 사용하여 달성할 수 있습니다. 마이크로 서비스와 같은 최신 앱 프레임워크를 사용하는 이 계층은 클라우드의 노드에서 작동하는 앱 구성 요소를 배치하여 앱을 서비스하는 방법을 정의할 수 있습니다.
배치 검사 목록
필요한 위치를 확인합니다. 앱 또는 해당 구성 요소가 특정 클라우드에서 작동하거나 인증을 요구하는 데 필요한지 확인합니다. 여기에는 회사의 주권 요구 사항 또는 법률에 의해 규정된 주권 요구 사항이 포함될 수 있습니다. 또한 특정 위치 또는 로캘에 온-프레미스 작업이 필요한지 확인합니다.
연결 종속성을 확인합니다. 필요한 위치 및 기타 요인은 구성 요소 간의 연결 종속성을 결정할 수 있습니다. 구성 요소를 배치할 때 통신을 위한 최적의 연결 및 보안을 결정합니다. 선택 항목에는 VPN,ExpressRoute, 및 하이브리드 연결포함됩니다.
플랫폼 기능을 평가합니다. 각 앱 구성 요소에 대해 앱 구성 요소에 필요한 리소스 공급자를 클라우드에서 사용할 수 있는지와 대역폭이 예상 처리량 및 대기 시간 요구 사항을 수용할 수 있는지 확인합니다.
이식성을 계획합니다. 컨테이너 또는 마이크로 서비스와 같은 최신 앱 프레임워크를 사용하여 작업 이동을 계획하고 서비스 종속성을 방지합니다.
데이터 주권 요구 사항을 결정합니다. 하이브리드 앱은 로컬 데이터 센터와 같은 데이터 격리를 수용하기 위한 것입니다. 리소스 배치를 검토하여 이 요구 사항을 수용하는 데 성공하도록 최적화합니다.
대기 시간을 계획합니다. 클라우드 간 작업은 앱 구성 요소 간의 물리적 거리를 도입할 수 있습니다. 대기 시간을 수용하기 위한 요구 사항을 확인합니다.
트래픽 흐름을 제어합니다. 퍼블릭 클라우드의 프런트 엔드에서 액세스할 때 개인 식별 정보 데이터에 대한 최대 사용량 및 적절한 보안 통신을 처리합니다.
확장성
확장성은 앱의 크기 및 범위 외에도 다른 요인과 힘이 대상 그룹 크기에 영향을 주므로 시간이 지남에 따라 달라질 수 있는 앱의 증가된 부하를 처리하는 시스템의 기능입니다.
이 핵심 요소에 대한 핵심 논의는 아키텍처 우수성의 5가지 핵심 요소에서 확장성 참조하세요.
하이브리드 앱에 대한 수평적 크기 조정 접근 방식을 사용하면 수요를 충족하기 위해 더 많은 인스턴스를 추가한 다음 조용한 기간 동안 사용하지 않도록 설정합니다.
하이브리드 시나리오에서 개별 구성 요소를 확장하려면 구성 요소가 클라우드에 분산되는 경우 추가 고려 사항이 필요합니다. 앱의 한 부분을 크기 조정하려면 다른 부분의 크기 조정이 필요할 수 있습니다. 예를 들어 클라이언트 연결 수가 증가하지만 앱의 웹 서비스가 적절하게 확장되지 않으면 데이터베이스의 부하가 앱을 포화시킬 수 있습니다.
일부 앱 구성 요소는 선형적으로 스케일 아웃할 수 있는 반면, 다른 앱 구성 요소는 크기 조정 종속성을 가지며 크기를 조정할 수 있는 범위로 제한될 수 있습니다. 예를 들어 앱 구성 요소 위치에 대한 하이브리드 연결을 제공하는 VPN 터널은 확장할 수 있는 대역폭 및 대기 시간에 제한이 있습니다. 이러한 요구 사항을 충족하도록 앱 구성 요소의 크기를 조정하려면 어떻게 해야 합니까?
확장성 검사 목록
크기 조정 임계값을 확인합니다. 앱의 다양한 종속성을 처리하려면 앱을 실행하기 위한 요구 사항을 충족하면서 서로 다른 클라우드의 앱 구성 요소가 서로 독립적으로 확장할 수 있는 범위를 결정합니다. 하이브리드 앱은 앱의 나머지 부분과 상호 작용하고 영향을 줄 때 기능을 처리하기 위해 앱의 특정 영역을 확장해야 하는 경우가 많습니다. 예를 들어 여러 프런트 엔드 인스턴스를 초과하려면 백 엔드의 크기를 조정해야 할 수 있습니다.
크기 조정 일정을 정의합니다. 대부분의 앱에는 사용량이 많은 기간이 있으므로 최적의 크기 조정을 조정하려면 피크 시간을 일정으로 집계해야 합니다.
중앙 집중식 모니터링 시스템을 사용합니다. 플랫폼 모니터링 기능은 자동 크기 조정을 제공할 수 있지만 하이브리드 앱에는 시스템 상태 및 부하를 집계하는 중앙 집중식 모니터링 시스템이 필요합니다. 중앙 집중식 모니터링 시스템은 한 위치에서 리소스 크기를 조정하고 다른 위치의 리소스에 따라 크기 조정을 시작할 수 있습니다. 또한 중앙 모니터링 시스템은 자동 크기 조정 리소스와 그렇지 않은 클라우드를 추적할 수 있습니다.
자동 크기 조정 기능을 활용합니다(사용 가능한 경우). 자동 크기 조정 기능이 아키텍처의 일부인 경우 앱 구성 요소를 강화, 확장, 축소 또는 축소해야 하는 시기를 정의하는 임계값을 설정하여 자동 크기 조정을 구현합니다. 자동 크기 조정의 예로는 증가된 용량을 처리하기 위해 한 클라우드에서 자동 크기 조정되지만 다른 클라우드에 분산된 앱의 다른 종속성도 크기 조정되는 클라이언트 연결이 있습니다. 이러한 종속 구성 요소의 자동 크기 조정 기능을 확인해야 합니다.
자동 크기 조정을 사용할 수 없는 경우 중앙 집중식 모니터링 시스템의 임계값에 의해 트리거되는 수동 크기 조정을 수용하도록 스크립트 및 기타 리소스를 구현하는 것이 좋습니다.
위치별로 예상 부하를 결정합니다. 클라이언트 요청을 처리하는 하이브리드 앱은 주로 단일 위치에 의존할 수 있습니다. 클라이언트 요청의 로드가 임계값을 초과하면 다른 위치에 추가 리소스를 추가하여 인바운드 요청의 부하를 분산할 수 있습니다. 클라이언트 연결이 증가된 부하를 처리할 수 있는지 확인하고 클라이언트 연결에서 부하를 처리하기 위한 자동화된 프로시저도 결정합니다.
가용도
가용성은 시스템이 작동하고 작동하는 시간입니다. 가용성은 가동 시간의 백분율로 측정됩니다. 앱 오류, 인프라 문제 및 시스템 로드는 모두 가용성을 줄일 수 있습니다.
이 핵심 요소에 대한 핵심 논의는 아키텍처 우수성의 5가지 핵심 요소에서 가용성 참조하세요.
가용성 검사 목록
연결에 대한 중복성을 제공합니다. 하이브리드 앱은 앱이 분산된 클라우드 간에 연결이 필요합니다. 하이브리드 연결에 대한 기술을 선택할 수 있으므로 기본 기술 선택 외에도 다른 기술을 사용하여 기본 기술이 실패할 경우 자동화된 장애 조치(failover) 기능과 중복성을 제공합니다.
장애 도메인을 분류합니다. 내결함성 앱에는 여러 장애 도메인이 필요합니다. 장애 도메인은 단일 하드 디스크가 온-프레미스에서 실패하거나, 최상위 랙 스위치가 중단되거나, 전체 데이터 센터를 사용할 수 없는 경우와 같이 오류 지점을 격리하는 데 도움이 됩니다. 하이브리드 앱에서 위치는 장애 도메인으로 분류될 수 있습니다. 가용성 요구 사항이 많을수록 단일 장애 도메인을 분류하는 방법을 더 많이 평가해야 합니다.
업그레이드 도메인을 분류합니다. 업그레이드 도메인은 앱 구성 요소의 인스턴스를 사용할 수 있도록 하는 데 사용되며, 동일한 구성 요소의 다른 인스턴스는 업데이트 또는 기능 업그레이드로 서비스됩니다. 장애 도메인과 마찬가지로 업그레이드 도메인은 위치 간 배치에 따라 분류할 수 있습니다. 앱 구성 요소가 다른 위치에서 업그레이드되기 전에 한 위치에서 업그레이드를 수용할 수 있는지 또는 다른 도메인 구성이 필요한지 확인해야 합니다. 단일 위치 자체에는 여러 업그레이드 도메인이 있을 수 있습니다.
인스턴스 및 가용성을 추적합니다. 부하 분산 및 동기 데이터 복제를 통해 고가용성 앱 구성 요소를 사용할 수 있습니다. 서비스가 중단되기 전에 오프라인으로 전환할 수 있는 인스턴스 수를 결정해야 합니다.
자체 복구를 구현합니다. 문제가 앱 가용성을 중단하는 경우 모니터링 시스템의 검색은 실패한 인스턴스를 드레이닝하고 다시 배포하는 등 앱에 대한 자체 복구 작업을 시작할 수 있습니다. 하이브리드 CI/CD(지속적인 통합) 파이프라인과 통합된 중앙 모니터링 솔루션이 필요할 가능성이 높습니다. 앱은 모니터링 시스템과 통합되어 앱 구성 요소를 다시 배포해야 할 수 있는 문제를 식별합니다. 또한 모니터링 시스템은 하이브리드 CI/CD를 트리거하여 앱 구성 요소 및 잠재적으로 동일한 위치 또는 다른 위치에 있는 다른 종속 구성 요소를 다시 배포할 수 있습니다.
SLA(서비스 수준 계약)를 유지 관리합니다. 가용성은 고객과의 서비스 및 앱에 대한 연결을 유지하기 위한 모든 계약에 매우 중요합니다. 하이브리드 앱이 사용하는 각 위치에는 자체 SLA가 있을 수 있습니다. 이러한 다양한 SLA는 하이브리드 앱의 전체 SLA에 영향을 줄 수 있습니다.
복구
복원력은 하이브리드 앱 및 시스템이 오류로부터 복구하고 계속 작동할 수 있는 기능입니다. 복원력의 목표는 오류가 발생한 후 앱을 완전히 작동하는 상태로 되돌리는 것입니다. 복원력 전략에는 백업, 복제 및 재해 복구와 같은 솔루션이 포함됩니다.
이 핵심 요소에 대한 핵심 논의는 아키텍처 우수성의 5가지 핵심 요소에서 복원력 참조하세요.
복원력 검사 목록
재해 복구 종속성을 파악합니다. 한 클라우드에서 재해 복구를 수행하려면 다른 클라우드의 앱 구성 요소를 변경해야 할 수 있습니다. 한 클라우드의 하나 또는 여러 구성 요소가 동일한 클라우드 또는 다른 클라우드 내의 다른 위치로 장애 조치(failover)되는 경우 종속 구성 요소는 이러한 변경 내용을 인식해야 합니다. 여기에는 연결 종속성도 포함됩니다. 복원력에는 각 클라우드에 대해 완전히 테스트된 앱 복구 계획이 필요합니다.
복구 흐름을 설정합니다. 효과적인 복구 흐름 디자인은 버퍼를 수용하고, 다시 시도하며, 실패한 데이터 전송을 다시 시도하고, 필요한 경우 다른 서비스 또는 워크플로로 대체되는 기능에 대해 앱 구성 요소를 평가했습니다. 사용할 백업 메커니즘, 해당 복원 프로시저에 포함되는 항목 및 테스트 빈도를 결정해야 합니다. 또한 증분 및 전체 백업의 빈도를 결정해야 합니다.
부분 복구를 테스트합니다. 앱의 일부에 대한 부분 복구는 모든 것을 사용할 수 없다는 확신을 사용자에게 제공할 수 있습니다. 계획의 이 부분은 부분 복원에 백업이 수행되기 전에 정상적으로 종료하기 위해 앱과 상호 작용하는 백업 및 복원 서비스와 같은 부작용이 없도록 해야 합니다.
재해 복구 선동자를 결정하고 책임을 할당합니다. 복구 계획은 백업 및 복원할 수 있는 역할 외에도 백업 및 복구 작업을 시작할 수 있는 사용자와 역할을 설명해야 합니다.
자체 복구 임계값을 재해 복구와 비교합니다. 자동 복구 시작에 대한 앱의 자동 복구 기능과 앱의 자체 복구를 실패 또는 성공으로 간주하는 데 필요한 시간을 결정합니다. 각 클라우드에 대한 임계값을 결정합니다.
복원력 기능의 가용성을 확인합니다. 각 위치에 대한 복원력 기능 및 기능의 가용성을 결정합니다. 위치가 필요한 기능을 제공하지 않는 경우 복원력 기능을 제공하는 중앙 집중식 서비스에 해당 위치를 통합하는 것이 좋습니다.
가동 중지 시간을 확인합니다. 앱 전체 및 앱 구성 요소에 대한 유지 관리로 인해 예상되는 가동 중지 시간을 결정합니다.
문서 문제 해결 절차. 리소스 및 앱 구성 요소를 다시 배포하기 위한 문제 해결 절차를 정의합니다.
관리
하이브리드 앱을 관리하는 방법에 대한 고려 사항은 아키텍처를 디자인하는 데 중요합니다. 잘 관리되는 하이브리드 앱은 공통 개발 파이프라인에서 일관된 앱 코드를 통합할 수 있도록 하는 코드로 인프라를 제공합니다. 인프라에 대한 일관된 시스템 차원의 개별 테스트를 구현하여 변경 내용이 테스트를 통과하면 통합 배포를 보장하여 소스 코드에 병합할 수 있습니다.
이 핵심 요소에 대한 핵심 논의는 아키텍처 우수성의 5가지 핵심 요소에서 DevOps 참조하세요.
관리 효율성 검사 목록
모니터링을 구현합니다. 클라우드에 분산된 앱 구성 요소의 중앙 집중식 모니터링 시스템을 사용하여 상태 및 성능에 대한 집계 보기를 제공합니다. 이 시스템에는 앱 구성 요소와 관련 플랫폼 기능 모두 모니터링이 포함됩니다.
모니터링이 필요한 앱 부분을 결정합니다.
정책을 조정합니다. 하이브리드 앱이 포괄하는 각 위치에는 허용된 리소스 종류, 명명 규칙, 태그 및 기타 조건을 포함하는 자체 정책이 있을 수 있습니다.
역할을 정의하고 사용합니다. 데이터베이스 관리자는 앱 리소스에 액세스해야 하는 다른 가상 사용자(예: 앱 소유자, 데이터베이스 관리자 및 최종 사용자)에 필요한 권한을 결정해야 합니다. 이러한 권한은 리소스 및 앱 내에서 구성해야 합니다. RBAC(역할 기반 액세스 제어) 시스템을 사용하면 앱 리소스에 대해 이러한 권한을 설정할 수 있습니다. 이러한 액세스 권한은 모든 리소스가 단일 클라우드에 배포되지만 리소스가 클라우드에 분산될 때 더 많은 주의가 필요한 경우에 어렵습니다. 한 클라우드에서 설정된 리소스에 대한 사용 권한은 다른 클라우드에 설정된 리소스에는 적용되지 않습니다.
CI/CD 파이프라인을 사용합니다. CI/CD(지속적인 통합 및 지속적인 개발) 파이프라인은 클라우드에 걸쳐 있는 앱을 작성 및 배포하고 인프라 및 앱에 대한 품질 보증을 제공하기 위한 일관된 프로세스를 제공할 수 있습니다. 이 파이프라인을 사용하면 인프라와 앱을 한 클라우드에서 테스트하고 다른 클라우드에 배포할 수 있습니다. 파이프라인을 사용하면 하이브리드 앱의 특정 구성 요소를 한 클라우드에 배포하고 다른 구성 요소를 다른 클라우드에 배포할 수 있으므로 기본적으로 하이브리드 앱 배포의 토대가 됩니다. CI/CD 시스템은 데이터베이스에 대한 연결 문자열이 필요한 웹앱과 같이 설치 중에 앱 구성 요소가 서로에 대해 갖는 종속성을 처리하는 데 중요합니다.
수명 주기를 관리합니다. 하이브리드 앱의 리소스는 위치에 걸쳐 있을 수 있으므로 각 단일 위치의 수명 주기 관리 기능을 단일 수명 주기 관리 단위로 집계해야 합니다. 생성, 업데이트 및 삭제 방법을 고려합니다.
문제 해결 전략을 검토합니다. 하이브리드 앱 문제 해결에는 단일 클라우드에서 실행되는 동일한 앱보다 더 많은 앱 구성 요소가 포함됩니다. 클라우드 간의 연결 외에도 앱은 하나의 플랫폼이 아닌 두 플랫폼에서 실행됩니다. 하이브리드 앱 문제 해결의 중요한 작업은 앱 구성 요소의 집계된 상태 및 성능 모니터링을 검사하는 것입니다.
안전
보안은 모든 클라우드 앱에 대한 주요 고려 사항 중 하나이며 하이브리드 클라우드 앱의 경우 더욱 중요해집니다.
이 핵심 요소에 대한 핵심 논의는 아키텍처 우수성의 5가지 핵심 요소에서 보안 참조하세요.
보안 검사 목록
위반을 가정합니다. 앱의 한 부분이 손상된 경우 동일한 위치 내에서뿐만 아니라 여러 위치에서 위반의 확산을 최소화하기 위한 솔루션이 있는지 확인합니다.
허용된 네트워크 액세스를 모니터링합니다. 특정 서브넷에서 앱에만 액세스하고 앱이 제대로 작동하는 데 필요한 구성 요소 간의 최소 포트 및 프로토콜만 허용하는 등 앱에 대한 네트워크 액세스 정책을 결정합니다.
강력한 인증을 사용합니다. 강력한 인증 체계는 앱의 보안에 매우 중요합니다. Single Sign-On 기능을 제공하고 사용자 이름 및 암호 로그온, 퍼블릭 및 프라이빗 키, 2단계 또는 다단계 인증 및 신뢰할 수 있는 보안 그룹 중 하나 이상을 사용하는 페더레이션 ID 공급자를 사용하는 것이 좋습니다. 인증서 유형 및 요구 사항 외에도 앱 인증을 위해 중요한 데이터 및 기타 비밀을 저장할 적절한 리소스를 결정합니다.
암호화를 사용합니다. 데이터 스토리지 또는 클라이언트 통신 및 액세스와 같이 암호화를 사용하는 앱 영역을 식별합니다.
보안 채널을 사용합니다. 클라우드 전체의 보안 채널은 클라우드 전체에서 보안 및 인증 검사, 실시간 보호, 격리 및 기타 서비스를 제공하는 데 중요합니다.
역할을 정의하고 사용합니다. 클라우드에서 리소스 구성 및 단일 ID 액세스에 대한 역할을 구현합니다. 앱 및 해당 플랫폼 리소스에 대한 RBAC(역할 기반 액세스 제어) 요구 사항을 결정합니다.
시스템을 감사합니다. 시스템 모니터링은 앱 구성 요소와 관련 클라우드 플랫폼 작업 모두에서 데이터를 기록하고 집계할 수 있습니다.
요약
이 문서에서는 하이브리드 앱을 작성하고 디자인하는 동안 고려해야 할 항목의 검사 목록을 제공합니다. 앱을 배포하기 전에 이러한 핵심 요소를 검토하면 프로덕션 중단 시 이러한 질문이 실행되지 않고 디자인을 다시 검토해야 할 수 있습니다.
시간이 많이 걸리는 작업처럼 보일 수 있지만 이러한 핵심 요소를 기반으로 앱을 디자인하면 투자 수익률을 쉽게 얻을 수 있습니다.
다음 단계
자세한 내용은 다음 리소스를 참조하세요.
- 하이브리드 클라우드
- 하이브리드 클라우드 앱
- 클라우드 일관성을 위한 Azure Resource Manager 템플릿 개발