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

1. 개요

서버리스 마이그레이션 스테이션 Codelab 시리즈 (사용자 주도형, 실무 가이드) 및 관련 동영상은 Google Cloud 서버리스 개발자가 주로 기존 서비스에서 벗어나는 하나 이상의 마이그레이션을 통해 애플리케이션을 현대화할 수 있도록 돕기 위한 것입니다. 이렇게 하면 앱의 이식성이 높아지고 더 많은 옵션과 유연성을 제공하여 다양한 Cloud 제품과 통합하고 액세스할 수 있으며 최신 언어 출시로 더 쉽게 업그레이드할 수 있습니다. 이 시리즈는 처음에는 주로 App Engine (표준 환경) 개발자와 같은 초기 Cloud 사용자를 대상으로 하지만, 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 서비스 사용 경험을 평가해 주세요.

초급 중급 고급

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 NDB App Engine 샘플 앱의 Python 3 버전으로 시작합니다. 먼저 프로젝트를 설정하고, 코드를 가져온 다음, 기본 앱을 배포하여 작동하는 코드로 시작할 수 있도록 준비합니다.

1. 프로젝트 설정

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

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 작동하는 모듈 2 샘플 앱을 준비하는 것입니다. 샘플 앱이 없는 경우에는 계속하기 전에 위 링크의 가이드를 완료하세요. 가이드 내용을 잘 알고 계시다면 아래 모듈 2 코드를 선택하여 시작하세요.

무엇을 사용하든 모듈 2 Python 3 코드에서부터 시작해야 합니다. 이 모듈 11 Codelab은 각 단계를 안내하며, 모듈 11 저장소 폴더 (완료)에 있는 것과 비슷한 코드로 마무리됩니다.

Python 3 모듈 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()

AFTER:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

앱 객체 (app) 또는 기타 웹 프레임워크 인프라를 사용하는 경우 이러한 종속 항목을 모두 해결하고 적절한 해결 방법을 찾거나 사용을 완전히 삭제하거나 프록시를 찾아야 합니다. 그런 후에만 코드를 Cloud 함수로 변환할 수 있습니다. 그렇지 않은 경우 App Engine을 사용하거나 Cloud Run용 앱을 컨테이너화하는 것이 좋습니다.

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

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

  1. 앱을 Cloud Functions로 변환한 후에는 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)

AFTER:

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에는 Functions Framework가 있습니다. 이 프레임워크를 사용하면 로컬에서 개발하고 테스트할 수 있습니다. 코드를 Cloud Functions에 배포할 수 있지만 Compute Engine, Cloud Run과 같은 다른 컴퓨팅 플랫폼이나 Knative를 지원하는 온프레미스 또는 하이브리드 클라우드 시스템에도 배포할 수 있습니다. Functions Framework에 대한 추가 링크는 아래를 참고하세요.

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 Functions로 변환하신 것을 축하드립니다. 또 다른 적절한 사용 사례는 대규모 모놀리식 App Engine 앱을 각각 Cloud Functions인 일련의 마이크로서비스로 분할하는 것입니다. 이는 더 현대적인 개발 기법으로, 'JAM 스택' 스타일의 '플러그 앤 플레이' 구성요소를 만듭니다. 이를 통해 혼합 및 매칭과 코드 재사용이 가능하며, 이는 두 가지 목표입니다. 또 다른 이점은 이러한 마이크로서비스가 시간이 지남에 따라 계속 디버그되므로 안정적인 코드와 전반적으로 낮은 유지보수 비용을 의미합니다.

삭제

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

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

Cloud Functions에는 '사용 중지' 기능이 없습니다. 코드를 백업하고 함수를 삭제하기만 하면 됩니다. 나중에 언제든지 동일한 이름으로 다시 배포할 수 있습니다. 하지만 다른 마이그레이션 Codelab을 계속하지 않고 모든 것을 완전히 삭제하려면 Cloud 프로젝트를 종료하세요.

다음 단계

이 튜토리얼 외에도 Cloud Run용 App Engine 앱 컨테이너화와 같은 다른 마이그레이션 모듈을 살펴보세요. 모듈 4 및 모듈 5 Codelab 링크를 참고하세요.

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

다른 많은 모듈에서는 개발자가 App Engine 번들 서비스에서 Cloud 독립형 대체 서비스로 마이그레이션하는 방법을 보여줍니다.

  • 모듈 2: App Engine ndb에서 Cloud NDB로 마이그레이션
  • 모듈 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으로 마이그레이션하는 것이 좋습니다. 모듈 4에서 Docker를 사용하여 앱을 컨테이너화하거나 모듈 5에서 컨테이너, Docker 지식 또는 Dockerfile 없이 컨테이너화하는 방법을 알아보세요. Cloud Functions 또는 Cloud Run을 고려할 때 다른 서버리스 플랫폼으로 전환하는 것은 선택사항이며, 변경하기 전에 앱과 사용 사례에 가장 적합한 옵션을 고려하는 것이 좋습니다.

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

8. 추가 리소스

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

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

마이그레이션 리소스

모듈 8 (시작) 및 모듈 9 (완료)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 클론 또는 ZIP 파일로 다운로드할 수 있는 모든 App Engine Codelab 마이그레이션 저장소에서 액세스할 수도 있습니다.

Codelab

Python 3

모듈 2

코드

모듈 11

코드

온라인 리소스

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

App Engine

Cloud Functions

기타 클라우드 정보

동영상

라이선스

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