[GCP Associate Cloud Engineer] App Engine

컴퓨터/클라우드

[GCP Associate Cloud Engineer] App Engine

sidedoor 2025. 1. 14. 16:40

앱 엔진

앱 엔진(App Engine)은 GCP에서 제공하는 관리형 서비스 중 하나로 2008년에 출시되어 클라우드 컴퓨팅의 초창기부터 존재했던 관리형 서비스 중 하나이다.

앱 엔진은 GCP에서 애플리케이션을 배포하고 확장하는 가장 간단한 방법 중 하나로, 종단 간 애플리케이션 관리를 제공한다.

앱 엔진의 주요 기능

- 다양한 언어 및 런타임 지원

앱 엔진은 Go, Java, .NET, Node.js, PHP, Ruby, Python과 같은 여러 언어와 사전 구성된 런타임 환경을 지원한다.

이는 컨테이너화된 애플리케이션 실행을 지원하며, 컨테이너를 생성하고 원하는 특정 언어로 코드를 작성할 수 있다.

- GCP 서비스와의 긴밀한 통합

앱 엔진은 GCP의 다른 서비스들과 원활히 통합된다.

예를들어 Cloud SQL과 같은 관계형 데이터베이스, Cloud Storage와 같은 객체 스토리지, 큐 서비스(Queue Service)와의 통신이 가능하다.

이러한 통합은 애플리케이션 개발 및 관리 프로세스를 크게 간소화한다.

- 비용 구조

앱 엔진 자체에는 사용료가 없다. 하지만, 앱 엔진을 통해 사용한 VM과 같은 컴퓨팅 리소스=에 대한 비용이 청구된다.

- 자동화 기능

Auto Load Balancing을 통해 애플리케이션 사용량에 따라 부하를 자동으로 분산시킨다.

Auto Scaling을 통해 사용량이 증가하면 실행 중인 인스턴스를 자동으로 늘리고, 사용량이 줄어들면 줄여준다.

- 버전 관리 및 트래픽 분할

앱 엔진은 앱의 다양한 버전 관리를 제공한다.

여러 버전을 동시에 실행하고, 각 버전 간의 트래픽 분할이 가능한데, 예를 들어 최신 버전(V2)에 트래픽의 30%를 보내고

기존 버전(V3)에 트래픽의 70%를 보낼 수 있다.

이를 통해 새로운 애플리케이션을 점진적으로 배포하거나 실험적으로 테스트할 수 있다.

- 운영 관리

앱 엔진은 플랫폼 업데이트를 자동으로 관리하며, 실행 중인 앱의 상태를 모니터링한다.

개발자는 앱 엔진의 무중단 업데이트(Rolling Updates)를 통해 손쉽게 애플리케이션을 최신 상태로 유지할 수 있다.

컴퓨트 엔진과의 비교

앱 엔진은 컴퓨트 엔진과 비교했을 때, 더 단순하고 관리가 쉬운 옵션을 제공한다.

컴퓨트 엔진은 IaaS로, 사용자가 직접 VM을 관리한다.

따라서 사용자가 원하는 운영체제를 선택하고 Python과 같은 프로그램을 직접 설치할 수 있다.

그리고 GPU나 CPU와 같은 하드웨어 사양을 직접 결정하고 관리한다.

다만, 운영체제 설치, 방화벽 구성, 인증서 설정, 애플리케이션 확장 등 모든 설정과 관리가 사용자의 책임이다.

앱 엔진은 PaaS로, 서버리스 환경을 제공한다.

서버 관리를 할 필요가 없으며, 모든 운영 및 유지보수는 Google이 담당 하기 때문에 간단한 웹 애플리케이션을 빠르게 배포하려는 경우 적합하다.

다만 GPU 추가, 특정 하드웨어 선택 등은 불가능하다.

App Engine 환경

Standard 환경

Standard 환경에서는 애플리케이션이 언어별로 제공되는 샌드박스 안에서 실행된다. 각 언어별로 미리 구성된 샌드박스를 제공하며, 이는 Java, Python, PHP, Go 등의 언어에 대해 각각 별도의 샌드박스를 포함한다.

운영체제, 디스크, 다른 애플리케이션과의 충돌이나 의존성을 고려할 필요가 없고 개발자는 오직 자신의 애플리케이션 코드만 신경 쓰면 된다. 다만, 언어별로 미리 구성된 샌드박스의 제약이 있을 수 있다.

