다음을 통해 공유

간소화된 애플리케이션 개발 및 인프라 관리를 위한 애플리케이션 플랫폼 구체화

  • 아티클

조직의 플랫폼 엔지니어링 사례를 개선하는 데 중요한 부분은 애플리케이션 플랫폼을 평가하는 것입니다. 애플리케이션 플랫폼에는 조직의 개발, 배포 및 애플리케이션 관리를 지원하는 데 사용되는 모든 도구와 서비스가 포함됩니다.

단순화 및 표준화

IaC(Infrastructure as Code) 및 자동화 도구를 템플릿과 결합하여 인프라 및 애플리케이션 배포를 표준화할 수 있습니다. 최종 사용자에 대한 플랫폼 관련 부담을 줄이려면 선택 항목을 관련 가능한 명명 규칙으로 세분화하여 플랫폼 세부 정보를 추상화합니다. 예를 들면 다음과 같습니다.

  • 리소스 종류 범주(높은 컴퓨팅, 높은 메모리)
  • 리소스 크기 범주(티셔츠 크기 조정, 중소형 및 대형)

템플릿은 미리 설정된 구성으로 테스트된 일반적인 요구 사항을 나타내야 하므로 개발 팀은 옵션을 검토하지 않고도 최소한의 매개 변수 제공을 즉시 시작할 수 있습니다. 그러나 팀이 게시된 템플릿에 대해 사용 가능하거나 바람직한 것보다 더 많은 옵션을 변경해야 하는 경우가 있습니다. 예를 들어 승인된 디자인에는 지원되는 템플릿 기본값을 벗어난 특정 구성이 필요할 수 있습니다. 이 인스턴스에서 운영 또는 플랫폼 엔지니어링 팀은 일회성 구성을 만든 다음 템플릿에서 이러한 변경 내용을 기본값으로 통합해야 하는지 여부를 결정할 수 있습니다.

드리프트(GitOps)를 자동으로 수정할 수 있는 드리프트 검색 기능이 있는 IaC 도구를 사용하여 변경 내용을 추적할 수 있습니다. 이러한 도구의 예로 Terraform 및 클라우드 네이티브 IaC 도구(예: 클러스터 API, 크로스플레인, Azure Service Operator v2)가 있습니다. IaC 도구 드리프트 외부에서 Azure Resource Graph와 같은 리소스 구성을 쿼리할 수 있는 클라우드 구성 도구가 있음을 감지합니다. 이는 두 가지 혜택으로 사용될 수 있습니다. 인프라 코드 외부의 변경 내용을 모니터링하고 변경된 사전 설정 구성을 검토합니다. 너무 엄격한 것을 방지하기 위해 미리 정의된 제한으로 배포에서도 허용 오차를 구현할 수 있습니다. 예를 들어 Azure Policy를 사용하여 배포에 사용할 수 있는 Kubernetes 노드 수를 제한할 수 있습니다.

자체 관리 또는 관리?

퍼블릭 클라우드에서는 SaaS, PaaS 또는 IaaS를 사용할 수 있습니다. SaaS, PaaS 및 IaaS에 대한 자세한 내용은 클라우드 개념 설명 학습 모듈 을 참조하세요. PaaS 서비스는 간소화된 개발 환경을 제공하지만 앱 모델에 더 규범적입니다. 궁극적으로, 사용 편의성과 평가해야 하는 제어 간에는 절판이 있습니다.

플랫폼 디자인 중에 조직의 서비스 요구 사항을 평가하고 우선 순위를 지정합니다. 예를 들어 AKS(Azure Kubernetes Service) 또는 ACA(Azure Container Apps)를 통해 직접 앱을 빌드하는지 여부는 서비스에 대한 요구 사항과 사내 용량 및 기술 집합에 따라 달라집니다. Azure Functions 또는 Azure 앱 Service와 같은 함수 스타일 서비스에서도 마찬가지입니다. ACA, Azure Functions 및 App Service는 복잡성을 줄이며 AKS는 더 많은 유연성과 제어를 제공합니다. OSS Radius 인큐베이션 프로젝트와 같은 더 많은 실험적 앱 모델은 둘 사이의 균형을 제공하려고 하지만 일반적으로 완전한 지원과 설정된 IaC 형식의 존재가 있는 클라우드 서비스보다 성숙도의 초기 단계에 있습니다.

