Google Cloud의 .NET Framework 애플리케이션을 위한 현대화 여정

Last reviewed 2023-07-13 UTC

이 문서에서는 모놀리식 애플리케이션의 일반적인 제한사항을 살펴보고 이를 현대화하기 위한 점진적이지만 구조화된 프로세스를 설명합니다.

이 문서는 Windows 및 .NET 에코시스템에 익숙하고 현대화가 무엇인지 자세히 알고 싶어하는 클라우드 설계자, 시스템 관리자, CTO를 대상으로 합니다. 이 문서에서는 커스텀 빌드된 서버 애플리케이션(예: ASP.NET 또는 Windows 서비스 애플리케이션)에 중점을 두고 있지만 다른 사용 사례에도 이 문서 내용을 적용할 수 있습니다.

기존 애플리케이션과 최신 애플리케이션 비교: 현대화하는 이유

기존 애플리케이션을 현대화하는 것은 마치 여행을 하는 것과 같습니다. 이러한 여행의 시작과 끝, 얻게 되는 이점은 애플리케이션의 상태와 현대화에 투자할 수 있는 시간과 노력에 따라 크게 달라집니다.

.NET Framework 애플리케이션과 관련하여 기존현대적의 개념은 명확하지 않습니다. 애플리케이션마다 기존 및 현대화 니즈가 다릅니다. 그러나 기존 애플리케이션에는 몇 가지 일반적인 제한사항이 있습니다.

다음 다이어그램은 기존 애플리케이션과 최신 클라우드 기반 애플리케이션의 특성을 요약합니다.

모놀리식 및 최신 클라우드 기반 애플리케이션의 차이점

기존 .NET Framework 애플리케이션은 일반적으로 .NET Framework에서 빌드되고 온프레미스 Microsoft Windows 서버에서 호스팅되며 Microsoft SQL Server를 실행하는 온프레미스 서버에 연결되는 모놀리식입니다. 아키텍처의 세부정보는 이러한 일반적인 특성과 다를 수 있지만 대부분의 모놀리식 애플리케이션에는 다음과 같은 제한사항이 있습니다.

  • Windows 및 SQL Server를 실행하는 온프레미스 서버를 관리해야 함
  • Windows의 종속 항목과 관련된 배포 환경과 라이선스 비용 제한
  • 모놀리식 아키텍처에서 빌드된 기존 애플리케이션 업그레이드가 어려움
  • 온프레미스 리소스로 계획하고 예산을 책정하고 확장할 수 있는 민첩성 부족

클라우드 기반 아키텍처용으로 빌드된 애플리케이션은 다음과 같은 몇 가지 이점을 제공합니다.

  • 관리형 서비스와 통합하여 관리 오버헤드 최소화
  • .NET 및 컨테이너와의 완전한 이동성과 Windows 종속 항목 또는 라이선스 비용 없음
  • 독립적으로 배포할 수 있는 마이크로서비스를 기반으로 한 고속 업그레이드 경로
  • 서버리스 아키텍처로 확장 및 예산에 대한 완벽한 민첩성

기존의 온프레미스 방식과 비교할 때 클라우드 아키텍처는 애플리케이션을 보다 경제적이고 효율적이며 탄력적으로 실행할 수 있는 방법을 제공합니다. 클라우드 기반 방식에서는 애플리케이션의 배포 위치와 시기를 더 유연하게 선택할 수 있습니다.

현대화 경로

클라우드 기반 아키텍처의 이점은 명확하지만 클라우드의 경로는 명확하지 않을 수 있습니다. 기존 .NET Framework 아키텍처에서 클라우드 기반 아키텍처로의 현대화는 모든 경우에 적합한 단일 패턴을 따르지 않습니다. 다음 다이어그램에서 알 수 있듯이 현대화에는 일련의 단계가 포함되어 있으며, 각 단계에서 제한사항을 제거하고 애플리케이션 기능을 향상시키며 이후의 현대화 기회가 열립니다.

현대화 프로세스와 관련된 프로세스, 기술, 서비스

