App Engine 번들 서비스 지원 확장: 1부 (모듈 17)

1. 개요

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

이전에는 개발자가 언어 버전을 업그레이드하기 전에 Datastore 및 Memcache와 같은 App Engine의 기존 '번들 서비스'에서 이전해야 했습니다. 이는 연속으로 수행하기에 어려울 수 있는 두 가지 작업입니다. 2세대 App Engine 서비스에서 여러 주요 번들 서비스를 사용할 수 있게 됨에 따라 개발자는 이제 번들 서비스 대부분을 계속 사용하면서 최신 런타임으로 앱을 포팅할 수 있습니다. 이 Codelab에서는 App Engine NDB 라이브러리를 통해 Datastore 번들 서비스의 사용을 유지하면서 샘플 앱을 Python 2에서 3으로 업그레이드하는 방법을 안내합니다. 번들 서비스 대부분을 사용하려면 이 튜토리얼에서 설명하는 것처럼 코드를 약간만 업데이트하면 되지만 더 광범위한 변경이 필요한 서비스도 있습니다. 이러한 서비스는 후속 모듈 및 Codelab인 '2부'에서 설명합니다.

다음 실습에서는

샘플 App Engine 앱을 Python 2에서 3으로 포팅
App Engine SDK를 포함하도록 앱 구성 업데이트
Python 3과 같은 2세대 런타임에서 번들 서비스를 지원하는 앱에 SDK 코드 추가

필요한 항목

활성 GCP 결제 계정이 있는 Google Cloud 프로젝트
기본 Python 기술
일반적인 Linux 명령어에 대한 실무 지식
App Engine 앱 개발 및 배포에 대한 기본 지식
작동하는 모듈 1 App Engine 앱 (Codelab 완료[권장] 또는 저장소에서 앱 복사)

설문조사

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

읽기만 할 계획입니다

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

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

초급

중급

고급

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

초급

중급

고급

2. 배경

원래 App Engine 서비스는 2008년에 출시되었으며 개발자가 전 세계적으로 애플리케이션을 빌드하고 배포하는 데 편리하도록 기존 API (현재 번들 서비스라고 함) 집합이 함께 제공되었습니다. 이러한 서비스에는 Datastore, Memcache, 태스크 큐가 포함됩니다. 편리하기는 하지만 사용자는 App Engine에 연결된 독점 API를 사용할 때 앱의 이식성에 대해 우려했으며 앱이 더 이식 가능하기를 원했습니다. 이러한 번들 서비스 중 상당수가 자체 독립형 Cloud 제품으로 발전했다는 사실과 함께 App Engine팀은 이러한 서비스 없이 2018년에 차세대 플랫폼을 출시했습니다.

Python 2 개발자가 Python 3으로 업그레이드하기를 원하는 오늘날로 돌아가 보겠습니다. 번들 서비스를 사용하는 2.x 앱은 앱을 3.x로 포팅하기 전에 이러한 서비스에서 마이그레이션해야 했으므로 연속된 강제 마이그레이션이 발생했으며 이로 인해 어려움이 따를 수도 있었습니다. 이 전환을 지원하기 위해 App Engine팀은 2021년 가을에 과거로 연결되는 '웜홀'을 도입하여 차세대 런타임에서 실행되는 앱이 이러한 번들 서비스에 액세스할 수 있도록 했습니다. 이 출시에는 원래 런타임에서 사용할 수 있는 모든 서비스가 포함되어 있지는 않지만 Datastore, 작업 대기열, Memcache와 같은 주요 서비스는 사용할 수 있습니다.

이 Codelab에서는 번들 서비스 사용을 유지하면서 앱을 Python 3로 업그레이드하는 데 필요한 변경사항을 보여줍니다. 목표는 앱을 최신 런타임에서 실행하여 3.x 업그레이드를 차단하는 대신 번들 서비스에서 Cloud 독립형 서비스 또는 서드 파티 대안으로 자체 일정에 따라 마이그레이션할 수 있도록 하는 것입니다. 번들 서비스에서 마이그레이션하는 것은 더 이상 필수가 아니지만, 이렇게 하면 워크로드에 더 적합한 플랫폼으로 전환하거나 방금 설명한 대로 최신 언어 출시로 업그레이드하면서 App Engine을 유지하는 등 앱을 호스팅할 수 있는 위치에 관해 더 많은 이식성과 유연성을 확보할 수 있습니다.

