Share via

Azure의 중요 업무용 워크로드에 대한 애플리케이션 플랫폼 고려 사항

  • 아티클

Azure는 고가용성 애플리케이션을 호스팅하기 위한 많은 컴퓨팅 서비스를 제공합니다. 서비스는 기능과 복잡성이 다릅니다. 다음을 기반으로 서비스를 선택하는 것이 좋습니다.

  • 안정성, 가용성, 성능 및 보안에 대한 비기능적 요구 사항
  • 확장성, 비용, 조작성 및 복잡성과 같은 의사 결정 요소

애플리케이션 호스팅 플랫폼의 선택은 다른 모든 디자인 영역에 영향을 주는 중요한 결정입니다. 예를 들어 레거시 또는 독점 개발 소프트웨어는 PaaS 서비스 또는 컨테이너화된 애플리케이션에서 실행되지 않을 수 있습니다. 이 제한은 컴퓨팅 플랫폼 선택에 영향을 미칩니다.

중요 업무용 애플리케이션은 둘 이상의 컴퓨팅 서비스를 사용하여 각각 고유한 요구 사항이 있는 여러 복합 워크로드 및 마이크로 서비스를 지원할 수 있습니다.

이 디자인 영역에서는 컴퓨팅 선택, 디자인 및 구성 옵션과 관련된 권장 사항을 제공합니다. 또한 컴퓨팅 의사 결정 트리를 숙지하는 것이 좋습니다.

중요

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

플랫폼 리소스의 글로벌 배포

중요 업무용 워크로드의 일반적인 패턴에는 전역 리소스 및 지역 리소스가 포함됩니다.

특정 Azure 지역에 제한되지 않는 Azure 서비스는 전역 리소스로 배포되거나 구성됩니다. 일부 사용 사례에는 여러 지역에 트래픽 분산, 전체 애플리케이션에 대한 영구 상태 저장 및 전역 정적 데이터 캐싱이 포함됩니다. 배율 단위 아키텍처와 전역 배포를 모두 수용해야 하는 경우 리소스를 Azure 지역에 최적으로 배포하거나 복제하는 방법을 고려합니다.

다른 리소스는 지역적으로 배포됩니다. 배포 스탬프의 일부로 배포되는 이러한 리소스는 일반적으로 배율 단위에 해당합니다. 그러나 한 지역에는 두 개 이상의 스탬프가 있을 수 있으며 스탬프에는 둘 이상의 단위가 있을 수 있습니다. 지역 리소스의 안정성은 기본 워크로드를 실행해야 하므로 매우 중요합니다.

다음 이미지는 고급 디자인을 보여줍니다. 사용자는 중앙 전역 진입점을 통해 애플리케이션에 액세스한 다음, 요청을 적절한 지역 배포 스탬프로 리디렉션합니다.

중요 업무용 아키텍처를 보여 주는 다이어그램

중요 업무용 디자인 방법론에는 다중 지역 배포가 필요합니다. 이 모델은 지역 내결함성을 보장하므로 전체 지역이 다운된 경우에도 애플리케이션을 계속 사용할 수 있습니다. 다중 지역 애플리케이션을 디자인할 때는 각 접근 방식에 상당한 장차가 있기 때문에 애플리케이션 요구 사항과 함께 활성/활성 및 활성/수동과 같은 다양한 배포 전략을 고려합니다. 중요 업무용 워크로드의 경우 활성/활성 모델을 사용하는 것이 좋습니다.

모든 워크로드가 여러 지역을 동시에 실행하도록 지원하거나 필요로 하는 것은 아닙니다. 최적의 디자인 결정을 결정하려면 특정 애플리케이션 요구 사항을 절판과 비교할 수 있어야 합니다. 안정성 목표가 낮은 특정 애플리케이션 시나리오의 경우 활성/수동 또는 분할이 적합한 대안이 될 수 있습니다.

가용성 영역은 지역 내의 여러 데이터 센터에서 고가용성 지역 배포를 제공할 수 있습니다. 거의 모든 Azure 서비스는 서비스가 특정 영역에 위임되는 영역 구성 또는 영역 중복 구성에서 사용할 수 있습니다. 여기서 플랫폼은 서비스가 영역 전체에 걸쳐 있고 영역 중단을 견딜 수 있도록 자동으로 보장합니다. 이러한 구성은 데이터 센터 수준까지 내결함성을 제공합니다.

