GCP; App Engine

# 개요

App Engine은 완전 관리형 서버리스 애플리케이션 플랫폼이라고 합니다. 해당 플랫폼에서 애플리케이션 빌드, 배포하기 때문에 인프라 관리, 배포 구성, 서버 관리 등을 할 필요가 없습니다. 이로부터 개발자의 높은 생산성을 이끌어냅니다.

## 언어 & 도구

자바, PHP, Node.js, Python, C#, .Net, Ruby, Go 등 다양한 언어, 프레임워크를 지원합니다. 또한 IntelliJ, Visual Studio 등 인기 개발 도구를 사용하여 실행도 가능합니다.

## 코드만 추가

인프라 관리 걱정 없이 코드 개발에만 집중할 수 있습니다. 방화벽, IAM, SSL/TLS 인증서 기능을 사용하여 보안을 쉽게 다룰 수 있습니다.

## 비용

사용한 만큼만 지불하면 되는 구조입니다. 트래픽에 따라 자동으로 확장되며 코드가 실행 중일 때만 리소스를 사용합니다.

## 참조

https://cloud.google.com/appengine/?hl=ko

App Engine - 확장 가능한 웹 및 모바일 백엔드를 모든 언어로 빌드  |  App Engine  |  Google Cloud

# App Engine Environment

App Engine 환경은 크게 Standard environment, Flexible environment 두 가지로 구성됩니다.

주로, 특정 버전의 Native Language를 사용한다고 하면 Standard environment, 그 외에 프레임워크나 Docker Images 등 다른 개발 방법을 이용한다면 Flexible environment 환경을 사용하시면 됩니다.

App Engine Flexible의 경우 Compute Engine을 통하여 VM을 받는 것과 비슷해 보이지만, 실제로는 다음과 같은 차이점들이 존재합니다.

• Flexible environment VM instances are restarted on a weekly basis. During restarts, Google's management services apply any necessary operating system and security updates.

• You always have root access to Compute Engine VM instances. By default, SSH access to the VM instances in the flexible environment is disabled. If you choose, you can enable root access to your app's VM instances.

• Code deployments can take longer as container images are built by using the Cloud Build service.

• The geographical region of a flexible environment VM instance is determined by the location that you specify for the App Engine application of your GCP project. Google's management services ensures that the VM instances are co-located for optimal performance.

환경 비교에 관한 자세한 내용은 아래 링크를 참조하시면 됩니다.

https://cloud.google.com/appengine/docs/the-appengine-environments

Choosing an App Engine environment  |  App Engine Documentation  |  Google Cloud

# Google App Engine on IntelliJ

콘솔로 실행하는 내용은 Quick Start 문서를 그대로 따라 하면 되기 때문에 이번 포스트에서는 생략하도록 하겠습니다.

대신, IntelliJ GAE Flexible 배포하는 방법을 정리하도록 하겠습니다.

(GAE Standard는 너무 간단하기 때문에 생략하도록 합니다.)

## "Cloud Code" Plugin 설치

IntelliJ에서 제공하는 Google Cloud Plugin입니다.

## 계정 로그인 진행

우측 상단에 있는 이미지를 클릭하여 로그인을 진행합니다.

## Deploy Project 준비

저 같은 경우는 Spring Boot 기반의 웹앱을 준비하였습니다. 이 부분은 각자 필요한 서비스를 준비하시면 될 것 같습니다.

## Add Framework

이제 준비해둔 프로젝트에 App Engine Flexible Framework를 추가합니다.

app.yaml 파일도 반드시 같이 생성해주셔야 합니다.

## Deploy

이제 Google Deployment 설정을 진행할 수 있습니다. 다음 두 방법으로 설정이 가능한데, 편하신 것을 선택하시면 됩니다.

• Tools → Google Cloud Tools → Deploy to App Engine
• Run/Debug Configurations → Google App Engine Deployment

아래는 설정 화면입니다.

• Server : 서버라 적혀 있지만 Deploy 기록들이 저장되는 라우트(?) 그런 개념으로 이해하시면 될 것 같습니다.

• Deployment : 배포 방식인데, 편하신 방법으로 진행하면 됩니다. 저 같은 경우는 Spring Boot를 사용하다 보니, maven build로 배포를 진행하였습니다.

• Environment : Flexible로 설정되어 있습니다.

• Project : GCP 프로젝트를 클릭하여 선택하시면 됩니다.

• app.yaml : 위에서 App Engine Flexible Framework를 추가하면서 생성된 것으로 자동 읽어오게 됩니다. 읽지 못하면 프레임워크 추가 여부를 다시 확인하거나 intelliJ를 재시작하면 해결되더라고요.

## 배포를 위한 권한

IntelliJ를 통한 배포가 GCP 콘솔에서 직접 작업하는 것이 아니고 Cloud API를 사용하여 호출하는 방식이다 보니 여러 권한 오픈들이 필요합니다. (만약 프로젝트 Owner시라면 이 작업은 필요가 없습니다.)

Auth 관련 링크

• App Engine Flexible API 권한 오픈

