최신 애플리케이션 플랫폼을 위한 계획

아티클
07/11/2023

클라우드 채택 프레임워크 계획 방법론은 전체 클라우드 채택 계획을 만들어 클라우드 기반 디지털 변환에 관련된 프로그램 및 팀을 안내하는 데 도움이 됩니다. 이 지침은 클라우드에서 수행하고자 하는 작업을 기반으로 백로그를 만드는 템플릿과 팀 전반에 걸쳐 필요한 기술을 구축하는 계획을 제공합니다.

계획 방법론의 적용은 디지털 자산을 합리화하는 5가지 R에 중점을 두고 있습니다. 클라우드로의 가장 일반적인 전환 방식은 마이그레이션 및 현대화 프로세스의 속도, 효율성 및 반복성에 집중하는 것입니다. 5가지의 R에서 계획은 일반적으로 재설계 및 재구축 옵션을 위한 제한된 병렬 지원으로 재호스트 옵션의 우선 순위를 지정합니다.

디지털 자산

디지털 자산을 계획할 때 인벤토리 데이터를 수집하고 자산을 합리화하려고 할 것입니다. 컨테이너 채택 계획에서 모든 자산(예: VM, 데이터 및 애플리케이션)은 지원하는 워크로드별로 그룹화해야 합니다. 그룹화 및 기본 합리화가 완료되면 이러한 워크로드를 평가하여 패키지를 결정하고 옵션을 다시 호스트하거나 아키텍처를 변경할 수 있습니다.

표준 클라우드 채택 계획 템플릿은 일반적인 클라우드 채택 노력에 필요한 작업 유형을 설명합니다. 그러나 워크로드를 컨테이너로 패키징하고 컨테이너 프로비전을 오케스트레이션하기 위한 계획에 작업을 추가해야 합니다.

주의

이 문서에서는 독자가 이미 Azure DevOps 클라우드 채택 계획 구축에 대한 문서 시리즈에 설명된 모범 사례를 따르고 있다고 가정합니다. 스프레드시트 또는 다른 프로젝트 추적 도구에서 클라우드 채택 계획을 추적하는 경우 여전히 다음 섹션을 적용할 수 있지만 실행 가능한 단계, 즉 계획에 데이터를 추가하는 단계는 조정해야 합니다.

경고

최신 애플리케이션 플랫폼 전략을 표준 마이그레이션 프로세스(또는 마이그레이션 팩터리)에 통합하려면 마이그레이션 전에 워크로드 아키텍처 디자인과 관련된 작업을 발전된 상태로 구현해야 합니다. 이러한 작업 없이 이 전략을 계속 진행하면 마이그레이션 작업이 지연되고 배포된 컨테이너 호스트 및 지원 워크로드에 대한 아키텍처 결정이 나빠질 수 있습니다.

후보 워크로드 식별

최신 애플리케이션 플랫폼 시나리오에서 더 많은 선행 투자가 필요한 장기 수익은 더 효율적인 마이그레이션 프로세스보다 우선시됩니다. 장기 투자는 특정 워크로드 그룹에 대한 혁신을 가능하게 하고 작업을 간소화하는 데 더욱 중점을 둠에 따라 계획의 특정 부분에 표시됩니다.

전략 및 계획 조정을 시작하기 위해 클라우드 채택 전략에 최신 애플리케이션 플랫폼을 추가할 경우 영향을 받을 수 있는 워크로드를 식별합니다. 기술적 변경을 구현하기 전에 이러한 가정을 확인할 것입니다. 잠재적인 후보를 식별하는 데 도움이 되도록 워크로드의 포트폴리오 내에서 다음 기준을 찾습니다.

현재 진행 중인 개발 또는 DevOps 투자: 프로덕션 워크로드의 비율이 현재 진행 중인 개발보다 적습니다. 일부는 지속적인 DevOps 관행을 통해 관리될 수도 있습니다.
워크로드 이식성: 일부 워크로드는 프라이빗 클라우드, 에지 또는 여러 퍼블릭 클라우드 공급자 간에 이식성이 필요할 수 있는 규정 준수, 데이터 보호 또는 운영 제약 조건의 영향을 받습니다.
워크로드 통합: 많은 워크로드(특히 사용률이 낮은 워크로드)는 컨테이너 호스트에 통합할 후보가 될 수 있으며, 그 결과 서버/VM 수가 줄어들고 운영 비용이 절감됩니다.
레거시 워크로드: 레거시 워크로드는 운영 체제에 대한 업데이트를 차단하고 클라우드로 마이그레이션하지 못하게 방해할 수도 있습니다. Azure 기능과 호환되지 않는 레거시 워크로드는 컨테이너 호스트에서 마이그레이션할 후보일 수 있습니다.

