クラウドコスト管理:スケールしても請求を予測可能に保つ
クラウドの請求書を開いた瞬間、胃が沈むような感覚を覚えたことはありませんか。前四半期は月$4,000を支払っていました。今四半期は$11,000で、トラフィックは2倍にしかなっていないのに、追加された$3,000を項目ごとに説明できる人はチームに誰もいません。プロダクトが成長しているのは良いニュースですが、財務チームは厳しい質問を投げかけ、エンジニアリングは肩をすくめて答えるしかありません。支出している金額と説明できる金額のあいだにあるこのギャップこそが、真のコスト問題です。金額そのものは症状にすぎません。
クラウドの請求書は公共料金の請求書よりも、月次明細書のない状態で20人が共有するクレジットカードのように振る舞います。どのエンジニアも、データベース、キュー、GPUインスタンス、マネージドサービスを2クリックで立ち上げられます。そのクリック一つひとつが、月次のコミットメントを静かに拡大していきます。意図的なコスト戦略がなければ、成長は祝福ではなく不安の源になります。良いニュースは、予測可能なクラウド支出が技術的な問題ではないということです。それは運用上の規律であり、真剣なエンジニアリングチームであれば必ず身につけることができます。
なぜクラウド請求はトラフィックよりも速く増えるのか
ほとんどのチームは、コストは使用量に比例してスケールすると想定します。ユーザーが2倍になれば請求も2倍、というわけです。しかし実際には、プロダクトの最初の2年間はコストがトラフィックよりも速く成長するのがほぼ常であり、その理由は技術的というより構造的なものです。
第一の理由は、遊休キャパシティです。開発環境、ステージングクラスタ、忘れられたテスト用データベース、古いスナップショットは、それを必要としていた機能がリリースされたあとも長く動き続けます。ある中規模のSaaSクライアントで実施したレビューでは、月次のコンピュート請求の34パーセントが、現チームの誰も特定できないリソースから発生していました。第二の理由は、オーバープロビジョニングです。エンジニアは金曜午後の最悪ケースを想定してインスタンスをサイジングし、残り167時間もそのサイズのまま放置します。第三の理由は、アーキテクチャのドリフトです。シンプルなAPIとして始まったサービスに、キャッシュ、検索インデックス、メッセージキュー、バックグラウンドワーカーが加わり、それぞれが独自のベースラインコストを抱えるようになる。にもかかわらず、その全体像がまだ妥当かどうかを立ち止まって問う人はいません。
これらはバグではありません。チームがリリース速度を最適化し、クラウド請求を他人事として扱った結果として自然に生じるものです。運用モデルに手を入れずに請求だけを修正しても、次のスパイクを6か月先送りするにすぎません。
コスト最適化はコスト削減ではない
戦術に入る前に、リーダーシップチームはクラウドコスト最適化が実際に何を意味するのかについて合意する必要があります。それはコスト削減運動ではありません。すべてを最も安いティアに移せという指令でもありません。それは、インフラに費やされるすべてのドルが、それに比例したビジネス価値を生み出し、その関係をチームが明確に見られるようにするための規律です。
よく運営されているコストプログラムは、毎月三つの問いに答えます。何にいくら使ったか。アクティブユーザーあたりのコストやトランザクションあたりのコストなど、ビジネスが気にする単位で表現したとき、その支出から何を得たか。トレンドはどうで、成長計画と一致しているか。この三つの問いに落ち着いて答えられるチームは、状況をコントロールしています。答えられないチームは、悪い四半期を一度経験するだけで緊急移行の状況に追い込まれます。
このフレーミングが重要な理由は、エンジニアが「クラウド支出を30パーセント削減せよ」というトップダウンの圧力に合理的に抵抗するからです。そのフレーミングは問題に最も近い人々を罰し、モニタリングを止める、本番データベースを縮小するといった短期的な判断を招き、のちの障害を生み出しがちです。正しいフレーミングは異なります。自分が構築するものにかかるコストの可視性をエンジニアに与え、絶対値ではなくコストと価値の比率について責任を負わせるのです。
予測可能なクラウド支出の四本の柱
成長中のSMEクライアント向けに提供してきたプロジェクト全体を通じて、四本の柱が、予測可能なクラウド請求を持つチームと、次の請求書を恐れて暮らすチームを一貫して分けてきました。
第一の柱は可視性です。見えないものは管理できません。すべてのアカウントのすべてのリソースには、チーム、プロダクト、環境にひもづくタグを付ける必要があります。コストダッシュボードはそれらのタグ別に週次トレンドを表示し、すべてのエンジニアリングリードは、店主が毎日のレジを読むようにそれを読むべきです。このベースラインがなければ、他のすべての柱は当てずっぽうになります。
第二の柱は右サイジングと弾力性です。本番ワークロードは推測ではなく測定に基づくべきです。オートスケーリンググループ、サーバーレス関数、マネージドデータベースのティアは、まさに使った分だけ支払うために存在します。トレードオフは実在します。弾力的なインフラは複雑さを増し、トラフィックスパイク時にはより慎重なキャパシティプランニングを要します。しかし、ほとんどのSMEワークロードにおいて、24時間ピークサイズで動かし続けることは、追加の信頼性を一切生まないまま40〜60パーセントの過剰支出になっています。
第三の柱はコミットメント規律です。あるワークロードが本番で6か月稼働し、安定したベースラインを示したら、そのベースラインはプロバイダに応じてリザーブドインスタンス、Savings Plans、確約使用割引でカバーすべきです。どうせ使う予定のキャパシティに対する1年コミットメントで、30〜55パーセントの割引が得られます。リスクは、あとで廃止するワークロードに対してコミットメントを購入してしまうことです。だからこそコミットメントは、実証された使用に常に追随すべきであり、決してそれを先行してはなりません。
第四の柱はアーキテクチャレビューです。四半期に一度、エンジニアリングリードは上位10のコスト項目を一つひとつ見て、簡単な問いを立てるべきです。これは今日の仕事にとって正しい形なのか、それとも問題の性質が違っていた18か月前に選んだ形なのか。1,000ユーザー時点で妥当だったマネージドサービスは、100,000ユーザー時点では大幅に割高になっているかもしれず、その逆もまた真です。このレビューは物事を剥ぎ取ることが目的ではありません。アーキテクチャの慣性がビジネスに静かに課税していないかを確認することが目的です。
短い事例:パニックから予測可能性へ
月間アクティブユーザー約20万人を抱えるあるベトナムのeコマースプラットフォームは、10か月でクラウド請求が月$6,000から$18,000へと成長した一方、収益は60パーセントしか伸びなかったため、私たちに相談を持ちかけました。財務ディレクターは、クラウドから完全に移行することを検討するよう推奨する取締役会向けメモを準備していました。
私たちはまず可視性の作業に2週間を費やしました。すべてのリソースにタグを付け、注文あたりのコストダッシュボードを構築し、各サービスをプロダクトオーナーにマッピングしました。そのうえで初めて、何かに手を入れました。見つかった事実は華やかなものではありませんでした。Black Fridayの負荷テストから残された3台の過大なデータベースレプリカ、チームが実際には直近7日間しかクエリしないのに90日間ぶんのリクエストペイロードをすべて保持し続けているロギングパイプライン、毎晩40分しか動かないワークロードのために24時間365日稼働しているバックグラウンドジョブクラスタ。これら3つを右サイジングし、実証されたベースラインに対して1年のSavings Planを追加し、ロギング保持をティア化ストレージポリシーに移すことで、月次請求は$18,000から$9,400へと、アプリケーションコードを1行も触らずに下がりました。より重要なのは、チームが次四半期の請求を10パーセント以内のマージンで予測できるようになったことです。
エンジニアリングの作業自体は6週間で完了しました。以来14か月にわたって請求を予測可能に保っているのは、その運用規律です。
今月から始められる実践的なロードマップ
クラウド請求がビジネスよりも速く成長しており、そこに先手を打ちたいのであれば、順序通りに実行する5つのステップが道のりの大半をカバーしてくれます。
第一に、単一のオーナーを任命します。責任者のいないコスト最適化は計画ではなく願望です。これはフルタイムのロールである必要はありませんが、誰かの職務記述書に指名された責任として明記される必要があります。第二に、タグ付けを強制します。新しいリソースにはすべてチーム、プロダクト、環境のタグを付け、コストダッシュボードはその軸で分解しなければなりません。既存環境のバックフィルには2週間の猶予をエンジニアに与えます。第三に、クイックウィン監査を実施します。遊休リソース、過大なインスタンス、忘れられた環境を探します。ほとんどのチームは、これだけで最初の1か月に15〜25パーセントの節約を見つけます。第四に、安定しているものにコミットします。ベースラインが完全な2四半期にわたって安定したら、それに対してリザベーションやSavings Plansを購入します。投機的な成長に対してはコミットしないでください。第五に、アーキテクチャレビューを四半期カレンダーに載せます。セキュリティレビューと同じくらい真剣に扱うべきです。暴走するクラウド請求は、侵害と同じくらい速く会社を終わらせることがあるからです。
これらのステップはどれも技術的に難しいものではありません。難しいのは組織的な側面です。プロダクト、エンジニアリング、財務が同じテーブルに着き、インフラについて同じ言語で語る必要があるからです。
結びに
予測可能なクラウド請求は、より小さなクラウド請求ではありません。それは、あなたが説明でき、予測でき、取締役会に対して弁護できる請求です。その状態に到達したチームは、クラウド支出を四半期ごとの不安の源として扱うのをやめ、ビジネスの成長に合わせて意図的に引くことができるレバーとして扱い始めます。
もしあなたのチームが、答えよりも先に請求書が届く段階にいるのであれば、最初のパスに経験豊富なパートナーを招くことには価値があります。MerkTechsでは、パニック状態の監査から落ち着いた月次レビューへと、まさにこの道のりを何社かのSMEクライアントと共に歩んできました。あなたのプロダクトにとって、コスト規律の最初の90日がどのようなものになりうるかを、いつでも喜んでお話しします。