暑くなってくるとだんだん食欲がなくなってきませんか？今年もそんな季節となりました。
今年の夏は北海道に行く予定です、私は本当にやるぞ。DPEチームの嶺岸です。
ところで、パブリッククラウド高くないですか？
使った分だけお支払いいただきます、この売り文句を聞いて高くなると思うか、安くなると思うか、その感覚は人それぞれかと思います。しかし覚えておいて欲しい。使えば使っただけ支払わなければならないということを。
弊社のGoogle Cloud、高くない？
私のコスト感覚を一言で言うと、「なんとなく」です。身も蓋もない。
この費用……なんか、変？何が高いのかな……？（裏声）
という感じでなんとなくGoogle Cloudの請求レポートを眺めます。
期間を1年くらい、グループ条件を月 > サービスに設定すると、毎月どのサービスにどれだけ課金しているかが分かります。
そこから上位3サービスくらいをピックアップして詳細を確認していきましょう。
大抵のWEBサービスであれば、サーバー、DB、あとはサービス内容によってはストレージ辺りが多いのではないでしょうか。
弊社もご多分に漏れずといったところだったので、今回はCloud Runについて掘り下げていこうと思います。
Cloud Runの何が高いんだい？
さて、実際にCloud Runのコストが適正かどうかを確認するために、請求レポートのフィルタを変更します。
サービスをCloud Runに、グループ条件を月 > SKUに変更すると、Cloud Runにかかるコストの詳細が確認できるようになりますね。
Cloud Runにかかるコストはおよそ下記のように分類することができます。
※CPUの常時割り当ては使用していないものとする
【リクエストを処理するコスト】
実際にリクエストを捌くのにかかる料金です。アクセスが多いほど増加する変動費ですね。
- CPU Allocation Time
- Memory Allocation Time
- Requests
【最小インスタンスを確保するコスト】
最小インスタンスを1以上に設定している場合にかかる料金です。固定費ですね。
- Idle Min-Instance CPU Allocation Time
- Idle Min-Instance Memory Allocation Time
弊社ではコールドスタートを避けるため最小インスタンスを設定しているので、リクエストがない時間帯においても最小インスタンスの費用がかかっています。
が、コールドスタートを避けてお客様に快適なサービスを提供するため、ある程度のコストは必要であると考えられます。
ある程度のコストであれば。
今回請求内容を確認したところ、リクエストを処理するコストに対して、最小インスタンスを確保するコストが10倍ほどかかっていました。
流石にこれは、かかりすぎなのではないか……？
スーパーのレジを思い浮かべてみてください。およそ1〜2台のレジで大体捌けているのに、10台のレジに店員さんが開いている様子を。これからビッグウェーブが来るのか？なんだ？花火大会か？という気持ちになりませんか。ちなみにビッグウェーブはこない。
最小インスタンスにかかる費用の原因を探求する
実際のところ、大量の最小インスタンスが本当に必要なのであれば、あるいは私の金銭感覚がまだGoogle Cloudに追いついておらず大体それくらいはかかるのが普通なのであれば、それはそれで良いのだと思います。
しかしどうも多い気がする。多くないかこれは。
そんな気持ちが拭えないので、実際Cloud Runがどのように設定されているのか確認しました。
結果、どうやらトラフィックを制御するためのリビジョンタグが、大体常に3〜4リビジョンに付与されているということがわかりました。
ちなみに、Cloud Runはリビジョンタグが付いているリビジョンに関して、割り当てられたトラフィックが0％だったとしても最小インスタンスを確保します。トラフィックが流れてくるかもしれないからね。こないよ。
そう、別にトラフィックを流していないのである。
消そう。
対策編
一旦、一番単純な対策としてリリース時に古いリビジョンのタグを消すこととしました。
gcloud run services describeコマンドでサービスのリビジョンタグを抽出して一つずつ消しても良かったのですが、残すべきタグだけがわかっている状態であればgcloud run services update-traffic --set-tagsを使った方がシンプルに済むためこちらを採用しました。
gcloud run services update-traffic --set-tags TAG=REVISION
describeして既存のタグを抽出して--remove-tagsコマンドを打つよりだいぶスッキリするので、最終的に残っているべきタグがわかっている状態であれば、個人的にはこちらの方がおすすめです。
一応、リリースのタイミングでちょうど走っていたトラフィックを尊重するため、今回の実装ではトラフィックの切り替えから古いタグの削除までの間に任意のディレイを入れる事にしています。
結果
さて、そんなこんなで当初の目的であったGoogle Cloudのコスト削減は達成できたのでしょうか？
請求額に関わることなのでスクリーンショットがお見せできないのですが、当初リクエストを処理するコストの10倍程度であった最小インスタンスのコストは、リクエスト処理コストの2倍程度まで縮小することができました。
スーパーのレジで考えても、3台レジが開いていて大体1〜2台のレジが稼働している状態、だいぶ普通の光景じゃないですか？
平和な景色を取り戻すことができてなによりです。
パブリッククラウドの運用コストを見直してみると、新たな発見があるかもしれませんよ。
余談〜Google Cloud 認定資格〜
余談オブ余談ですが、昨年末と昨年度末にGoogle Cloudの認定資格のうちProfessional Cloud ArchitectとProfessional Cloud Security Engineerを受けて無事に合格しました。合格体験記を書こうか悩んだのですが、あまり書くことがなくて……。
これから受験しようかなと思っている方に、ひとつだけライフハックをお伝えしておきますね。
試験終了の画面に合否が出ます。
初回はこれを知らずに受かったかどうかわからないまましばらく心臓に悪い時間を過ごしたので、これだけは皆様にお伝えしておきたい。本当にちっっっっっっっちゃい文字で合否書いてあります。試験終了のときに、ぜひ落ち着いて確認してみてくださいね。
それでは皆様、よいパブリッククラウドライフを。
:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:・:+:・:+:・:+:
ビザスクではエンジニアの仲間を募集しています！
少しでもビザスク開発組織にご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
developer-recruit.visasq.works
:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:-・:+:・:+:・:+:・:+:
