모듈 11: Google App Engine에서 Cloud Functions로 마이그레이션

1. 개요

서버리스 마이그레이션 스테이션 Codelab 시리즈 (사용자 주도형 실습 튜토리얼) 및 관련 동영상은 Google Cloud 서버리스 개발자가 주로 기존 서비스에서 벗어나 하나 이상의 마이그레이션을 통해 애플리케이션을 현대화하도록 돕는 것을 목표로 합니다. 이렇게 하면 앱의 이식성이 향상되고 더 많은 옵션과 유연성이 제공되므로 다양한 Cloud 제품과 통합하고 액세스하고 최신 언어 버전으로 보다 쉽게 업그레이드할 수 있습니다. 이 시리즈는 처음에는 초기 Cloud 사용자, 특히 App Engine (표준 환경) 개발자에 중점을 두고 있지만 Cloud Functions 및 Cloud Run과 같은 다른 서버리스 플랫폼이나 해당하는 경우 다른 플랫폼을 포함할 만큼 광범위합니다.

'전체 앱'이 없는 경우 App Engine 또는 Cloud Run의 리소스가 필요합니다. 코드가 마이크로서비스 또는 간단한 함수로만 구성된 경우 Cloud Functions가 더 적합할 수 있습니다. 이 Codelab에서는 간단한 App Engine 앱을 마이그레이션하거나 대규모 앱을 여러 마이크로서비스로 분할하여 이와 같은 사용 사례를 위해 특별히 제작된 또 다른 서버리스 플랫폼인 Cloud Functions에 배포하는 방법을 알아봅니다.

다음 실습에서는

  • Cloud Shell 사용하기
  • Google Cloud Translation API 사용 설정
  • API 요청 인증
  • Cloud Functions에서 실행되도록 소규모 App Engine 앱 변환
  • Cloud Functions에 코드 배포

필요한 항목

설문조사

이 튜토리얼을 어떻게 사용하실 계획인가요?

읽기만 할 계획입니다 읽은 다음 연습 활동을 완료할 계획입니다

귀하의 Python 사용 경험이 어떤지 평가해 주세요.

초급 중급 고급

귀하의 Google Cloud 서비스 사용 경험을 평가해 주세요.

<ph type="x-smartling-placeholder"></ph> 초보자 중급 숙련도

2. 배경

Google App Engine 및 Cloud Functions와 같은 PaaS 시스템은 사용자에게 많은 편의성을 제공합니다. 이러한 서버리스 플랫폼을 사용하면 기술팀이 사용할 플랫폼을 조사하고 필요한 하드웨어 양을 결정하는 데 시간을 할애하지 않고 비즈니스 솔루션을 만드는 데 집중할 수 있습니다. 애플리케이션은 필요에 따라 자동 확장하고, 사용한 만큼만 지불하는 방식으로 0으로 축소하여 비용을 관리할 수 있으며, 오늘날의 다양한 개발 언어를 지원합니다.

풀 스택 웹 애플리케이션 개발이나 모바일 앱을 위한 복잡한 백엔드가 App Engine에 적합하지만, 개발자가 주로 뉴스 피드를 업데이트하거나 홈팀의 플레이오프 경기의 최신 점수를 가져오는 등 일부 기능을 온라인에 게시하려는 경우가 많습니다. 두 시나리오 모두에 코딩 로직이 존재하지만 둘 다 본격적인 '애플리케이션'이 아닌 것처럼 보입니다. App Engine의 강력한 기능이 필요합니다 이때 Cloud Functions가 유용합니다.

Cloud Functions는 다음과 같은 작은 코드 배포를 위한 것입니다.

  • 전체 애플리케이션의 일부가 아님
  • 전체 개발 스택에 필요하지 않음
  • 한 가지 항목에 집중하는 애플리케이션 또는 단일 모바일 앱 백엔드에 있음

또한 Cloud Functions를 사용하면 Cloud Firestore 또는 Cloud SQL과 같은 공유된 공통 데이터베이스를 사용하는 대규모 모놀리식 애플리케이션을 여러 마이크로서비스로 분할할 수 있습니다. 함수 또는 마이크로서비스를 컨테이너화하고 Cloud Run에서 서버리스로 실행하려는 경우에도 가능합니다.

거의 모든 이전 튜토리얼에 포함된 샘플 App Engine 앱은 Cloud Functions에서 잘 작동하는 기본 기능을 갖춘 짧은 앱입니다. 이 튜토리얼에서는 Cloud Functions에서 실행되도록 앱을 수정하는 방법을 알아봅니다. App Engine 관점에서는 함수가 전체 앱보다 간단하므로 '오버헤드'가 적고 더 쉽고 빠르게 시작할 수 있습니다. 살펴보겠습니다 이 이전 단계는 다음과 같습니다.

  • 설정/사전 작업
  • 구성 파일 삭제
  • 애플리케이션 파일 수정

3. 설정/사전 작업

Cloud Functions는 Python 2를 지원하지 않으므로 이 Codelab은 모듈 2 Cloud NBS App Engine 샘플 앱의 Python 3 버전으로 시작합니다. 먼저 프로젝트를 설정하고 코드를 가져온 다음 기준 앱을 배포하여 작동하는 코드로 시작하고 있는지 확인합니다.

1. 프로젝트 설정

모듈 2 Codelab을 완료하고 Python 3으로 포팅한 경우 동일한 프로젝트와 코드를 재사용하는 것이 좋습니다. 또는 새 프로젝트를 만들거나 다른 기존 프로젝트를 재사용할 수 있습니다. 프로젝트에 App Engine 서비스가 사용 설정된 활성 결제 계정이 있는지 확인합니다.

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 모듈 2 샘플 앱이 작동하는 것입니다. 이러한 튜토리얼이 없으면 여기로 이동하기 전에 위에 링크된 튜토리얼을 완료하세요. 그렇지 않고 이미 콘텐츠에 익숙하다면 아래의 모듈 2 코드를 가져와 시작할 수 있습니다.

여러분의 것이든 우리의 것이든, 모듈 2 Python 3 코드부터 시작하겠습니다. 이 모듈 11 Codelab에서는 각 단계를 살펴보고 모듈 11 저장소 폴더 (FINISH)에 있는 코드와 유사한 코드로 마무리합니다.

Python 3 Module 2 시작 파일 (사용자 또는 Google의 파일)의 디렉터리는 다음과 같습니다.

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. 기준 앱 (재)배포

이제 남은 사전 작업 실행 단계는 다음과 같습니다.

  1. gcloud 명령줄 도구 다시 숙지
  2. gcloud app deploy를 사용하여 샘플 앱 재배포
  3. 앱이 문제 없이 App Engine에서 실행되는지 확인합니다.

이러한 단계를 성공적으로 실행했으면 Cloud 함수로 변환할 수 있습니다.

4. 구성 파일 삭제

app.yaml 파일은 Cloud Functions에서 사용되지 않는 App Engine 아티팩트이므로 지금 삭제합니다. 이 작업을 하지 않거나 잊더라도 Cloud Functions는 이를 사용하지 않으므로 피해가 없습니다. requirements.txt가 모듈 2의 구성과 동일하게 유지되기 때문에 유일한 구성 변경사항입니다.

Python 2 App Engine 앱도 Python 3로 포팅하는 경우 appengine_config.py 폴더와 lib 폴더(있는 경우)를 삭제합니다. Python 3 런타임에서 사용되지 않는 App Engine 아티팩트입니다.

5. 애플리케이션 파일 수정

애플리케이션 파일은 main.py 하나뿐이므로 Cloud Functions로 이동하는 데 필요한 모든 변경사항이 이 파일에 적용됩니다.

가져오기

함수만 다루기 때문에 웹 애플리케이션 프레임워크가 필요하지 않습니다. 하지만 편의를 위해 Python 기반 Cloud Functions가 호출되면 필요에 따라 코드에서 사용할 요청 객체가 자동으로 전달됩니다. (Cloud Functions팀에서 함수에 전달되는 Flask 요청 객체로 이 객체를 선택했습니다.)

웹 프레임워크는 Cloud Functions 환경의 일부가 아니므로 앱이 다른 Flask 기능을 사용하지 않는 한 Flask에서 데이터를 가져오지 않습니다. 함수로 변환한 후에도 템플릿 렌더링이 계속 발생하기 때문입니다. 즉, flask.render_template()를 호출해야 하므로 Flask에서 가져옵니다. 웹 프레임워크가 없으므로 Flask 앱을 인스턴스화할 필요가 없으므로 app = Flask(__name__)를 삭제합니다. 변경사항을 적용하기 전과 후의 코드는 다음과 같습니다.

이전:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

변경 후:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

앱 객체 (app) 또는 다른 웹 프레임워크 인프라에 의존하는 경우 이러한 모든 종속 항목을 해결하여 적절한 해결 방법을 찾거나 사용을 완전히 삭제하거나 프록시를 찾아야 합니다. 그런 다음에 코드를 Cloud 함수로 변환할 수 있습니다. 아니면 App Engine을 유지하거나 Cloud Run용으로 앱을 컨테이너화하는 편이 더 나을 수 있습니다.