계획할 때 식별한 문제는 이 규모의 끝이 적합한지 평가하는 데 도움이 됩니다. 결정을 내릴 때 고유한 내부 기존 기술 집합을 고려해야 합니다.

공유 및 전용 리소스

조직 내에는 사용률과 비용 효율성을 높이기 위해 여러 애플리케이션에서 공유할 수 있는 리소스가 있습니다. 각 공유 리소스에는 고유한 고려 사항 집합이 있습니다. 예를 들어 K8s 클러스터를 공유하기 위한 고려 사항이지만 일부는 다른 유형의 리소스에 적용됩니다.

  • 조직: 조직의 경계를 넘지 않고 클러스터와 같은 리소스를 공유하면 조직의 방향, 요구 사항 및 우선 순위에 맞게 조정하는 방법이 향상될 수 있습니다.
  • 애플리케이션 테넌트: 애플리케이션에는 다른 테넌트 격리 요구 사항이 있을 수 있습니다. 다른 애플리케이션과 공존할 수 있는 경우 개별 애플리케이션 보안 및 규정 준수를 검토해야 합니다. 예를 들어 Kubernetes에서 애플리케이션은 네임스페이스 격리를 사용할 수 있습니다. 그러나 다양한 환경 유형에 대한 애플리케이션 테넌트도 고려해야 합니다. 예를 들어 잘못된 구성 또는 보안 문제로 인한 예기치 않은 영향을 방지하기 위해 동일한 클러스터의 프로덕션 애플리케이션과 테스트 애플리케이션을 혼합하지 않는 것이 가장 좋습니다. 또는 먼저 전용 Kubernetes 클러스터를 테스트하고 조정하여 공유 클러스터에 배포하기 전에 이러한 문제를 추적하도록 선택할 수 있습니다. 그럼에도 불구하고, 접근 방식의 일관성은 혼란과 실수를 방지하는 열쇠입니다.
  • 리소스 사용: 각 애플리케이션 리소스 사용량, 예비 용량을 이해하고 프로젝션을 수행하여 공유가 실행 가능한지 여부를 예측합니다. 또한 사용된 리소스의 제한(데이터 센터 용량 또는 구독 제한)을 알고 있어야 합니다. 목표는 공유 환경의 리소스 제약 조건으로 인해 애플리케이션 및 종속성을 이동하지 않거나 용량이 부족할 때 라이브 사이트 인시던트를 갖는 것입니다. 리소스 제한, 대표 테스트, 모니터링 경고 및 보고를 사용하여 리소스 소비를 식별하고 너무 많은 리소스를 사용하는 애플리케이션으로부터 보호합니다.
  • 공유 구성 최적화: 공유 클러스터와 같은 공유 리소스에는 추가 고려 사항 및 구성이 필요합니다. 이러한 고려 사항에는 교차 충전, 리소스 할당, 권한 관리, 워크로드 소유권, 데이터 공유, 업그레이드 조정, 워크로드 배치, 기준 구성 설정, 관리 및 반복, 용량 관리 및 워크로드 배치가 포함됩니다. 공유 리소스에는 이점이 있지만 표준 구성이 너무 제한적이고 진화하지 않으면 더 이상 사용되지 않습니다.

거버넌스 전략 구현