디자인 고려 사항

  • 지역 및 영역 기능. 모든 Azure 지역에서 모든 서비스 및 기능을 사용할 수 있는 것은 아닙니다. 이 고려 사항은 선택한 지역에 영향을 줄 수 있습니다. 또한 가용성 영역은 모든 지역에서 사용할 수 없습니다.

  • 지역 쌍. Azure 지역은 단일 지역에 있는 두 지역으로 구성된 지역 쌍 으로 그룹화됩니다. 일부 Azure 서비스는 쌍을 이루는 지역을 사용하여 비즈니스 연속성을 보장하고 데이터 손실에 대한 보호 수준을 제공합니다. 예를 들어 Azure GRS(지역 중복 스토리지)는 보조 쌍을 이루는 지역에 데이터를 자동으로 복제하여 주 지역을 복구할 수 없는 경우 데이터가 지속되도록 합니다. 중단이 여러 Azure 지역에 영향을 주는 경우 복구를 위해 각 쌍에서 하나 이상의 지역이 우선 순위가 지정됩니다.

  • 데이터 일관성. 일관성 문제의 경우 전역적으로 분산된 데이터 저장소, 스탬프가 찍은 지역 아키텍처 및 부분적으로 활성/활성 배포를 사용하는 것이 좋습니다. 부분 배포에서 일부 구성 요소는 모든 지역에서 활성화되고 다른 구성 요소는 주 지역 내에서 중앙에 위치합니다.

  • 안전한 배포. Azure SDP(안전한 배포 사례) 프레임워크를 통해 Azure 플랫폼에 대한 모든 코드 및 구성 변경(계획된 유지 관리)이 단계적으로 롤아웃됩니다. 릴리스 중에 성능 저하를 위해 상태를 분석합니다. 카나리아 및 파일럿 단계가 성공적으로 완료되면 플랫폼 업데이트가 지역 쌍 간에 직렬화되므로 각 쌍의 한 지역만 지정된 시간에 업데이트됩니다.

  • 플랫폼 용량. 다른 클라우드 공급자와 마찬가지로 Azure에는 한정된 리소스가 있습니다. 사용 불가는 지역의 용량 제한의 결과일 수 있습니다. 지역 가동 중단이 있는 경우 워크로드가 쌍을 이루는 지역 내에서 복구를 시도함에 따라 리소스에 대한 수요가 증가합니다. 가동 중단으로 인해 공급이 일시적으로 수요를 충족하지 못하는 용량 문제가 발생할 수 있습니다.

디자인 권장 사항

  • 지역 가동 중단으로부터 보호하기 위해 두 개 이상의 Azure 지역에 솔루션을 배포합니다. 워크로드에 필요한 기능과 특징이 있는 지역에 배포합니다. 기능은 데이터 보존 및 보존 요구 사항을 충족하면서 성능 및 가용성 목표를 충족해야 합니다.

    예를 들어 일부 데이터 규정 준수 요구 사항은 사용 가능한 지역 수를 제한하고 잠재적으로 디자인 손상이 발생할 수 있습니다. 이러한 경우 운영 래퍼에 추가 투자를 추가하여 오류를 예측, 감지 및 대응하는 것이 좋습니다. 두 지역이 있는 지리로 제한되고 해당 지역 중 하나만 가용성 영역(3 + 1 데이터 센터 모델)을 지원한다고 가정합니다. 장애 도메인 격리를 사용하여 보조 배포 패턴을 만들어 두 지역을 활성 구성으로 배포할 수 있도록 하고 주 지역에 여러 배포 스탬프가 있는지 확인합니다.

    적합한 Azure 지역이 필요한 기능을 모두 제공하지 않는 경우 지역 배포 스탬프의 일관성을 손상하여 지리적 배포의 우선 순위를 지정하고 안정성을 극대화할 준비를 합니다. 단일 Azure 지역만 적합한 경우 선택한 지역에 여러 배포 스탬프(지역 배율 단위)를 배포하여 일부 위험을 완화하고 가용성 영역을 사용하여 데이터 센터 수준 내결함성을 제공합니다. 그러나 지리적 분포가 크게 손상되면 달성 가능한 복합 SLA 및 전반적인 안정성이 크게 제한됩니다.

    중요

    99.99%보다 크거나 같은 SLO를 대상으로 하는 시나리오의 경우 복합 SLA 및 전반적인 안정성을 최대화하려면 최소 3개의 배포 지역을 사용하는 것이 좋습니다. 모든 사용자 흐름에 대한 복합 SLA 를 계산합니다. 복합 SLA가 비즈니스 목표와 일치하는지 확인합니다.

  • 상당한 양의 트래픽이 있는 대규모 애플리케이션 시나리오의 경우 단일 지역 내에서 잠재적인 용량 제약 조건을 탐색하기 위해 여러 지역에 걸쳐 스케일링할 솔루션을 설계합니다. 추가 지역 배포 스탬프는 더 높은 복합 SLA를 달성합니다. 전역 리소스를 사용하면 더 많은 지역을 추가하여 달성한 복합 SLA의 증가가 제한됩니다.

  • RPO(복구 지점 목표) 및 RTO(복구 시간 목표)를 정의하고 유효성을 검사합니다.

  • 단일 지역 내에서 계획되지 않은 유지 관리를 위해 계획된 유지 관리 및 지역 우선 순위 지정을 위해 SDP 직렬화된 롤아웃을 활용하려면 지역 쌍의 사용 우선 순위를 지정합니다.

  • 네트워크 대기 시간을 최소화하고 엔드 투 엔드 성능을 최대화하기 위해 Azure 리소스를 사용자와 지리적으로 공동 배치합니다.

  • 배포 지역을 선택할 때 현재 서비스 가용성을 제품 로드맵에 맞춥니다. 일부 서비스는 모든 지역에서 즉시 사용할 수 없습니다.

컨테이너화

컨테이너에는 애플리케이션 코드와 애플리케이션이 실행해야 하는 관련 구성 파일, 라이브러리 및 종속성이 포함됩니다. 컨테이너화는 애플리케이션 코드 및 해당 종속성에 대한 추상화 계층을 제공하고 기본 호스팅 플랫폼과 분리를 만듭니다. 단일 소프트웨어 패키지는 이식성이 뛰어나며 다양한 인프라 플랫폼 및 클라우드 공급자에서 일관되게 실행할 수 있습니다. 개발자는 코드를 다시 작성할 필요가 없으며 애플리케이션을 더 빠르고 안정적으로 배포할 수 있습니다.

중요

