이 솔루션은 하이브리드 인프라에 배포된 워크로드의 클러스터 간 크기 조정을 달성하는 방법을 보여 줍니다. 이 솔루션은 Azure 로컬 클러스터에서 Azure Arc 지원 서비스의 확장성 및 관리 기능을 적용하여 달성됩니다.
아키텍처
이 아키텍처는 Azure Local, Azure Pipelines에서 Azure Arc 지원 서비스를 사용하여 하이브리드 솔루션을 배포하고 글로벌 부하 분산 장치 및 Azure 함수 앱의 통합을 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
아키텍처는 다음과 같은 단계로 구성됩니다.
두 Azure Local 인스턴스는 서로 다른 두 위치에 설정됩니다. Azure Local은 기본 온-프레미스 인프라 역할을 합니다.
Azure 로컬 인스턴스는 SD-WAN 통해 Azure에 연결되며 Azure Arc 및 Windows Admin Center를 통해 관리됩니다. 따라서 Azure 기능을 온-프레미스 인프라로 확장하고 Azure 관리 도구 및 서비스를 사용하여 온-프레미스 인프라 및 워크로드를 관리하고 모니터링할 수 있습니다.
Azure Local에 배포된 AKS(Azure Kubernetes Service)
관리 클러스터(AKS 호스트) 및 컨테이너화된 애플리케이션이 배포되는 워크로드 클러스터(대상 클러스터라고도 함)로 구성됩니다. Azure Local의 AKS에 대한 AKS(Azure Kubernetes Service) 기준 아키텍처 참조하세요. Azure 로컬 및 워크로드 클러스터의 Azure Kubernetes Service 호스트는 AksHci PowerShell 모듈을 사용하여 배포됩니다. PowerShell을 사용하여 Azure 로컬 및 Windows Server 클러스터Kubernetes를 설정하는
참조하세요. 네트워크 리소스의 가상화는 Azure 로컬 인스턴스의 SDN 기능을 적용하여 구현됩니다. 더 높은 네트워크 가용성을 위해 소프트웨어 Load Balancer Mux VM, RAS 게이트웨이 VM 및 네트워크 컨트롤러와 같은 필요한 SDN 네트워크 인프라 리소스를 배포합니다. Azure 로컬 및 Windows Server
SDN(소프트웨어 정의 네트워킹)을 참조하세요. AKS 인프라 및 워크로드 VM은 SDN SLB(소프트웨어 부하 분산 장치)를 통해 달성된 하이브리드 부하 분산을 사용하여 SDN Virtual Network에 배포됩니다. Azure 로컬AKS를 사용하여 Microsoft SDN(소프트웨어 정의 네트워킹) 배포
참조하세요. Azure Pipelines 두 Azure 로컬 온-프레미스 환경에 배포된 동일한 버전의 컨테이너화된 애플리케이션을 사용하여 프런트 엔드 애플리케이션을 배포합니다.
데이터베이스는 AKS 하이브리드에 배포된 Arc 지원 SQL Managed Instances에서 호스트됩니다.
개발자는 Kubernetes 매니페스트 및 AksHci PowerShell 모듈을 사용하여 AKS 하이브리드 클러스터 모두에 배포할 컨테이너로 애플리케이션을 패키지하고 Azure Pipelines를 통해 배포 작업을 자동화합니다.
애플리케이션에 대한 클라이언트 요청은 Azure Front Door 또는 Azure Traffic Manager와 같은 글로벌 부하 분산 장치 서비스를 통해 전달되며, 이 서비스는 가중 트래픽 라우팅 방법을 사용하여 요청을 적절한 서비스 엔드포인트로 라우팅합니다. 할당된 가중 백분율에 따라 트래픽은 Stack HCI의 두 AKS 하이브리드 클러스터에 배포된 서비스에 배포됩니다.
Traffic Manager와 Azure Front Door는 여러 지역에 클러스터가 있기 때문에 전역 부하 분산 기능을 해결하기 위한 실행 가능한 옵션입니다. Azure Front Door와 Traffic Manager 중에서 선택하는 것은 다양한 요인에 따라 달라지며, 다른 요소 중 하나를 추천하려면 신중하게 고려해야 합니다. 다른 부하 분산 서비스를 고려해야 하는 몇 가지 이유는 다음과 같습니다.
- 인터넷 연결 애플리케이션에서 HTTPS를 사용하는 경우 Azure Front Door가 바람직한 옵션입니다. 일반적으로 Traffic Manager는 이러한 인스턴스에서 기본 선택이 아닙니다. 예외가 있을 수 있지만 특정 시나리오는 이 토론의 범위를 벗어납니다.
- 기본 목표가 효율적인 글로벌 부하 분산인 경우 Traffic Manager로 충분할 수 있습니다. 콘텐츠 배달 최적화, 애플리케이션 계층 보안 및 고급 라우팅 기능도 필요한 경우 Azure Front Door가 더 적합할 수 있습니다.
- Traffic Manager는 설정이 더 간단하며 주로 부하 분산에 중점을 둡니다. Azure Front Door는 더 많은 기능을 제공하지만 학습 곡선이 더 가파르게 나타날 수 있습니다.
- 애플리케이션 유형을 고려합니다. 웹 중심이 더 많고 캐싱 및 SSL 종료와 같은 최적화가 필요한 경우 Azure Front Door가 도움이 될 수 있습니다.
- DNS 기반 라우팅과 관련하여 애플리케이션 수준에서 부하 분산을 처리할 때 복잡성이 줄어듭니다. 그러나 DNS 기반 라우팅에만 의존하면 실패 시 가동 중지 시간이 증가하여 애플리케이션의 SLA(서비스 수준 계약)에 부정적인 영향을 줄 수 있습니다. Azure Front Door와 Traffic Manager 간의 결정은 DNS 솔루션의 SLA와 애플리케이션이 두 옵션 간의 서로 다른 장애 조치(failover) 시간을 수용할 수 있는지 여부를 고려해야 합니다.
배포된 워크로드 애플리케이션은 Azure Arc 지원 서비스, Azure Monitor 및 Log Analytic 작업 영역을 사용하여 부하를 모니터링합니다.
일반적인 부하 조건에서 클라이언트 요청은 주 클러스터 환경에서 온-프레미스에서 호스트되는 앱의 인스턴스로 라우팅됩니다.
Arc 지원 AKS 클러스터 워크로드는 주문형에 따라 배포된 AKS 클러스터의 노드 수를 자동으로 확장하거나 축소하는 기본 제공 자동 크기 조정기를 사용하여 여러 인스턴스로 수평으로 확장되도록 설계되었습니다.
컨테이너 인사이트는 Azure Local에서 호스트되는 Kubernetes 클러스터에서 진단을 캡처하고 워크로드 성능을 모니터링하도록 설정됩니다.
트래픽이 증가하고 워크로드 클러스터가 추가 Pod 크기 조정 옵션 없이 최대 노드 수에 도달하면 Azure Function 앱을 트리거하는 경고를 생성합니다.
경고 규칙은 KubeNodeInventory 및 KubePodInventory Azure Monitor 테이블에서 최대 노드 수 및 Pod 준비 비율을 확인하는 사용자 지정 Kusto 쿼리의 결과를 모니터링하도록 구성됩니다. 컨테이너 인사이트에서 로그 경고 만들기를 참조 하세요.
Kubernetes 컨테이너 인사이트에서 미리 구성된 경고 규칙을 사용하여 Kubernetes 모니터링을 수행할 수도 있습니다. 컨테이너 인사이트에서 KubePodNotReady 또는 KubeHpaMaxedOut 메트릭 규칙을 적용하여 경고 규칙 조건을 구성할 수도 있습니다. 컨테이너 인사이트(미리 보기)에서 메트릭 경고 규칙을 참조하고 경고의 작업 그룹을 통해 Azure 함수 앱을 호출합니다.
Azure Function App은 주 클러스터의 조건에 따라 가중치가 적용된 트래픽 라우팅 규칙을 동적으로 관리하고 트래픽을 클러스터로 리디렉션합니다.
- Azure Function을 사용하여 클러스터 준비 상태 및 트래픽 조건의 미리 정의된 임계값 제한에 따라 리디렉션해야 하는 트래픽의 비율을 계산할 수 있습니다. 이렇게 하면 빠르게 변경에 적응하고, 작업을 자동화하고, 리소스를 효율적으로 확장하고, 비용을 절감할 수 있습니다.
- Azure Function은 트래픽 라우팅 규칙을 동적으로 관리하는 데 도움이 됩니다. 이 기능은 고가용성, 확장성 및 성능을 보장하며, 최대 트래픽 및 장애 조치(failover) 시나리오에서도 원활한 사용자 환경을 제공합니다. 예를 들어 초기 트래픽 분산은 트래픽의 100%가 잘 수행되고 부하를 처리할 수 있을 때 기본 클러스터로 전송하는 것으로 시작합니다. 주 클러스터가 거의 가득 차거나 성능 저하가 발생하는 경우 Azure Function 내에서 트래픽 라우팅 규칙을 조정할 수 있습니다. 이렇게 하면 일부 읽기 전용 트래픽이 보조 클러스터로 리디렉션됩니다.
두 클러스터 환경에서 실행되는 앱 인스턴스는 해당 클러스터 내에서 로컬로 arc 지원 SQL Managed Instance와 같은 데이터 서비스에 연결됩니다.
Arc SQL Managed Instances에 대한 클러스터 간 데이터 동기화는 Azure 장애 조치(failover) 그룹에 의해 관리되며, 이 그룹은 분산 가용성 그룹을 사용합니다. 클러스터 간의 동기화는 동기화 또는 비동기일 수 있습니다. Azure Arc 지원 SQL Managed Instance를 참조하세요.
전반적으로 이 워크플로에는 여러 클러스터 환경에서 애플리케이션 빌드 및 배포, 부하 분산, 트래픽 관리, 자동 크기 조정 및 데이터 동기화가 포함됩니다. 이 설정을 사용하면 서로 다른 두 데이터 센터 또는 위치에서 클러스터 간에 인프라를 수평적으로 확장하여 보안, 중복성, 유연성 및 효율적인 리소스 사용률을 제공할 수 있습니다.
구성 요소
Azure Front Door 는 계층 7 부하 분산 장치입니다. 이 아키텍처에서는 HTTP 요청을 Stack HCI 클러스터에 배포된 웹 애플리케이션으로 라우팅합니다. 일반적인 악용 및 취약성으로부터 애플리케이션을 보호하는 Azure Front Door와 함께 WAF(웹 애플리케이션 방화벽)를 사용하고, 이 디자인의 CDN(Content Delivery Network) 솔루션을 사용하여 대기 시간을 줄이고 에지 위치에서 콘텐츠를 캐싱하여 콘텐츠 로드 시간을 개선할 수 있습니다.
Traffic Manager 는 DNS 기반 트래픽 부하 분산 장치이며 실행 가능한 부하 분산 옵션입니다. 이를 사용하여 다양한 데이터 센터의 서비스 엔드포인트에 애플리케이션 트래픽의 배포를 제어할 수 있습니다. Traffic Manager 구성의 작동 방식은 다음과 같습니다.
- Azure의 글로벌 부하 분산 솔루션인 Traffic Manager를 설정하여 들어오는 트래픽을 Azure 로컬 인스턴스에 분산합니다. Traffic Manager는 요구 사항에 따라 성능, 장애 조치(failover) 또는 가중 라운드 로빈과 같은 다양한 부하 분산 방법을 사용하도록 구성할 수 있습니다.
- Azure 로컬 인스턴스에 배포된 워크로드의 엔드포인트에 해당하는 Traffic Manager 엔드포인트를 만듭니다. 이를 통해 Traffic Manager는 트래픽을 적절한 엔드포인트로 보낼 수 있습니다. 이 시나리오에서는 가중 라우팅 부하 분산 방법을 기반으로 트래픽을 직접 전송합니다.
- Azure 함수를 통해 계산된 크기 조정 정책에 따라 추가 용량 또는 고가용성이 필요한 경우 Traffic Manager는 라우팅 규칙 및 가중 백분율에 따라 트래픽을 다른 인스턴스로 동적으로 라우팅할 수 있습니다.
Application Insights는 이 하이브리드 솔루션에 배포된 다양한 구성 요소에서 원격 분석 데이터를 수집합니다. 문제를 식별하고, 성능을 최적화하고, 사용자 환경을 개선하는 데 사용할 수 있는 인사이트 및 분석을 제공합니다.
Azure Functions는 트래픽 배포를 위한 오케스트레이터 역할을 합니다. 리소스 사용률, 대기 시간 및 상태와 같은 요소를 평가하여 각 클러스터의 준비 상태를 모니터링합니다. 이 평가에 따라 함수 앱은 들어오는 트래픽을 보낼 위치를 결정합니다.
Azure 로컬 가상화된 Windows 및 Linux 워크로드를 호스트하고 온-프레미스 인프라와 Azure 서비스를 결합하는 하이브리드 환경에서 스토리지를 호스트하는 HCI(하이퍼 컨버지드 인프라) 클러스터 솔루션입니다.
- 이 솔루션은 Azure 로컬
Arc-Enabled Azure Kubernetes Service를 사용하여 두 환경 모두에서 웹앱 또는 API, Arc-Enabled Azure Server 및Arc-Enabled Data Services 호스트합니다.
- 이 솔루션은 Azure 로컬
Azure DevOps Services는 전체 소프트웨어 배달 수명 주기를 간소화하는 데 필요한 자동화 및 오케스트레이션을 제공하는 이 하이브리드 솔루션 배포 전략의 중추 역할을 합니다. 이를 통해 개발 팀은 파이프라인이 애플리케이션 빌드, 테스트 및 배포를 수행하는 동안 고품질 코드를 제공하는 데 집중할 수 있습니다.
Azure Local에 AKS 클러스터를 배포하려면 Azure Pipelines 내에서 빌드 서버를 설정할 수 있습니다. 빌드 서버는 배포 프로세스를 실행해야 합니다.
a. Azure 내에서 VM(가상 머신)을 만들거나 Stack HCI 환경에서 VM을 만듭니다. 또는 하이브리드 인프라에 대한 네트워크 연결이 있는 경우 기존 온-프레미스 VM을 빌드 서버로 사용합니다.
b. 빌드 서버(예: Git, Azure CLI 및 Azure PowerShell 모듈)에 필요한 도구를 설치합니다.
c. 서비스 주체를 설정하거나 관리 ID를 사용하여 Azure에 대한 인증을 구성합니다.
Azure Pipelines 는 CI/CD를 제공하고 호스트된 빌드 및 릴리스 에이전트 및 정의를 관리하는 서비스입니다. 개발 파이프라인은 GitHub, Bitbucket, Dropbox, OneDrive 및 Azure Repos를 비롯한 다양한 코드 리포지토리를 사용할 수 있습니다.
Azure Monitor 는 원격 분석 데이터를 수집하고 클러스터 및 워크로드의 성능을 모니터링합니다. 또한 Azure Function을 트리거하거나 클러스터가 비정상 상태가 되거나 미리 정의된 임계값을 초과하는 경우 관리자에게 알리도록 경고를 구성할 수 있습니다. Azure Automation 또는 Azure Logic Apps를 사용하여 모니터링 데이터를 기반으로 크기 조정 작업을 자동화할 수 있습니다.
Azure Policy 는 거버넌스 및 규정 준수 적용자 역할을 하여 Stack HCI 클러스터 및 관련 SDN 리소스가 정의된 지침 및 표준 내에서 작동할 수 있도록 보장합니다. Azure Policy를 통해 환경의 보안을 강화하는 몇 가지 예는 다음과 같습니다.
- Container Insight Addon 적용
- Stack HCI 클러스터 내에 필수 확장 설치
- 리소스 태그 지정 적용
- 정책 기반 액세스 제어
- 네트워킹 및 모니터링 관련 정책
Azure Container Registry는 Azure의 관리형 프라이빗 Docker 레지스트리 서비스입니다. Container Registry를 사용하여 클러스터에 배포되는 프라이빗 Docker 이미지를 저장합니다.
Azure Arc 는 Azure 서비스를 온-프레미스 환경으로 확장하여 조직이 자체 인프라 내에서 중요한 데이터를 유지하면서 클라우드 기능을 활용할 수 있도록 합니다.
컨테이너 인사이트는 AKS 클러스터에서 실행되는 컨테이너의 성능 및 상태에 대한 인사이트를 얻을 수 있도록 Azure Monitor에서 제공하는 모니터링 및 관찰성 솔루션입니다. AKS에 Azure Arc를 사용하도록 설정하면 컨테이너 인사이트 기능을 확장하여 온-프레미스 또는 다중 클라우드 환경과 같이 Azure 외부에서 실행되는 AKS 클러스터를 모니터링하고 관리할 수 있습니다.
Arc 지원 SQL Managed Instances 는 Stack HCI 인프라에서 만들고 Azure Arc를 사용하여 관리할 수 있는 Azure SQL 데이터 서비스입니다.
Azure Key Vault 를 사용하면 암호화 키, 비밀 및 인증서를 안전하게 저장하고 관리할 수 있습니다. Azure Key Vault는 주로 클라우드 서비스이지만 Azure 로컬 배포와 함께 사용하여 중요한 정보를 온-프레미스에 안전하게 저장하고 관리할 수도 있습니다.
SDN 인프라. Azure Local의 AKS 하이브리드 배포에서 부하 분산은 SLB(소프트웨어 부하 분산 장치) SDN을 통해 수행됩니다. SLB는 Mux 부하 분산 장치 VM, 게이트웨이 VM 및 네트워크 컨트롤러와 같은 필요한 SDN 네트워크 인프라 리소스를 포함하여 SDN(소프트웨어 정의 네트워킹) Virtual Network 내에서 AKS-HCI 인프라 및 애플리케이션을 관리합니다.
관련된 구성 요소의 분석은 다음과 같습니다.
- SLB(소프트웨어 Load Balancer): SLB는 클러스터에서 실행되는 애플리케이션에 네트워크 트래픽을 분산하기 위한 부하 분산 기능을 제공하는 AKS-HCI 인프라의 핵심 구성 요소입니다. 전송 계층(계층 4)에서 작동하고 구성된 규칙에 따라 트래픽을 전달합니다.
- Mux Load Balancer VM: Mux 부하 분산 장치 VM은 외부 원본에서 들어오는 네트워크 트래픽을 처리하고 AKS-HCI 클러스터 내의 적절한 백 엔드 Pod 또는 서비스에 배포하는 가상 머신입니다. 부하 분산을 수행하기 위해 SLB와 함께 작동합니다.
- 게이트웨이 VM: 게이트웨이 VM은 AKS-HCI 클러스터와 외부 네트워크 간의 연결을 제공합니다. 내부 SDN Virtual Network와 외부 네트워크 간의 브리지 역할을 하여 수신 및 송신 트래픽이 안전하게 흐르도록 합니다.
- 네트워크 컨트롤러: 네트워크 컨트롤러는 AKS-HCI 클러스터 내에서 SDN 인프라를 관리해야 합니다. 네트워크 정책 적용, 네트워크 구성 및 부하 분산 장치 구성과 같은 작업을 처리합니다.
AKS-HCI는 SLB, Mux 부하 분산 장치 VM, 게이트웨이 VM 및 네트워크 컨트롤러를 사용하여 하이브리드 배포에 대한 부하 분산을 달성합니다. 들어오는 네트워크 트래픽이 클러스터 내에서 실행되는 애플리케이션에 효율적으로 분산되어 고가용성 및 확장성을 제공합니다.
참고 항목
이러한 구성 요소는 AKS-HCI에서 관리 및 구성되므로 플랫폼의 기본 제공 부하 분산 기능을 사용하는 동안 애플리케이션을 배포하고 관리하는 데 집중할 수 있습니다.
대안
웹 애플리케이션 및 이벤트 기반 서비스의 경우 Azure Local에서 호스트되는 Azure Arc 지원 Kubernetes 클러스터에서 App Service, Functions 및 Logic Apps를 실행할 수 있습니다. 데이터베이스의 경우 Azure Arc 지원 PostgreSQL 서버와 같은 다른 스토리지 옵션을 사용할 수 있습니다.
웹 애플리케이션의 경우 Azure Front Door를 사용할 수 있습니다. Azure Front Door는 HTTP/HTTPS 계층인 계층 7에서 작동합니다. 분할 TCP를 사용하는 anycast 프로토콜 및 Microsoft 글로벌 네트워크를 사용하여 글로벌 연결을 개선합니다. 라우팅 방법을 사용하면 Azure Front Door가 클라이언트 요청을 가장 빠르고 가장 가용성이 높은 애플리케이션 백 엔드로 라우팅합니다.
Azure ExpressRoute를 사용하여 전용 프라이빗 네트워크 연결을 사용하여 로컬 네트워크를 Azure 리소스에 직접 연결할 수 있습니다.
리포지토리가 GitHub에 있는 경우 Azure Pipelines 대신 GitHub Actions를 사용할 수 있습니다.
시나리오 정보
기본 목표는 서로 다른 두 데이터 센터 또는 위치에 위치한 클러스터 간에 워크로드를 효과적으로 분산하여 클러스터 간 크기를 쉽게 조정하는 것입니다. 이 방법은 단일 클러스터의 오버로드를 방지하고 모든 클러스터에서 리소스 사용률을 최적화합니다. Azure Function App은 클러스터 준비 상태에 따라 트래픽을 지능적으로 분산하여 효율성, 확장성, 가용성 및 성능을 향상시키는 데 중요한 역할을 합니다.
이 시나리오는 엄격한 제약 조건, 데이터 주권 규정 또는 중요한 복원력 및 비즈니스 연속성 요구 사항을 처리하거나 은행, 금융, 국방 및 정부와 같은 매우 제한적이고 규제된 환경에서 중요한 워크로드를 처리하는 조직에 적용됩니다. 조직의 규정 및 규정 준수 정책으로 인해 애플리케이션 및 데이터베이스는 퍼블릭 클라우드에서 기밀 또는 중요한 데이터가 노출되지 않도록 온-프레미스에서 실행됩니다. 이 솔루션은 다음과 같은 경우에 유용합니다.
온-프레미스 앱은 성수기 동안 사용량이 급증하고 클러스터 내에서 자동 크기 조정이 발생하지만 주 클러스터는 100% 용량에 도달하여 서비스 실행을 중단하지 않고 오버플로 트래픽을 다른 데이터 센터 클러스터로 전환하려고 합니다.
앱/API 트래픽의 경로를 사용 가능한 가장 가까운 온-프레미스 환경으로 자동으로 다시 라우팅하려고 합니다.
온-프레미스 설정의 거버넌스 및 관리를 간소화하고 Azure Local에 배포된 Azure Arc 지원 서비스를 통해 일관되고 안전한 방식으로 방화벽 또는 프록시 서버를 통해 필터링되는 관련 클라우드 서비스에 액세스하려고 합니다.
잠재적인 사용 사례
- 온-프레미스 Azure 로컬 인스턴스 환경에서 고가용성, 확장성, 보안 및 제한된 워크로드를 구현하려고 합니다.
- 온-프레미스 앱의 사용량이 급증할 때마다 데이터 센터 간에 실행 중인 애플리케이션의 동적 크기 조정을 원합니다.
- 중앙 집중식 관리, 거버넌스 및 모니터링을 사용하여 클라우드 기반 자동화를 적용하려고 합니다.
- 온-프레미스 구성 요소가 있으며 다른 온-프레미스 설정을 사용하여 크기를 조정하려고 합니다.
- 워크로드 크기를 클라우드 인스턴스로 확장할 수 있을 때까지 동적 클러스터 간 확장성이 온-프레미스에서 앱을 실행하려고 합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
안정성
안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.
회사는 규정 및 성능상의 이유로 앱과 리소스를 온-프레미스에 유지하여 시스템을 유지 관리하는 하이브리드 접근 방식을 취할 수 있습니다. Azure 클라우드 기능을 적용하려는 경우 여러 지역에 걸쳐 Azure HCI 클러스터에 호스트되는 동일한 버전의 애플리케이션을 배포할 수 있습니다. 이렇게 하면 고가용성 및 확장성 있는 서비스의 규정 준수가 충족됩니다.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
AKS-HCI를 배포할 때는 애플리케이션 및 인프라를 보호하는 데 도움이 되는 보안 사례를 고려해야 합니다. AKS-HCI에 대한 몇 가지 주요 보안 고려 사항은 다음과 같습니다.
클러스터 액세스 보호
- 최소 권한 원칙에 따라 AKS-HCI 클러스터에 대한 액세스를 제한합니다. 사용자, 그룹 또는 서비스 계정에 필요한 권한만 부여합니다.
- Microsoft Entra 통합, Microsoft Entra Pod ID 또는 Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어)와 같은 강력한 인증 메커니즘을 사용하여 클러스터 및 해당 리소스에 대한 액세스를 제어합니다.
- 추가 보안 계층을 추가하기 위해 클러스터 액세스에 대한 MFA(다단계 인증)를 구현하는 것이 좋습니다.
네트워크 보안
- Kubernetes 네트워크 정책 또는 Azure 네트워크 보안 그룹을 사용하여 AKS-HCI 클러스터 내에서 네트워크 세분화 및 격리를 구현합니다.
- Azure Firewall과 같은 네트워크 수준 방화벽을 사용하여 인바운드 및 아웃바운드 트래픽을 제어하고 IP 허용 목록 또는 가상 네트워크 피어링에 따라 액세스를 제한합니다.
- TLS(전송 계층 보안) 또는 mTLS(상호 TLS) 인증을 사용하여 서비스 간 네트워크 트래픽을 암호화합니다.
컨테이너 이미지 보안
- 신뢰할 수 있는 원본의 보안 컨테이너 이미지를 사용하고 최신 보안 패치 및 취약성 수정으로 정기적으로 업데이트합니다.
- 이미지 검사 및 취약성 평가 도구를 구현하여 컨테이너 이미지의 보안 문제를 식별하고 수정합니다.
- 컨테이너 이미지 서명 및 확인 메커니즘을 사용하여 이미지의 무결성과 신뢰성을 보장합니다.
비밀 관리
- 애플리케이션 코드 또는 구성 파일에서 중요한 정보(예: 암호, API 키 또는 연결 문자열)를 하드 코딩하지 마세요.
- Azure Key Vault 또는 보안 비밀 관리 솔루션을 사용하여 중요한 정보를 안전하게 저장하고 검색합니다.
- Kubernetes 비밀 또는 Azure Key Vault 통합을 사용하여 비밀을 애플리케이션 컨테이너에 안전하게 삽입합니다.
로깅 및 모니터링
- Azure Monitor 또는 타사 솔루션을 사용하여 AKS-HCI 클러스터에 대한 중앙 집중식 로깅 및 모니터링을 구현합니다.
- 중요한 보안 이벤트를 캡처하도록 감사 로그, 컨테이너 로그 및 시스템 로그를 구성합니다.
- 보안 인시던트 또는 변칙을 사전에 감지하고 대응하도록 경고 및 알림 메커니즘을 설정합니다.
정기 업데이트 및 패치
- 최신 보안 패치 및 업데이트를 사용하여 AKS-HCI 클러스터 노드 및 기본 인프라를 최신 상태로 유지합니다.
- 패치 관리 프로세스를 설정하여 보안 수정 사항을 적시에 적용합니다.
규정 준수 및 규정 고려 사항
- 조직의 요구 사항에 따라 관련 업계별 보안 및 규정 준수 규정(예: HIPAA 또는 PCI DSS)을 이해하고 준수합니다.
- 업계에 적용되는 규정 준수 표준을 충족하도록 보안 제어 및 사례를 구현합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
Azure Local에서 Arc 지원 서비스를 배포하기 위한 몇 가지 비용 최적화 고려 사항:
- 과잉 프로비전 또는 사용 미달을 방지하기 위해 실제 워크로드 요구 사항에 따라 AKS-HCI 클러스터 노드의 크기를 올바르게 조정합니다.
- AKS-HCI 자동 크기 조정은 리소스 할당을 최적화하고 수요가 적은 기간 동안 비용을 절감하는 데 도움이 됩니다. 요청 및 워크로드 패턴에 따라 HPA(Horizontal Pod Autoscaling)를 구성하여 AKS-HCI 클러스터의 Pod 수를 자동으로 조정합니다.
-
스토리지 최적화:
- 워크로드 요구 사항 및 성능 요구 사항에 따라 적절한 스토리지 옵션을 선택합니다.
- 영구 볼륨에 Azure Disk Storage를 사용하거나 공유 파일 스토리지에 Azure Files를 사용하는 것이 좋습니다.
- 워크로드 요구에 따라 디스크의 크기 및 유형을 조정하는 등 스토리지 구성을 최적화합니다.
-
태그 지정 및 리소스 그룹 관리:
- 일관된 리소스 태그 지정을 구현하여 리소스를 추적하고 분류합니다.
- 리소스 그룹을 사용하여 리소스를 논리적으로 구성하여 비용을 보다 쉽게 관리하고 추적할 수 있습니다.
-
지속적인 비용 모니터링 및 최적화:
- Microsoft Cost Management에서 제공하는 비용 보고서 및 대시보드를 정기적으로 검토하여 비용 절감 기회를 파악하고 지출을 최적화합니다.
- Azure Advisor와 같은 도구를 사용하여 리소스 사용률을 최적화하고 보안을 개선하며 비용을 절감하는 권장 사항을 받습니다.
- Azure DevOps Services를 사용하여 배포 및 유지 관리 작업을 줄입니다.
운영 우수성
운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.
성능 효율성
성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.
클러스터 간 크기 조정의 주요 이점은 조직의 보안 네트워크 내에서 설정을 완전히 제어하는 기능과 함께 온-프레미스 환경으로 주문형 크기 조정을 제공할 수 있다는 것입니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
Mayuri Bhavsar | 선임 클라우드 솔루션 설계자
Vidya Narasimhan | 수석 클라우드 솔루션 설계자
기타 기여자:
히만슈 아모드왈라 | 선임 클라우드 솔루션 설계자
나쿨 조시 | 주 소프트웨어 엔지니어링 관리자
비네스 마라 | 선임 클라우드 솔루션 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.