거버넌스는 가드레일을 사용하여 셀프 서비스를 사용하도록 설정하는 핵심 부분이지만 애플리케이션의 비즈니스 가치에 시간을 영향을 주지 않는 방식으로 규정 준수 규칙을 적용하는 것은 일반적인 과제입니다. 거버넌스에는 다음 두 부분이 있습니다.

  • 초기 배포 규정 준수(시작 오른쪽): 허용된 리소스 및 구성만 배포할 수 있도록 하는 권한 관리 및 정책을 사용하여 카탈로그를 통해 사용할 수 있는 표준화된 IaC 템플릿으로 이 작업을 수행할 수 있습니다.
  • 규정 준수 유지(올바른 유지): 정책 기반 도구는 리소스 변경이 있을 때 이를 방지하거나 경고할 수 있습니다. 핵심 인프라 외에도 컨테이너 또는 VM에서 사용되는 OS와 함께 K8과 같은 리소스 내의 규정 준수를 지원하는 도구도 고려합니다. 예를 들어 잠긴 OS 구성을 적용하거나 Windows 그룹 정책, SELinux, AppArmor, Azure Policy 또는 Kyverno와 같은 보안 소프트웨어 도구를 설치할 수 있습니다. 개발자가 IaC 리포지토리에만 액세스할 수 있는 경우 승인 워크플로를 추가하여 제안된 변경 내용을 검토하고 리소스 제어 평면(예: Azure)에 직접 액세스하지 못하도록 할 수 있습니다.

규정 준수를 유지하려면 문제에 액세스, 보고 및 조치를 수행하는 도구가 필요합니다. 예를 들어 Azure Policy는 감사, 보고 및 수정을 위해 많은 Azure 서비스와 함께 사용할 수 있습니다. 또한 요구 사항에 따라 감사, 거부 및 DeployIfNotExists와 같은 다른 모드가 있습니다.

정책은 규정 준수를 적용할 수 있지만 예기치 않게 애플리케이션을 중단할 수도 있습니다. 따라서 대규모로 작동할 때 PaC(정책)로 발전하는 것이 좋습니다. 시작 오른쪽 및 올바른 접근 방식의 핵심 부분인 PaC는 다음을 제공합니다.

  • 중앙에서 관리되는 표준
  • 정책에 대한 버전 제어
  • 자동화된 테스트 및 유효성 검사
  • 롤아웃 시간 단축
  • 연속 배포

PaC는 다음과 같은 기능을 사용하여 잠재적으로 잘못된 정책의 폭발 반경을 최소화하는 데 도움이 될 수 있습니다.

  • 검토 및 승인되는 리포지토리에 코드로 저장된 정책 정의입니다.
  • 테스트 및 유효성 검사를 제공하는 자동화입니다.
  • 기존 리소스에 대한 정책 및 수정의 링 기반 점진적 출시는 잠재적으로 잘못된 정책의 폭발 반경을 최소화하는 데 도움이 됩니다.
  • 수정 작업에는 배포의 90% 이상이 실패할 경우 수정 작업을 중지하는 등의 컨트롤이 포함된 안전 기능이 기본 제공되어 있습니다.

역할별 관찰 가능성 및 로깅 구현

애플리케이션 및 인프라를 지원하려면 전체 스택에서 관찰 가능성 및 로깅이 필요합니다.

관찰 가능성 및 로깅을 보여 주는 Grafana 대시보드의 그림입니다.

요구 사항은 역할마다 다릅니다. 예를 들어 플랫폼 엔지니어링 및 운영 팀은 적절한 경고가 있는 인프라의 상태 및 용량을 검토하기 위해 대시보드가 필요합니다. 개발자는 애플리케이션 메트릭, 로그 및 추적을 요구하여 애플리케이션 및 인프라 상태를 표시하는 대시보드 및 사용자 지정된 대시보드의 문제를 해결해야 합니다. 이러한 역할 중 하나가 발생할 수 있는 한 가지 문제는 유용한 정보가 부족하여 너무 많은 정보 또는 지식 격차에서 발생하는 인지 오버로드입니다.