중요 업무용 애플리케이션 패키지에 컨테이너를 사용하는 것이 좋습니다. 동일한 가상화된 인프라에서 여러 컨테이너를 호스트할 수 있으므로 인프라 사용률이 향상됩니다. 또한 모든 소프트웨어가 컨테이너에 포함되어 있으므로 런타임 또는 라이브러리 버전에 관계없이 다양한 운영 체제에서 애플리케이션을 이동할 수 있습니다. 기존 가상화된 호스팅보다 컨테이너 관리가 더 쉽습니다.

중요 업무용 애플리케이션은 성능 병목 현상을 방지하기 위해 빠르게 확장해야 합니다. 컨테이너 이미지는 미리 빌드되어 있으므로 빠른 확장성을 제공하는 애플리케이션의 부트스트래핑 중에만 시작이 발생하도록 제한할 수 있습니다.

디자인 고려 사항

  • 모니터링. 모니터링 서비스가 컨테이너에 있는 애플리케이션에 액세스하기 어려울 수 있습니다. 일반적으로 CPU 또는 RAM 사용량과 같은 컨테이너 상태 표시기를 수집하고 저장하려면 타사 소프트웨어가 필요합니다.

  • 보안. 호스팅 플랫폼 OS 커널은 여러 컨테이너에서 공유되어 단일 공격 지점을 만듭니다. 그러나 컨테이너는 기본 운영 체제에서 격리되므로 호스트 VM 액세스의 위험이 제한됩니다.

  • 상태입니다. 실행 중인 컨테이너의 파일 시스템에 데이터를 저장할 수 있지만 컨테이너를 다시 만들 때 데이터가 유지되지 않습니다. 대신 외부 스토리지를 탑재하거나 외부 데이터베이스를 사용하여 데이터를 유지합니다.

디자인 권장 사항

  • 모든 애플리케이션 구성 요소를 컨테이너화합니다. 컨테이너 이미지를 애플리케이션 배포 패키지의 기본 모델로 사용합니다.

  • 가능하면 Linux 기반 컨테이너 런타임의 우선 순위를 지정합니다. 이미지는 더 가벼우며 Linux 노드/컨테이너에 대한 새로운 기능이 자주 릴리스됩니다.

  • 짧은 수명 주기로 컨테이너를 변경할 수 없으며 교체할 수 있도록 합니다.

  • 컨테이너, 컨테이너 호스트 및 기본 클러스터에서 모든 관련 로그 및 메트릭을 수집해야 합니다. 추가 처리 및 분석을 위해 수집된 로그 및 메트릭을 통합 데이터 싱크로 보냅니다.

  • 컨테이너 이미지를 Azure Container Registry 저장합니다. 지역 복제를 사용하여 모든 지역에서 컨테이너 이미지를 복제합니다. 컨테이너 레지스트리에 대한 Microsoft Defender 사용하도록 설정하여 컨테이너 이미지에 대한 취약성 검사를 제공합니다. 레지스트리에 대한 액세스가 Microsoft Entra ID로 관리되는지 확인합니다.

컨테이너 호스팅 및 오케스트레이션

여러 Azure 애플리케이션 플랫폼은 컨테이너를 효과적으로 호스트할 수 있습니다. 이러한 각 플랫폼과 관련된 장점과 단점이 있습니다. 비즈니스 요구 사항의 컨텍스트에서 옵션을 비교합니다. 그러나 항상 안정성, 확장성 및 성능을 최적화합니다. 자세한 내용은 다음 문서를 참조하세요.

중요

AKS(Azure Kubernetes Service) 및 Azure Container Apps는 요구 사항에 따라 컨테이너 관리를 위한 첫 번째 선택 항목 중 하나여야 합니다. Azure App Service 오케스트레이터는 아니지만 마찰이 적은 컨테이너 플랫폼으로서 AKS에 대한 실행 가능한 대안입니다.

Azure Kubernetes Service 대한 디자인 고려 사항 및 권장 사항

관리되는 Kubernetes 서비스인 AKS는 복잡한 클러스터 관리 작업 없이도 빠른 클러스터 프로비저닝을 가능하게 하며 고급 네트워킹 및 ID 기능을 포함하는 기능 집합을 제공합니다. 전체 권장 사항 집합은 Azure Well-Architected Framework 검토 - AKS를 참조하세요.

중요

AKS 클러스터를 다시 배포하지 않고는 변경할 수 없는 몇 가지 기본 구성 결정이 있습니다. 예를 들어 공용 및 프라이빗 AKS 클러스터 중에서 선택, Azure 네트워크 정책 사용, Microsoft Entra 통합, 서비스 주체 대신 AKS에 대한 관리 ID 사용 등이 있습니다.

안정성

AKS는 네이티브 Kubernetes 컨트롤 플레인을 관리합니다. 컨트롤 플레인을 사용할 수 없는 경우 워크로드에 가동 중지 시간이 발생합니다. AKS에서 제공하는 안정성 기능을 활용합니다.

  • 다양한 Azure 지역에 AKS 클러스터를 확장 단위로 배포하여 안정성과 가용성을 최대화합니다. 가용성 영역을 사용하여 물리적으로 분리된 데이터 센터에 AKS 컨트롤 플레인 및 에이전트 노드를 배포하여 Azure 지역 내에서 복원력을 최대화합니다. 그러나 공동 배치 대기 시간이 문제가 되는 경우 단일 영역 내에서 AKS 배포를 수행하거나 근접 배치 그룹을 사용하여 노드 간 대기 시간을 최소화할 수 있습니다.

  • 프로덕션 클러스터에 AKS 작동 시간 SLA 를 사용하여 Kubernetes API 엔드포인트 가용성 보장을 최대화합니다.

확장성

