이 페이지는 Cloud Translation API를 통해 번역되었습니다.

AWS에서 Google Cloud로 마이그레이션: AWS Lambda에서 Cloud Run으로 마이그레이션

Last reviewed 2024-10-21 UTC

Google Cloud는 Amazon Web Services(AWS) Lambda에서 Google Cloud로 서버리스 워크로드를 마이그레이션하는 데 도움이 되는 도구, 제품, 안내, 전문 서비스를 제공합니다. Google Cloud에서는 서버리스 애플리케이션을 개발하고 배포할 수 있는 여러 서비스를 제공하지만 이 문서에서는 서버리스 런타임 환경인 Cloud Run으로의 이전에 중점을 둡니다. AWS Lambda와 Cloud Run은 자동 리소스 프로비저닝, 클라우드 제공업체의 확장, 사용량 기반 가격 책정 모델과 같은 유사점을 공유합니다.

이 문서는 AWS Lambda에서 Cloud Run으로 서버리스 워크로드를 마이그레이션하는 계획을 설계, 구현, 검증하는 데 도움이 됩니다. 또한 이러한 이전의 잠재적 이점과 절차를 평가하는 사용자를 위한 안내도 제공합니다.

이 문서는 AWS에서 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부로서 이 시리즈에는 다음 문서가 포함됩니다.

비즈니스 로직에 적합한 서버리스 런타임 환경을 선택하는 방법에 관한 자세한 내용은 관리형 컨테이너 런타임 환경 선택을 참고하세요. AWS와 Google Cloud 서비스 간의 포괄적인 매핑은 AWS 및 Azure 서비스와 Google Cloud 서비스 비교를 참고하세요.

Google Cloud로의 마이그레이션의 경우 Google Cloud로 마이그레이션: 시작하기에 설명된 마이그레이션 프레임워크를 따르는 것이 좋습니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

일련의 반복 작업을 통해 원본 환경에서 Google Cloud로 마이그레이션할 수 있습니다. 예를 들어 일부 워크로드를 먼저 마이그레이션하고 나중에 다른 워크로드를 마이그레이션할 수 있습니다. 개별 마이그레이션을 반복할 때마다 일반 마이그레이션 프레임워크 단계를 수행합니다.

워크로드와 데이터를 평가하고 탐색합니다.
Google Cloud에 대한 기초를 계획하고 빌드합니다.
워크로드와 데이터를 Google Cloud로 마이그레이션합니다.
Google Cloud 환경을 최적화합니다.

이 프레임워크 단계에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

효과적인 마이그레이션 계획을 설계하려면 계획의 각 단계를 검증하고 롤백 전략이 있는지 확인하는 것이 좋습니다. 마이그레이션 계획을 검증하려면 Google Cloud로 마이그레이션: 마이그레이션 계획 검증 권장사항을 참조하세요.

서버리스 워크로드를 이전하는 작업은 한 클라우드 제공업체에서 다른 클라우드 제공업체로 함수를 이동하는 것 이상을 의미하는 경우가 많습니다. 클라우드 기반 애플리케이션은 상호 연결된 서비스 웹을 사용하므로 AWS에서 Google Cloud로 이전하려면 종속 AWS 서비스를 Google Cloud 서비스로 대체해야 할 수 있습니다. 예를 들어 Lambda 함수가 Amazon SQS 및 Amazon SNS와 상호작용하는 시나리오를 생각해 보세요. 이 함수를 이전하려면 유사한 기능을 구현하기 위해 Pub/Sub 및 Cloud Tasks를 채택해야 할 수 있습니다.

또한 이전은 서버리스 애플리케이션의 아키텍처와 설계 결정을 꼼꼼하게 검토할 수 있는 좋은 기회입니다. 이 검토를 통해 다음과 같은 기회를 발견할 수 있습니다.

Google Cloud 기본 제공 기능으로 최적화: Google Cloud 서비스가 고유한 이점을 제공하는지 또는 애플리케이션 요구사항에 더 적합한지 살펴보세요.
아키텍처 간소화: 기능을 통합하거나 Google Cloud 내에서 서비스를 다르게 사용하여 간소화할 수 있는지 평가합니다.
비용 효율성 개선: Google Cloud에서 제공되는 인프라에서 리팩터링된 애플리케이션을 실행할 때의 잠재적 비용 차이를 평가합니다.
코드 효율성 개선: 이전 프로세스와 함께 코드를 리팩터링합니다.

전략적으로 이전을 계획합니다. 이전을 리호스트 (리프트 앤 시프트) 작업으로 보지 마세요. 이전을 계기로 서버리스 애플리케이션의 전반적인 디자인과 코드 품질을 개선하세요.

원본 환경 평가

평가 단계에서는 원본 환경을 Google Cloud로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

평가 단계는 마이그레이션의 성공에 매우 중요합니다. 마이그레이션하려는 워크로드, 요구사항, 종속 항목, 현재 환경에 대해 자세히 알고 있어야 합니다. Google Cloud 마이그레이션을 성공적으로 계획하고 실행하려면 시작점을 이해해야 합니다.

평가 단계는 다음 작업으로 구성됩니다.

워크로드의 포괄적인 인벤토리를 빌드합니다.
워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
팀에 Google Cloud 교육을 실시합니다.
Google Cloud에서 실험 및 개념 증명을 빌드합니다.
대상 환경의 총 소유 비용(TCO)을 계산합니다.
워크로드에 적합한 마이그레이션 전략을 선택합니다.
마이그레이션 도구를 선택합니다.
마이그레이션 계획 및 타임라인을 정의합니다.
마이그레이션 계획을 검증합니다.

평가 단계와 이러한 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요. 다음 섹션은 해당 문서의 정보를 기반으로 합니다.

AWS Lambda 워크로드의 인벤토리 빌드

마이그레이션 범위를 정의하려면 인벤토리를 만들고 AWS Lambda 워크로드에 관한 정보를 수집합니다.