이러한 문제를 해결하려면 다음을 고려하세요.

  • 표준: 로깅 표준을 적용하여 표준화된 대시보드를 더 쉽게 만들고 재사용하고 OpenTelemetry 관찰성 프레임워크와 같은 항목을 통해 수집 처리를 간소화할 수 있습니다.
  • 사용 권한: Grafana와 같은 항목을 사용하여 팀 또는 애플리케이션 수준 대시보드를 제공하여 관심 있는 모든 사용자에게 롤업 데이터를 제공하고 애플리케이션 팀의 신뢰할 수 있는 구성원이 필요할 때 로그에 안전하게 액세스할 수 있는 기능을 제공합니다.
  • 보존: 로그 및 메트릭을 유지하는 것은 비용이 많이 들 수 있으며 의도하지 않은 위험 또는 규정 준수 위반을 초래할 수 있습니다. 보존 기본값을 설정하고 시작 올바른 지침의 일부로 게시합니다.
  • 리소스 제한 모니터링: 운영 팀은 지정된 유형의 리소스에 대한 제한 사항을 식별하고 추적할 수 있어야 합니다. 이러한 제한 사항은 Azure Policy와 같은 도구를 사용하여 IaC 템플릿 또는 정책에 고려해야 합니다. 그런 다음, 작업은 Grafana와 같은 대시보드를 사용하여 사전에 모니터링하고 자동화된 크기 조정이 가능하지 않거나 사용하도록 설정되지 않은 공유 리소스를 확장해야 합니다. 예를 들어 시간이 지남에 따라 앱이 온보딩되고 수정될 때 용량에 대한 K8s 클러스터 노드 수를 모니터링합니다. 경고가 필요하며 이러한 정의는 프로그래밍 방식으로 리소스에 추가할 수 있도록 코드로 저장해야 합니다.
  • 주요 용량 및 상태 메트릭 식별: Prometheus 또는 Azure Container Insights와 같은 항목을 사용하여 메트릭 컬렉션이 부족해지려면 OS 및 공유 리소스(예: CPU, 메모리, 스토리지)를 모니터링하고 경고합니다. 사용 중인 소켓/포트, 번잡한 앱의 네트워크 대역폭 사용 및 클러스터에서 호스트되는 상태 저장 애플리케이션 수를 모니터링할 수 있습니다.

최소 권한, 통합 보안 관리 및 위협 탐지 원칙을 사용하여 보안 구축

코드, 컨테이너, 클러스터 및 클라우드/인프라의 모든 계층에서 보안이 필요합니다. 권장되는 최소 보안 단계는 다음과 같습니다.

  • 최소 권한 원칙을 따릅니다.
  • 여러 파이프라인에서 DevOps 보안 관리를 통합합니다.
  • 가장 중요한 위험을 식별하고 수정하기 위한 컨텍스트 인사이트가 표시되는지 확인합니다.
  • 런타임에 클라우드 워크로드에서 최신 위협에 대한 검색 및 대응을 사용하도록 설정합니다.

이 영역의 문제를 해결하려면 클라우드 및 하이브리드(예: 클라우드용 Microsoft Defender)에서 엔지니어링 및 애플리케이션 시스템, 리소스 및 서비스에서 작동하는 도구를 평가하는 도구가 필요합니다. 애플리케이션 보안 외에도 다음을 평가합니다.

사용 권한 요구 사항은 환경에 따라 다를 수 있습니다. 예를 들어 일부 조직에서는 개별 팀이 프로덕션 리소스에 액세스할 수 없으며 검토가 완료될 때까지 새 애플리케이션을 자동으로 배포할 수 없습니다. 그러나 개발 및 테스트 환경에서는 자동화된 리소스 및 앱 배포 및 문제 해결을 위한 클러스터에 대한 액세스가 허용될 수 있습니다.

서비스, 애플리케이션, 대규모 인프라에 대한 ID 액세스를 관리하는 것은 어려울 수 있습니다. ID 정보를 만들고, 유지 관리하고, 관리할 ID 공급자입니다. 계획에는 애플리케이션 및 서비스에 대한 인증 서비스가 포함되어야 하며 대규모 RBAC(역할 기반 액세스 제어 권한 부여) 시스템과 통합할 수 있습니다. 예를 들어 Microsoft Entra ID를 사용하여 모든 개별 클러스터에서 직접 권한을 설정할 필요 없이 Azure Kubernetes Service와 같은 Azure 서비스에 대한 대규모 인증 및 권한 부여를 제공할 수 있습니다.