노드 수, 클러스터당 노드 풀 및 구독당 클러스터 수와 같은 AKS 크기 조정 제한을 고려합니다.

  • 크기 조정 제한이 제약 조건인 경우 배율 단위 전략을 활용하고 클러스터를 사용하여 더 많은 단위를 배포합니다.

  • 클러스터 자동 스케일러가 리소스 제약 조건에 대한 응답으로 에이전트 노드 수를 자동으로 조정하도록 설정합니다.

  • 수평 Pod 자동 크기 조정기를 사용하여 CPU 사용률 또는 기타 메트릭에 따라 배포의 Pod 수를 조정합니다.

  • 대규모 및 버스트 시나리오의 경우 광범위하고 빠른 규모 로 가상 노드를 사용하는 것이 좋습니다.

  • 애플리케이션 배포 매니페스트에서 Pod 리소스 요청 및 제한을 정의합니다. 그렇지 않으면 성능 문제가 발생할 수 있습니다.

격리

워크로드와 시스템 도구에서 사용하는 인프라 간의 경계를 유지 관리합니다. 인프라를 공유하면 리소스 사용률이 높고 노이즈 이웃 시나리오가 발생할 수 있습니다.

  • 시스템 및 워크로드 서비스에 별도의 노드 풀을 사용합니다. 워크로드 구성 요소에 대한 전용 노드 풀은 고메모리 GPU VM과 같은 특수 인프라 리소스에 대한 요구 사항을 기반으로 해야 합니다. 일반적으로 불필요한 관리 오버헤드를 줄이려면 많은 수의 노드 풀을 배포하지 마십시오.

  • taint 및 toleration을 사용하여 전용 노드를 제공하고 리소스를 많이 사용하는 애플리케이션을 제한합니다.

  • 애플리케이션 선호도 및 선호도 방지 요구 사항을 평가하고 노드에서 컨테이너의 적절한 공동 배치를 구성합니다.

보안

기본 바닐라 Kubernetes는 중요 업무용 시나리오에 적합한 보안 태세를 보장하기 위해 중요한 구성이 필요합니다. AKS는 다양한 보안 위험을 해결합니다. 기능에는 프라이빗 클러스터, Log Analytics 감사 및 로그인, 강화된 노드 이미지 및 관리 ID가 포함됩니다.

  • AKS 보안 기준에 제공된 구성 지침을 적용합니다.

  • AKS 기능을 사용하여 클러스터 ID 및 액세스 관리를 처리하여 운영 오버헤드를 줄이고 일관된 액세스 관리를 적용합니다.

  • 서비스 주체 대신 관리 ID를 사용하여 자격 증명 관리 및 회전을 방지합니다. 클러스터 수준에서 관리 ID를 추가할 수 있습니다. Pod 수준에서 Microsoft Entra 워크로드 ID 통해 관리 ID를 사용할 수 있습니다.

  • 중앙 집중식 계정 관리 및 암호, 애플리케이션 액세스 관리 및 향상된 ID 보호에 Microsoft Entra 통합을 사용합니다. 최소 권한으로 Microsoft Entra ID와 함께 Kubernetes RBAC를 사용하고, 구성 및 비밀 액세스를 보호하는 데 도움이 되는 관리자 권한 부여를 최소화합니다. 또한 Azure 역할 기반 액세스 제어를 사용하여 Kubernetes 클러스터 구성 파일에 대한 액세스를 제한합니다. 컨테이너가 수행할 수 있는 작업에 대한 액세스를 제한하고, 최소한의 권한을 제공하며, 루트 권한 에스컬레이션을 사용하지 않도록 합니다.

업그레이드

클러스터 및 노드를 정기적으로 업그레이드해야 합니다. AKS는 네이티브 Kubernetes 의 릴리스 주기에 따라 Kubernetes 버전을 지원합니다.

  • GitHub의 공용 AKS 로드맵 및 릴리스 정보를 구독하여 예정된 변경, 개선 사항 및 가장 중요한 Kubernetes 버전 릴리스 및 사용 중단에 대한 최신 정보를 유지합니다.

  • AKS 검사 목록에 제공된 지침을 적용하여 모범 사례와 일치하도록 합니다.

  • 노드 및/또는 클러스터를 업데이트하기 위해 AKS에서 지원하는 다양한 방법을 알고 있어야 합니다. 이러한 메서드는 수동 또는 자동화될 수 있습니다. 계획된 유지 관리를 사용하여 이러한 작업에 대한 유지 관리 기간을 정의할 수 있습니다. 새 이미지는 매주 릴리스됩니다. AKS는 AKS 클러스터를 사용할 수 있을 때 최신 버전의 Kubernetes 및/또는 최신 노드 이미지로 자동으로 업그레이드하기 위한 자동 업그레이드 채널 도 지원합니다.

네트워킹

사용 사례에 가장 적합한 네트워크 플러그 인을 평가합니다. Pod 간의 트래픽을 세분화하여 제어해야 하는지 여부를 결정합니다. Azure는 kubenet, Azure CNI를 지원하고 특정 사용 사례에 대해 고유한 CNI를 가져옵니다 .

네트워크 요구 사항 및 클러스터 크기를 평가한 후 Azure CNI 사용 우선 순위를 지정합니다. Azure CNI를 사용하면 클러스터 내의 트래픽을 제어하기 위해 Azure 또는 Calico 네트워크 정책을 사용할 수 있습니다.

모니터링

모니터링 도구는 실행 중인 Pod에서 로그 및 메트릭을 캡처할 수 있어야 합니다. 또한 Kubernetes 메트릭 API에서 정보를 수집하여 실행 중인 리소스 및 워크로드의 상태를 모니터링해야 합니다.

