「コスト削減」というパワーワードに負けずにコストコントロールを素早く進めたい
この記事は株式会社 X-Tech5 CTOの、ばば（netmarkjp）が書きました。
事業でのコストコントロールは永遠の課題ですね。クラウドサービスのコストコントロールは昨年あたりから特に大きく取り上げられている印象です。 キーワードとしては「コスト削減」や「コスト最適化」がよく使われます。ここではまるっとコストコントロールと呼びます。
わたしはお仕事で色々な会社のSREの実践や体制構築をお手伝いするSREサービスや、SRE/オブザーバビリティの導入・定着支援をしています。 各種クラウドサービスのコストコントロールの機会も多々あるので、その中で得たクラウドサービスのコストコントロールにスムーズに取り組むためのヒントを共有します。
同じ成果なら支出は少ないほうが嬉しい
何をいまさら、という感じかもしれませんが、支出は少ないほうが嬉しいですよね。それはそう。
ただ、この「同じ成果なら」というのは意見がわかれるポイントです。 「成果」は最終的なアウトプットだけでなく、その過程での学びや成長も含むものです。 激しい競合との競争や市場環境の変化がある中で「時間を買う」という視点もあるので、一概に支出が少なかったから良かったとは言い切れません。 支出は投資という側面もありますから、わたしはその投資によって事業・企業全体が健全に成長していくことが大事だと考えています。
さっそくゴタゴタしそうな気配です。
2つの軸で考えて話すとスムーズ
議論が紛糾しがちなので、整理するために2つの軸を持つといいです。
- 時間軸の考慮
- 短期か中長期か
- 非機能要求や持続性リスクの閾値の考慮
- 非機能要求の達成水準や受容する持続性リスクの水準を変えるか変えないか
この2つの軸を使うと、アイデア出しや施策を進めるのがスムーズになります。
それはそう：クラウドサービスはコストコントロールの対応が1日早ければ支出が減るのも1日早い
口に出すとあたり前なのですが、クラウドサービスはほとんどが秒単位・分単位・時間帯の費用発生ですから、施策が1日早ければ支出が減るのも1日早いです。 なので即効性のためには1秒でも早く対応を実現させたいですね。
もちろん手当たり次第何でもやればいいわけではありません。コストコントロールはパフォーマンスチューニングと似ています。 パフォーマンスチューニングでアプローチすべきはボトルネックで、コストコントロールでまずアプローチすべきはボリュームゾーンです。
ともあれ早く対応するためには早く決断しなければなりません。 短期間での実現が叶わないのは、エンジニアリングに時間がかかる場合と、意思決定に時間がかかる場合があります。 エンジニアリングのほうはSREの本分なのでがんばるとして、意思決定をスムーズにしたいですよね。わたしはしたい。
短期で、それこそ1ヶ月/3ヶ月で確実に成果を出すためのアプローチと、中長期で体質改善するためのアプローチをわけると整理しやすくなります。 中長期は市場や競合の状況変化も考慮することになり、変数が多く不確実性が高いので、すぐには決められないですよね。 支出を着実に減らすには、短期のものは短期のもので切り分けてさくさく進めましょう。
それはそう：非機能要求や持続性リスクの閾値が変わる事柄に手を付けないと「承認」で済む
コストコントロールのために何か取り組むとなると、いまのつくりややり方を多少なりとも見直すことになりますね。 このとき非機能要求や持続性リスクの閾値が変わらない、あるいはほとんど変わらない内容であれば、関係者は何かを判断してバランスを変える意思決定、つまり決断する必要はありません。実質的に承認をもらうだけで済みます。
もちろん非機能要求や持続性リスクの閾値は0/1ではなくグラデーションですから、明確に「これはこっち」「これはあっち」とはなりません。とはいえこの軸で切り分けてアイデアを出したり施策を決定したりすると、すぐできるものをすぐやる、いっしょくたにして後に回さないというのを実現するのに役立ちます。
例：
- まず明らかな無駄を減らすために、消し忘れているリソースを削除したり、使っていないリソースを削除したりする
- 過剰な余剰を減らすために、スペックを見直したり、非利用時間帯にリソースを停止したりする
- 長期利用割引プランや利用量コミット割引プラン、ボリュームディスカウントを利用する
他には監視間隔を伸ばしたりトレースのサンプリングレートを下げて監視の解像度を下げたり、ログの取得レベルを下げたりも検討します。 一部のひとしかうまく使えていない機能を使わないようにすることもあります。 このようないまの自分たちには過剰かなぁ…というものを削るのは、ライン決めが悩ましいものです。 段階的に進めて、やりすぎだったら一歩戻すと無難に無駄を減らすことができます。
あとはパフォーマンスチューニングで処理効率を改善して必要なキャパシティを減らしてコストを減らすことがよくあります。
他の施策はないか…と考えるときにも、非機能要求の達成水準をあまり変えずに、持続性リスクをあまりとらずに無駄や不適切を減らす施策を考えます。
それはそう：非機能要求や持続性リスクの閾値が変わる事柄に手を付けるのは「決断」が必要
大胆に支出を減らしたいときは、非機能要求の達成水準を下げたり、持続性リスクをとったりを積極的に検討します。 当然のように議論や意思決定で時間がかかりがちです。 そして多くの場合はエンジニアリングにも時間がかかります。 となると支出が減るのは遅れます。 でも大きな効果が期待できることがあります。
こういうときは聖域なしで、あるいは聖域を明確に狭めて検討します。
例：
- 可用性リスクを受容して冗長化をやめる、高可用性オプションを外す
- 運用がなおざりになるのを暗に受容してマネージドサービスを使うのをやめる
- 顕在化したときに検知・追跡できる範囲が狭まるのを受容してセキュリティログの取得レベルを下げる
これはAWSであればAmazon RDSのMulti-AZオプションを外したり、Amazon VPCのNAT GatewayをNATインスタンスに変えたりします。 他にはVPCを集約してロードバランサーやNATインスタンスを共有することもあります。 場合によっては利用するクラウドサービスを変えたり、アプリケーションのアーキテクチャを変えたりすることもありますね。
このあたりの採否はたいていプロダクトマネージャーレベルの意思決定が必要です。 あまり深く考えずに支出を減らす目的で施策を決めると、非機能要求の達成水準を削りすぎたり、持続性リスクを取りすぎて機会損失がおきたり、必要な投資ができなかったりして成長が阻害されたりします。 潜在的な・あるいは将来の持続性リスクや損害にも目を向けるあたりがややこしいですね。
「コスト削減」というパワーワード
ここまで「コスト削減」や「コスト最適化」と言わずにコストコントロールと呼んできました。 これはどっちでもいいといえばどっちでもいいですし、こだわりポイントといえばこだわりポイントです。
「コスト削減」と銘打つとどうしても、アイデアを出す人も採否を判断するひとも、非機能要求や持続性リスクの閾値、短期や中長期よりも、削減額を軸に検討しがちです。削減額に着目すると非機能要求や持続性リスクの閾値を下げる手法が魅力的に見えてきます。前述のとおり非機能要求や持続性リスクの閾値に手を付けようとすると揉めがちだし時間がかかりがちです。というわけで、議論が白熱し紛糾するもののなかなか進まなかったりします。 削減額は取り組みの完了基準として利用することはあります。しかし取り組みを選ぶ直接の最優先基準にすると、取り組みの着手や完了が遅れて結果的に支出があまり減らないことも多々あります。
また「コスト削減」という意識だと、適切な投資が滞りがちになります。支出が投資であるという側面を忘れがち・ないがしろにしがちになるのが難点です。お金を適切に減らすのも、適切に使うのも難しいですよね。
なので用語としては「コスト最適化」を使うことが多いわけです。できることをサクサク進めてまずは早々に改善成果を出して、さらに大胆なことをするならするで段階的にやっていきましょうとします。
とはいえ「コスト削減」というパワーがあるワードは非機能要求や持続性リスクの閾値を変える「決断」の後押しになるので、時と場合によっては「コスト削減」を敢えて選ぶこともあります。 一般社会常識的にあまり強い言葉を使うのは好ましくないと思うので.、このあたりはSREsが中心に導いて行けるといいですね。
などと考えながら、現場の雰囲気によって使い分けています。