AWS Lambda 워크로드의 인벤토리를 빌드하려면 AWS API, AWS 개발자 도구, AWS 명령줄 인터페이스를 기반으로 하는 데이터 수집 메커니즘을 구현하는 것이 좋습니다.

인벤토리를 빌드한 후에는 인벤토리의 각 AWS Lambda 워크로드에 관한 정보를 수집하는 것이 좋습니다. 각 워크로드의 경우 잠재적인 불편을 예상하는 데 도움이 되는 측면에 집중하세요. 또한 Cloud Run으로 마이그레이션하기 전에 워크로드와 종속 항목을 수정해야 하는 경우를 파악하기 위해 워크로드를 분석합니다. 먼저 각 AWS Lambda 워크로드의 다음 측면에 관한 데이터를 수집하는 것이 좋습니다.

사용 사례 및 설계
소스 코드 저장소
배포 아티팩트
호출, 트리거, 출력
런타임 및 실행 환경
워크로드 구성
액세스 제어 및 권한
규정 준수 및 규제 요구사항
배포 및 운영 프로세스

사용 사례 및 설계

워크로드의 사용 사례와 설계에 관한 정보를 수집하면 적절한 마이그레이션 전략을 파악하는 데 도움이 됩니다. 이 정보는 마이그레이션 전에 워크로드와 종속 항목을 수정해야 하는지 여부를 파악하는 데도 도움이 됩니다. 각 워크로드에 대해 다음을 실행하는 것이 좋습니다.

워크로드가 제공하는 특정 사용 사례에 대한 통계를 얻고 다른 시스템, 리소스 또는 프로세스와의 종속 항목을 식별합니다.
워크로드의 설계 및 아키텍처를 분석합니다.
워크로드의 지연 시간 요구사항을 평가합니다.

소스 코드 저장소

AWS Lambda 함수의 소스 코드를 인벤토리화하면 Cloud Run과의 호환성을 위해 AWS Lambda 워크로드를 리팩터링해야 하는 경우에 도움이 됩니다. 이 인벤토리를 만들려면 코드베이스를 추적해야 합니다. 코드베이스는 일반적으로 Git과 같은 버전 제어 시스템이나 GitHub 또는 GitLab과 같은 개발 플랫폼에 저장됩니다. 소스 코드 인벤토리는 Cloud Run으로 이전할 때 이러한 프로세스도 업데이트해야 하므로 지속적 통합 및 지속적 개발 (CI/CD) 파이프라인과 같은 DevOps 프로세스에 필수적입니다.

배포 아티팩트

워크로드에 필요한 배포 아티팩트를 아는 것도 AWS Lambda 워크로드를 리팩터링해야 하는지 여부를 파악하는 데 도움이 되는 또 다른 구성요소입니다. 워크로드에 필요한 배포 아티팩트를 식별하려면 다음 정보를 수집합니다.

워크로드를 배포할 배포 패키지의 유형입니다.
라이브러리 및 기타 종속 항목과 같은 추가 코드가 포함된 모든 AWS Lambda 레이어
워크로드에 종속된 모든 AWS Lambda 확장 프로그램
버전 및 별칭을 지정하도록 구성한 한정자입니다.
배포된 워크로드 버전입니다.

호출, 트리거, 출력

AWS Lambda는 트리거와 같은 여러 호출 메커니즘과 동기 호출 및 비동기 호출과 같은 다양한 호출 모델을 지원합니다. 각 AWS Lambda 워크로드의 경우 트리거 및 호출과 관련된 다음 정보를 수집하는 것이 좋습니다.

워크로드를 호출하는 트리거 및 이벤트 소스 매핑
워크로드가 동기 및 비동기 호출을 지원하는지 여부입니다.
워크로드 URL 및 HTTP(S) 엔드포인트

AWS Lambda 워크로드는 다른 리소스 및 시스템과 상호작용할 수 있습니다. AWS Lambda 워크로드의 출력을 소비하는 리소스와 이러한 리소스가 출력을 소비하는 방식을 알아야 합니다. 이를 통해 다른 시스템이나 워크로드와 같이 이러한 출력에 종속될 수 있는 항목을 수정해야 하는지 여부를 판단할 수 있습니다. 각 AWS Lambda 워크로드의 경우 다른 리소스 및 시스템에 관한 다음 정보를 수집하는 것이 좋습니다.

워크로드가 이벤트를 전송할 수 있는 대상 리소스입니다.
비동기 호출에 관한 정보 레코드를 수신하는 대상입니다.
워크로드에서 처리하는 이벤트의 형식입니다.
AWS Lambda 워크로드와 확장 프로그램이 AWS Lambda API 또는 다른 AWS API와 상호작용하는 방식

작동하기 위해 AWS Lambda 워크로드는 영구 데이터를 저장하고 다른 AWS 서비스와 상호작용할 수 있습니다. 각 AWS Lambda 워크로드의 경우 데이터 및 기타 서비스에 관한 다음 정보를 수집하는 것이 좋습니다.

워크로드가 가상 프라이빗 클라우드 (VPC) 또는 기타 비공개 네트워크에 액세스하는지 여부
워크로드가 임시 데이터 저장소 및 Amazon Elastic File System (EFS)을 사용하여 영구 데이터를 저장하는 방법입니다.

런타임 및 실행 환경

AWS Lambda는 워크로드의 여러 실행 환경을 지원합니다. AWS Lambda 실행 환경을 Cloud Run 실행 환경에 올바르게 매핑하려면 각 AWS Lambda 워크로드에 대해 다음을 평가하는 것이 좋습니다.

워크로드의 실행 환경입니다.
워크로드가 실행되는 컴퓨터 프로세서의 명령 집합 아키텍처입니다.

AWS Lambda 워크로드가 언어별 런타임 환경에서 실행되는 경우 각 AWS Lambda 워크로드에 대해 다음을 고려하세요.

언어별 런타임 환경의 유형, 버전, 고유 식별자입니다.
런타임 환경에 적용한 모든 수정사항

워크로드 구성

AWS Lambda에서 Cloud Run으로 워크로드를 마이그레이션할 때 워크로드를 구성하려면 각 AWS Lambda 워크로드를 구성한 방법을 평가하는 것이 좋습니다.