거버넌스

정책을 사용하여 일관된 방식으로 AKS 클러스터에 중앙 집중식 보호 장치를 적용합니다. 구독 scope 이상에서 정책 할당을 적용하여 개발 팀 전체에서 일관성을 높입니다.

  • Azure Policy 사용하여 Pod에 부여되는 함수와 실행이 정책과 모순되는지 여부를 제어합니다. 이 액세스는 AKS용 Azure Policy 추가 기능에서 제공하는 기본 제공 정책을 통해 정의됩니다.

  • Azure Policy 사용하여 AKS 클러스터 및 Pod 구성에 대한 일관된 안정성 및 보안 기준을 설정합니다.

  • AKS용 Azure Policy 추가 기능을 사용하여 루트 권한과 같은 Pod 함수를 제어하고 정책을 준수하지 않는 Pod를 허용하지 않습니다.

참고

Azure 랜딩 존에 배포하는 경우 랜딩 존 구현에서 일관된 안정성 및 보안을 보장하는 데 도움이 되는 Azure 정책을 제공해야 합니다.

중요 업무용 참조 구현은 권장 안정성 및 보안 구성을 구동하는 기준 정책 제품군을 제공합니다.

Azure App Service 대한 디자인 고려 사항 및 권장 사항

웹 및 API 기반 워크로드 시나리오의 경우 App Service AKS에 대한 가능한 대안이 될 수 있습니다. Kubernetes의 복잡성 없이 마찰이 적은 컨테이너 플랫폼을 제공합니다. 전체 권장 사항 집합은 App Service 안정성 고려 사항 및 App Service대한 운영 우수성을 참조하세요.

안정성

TCP 및 SNAT 포트 사용을 평가합니다. TCP 연결은 모든 아웃바운드 연결에 사용됩니다. SNAT 포트는 공용 IP 주소에 대한 아웃바운드 연결에 사용됩니다. SNAT 포트 고갈은 일반적인 오류 시나리오입니다. Azure Diagnostics 사용하여 포트를 모니터링하는 동안 부하 테스트를 통해 이 문제를 예측적으로 검색해야 합니다. SNAT 오류가 발생하는 경우 더 많거나 큰 작업자 간에 크기를 조정하거나 SNAT 포트를 보존하고 재사용하는 데 도움이 되는 코딩 방법을 구현해야 합니다. 사용할 수 있는 코딩 사례의 예로는 연결 풀링 및 리소스 지연 로드가 있습니다.

TCP 포트 고갈은 또 다른 실패 시나리오입니다. 지정된 작업자의 아웃바운드 연결 합계가 용량을 초과할 때 발생합니다. 사용 가능한 TCP 포트 수는 작업자의 크기에 따라 달라집니다. 권장 사항은 TCP 및 SNAT 포트를 참조하세요.

확장성

처음부터 적절한 권장 사항을 적용할 수 있도록 향후 확장성 요구 사항 및 애플리케이션 증가를 계획합니다. 이렇게 하면 솔루션이 증가함에 따라 기술 마이그레이션 문제를 방지할 수 있습니다.

  • 자동 크기 조정을 사용하도록 설정하여 서비스 요청에 적절한 리소스를 사용할 수 있는지 확인합니다. App Service 고밀도 호스팅에 대한 앱별 크기 조정을 평가합니다.

  • App Service 계획당 인스턴스의 기본 소프트 제한이 App Service.

  • 자동 크기 조정 규칙을 적용합니다. 프로필 내의 규칙이 충족되면 App Service 계획이 확장되지만 프로필 내의 모든 규칙이 충족되는 경우에만 확장됩니다. 스케일 아웃 및 스케일 인 규칙 조합을 사용하여 자동 크기 조정이 스케일 아웃 및 스케일 인 모두에 대한 작업을 수행할 수 있도록 합니다. 단일 프로필에서 여러 크기 조정 규칙의 동작을 이해합니다.

  • 애플리케이션을 호스트하는 App Service 계획과 독립적으로 확장할 수 있도록 App Service 계획 수준에서 앱별 크기 조정을 사용하도록 설정할 수 있습니다. 앱은 균등 배포를 위한 최선의 방법을 통해 사용 가능한 노드에 할당됩니다. 짝수 배포가 보장되지는 않지만 플랫폼은 동일한 앱의 두 인스턴스가 동일한 instance 호스트되지 않도록 합니다.

모니터링

애플리케이션 동작을 모니터링하고 관련 로그 및 메트릭에 액세스하여 애플리케이션이 예상대로 작동하는지 확인합니다.

  • 진단 로깅을 사용하여 Azure Event Hubs 통해 Log Analytics, Azure Storage 또는 타사 도구에 애플리케이션 수준 및 플랫폼 수준 로그를 수집할 수 있습니다.

  • Application Insights를 사용하여 애플리케이션 성능 모니터링은 애플리케이션 성능에 대한 심층적인 인사이트를 제공합니다.

  • 중요 업무용 애플리케이션은 오류가 있는 경우 스스로 치유할 수 있어야 합니다. 자동 복구를 사용하도록 설정하여 비정상 작업자를 자동으로 재활용합니다.

  • 적절한 상태 검사를 사용하여 모든 중요한 다운스트림 종속성을 평가해야 하므로 전반적인 상태를 보장하는 데 도움이 됩니다. 응답하지 않는 작업자를 식별하려면 Health Check 를 사용하도록 설정하는 것이 좋습니다.

배포

