請求書を読んで減らす

目標

クラウドのコストは、どこに付いているかを知らなければ減らせません。 そして、たいてい「高いもの」ではなく、「何もしていないのに起動しているもの」に付いています。

あるチームの1か月分の請求書が、項目に展開されています。読んで、直して、どれだけ減ったかを確認します。

開始

cp -r /opt/lab/cost/* . && python3 cost.py

合計はおよそ$3,191になります。

ファイル

ファイル	役割
`architecture.json`	料金とリソース。これを直していきます
`cost.py`	項目別に計算します。直しません

各リソースの메모を必ず読んでください(韓国語で「メモ」を意味するフィールド名です)。無駄は、数字ではなくメモに書かれています。

採点

ステップ3からは、採点ツールが自分のarchitecture.jsonで直接計算します。 数字だけを書いて出しても通過しません。

ステップ

項目別の比率 → 01-breakdown.txt
遊んでいる時間 → 02-idle.md
直すとどれだけ減るか → 03-fix-idle.txt
スナップショットの保管 → 04-snapshot.txt
経路の変更 → 05-path.txt
AZ間のトラフィック → 06-az.md
使っていないもの → 07-unused.txt
整理 → 08-notes.md

参考

料金は、事業者やリージョンごとに違います。重要なのは、桁と「何が何に比例するか」です。

請求書を項目に分ける

/opt/lab/cost/をコピーしてpython3 cost.pyを実行し、最も大きい項目3つとそれぞれの比率を01-breakdown.txtに残してください。

cp -r /opt/lab/cost/* . && python3 cost.py

コストを減らすとき、最初にやることがこれです。項目に分ける前は、どこに手を付けるべきかわからず、たいてい目に付くもの(=小さいもの)から手を付けてしまいます。

合計は、おおよそ$3,191になるはずです。

最も大きい項目が実際にどれだけ稼働しているかを見る

1位の項目の메모を読み、実際に稼働している時間と請求される時間を比較して、02-idle.mdに書いてください(韓国語で「メモ」を意味するフィールド名です)。

architecture.jsonの메모を見てください。1日2時間のバッチなのに、インスタンスは730時間起動しています。

コストの90%以上が、何もしていない時間に付いています。 クラウドのコストで最もよくある無駄で、CPU使用率だけを見てもわかりにくいものです。平均が低くても「元々そういうワークロード」と見過ごしてしまうからです。

直すとどれだけ減るかを確認する

architecture.jsonをarchitecture.jsonのまま残してコピーを作り、バッチが実際に必要な時間だけ動くように直してください。ファイル名はarchitecture.jsonを上書きしてもかまいません。直したあと、python3 cost.pyの結果を03-fix-idle.txtに残します。

1日2時間×30日=60時間です。가동시간を730から60に変更してください(韓国語で「稼働時間」を意味するフィールド名です)。

採点ツールは、自分のarchitecture.jsonで直接計算して確認します。数字だけを書いて出しても通過しません。

1行直して、どれだけ減ったかを見てください。これが「どこから手を付けるべきか」の答えです。

消していないものを整理する

スナップショットの項目のメモを見て、保管ポリシーを決めたうえで、その分だけ減らして04-snapshot.txtに書いてください。なぜその期間なのかも書きます。

7か月分の日次スナップショットがたまっています。30日保管にすると、およそ7分の1に減ります。

保管期間は、コストではなく復旧要件が決めます。 「どれだけ古い時点まで戻れなければならないか」に答えがあり、その答えがなければ誰も消せません。だから7か月分がたまります。

経路を変えてなくすコスト

NATの項目のメモを見て、処理量の料金がなくなる構造に変えて、05-path.txtに残してください。

NATには、時間あたりの料金と処理量あたりの料金が別々にかかります。処理量の大部分がオブジェクトストレージへ向かうトラフィックなら、ゲートウェイエンドポイントを使えば、その経路はNATを通りません。

처리GBを減らしてみてください(韓国語で「処理GB」を意味するフィールド名です)。トラフィックはそのままで、経路だけを変えてコストがなくなります。時間あたりの料金は残ります。NAT自体は依然として必要ですから。

AZをまたぐトラフィックを見る

cross-azの項目がなぜ3000GBなのかをメモから探し、減らす方法を06-az.mdに書いてください。

WebとDBが別のAZにあるため、リクエストのたびにAZをまたぎます。GBあたりの料金は小さくても、量が多いので積み上がります。

ただし、ここには落とし穴があります。同じAZにまとめると、そのAZが落ちるときに一緒に落ちます。 この項目は「減らすべき無駄」ではなく、可用性に支払う対価かもしれません。何を買うお金なのかを区別して書いてください。

誰も使っていないものを探す

メモに目を通して今は誰も使っていないリソースを探して削除し、最終的な合計を07-unused.txtに残してください。

3か月前に使っていたロードバランサーが、まだ起動しています。

金額は小さいです。しかし、こういうものは見つけるのが最も簡単で、リスクも最も低いのです。コスト削減を始めるときにここから始めると、チームが進め方を身につけながら成果が出ます。大きなものから手を付けると、たいてい議論で終わります。

整理する

08-notes.mdに3行以上書いてください。どこから手を付けるべきか、無駄と可用性のコストをどう区別するか、経路を変えてなくなるコストの例です。

本文に비중、가용성、경로が含まれている必要があります(韓国語で、順に「比率」「可用性」「経路」を意味する語です)。