Google App Engine 의 표준/유연한 환경 선택 시 알림 및 설정 고려 사항

TL;DR

GAE의 표준 환경 vs 유연한 환경

Zenn에서 최근 표준에서 유연성으로의 과도

표준의 가격은 결코 싸지 않다

부드러운 환경으로 확대/축소를 더욱 잘 제어할 수 있음

GAE의 낙찰 설정app.yaml을 미리 하지 않으면 귀찮아

개시하다

Zenn의 백엔드는 Rails(API 모드) on Google App Engine(GAE)으로 구성됩니다.
https://zenn.dev/catnose99/articles/zenn-dev-stack

GAE 환경(표준 vs 유연성)

GAE는 표준 환경과 부드러운 환경을 가지고 있다.서로 다른 점은 공식 문서App Engine 환경 선택를 읽는 것이 좋을 것이다. 주요 점은 다음과 같다.
표준
연성
운행 시간
사용 가능한 언어 버전 결정
실행 가능한 Docker 컨테이너
최소 인스턴스
0
1(항상 1 이상 실행)
무료 테두리
있다
없음
메모리 CPU
인스턴스 클래스당 1개
비교자유롭게 설정할 수 있어요.
인상

표준 환경을 쉽게 시작할 수 있음

부드러운 환경에 대해 더욱 세밀한 설정을 할 수 있다

이런 느낌인가?

반드시'비용이 싼 것이 표준'은 아니다.

구글이 발견한 정보를 읽으면 많은 사람들이 표준 환경이 더 싼 것 같다는 인상을 갖게 된다.나도 이런 생각에서 당연히 표준 환경을 선택했다.그러나 그 결과 젠의 경우 유연한 환경의 비용이 크게 낮아진다.

Zenn의 경우

구체적인 예가 있는 사람이 읽으면 즐겁기 때문에 치욕을 버리고 실제 쓴 GAE의 비용을 올린다.아이고.

※ 비용의 추이는 서비스 방문량과 거의 상관 없음
피크 타임이 거의 1만 엔/일이니 설정과 환경을 다시 생각해 보면 ¥500/일이면 된다.설정이 틀리지 않았다면 전매자로부터 PS5를 구매할 수 있었을 것이다.
다음은 무슨 일이 일어났는지, 어떤 대책을 취했는지 설명할 것이다.

표준 환경을 사용할 때는 자동 배율 조정 설정에 주의해야 합니다.

GAE에서 확대/축소 설정은 app.yaml에 표시됩니다.표준 환경에서 다음과 같이 지정합니다.
app.yaml

# 自動スケーリング以外の項目は省略
automatic_scaling:
  target_cpu_utilization: 0.6 # インスタンスを起動するためのCPU使用率のしきい値
  min_instances: 2 # 最小インスタンス数
  max_instances: 20 # 最大インスタンス数
  min_idle_instances: 1 # アイドル状態インスタンスの最小数
  max_idle_instances: 20 # アイドル状態のインスタンスの最大数
  max_concurrent_requests: 80 # これ以上の同時リクエストで新しいインスタンスを立ち上げる（デフォルトは10）

젠은 이 같은 설정에서 왠지 교통에 큰 변화가 없어도 요금이 나날이 높아지고 있다.만 위안에 육박하는 것도 이 설정의 때다.
GCP의 메트릭 익스플로러에서 이상한 점이 확인된 결과, 활약 실례는 2~3을 막론하고 아이돌 상태(대기 상태)의 실례는 10~20개 정도 서 있었다.
포획 기록을 위에 올리려고 했는데 메트릭 익스플로러가 거슬러 올라갈 수 있는 기간이 제한되어 있어서 표시하지 못했는데...
GAE에서 아이돌 상태의 실례도 유료 대상이기 때문에 10~20개만 유료로 하면 하루에 1만 위안씩 받는 것도 이상하지 않다.

대책:maxidle_instances 설정

그러자 max_idle_instances의 값이 20에서 2로 바뀌었고 아이돌 상태의 실례와 바보가 일어서지 못해 GAE의 비용이 뚝 떨어졌다.

교통량에는 큰 변화가 없지만, 하루가 다르게 아이돌 상태의 실례 수가 늘어나는 이유는 아직 밝혀지지 않았다.

10초 이상 지연되는 문제가 거의 없음

비용이 매우 비싼 것 외에 또 하나의 문제가 있다.방문자가 급증할 때 가끔 반응이 10초 이상 걸리는 현상이다.

로그에서 볼 수 있듯이 지연은 Rails의 시작 시간rails server이다.즉, Rails가 시작 중인 인스턴스에 요청을 보낸 것입니다.
GAE의 표준 환경간편한 예열 설정 가능에서 어느 정도 대책을 세울 수 있지만 방문자가 급증하면 문제가 발생할 수 있다.
※ Gem 읽기 지연 등 라일스 시동 속도를 높이는 방향에서도 대책이 있었지만, 뚜렷한 효과는 없었다.

부드러운 환경에서 실례적인 준비를 검사할 수 있다

대책에 어려움을 겪었을 때 선생님께서는 GAE의 유연한 환경에서 준비검사(readiness check)를 설정할 수 있다고 말씀하셨다.
실례가 수신 요청을 처리할 수 있는 상태인지 확인하십시오.준비 검사를 통과하지 않은 실례는 사용 가능한 실례 수영장에 추가되지 않습니다.
app.yaml의 응용 프로그램 구성 - 검사 준비
이 기능을 사용하면 Rails가 시작 중인 인스턴스에 요청을 보내는 것을 방지할 수 있습니다.

대책: 표준에서 유연한 환경으로 이행

표준 환경에서 대응 준비 점검이 없기 때문에 대담하게 유연한 환경으로 옮기기로 했다.의외로 이전은 간단해서 거의 개작app.yaml만 하면 된다.상세한 상황을 스크랩에 쓰다.
https://zenn.dev/catnose99/scraps/1951c124257888
유연한 환경용app.yaml은 먼저 다음과 같다.참조: 부드러운 환경 응용.yaml 쓰기
app.yaml

# 一部を抜粋
env: flex # フレキシブル環境
resources:
  cpu: 2
  memory_gb: 4
  disk_size_gb: 10
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 5
readiness_check:
  path: "/readiness_check" # このURLへアクセスされたときに200を返せば「準備完了」と判断してもらえる

전이 후 자주 발생하는 지연이 완전히 사라졌다.그리고 비용도 아래와 같이 대폭 싸졌다.

유일하게 신경 쓰이는 건 디프로가 5분 정도 걸렸는데...

결론

표준 환경이 반드시 싸지는 않다

표준 환경을 사용하는 경우 권장max_idle_instances

표준→유연성으로의 과도가 수월하기 때문에 먼저 표준환경을 이용하여 상황을 관찰할 수 있다