App Service 계획당 인스턴스의 기본 제한을 해결하려면 단일 지역의 여러 배율 단위로 App Service 계획을 배포합니다. 가용성 영역 구성에 App Service 계획을 배포하여 작업자 노드가 지역 내의 영역에 분산되도록 합니다. 지원 티켓을 열어 최대 작업자 수를 정상 최대 부하를 제공하는 데 필요한 instance 수의 두 배로 늘리는 것이 좋습니다.

컨테이너 레지스트리

컨테이너 레지스트리는 AKS와 같은 컨테이너 런타임 환경에 배포된 이미지를 호스트합니다. 중요 업무용 워크로드에 대해 컨테이너 레지스트리를 신중하게 구성해야 합니다. 특히 크기 조정 작업 중에 중단으로 인해 이미지 끌어당김이 지연되지 않아야 합니다. 다음 고려 사항 및 권장 사항은 중앙 집중식 배포 모델 및 페더레이션 배포 모델과 관련된 장만을 Azure Container Registry 중점으로 살펴봅니다.

디자인 고려 사항

  • 형식. 푸시 및 끌어오기 작업 모두에 Docker 제공 형식 및 표준을 사용하는 컨테이너 레지스트리를 사용하는 것이 좋습니다. 이러한 솔루션은 호환되며 대부분 서로 교환할 수 있습니다.

  • 배포 모델. 컨테이너 레지스트리를 organization 내의 여러 애플리케이션에서 사용하는 중앙 집중식 서비스로 배포할 수 있습니다. 또는 특정 애플리케이션 워크로드에 대한 전용 구성 요소로 배포할 수 있습니다.

  • 공용 레지스트리. 컨테이너 이미지는 Azure 및 지정된 가상 네트워크 외부에 있는 Docker Hub 또는 기타 공용 레지스트리에 저장됩니다. 반드시 문제가 되는 것은 아니지만 서비스 가용성, 제한 및 데이터 반출과 관련된 다양한 문제가 발생할 수 있습니다. 일부 애플리케이션 시나리오의 경우 송신 트래픽을 제한하거나 가용성을 높이거나 잠재적인 제한을 방지하기 위해 프라이빗 컨테이너 레지스트리에 공용 컨테이너 이미지를 복제해야 합니다.

디자인 권장 사항

  • 애플리케이션 워크로드 전용 컨테이너 레지스트리 인스턴스를 사용합니다. 조직의 가용성 및 안정성 요구 사항이 애플리케이션에 완전히 부합하지 않는 한 중앙 집중식 서비스에 대한 종속성을 만들지 마십시오.

    권장 되는 핵심 아키텍처 패턴에서 컨테이너 레지스트리는 오래 지속되는 글로벌 리소스입니다. 환경당 단일 전역 컨테이너 레지스트리를 사용하는 것이 좋습니다. 예를 들어 전역 프로덕션 레지스트리를 사용합니다.

  • 공용 레지스트리용 SLA가 안정성 및 보안 대상과 일치하는지 확인합니다. Docker Hub 의존하는 사용 사례에 대한 제한 제한을 특별히 기록해 둡니다.

  • 컨테이너 이미지를 호스팅하기 위한 Azure Container Registry 우선 순위를 지정합니다.

Azure Container Registry 대한 디자인 고려 사항 및 권장 사항

이 네이티브 서비스는 지역에서 복제, Microsoft Entra 인증, 자동화된 컨테이너 빌드 및 Container Registry 작업을 통한 패치를 비롯한 다양한 기능을 제공합니다.

안정성

지역 종속성을 제거하고 대기 시간을 최적화하도록 모든 배포 지역에 대한 지역 복제를 구성합니다. Container Registry는 지역 복제 를 통해 구성된 여러 지역으로의 고가용성을 지원하여 지역 중단에 대한 복원력을 제공합니다. 지역을 사용할 수 없게 되면 다른 지역은 계속해서 이미지 요청을 처리합니다. 지역이 다시 온라인 상태가 되면 Container Registry는 변경 내용을 복구하고 복제합니다. 또한 이 기능은 구성된 각 지역 내에서 레지스트리 공동 배치를 제공하여 네트워크 대기 시간과 지역 간 데이터 전송 비용을 줄입니다.

가용성 영역 지원을 제공하는 Azure 지역에서 프리미엄 Container Registry 계층은 영역 중복성을 지원 하여 영역 오류에 대한 보호를 제공합니다. 또한 프리미엄 계층은 레지스트리에 대한 무단 액세스를 방지하는 데 도움이 되는 프라이빗 엔드포인트 를 지원하므로 안정성 문제가 발생할 수 있습니다.

동일한 Azure 지역 내에서 소비하는 컴퓨팅 리소스에 가까운 이미지를 호스트합니다.

이미지 잠금

예를 들어 수동 오류의 결과로 이미지를 삭제할 수 있습니다. Container Registry는 변경 또는 삭제를 방지하기 위해 이미지 버전 또는 리포지토리 잠금 을 지원합니다. 이전에 배포한 이미지 버전 이 변경되면 동일한 버전 배포가 변경 전후에 다른 결과를 제공할 수 있습니다.

컨테이너 레지스트리 instance 삭제하지 않도록 보호하려면 리소스 잠금을 사용합니다.

태그가 지정된 이미지

태그가 지정된 Container Registry 이미지는 기본적으로 변경할 수 있습니다. 즉, 레지스트리에 푸시된 여러 이미지에서 동일한 태그를 사용할 수 있습니다. 프로덕션 시나리오에서 이로 인해 애플리케이션 작동 시간에 영향을 줄 수 있는 예측할 수 없는 동작이 발생할 수 있습니다.