ERROR: (gcloud.app.deploy) Enabling the Appengine Flexible API failed on project [stroyparks-project]. You may not have permission to enable APIs on this project. Please ask the project owner to enable the Appengine Flexible API on this project.

API 링크

이것 이외에도 시행착오를 겪으면서 여러 API를 오픈했었는데, 모두 기억이 안 나네요.. 아무래도 Kubernetes처럼 Container 기반으로 동작하다 보니, Container 관련 API들도 오픈이 필요할 것 같습니다.

• Project Access Permission

정말 애먹인 권한 관련 에러입니다. 여러 API를 오픈해줬는데도 해결되지 않던 기억이 있네요.

ERROR: (gcloud.app.deploy) User [oringnam@gmail.com] does not have permission to access project [storyparks-project] (or it may not exist): The caller does not have permission

IAM Role 관리에서 Google Cloud Build Account 권한 오픈이 필요합니다.

## 배포 관련

잡설로 80 포트 배포는 지양하라고 알려드리고 싶네요. nginx가 떠있습니다.

 

# Google App Engine on Maven

이번에는 Maven으로 배포하는 방법을 정리해보겠습니다.

IntelliJ에서 제공하는 플로그인을 이용하여 배포를 하게되면, 간편하긴 하지만 Custom Version Name 등록이 어렵습니다. Timestamp로 자동생성 되기 때문에, Maven Plugin을 이용하여 버전 이름을 직접 넣어 보도록 하겠습니다.

## Cloud SDK 설치

여기에서 설치를 진행하 신 후, 아래 명령어를 통하여 로그인을 진행하시면 됩니다.

gcloud init

## Magen Google App Engine Plugin 적용

<properties>
        <app-engine.collector.server>storyparks-test</app-engine.collector.server>
        <app-engine.collector.version>100k-qa</app-engine.collector.version>
</properties>

<plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>appengine-maven-plugin</artifactId>
                <version>1.3.1</version>
                <configuration>
                    <appEngineDirectory>${basedir}/src/main/appengine/${env}</appEngineDirectory>
                    <deploy.server>${app-engine.collector.server}</deploy.server>
                    <deploy.version>${app-engine.collector.version}</deploy.version>
                    <deploy.stopPreviousVersion>false</deploy.stopPreviousVersion>
                    <deploy.promote>false</deploy.promote>
                </configuration>
</plugin>

# Service 관리

App Engine 계층 구조는 다음과 같습니다. 생성해둔 Applications 아래 Service들이 있고 각 Service는 Versioning 기능이 지원됩니다. Version별로 Traffic 할당이 가능하며, 필요에 따라서 Instance를 구성하여 실행됩니다.

기본적으로 하나 이상의 Default Service가 존재해야 하며, 해당 서비스는 삭제가 안됩니다.

App Engine 계층 구조

App Engine 개요  |  App Engine flexible environment for Python docs  |  Google Cloud

대시보드 이미지를 같이 보여드리고 싶었는데, 개인 계정으로 따로 구성해둔 App Engine 이 없어서 보여드리기 힘드네요. 어렵지 않으니 금방 하실 수 있을 것이라 생각됩니다.

App Engine은 Stack Drivere와 연동되어 있어서 모니터링 기능 지원이 빵빵합니다. 프로세스부터 인프라 로그까지 자세하게 볼 수도 있으니 장애 해결에 크게 도움이 될 거라 생각되네요.

## App Engine Architecture with Service, Projects

App Engine의 서비스들은 서로 독립적으로 동작하지만, 그 아래에서는 여러 자원들을 공유하고 있습니다.

이 구조를 이해하고 마이크로서비스 설계를 진행할 경우, 서비스 성격에 맞추어 Service 레벨 격리를 진행할 것인지, Project 레벨로 격리를 할 것인지 판단하시면 될 것 같습니다.

Microservices Architecture on Google App Engine

Microservices Architecture on Google App Engine  |  App Engine standard environment for Python  |  Google Cloud

# app.yaml

Standard Environment와 달리 Flexible Environment에서는 배포 설정 파일이 정말 중요합니다.

어떻게 보면 App Engine Flexible은 쿠버네티스와 비슷한 면이 많네요.

App Engine Flexible app.yaml Reference

기본적으로 runtime, env 두 개의 값만 잘 써준다면 돌아가기야 하겠지만.. 필요한 서비스를 잘 이용하려면 위 문서를 참고하시는 게 좋을 것 같습니다.

제가 가장 중요하게 생각하는 부분은 Automatic Scaling이네요. 모든 설정이 중요하지만, Scalable이 강점인 App Engine을 잘 쓰려면 이 설정이 중요할 것 같습니다.

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 4
  cool_down_period_sec: 300
  cpu_utilization:
    target_utilization: 0.8

 간단하게 설명드리면, 최소 1개의 인스턴스가 늘 동작하고 있고 최대 4개의 인스턴스까지 생성될 수 있습니다. Scalable 조건은 CPU Usage가 80% 이상이 되면 새로운 인스턴스가 생성되도록 설정하였습니다. 인스턴스 생성 요청은 300초의 "cool_down_period_sec"을 가지도록 하였습니다.