후보 워크로드 문서화

참고

다음 고려 사항 목록은 위의 기준으로 식별된 마이그레이션 후보에 대해서만 문서화해야 합니다.

클라우드 채택 계획을 빌드할 때 각 워크로드는 워크로드 정의 및 우선 순위 지정의 지침에 따라 문서화됩니다. 최신 애플리케이션 플랫폼 시나리오의 후보인 모든 워크로드에는 계획 실행을 안내하는 추가 정보가 필요합니다. 해당 문서에서 워크로드를 정의하기 위한 비즈니스 및 기술 입력 문서화의 중요성을 강조합니다. 최신 애플리케이션 플랫폼 후보의 경우 다음 데이터 요소를 워크로드 정의에 추가해야 합니다.

비즈니스 입력

다음은 최신 애플리케이션 플랫폼 전략에 워크로드를 포함하는 의사 결정에 영향을 줄 수 있는 비즈니스 관련 데이터 요소입니다.

규정 준수 영향 요소: 프라이빗 클라우드에서 이 워크로드를 호스트하도록 고려하게 만드는 특정 규정 준수 조건은 무엇인가요?
데이터 보호 영향 요소: 프라이빗 클라우드에서 이 워크로드를 호스트하도록 고려하게 만드는 데이터 보호 조치는 무엇인가요?
운영 제약 조건: 프라이빗 클라우드에서 이 워크로드를 호스트하도록 고려하게 만드는 운영 제약 조건은 무엇인가요?
최신 애플리케이션 플랫폼 결과: 다음 중 이 워크로드를 컨테이너 후보로 평가하도록 영향을 주는 요소는 무엇인가요? DevOps, 이식성, 통합, 레거시 또는 이 중 다수의 요소.
운영 모델: 이 워크로드는 중앙 집중식으로 관리(중앙 IT/CCoE에 의해)되나요, 아니면 분산식으로 관리(워크로드 팀별)되나요, 아니면 엔터프라이즈 운영을 통해 관리(중앙 지원 및 워크로드별 작업)되나요?

기술 입력

다음은 최신 애플리케이션 플랫폼 전략에 워크로드를 포함하기로 결정하는 데 영향을 줄 수 있는 기술 팀의 데이터 요소입니다.

위치 고려 사항:

워크로드가 호스트되는 위치와 관련된 고려 사항입니다.

퍼블릭 클라우드 호스팅 요구 사항: 퍼블릭 클라우드 요구 사항과 관련된 특정 기술 제약 조건이 있나요?
프라이빗 클라우드 호스팅 요구 사항: 프라이빗 클라우드 요구 사항과 관련된 특정 기술 제약 조건이 있나요?
에지 호스팅 요구 사항: 에지 요구 사항과 관련된 특정 기술 제약 조건이 있나요?
이식성 요구 사항: 클라우드 이식성 요구 사항과 관련된 특정 기술 제약 조건이 있나요?

작업 고려 사항:

플랫폼, 호스트 및 워크로드의 작업과 관련된 고려 사항입니다.