현대화 단계는 다음과 같은 3단계로 구성됩니다.

  1. 클라우드에서 다시 호스팅(리프트 앤 시프트라고도 함)
  2. 플랫폼 변경
  3. 아키텍처 재구축 및 다시 빌드

현대화 사전 평가 및 학습

현대화하기 전에 준비해야 합니다. 첫 번째 단계에서는 애플리케이션과 애플리케이션의 종속 항목을 평가하여 현대화에 적합한 애플리케이션과 변경하거나 이동할 수 없는 애플리케이션(일반적으로 기존 관련 또는 규제상의 이유로)을 결정합니다. 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 검색을 참조하세요.

이 평가와 함께 팀에서 클라우드의 기능을 학습해야 합니다. Google Cloud는 학습 프로세스 속도를 높이는 데 유용한 인증, 기술 가이드, Windows 전용 및 .NET 전용 Codelab을 제공합니다.

현대화할 애플리케이션을 식별한 후 기존 애플리케이션을 그대로 또는 애플리케이션 코드 또는 구성을 최소한으로 변경하여 마이그레이션할 수 있습니다.

1단계: 클라우드에서 다시 호스팅

첫 번째 단계의 주요 목표는 온프레미스 리소스에서 클라우드 인프라로 서버 관리 부담을 이전하는 것입니다. 이 단계에서는 이후 단계에서 인프라를 클라우드에 맞게 최적화할 수 있도록 인프라가 클라우드를 지원하는지 확인합니다.

수동 마이그레이션과 도구 기반 마이그레이션 비교

Windows 기반 .NET Framework 애플리케이션의 리프트 앤 시프트는 일반적으로 온프레미스 Windows Server 및 SQL Server 인스턴스를 Compute Engine 가상 머신(VM) 인스턴스로 이동하면서 시작합니다. 이 프로세스를 수동으로 수행하거나 마이그레이션 도구를 사용하여 자동화할 수 있습니다.

수동 마이그레이션에서는 Compute Engine Windows Server 이미지를 사용하여 인스턴스를 시작할 수 있습니다. Google Cloud Marketplace에는 IIS, SQL, Express, ASP.NET이 포함된 Windows Server VM을 가져오는 ASP.NET Framework 솔루션과 같이 Compute Engine에 배포할 수 있는 솔루션도 있습니다.

마찬가지로, SQL Server 이미지에서 SQL Server 인스턴스를 시작하거나 관리형 솔루션(예: SQL Server용 Cloud SQL)로 직접 이동할 수 있습니다.

또한 Google Cloud는 온프레미스 VMware VM에서 Google Cloud의 VMware 환경으로 이동하는 데 유용한 Migrate to Virtual Machines 또는 VMware Engine과 같은 마이그레이션 도구를 제공합니다.

VM을 구성한 후에는 일반적으로 요청 시 새 인스턴스를 다시 만들 수 있도록 커스텀 VM 이미지를 만듭니다. 이 단계는 이 문서의 뒷부분에서 설명하는 인스턴스 템플릿에도 중요합니다.

클라우드에 도메인 서비스가 필요하면 Virtual Private Cloud(VPC)를 사용하여 Compute Engine에서 내결함성 Microsoft Active Directory 환경을 배포하거나 직접 Microsoft Active Directory용 관리형 서비스로 이동하면 됩니다.

온프레미스 및 클라우드 연결

VM을 클라우드로 마이그레이션할 때 일부 워크로드를 온프레미스로 유지하는 것이 일반적입니다. 예를 들어 기존 하드웨어 또는 소프트웨어가 필요한 애플리케이션이 있거나 규정 준수 및 지역 규제 기관 요구사항을 충족해야 하는 경우가 있습니다. 온프레미스 및 클라우드 리소스를 안전하게 연결하려면 VPN 또는 상호연결 솔루션이 필요합니다. 이 연결을 만들고 관리하는 다양한 방법과 하이브리드 클라우드 및 온프레미스 워크로드의 기타 영향은 Google Cloud로 마이그레이션: 기반 구축하기를 참조하세요.