# Optimizing Spring on App Engine

위에서 Automatic Scaling 설정이 어려운 이유는 Flexible Environment의 경우 인스턴스가 생성되고 프로세스가 활성화되기까지 시간이 오래 걸리기 때문입니다. App Engine Flexible의 동작을 간단히 설명하면 다음과 같습니다.

1. VM 인스턴스 생성
2. Container Image 배포
3. 서비스 활성화

안 그래도 비싼 GCP 가격을 조금이라도 줄이려면 이 프로세스 과정을 최적화시켜야 합니다.

Spring Initiating Optimization 포스트에서 스프링의 최적화 방법을 잘 설명하고 있습니다. 기본적으로 Bean과 DI, 스프링의 기본적인 내용을 다루고 있네요. 주요 내용은 다음과 같습니다.

## Automatic Wiring을 지양하자

Auto-wiring을 하면, 초기화 과정에서 Bean들을 Resolve 해야 하기 때문에 초기화 시간이 길어질 수밖에 없습니다.

## XML Validation을 실계에서는 사용하지 말자

이거는 잘 모르겠어요... 죄송..

## Lazy-Initialized Beans을 사용하자

Effective Java에서도 자주 나오는 내용인데요. 초기에 모든 Bean을 등록하지 말고 사용 시점에 Bean을 등록하여 사용한다는 내용입니다.

어떠한 서비스인지에 따라서 적절히 사용하시면 좋을 것 같아요.

## 이름을 통한 Constructor Injection을 피하라

스프링 3.0부터 파라미터가 있는 생성자 등록이 가능한데, 스프링의 특성상 모든 컴파일은 debug flag가 함께 이루어져야 합니다. 디버그가 이루어지려면 파라미터도 함께 저장되어야 하는데, 이는 JVM 캐시에 저장되지 않기 때문에 디스크에 쓰이게 됩니다. 곧 I/O Time이 발생하고 그만큼 성능이 저하되겠죠.

# 기타 이슈

## Random Zone

Flexible Environment는 인스턴스를 생성할 때, 생성 가능한 Zone을 정해진 Region 내에서 랜덤 하게 생성하게 됩니다.

만약 App Engine이 특정 Zone에 Resource를 사용하게 되는 경우, 응답 지연 문제가 발생할 수 있습니다.

참조: App Engine 위치 문서

## Custom Domain

아래 리전에서 Custom Domain 구성 시, 응답 지연 현상이 있다는 게시글이 있습니다. 자세한 내용은 천천히 확인해봐야겠어요.

• us-west2
• us-east4
• northamerica-northeast1
• southamerica-east1
• europe-west2
• europe-west3
• asia-south1
• asia-northeast1
• australia-southeast1

참고자료

Nginx 문제일 가능성도 있을 것 같습니다. App Engine Load Balacner가 nginx 기반이라고 하네요.

어떤 커뮤니티의 저자분께서 App Engine의 단점을 재밌게 서술해주셨네요. 여기에 nginx 이야기가 나옵니다.

App 쪽의 부하 분산은 Google에서 하고 있지만, 그 아래단에 네트워크 로드 밸런싱은 Google LB가 아니기 때문에 이슈가 발생하는 것 같습니다.

출처: https://cloud.google.com/load-balancing/docs/https/

위 그림은 HTTP(s) Cross-region Load Balancing Diagram입니다. Url Map부터는 Google LB가 작업을 해준다고 가정을 하면, 그 앞단 (Global Forwarding Rule, Target Proxy) 쪽에서 문제가 발생하는 것 같네요. 이 부분을 손보기는 쉽지 않을 것 같아요.. 일단 *.appspot.com을 사용하는 수밖에 없을 것 같습니다.

## 서비스 초기 응답 지연

App Engine Flexible 서비스 구조가, VM Instance Create --> Service Container Image Deploy --> Service Activating 이므로, 초기 서비스가 안정적으로 올라오기 전까지 응답 지연이 발생하는 경우가 종종 있습니다.

또 반대로 오랫동안 사용하지 않으면 Instance가 내려가거나 유휴 상태로 들어가기 때문에 이 경우에도 응답 지연이 발생하기도 합니다.

또 하나의 경우로 새로운 버전을 배포하였을 경우 이러한 문제가 발생합니다. 새로운 버전의 앱이 배포되는 경우 높은 Latency가 발생하는데, 구버전과 적절한 트래픽 조절을 통해 이 시점을 넘기는 게 좋을 것 같습니다.

## Auto Scaling시, Instance 여러 개 증가

App Engine에 부하가 늘어나서 Auto Scaling이 이루어질 때, 인스턴스가 여러 개가 동시에 증가하는 모습을 볼 수 있는데, 어떤 방식으로 확장이 이루어지는지 알아둬야 할 것 같아 글을 남깁니다.

# 마무리

App Engine은 진짜 잘 만든 서비스인 것 같습니다. 많은 서비스에서 이용하는 이유를 알 것 같네요. Flexible 성능을 제대로 끌어내려면 좀 더 공부해야 하겠네요..