기본 클라우드 플랫폼: 조직은 작업 관리 도구를 제공할 기본 클라우드 플랫폼을 정의해야 합니다. 일부 조직에는 다양한 유형의 작업을 관리하는 기본 클라우드 플랫폼이 둘 이상 있을 수 있습니다. 이 워크로드를 운영하는 기본 클라우드 플랫폼은 무엇인가요?
추가 작업 플랫폼: 이 워크로드는 추가 작업 플랫폼에서도 관리되나요?
클라우드 호스팅 요구 사항: 이 워크로드에는 특정 클라우드 호스팅 전략이 필요한가요? 퍼블릭 클라우드, 프라이빗 클라우드 또는 클라우드 이식성
표준화된 오케스트레이션 플랫폼: 회사에 컨테이너 오케스트레이션을 위한 표준 솔루션이 있는 경우 고려할 표준화된 플랫폼의 이름을 포함합니다. 예: AKS(Azure Kubernetes Service), AKS 엔진 또는 Kubernetes.
사용자 지정 오케스트레이션 고려 사항: 비표준 컨테이너 오케스트레이션 플랫폼에 대한 요구 사항이 있나요? 그렇다면 해당 요구 사항을 설명합니다.
표준화된 호스트 작업: 워크로드가 유해하지 않으며 표준화된 호스트 작업에서 지원하는 공유 컨테이너에서 호스트될 수 있다고 가정합니다. 이 워크로드는 이 접근 방식과 호환되나요?
사용자 지정된 호스트 작업 고려 사항: 워크로드가 표준화된 작업과 호환되지 않는 경우 이 워크로드에 대한 호스트 작업 관행을 수립할 때 고려해야 할 특정 요구 사항은 무엇인가요?

애플리케이션 고려 사항:

애플리케이션이 어떻게 개발되었고 향후 어떻게 개발할지에 관한 고려 사항입니다.

PaaS(Platform as a Service) 런타임: 퍼블릭 클라우드 공급자는 종종 PaaS(Platform as a Service) 제품이라고도 하는 일관된 애플리케이션 런타임을 생성합니다. Azure의 Azure App Service에서 제공하는 PaaS 런타임입니다. 이 애플리케이션이 PaaS 런타임에서 작동할 수 있나요? 가장 호환되는 런타임은 무엇인가요?
표준화된 런타임: 애플리케이션이 PaaS 런타임과 호환되지 않는 경우 조직에서 제공하는 표준화된 런타임이 있나요? 이 워크로드를 빌드할 런타임은 무엇인가요?
사용자 지정 런타임 고려 사항: 이 워크로드에 대해 사용자 지정된 런타임이 필요한 특정 고려 사항은 무엇인가요?
런타임 제약 조건: 선택한 런타임에 의해 애플리케이션에 적용되는 제약 조건이 있나요?
애플리케이션 종속성: 이 워크로드는 특정 위치(예: 퍼블릭 또는 프라이빗)에 있는 기존 시스템에 종속되나요? 예를 들어 특정 솔루션에서 실행되는 SAP와 같은 ERP 시스템이 있습니다.
데이터 중력: 이 워크로드는 특정 위치(예: 퍼블릭 또는 프라이빗)에 있는 데이터 원본에 종속되나요? 예를 들어 SAP 또는 다른 중앙 집중식 데이터 원본의 데이터에 대한 종속성이 있을 수 있습니다.
승인된 목록 고려 사항: 사용자 지정 작업 고려 사항이 클라우드 플랫폼 내에서 사용하도록 승인되었나요? 배포에 포함해야 하는 승인된 서비스는 무엇인가요?

초기 컨테이너에 대한 고려 사항

컨테이너에서 워크로드를 패키징하는 것이 예약하고 작업해야 하는 첫 번째 작업입니다. 두 번째는 해당 컨테이너의 호스팅을 계획하는 것입니다.

표준화된 런타임, 오케스트레이션 및 작업을 위한 PaaS 솔루션

일부 워크로드는 고도로 자체 포함되며 Kubernetes와 같은 대규모 플랫폼과 함께 제공되는 고급 제어 및 인프라 요구 사항의 이점을 활용하지 않는 경우도 있습니다. 워크로드가 컨테이너화되었다는 이유만으로 Kubernetes에 배포해야 한다는 것을 의미하지는 않습니다. Azure는 AKS에 필요한 관리 및 인프라 수준이 필요하지 않은 포트폴리오 내에서 워크로드를 실행하는 다양한 솔루션을 제공합니다. 다음 솔루션은 각각 계획에 대한 이 접근 방식을 따릅니다.

복잡성이 증가하지 않으리라 예상되고 이러한 솔루션의 목적과 제한에 부합하는 워크로드가 포함된 컨테이너에 대해서는 더 간단한 솔루션을 사용하는 것이 좋습니다.

퍼블릭 클라우드에서 사용자 지정 런타임 및 작업으로 표준화된 오케스트레이션