각 AWS Lambda 워크로드에 대해 다음과 같은 동시 실행 및 확장성 설정에 관한 정보를 수집합니다.

동시 실행 제어
확장성 설정
사용 가능한 메모리 양과 허용되는 최대 실행 시간 측면에서 워크로드 인스턴스의 구성입니다.
워크로드에서 AWS Lambda SnapStart, 예약된 동시 실행 또는 프로비저닝된 동시 실행을 사용하여 지연 시간을 줄이고 있는지 여부입니다.
구성한 환경 변수와 AWS 람다가 구성하고 워크로드가 종속되는 환경 변수입니다.
태그 및 속성 기반 액세스 제어
예외 조건을 처리하는 상태 머신
컨테이너 이미지를 사용하는 배포 패키지의 기본 이미지 및 구성 파일 (예: Dockerfile)

액세스 제어 및 권한

평가의 일환으로 AWS Lambda 워크로드의 보안 요구사항과 액세스 제어 및 관리 측면에서 워크로드의 구성을 평가하는 것이 좋습니다. 이 정보는 Google Cloud 환경에 유사한 제어 기능을 구현해야 하는 경우에 중요합니다. 각 워크로드에 대해 다음 사항을 고려하세요.

실행 역할 및 권한
워크로드와 레이어가 다른 리소스에 액세스하는 데 사용하는 Identity and Access Management 구성입니다.
다른 계정 및 서비스가 워크로드에 액세스하는 데 사용하는 ID 및 액세스 관리 구성입니다.
거버넌스 제어

규정 준수 및 규제 요구사항

각 AWS Lambda 워크로드에 대해 다음을 수행하여 규정 준수 및 규제 요구사항을 이해해야 합니다.

워크로드가 충족해야 하는 규정 준수 및 규제 요구사항을 평가합니다.
워크로드가 현재 이러한 요구사항을 충족하는지 확인합니다.
향후 충족해야 할 요구사항이 있는지 확인합니다.

규정 준수 및 규제 요구사항은 사용 중인 클라우드 제공업체와 무관할 수 있으며 이러한 요구사항은 이전에도 영향을 미칠 수 있습니다. 예를 들어 데이터 및 네트워크 트래픽이 유럽 연합 (EU)과 같은 특정 지역의 경계 내에 있도록 해야 할 수 있습니다.

배포 및 운영 프로세스 평가

배포 및 운영 프로세스의 작동 방식을 명확하게 이해하는 것이 중요합니다. 이러한 프로세스는 프로덕션 환경과 그 환경에서 실행되는 워크로드를 준비하고 유지관리하는 관행의 중요한 부분입니다.

배포 및 운영 프로세스에서 워크로드가 작동하는 데 필요한 아티팩트를 빌드할 수 있습니다. 따라서 각 아티팩트 유형에 대한 정보를 수집해야 합니다. 예를 들어 아티팩트는 운영체제 패키지, 애플리케이션 배포 패키지, 운영체제 이미지, 컨테이너 이미지 등일 수 있습니다.

아티팩트 유형 외에도 다음 태스크를 완료하는 방법을 고려하세요.

워크로드 개발. 개발팀이 워크로드를 빌드하기 위해 마련한 프로세스를 평가합니다. 예를 들어 개발팀이 워크로드를 어떻게 설계, 코딩, 테스트하는지 평가합니다.
원본 환경에 배포하는 아티팩트 생성. 원본 환경에 워크로드를 배포하기 위해 컨테이너 이미지 또는 운영체제 이미지와 같은 배포 가능한 아티팩트를 생성하거나 소프트웨어를 설치 및 구성하여 제3자 운영체제 이미지와 같은 기존 아티팩트를 맞춤설정할 수 있습니다. 이러한 아티팩트를 생성하는 방법에 대한 정보를 수집하면 생성된 아티팩트가 Google Cloud 배포에 적합한지 확인하는 데 도움이 됩니다.
아티팩트 저장. AWS의 Artifact Registry에 저장하는 아티팩트를 생성하는 경우 Google Cloud 환경에서 아티팩트를 사용할 수 있도록 해야 합니다. 다음과 같은 전략을 사용하면 수행할 수 있습니다.
- 환경 간 통신 채널 설정: 원본 환경의 아티팩트를 대상 Google Cloud 환경에서 연결할 수 있도록 합니다.
- 아티팩트 빌드 프로세스 리팩터링: 원본 환경과 대상 환경 모두에 아티팩트를 저장할 수 있도록 원본 환경의 마이너 리팩터링을 완료합니다. 이 방식은 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하기 전에 아티팩트 저장소와 같은 인프라를 빌드하여 마이그레이션을 지원합니다. 이 접근 방식을 직접 구현하거나 통신 채널을 먼저 설정하는 이전의 접근 방식으로 빌드할 수 있습니다.
원본 환경과 대상 환경 모두에서 아티팩트를 사용할 수 있으면 마이그레이션의 일환으로 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하지 않고도 마이그레이션에 집중할 수 있습니다.
코드 스캔 및 서명. 아티팩트 빌드 프로세스의 일부로 코드 스캔을 사용하여 일반적인 취약점과 의도하지 않은 네트워크 노출을 방지하고, 코드 서명을 사용하여 신뢰할 수 있는 코드만 환경에서 실행되도록 할 수 있습니다.
원본 환경에 아티팩트 배포. 배포 가능한 아티팩트를 생성한 후 원본 환경에 배포할 수 있습니다. 각 배포 프로세스를 평가하는 것이 좋습니다. 이 평가는 배포 프로세스가 Google Cloud와 호환되는지 확인하는 데 도움이 됩니다. 또한 프로세스를 리팩터링하는 데 필요한 노력을 파악하는 데도 도움이 됩니다. 예를 들어 배포 프로세스가 원본 환경에서만 작동하는 경우 Google Cloud 환경을 타겟팅하도록 이를 리팩터링해야 할 수 있습니다.
런타임 구성 삽입. 특정 클러스터, 런타임 환경 또는 워크로드 배포에 대한 런타임 구성을 삽입할 수 있습니다. 이 구성으로 환경 변수와 보안 비밀, 사용자 인증 정보, 키와 같은 기타 구성 값이 초기화될 수 있습니다. 런타임 구성 삽입 프로세스가 Google Cloud에서 작동하는지 확인하려면 원본 환경에서 실행되는 워크로드를 구성하는 방법을 평가하는 것이 좋습니다.
로깅, 모니터링, 프로파일링. 원본 환경의 상태, 관심 측정항목, 이러한 프로세스에서 제공하는 데이터 사용 방식을 모니터링하기 위해 마련한 로깅, 모니터링, 프로파일링 프로세스를 평가합니다.
인증 원본 환경에 대해 인증하는 방법을 평가합니다.
리소스 프로비저닝 및 구성. 원본 환경을 준비하기 위해 리소스를 프로비저닝하고 구성하는 프로세스를 설계하고 구현했을 수 있습니다. 예를 들어 구성 관리 도구와 함께 Terraform을 사용하여 원본 환경에서 리소스를 프로비저닝하고 구성할 수 있습니다.