초기 이점

1단계가 종료되면 클라우드에서 기본 인프라가 실행되고 다음과 같은 이점을 제공합니다.

  • 비용 최적화. 커스텀 머신 유형(CPU, 메모리, 스토리지)을 만들고 사용한 만큼만 비용을 지불할 수 있습니다. VM 및 재해 복구 환경을 시작 및 중지하고 실행 중인 경우에만 비용을 지불합니다. 마이그레이션하기 전에 적합한 권장 사항을 확인합니다.
  • 운영 효율성 증가. VM에 영구 디스크를 연결하고 스냅샷을 만들어 백업 및 복원을 간소화할 수 있습니다.
  • 안정성 증가. 라이브 마이그레이션 기능으로 인해 더 이상 유지보수 기간을 예약할 필요가 없습니다.

이러한 초기 이점은 유용하지만 클라우드에 최적화를 시작하면 더 많은 이점을 얻을 수 있습니다.

2단계: 플랫폼 변경

플랫폼을 변경하면 애플리케이션 아키텍처를 변경하지 않고 코드베이스를 최소한으로 변경하여 애플리케이션 구성요소(예: 데이터베이스, 캐싱 레이어 또는 스토리지 시스템)를 업그레이드하여 애플리케이션을 최적화합니다. 2단계 목표는 애플리케이션을 크게 재구성하거나 VM 환경을 벗어나지 않고 클라우드 기능을 사용하여 애플리케이션의 관리, 탄력성, 확장성, 유연성을 높이는 것입니다.

Compute Engine 활용

Compute Engine은 탐색에 유용한 몇 가지 표준 기능을 제공합니다. 예를 들어 Compute Engine의 인스턴스 템플릿을 사용하여 기존 VM 구성에서 템플릿을 만들 수 있습니다. 인스턴스 그룹은 애플리케이션의 성능과 중복성을 효율적으로 확장할 수 있게 하는 동일한 VM의 일부입니다. 간단한 부하 분산과 중복성 이외에도 관리형 인스턴스 그룹에는 확장성 기능(예: 자동 확장), 고가용성 기능(예: 자동 복구, 리전 배포), 안전성 기능(예: 자동 업데이트)이 있습니다.

이러한 기능을 사용하면 애플리케이션을 완전히 재구성할 필요 없이 VM 환경에 그대로 유지하면서 애플리케이션의 복원력, 중복성, 가용성을 높일 수 있습니다.

인플레이스(in-place) 교체 찾기

애플리케이션을 클라우드로 이전할 때 Cloud Marketplace의 Google 및 타사 파트너에서 관리하는 클라우드 옵션으로 호스팅된 인프라를 교체할 수 있는 기회를 찾아야 합니다. 이러한 기회는 다음과 같습니다.

  • 자체 호스팅된 SQL Server, MySQL 또는 Postgres 대신 Cloud SQL. Cloud SQL을 사용하면 Windows 라이선스의 요구사항을 제거하는 추가 이점을 활용하여 인프라 관리(예: 보안을 위해 데이터베이스 VM 패치 또는 백업 관리) 대신 데이터베이스 관리에 집중할 수 있습니다.
  • 자체 호스팅된 Active Directory 대신 Microsoft Active Directory용 관리형 서비스
  • 자체 호스팅된 Redis 인스턴스 대신 Memorystore

이러한 교체에는 코드 변경이 필요 없고 구성을 최소한으로만 변경하면 되므로 최소한의 관리, 강화된 보안, 확장성의 이점을 누릴 수 있습니다.

Windows 컨테이너 첫 번째 단계

클라우드의 기본 기능을 최적화한 후 VM에서 컨테이너로 이전을 시작할 수 있습니다.