완전 관리형 PaaS 플랫폼에서 실행할 수 없고 인프라 수준 컨트롤에서 릴레이해야 하는 워크로드, 컨테이너 오케스트레이터에서 제공하는 것과 같은 고급 배포 기능을 사용하려는 워크로드, 또는 모듈식 복잡성이 증가할 것으로 예상되는 워크로드의 경우, AKS(Azure Kubernetes Service)로 전환합니다. AKS는 컨테이너 호스팅을 모두 해결하지만 광범위한 아키텍처, SRE, 보안, 배포, 모니터링 및 인프라 옵션도 제공합니다.

플랫폼의 기능 집합은 클러스터 운영자 수준과 워크로드 수준에서 플랫폼을 학습해야 하는 요구 사항과 함께 제공됩니다. 운영 팀, 아키텍처 팀, 워크로드 엔지니어링 팀의 교육을 마이그레이션 타임라인에 반영합니다. 또한 AKS는 플랫폼이므로 워크로드 팀은 이 플랫폼 내의 책임 분리와 현재의 호스팅 배열을 비교하여 이해해야 합니다. 어떤 면에서는 유사할 수 있지만, 다른 면에서는 완전히 새로울 수도 있습니다.

퍼블릭 클라우드의 사용자 지정된 오케스트레이션, 런타임 및 작업

매우 특수한 워크로드나 조직의 구체적 요구 사항이 있을 경우 Azure는 컨테이너 오케스트레이션 공간에 다른 두 가지 주요 플랫폼을 제공합니다.

Azure Red Hat OpenShift
Azure Service Fabric

대안을 탐색할 이유가 있는 경우 모든 플랫폼 옵션의 이점과 장단점을 이해하는 데 시간을 할당해야 합니다. Azure의 기본 솔루션은 AKS이며, 이 설명서에서는 AKS가 선택된 기술이라고 가정합니다.

클라우드 플랫폼 전체에서 작업 표준화

고객은 프라이빗 클라우드, 에지 및 퍼블릭 클라우드 환경에 서로 다른 컨테이너 오케스트레이터를 배포하는 경우가 많습니다. 이러한 서로 다른 클라우드 플랫폼에서 작업을 표준화하기 위해 고객은 클라우드 작업 도구를 여러 클라우드 플랫폼으로 확장하여 통일된 작업 방식을 통합할 수 있습니다.

Azure에서 조직은 서로 다른 컨테이너 호스트를 Kubernetes용 Azure Arc에 온보딩하여 다양한 오케스트레이터에서 작업을 표준화할 수 있습니다. 이 도구는 각 컨테이너 호스트에서 일관된 모니터링, 작업 및 거버넌스를 보장합니다.

프라이빗 클라우드 및 에지 환경의 애플리케이션 런타임

워크로드를 프라이빗 클라우드 또는 에지 환경에서 실행해야 하지만 워크로드가 PaaS 런타임에서 가장 잘 지원되는 경우 개발자가 Azure App Service를 사용하여 일관된 PaaS 런타임 위에 빌드할 수 있는 몇 가지 도구가 있습니다.

Azure Stack HCI: Azure Stack 운영자가 관리하는 Azure Stack에서 기본적으로 Azure App Service를 호스팅할 수 있도록 허용합니다.
AKS용 Azure Stack HCI: 다른 Kubernetes 솔루션으로의 이식성을 허용하기 위해 Azure Stack 및 AKS 운영자가 관리하는 Azure Stack 내의 AKS에서 실행하는 사용자 지정 런타임을 호스팅할 수 있도록 허용합니다.
Azure Arc를 사용하는 Kubernetes의 Azure App Service: 모든 Kubernetes 호스트가 Azure에서 애플리케이션 서비스를 제공할 수 있도록 허용합니다. 모든 호스트가 Azure App Service의 작은 인스턴스가 됩니다. 각 호스트는 Azure Arc에도 온보딩되므로 해당 호스트를 일관된 클라우드 기반 호스트 작업을 통해 관리할 수도 있습니다.

다음 단계: 환경 또는 Azure 랜딩 존 검토

다음 문서 목록을 선택하면 클라우드 채택 시나리오를 성공할 수 있도록 클라우드 채택 과정의 해당 지점에 대한 지침으로 이동합니다.

다음을 통해 공유