평가 완료

AWS Lambda 환경에서 인벤토리를 빌드한 후 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색에 설명된 대로 평가 단계의 나머지 활동을 완료하세요.

기반 계획 및 빌드

계획 및 빌드 단계에서는 다음을 수행하도록 인프라를 프로비저닝하고 구성합니다.

Google Cloud 환경에서 워크로드를 지원합니다.
원본 환경과 Google Cloud 환경을 연결하여 마이그레이션을 완료합니다.

계획 및 빌드 단계는 다음과 같은 태스크로 구성됩니다.

리소스 계층 구조를 빌드합니다.
Google Cloud의 Identity and Access Management(IAM)를 구성합니다.
결제 설정.
네트워크 연결을 설정합니다.
보안을 강화합니다.
로깅, 모니터링, 알림을 설정합니다.

각 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기반 계획 및 빌드를 참조하세요.

AWS Lambda 워크로드 마이그레이션

AWS Lambda에서 Cloud Run으로 워크로드를 마이그레이션하려면 다음 단계를 따르세요.

Cloud Run 환경을 설계, 프로비저닝, 구성합니다.
필요한 경우 AWS Lambda 워크로드를 Cloud Run과 호환되도록 리팩터링합니다.
배포 및 운영 프로세스를 리팩터링하여 Cloud Run에서 워크로드를 배포하고 관찰합니다.
AWS Lambda 워크로드에 필요한 데이터를 마이그레이션합니다.
기능, 성능, 비용 측면에서 마이그레이션 결과를 검증합니다.

마이그레이션 중에 문제를 방지하고 마이그레이션에 필요한 작업을 추정하려면 AWS Lambda 기능이 비슷한 Cloud Run 기능과 어떻게 비교되는지 평가하세요. AWS Lambda와 Cloud Run 기능은 서로 비교했을 때 비슷하게 보일 수 있습니다. 하지만 두 클라우드 제공업체의 기능 설계와 구현의 차이로 인해 AWS Lambda에서 Cloud Run으로 마이그레이션하는 데 상당한 영향을 줄 수 있습니다. 이러한 차이점은 다음 섹션에서 강조 표시된 대로 설계 및 리팩터링 결정에 모두 영향을 미칠 수 있습니다.

Cloud Run 환경 설계, 프로비저닝, 구성

이전 단계의 첫 번째 단계는 AWS Lambda에서 이전하는 워크로드를 지원할 수 있도록 Cloud Run 환경을 설계하는 것입니다.

Cloud Run 환경을 올바르게 설계하려면 평가 단계에서 각 AWS Lambda 워크로드에 관해 수집한 데이터를 사용하세요. 이 데이터는 다음을 수행하는 데 도움이 됩니다.

워크로드를 배포할 적절한 Cloud Run 리소스를 선택합니다.
Cloud Run 리소스 구성을 설계합니다.
Cloud Run 리소스를 프로비저닝하고 구성합니다.

적절한 Cloud Run 리소스 선택

마이그레이션할 각 AWS Lambda 워크로드에 적절한 Cloud Run 리소스를 선택하여 워크로드를 배포합니다. Cloud Run은 다음과 같은 기본 리소스를 지원합니다.

Cloud Run 서비스: 컨테이너화된 런타임 환경을 호스팅하고 고유한 엔드포인트를 노출하며 수요에 따라 기본 인프라를 자동으로 확장하는 리소스입니다.
Cloud Run 작업: 하나 이상의 컨테이너를 완료될 때까지 실행하는 리소스입니다.

다음 표는 AWS Lambda 리소스가 이러한 기본 Cloud Run 리소스에 매핑되는 방식을 요약하여 보여줍니다.

AWS Lambda 리소스	Cloud Run 리소스
웹사이트 및 웹 애플리케이션, API 및 마이크로서비스, 스트리밍 데이터 처리, 이벤트 기반 아키텍처에 사용되는 이벤트(예: 이벤트 기반 아키텍처)에 의해 트리거되는 AWS Lambda 함수입니다.	트리거로 호출할 수 있는 Cloud Run 서비스입니다.
백그라운드 작업 및 일괄 작업과 같이 실행되도록 예약된 AWS Lambda 함수	완료될 때까지 실행되는 Cloud Run 작업

Cloud Run은 서비스와 작업 외에도 이러한 기본 리소스를 확장하는 추가 리소스를 제공합니다. 사용 가능한 모든 Cloud Run 리소스에 관한 자세한 내용은 Cloud Run 리소스 모델을 참고하세요.

Cloud Run 리소스 구성 설계