기본 핸들러 함수 서명 업데이트

함수 서명에 필요한 변경사항은 다음과 같습니다.

  1. 앱을 Cloud 함수로 변환한 후에는 Flask가 더 이상 사용되지 않으므로 경로 데코레이터를 삭제하세요.
  2. Cloud Functions는 자동으로 Flask Request 객체를 매개변수로 전달하므로 이 객체의 변수를 만듭니다. 샘플 앱에서는 request라고 합니다.
  3. 배포된 Cloud Functions의 이름을 지정해야 합니다. 기본 핸들러의 이름을 App Engine에서 root()로 지정하여 루트 애플리케이션 핸들러로 설명했습니다. Cloud 함수로서 이 이름을 사용하는 것은 적합하지 않습니다. 대신 이름이 visitme인 Cloud 함수를 배포하므로 Python 함수의 이름으로도 사용합니다. 마찬가지로 모듈 4와 5에서는 Cloud Run 서비스의 이름을 visitme로 지정했습니다.

이러한 업데이트 전후의 모습은 다음과 같습니다.

이전:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

변경 후:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

이로써 필요한 모든 업데이트를 마치겠습니다. 변경사항은 애플리케이션의 '인프라'에만 영향을 미쳤습니다. 있습니다. 핵심 애플리케이션 코드는 변경할 필요가 없으며 앱의 기능이 변경되지 않았습니다. 다음은 이 점을 설명하기 위해 변경된 사항을 그림으로 표현한 것입니다.

668f30e3865b27a9.png

로컬 개발 및 테스트

App Engine에는 dev_appserver.py 로컬 개발 서버가 있는 반면 Cloud Functions에는 함수 프레임워크가 있습니다. 이 프레임워크를 사용하면 개발과 테스트가 로컬에서 가능합니다. 코드를 Cloud Functions에 배포할 수 있을 뿐만 아니라 Compute Engine, Cloud Run과 같은 다른 컴퓨팅 플랫폼이나 Knative를 지원하는 온프렘 또는 하이브리드 클라우드 시스템에 배포할 수도 있습니다. 함수 프레임워크의 추가 링크는 아래를 참고하세요.

6. 빌드 및 배포

Cloud Functions에 배포하는 방법은 App Engine과 약간 다릅니다. requirements.txt 외부에서는 구성 파일이 사용되지 않으므로 코드에 대한 추가 정보를 명령줄에 지정해야 합니다. 다음 명령어를 사용하여 Python 3.10에서 실행되는 새 HTTP 트리거 Cloud 함수를 배포합니다.

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

다음과 비슷한 출력이 예상됩니다.

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

함수가 배포되면 배포 출력의 URL을 사용하여 앱을 방문합니다. URL 형식은 REGION-PROJECT_ID.cloudfunctions.net/visitme입니다. 출력은 이전에 App Engine에 배포했을 때와 동일합니다.

2732ae9218f011a2.png

이 시리즈의 다른 Codelab 및 동영상과 마찬가지로 기준 앱 기능은 변경되지 않습니다. 한 가지 현대화 기법을 적용하여 앱이 이전과 동일하게 작동하되 최신 인프라에 기반하도록 하는 것입니다. 예를 들어 이전의 App Engine 기존 서비스에서 대체 Cloud 독립형 제품으로 마이그레이션하거나, 이 튜토리얼의 경우처럼 앱을 다른 Google Cloud 서버리스 플랫폼으로 이전합니다.

7. 요약/삭제

축하합니다. 이 작은 App Engine 앱을 Cloud 함수로 변환했습니다. 또 다른 적절한 사용 사례로는 대규모 모놀리식 App Engine 앱을 각각 Cloud 함수인 일련의 마이크로서비스로 분할하는 것입니다. 이것은 좀 더 현대적인 개발 기술로서, 보다 '플러그 앤 플레이' 구성요소('JAM 스택') 스타일입니다. 혼합 및 매칭, 코드 재사용이 허용된다는 점도 두 가지 목표이지만, 또 다른 이점은 마이크로서비스가 시간이 지남에 따라 계속 디버깅되므로 코드가 안정되고 전반적인 유지보수 비용이 낮아진다는 것입니다.

삭제

이 Codelab을 완료한 후에는 요금이 청구되지 않도록 (일시적 또는 영구적으로) 모듈 2 App Engine 앱을 사용 중지할 수 있습니다. App Engine 플랫폼에는 무료 할당량이 있으므로 사용 등급 내에 있는 한 요금이 청구되지 않습니다. Datastore도 마찬가지입니다. 자세한 내용은 Cloud Datastore 가격 책정 페이지를 참조하세요.

