최신 애플리케이션 플랫폼 클러스터 관리
클라우드 채택 프레임워크는 클라우드에 대한 운영 관리 프로세스를 중립적인 의미로 정의하는 핵심 방법론을 제공합니다. 이 지침은 운영 관리 기준 및 기타 특수화된 작업 계층을 설정하는 데 도움이 됩니다. 이 지침은 IaaS(Infrastructure as a Service), PaaS(Platform as a Service), 컨테이너화된 워크로드가 혼합된 조직에 계속 적용할 수 있습니다. 이 문서에서는 컨테이너 관리를 준비하기 위해 기존 작업에 통합해야 하는 사항을 간략하게 설명합니다. 또한 AKS(Azure Kubernetes Service)를 컨테이너 관리 전략에 통합하면 얻을 수 있는 이점을 강조합니다.
운영 관리 요구 사항에 대한 비즈니스 맞춤
컨테이너는 여러 인프라 계층에 대한 종속성을 제거하여 향상된 운영 관리 기능을 제공합니다. 이러한 운영 개선을 실현하려면 비즈니스 조정부터 시작하여 전반적인 클라우드 관리 전략을 수정해야 할 수 있습니다.
적절한 운영 관리 사례를 설정하려면 클라우드 채택 계획에서 컨테이너를 사용하는 방법과 컨테이너화된 워크로드로의 전환에서 실현하려는 이점을 이해해야 합니다.
- 클라우드 플랫폼에서 컨테이너, IaaS, PaaS와 같은 여러 기술 솔루션을 관리하나요?
- 중앙 집중식 팀은 컨테이너 또는 AKS 플랫폼의 운영 및 관리를 지원하나요? 이 책임은 개별 워크로드 팀으로 이동하나요?
- 중앙 집중식 팀이 각 컨테이너 또는 Pod에서 실행되는 워크로드의 운영 및 관리를 지원하나요? 이 책임은 개별 워크로드 팀으로 이동하나요?
- 중요 업무용 워크로드에 컨테이너를 사용하고 있나요?
- 중요도가 낮거나 유틸리티 워크로드에 대해서만 컨테이너를 사용하여 비용을 절감하고 있나요?
- 개별 워크로드의 성능과 안정성은 얼마나 중요한가요?
- 컨테이너의 애플리케이션 상태 비저장인가요? 컨테이너의 워크로드를 보호하고 복구하기 위해 상태를 유지해야 하나요?
이러한 기본 질문은 컨테이너 및 AKS를 운영 관리 전략에 가장 잘 통합하는 방법을 구체화합니다.
운영 기준
운영 기준을 구현하면 클라우드 환경의 모든 자산을 운영하고 관리하는 데 필요한 도구에 대한 중앙 집중식 액세스를 제공합니다. 컨테이너화되지 않은 자산에 대한 운영 기준이 없는 경우 관리 방법론에 정의된 운영 기준을 구현할 수 있습니다.
운영 기준에는 가시성, 모니터링, 운영 규정 준수, 최적화, 보호/복구를 제공하는 도구와 구성이 포함되어야 합니다.
위의 문서에서 설명된 운영 기준은 컨테이너 또는 AKS 플랫폼에 대한 지원을 제공하지 않습니다. 그러나 Azure Monitor, Azure Backup, 기타 도구와 같은 컨테이너를 지원하도록 확장할 수 있는 도구 기반을 제공합니다.
클라우드의 대부분의 포트폴리오가 컨테이너에 호스트되는 경우 다음 섹션의 특수 플랫폼 운영을 운영 기준에 포함하는 것이 좋습니다.
플랫폼 운영
이 구현이 조직의 클라우드에 대한 첫 번째 또는 유일한 배포가 아니라면 운영 기준이 있어야 합니다. 이 섹션에서는 컨테이너 또는 AKS 배포를 관리하는 데 도움이 되도록 포함할 수 있는 몇 가지 도구를 식별합니다.
인벤토리 및 표시 유형
컨테이너 및 AKS 클러스터 모니터링은 운영 기준에 포함된 도구, 대시보드, 경고를 사용합니다. 그러나 컨테이너의 데이터를 컨테이너용 Azure Monitor와 같은 작업 모니터링 도구로 가져오기 위해 더 많은 구성을 수행해야 할 수 있습니다. 컨테이너 및 AKS 플랫폼 운영을 운영 기준에 추가하는 데 필요한 데이터를 수집하려면 컨테이너용 Azure Monitor 개요를 참조하세요.
컨테이너에서 데이터를 수집하도록 Azure Monitor를 구성한 후에는 중앙 집중식 관리 프로세스의 일부로 다음 영역을 모니터링할 수 있습니다.
- 서비스 트리 항목에 이상적으로 연결되어 다양한 지역에서 실행되는 클러스터와 해당 클러스터의 주요 사실 식별
- 해당 클러스터의 클러스터 노드 풀, 네트워킹, 스토리지 토폴로지 식별
- AKS 버전 및 노드 이미지 버전 계층화를 식별합니다.
- 클러스터 노드 리소스 사용률 식별(프로세스, 메모리, 스토리지)
- 노드에서 실행되는 컨테이너 및 노드 사용률에 대한 기여도 식별
- 평균 및 부하가 가장 많은 클러스터의 동작을 이해합니다. 이 정보를 통해 용량 요구 사항을 파악하고 클러스터를 유지할 수 있는 최대 부하를 확인할 수 있습니다.
- 노드 또는 컨테이너의 CPU 및 메모리 사용률이 임계값을 초과하는 경우 또는 인프라나 노드 상태 롤업의 클러스터에서 상태 변경이 발생하는 경우를 사전에 알리거나 기록하도록 경고를 구성합니다.
- 쿼리를 사용하여 일반적인 경고 집합, 대시보드, 자세한 분석 수행
또한 이 데이터는 컨테이너화된 플랫폼에서 실행되는 워크로드에 대한 자세한 정보를 제공하여 워크로드 운영 팀을 지원합니다.
- Pod를 지원하는 표준 프로세스와 관련이 없는 호스트에서 실행되는 워크로드의 리소스 사용률을 검토합니다.
- Prometheus와 통합하여 애플리케이션 메트릭을 봅니다.
- 온-프레미스의 AKS 엔진 및 Azure Stack의 AKS 엔진에 배포된 컨테이너 워크로드를 모니터링합니다.
- Azure Red Hat OpenShift에 배포된 컨테이너 워크로드를 모니터링합니다.
- Azure Arc 사용 Kubernetes(미리 보기)에 배포된 컨테이너 워크로드를 모니터링합니다.
운영 규정 준수
패치, 튜닝, 크기 조정은 컨테이너화된 환경에서 몇 가지 다른 수준에서 발생합니다. 운영자는 원하는 운영 방식에 따라 여러 다른 팀에 앉을 수 있습니다. 운영 규정 준수를 유지하기 위해 운영자는 사용량을 모니터링하고, 성능과 비용의 균형을 맞추기 위해 자산 크기를 조정하고, 기본 시스템을 패치하여 위험 및 구성 드리프트를 최소화합니다. 중앙 IT 조직은 IaaS 및 PaaS 솔루션에 대한 운영 기준의 일부로 이러한 작업을 제공하는 경향이 있습니다.
Azure의 클러스터 환경에서 이러한 작업은 AKS 클러스터, 노드 이미지, 노드 OS와 같은 여러 수준에서 수행됩니다. 이러한 모든 작업 태스크는 클러스터 또는 개별 노드 풀에서 실행되는 워크로드의 이해 및 작업 관계에 더 의존하게 됩니다. 다음 문은 컨테이너 환경을 작동하기 위해 수행할 작업과 작업을 평가하는 데 도움이 됩니다.
- AKS 클러스터, 노드 이미지, 노드 OS의 크기 조정 및 패치가 애플리케이션에 대한 배포 파이프라인의 일부로 제공되거나 애플리케이션 아키텍처 또는 구성에 종속된 경우 세부적인 제어를 위해 운영 규정 준수를 워크로드 팀으로 전환하는 것이 가장 좋습니다. 워크로드는 종종 오케스트레이션 기능에 종속되기 때문에 예기치 않은 AKS 버전 변경 또는 노드 이미지 변경은 워크로드 또는 런타임 도구에 치명적일 수 있으므로 가장 일반적인 패턴입니다.
- 워크로드 포트폴리오 및 다양한 애플리케이션을 지원하는 덜 일반적인 중앙 집중식 클러스터의 경우 중앙 집중식 운영 팀은 여전히 운영 준수 작업을 담당할 수 있으며, 다음 지침은 클러스터 전체에서 이러한 작업을 제공하는 데 도움이 됩니다. 이러한 작업(task)을 반복적으로 실행하면 플랫폼별 작업(operation)을 수행합니다. 중앙 운영 접근 방식에는 주목할 만한 위험이 있으며, 사전 프로덕션 환경에서 업그레이드를 신중하게 테스트하고, 예약된 유지 관리를 명확하게 준수하며, 비규격 워크로드에 대한 대체 계획을 모두 마련해야 합니다. 잘못된 업그레이드 하나가 단일 실패 지점일 수 있으며, 마찬가지로 업그레이드할 수 없는 워크로드 하나 때문에 클러스터가 지원되지 않을 수 있습니다. 실사를 통해 다중 테넌트 클러스터를 계획하고 관리합니다.
두 클러스터 유형 모두 아래의 업그레이드, 노드 이미지, 노드 OS 업데이트에 대한 지침을 따르세요.
보호 및 복구
AKS 노드는 본질적으로 일시적이므로 개별적으로 복원할 수 있는 방식으로 백업되지 않습니다. 인시던트에서 복구하려면 인시던트 범위에 따라 워크로드를 새 노드 풀 또는 완전히 새 클러스터로 다시 배포해야 할 수 있습니다.
- 클러스터에 작동 시간 SLA를 추가하도록 선택합니다.
- 더 높은 SLA의 경우 추가 보호를 제공하기 위해 다중 변경 BCDR 모범 사례를 고려할 수도 있습니다.
- 클러스터에 상태가 포함되어서는 안 되므로 외부 상태 복원은 기존 운영 기준 지침을 사용하여 처리됩니다. 클러스터에 상태를 가져온 경우 스토리지에 대한 운영자 모범 사례를 따르고 지정된 워크로드에 대해 이 데이터를 백업 및 복원하는 전략을 갖추어야 합니다. Velero와 같은 도구의 사용은 운영 기준을 확장하는 플랫폼별 작업의 예입니다.
- 애플리케이션 포트폴리오가 일관성 없는 상태를 적용하는 경우 중앙 운영 팀은 두 솔루션을 모두 유지 관리하려고 해서는 안 됩니다. 대신 모든 컨테이너에 대해 원하는 상태 도구 체인을 표준화하지만 대체 복구 솔루션에 대한 책임을 워크로드 운영 팀으로 전환합니다. 이 접근 방식을 사용하면 개발자가 자유롭게 설계할 수 있고, 중앙 비용을 낮게 유지하고, 워크로드 팀이 표준을 준수할 수 있도록 비용 절감 인센티브를 제공합니다.
워크로드 운영
위의 플랫폼 작업 섹션에서는 AKS 클러스터를 관리할 때의 일반적인 대화를 보여 줍니다. Kubernetes 클러스터는 중앙에서 관리하는 기술 플랫폼인가요? 또는 각 워크로드를 소유한 팀에서 관리해야 하는 워크로드 도구인가요? 이 질문은 조직별로 다릅니다. 대부분의 조직에서 볼 수 있는 상수는 컨테이너 및 AKS가 워크로드 팀이 각 워크로드를 운영하는 방법에 더 많은 유연성을 제공하고 애플리케이션의 소유자와 고객에게 혜택을 주기 위해 해당 워크로드가 아키텍처에서 사용할 특정 기능을 제공하도록 설계되었다는 것입니다.
워크로드 작업은 기존 작업 기준 및 플랫폼별 작업을 기반으로 빌드할 수 있습니다. 완전히 분산된 워크로드 작업을 사용하여 AKS 클러스터를 안전하게 운영할 수도 있습니다. 두 경우 모두 특정 워크로드의 특정 결과에 집중하기 위해 운영을 승격해야 하는 경우 Azure Well-Architected Framework 및 Microsoft Azure Well-Architected Review를 사용하여 워크로드에 사용할 운영 프로세스 및 도구 유형에 대해 매우 구체적으로 확인할 수 있습니다.
다음 단계: 다음 마이그레이션 반복
최신 애플리케이션 플랫폼 마이그레이션이 완료되면 클라우드 채택 팀은 다음 시나리오별 마이그레이션을 시작할 수 있습니다. 또는 마이그레이션할 추가 플랫폼이 있는 경우 이 문서 시리즈를 다시 사용하여 다음 최신 애플리케이션 플랫폼 마이그레이션 또는 배포를 안내할 수 있습니다.