Cloud Run 리소스를 프로비저닝하고 구성하기 전에 구성을 설계합니다. 리소스 한도 및 요청 시간 제한과 같은 특정 AWS Lambda 구성 옵션은 유사한 Cloud Run 구성 옵션과 비슷합니다. 다음 섹션에서는 Cloud Run에서 서비스 트리거 및 작업 실행, 리소스 구성, 보안에 사용할 수 있는 구성 옵션을 설명합니다. 또한 이 섹션에서는 Cloud Run의 구성 옵션과 유사한 AWS Lambda 구성 옵션을 강조 표시합니다.

Cloud Run 서비스 트리거 및 작업 실행

서비스 트리거와 작업 실행은 AWS Lambda 워크로드를 마이그레이션할 때 고려해야 하는 주요 설계 결정사항입니다. Cloud Run은 AWS Lambda에서 사용되는 이벤트 기반 워크로드를 트리거하고 실행하는 다양한 옵션을 제공합니다. 또한 Cloud Run은 스트리밍 워크로드 및 예약된 작업에 사용할 수 있는 옵션을 제공합니다.

워크로드를 마이그레이션할 때는 먼저 Cloud Run에서 사용할 수 있는 트리거와 메커니즘을 이해하는 것이 좋습니다. 이 정보는 Cloud Run의 작동 방식을 이해하는 데 도움이 됩니다. 그런 다음 이 정보를 사용하여 AWS Lambda 기능과 비슷한 Cloud Run 기능과 이러한 워크로드를 리팩터링할 때 사용할 수 있는 Cloud Run 기능을 결정할 수 있습니다.

Cloud Run에서 제공하는 서비스 트리거에 대해 자세히 알아보려면 다음 리소스를 사용하세요.

HTTPS 호출: HTTPS 요청을 전송하여 Cloud Run 서비스를 트리거합니다.
HTTP/2 호출: HTTP/2 요청을 전송하여 Cloud Run 서비스를 트리거합니다.
WebSockets: 클라이언트를 Cloud Run에서 실행되는 WebSockets 서버에 연결합니다.
gRPC 연결: gRPC를 사용하여 Cloud Run 서비스에 연결합니다.
비동기 호출: Cloud Tasks를 사용하여 Cloud Run 서비스에서 비동기식으로 처리할 태스크를 큐에 추가합니다.
예약된 호출: Cloud Scheduler를 사용하여 일정에 따라 Cloud Run 서비스를 호출합니다.
이벤트 기반 호출: Eventarc 트리거를 만들어 CloudEvents 형식의 특정 이벤트에서 Cloud Run 서비스를 호출합니다.
Pub/Sub 통합: Pub/Sub 푸시 구독에서 Cloud Run 서비스를 호출합니다.
Workflows 통합: 워크플로에서 Cloud Run 서비스를 호출합니다.

Cloud Run에서 제공하는 작업 실행 메커니즘에 관해 자세히 알아보려면 다음 리소스를 사용하세요.

주문형 실행: 완료될 때까지 실행되는 작업 실행을 만듭니다.
예약된 실행: 일정에 따라 Cloud Run 작업을 실행합니다.
Workflows 통합: 워크플로에서 Cloud Run 작업을 실행합니다.

AWS Lambda 호출 메커니즘과 비슷한 Cloud Run 호출 또는 실행 메커니즘을 파악하려면 다음 표를 사용하세요. 프로비저닝해야 하는 각 Cloud Run 리소스에 대해 올바른 호출 또는 실행 메커니즘을 선택해야 합니다.

AWS Lambda 기능	Cloud Run 기능
HTTPS 트리거 (함수 URL)	HTTPS 호출
HTTP/2 트리거 (외부 API 게이트웨이를 사용하여 부분적으로 지원됨)	HTTP/2 호출 (기본적으로 지원됨)
WebSocket (외부 API 게이트웨이를 사용하여 지원됨)	WebSocket (기본적으로 지원됨)
해당 사항 없음 (gRPC 연결이 지원되지 않음)	gRPC 연결
비동기 호출	Cloud Tasks 통합
예약된 호출	Cloud Scheduler 통합
독점 이벤트 형식의 이벤트 기반 트리거	CloudEvents 형식의 이벤트 기반 호출
Amazon SQS 및 Amazon SNS 통합	Pub/Sub 통합
AWS Lambda Step Functions	워크플로 통합

Cloud Run 리소스 구성

마이그레이션된 워크로드를 트리거하고 실행하기 위해 내린 설계 결정을 보완하기 위해 Cloud Run은 런타임 환경의 여러 측면을 미세 조정할 수 있는 여러 구성 옵션을 지원합니다. 이러한 구성 옵션은 리소스 서비스와 작업으로 구성됩니다.

앞서 언급한 대로 먼저 Cloud Run에서 사용할 수 있는 모든 구성 옵션을 이해하면 Cloud Run의 작동 방식을 더 잘 이해할 수 있습니다. 이를 통해 AWS Lambda 기능을 유사한 Cloud Run 기능과 비교하고 워크로드를 리팩터링하는 방법을 결정할 수 있습니다.

Cloud Run 서비스에서 제공하는 구성에 대해 자세히 알아보려면 다음 리소스를 사용하세요.

용량: 메모리 한도, CPU 한도, CPU 할당, 요청 시간 초과, 인스턴스당 최대 동시 요청, 최소 인스턴스, 최대 인스턴스, GPU 구성
환경: 컨테이너 포트 및 진입점, 환경 변수, Cloud Storage 볼륨 마운트, 메모리 내 볼륨 마운트, 실행 환경, 컨테이너 상태 확인, 보안 비밀, 서비스 계정
자동 확장
예외 조건 처리: Pub/Sub 실패 처리 및 Eventarc 실패 처리
메타데이터: 설명, 라벨, 태그
트래픽 게재: 커스텀 도메인 매핑, 자동 할당 URL, Cloud CDN 통합, 세션 어피니티

Cloud Run에서 제공하는 작업에 관해 자세히 알아보려면 다음 리소스를 사용하세요.

용량: 메모리 한도, CPU 한도, 동시 실행, 작업 시간 초과
환경: 컨테이너 진입점, 환경 변수, Cloud Storage 볼륨 마운트, 메모리 내 볼륨 마운트, 비밀, 서비스 계정
예외 조건 처리: 최대 재시도 횟수
메타데이터: 라벨 및 태그