애플리케이션은 스토리지와 같은 클라우드 리소스에 액세스하기 위해 ID에 액세스해야 할 수 있습니다. 요구 사항을 검토하고 ID 공급자가 가능한 가장 안전한 방법으로 이를 지원하는 방법을 평가해야 합니다. 예를 들어 AKS 내에서 클라우드 네이티브 앱은 Microsoft Entra ID와 페더레이션되는 워크로드 ID를 활용하여 컨테이너화된 워크로드가 인증되도록 할 수 있습니다. 이 방법을 사용하면 애플리케이션이 애플리케이션 코드 내에서 비밀 교환 없이 클라우드 리소스에 액세스할 수 있습니다.

워크로드 소유자를 식별하고 리소스를 추적하여 비용 절감

비용 관리는 플랫폼 엔지니어링의 또 다른 부분입니다. 애플리케이션 플랫폼을 제대로 관리하려면 워크로드 소유자를 식별하는 방법이 필요합니다. 특정 메타데이터 집합에 대한 소유자에게 매핑되는 리소스 인벤토리를 가져오는 방법을 원합니다. 예를 들어 Azure 내에서 AZURE 배포 환경의 프로젝트와 같은 개념과 함께 AKS 레이블, Azure Resource Manager 태그를 사용하여 다양한 수준에서 리소스를 그룹화할 수 있습니다. 이렇게 하려면 선택한 메타데이터에 워크로드 및 리소스를 배포할 때 필수 속성(Azure Policy와 같은 항목 사용)이 포함되어야 합니다. 이는 비용 할당, 솔루션 리소스 매핑 및 소유자에게 도움이 됩니다. 분리된 리소스를 추적하기 위해 정기적인 보고를 실행하는 것이 좋습니다.

추적 외에도 Microsoft Cost Management와 같은 비용 관리 시스템과 동일한 메타데이터를 사용하여 리소스 사용에 대한 비용을 개별 애플리케이션 팀에 할당해야 할 수 있습니다. 이 메서드는 애플리케이션 팀에서 프로비전한 리소스를 추적하지만 ID 공급자, 로깅 및 메트릭 스토리지, 네트워킹 대역폭 사용과 같은 공유 리소스의 비용은 다루지 않습니다. 공유 리소스의 경우 운영 비용을 개별 팀으로 균등하게 나누거나, 비유형 소비가 있는 전용 시스템(예: 로깅 스토리지)을 제공할 수 있습니다. 일부 공유 리소스 유형은 리소스 소비에 대한 인사이트를 제공할 수 있습니다. 예를 들어 Kubernetes에는 OpenCost 또는 Kubecost와 같은 도구가 있으며 도움이 될 수 있습니다.

또한 현재 지출을 검토할 수 있는 비용 분석 도구를 찾아야 합니다. 예를 들어 Azure Portal에는 미리 설정된 임계값에 도달하면 그룹의 리소스 사용을 추적하고 알림을 보낼 수 있는 비용 경고 및 예산 경고가 있습니다.

투자 시기 및 위치 결정

둘 이상의 애플리케이션 플랫폼이 있는 경우 높은 비용 또는 낮은 관찰 가능성과 같은 문제를 해결하는 개선에 투자할 시기와 위치를 결정하는 것이 까다로울 수 있습니다. 새로 시작하는 경우 Azure 아키텍처 센터에 는 평가할 수 있는 몇 가지 잠재적 패턴이 있습니다. 하지만 이 외에도 원하는 작업을 계획하기 시작할 때 고려해야 할 몇 가지 질문은 다음과 같습니다.