ID 및 액세스 관리

Microsoft Entra 통합 인증을 사용하여 액세스 키에 의존하는 대신 이미지를 푸시하고 끌어올 수 있습니다. 보안 강화를 위해 관리자 액세스 키의 사용을 완전히 사용하지 않도록 설정합니다.

서버리스 컴퓨팅

서버리스 컴퓨팅은 요청 시 리소스를 제공하고 인프라를 관리할 필요가 없습니다. 클라우드 공급자는 배포된 애플리케이션 코드를 실행하는 데 필요한 리소스를 자동으로 프로비전, 크기 조정 및 관리합니다. Azure는 다음과 같은 여러 서버리스 컴퓨팅 플랫폼을 제공합니다.

  • Azure Functions. Azure Functions 사용하는 경우 애플리케이션 논리는 HTTP 요청 또는 큐 메시지와 같은 이벤트에 대한 응답으로 실행되는 고유한 코드 블록 또는 함수로 구현됩니다. 각 함수는 수요를 충족하기 위해 필요에 따라 크기가 조정됩니다.

  • Azure Logic Apps. Logic Apps는 다양한 앱, 데이터 원본, 서비스 및 시스템을 통합하는 자동화된 워크플로를 만들고 실행하는 데 가장 적합합니다. Azure Functions 마찬가지로 Logic Apps는 이벤트 기반 처리에 기본 제공 트리거를 사용합니다. 그러나 애플리케이션 코드를 배포하는 대신 조건부 및 루프와 같은 코드 블록을 지원하는 그래픽 사용자 인터페이스를 사용하여 논리 앱을 만들 수 있습니다.

  • Azure API Management. API Management 사용하여 소비 계층을 사용하여 향상된 보안 API를 게시, 변환, 유지 관리 및 모니터링할 수 있습니다.

  • Power Apps 및 Power Automate. 이러한 도구는 사용자 인터페이스의 연결을 통해 구성할 수 있는 간단한 워크플로 논리 및 통합을 통해 로우 코드 또는 코드 없는 개발 환경을 제공합니다.

중요 업무용 애플리케이션의 경우 서버리스 기술은 간단한 비즈니스 사용 사례에 유용할 수 있는 간소화된 개발 및 운영을 제공합니다. 그러나 이러한 단순성은 확장성, 안정성 및 성능 측면에서 유연성의 비용으로 제공되며 대부분의 중요 업무용 애플리케이션 시나리오에서는 실행 가능하지 않습니다.

다음 섹션에서는 중요하지 않은 워크플로 시나리오에 대한 대체 플랫폼으로 Azure Functions 및 Logic Apps를 사용하기 위한 디자인 고려 사항 및 권장 사항을 제공합니다.

Azure Functions 대한 디자인 고려 사항 및 권장 사항

중요 업무용 워크로드에는 중요하고 중요하지 않은 시스템 흐름이 있습니다. Azure Functions 중요한 시스템 흐름과 동일한 엄격한 비즈니스 요구 사항이 없는 흐름에 대한 실행 가능한 선택입니다. 함수는 가능한 한 빨리 실행되는 고유한 작업을 수행하기 때문에 수명이 짧은 프로세스가 있는 이벤트 기반 흐름에 적합합니다.

애플리케이션의 안정성 계층에 적합한 Azure Functions 호스팅 옵션을 선택합니다. 프리미엄 플랜을 사용하면 컴퓨팅 instance 크기를 구성할 수 있으므로 권장됩니다. 전용 플랜은 서버리스가 가장 적은 옵션입니다. 자동 크기 조정을 제공하지만 이러한 크기 조정 작업은 다른 계획보다 느립니다. 프리미엄 플랜을 사용하여 안정성과 성능을 최대화하는 것이 좋습니다.

몇 가지 보안 고려 사항이 있습니다. HTTP 트리거를 사용하여 외부 엔드포인트를 노출하는 경우 WAF(웹 애플리케이션 방화벽)를 사용하여 일반적인 외부 공격 벡터로부터 HTTP 엔드포인트에 대한 보호 수준을 제공합니다.

프라이빗 가상 네트워크에 대한 액세스를 제한하기 위해 프라이빗 엔드포인트를 사용하는 것이 좋습니다. 악의적인 관리자 시나리오와 같은 데이터 반출 위험을 완화할 수도 있습니다.

Azure Functions 코드에서 코드 검사 도구를 사용하고 해당 도구를 CI/CD 파이프라인과 통합해야 합니다.

Azure Logic Apps에 대한 디자인 고려 사항 및 권장 사항

Azure Functions 마찬가지로 Logic Apps는 이벤트 기반 처리에 기본 제공 트리거를 사용합니다. 그러나 애플리케이션 코드를 배포하는 대신 조건부, 루프 및 기타 구문과 같은 블록을 지원하는 그래픽 사용자 인터페이스를 사용하여 논리 앱을 만들 수 있습니다.

여러 배포 모드를 사용할 수 있습니다. 단일 테넌트 배포를 보장하고 시끄러운 인접 시나리오를 완화하려면 표준 모드를 사용하는 것이 좋습니다. 이 모드는 Azure Functions 기반으로 하는 컨테이너화된 단일 테넌트 Logic Apps 런타임을 사용합니다. 이 모드에서 논리 앱에는 여러 상태 저장 및 상태 비저장 워크플로가 있을 수 있습니다. 구성 제한을 알고 있어야 합니다.