컨테이너는 애플리케이션과 모든 종속 항목이 포함된 가벼운 패키지입니다. VM에서 직접 애플리케이션 실행과 비교 시 컨테이너를 사용하면 다양한 환경에서보다 일관되고 예측 가능하며 효율적인 방식으로 애플리케이션을 실행할 수 있습니다(특히 동일한 호스트에서 여러 컨테이너를 실행할 경우). Kubernetes, Istio, Knative와 같은 컨테이너 전반의 생태계는 단일 모놀리식에서 일련의 집중화된 마이크로서비스로 애플리케이션의 변환을 더욱 가속화할 수 있는 다양한 관리, 탄력성, 모니터링 기능도 제공합니다.

한동안 컨테이너화는 Linux 전용 기능이었습니다. Windows 애플리케이션은 컨테이너의 이점을 누릴 수 없습니다. 이는 Windows 컨테이너와 이후 KubernetesGoogle Kubernetes Engine(GKE)에서 지원으로 변경되었습니다.

Windows 컨테이너는 .NET Framework 애플리케이션을 .NET으로 마이그레이션하지 않고 컨테이너의 이점(예: 민첩성, 이동성, 제어)을 원하는 경우에 사용할 수 있는 옵션입니다. .NET Framework 버전에 따라 타겟팅할 적절한 OS를 선택해야 하며 Windows 컨테이너에서 모든 Windows 스택이 지원되는 것은 아닙니다. 이 방식과 대안의 제한사항은 이 문서 뒷부분의 .NET 및 Linux 컨테이너를 참조하세요.

.NET Framework 애플리케이션을 Windows 컨테이너로 컨테이너화한 후에는 Kubernetes 클러스터에서 실행하는 것이 좋습니다. Kubernetes는 컨테이너 포드가 다운 및 재생성되고, 포드를 자동 확장하고, 출시 또는 롤백, 상태 확인을 자동화할 시기를 감지하는 등과 같은 표준 기능을 제공합니다. GKE는 클러스터 자동 확장, 리전 클러스터, 가용성이 높은 제어 영역, GKE Enterprise의 하이브리드 및 멀티 클라우드 지원과 같은 기능을 추가합니다. GKE 또는 GKE Enterprise를 사용하려는 경우 Migrate to Containers를 사용하여 Windows VM을 컨테이너로 마이그레이션하는 작업을 간소화하고 가속화할 수 있습니다. Migrate to Containers는 애플리케이션을 재작성하거나 재설계할 필요 없이 VM의 애플리케이션을 컨테이너로 추출하는 작업을 자동화합니다.

Compute Engine의 올바른 기능을 사용하면 많은 이점을 누릴 수 있지만 컨테이너와 GKE로 이동하면 동일한 VM에 여러 포드를 압축하여 VM을 최대한으로 사용할 수 있습니다. 이 전략을 사용하면 VM 수가 줄어들고 Windows 라이선스 비용이 낮아질 수 있습니다.

Kubernetes 및 GKE를 사용하여 Windows 컨테이너와 Linux 컨테이너 모두를 선언적으로 관리하면 인프라 관리가 간소화될 수도 있습니다. 컨테이너화가 준비되면 팀은 다음 현대화 단계를 준비합니다.

3단계: 재설계 및 다시 빌드

플랫폼 변경은 클라우드의 완전한 이점을 얻기 위한 시작일 뿐입니다. 아키텍처를 클라우드 기반 플랫폼으로 변환하면 다음과 같은 몇 가지 이점이 있습니다.

관리형 서비스로 이동

애플리케이션의 일부를 다시 작성하기 시작하면 호스팅된 서비스에서 관리형 서비스로 이동하는 것이 좋습니다. 예를 들어 다음을 사용할 수 있습니다.

애플리케이션을 이러한 서비스와 통합하려면 추가 코드가 필요하지만 플랫폼 관리 부담을 Google Cloud로 이전하므로 투자 가치가 있습니다. Google Cloud .NET 라이브러리, Visual Studio용 Tools, Visual Studio Code용 Cloud Code를 사용하면 .NET 생태계와 도구를 유지하면서 이러한 서비스와 통합할 수 있습니다.

