GCPでWebアプリケーションをデプロイしているのですが、毎月少なくない利用料金が発生しており、利用料金を下げるためにリソースや構成の見直しをしました。
ここでは簡単にGCPやAWSなどのパブリッククラウドにおいてリソース利用料金を下げるうえでのチェックポイントをまとめてみます。
利用料金の無駄を明細データから洗い出す
まずはコンソールの「課金」画面から、「どのサービスに、どのくらいの料金が発生しているのか」を見てみましょう。
シンプルなWebアプリケーションをデプロイしている場合、「Compute Engine」「Networking」「Cloud SQL」などが大きな金額を占めることが多いと思います。
さらに「料金明細」画面ではより細かい料金内訳を見ることができます。例えばVMインスタンスの利用料は「Compute Engine」に反映されますが、「CPU」「RAM」（メモリー）「ディスク」など項目が分かれているので、具体的にどのような理由で料金がかかっているのかが分かります。
上記のように詳細を確認すると、いくつかのポイントが分かります。
1つ目は「本来は不要なのに使用しているサービス」。2つ目は「多くの料金が発生しているサービス」です。
無駄なサービスの利用を停止する
本来は不要なのに使用しているサービスは、大きいものから小さいものまで意外に多く見つかります。
例えば以下です。
- アクセスが無い時間でのVMインスタンス起動
- 使用していない静的IPアドレス
- VMインスタンスグループの過剰な数
- Cloud Storageに積み重なったバックアップデータ
- Atrifact Registryに保存中の古いイメージ
「深夜帯はアクセスがほぼゼロなのに起動している」という場合は、リソースの無駄使いかもしれません。「Cloud Scheduler」を使えばスケジューリングで起動オン・オフを操作することも可能で、検討したいところです。
静的IPアドレスは、「使用していない場合に多く課金されてしまう」という特徴があります。ネットワーク系の操作をしていると、いつの間にか予約したものの使用しないままになっている静的IPアドレスが見つかることがあり、注意したいポイントです。そのほか、ネットワーク系を見るついでに不要なバックエンドサービスや、ファイアウォールルールなどをチェックしてもよいかもしれません。
ロードバランサのバックエンドでVMインスタンスグループを形成している場合、「VMインスタンスの数が多すぎないか？」もチェックしたいところ。高負荷にも耐えられるように常時VMインスタンス数を確保するのはよいですが、過去の利用ログと照らして、過剰な数を起動していないか見直してみます。特にVMインスタンスは常時起動で月に約720時間（24時間×30日）のCPU、メモリ、ストレージの利用料金がかかるので、利用料金が膨らみやすいものです。このGCEの最適化は料金を抑えるうえで無視できません。
そのほか、金額としては小さいものの、Cloud StorageやAtrifact Registryで、削除してもよいリソースがないか見直します。
コスト効率のよい代替サービスに切り替える
「多くの料金が発生しているサービス」は、別のコストパフォーマンスの高い、つまりもっと安いサービスに切り替えられないか検討します。
VMインスタンス
WebアプリケーションでVMインスタンスの扱いは難しいところです。「いつリクエストがあっても対応できる状態」が必要なものの、一方で「常に起動すると無駄なリソースを消費してしまう」というジレンマがあります。そこでリクエスト数がそこまで多くなく、リクエスト間の連続性を保つ必要がないなら、サーバーレスへの移行も選択肢です。
私の場合はまさにこの「少数ユーザーのランダムなリクエストに常時対応する必要がある」かつ「サーバーがセッション内のデータを継続的に保持する必要がない」という状況だったので、サーバーレス「Cloud Run」で対応することにしました。「Cloud Run」は、「GCE」と同じくDockerイメージをもとにデプロイできシンプルですし、当然ながら起動スクリプトや環境変数、ポート指定もできて使い勝手はほぼ同じ。バックエンドサーバーはもちろんユーザーがブラウザ操作するアプリケーションも問題なく起動できます。それからVMインスタンスグループと同様、「サーバーレス ネットワーク エンドポイント グループ」（NEG）というバックエンドを構成することもできます。つまり以下が可能ということです。
・GCE：インターネット→LB→VMインスタンスグループ→VMインスタンス
・Cloud Run：インターネット→LB→NEG→Cloud Runインスタンス
「Cloud Run」は従量課金なので、GCEのように常時起動で月に720時間の利用料金が課されることもありません。アクセスがゼロなら、料金もかからない点は魅力です。移行作業もスムーズでした。
以下のように、Compute Engine（青の部分）の料金が減っています。
ネットワーク構成
例えば、LB（ロードバランサ）は「グローバル型」「単一リージョン型」があり、後者の方が安くなります。グローバル型は、「複雑なルーティングができる」「マネージドのSSL証明書を利用でき手動更新が不要」「グローバルなユーザーに対応しやすい」などのメリットがあるものの、割高です。そこでシンプルなネットワーク構成かつ国内向けアプリケーションで、SSL証明書も自身で手動対応できるなら、「単一リージョン型」でもよいかもしれません。
ちなみに私の場合は「パスによってルーティングするバックエンドを分ける」という要件を満たす必要があり、それは「グローバル型」でなければできないので、割高な方を使わざるを得ない状況です。そのほか「グローバル型」の「SSL証明書の自動更新」も確かに魅力的なので、「安いから単一リージョン型がよい」とは一概には言えないと思います。
最後に
環境構築・運用は、やっているうちに不要なリソースがいつの間にか積み重なって、「いつのまにか無駄な支出になっている」という怖さがあると思いました。チェックを丁寧にしない甘さと言えばそれまでなのですが、料金明細は少なくとも月に1回は細かくチェックすべきだと実感しました。今回の見直し・構成変更だけでも、必要な要件は損なわず、30〜50％のコスト削減効果がありました。
特に代替サービスは奥深い。GCPを個人用・受託用で使って3年ほど経ちますが、「困りごとがあれば、何らかの解決策が用意されている」という印象です。
今回は料金の最適化でしたが、サーバーレスの従量課金と、そのデプロイ・運用のしやすさは助かりました。それほど予算をかけたくない・かけられない、個人・中小規模のWebアプリケーション運用でも、便利に使えています。