모듈 1 Python 2 샘플 앱은 App Engine NDB를 통해 Datastore 번들 서비스를 활용합니다. 앱은 이미 webapp2에서 Flask로 프레임워크를 이전했지만(모듈 1 Codelab에서 완료) Datastore 사용은 그대로입니다.

이 튜토리얼에서는 다음 단계를 다룹니다.

설정/사전 작업
구성 업데이트
애플리케이션 코드 수정

3. 설정/사전 작업

이 섹션에서는 다음을 수행하는 방법을 설명합니다.

Cloud 프로젝트 설정
기준 샘플 앱 가져오기
기준 앱 (재)배포 및 검증

이 단계를 따르면 작동하는 코드로 시작할 수 있습니다.

1. 프로젝트 설정

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

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 작동하는 모듈 1 App Engine 앱을 준비하는 것입니다. 모듈 1 Codelab을 완료하거나 (권장) 저장소에서 모듈 1 앱을 복사하세요. 무엇을 사용하든 모듈 1 코드에서부터 시작해야 합니다. 이 Codelab은 각 단계를 안내하며, 모듈 7 저장소 폴더 '완료'에 있는 것과 비슷한 코드로 마무리됩니다.

시작: 모듈 1 폴더 (Python 2)
완료: Module 1b 폴더 (Python 3)
전체 저장소 (클론 또는 ZIP 파일 다운로드)

사용하는 모듈 1 앱에 관계없이 폴더는 아래와 같이 표시되며 lib 폴더도 있을 수 있습니다.

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

3. 기준 앱 (재)배포

다음 단계를 실행하여 모듈 1 앱을 (다시) 배포합니다.

lib 폴더가 있는 경우 삭제하고 pip install -t lib -r requirements.txt를 실행하여 lib를 다시 채웁니다. Python 2와 3이 모두 설치된 경우 pip2 명령어를 대신 사용해야 할 수 있습니다.
gcloud 명령줄 도구를 설치하고 초기화했으며 사용법을 검토했는지 확인합니다.
발급된 각 gcloud 명령어에 PROJECT_ID를 입력하지 않으려면 gcloud config set project PROJECT_ID로 클라우드 프로젝트를 설정하세요.
gcloud app deploy로 샘플 앱 배포
모듈 1 앱이 최근 방문을 표시하는 데 문제가 없이 예상대로 실행되는지 확인합니다 (아래 그림 참고).

4. 구성 업데이트

이러한 단계를 성공적으로 실행하고 웹 앱이 작동하는지 확인한 후에는 구성부터 시작하여 이 앱을 Python 3로 포팅할 수 있습니다.

requirements.txt에 SDK 추가

App Engine Python 3 런타임은 서드 파티 라이브러리 사용의 오버헤드를 크게 줄여줍니다. requirements.txt에 나열하기만 하면 됩니다. Python 3에서 번들 서비스를 사용하려면 App Engine SDK 패키지 appengine-python-standard를 추가합니다. SDK 패키지가 모듈 1의 Flask에 조인됩니다.

flask
appengine-python-standard

app.yaml 업데이트

아래 단계에 따라 app.yaml 파일에 구성 변경사항을 적용하세요.

runtime 지시어를 지원되는 Python 3 출시로 바꿉니다. 예를 들어 Python 3.10의 경우 python310을 지정합니다.
Python 3에서는 threadsafe 및 api_version 지시문이 모두 사용되지 않으므로 두 지시문을 모두 삭제합니다.
이 앱에는 스크립트 핸들러만 있으므로 handlers 섹션을 완전히 삭제합니다. 앱에 정적 파일 핸들러가 있는 경우 handlers에서 그대로 둡니다.
Python 3 런타임은 Python 2 런타임과 달리 기본 제공 서드 파티 라이브러리를 지원하지 않습니다. 내 앱에 app.yaml의 libraries 섹션이 있는 경우 섹션 전체를 삭제합니다. (필수 패키지는 기본 제공이 아닌 라이브러리처럼 requirements.txt에 나열하기만 하면 됩니다.) 샘플 앱에는 libraries 섹션이 없으므로 다음 단계로 이동합니다.
true로 설정된 app_engine_apis 지시어를 만들어 사용합니다. 이는 위의 requirements.txt에 App Engine SDK 패키지를 추가하는 것과 같습니다.

app.yaml에 적용해야 하는 필수 변경사항 요약:

이전:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

AFTER:

runtime: python310
app_engine_apis: true

기타 구성 파일

모든 서드 파티 패키지는 requirements.txt에만 나열하면 되므로 appengine_config.py에 특별한 항목이 없는 한 필요하지 않으므로 삭제합니다. 마찬가지로 빌드 프로세스 중에 모든 서드 파티 라이브러리가 자동으로 설치되므로 복사하거나 공급업체에 제공할 필요가 없습니다. 즉, 더 이상 pip install 명령어나 lib 폴더가 없으므로 삭제합니다. 요약:

파일 appengine_config.py개 삭제
폴더 lib개 삭제

이로써 필요한 모든 구성 변경이 완료되었습니다.

5. 애플리케이션 코드 수정

Python 3 런타임 환경에서 사용 가능한 번들 서비스 대부분에 액세스하려면 웹 서버 게이트웨이 인터페이스 (WSGI) 애플리케이션 객체를 main.py로 래핑하는 짧은 코드 조각이 필요합니다. 래퍼 함수는 google.appengine.api.wrap_wsgi_app()이며, 이를 가져와 WSGI 객체를 래핑하여 사용합니다. main.py에서 Flask의 필수 업데이트를 반영하도록 아래와 같이 변경합니다.

이전:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

AFTER:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

다른 Python 프레임워크의 WSGI 래핑 예시는 문서를 참고하세요.

이 예시는 앱이 Python 3의 번들 서비스 대부분에 액세스할 수 있도록 하지만 Blobstore 및 Mail과 같은 다른 서비스에는 추가 코드가 필요합니다. 이러한 샘플은 다른 이전 모듈에서 다루겠습니다.

이로써 모듈 1 샘플 앱에 App Engine 번들 서비스 사용을 추가하는 데 필요한 모든 변경사항이 완료되었습니다. 애플리케이션은 이미 Python 2 및 3과 호환되므로 구성에서 이미 수행한 작업 외에 Python 3으로 포팅하기 위한 추가 변경사항은 없습니다. 마지막 단계는 수정된 앱을 차세대 App Engine Python 3 런타임에 배포하고 업데이트가 성공했는지 확인하는 것입니다.

6. 요약/삭제

이 섹션에서는 앱을 배포하고 의도한 대로 작동하는지, 반영된 출력이 있는지 확인하여 이 Codelab을 마무리합니다. 앱 유효성 검사 후 정리 작업을 실행하고 다음 단계를 고려합니다.

애플리케이션 배포 및 확인

gcloud app deploy를 사용하여 Python 3 앱을 배포하고 앱이 Python 2에서와 같이 작동하는지 확인합니다. 기능은 변경되지 않으므로 출력은 모듈 1 앱과 동일해야 합니다.

최종 참고사항

Module 1b folder (FINISH)의 내용과 비교하고 중간에 잘못된 부분이 있으면 필요에 따라 조정합니다.
앱에서 아직 webapp2를 사용하는 경우 이 페이지에서 모듈 0 main.py을 모듈 1b main.py와 나란히 비교한 다음 모듈 1 Codelab을 실행하여 webapp2에서 Flask로 이전하는 방법을 알아보세요.

Python 2 App Engine 앱을 Python 3로 포팅하면서 현재 번들 서비스 사용을 유지하기 위한 첫 번째 단계를 밟으신 것을 축하드립니다.

삭제

일반

지금까지 완료한 경우 청구가 발생하지 않도록 App Engine 앱을 사용 중지하는 것이 좋습니다. 하지만 테스트나 실험을 더 진행하고 싶다면 App Engine 플랫폼에 무료 할당량이 있으므로 해당 사용량 등급을 초과하지 않는 한 요금이 청구되지 않습니다. 이는 컴퓨팅에 대한 요금이며 관련 App Engine 서비스에 대한 요금도 부과될 수 있으므로 자세한 내용은 가격 책정 페이지를 확인하세요. 이 이전과 관련된 다른 클라우드 서비스는 별도로 청구됩니다. 두 경우 모두 해당하는 경우 아래의 '이 Codelab에만 해당' 섹션을 참고하세요.