또한 관리형 서비스는 애플리케이션 작업을 지원할 수 있습니다. Cloud Logging에 애플리케이션 로그를 저장하고 애플리케이션 측정항목을 Cloud Monitoring으로 보낼 수 있습니다. 여기서 서버와 애플리케이션 측정항목으로 대시보드를 빌드할 수 있습니다. Google Cloud는 Cloud Logging, Cloud Monitoring, Cloud Trace 용 .NET 클라이언트 라이브러리를 제공합니다.

.NET 및 Linux 컨테이너

애플리케이션이 Windows에서만 실행되는 기존 .NET Framework 애플리케이션인 경우 Compute Engine의 Windows 서버 또는 GKE의 Windows Server 컨테이너에서 계속 실행되도록 할 수 있습니다. 단기적으로는 이 방식이 효과가 있을 수 있지만 장기적으로는 심각한 제한사항이 있을 수 있습니다. Windows는 Linux보다 라이선스 비용과 전체 리소스 사용 공간이 더 많으므로 장기적으로 소유 비용이 증가할 수 있습니다.

.NET의 가장 중요한 측면 중 하나는 멀티 플랫폼입니다. .NET 애플리케이션을 Linux 컨테이너로 컨테이너화할 수 있습니다. Linux 컨테이너는 Windows 컨테이너보다 가벼우며 더 많은 플랫폼에서 더욱 효율적으로 실행됩니다. 이 요소는 .NET 애플리케이션의 배포 옵션을 만들고 Windows에 대한 종속 항목과 이와 관련된 라이선스 비용을 없애줍니다.

.NET Framework 애플리케이션을 .NET으로 포팅

.NET으로 전환하는 좋은 방법은 .NET Framework에서 .NET으로 포팅 개요를 참조하세요. .NET 이동성 분석기플랫폼 호환성 분석기와 같은 도구를 사용하면 어셈블리와 API가 이동식인지 확인할 수 있습니다. dotnet try-convert와 같은 다른 포팅 도구가 유용할 수 있습니다.

외부 도구를 사용하면 호환성 문제를 파악하고 먼저 마이그레이션할 구성요소를 결정할 수 있습니다. 결국 .NET 프로젝트를 만들고 .NET Framework 코드를 점진적으로 새 프로젝트로 이동하고 이 과정에서 비호환성을 수정해야 합니다. 코드를 포팅하기 전에 테스트를 수행하고 포팅한 후에 기능을 테스트하는 것이 중요합니다. 이전 코드와 새 코드를 테스트하려면 A/B 테스트를 사용하는 것이 좋습니다. A/B 테스트를 사용하면 일부 사용자를 새 애플리케이션으로 안내하는 동시에 기존 애플리케이션을 계속 실행할 수 있습니다. 이 방식을 사용하면 새 애플리케이션의 출력, 확장성, 탄력성을 테스트할 수 있습니다. A/B 테스트를 지원하기 위해 Google Cloud는 전역 외부 애플리케이션 부하 분산기와 같은 부하 분산 솔루션을 제공합니다.

문화 혁신

.NET Framework 및 Windows 서버에서 .NET 및 Linux 컨테이너로의 변환은 기술적인 문제가 아닙니다. 이러한 변화에는 조직의 문화 혁신이 필요합니다. Windows 전용 환경을 사용할 수 있는 직원은 멀티 플랫폼 환경을 채택해야 합니다. 이러한 문화적 변환에는 .NET, Linux, 컨테이너 도구(예: Docker 및 Kubernetes)를 학습시킬 시간과 예산이 필요합니다. 그러나 Windows 전용 플랫폼에서 멀티 플랫폼 조직으로 변환하면 더 큰 일련의 도구와 기술에 액세스할 수 있습니다.

모놀리식 분해

.NET Framework에서 .NET으로 이동하면 다음을 포함한 몇 가지 문제가 발생할 수 있습니다.

  • .NET에서 전체 애플리케이션을 다시 작성하나요?
  • 애플리케이션을 더 작은 서비스로 분할하여 .NET에서 작성하나요?
  • .NET에서만 새 서비스를 작성하나요?