버전

- v1 (구버전)

지원 언어: Java, Python, PHP, Go

제한 사항: Python과 PHP 런타임에는 네트워크 접근 제한이 있다. 특정 화이트리스트 확장과 라이브러리만 사용 가능하다. Java와 Go의 경우에는 네트워크 제한이나 라이브러리 사용 제한이 없다.

- v2 (신버전)

지원 언어: Java, Python, PHP, Node.js, Ruby, Go 등 최신 언어 버전.

제한 사항이 없어 모든 네트워크 접근 가능하고, 언어 확장 및 라이브러리에 대한 제한이 없다.

Standard환경의 경우 C++ 또는 C 애플리케이션 실행이 불가능 하다.

Flexible 환경

Flexible 환경에서는 애플리케이션이 Docker 컨테이너 내에서 실행된다. 이는 Google Cloud의 Compute Engine 가상 머신 위에서 동작하며, 보다 유연한 환경을 제공한다.

Python, Java, Node.js, Go, Ruby, PHP, .NET 등의 언어를 지원하고, Docker 이미지를 직접 빌드하여 배포하면 다른 언어를 사용할 수 있다.

로컬 디스크와 배경 프로세스에 접근 가능하고,가상 머신의 모든 기능을 활용 가능하다.

결론적으로 Flexible 환경은 높은 유연성을 제공하며, 사용자가 직접 컨테이너를 정의할 수 있다. 이는 특히 C++ 또는 C와 같은 언어를 사용할 때 유용하다.

Standard vs Flexible 비교

특성	Standard	Flexible
실행 환경	언어별 샌드박스	Docker 컨테이너
제약	일부 제한 사항(v1), 제한 없음(v2)	제한 없음
지원 언어	Java, Python, PHP, Node.js, Ruby, Go (C/C++ 미지원)	모든 언어 지원 (Docker 이미지 빌드 필요)
네트워크 접근	제한 있음(v1), 제한 없음(v2)	제한 없음
로컬 디스크/배경 프로세스	지원하지 않음	지원 가능
사용 사례	간단하고 빠른 배포가 필요한 애플리케이션	고유한 환경 설정 또는 고성능이 필요한 애플리케이션
비용 효울성	상대적으로 저렴하며, 자동으로 확장되는 애플리케이션에 적합	유연성을 제공하지만, 가상 머신 사용으로 인해 비용이 더 높다
확장성	Google의 자동 확장 기능을 사용하여, 트래픽 증가에 따라 애플리케이션 인스턴스를 자동으로 추가하거나 제거	확장 가능하지만, 사용자가 확장 구성을 더 세밀히 조정가능
가격 정책	인스턴스 시간(instance hours) 기반 과금	사용된 CPU, 메모리, 부착된 디스크(Persistent Disk) 용량 기반 과금.
확장 옵션	Manual, Basic, Automatic (모두 지원).	Manual, Automatic (Basic은 지원하지 않음).
제로 스케일링 지원	지원 (로드가 없을 경우 인스턴스를 0으로 축소 가능).	지원하지 않음 (항상 최소 1개의 인스턴스가 실행되어야 함).
인스턴스 시작 시간	초 단위 (빠른 시작 가능).	분 단위 (느린 시작).
스케일링 속도	빠른 확장 및 축소 지원 (초 단위 시작 시간 덕분).	느린 확장 및 축소 (인스턴스 시작 시간이 분 단위).
최대 요청 타임아웃	1~10분 (짧은 요청 시간에 적합).	최대 60분 (긴 요청 시간에 적합).
로컬 디스크 접근	Python, PHP를 제외하고 /tmp 폴더 사용 가능.	로컬 디스크 부착 가능. 하지만 임시 저장소로, 인스턴스 재시작 시 데이터 소멸.
디버깅 (SSH)	SSH를 통한 디버깅 불가.	SSH를 통해 디버깅 가능 (가상 머신 접근 가능).

인스턴스 확장 옵션

확장 방식은 각기 다른 워크로드와 요구 사항에 맞춰 인스턴스를 관리하는 방법이다.

1. 자동 확장 (Automatic Scaling)

자동 확장은 애플리케이션의 traffic에 따라 인스턴스를 자동으로 확장하거나 축소하는 방식이다. 이는 지속적으로 트래픽이 발생하는 워크로드에 적합하며, 아래와 같은 다양한 설정 기준을 지원한다.

