서문
GCA 자격증 취득을 위해 들은 강의 내용 요약이다. 섹션 9의 내용을 담고 있다.
App Engine의 특징
- 종단간 응용프로그램 지원
- 다양한 언어 지원, 커스텀 런타임 지원
- 다른 구글 서비스들과 높은 연동성
- 앱 엔진 자체에는 비용이 없으나 컴퓨팅 인스턴스를 사용한다면 그 비용을 지불해야 한다.
- 자동 스케일링, 로드밸런싱, 버젼설정과 업데이트, health monitoring, 트래픽 분할 가능
- compute Engine과의 차이점은 App Engine은 IAAS가 아닌 Paas이고 serverless 하다. 설정에 있어 compute Engine보다 유연하지 못해 GPU 추가 같은 옵션을 할 수는 없다. 그래서 자바스크립트나 파이썬 처럼 간단한 걸 올릴떄 좋다.
App Engine의 환경
- App Engine의 환경에는 크게 2가지 Standard와 Flexible이 있다.
- Standard: 언어별 sandbox 기반, isolation하다.
- v1:Java,python,PHP,Go 의 구버젼 가능, python과 PHP만 runtime으로 쓸수 있음, 네트워크 연결 제한됨, 화이트리스트 라이브러리만 사용가능
- v2:위의 것에서 Ruby랑 Node.js 추가됨. network 다 쓸수 있고, extension에 제한 없다. - Flexible: 가상 머신 사용, Docker 사용하여 유연하다.
- 가상머신 사용하기에 이론상 어떤 언어든 가능
- version2의 언어들 runtime 지원
- 백그라운드 프로세스와 디스크 연결 가능
Feature | Standard | Flexible |
가격 기준 | 인스턴스 시간 | CPU, 메모리 디스크 할당량 |
Scaling | manual, automatic, basic 가능 | manual, automatic 가능 |
Scaling to zero | 가능 | 최소 1개, 불가능 |
Instance startup time | 몇초 정도 | 몇분 정도 |
rapid scaling | 가능 | 불가능 |
max, request timeout | 1 | 60분 |
local disk | 대부분 /tmp에 적을 수 있음(python과 php 제외) | 디스크 시작할때만 일시적 유지 |
ssh for debugging | 불가능 | 가능 |
App Engine의 구조
- Application(1개의 app, project)>services(modules)>versions(여러개 존재 가능),트래픽 나눌 수 있음> instance
- 마치 하나의 컨테이너처럼 작동한다
scaling의 3가지 종류
- Automatic:
- 부하량에 따라 자동으로 맞추어줌(CPU 사용량, 처리량, 최대 동시요구 설정 가능 )
- 최대와 최소 수 인스턴스 설정 가능 - Basic :
- request를 받을때 instance 생성함 (request 0이면 shutdown됨)
- 비용 적음
- flexible app engine에는 안됨
- 대기 시간 김
- 최대 인스턴스와 Idle timeout 설정가능 - Manual:
- 수동임, 시간에 따른 인스턴스 수 실행 구성
- 사용량 정확히 예측가능할때 좋음
트래픽 분할, app.yaml, 라우팅
- `set-traffic --splits=v3 .5,v2=.5` 로 버젼에 따른 트래픽 분할 가능, 그 외에도 app Engine> version으로 트래픽 나눌 수 있음. 그 version에 따라 URL이 미묘하게 다르다.
- app.yaml에서 runtime: 언어, api_version, instance_class, serivce: 서비스 이름, inbound-services, 환경변수, handler, automatic scaling 을 설정할 수 있다.
- 라우팅 하는 방법
1. URL로 라우팅 하기 기본과 다르게 특정 서비스는 ProjectID 앞에 서비스가 붙고, 그 서비스 중에서도 특정 버젼은 앞에 버젼이 한번 더 붙음
2. dispatch.yaml 파일 이용
3. 클라우드 로드밸런싱 이용
downtime 없이 새로운 버젼을 배포하는 법
- 1. 그냥 `gcloud app deploy`로 생각 안하고 강제 이주시키기
- 2. `gcloud app depoly --no-promote` 로 입력한 후
- 2-1. `gcloud app services set-traffic s1 --splits V2=1` 로 한번에 옮기기
- 2-2. `--migrate` 로 자동으로 점진적으로 이동하게 하기
- 2-3. `gcloud app services set-traffic s1 --splits=v2=.5,v1=.5` 로 수동으로 비율 조정해서 옮기기
사용자의 수신을 분할하는 법
`gcloud app services set-traffic --split-by` 뒤에 옵션으로 붙여주면서 분할 가능
1. IP: 근데 장소 이동이나 회사 VPN 사용 등에 따라 달라짐
2. Cookie:유저별 정확히 분배 가능
3. 무작위
기억해야할 명령어들
`gcloud app browse/create/deploy/describe/open-console` 알아야 하는 명령어 이다. 그 외에도 로그 보여주는 `gcloud app logs tail` 과 서비스되는 지역을 보여주는 `gcloud regions list` 명령어가 있다. regions 자리에 instances나 services로 바꾸어 list 뽑아볼 수 있다.
- `gcloud app instances scp --service=s1 --version=v1 --recurse local_dir i1:remote_dir` 은 로컬디렉토리에서 scp(secure copy protocol) 명령으로 flexible instance로 파일을 보내는 것이다
- `gcloud app instances ssh --service=s1 --version=v1 i1`은 SSH 접속 명령어로 인스턴스에 원격으로 접근해 서비스 s1 버젼 v1 시행중인 i1 에 SSH로 접근한다는 뜻
- `gcloud app services browse/delete/describe/list/set-traffic` 와 `gcloud app versions browse/delete/describe/list/migrate/start/stop` 역시 어떻게 쓰이는지 알아야 하는 명령어 이다.
cron.yaml, dispatch.yaml
- cron.yaml 파일을 만들어 미리 정의된 작업을 정해진 간격으로 실행시킬 수 있다. 당연히 gcloud app deploy cron.yaml 같은 식으로 실행하고 HTTP GET 요청을 구성한다.
- dispatch.yaml은 경로에 따라서 routing 규칙을 override 하고, queue.yaml은 task queues에서 parameters를 픽업하고 재구성한다.
기억해야할 app engine의 특징들
- 1. app engine은 regional하여 region을 변경할 수 없다.
2. 간단하고(micro) 다양한(multiple) service에 적합하다. 지원되는 언어(Java, python)를 사용한다면 standard v2를 사용하고, 지원하지 않는 언어(C#, C++)로 contanizerd app을 원한다면 flexible을 써라
3. flexible 앱 엔진은 컨테이너 수를 0까지 줄일수 없다, 최소 1이다. 만약 0까지 줄이는 걸 원한다면 standard를 써라
4. resident와 dynamic 인스턴스를 조합하라. resident는 지속적으로 작동하고 dynamic은 원할때만 작동하는 것이다. 그래서 비용 최소화를 원하면 dynamic을, 계속 실행되는 것이 중요하다면 resident를 써서 둘의 조합으로 최적의 효율을 만들어라
시나리오들
1. 같은 프로젝트에 2개의 앱 엔진을 쓰고 싶어요.
- 불가능함, 하나의 프로젝트에는 하나의 앱 엔진만을 사용 가능함. 대신 서비스나 버젼은 다양하게 할 수 있음
2. 두개의 앱 엔진 서비스를 같은 앱에 다가 넣고 싶어요.
- 가능함. 위에서 말했듯이 하나의 앱에 다양한 서비스 들어가는 건 가능함. 버젼도 마찬가지로 하나의 서비스에 다양한 버젼 가질 수 있고
3. 구글 앱 엔진을 다른 지역으로 옮기고 싶어요.
- 불가능함, 새로운 프로젝트 파서 새로운 앱 엔진과 지역설정 하시길
4. Canary 방식으로 배포하고 싶어요.
- 가능함. `gcloud app deploy --no-promote` `gcloud app services set-traffic s1--splits v1=0.9, v2=0.1` 같은 식으로 no promote 옵션으로 배포된 새버젼을 기본 버젼으로 자동 트래픽 설정하지 않고 후에 수동으로 새 버젼에 트래픽 할당하는 방식이다.
'CS 내용 요약, 지식 > Google Cloud Associate' 카테고리의 다른 글
Google Cloud Associate 강의 요약: Service (0) | 2024.11.24 |
---|---|
Google Cloud Associate 강의 요약: Load Balancer (1) | 2024.11.24 |
Google Cloud Associate 강의 요약: Instance Group (0) | 2024.11.24 |
Google Cloud Associate 강의 요약: Section 5 (0) | 2024.11.19 |
Google Cloud Associate 강의 요약: Section 4 (3) | 2024.11.08 |