AWS Lambda 구성 옵션과 비슷한 Cloud Run 구성 옵션을 파악하려면 다음 표를 사용하세요. 프로비저닝해야 하는 각 Cloud Run 리소스에 대해 올바른 구성 옵션을 선택해야 합니다.

AWS Lambda 기능	Cloud Run 기능
프로비저닝된 동시 실행	최소 인스턴스
인스턴스당 예약된 동시 실행 (동시 실행 풀은 AWS 계정의 AWS Lambda 함수 간에 공유됩니다.)	서비스당 최대 인스턴스 수
해당 사항 없음 (지원되지 않음, 하나의 요청이 하나의 인스턴스에 매핑됨)	인스턴스당 동시 요청 수
해당 사항 없음 (메모리 할당에 따라 다름)	CPU 할당
확장성 설정	서비스의 인스턴스 자동 확장 작업의 동시 실행
인스턴스 구성 (CPU, 메모리)	CPU 및 메모리 한도
최대 실행 시간	서비스 요청 제한 시간 작업의 태스크 제한 시간
AWS Lambda SnapStart	시작 CPU 부스트
환경 변수	환경 변수
임시 데이터 저장소	인메모리 볼륨 마운트
Amazon Elastic File System 연결	NFS 볼륨 마운트
S3 볼륨 마운트는 지원되지 않습니다.	Cloud Storage 볼륨 마운트
AWS Lambda 워크로드의 AWS Secrets Manager	보안 비밀
워크로드 URL 및 HTTP(S) 엔드포인트	자동 할당된 URL Google Cloud 제품과의 Cloud Run 통합
스티키 세션 (외부 부하 분산기 사용)	세션 어피니티
한정자	버전

이전 표에 나열된 기능 외에도 AWS Lambda와 Cloud Run이 실행 환경의 인스턴스를 프로비저닝하는 방식의 차이도 고려해야 합니다. AWS Lambda는 동시 요청마다 단일 인스턴스를 프로비저닝합니다. 하지만 Cloud Run을 사용하면 인스턴스가 처리할 수 있는 동시 요청 수를 설정할 수 있습니다. 즉, AWS Lambda의 프로비저닝 동작은 Cloud Run에서 인스턴스당 최대 동시 요청 수를 1로 설정하는 것과 같습니다. 동시 요청의 최대 개수를 1보다 크게 설정하면 인스턴스의 CPU와 메모리가 동시 요청에서 공유되지만 요금은 한 번만 청구되므로 비용을 크게 절감할 수 있습니다. 대부분의 HTTP 프레임워크는 요청을 동시에 처리하도록 설계되었습니다.

Cloud Run 보안 및 액세스 제어

Cloud Run 리소스를 설계할 때는 마이그레이션된 워크로드에 필요한 보안 및 액세스 제어도 결정해야 합니다. Cloud Run은 환경을 보호하고 Cloud Run 워크로드의 역할과 권한을 설정하는 데 도움이 되는 여러 구성 옵션을 지원합니다.

이 섹션에서는 Cloud Run에서 사용할 수 있는 보안 및 액세스 제어를 강조 표시합니다. 이 정보는 이전된 워크로드가 Cloud Run에서 작동하는 방식을 이해하고 이러한 워크로드를 리팩터링하는 데 필요한 Cloud Run 옵션을 식별하는 데 도움이 됩니다.

Cloud Run에서 제공하는 인증 메커니즘에 관해 자세히 알아보려면 다음 리소스를 사용하세요.

Cloud Run에서 제공하는 보안 기능에 대해 자세히 알아보려면 다음 리소스를 사용하세요.

AWS Lambda에서 사용할 수 있는 보안 및 액세스 제어와 비슷한 Cloud Run 보안 및 액세스 제어를 파악하려면 다음 표를 사용하세요. 프로비저닝해야 하는 각 Cloud Run 리소스에 적절한 액세스 제어 및 보안 기능을 선택해야 합니다.

AWS Lambda 기능	Cloud Run 기능
AWS Identity Access and Management(IAM)를 통한 액세스 제어	Google Cloud IAM을 사용한 액세스 제어
실행 역할	Google Cloud의 IAM 역할
권한 경계	Google Cloud의 IAM 권한 및 맞춤 잠재고객
거버넌스 제어	조직 정책 서비스
코드 서명	Binary Authorization
전체 VPC 액세스	세분화된 VPC 이그레스 액세스 제어

Cloud Run 리소스 프로비저닝 및 구성

워크로드를 배포할 Cloud Run 리소스를 선택한 후 해당 리소스를 프로비저닝하고 구성합니다. Cloud Run 리소스 프로비저닝에 관한 자세한 내용은 다음을 참고하세요.

AWS Lambda 워크로드 리팩터링

AWS Lambda 워크로드를 Cloud Run으로 이전하려면 리팩터링해야 할 수 있습니다. 예를 들어 이벤트 기반 워크로드가 Amazon CloudWatch 이벤트가 포함된 트리거를 수용하는 경우 CloudEvents 형식의 이벤트를 수용하도록 워크로드를 리팩터링해야 할 수 있습니다.

각 AWS Lambda 워크로드에 필요한 리팩터링의 양에 영향을 줄 수 있는 요소에는 다음과 같은 여러 가지가 있습니다.