CPU 활용도(CPU Utilization): 특정 CPU 사용률 임계값을 기준으로 확장.

처리량(Throughput): 초당 처리량 목표를 설정하고 이를 기준으로 확장.

동시 요청 수: 한 인스턴스에서 처리할 수 있는 최대 동시 요청 수를 설정 가능.

인스턴스 제한: 최대 및 최소 인스턴스 수를 설정하여 리소스 사용을 제어.

이는 지속적인 워크로드에 최적화되어 있어 트래픽에 따라 자동으로 리소스를 최적화하여 관리 부담이 감소한다.

App Engine Standard와 Flexible 환경 모두에서 지원한다.

2. 기본 확장 (Basic Scaling)

기본 확장은 요청이 들어올 때만 인스턴스를 생성하며, 요청이 없을 경우 인스턴스를 완전히 종료할 수 있다. 이는 간헐적인 워크로드에 적합하며, 비용 절감에 효과적이다.

요청 기반 확장: 요청이 들어올 때만 새로운 인스턴스를 생성.

제로 스케일링(Zero Scaling): 요청이 없을 경우 인스턴스를 0으로 축소 가능.

유휴 시간 설정: 요청이 없는 상태가 일정 시간 지속되면 인스턴스를 종료.

사용하지 않을 때 리소스를 사용하지 않아 비용이 절감되어 트래픽이 간헐적일 때 적합하다.

다만, 높은 지연 시간으로 인해 요청 시 새 인스턴스를 생성해야 하므로 응답 시간이 길어질 수 있다.

App Engine Flexible 환경에서는 지원하지 않고, 오직 Standard 환경에서만 사용 가능하다.

3. 수동 확장 (Manual Scaling)

수동 확장은 지정된 고정 인스턴스 수를 설정하고, 필요에 따라 사용자가 직접 조정하는 방식이다. 이는 특정 워크로드를 정확히 예측할 수 있는 경우에 적합하다.

인스턴스 수를 사용자가 직접 설정하고, 로드가 변하더라도 설정된 인스턴스 수가 고정적으로 유지된다.

설정이 간단하며, 예측 가능한 워크로드에 적합하지만, 수동으로 관리해야 하므로 운영 부담 증가하고, 로드 예측이 어렵다면 비효율적일 수 있다.

앱 엔진 실행

앱 엔진을 실제로 사용하려면 다음과 같이 하면된다.

먼저 GCP의 앱 엔진에서 앱 만들기를 통해 생성을 한다.

그 후 App Engine에 배포하기 위해서 gcloud에 아래와 같은 명령어를 입력해 주면 된다.

gcloud app deploy

다만 처음의 경우 아래와 같이 실행했을때 권한이 없어 실행되지 않는 문제가 발생한다.

이러한 문제가 발생하면 IAM에 들어가 해당하는 프로젝트의 역할에 스토리지 객체 사용자 권한을 추가해주면 된다.

권한이 추가되면 아래와 같이 실행이 잘 되는 것을 확인해 볼 수 있다.

그리고 실행결과 서비스되는 주소로 들어가면 아래와 같이 파일이 잘 실행되는 것을 볼 수 있다.

App Engine 관리

App Engine 대시보드

특정 버전에 대한 메트릭(로드 상태, 비용, 현재 트래픽 등)을 확인하고, 서버 및 클라이언트 오류 상태를 확인 가능하다.

기본 서비스가 생성되어 있으며, 여기서 현재 활성화된 버전을 볼 수 있다.

Versions 탭에서 트래픽을 처리 중인 버전과 배포된 버전을 확인할 수 있다.

현재 실행 중인 인스턴스를 Instances 탭에서 볼 수 있다.

Google Cloud CLI

# 현재 생성된 서비스 확인
gcloud app services list

# 배포된 모든 버전을 확인, 각 버전의 트래픽 처리 상태와 활성화 여부도 확인 가능
gcloud app versions list

# 인스턴스 목록 보기
gcloud app instances list

새로운 내용 배포

# 새로운 버전 배포
gcloud app deploy --version=v2

--version 옵션을 사용해 새 버전을 지정하여 배포 가능.

app.yaml에 설정된 프로젝트, 서비스, 버전 등의 구성 파일을 기준으로 배포가 진행된다.

이때 변경된 파일만 Google Cloud Storage에 업로드되고, Cloud Build가 백그라운드에서 패키지를 빌드하고 배포한다.

