請求書を開いた瞬間、まず何を見るのか
一言でいうと
コスト削減は、金額が大きい項目から、リスクが低い措置から見ていきます。逆にすると、労力に見合った効果が出ず、サービスを壊します。
なぜ必要なのか
割引契約やアーキテクチャの変更から始めると、使っていないリソースまで長期間固定してしまったり、小さな削減のためにサービスのリスクを高めたりしかねません。元に戻しやすい無駄の除去から、測定が必要なサイズ調整へ進む順序が、コストと運用の安定性を両立させます。
どう動くのか
順序
1. 안 쓰는 것 지우기 ← 위험 0, 효과 즉시
2. 안 쓸 때 끄기 ← 위험 낮음, 효과 큼
3. 크기 줄이기(right-sizing) ← 측정 필요
4. 저장 계층 옮기기 ← 수명주기 정책
5. 아키텍처 바꾸기 ← 효과 크지만 오래 걸림
6. 약정 할인 구매 ← 위 5개를 끝낸 뒤에 한다
6つ目が最後であることが重要です。 無駄をそのままにしてコミットメントを買うと、無駄を3年契約で固定するようなものです。整理を先に行い、整理されたベースラインにコミットメントを付けます。
1. 使っていないもの
チェックリストにして、四半期ごとに回します。
- 切り離されたボリューム(unattached)
- 使われていない固定IP
- ターゲットが1つもないロードバランサー
- 古いスナップショットやAMI
- 空のデータベースインスタンス
- 30日間ログがないロググループ
- 誰も参照していないテーブル
これだけで10–20%減ることがよくあります。
2. スケジュール
本番以外の環境を業務時間だけ起動します。実行は簡単で、効果は大きいです。注意点は、停止する前に通知を送ることです。残業中の人がいるかもしれません。また、例外のタグ(AlwaysOn=true)を用意して、必要なものは残します。
3. サイズを減らす
指標なしに行うと事故になります。最低限、次のように見ます。
- CPUの最大値が2週間にわたって40%未満なら、1段階減らす候補です
- メモリ: これが本当の制約であることが多くあります。必ず一緒に見ます
- バーストクレジット: バースト型のインスタンスは、クレジットの枯渇の有無を見る必要があります。平均CPUが低くても、クレジットが底をついていれば、すでに性能が制約された状態です。
1段階ずつ減らして観察します。2段階を一度に減らすと、元に戻すときに判断する根拠がありません。
4. ストレージのライフサイクル
ログ、バックアップ、イメージにポリシーをかけます。
0~30일 자주 접근 계층
30~90일 저빈도 계층
90~365일 아카이브
365일 이후 삭제
削除ルールを入れる前に、保存要件を確認する必要があります。規制上、数年間保管しなければならないデータが混ざっているかもしれません。
5. アーキテクチャ
前に扱ったものです。エンドポイントの導入、CDN、AZの配置、マネージドサービスへの移行や離脱です。効果は大きいものの、リードタイムが長いため、前の4つの段階と並行して進めます。
削減を維持する方法
一度減らしても、6か月で元に戻ります。維持するには手順が必要です。
- 予算とアラート: チームごとに予算を設定して、超過しそうなときにアラートを出す
- タグの強制: タグのないリソースは作成を禁止する
- 定期レビュー: 四半期ごとに、上位10項目を一緒に見る
- 可視性: チームが自分のコストを見られるようにする。見えなければ減りません
最後が核心です。コストを財務チームしか見ていないと、誰も減らしません。作った人が金額を見られる必要があります。
現場での姿
- コミットメントを先に買ってしまい、アーキテクチャを変更できなくなった → 順序が間違っていました。
- サイズを2段階減らして障害になった → 指標なしに判断していました。
- 削減から半年で元に戻った → 手順ではなく、一回限りの作業でした。
続くラボですること
この順序を、実際の数字で確認します。指標だけを見てサイズを減らそうとすると、5台のうち3台が妨げられていて、その妨げの正体はCPUではなく、メモリとバーストクレジットにあります。さらに、整理の前にコミットメントを買っていたら、3年でいくら多く支払うことになるかを、自分で計算します。
削減する前に確認すること
前の5つの段階は、何を減らすかを教えてくれますが、減らしてよいのかは別に見なければなりません。この確認を飛ばしたために起きる事故のほうが、削減で節約した額より高くつくことがよくあります。
本当に使っていないのか。 指標が0だということと、誰も使っていないということは違います。月に1回動く精算バッチ、四半期ごとに使うレポート用のインスタンス、災害復旧用に停止しておいたリソースは、すべて普段は0に見えます。観測期間が、そのリソースの最も長い周期より長くなければ判断できず、そうでなければ、削除する前に所有者に聞く必要があります。
誰が使っているかわかるか。 タグがなくて所有者がわからないリソースが、最も削除しにくいものです。そういうときは、削除する代わりにまず停止してみます。 数日置いて、誰も探しに来なければ、そのときに削除します。元に戻せる段階を1つ挟むだけで、この判断はずっと楽になります。
依存しているものはないか。 ストレージのクラスを下げる前に、それを読む側がレイテンシに耐えられるかを見る必要があり、インスタンスの種類を変える前に、その上に固定されたライセンスやIPがないかを見る必要があります。
いつ元に戻すかを決めているか。 サイズを減らしたあと、何を見て元に戻すか、そして何日間様子を見るかを、あらかじめ書いておきます。前に、2段階を一度に減らして障害になったという事例が出てきますが、その事故の本質は、幅が大きかったことではなく、元に戻す条件を決めていなかったことです。
最後に、節約した金額を記録します。 何をいつ減らして、いくら節約したかが残っていれば、次の四半期に同じ議論を最初からやり直さなくて済み、何よりも、元に戻さなければならなくなったときに、その代償を数字で語れます。
次に見ること
可用性にも値段があります。RTOとRPOで、その値を決める方法です。