아키텍처. 아키텍처 측면에서 워크로드가 어떻게 설계되었는지 고려합니다. 예를 들어 비즈니스 로직을 AWS별 API에 액세스하는 로직과 명확하게 분리한 AWS Lambda 워크로드의 경우 두 로직이 혼합된 워크로드에 비해 리팩터링이 덜 필요할 수 있습니다.
멱등성. 워크로드가 입력과 관련하여 멱등적인지 고려합니다. 입력에 대해 일관된 워크로드는 이미 처리한 입력에 관한 상태를 유지해야 하는 워크로드에 비해 리팩터링이 덜 필요할 수 있습니다.
상태. 워크로드가 스테이트리스인지 고려합니다. 스테이트리스 워크로드는 상태를 유지하는 워크로드에 비해 리팩터링이 덜 필요할 수 있습니다. Cloud Run에서 데이터 저장을 위해 지원하는 서비스에 관한 자세한 내용은 Cloud Run 스토리지 옵션을 참고하세요.
런타임 환경 워크로드가 런타임 환경에 관해 가정하는지 고려합니다. 이러한 유형의 워크로드의 경우 Cloud Run 런타임 환경에서 동일한 가정을 충족해야 하거나 Cloud Run 런타임 환경에 대해 동일하게 가정할 수 없는 경우 워크로드를 리팩터링해야 할 수 있습니다. 예를 들어 워크로드에 특정 패키지 또는 라이브러리가 필요한 경우 해당 워크로드를 호스팅할 Cloud Run 런타임 환경에 패키지 또는 라이브러리를 설치해야 합니다.
구성 삽입 워크로드가 환경 변수와 비밀을 사용하여 구성을 삽입 (설정)하는 것을 지원하는지 고려합니다. 이 유형의 삽입을 지원하는 워크로드에는 다른 구성 삽입 메커니즘을 지원하는 워크로드에 비해 리팩터링이 덜 필요할 수 있습니다.
API 워크로드가 AWS Lambda API와 상호작용하는지 고려합니다. 이러한 API와 상호작용하는 워크로드는 Cloud API 및 Cloud Run API를 사용하도록 리팩터링해야 할 수 있습니다.
오류 보고 워크로드가 표준 출력 및 오류 스트림을 사용하여 오류를 보고하는지 고려합니다. 이러한 오류 보고를 실행하는 워크로드는 다른 메커니즘을 사용하여 오류를 보고하는 워크로드에 비해 리팩터링이 덜 필요할 수 있습니다.

Cloud Run 워크로드 개발 및 최적화에 관한 자세한 내용은 다음 리소스를 참고하세요.

배포 및 운영 프로세스 리팩토링

워크로드를 리팩터링한 후에는 배포 및 운영 프로세스를 리팩터링하여 다음을 실행합니다.

소스 환경에서 리소스를 프로비저닝하는 대신 Google Cloud 환경에서 리소스를 프로비저닝하고 구성합니다.
워크로드를 빌드 및 구성하고 원본 환경에 배포하는 대신 Google Cloud에 배포합니다.

이 프로세스 앞부분의 평가 단계에서는 이러한 프로세스에 대한 정보를 수집한 바 있습니다.

이러한 프로세스에 대해 고려해야 하는 리팩터링 유형은 이를 설계하고 구현한 방법에 따라 달라집니다. 리팩터링은 또한 각 프로세스에서 원하는 최종 상태에 따라 달라집니다. 예를 들어, 다음 사항을 고려해 보세요.

이러한 프로세스를 소스 환경에서 구현했으며 Google Cloud에서 유사한 프로세스를 설계하고 구현하려고 할 수 있습니다. 예를 들어 이러한 프로세스를 리팩터링하여 Cloud Build ,Cloud Deploy 및Infrastructure Manager 를 사용할 수 있습니다.
이러한 프로세스를 원본 환경 외부의 다른 제3자 환경에서 구현했을 수 있습니다. 이 경우 원본 환경 대신 Google Cloud 환경을 타겟팅하도록 이러한 프로세스를 리팩터링해야 합니다.
앞선 접근 방식을 조합합니다.

배포 및 운영 프로세스를 리팩터링하는 작업은 복잡할 수 있으며 상당한 노력이 필요할 수 있습니다. 워크로드 이전의 일부로 이러한 작업을 수행하려고 하면 워크로드 이전이 더 복잡해지고 위험에 노출될 수 있습니다. 배포 및 운영 프로세스를 평가하면 프로세스의 설계와 복잡성을 파악할 수 있습니다. 배포 및 운영 프로세스를 리팩터링하는 데 상당한 노력이 필요하다고 판단되면 별도의 전용 프로젝트의 일부로 이러한 프로세스를 리팩터링하는 것이 좋습니다.

Google Cloud에서 배포 프로세스를 설계하고 구현하는 방법에 관한 자세한 내용은 다음을 참고하세요.

이 문서에서는 배포할 아티팩트를 생성하고 대상 런타임 환경에 배포하는 배포 프로세스에 중점을 둡니다. 리팩터링 전략은 이러한 프로세스의 복잡성에 따라 크게 달라집니다. 다음 목록은 가능한 일반적인 리팩터링 전략을 간략히 보여줍니다.

Google Cloud에서 아티팩트 저장소를 프로비저닝합니다. 예를 들어 Artifact Registry를 사용하여 아티팩트와 빌드 종속 항목을 저장할 수 있습니다.
원본 환경과 Artifact Registry 모두에 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
대상 Google Cloud 환경에 워크로드를 배포하도록 배포 프로세스를 리팩터링합니다. 예를 들어 먼저 Artifact Registry에 저장된 아티팩트를 사용하여 Google Cloud에 워크로드의 일부를 배포합니다. 그런 다음 마이그레이션할 모든 워크로드가 Google Cloud에서 실행될 때까지 Google Cloud에 배포된 워크로드 수를 점차 늘립니다.
Artifact Registry에만 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
필요한 경우 배포할 이전 버전의 아티팩트를 원본 환경의 저장소에서 Artifact Registry로 마이그레이션합니다. 예를 들어 컨테이너 이미지를 Artifact Registry에 복사할 수 있습니다.
더 이상 필요하지 않으면 원본 환경에서 저장소를 사용 중단합니다.

마이그레이션 중 예기치 않은 문제로 인한 최종 롤백을 용이하게 하기 위해 Google Cloud로 마이그레이션이 진행되는 동안 Google Cloud의 현재 아티팩트 저장소에 컨테이너 이미지를 저장할 수 있습니다. 마지막으로 원본 환경을 지원 중단하는 과정에서 컨테이너 이미지 빌드 프로세스를 리팩터링하여 Google Cloud에만 아티팩트를 저장할 수 있습니다.