새 버전이 배포되면 트래픽이 자동으로 새로운 버전으로 전환되고, 이전 버전은 여전히 실행 중이지만 트래픽은 처리하지 않는다.

이전 버전은 실행 중이지만 트래픽을 처리하지 않으며, 특정 URL로 접근 가능하다.

따라서 기본 URL은 서비스명.도메인으로 확인이 가능하고 만약 다른 버전을 확인하고 싶으면 버전명.서비스명.도메인으로 확인이 가능하다.

새 버전 배포와 트래픽 자동 전환 방지

gcloud app deploy 명령어를 사용하면 새 버전을 배포하며, 기본적으로 트래픽이 자동 전환된다.

상황에 따라서 배포는 하지만 배포된 버전이 문제가 없는지 확인을 해보고싶어 실제 반영은 안했으면 하는 상황이 있을 수 있다. 이때 트래픽 전환을 방지하려면 --no-promote 옵션을 사용한다.

gcloud app deploy --version=v3 --no-promote

--no-promote 옵션: 새 버전을 배포하면서 기존 트래픽 유지

이 명령어는 V3을 배포하지만, V2가 여전히 모든 트래픽을 처리하게 한다.

V3은 실행 상태이지만 기본 URL로는 접근할 수 없으며, 특정 URL로만 접근 가능하다.

배포된 V3이 올바르게 작동하는지 테스트하려면 특정 버전의 URL을 확인해야 한다.

gcloud app browse --version=v3

해당 URL로 접근하여 V3이 제대로 동작하는지 테스트한다.

트래픽 분할 설정

새 버전으로 트래픽을 점진적으로 이전하려면 트래픽 분할 설정을 사용한다. 이를 통해 트래픽의 일부를 새 버전으로 보내면서 안정성을 확인할 수 있다.

트래픽 분할 설정 명령어

gcloud app services set-traffic --splits=v2=0.5,v3=0.5

이 코드는 V2와 V3이 각각 50%의 트래픽을 처리하도록 설정한다.

--splits 옵션을 사용하여 각 버전의 트래픽 비율을 지정

트래픽 분할 기준

IP 기반 분할

기본 설정으로 동일한 IP에서 발생하는 모든 요청은 하나의 버전으로 라우팅된다.

예를 들어 IP 주소를 기준으로 트래픽을 나누는 경우, 동일 IP는 항상 동일한 버전을 호출한다.

랜덤 분할

요청을 랜덤하게 각 버전으로 분배한다.

gcloud app services set-traffic --splits v2=0.5,v3=0.5 --split-by=random

랜덤 분할은 테스트 중에 동일한 IP에서 여러 버전의 응답을 확인할 수 있어 유용하다.

쿠키 기반 분할

애플리케이션이 특정 쿠키 값을 설정하여 요청을 특정 버전으로 라우팅한다.

트래픽 분할 테스트

URL에 주기적으로 요청을 보내 트래픽 분할 결과를 확인한다.

watch curl <서비스 URL>

2초마다 GET 요청을 보내, 응답에서 결과를 확인한다.

트래픽 완전 전환

새 버전이 안정적으로 작동한다고 판단되면 모든 트래픽을 새 버전으로 전환할 수 있다.

gcloud app services set-traffic --splits v3=1

V3이 모든 트래픽을 처리하도록 설정한다.

보안 파일 복사(SCP)

App Engine Flexible에서 로컬 파일을 인스턴스로 복사.

gcloud app instances scp <LOCAL_PATH> <REMOTE_PATH> --instance=<INSTANCE_ID>

SSH 접속

App Engine Flexible의 VM에 직접 접속하여 디버깅 가능.

gcloud app instances ssh <INSTANCE_ID>

요약

App Engine은 지역 기반 서비스이며, 프로젝트와 지역은 한 번 설정되면 변경할 수 없다.
단순한 마이크로서비스에 적합하며, 복잡한 컨테이너 오케스트레이션에는 Kubernetes가 더 적합하다.
App Engine Standard는 요청이 없을 때 0으로 축소 가능하며, 간헐적인 트래픽 처리에 유리하다.
App Engine Flexible은 항상 최소 1개의 컨테이너를 유지하며, 지속적인 트래픽 처리에 적합하다.
비용과 성능을 고려해 고정 인스턴스와 동적 인스턴스를 적절히 조합해야 한다.