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

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

1. 개요

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

이전에는 개발자가 App Engine의 기존 '번들 서비스'에서 마이그레이션해야 했습니다. Datastore와 Memcache처럼 언어 버전을 업그레이드할 수 없었기 때문에 이 두 가지 작업은 연달아 어려울 수 있습니다. 2세대 App Engine 서비스에서 주요 번들 서비스 대부분을 사용할 수 있도록 함으로써, 개발자는 이제 대부분의 번들 서비스를 계속 사용하면서 앱을 최신 런타임으로 포팅할 수 있습니다. 이 Codelab에서는 Datastore 번들 서비스를 계속 사용하면서 샘플 앱을 Python 2에서 3으로 업그레이드하는 과정을 안내합니다 (App Engine NBS 라이브러리를 통해). 대부분의 번들 서비스를 사용하려면 이 튜토리얼에서 다루는 것처럼 코드를 약간만 업데이트하면 되지만 더 광범위한 변경이 필요한 서비스도 있습니다. 이는 '2부'에서 다루며 후속 모듈 및 Codelab을 진행합니다.

다음 실습에서는

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

필요한 항목

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

설문조사

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

읽기만 할 계획입니다

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

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

초급

중급

고급

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

<ph type="x-smartling-placeholder"></ph> 초보자

중급

숙련도

2. 배경

최초의 App Engine 서비스는 2008년에 출시되었으며, 개발자가 애플리케이션을 전 세계에 편리하게 빌드하고 배포할 수 있도록 기존 API 세트 (현재는 번들 서비스로 알려짐)와 함께 제공되었습니다. 이러한 서비스로는 Datastore, Memcache, 태스크 큐가 있습니다. 사용자들은 편리하기는 하지만 App Engine에 연결된 독점 API를 사용할 때 앱의 이동성에 대해 우려하며 앱의 이식성을 높이길 바랐습니다. 이에 더해 App Engine팀은 번들 서비스가 자체 독립형 Cloud 제품으로 발전해 나가면서 이러한 번들 없이 2018년에 차세대 플랫폼을 출시하게 되었습니다.

Python 3로 업그레이드하고자 하는 Python 2 개발자분들께 알려드립니다. 번들 서비스를 사용하는 2.x 앱은 앱을 3.x로 포팅하기 전에 해당 서비스에서 이전해야 했습니다. 이는 한 쌍의 강제적인 연쇄 이전으로, 이는 잠재적으로 문제가 될 수 있습니다. 이러한 전환을 지원하기 위해 App Engine팀은 2021년 가을에 '웜홀'이라는 기능을 도입했습니다. 차세대 런타임에서 실행되는 앱이 이러한 번들 서비스 다수에 액세스할 수 있습니다. 이 출시 버전에는 원래 런타임에서 사용 가능한 모든 서비스가 포함되어 있지는 않지만 Datastore, 작업 대기열, Memcache와 같은 주요 플레이어는 사용할 수 있습니다.

이 Codelab에서는 번들 서비스를 계속 사용하면서 앱을 Python 3으로 업그레이드하는 데 필요한 변경사항을 보여줍니다. 목표는 앱을 최신 런타임에서 실행하여 3.x 업그레이드를 방해하지 않고, 번들 서비스에서 동급의 Cloud 독립형 또는 서드 파티 대안으로 자체 타임라인에 마이그레이션할 수 있도록 하는 것입니다. 더 이상 번들 서비스에서 마이그레이션할 필요는 없지만, 마이그레이션하면 워크로드를 더 잘 처리할 수 있는 플랫폼으로 전환하거나 방금 설명한 최신 언어 버전으로 업그레이드하는 동안 App Engine을 유지하는 등 앱을 호스팅할 수 있는 위치 측면에서 더 많은 이동성과 유연성을 확보할 수 있습니다.

모듈 1 Python 2 샘플 앱은 App Engine NBS를 통해 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 저장소 폴더 'FINISH'에 있는 코드와 유사한 코드로 마무리합니다.

시작: 모듈 1 폴더 (Python 2)
완료: 모듈 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로 Cloud 프로젝트를 설정합니다.
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

변경 후:

runtime: python310
app_engine_apis: true

기타 구성 파일

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

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

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

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

Python 3 런타임 환경에서 사용 가능한 대부분의 번들 서비스에 액세스하려면 main.py의 웹 서버 게이트웨이 인터페이스 (WSGI) 애플리케이션 객체를 래핑하는 짧은 코드가 필요합니다. 래퍼 함수는 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__)

변경 후:

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 앱과 동일해야 합니다.

최종 참고 사항

현재 있는 내용을 모듈 1b 폴더 (완료)와 비교합니다. 이 과정에서 실수를 한 경우 필요에 따라 조정합니다.
앱에서 여전히 webapp2를 사용하는 경우 모듈 0 main.py을 이 페이지의 모듈 1b main.py와 나란히 비교합니다. 그런 다음 모듈 1 Codelab을 진행하여 webapp2에서 Flask로 이전하는 방법을 알아봅니다.

축하합니다. 현재 번들로 제공되는 서비스 사용을 유지하면서 Python 2 App Engine 앱을 Python 3로 포팅하기 위한 첫 단계를 마쳤습니다.

삭제

일반

이 작업이 완료되면 요금이 청구되지 않도록 App Engine 앱을 사용 중지하는 것이 좋습니다. 하지만 추가 테스트 또는 실험을 원하는 경우 App Engine 플랫폼에서 무료 할당량을 사용할 수 있으므로 이 사용 등급을 초과하지 않는 한 요금이 청구되지 않습니다. 이는 컴퓨팅을 위한 것이며, 관련 App Engine 서비스에 대한 요금이 부과될 수 있으므로 자세한 내용은 가격 책정 페이지를 확인하세요. 이 마이그레이션에 다른 Cloud 서비스가 포함된 경우 별도로 요금이 청구됩니다. 두 경우 모두 해당하는 경우 '이 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, 메일, 지연과 같은 다른 번들 서비스에 액세스하려면 코드를 추가로 변경해야 합니다. App Engine 기존 번들 서비스에서 벗어나는 데 중점을 둔 마이그레이션 모듈은 다음과 같습니다.

모듈 2: App Engine에서 CloudN으로
모듈 7~9: App Engine TaskQueue (태스크를 Cloud Tasks로 푸시)
모듈 12~13: App Engine Memcache에서 Cloud Memorystore로
모듈 15~16: App Engine blobstore to Cloud Storage
모듈 18~19: Cloud Pub/Sub로 App Engine TaskQueue (태스크 가져오기)

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

App Engine에서 Cloud Functions로 마이그레이션: 모듈 11 참조
App Engine에서 Cloud Run으로 마이그레이션: Docker로 앱을 컨테이너화하려면 모듈 4를 참조하고, 컨테이너, Docker 지식 또는 Dockerfile 없이 마이그레이션하려면 모듈 5를 참조하세요.

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

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

7. 추가 리소스

아래에는 이 모듈이나 관련 이전 모듈 및 관련 제품을 자세히 살펴보는 개발자를 위한 추가 리소스가 나열되어 있습니다. 여기에는 이 콘텐츠에 대한 의견을 제공할 수 있는 곳, 코드 링크 및 도움이 될 만한 다양한 문서가 포함됩니다.

Codelab 문제/의견

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

마이그레이션 리소스

모듈 1 (START)과 모듈 1b (FINISH)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 모든 App Engine Codelab 이전용 저장소에서도 액세스할 수 있습니다.

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

온라인 리소스

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

App Engine 번들 서비스

App Engine 일반 문서

기타 클라우드 정보

동영상

라이선스

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