마이그레이션의 성공에 중요하지 않을 수도 있지만 이전 버전의 아티팩트를 원본 환경에서 Google Cloud의 아티팩트 저장소로 마이그레이션해야 할 수 있습니다. 예를 들어 워크로드를 임의의 시점으로 롤백하는 기능을 지원하려면 이전 버전의 아티팩트를 Artifact Registry로 마이그레이션해야 할 수 있습니다. 자세한 내용은 서드 파티 레지스트리에서 이미지 마이그레이션을 참조하세요.

Artifact Registry를 사용하여 아티팩트를 저장하는 경우 액세스 제어, 데이터 무단 반출 방지, 취약점 스캔, Binary Authorization과 같은 아티팩트 저장소를 보호하는 데 도움이 되는 제어 기능을 구성하는 것이 좋습니다. 자세한 내용은 액세스 제어 및 아티팩트 보호를 참조하세요.

운영 프로세스 리팩터링

Cloud Run으로 이전하는 과정에서 Cloud Run 환경을 지속적으로 효과적으로 모니터링할 수 있도록 운영 프로세스를 리팩터링하는 것이 좋습니다.

Cloud Run은 다음과 같은 운영 서비스와 통합됩니다.

Google Cloud Observability: 워크로드에 로깅, 모니터링, 알림을 제공합니다. 필요한 경우 Cloud Run 워크로드에 대한 Prometheus 스타일 모니터링 또는 OpenTelemetry 측정항목을 가져올 수도 있습니다.
Cloud 감사 로그: 감사 로그를 제공합니다.
Cloud Trace: 분산 성능 추적을 제공합니다.

데이터 이전

이 프로세스의 앞부분에 있는 평가 단계에서 마이그레이션하는 AWS Lambda 워크로드가 AWS 환경에 있는 데이터에 종속되는지 또는 데이터를 생성하는지 확인할 수 있었습니다. 예를 들어 AWS S3에서 Cloud Storage로 또는 Amazon RDS 및 Aurora에서 PostgreSQL용 Cloud SQL 및 AlloyDB로 데이터를 마이그레이션해야 한다고 판단했을 수 있습니다. AWS에서 Google Cloud로 데이터를 마이그레이션하는 방법에 관한 자세한 내용은 AWS에서 Google Cloud로 마이그레이션: 시작하기를 참고하세요.

배포 및 운영 프로세스 리팩터링과 마찬가지로 AWS에서 Google Cloud로 데이터를 마이그레이션하는 작업은 복잡할 수 있으며 상당한 노력이 필요할 수 있습니다. AWS Lambda 워크로드의 마이그레이션의 일환으로 이러한 데이터 마이그레이션 작업을 실행하려고 하면 마이그레이션이 복잡해지고 위험에 노출될 수 있습니다. 이전할 데이터를 분석하면 데이터의 크기와 복잡성을 파악할 수 있습니다. 이 데이터를 마이그레이션하는 데 상당한 노력이 필요하다고 판단되면 별도의 전용 프로젝트의 일환으로 데이터를 마이그레이션하는 것이 좋습니다.

이전 결과 검증

워크로드 이전의 유효성 검사는 일회성 이벤트가 아니라 연속적인 프로세스입니다. AWS Lambda에서 Cloud Run으로 이전하기 전, 도중, 후에 테스트 및 유효성 검사에 집중해야 합니다.

최적의 성능과 최소한의 서비스 중단으로 원활하게 이전할 수 있도록 다음 프로세스를 사용하여 AWS Lambda에서 Cloud Run으로 이전하는 워크로드를 검증하는 것이 좋습니다.

이전 단계를 시작하기 전에 대상 Google Cloud 환경을 고려하도록 기존 테스트 사례를 리팩터링합니다.
이전 중에 각 이전 마일스톤에서 테스트 결과를 검증하고 철저한 통합 테스트를 실행합니다.
이전 후 다음 테스트를 실행합니다.
- 기준점 테스트: 다양한 부하에서 실행 시간, 리소스 사용량, 오류율과 같은 AWS Lambda의 원래 워크로드 성능 벤치마크를 설정합니다. Cloud Run에서 이러한 테스트를 복제하여 이전 또는 구성 문제를 나타낼 수 있는 불일치를 식별합니다.
- 기능 테스트: 두 환경에서 다양한 입력 및 예상 출력 시나리오를 다루는 테스트 사례를 만들고 실행하여 워크로드의 핵심 로직이 일관되게 유지되도록 합니다.
- 부하 테스트: 트래픽을 점진적으로 늘려 실제 조건에서 Cloud Run의 성능과 확장성을 평가합니다. 원활한 이전을 위해 오류 및 리소스 제한과 같은 불일치를 해결하세요.

Google Cloud 환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 대상 환경이 최적화 요구사항을 충족할 때까지 최적화 태스크를 반복합니다. 각 반복 단계는 다음과 같습니다.

현재 환경, 팀 및 최적화 루프를 평가합니다.
최적화 요구사항 및 목표를 설정합니다.
환경 및 팀을 최적화합니다.
최적화 루프를 조정합니다.

최적화 목표에 도달할 때까지 이 순서를 반복합니다.

Google Cloud 환경 최적화에 대한 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화 및 성능 최적화 프로세스를 참조하세요.

다음 단계

기타 AWS에서 Google Cloud로의 마이그레이션 여정 알아보기
AWS 및 Azure 서비스와 Google Cloud 비교 방법 알아보기
마이그레이션에 대한 도움을 찾는 방법 알아보기
Cloud 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기

참여자

저자:

마르코 페라리 | 클라우드 솔루션 설계자
시앙 션 | 솔루션 설계자

기타 참여자:

Steren Giannini | 그룹 제품 관리자
제임스 마 | 제품 관리자
헨리 벨 | 클라우드 솔루션 설계자
크리스토프 스탄저 | 전략적 클라우드 엔지니어
CC 첸 | 고객 솔루션 설계자
위체 베네마 | 개발자 관계 엔지니어