App Engine 및 Cloud Functions와 같은 플랫폼에 배포하면 약간의 빌드 및 스토리지 비용이 발생합니다. 일부 리전에서는 Cloud Storage와 마찬가지로 Cloud Build에 자체 무료 할당량이 있습니다. 빌드가 이러한 할당량의 일부를 사용합니다. 특히 리전에 무료 등급이 없는 경우 잠재적인 비용을 최소화하려면 스토리지 사용량에 유의하세요.

아쉽게도 Cloud Functions에는 기능을 사용할 수 있습니다. 코드를 백업하고 함수만 삭제합니다. 나중에 언제든지 동일한 이름으로 다시 배포할 수 있습니다. 그러나 다른 이전 Codelab을 진행하지 않고 모든 항목을 완전히 삭제하려면 Cloud 프로젝트를 종료하세요.

다음 단계

이 튜토리얼 외에 살펴볼 다른 마이그레이션 모듈에는 Cloud Run용 App Engine 앱 컨테이너화가 포함됩니다. 모듈 4와 모듈 5 Codelab의 링크를 참고하세요.

  • 모듈 4: Docker를 사용하는 Cloud Run으로 마이그레이션
  • Docker를 사용하여 Cloud Run에서 실행하기 위해 앱을 컨테이너화합니다.
  • 이 마이그레이션을 통해 Python 2를 계속 사용할 수 있습니다.
  • 모듈 5: Cloud 빌드팩을 사용하여 Cloud Run으로 마이그레이션
  • Cloud Buildpacks를 사용하여 Cloud Run에서 실행할 앱 컨테이너화
  • Docker, 컨테이너, Dockerfile에 대해 알 필요가 없습니다.
  • 앱이 이미 Python 3로 마이그레이션되어 있어야 합니다(Buildpacks는 Python 2를 지원하지 않음).

그 외 많은 모듈은 App Engine 번들 서비스에서 Cloud 독립형 대체 서비스로 마이그레이션하는 방법을 개발자에게 보여주는 데 중점을 둡니다.

  • 모듈 2: App Engine ndb에서 Cloud Dataplex로 마이그레이션
  • 모듈 7~9: App Engine 태스크 큐 푸시 태스크에서 Cloud Tasks로 마이그레이션
  • 모듈 12~13: App Engine Memcache에서 Cloud Memorystore로 마이그레이션
  • 모듈 15~16: App Engine blobstore에서 Cloud Storage로 이전
  • 모듈 18~19: App Engine 작업 대기열 (가져오기 작업)에서 Cloud Pub/Sub로 마이그레이션

특히 CI/CD (지속적 통합/지속적 배포 또는 배포) 파이프라인으로 구성된 컨테이너화가 애플리케이션 개발 워크플로의 일부가 되었다면 Cloud Functions 대신 Cloud Run으로 마이그레이션하는 것이 좋습니다. Docker로 앱을 컨테이너화하려면 모듈 4를 참고하고, 컨테이너, Docker 관련 지식 또는 Dockerfile 없이 앱을 컨테이너화하려면 모듈 5를 참고하세요. Cloud Functions 또는 Cloud Run을 고려하고 있다면 다른 서버리스 플랫폼으로 전환하는 것은 선택사항이므로 변경하기 전에 앱 및 사용 사례에 가장 적합한 옵션을 고려하는 것이 좋습니다.

다음으로 고려할 마이그레이션 모듈과 관계없이 모든 서버리스 마이그레이션 스테이션 콘텐츠 (Codelab, 동영상, 소스 코드[사용 가능한 경우])는 오픈소스 저장소에서 액세스할 수 있습니다. 저장소의 README는 고려할 이전 및 관련 '순서'에 관한 안내도 제공합니다. 오신 것을 환영합니다

8. 추가 리소스

App Engine 마이그레이션 모듈 Codelab 문제/의견

이 Codelab에 문제가 발견된 경우 문제를 기록하기 전에 먼저 비슷한 기록이 있는지 검색해보세요. 검색 및 새 문제 만들기 링크:

마이그레이션 리소스

모듈 8 (START)과 모듈 9 (FINISH)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 ZIP 파일을 클론하거나 다운로드할 수 있는 모든 App Engine Codelab 이전 저장소에서도 액세스할 수 있습니다.

Codelab

Python 3

모듈 2

코드

모듈 11

코드

온라인 리소스

다음은 이 튜토리얼과 관련이 있을 수 있는 온라인 리소스입니다.

App Engine

Cloud Functions

기타 클라우드 정보

동영상

라이선스

이 작업물은 Creative Commons Attribution 2.0 일반 라이선스에 따라 사용이 허가되었습니다.