高いのではなく、遊んでいるのだ
一言でいうと
クラウドのコストは高いものではなく、何もしていないのに起動しているものに付きます。
なぜ請求書を読むのか
クラウドのコストは使った分だけ発生する仕組みなので、途中に決裁がありません。インスタンスを起動するのに承認は要らず、止めるのにも要りません。そのため、起動することは絶えず起き、止めることはほとんど起きません。
数か月が経つと請求書は大きくなりますが、肝心の何のせいで大きくなったのかを知っている人がいません。 作った人は別のチームに移り、財務チームは総額しか見ません。この状態で「コストを減らそう」と言うと、目に付くものから手を付けることになり、目に付くものはたいてい小さいのです。
そのため順序が決まっています。まず項目に分け、そのうえで、そのお金が何を買っているのかを区別します。 分けずに始めた削減は、たいてい金額が小さいか、節約してはいけないものを節約してしまいます。
項目に分けるまでは何もできない
「クラウドのコストが高すぎる」から始めると、たいてい次のように終わります。目に付くものから手を付け、目に付くものはたいてい小さいのです。
まず項目別の比率を見ます。ラボの請求書を分けると、次のようになります。
batch compute 1,401.60$ 43.9%
db managed_db 747.52$ 23.4%
web compute 525.60$ 16.5%
snapshots snapshot 210.00$ 6.6%
...
합계 3,191.17$
1位の1つだけで44%です。残りをすべて合わせても、これには届きません。
そして、1位はたいてい遊んでいる
batchのメモを読むと、次のとおりです。
1日2時間のバッチを回しているのに、インスタンスは起動したままです。
1日2時間×30日で60時間しか働いていないのに、730時間が請求されます。コストの92%が、何もしていない時間に付いています。
CPU使用率だけを見てもわかりにくいものです。平均11%を見て「バッチだから元々そういうものだ」と見過ごしてしまうからです。いつ稼働するのかを見る必要があります。
何を買うお金なのかを区別する
すべてのコストが無駄なわけではありません。
cross-azの3000GBは、WebとDBが別のAZにあるために生じます。同じAZにまとめれば消えます。ところが、そのAZが落ちると一緒に落ちます。
これは無駄ではなく、可用性に支払う対価です。減らすには、まず「AZが1つ落ちても問題ないか」に答える必要があります。その答えなしに減らしたなら、コストを節約したのではなく、リスクを買ったことになります。
スタンバイDB(db2台のうち1台)も同じです。普段は何もしていませんが、それがそのお金の使い道です。
経路を変えてなくなるコスト
最も気分のよい種類です。トラフィックはそのままで、コストだけがなくなります。
NATゲートウェイには、時間あたりの料金と処理量あたりの料金が別々にかかります。オブジェクトストレージへ向かうトラフィックがNATを通っているなら、ゲートウェイエンドポイントを使えば、その経路はNATを通らなくなります。
時間あたりの料金は残ります。NAT自体は依然として必要だからです。しかし、処理量の料金は0になります。
誰も消さないものたち
スナップショットの4200GBは、7か月分の日次スナップショットです。なぜ誰も消さなかったのでしょうか。
保管期間を決めた人がいないからです。 消すには「どれだけ古い時点まで戻れなければならないか」に答える必要がありますが、その答えがなければ、誰も責任を持って消せません。
保管期間は、コストではなく復旧要件が決めます。30日なら30日と書いておけば、それ以降は自動的に消えます。
どこから手を付けるか
比率の順が正解のように思えますが、実際には使っていないものから始めるほうがうまくいきます。
| 順序 | 何を | なぜ |
|---|---|---|
| 1 | 使っていないリソース | 見つけやすく、リスクがない |
| 2 | 遊んでいる時間 | 金額が大きく、元に戻しやすい |
| 3 | 保管ポリシー | 決めるだけで自動的に減る |
| 4 | 経路の変更 | 設計の変更が必要 |
| 5 | 構造の変更 | 議論が必要 |
1つ目は誰も反対しません。チームが進め方を身につけながら成果が出て、次のことをやる信頼が生まれます。5つ目から始めると、たいてい議論で終わります。
現場での姿
- 請求書の1位はバッチ用のインスタンスで、そのバッチは1日2時間しか動いていませんでした。稼働時間を60時間に変える1行で片付きました。
- CPU平均11%を見て「バッチだから元々そういうものだ」と、3年間そのままにしていました。見るべきだったのは使用率ではなく、いつ稼働するかでした。
- AZ間のトラフィックを無駄と見なしてWebとDBを1つのAZにまとめたところ、そのAZの障害時にサービス全体が止まりました。節約した金額より損失のほうが大きくなりました。
- スナップショットが7か月分たまっているのに、誰も消せません。消してよいか答えるドキュメントがないからです。
- 最も大きい項目から手を付けようとして、チーム間の議論で2か月が過ぎました。使っていないリソースから整理したチームは、同じ期間に成果を出しました。
まとめ
- 項目に分けて比率を見ます
- 1位がどれだけ稼働しているかを見ます
- 無駄と可用性のコストを区別します
- 経路を変えてなくなるものを探します
- 使っていないものから始めます