이러한 질문을 고려할 때는 각 방식의 이점, 시간, 비용을 고려해야 합니다. 모든 것을 한 번에 재작성하지 않는 균형 잡힌 방식을 취하는 것이 좋습니다. 대신 가능한 경우 .NET에서 새 서비스를 작성하고 기존 모놀리식을 .NET에서 더 작은 서비스로 분할할 수 있습니다. 계획 시 다음 문서가 도움이 될 수 있습니다.

.NET 컨테이너용 배포 옵션

Google Cloud에 .NET 앱 배포 상태에 따라 Google Cloud에 .NET 컨테이너를 배포하는 옵션이 다릅니다. 모놀리식 애플리케이션을 마이크로서비스로 분해할 때 마이크로서비스의 아키텍처와 설계에 따라 호스팅 솔루션을 두 개 이상 사용할 수 있습니다.

다음 질문에 답하면 최적의 호스팅 전략을 결정하는 데 도움이 됩니다.

  • 어떤 애플리케이션이 트리거되나요? 모든 호스팅 솔루션은 표준 HTTP(S)에 적합하지만 프로토콜이 TCP/UDP 또는 독점 프로토콜이면 GKE만 사용할 수 있습니다.
  • 애플리케이션에 특정 하드웨어가 필요한가요? Cloud Run은 각 요청에 합리적이지만 제한된 양의 RAM과 CPU를 제공합니다. Cloud Run for Anthos는 GPU, 추가 메모리, 디스크 공간과 같은 추가적인 맞춤설정 옵션을 제공합니다.
  • 확장 기대치가 어떻게 되나요? 애플리케이션에 비활성 기간이 있으면 Cloud Run과 같은 서버리스 솔루션은 0으로 축소 가능한 옵션을 제공할 수 있습니다.
  • 지연 시간은 얼마나 중요하며 애플리케이션에서 콜드 스타트를 어느 정도 허용합니까? 콜드 스타트에 대한 톨러레이션(toleration)이 낮으면 다음 옵션 중 하나를 고려해야 합니다.

각 호스팅 환경에 대한 문서를 읽고 기능, 장단점, 가격 모델을 이해하는 것이 좋습니다.

일반적으로 HTTP 요청을 제공하는 마이크로서비스를 만들려면 가능할 때 Cloud Run에 배포하고 Kubernetes 생태계에 있으려 하거나 더 많은 맞춤설정 옵션이 필요하면 GKE로 변경해야 합니다. 큐에서 리슨하는 프로세스 또는 HTTP(S) 이외의 프로토콜을 사용하는 애플리케이션과 같이 장기 실행 프로세스가 있는 경우 GKE가 기본적으로 선택됩니다.

Cloud Functions도 적절한 서버리스 배포 옵션이지만 Cloud Run에서 Cloud Functions가 제공하는 대부분의 기능을 제공하며 Cloud Functions는 모든 .NET 버전을 지원하지 않으므로 여기에서는 설명하지 않습니다.

Kubernetes 및 GKE

컨테이너 최적화 환경에서 실행하려는 경우 방식에 Kubernetes 및 관리형 버전인 GKE가 관련될 수 있습니다. 특히 서로 다른 요구사항에 따라 여러 컨테이너를 배포하고 각 컨테이너 배포 및 관리 방법에 대한 세부적인 제어를 원하는 경우에 Kubernetes 및 GKE를 적용할 수 있습니다.

Kubernetes는 컨테이너를 대규모로 실행하도록 설계되었으며 포드, 서비스, 배포, 복제본 세트와 같은 빌드 블록을 제공합니다. 이러한 구성을 제대로 이해하고 사용하는 것은 어려울 수 있지만 대부분의 컨테이너 관리 부담을 Kubernetes로 이전할 수 있습니다. 또한 마이크로서비스가 서비스 뒤에 부하 분산된 포드 집합이 있는 배포인 마이크로서비스 아키텍처에도 적합합니다.