IaaS를 통한 제한된 마이그레이션

기존 온-프레미스 배포가 있는 많은 애플리케이션은 가상화 기술 및 중복 하드웨어를 사용하여 중요 업무용 수준의 안정성을 제공합니다. 현대화는 중요 업무용 워크로드에 권장되는 클라우드 네이티브 기준(North Star) 아키텍처 패턴과의 완전한 정렬을 방지하는 비즈니스 제약 조건으로 인해 종종 방해를 받습니다. 따라서 많은 애플리케이션이 가상화를 사용하는 초기 클라우드 배포와 기본 애플리케이션 호스팅 모델로 Azure Virtual Machines 단계적 접근 방식을 채택합니다. IaaS 가상 머신의 사용은 특정 시나리오에서 필요할 수 있습니다.

  • 사용 가능한 PaaS 서비스는 필요한 성능 또는 제어 수준을 제공하지 않습니다.
  • 워크로드에는 운영 체제 액세스, 특정 드라이버 또는 네트워크 및 시스템 구성이 필요합니다.
  • 워크로드는 컨테이너에서 실행을 지원하지 않습니다.
  • 타사 워크로드에 대한 공급업체 지원은 없습니다.

이 섹션에서는 Azure Virtual Machines 및 관련 서비스를 사용하여 애플리케이션 플랫폼의 안정성을 최대화하는 가장 좋은 방법에 중점을 둡니다. 클라우드 네이티브 및 IaaS 마이그레이션 시나리오를 변환하는 중요 업무용 디자인 방법론의 주요 측면을 강조 표시합니다.

디자인 고려 사항

  • IaaS 가상 머신을 사용하는 운영 비용은 가상 머신 및 운영 체제의 관리 요구 사항 때문에 PaaS 서비스 사용 비용보다 훨씬 높습니다. 가상 머신을 관리하기 위해서는 소프트웨어 패키지 및 업데이트를 자주 롤아웃해야 합니다.

  • Azure는 가상 머신의 가용성을 높이는 기능을 제공합니다.

    • 가용성 집합은 장애 도메인 및 업데이트 도메인에 가상 머신을 배포하여 네트워크, 디스크 및 전원 오류로부터 보호하는 데 도움이 될 수 있습니다.
    • 가용성 영역은 지역 내에서 물리적으로 분리된 데이터 센터에 VM을 분산하여 더 높은 수준의 안정성을 달성하는 데 도움이 될 수 있습니다.
    • Virtual Machine Scale Sets 그룹의 가상 머신 수를 자동으로 크기 조정하는 기능을 제공합니다. 또한 instance 상태를 모니터링하고 비정상 인스턴스를 자동으로 복구하는 기능도 제공합니다.

디자인 권장 사항

중요

가능한 경우 PaaS 서비스 및 컨테이너를 사용하여 운영 복잡성과 비용을 줄입니다. 필요한 경우에만 IaaS 가상 머신을 사용합니다.

  • 적절한 크기의 VM SKU 크기를 통해 효과적인 리소스 사용률을 보장합니다.

  • 가용성 영역에 3개 이상의 가상 머신을 배포하여 데이터 센터 수준 내결함성을 달성합니다.

    • 상용 소프트웨어를 배포하는 경우 소프트웨어를 프로덕션 환경에 배포하기 전에 소프트웨어 공급업체에 문의하고 적절하게 테스트합니다.

  • 가용성 영역에 배포할 수 없는 워크로드의 경우 3개 이상의 VM이 포함된 가용성 집합 을 사용합니다.

    • 대기 시간이 짧은 워크로드와 같이 가용성 영역이 워크로드 요구 사항을 충족하지 않는 경우에만 가용성 집합을 고려합니다.

  • 확장성 및 영역 중복성을 위해 Virtual Machine Scale Sets 사용 우선 순위를 지정합니다. 이 점은 부하가 다양한 워크로드에 특히 중요합니다. 예를 들어 활성 사용자 또는 초당 요청 수가 다양한 부하인 경우

  • 개별 가상 머신에 직접 액세스하지 마세요. 가능하면 부하 분산 장치를 앞에 사용합니다.

  • 지역 가동 중단으로부터 보호하려면 여러 Azure 지역에 애플리케이션 가상 머신을 배포합니다.

  • 다중 지역 활성/활성 배포를 지원하지 않는 워크로드의 경우 지역 장애 조치(failover)를 위해 핫/웜 대기 가상 머신을 사용하여 활성/수동 배포를 구현하는 것이 좋습니다.

  • 유지 관리해야 하는 사용자 지정 이미지 대신 Azure Marketplace 표준 이미지를 사용합니다.

  • 수동 개입을 방지하여 가상 머신에 변경 내용을 배포하고 롤아웃하는 자동화된 프로세스를 구현합니다. 자세한 내용은 운영 절차 디자인 영역의 IaaS 고려 사항을 참조하세요.

  • 가상 머신 구성 요소에 애플리케이션 오류를 삽입하고 오류 완화를 관찰하는 비정상 상황 실험을 구현합니다. 자세한 내용은 지속적인 유효성 검사 및 테스트를 참조하세요.

  • 가상 머신을 모니터링하고 진단 로그 및 메트릭이 통합 데이터 싱크로 수집되는지 확인합니다.

  • 중요 업무용 애플리케이션 시나리오(해당하는 경우) 및 Azure의 IaaS 워크로드에 대한 보안 모범 사례에 대한 보안 사례를 구현합니다.

다음 단계

데이터 플랫폼에 대한 고려 사항을 검토합니다.

데이터 플랫폼