질문 팁
기존 애플리케이션 플랫폼을 조정하거나, 새로 시작하거나, 이러한 방법의 조합을 사용하시겠습니까? 지금 가지고 있는 것에 만족하거나 새로 시작하더라도 시간이 지남에 따라 변화에 적응하는 방법에 대해 생각하고 싶을 것입니다. 즉각적인 변경은 거의 작동하지 않습니다. 애플리케이션 플랫폼은 움직이는 대상입니다. 시간이 지남에 따라 이상적인 시스템이 변경됩니다. 이러한 사고와 관련된 마이그레이션 계획을 향후 설계에 고려하려고 합니다.
현재 하고 있는 일을 변경하려면 어떤 제품, 서비스 또는 투자에 만족하시나요? 속담처럼, "깨지지 않으면 고치지 마십시오." 그렇게 할 이유없이 일을 변경하지 마십시오. 그러나 자국에서 재배한 솔루션이 있는 경우 장기 유지 관리를 위해 기존 제품으로 전환해야 할 때인지 여부를 고려합니다. 예를 들어 자체 모니터링 솔루션을 운영하는 경우 운영 팀에서 해당 부담을 제거하고 새 관리되는 제품으로 마이그레이션하시겠습니까?
시간이 지남에 따라 가장 큰 변화가 발생하는 곳은 어디인가요? 조직 앱 유형의 모든(또는 대부분)에 공통적인 영역에서 이러한 항목이 있나요? 사용자 또는 내부 고객이 만족하지 않고 자주 변경할 가능성이 없는 영역은 시작하기에 좋은 장소입니다. 이들은 장기적으로 가장 큰 투자 수익률을 가지고 있습니다. 이를 통해 새 솔루션으로의 마이그레이션을 용이하게 하는 방법을 다림질할 수도 있습니다. 예를 들어 앱 모델은 유동적인 경향이 있지만 로그 분석 도구의 유효 기간이 길어지는 경향이 있습니다. 방향 변경에 원하는 반환이 있는지 확인하는 동안 시작할 새 프로젝트/애플리케이션에 집중할 수도 있습니다.
부가가치가 가장 높은 영역에서 사용자 지정 솔루션에 투자하고 있나요? 고유한 앱 인프라 플랫폼 기능이 경쟁 우위의 일부라고 강하게 생각하십니까? 격차를 확인한 경우 사용자 지정 작업을 수행하기 전에 공급업체가 투자할 가능성이 가장 큰 영역을 고려하고 다른 곳에서 사용자 지정 사고에 집중할 수 있습니다. 먼저 사용자 지정 앱 인프라 또는 앱 모델 공급자가 아닌 통합자로 생각해야 합니다. 당신이 구축 아무것도 장기적으로 선행 비용을 난쟁이 유지해야합니다. 공급업체가 장기적으로 다룰 것으로 의심되는 지역에서 솔루션을 사용자 지정해야 하는 긴급한 필요성을 느끼는 경우 일몰 또는 장기 지원을 계획하세요. 내부 고객은 일반적으로 기성품이 사용자 지정 제품만큼 행복합니다(그렇지 않은 경우).

기존 애플리케이션 플랫폼 투자를 조정하는 것이 좋은 방법이 될 수 있습니다. 업데이트를 수행할 때는 모든 종류의 롤아웃 전에 아이디어 파일럿을 간소화하기 위해 새 애플리케이션으로 시작하는 것이 좋습니다. IaC 및 애플리케이션 템플릿을 통해 이 변경을 고려합니다. 영향력이 높고 가치가 높은 영역에서 고유한 요구 사항을 위한 사용자 지정 솔루션에 투자합니다. 그렇지 않은 경우 기성품 솔루션을 사용하십시오. 엔지니어링 시스템과 마찬가지로 시간이 지남에 따라 변경을 관리하는 데 도움이 되는 하나의 엄격한 경로를 가정하는 대신 프로비저닝, 추적 및 배포를 자동화하는 데 집중합니다.

관련 콘텐츠

개발자 셀프 서비스 기반 디자인