Kubernetes 외에 GKE는 컨테이너 격리 및 비공개 레지스트리와 같은 Kubernetes 관리 및 보안 기능이 간소화되도록 클러스터 자동 확장, 자동 복구, 자동 업그레이드와 같은 기능을 제공합니다. GKE의 클러스터 내 각 노드에 비용이 청구되지만 GKE는 스팟 VM을 지원하여 비용을 절감합니다.

GKE는 Windows 컨테이너와 Linux 컨테이너를 모두 관리할 수 있습니다. 이 기능은 Windows 기반 및 최신 Linux 기반 애플리케이션 모두에 단일 하이브리드 환경을 유지하려는 경우에 유용합니다.

Knative 및 Cloud Run

스테이트리스(Stateless) .NET 컨테이너의 경우 Knative와 관리형 버전인 Cloud Run은 서버리스 컨테이너 환경을 제공합니다. 서버리스 컨테이너는 인프라 관리 오버헤드 없이 프로비저닝, 자동 확장, 부하 분산과 같은 이점을 제공합니다.

Kubernetes 클러스터에 컨테이너를 배포하는 경우 Knative는 Kubernetes보다 더 높은 수준의 작은 API 표면을 제공합니다. 따라서 Knative를 사용하면 Kubernetes의 복잡성이 방지되어 컨테이너를 더욱 쉽게 배포할 수 있습니다.

Cloud Run은 Knative API를 따르지만 Google 인프라에서 실행되므로 Kubernetes 클러스터가 필요하지 않습니다. Cloud Run은 컨테이너에 서버리스 옵션을 제공합니다. 기본적으로 Cloud Run에서 컨테이너는 요청 기간 동안 자동 확장되고 비용이 청구됩니다. 배포 시간은 초 단위입니다. 또한 Cloud Run은 버전 및 트래픽 분할과 같은 유용한 기능을 제공합니다.

Cloud Run for Anthos는 Knative의 단순성과 Kubernetes를 유연하게 운영할 수 있는 Cloud Run을 원하는 고객을 위한 더욱 유연한 Cloud Run 버전입니다. 예를 들어 GKE Enterprise 기반 Cloud Run을 사용하면 컨테이너를 실행 중인 기본 인스턴스에 GPU를 추가하거나 동일 VPC에 있는 다른 VM 또는 GKE 클러스터에 액세스할 수 있습니다.

Cloud Run은 Pub/Sub, Cloud Scheduler, Cloud Tasks와 같은 다른 서비스 및 Cloud SQL과 같은 백엔드와 통합됩니다. 자동 확장 웹 프런트엔드 또는 이벤트에 의해 트리거되는 내부 마이크로서비스 모두에 사용될 수 있습니다.

작업 현대화

현대화는 애플리케이션 코드 뿐만이 아닙니다. 애플리케이션의 전체 수명 주기, 즉 빌드, 테스트, 배포, 모니터링 방식에 적용됩니다. 따라서 현대화를 생각하는 경우 작업을 고려해야 합니다.

Cloud Build를 사용하면 애플리케이션의 빌드-테스트-배포주기를 현대화 및 자동화할 수 있습니다. Cloud Build는 .NET용 빌더를 제공할 뿐만 아니라 Artifact Registry의 취약점 스캐너Binary Authorization과 통합하여 알 수 없는 소스 코드나 안전하지 않은 저장소에서 빌드된 이미지가 배포 환경에서 실행되지 않도록 합니다.

Google Cloud Observability(이전에는 Stackdriver)는 애플리케이션의 관측 가능성을 현대화할 수 있는 여러 가지 서비스를 제공합니다.

Google.Cloud.Diagnostics.AspNetCore 라이브러리를 사용하여 ASP.NET 애플리케이션의 로그, 측정항목, trace를 Google Cloud로 내보낼 수 있습니다. OpenTelemetry 측정항목을 Google Cloud로 내보내려면 OpenTelemetry.Exporter.Stackdriver 라이브러리를 사용하면 됩니다.

현대화가 팀 프로세스와 문화에 적용되는 방식에 대한 자세한 내용은 DevOps용 Google Cloud 솔루션을 참조하세요.

다음 단계