완전한 공개를 위해 말씀드리면 App Engine과 같은 Google Cloud 서버리스 컴퓨팅 플랫폼에 배포하면 약간의 빌드 및 스토리지 비용이 발생합니다. Cloud Build에는 Cloud Storage와 마찬가지로 자체 무료 할당량이 있습니다. 해당 이미지를 저장하면 할당량의 일부가 사용됩니다. 하지만 무료 등급이 없는 지역에 거주할 수도 있으므로 스토리지 사용량을 파악하여 잠재적인 비용을 최소화하세요. 검토해야 하는 특정 Cloud Storage '폴더'는 다음과 같습니다.

console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
위의 스토리지 링크는 PROJECT_ID 및 *LOC*에 따라 달라집니다. 예를 들어 앱이 미국에서 호스팅되는 경우 'us'입니다.

반면에 이 애플리케이션 또는 기타 관련 이전 Codelab을 계속하지 않고 모든 것을 완전히 삭제하려면 프로젝트를 종료하세요.

이 Codelab에만 해당

아래에 나열된 서비스는 이 Codelab에만 해당합니다. 자세한 내용은 각 제품의 문서를 참고하세요.

App Engine Datastore 서비스는 무료 등급도 있는 Cloud Datastore (Datastore 모드의 Cloud Firestore)에서 제공합니다. 자세한 내용은 가격 책정 페이지를 참고하세요.

다음 단계

여기에서 몇 가지 방향으로 나아갈 수 있습니다.

더 많은 코드 변경이 필요한 번들 서비스를 사용하여 코드 업데이트
번들 서비스에서 Cloud 독립형 제품으로 마이그레이션
App Engine에서 다른 Cloud 서버리스 플랫폼으로 마이그레이션

Blobstore, Mail, Deferred와 같은 다른 번들 서비스에 액세스하려면 더 많은 코드 변경이 필요합니다. App Engine 기존 번들 서비스에서 벗어나는 데 중점을 둔 마이그레이션 모듈은 다음과 같습니다.

모듈 2: App Engine NDB에서 Cloud NDB로
모듈 7~9: App Engine TaskQueue (푸시 작업)에서 Cloud Tasks로
모듈 12~13: App Engine Memcache에서 Cloud Memorystore로
모듈 15~16: App Engine Blobstore에서 Cloud Storage로
모듈 18~19: App Engine TaskQueue (풀 작업)에서 Cloud Pub/Sub로

App Engine은 더 이상 Google Cloud의 유일한 서버리스 플랫폼이 아닙니다. 소규모 App Engine 앱이 있거나 기능이 제한된 앱이 있는데 이를 독립형 마이크로서비스로 전환하려는 경우 또는 모놀리식 앱을 재사용 가능한 여러 구성요소로 분할하려는 경우 Cloud Functions로 이전하는 것이 좋습니다. 컨테이너화가 애플리케이션 개발 워크플로의 일부가 된 경우, 특히 CI/CD (지속적 통합/지속적 배포) 파이프라인으로 구성된 경우 Cloud Run으로 이전하는 것이 좋습니다. 이러한 시나리오는 다음 모듈에서 다룹니다.

App Engine에서 Cloud Functions로 이전: 모듈 11 참고
App Engine에서 Cloud Run으로 마이그레이션: 모듈 4에서 Docker를 사용하여 앱을 컨테이너화하거나 모듈 5에서 컨테이너, Docker 지식 또는 Dockerfile 없이 컨테이너화하는 방법을 알아보세요.

다른 서버리스 플랫폼으로 전환하는 것은 선택사항이며, 변경하기 전에 앱과 사용 사례에 가장 적합한 옵션을 고려하는 것이 좋습니다.

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

7. 추가 리소스

아래에는 이 마이그레이션 모듈 또는 관련 마이그레이션 모듈과 관련 제품을 자세히 살펴보는 개발자를 위한 추가 리소스가 나와 있습니다. 여기에는 이 콘텐츠에 대한 의견을 제공할 수 있는 위치, 코드 링크, 유용할 수 있는 다양한 문서가 포함됩니다.

Codelab 문제/의견

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

마이그레이션 리소스

모듈 1 (시작) 및 모듈 1b (완료)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 모든 App Engine Codelab 마이그레이션 저장소에서도 액세스할 수 있습니다.

Codelab	Python 2	Python 3
모듈 1	코드	해당 사항 없음
모듈 17 (이 Codelab)	해당 사항 없음	코드 (mod1b-flask)

온라인 리소스

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

App Engine 번들 서비스

App Engine 일반 문서

기타 클라우드 정보

동영상

라이선스

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