Google Cloud Run으로 Container image 실행하기

Managed Container-as-a-Service

Serverless Deployment

• remove the needs for us to manage the underlying infraStructure.
• Simplified Application Management.
• Out-of-the-box High availability & Scaling
• "Pay what your Users use" business Model.
  • 서비스를 제공하는 vendor 입장에서는 'do not waste resources like cpu / ram for no reason.'

즉 '내가 사용하는 리소스'에 대한 비용 지출이 아니라, '내 프로덕트를 이용하는 사용자가 쓰는 리소스'에 대한 비용 지출이 이루어진다.

instead of paying what we use,
we are paying for what our users are using.

---

기존에 기업이 클라우드 환경으로 이전하는 방법

• Pay vendors for VM, Storage, Networking... 등등. '누가 이걸 사용할 것인지'는 중요하지 않았다.
• 클라우드 벤더가 만들어내는 모든 리소스에 관련된 비용을 지불해야 했다. 정확히는, every minute of the existence of those resources.
• 이렇게 만들어진 리소스 중 필요없는 건 알아서 찾아내고 삭제해야 했음.

Serverless 기반 환경설정 : Cloud Vendor에게 '내 프로덕트의 사용자가 쓰는 리소스'에 대한 비용만 지불하도록.

• 정확히 말하면 cloud vendor (service provider)는 keep it warm하도록 유지해야 한다.
  keep it warm에 관련한 비용을 청구하지 않을 뿐.

"Serverless production을 사용하는 대상" 을 조금 더 확장하면

• 서비스 사용자 (User)뿐만 아니라 Process도 포함된다.
• Function을 호출하는 모든 Object로 생각할 수 있기 때문.

따라서 Container as a Service는 Function as a Service보다 폭넓은 허용범위와 범용성을 제공하지만,
Managed Service는 그만큼 가격이 비싸다.

 

 

business logic을 제외한 나머지 요소들

• Provision & Management Infrastructure
• Scaling / high Availability 등

을 신경쓰지 않도록 만들어주는 것.

 

Serverless Solution을 평가할 때 중요하게 작동해야 하는 요소들

1. Allow Local Development.
2. Leverage common & widely accepted denominators ex) container image.
3. based on some sort of a standard.
4. should not be too restrictive.
5. (almost) support any type of application.

 

---

Google Cloud Run

Fully Managed Compute Platform for deploying / scaling "containerized application" quickly and securly.

1. container image를 사용하기 때문에, 어떤 언어를 써서 프로그램을 만들어도 상관없다 - Any application Server / Any dependencies.
2. application 동작에 필요한 모든 것들이 container 안에 있기만 하면 google cloud run에서 실행될 수 있다.
3. Automate scaling / redundancy와 monitoring, logging,

가장 큰 특징은 Knative를 사용한다는 것.

---

Prerequisite

• google cloud sdk (gcloud): https://cloud.google.com/sdk/docs/downloads-interactive
• 구글계정. google cloud에 project / billing registry / cloud run service enabled 권한이 있어야 한다.
• 해당 gist 참고해서 프로젝트 환경을 세팅한다. https://gist.github.com/vfarcic/2aa8ee4a6451fd762b1a10799bbeac88
  • 내 경우는 무료 크레딧 300 주는 계정을 새로 만들었음.
• brew install terraform 으로 테라폼 cli를 설치한다.
• docker, jq 설치 필요.

Google Container Registry (GCR) 에서 제공하는 예시코드를 사용할 예정.

• gcloud auth configure-docker
  
  
  
  

# 예시용 docker image 받아와서 gcr.io에 배포하기
docker image pull vfarcic/devops-toolkit-series

export IMAGE=gcr.io/$PROJECT_ID/devops-toolkit-series:0.0.1

docker image tag vfarcic/devops-toolkit-series $IMAGE

docker image push $IMAGE

# 현재 gcloud container image의 리스트 확인하기 
gcloud container images list --project $PROJECT_ID
# 브라우저로 확인하기
open https://console.cloud.google.com/gcr/images/$PROJECT_ID

• 콘솔로 gcr image 리스트 확인하기.
  
  
  
  
• 브라우저에서 확인하기
  
  

---

gcr에 올린 이미지를 Cloud Run으로 실행할 예정.

• 어느 region? -> 환경변수로 지정한다.
  export REGION=us-east1
• 요청의 authorization여부 결정하기.
  -> 일단은 모두가 접근 가능하도록 설정.
• 컨테이너 안에서 실행될 process port 정의하기.
  -> 80
• replica가 관리할 수 있는 concurrent request 정의하기.
  -> 예시에서는 100으로 설정 (하나의 replica에서 100의 concurrent 요청 처리 가능)
  • FaaS는 일반적으로 1 request -> 1 single Replica로 관리함. 따라서 request 개수만큼의 replica를 사용하는 게 일반적이다.
    • 일반적으로, 최대한 많은 요청을 Performance 문제 없이 처리해내는 것 + CPU / Memory 리소스를 적게 사용하는 것이 이상적이다.
    • = faas의 경우 fast but ineffective.
• cloud run이 어느 프로젝트에서 실행될 것인지 체크. managed service(cloud run) / k8s cluster

실행 명령어

• gcloud run deploy devops-toolkit-series --image $IMAGE --region $REGION --allow-unauthenticated --port 80 --concurrency 100 --platform managed --project $PROJECT_ID

실행 결과 확인하기

• gcloud run services list --region $REGION --platform managed --project $PROJECT_ID
  

 

Revision 확인하기

• gcloud run revisions list --region $REGION --platform managed --project $PROJECT_ID

Service 확인하기

• gcloud run services describe devops-toolkit-series --region $REGION --platform managed --project $PROJECT_ID --format yaml

 

---

 

FaaS가 높은 platform Dependency를 요구한다면, cloud run으로 대표되는 knative은 보다 개방적인 형태를 띄고 있다.
컨테이너 이미지만 맞춰주면 어디서든 코드를 실행해줄 수 있기 때문.

 

---

만들어진 url을 받아서 jq로 실행하기

• export ADDR=$(gcloud run services describe devops-toolkit-series --region $REGION --platform managed --project $PROJECT_ID --format json | jq -r ".status.url")
• open $ADDR

 

웹 ui로 확인하고 싶다면 open https://console.cloud.google.com/run?project=$PROJECT_ID 

 

 

 

 

stress test

• kubectl run siege --image yokogawa/siege -it --rm -- -d1 -r3 -c330 "$ADDR"
• 아래 스크린샷은 k8s 1.16까지 가능했던 명령어로, 1.17 이후부터는 siege를 실행하려면 위처럼 변경해야 한다.
  • -d1 : 1초 간격을 두고 요청을 보냄
  • -r3 : 테스트를 세 번 반복
  • -c330 : 330개의 요청을 concurrent하게 보냄
  • 따라서 위 명령어는 330개의 요청을 1초 간격으로 보내는 테스트를 세 번 반복한다는 뜻.
    따라서 아래의 결과와는 조금 다르다.

리소스 삭제

• gcloud run services delete devops-toolkit-series --region $REGION --platform managed --project $PROJECT_ID

---