請求明細書を見てお嘆きの皆様へ。
前回の記事では、すぐにコスト削減の成果を出したい人向けに比較的簡単な方法を解説しました。
この記事では、時間がかかっても良いので根本的に原価をなんとかしたい人を対象としています。
請求明細書(Billing)やCost Explorerの参照権限を広く付ける
開発者がコストを意識するところから、すべては始まります。
意識しようにも、そもそもいくらかかっているかわからないことがあります。見ようとしても現場レベルで直接参照する権限がないことがあります。情報対称性の意味でも、初期設定で権限を付与しておきましょう。デフォルトAllow、やむを得ない事情があればDenyという方式がよいです。
AWSの請求は日次で更新されるため、当日行った作業結果が翌日翌々日には反映されます。フィードバックループを回せるよう、まずはデータを入手できるようにしましょう。
横断してコストを見るには組織の親アカウントで
複数プロダクト、開発〜本番アカウントを横断して確認してもらうなら、組織の親アカウントでCost Explorer等の参照権限を付与するのが手っ取り早いです。親アカウントにデータが集約されているため。親アカウントにアクセスさせたくないなら、データ可視化基盤にコストデータを貯めるという方法もあります。
Cost Explorerの見方
(1) なにも設定しないとキャッシュアウトが表示されます。オプションで「非ブレンドコスト」から「償却コスト」にしましょう。こうすればRIといった前払いによる効果を均し、各アカウントにコストを配賦することで、プロダクト改善結果がわかりやすくなります。
(2)「使用タイプ」と「APIオペレーション」はあまり使われませんが強力です。「グループ化の条件」で内訳を見てみましょう。各AWSサービスに対する明細が見えてきます。
(3) 日別で確認するとき、アカウントやサービスによっては前日分は未集計です。2日経つと安定するので待ちましょう。
(4) AWSサポート費用と税金は毎日1日にまとめて反映されます。日別で見たいときは、歪みを取り除きたいので「サービス」から除外しておきましょう
大掛かりなチューニングの前に明細を理解する
「EC2」といっても、NAT Gatewayの料金が含まれています。「S3」はオブジェクト保存量ではなく、APIアクセス料金がかかっているかもしれません。あるサービスのコストが異常に増えているのは、外部からの攻撃が原因のこともあります。
請求ページやCost ExplorerではAWS API単位でキャッシュアウトを確認できます。想像ではなく、事実を確認しましょう。
ユニットエコノミクスでコスト構造を把握する
SaaSビジネスといえばユニットエコノミクス。ごく単純な説明として、AWSに支払う金額が増えている理由を知りたいとします。AWSコストだけを見ても、原価の上昇がもとなのかビジネスの伸びに起因しているのか不明確です。
まずは、顧客数を確認しましょう。店舗数が社内の共通言語なら店舗数を使います。ビジネスによってはユーザー数かもしれません。定義も社内で揃えるとよいです。ファイナンス関係の担当(経営企画、事業企画、BizDev、事業開発、コントローラー)と協力して定義を決めましょう。あとは単位あたりのコストを見れば、構造と推移がわかります。実際にはユーザー数以外にも操作するとコストが増える指標があるかもしれません。コストドライバーを見つけましょう。
＊厳密には限界費用(MC)の計算式は異なりますが、大まかには正しいです。
機能単位でコストを把握する
プロダクトのオプション単位、重要な機能単位でコストを計算しましょう。有償オプションの採算性が見えてくるほか、改善のあたりをつけやすいです。
サーバレスなら計算は容易です。
サーバレス以外だと計算は困難です。
リクエストのコスト構造を把握する
一つのリクエストを可視化してみましょう。
ごく簡単なAPIを想定します。
部分ごとにいくらかかっているのか把握することで改善しやすくなります。実際にはNAT Gateway、アウトバウンド、通信費などがあるかもしれません。金額が大きい部分は図に追加しましょう。
他チームや他社のAPI、運用関係のコストも考慮しましょう。とにかくリクエストに対してお金がかかるなら対象です。3rd partyのトレーシングやログは地味に高い傾向にあります。
図示すると、ユーザーに近いところからリクエスト量を削減する価値がよくわかります。前段に近いキャッシュは効果的ですね。
データフローはキャッシュフロー。一歩進むにつれお金が漏れ出すイメージです。
直接関係ありませんが、上記のような図はデータセキュリティやパフォーマンス改善時にも有益です。 例えば個人情報の流れを追うこともできます。
優先順位をつけていく
パフォーマンス ≒ ユーザー体験 ≒ コスト
コスト削減だけだと現場への説得力としては弱いことがあります。同時にレイテンシが削減され、ユーザー体験が改善するものを優先すると良いでしょう。APIのレイテンシを下げれば、フロントエンド側のキャッシュで通信を削減すれば、ユーザー体験がよくなりコストも下がります。ユーザー体験改善との違いの一つが、アクセス量の多いような通常パスに絞って改善するところです。
＊プライム企業で経営会議レベルまで上申が必要になったら、脱炭素も添えておきましょう。
スケーラビリティ、信頼性の視点
リソースの浪費はスケールが難しくなったり、障害につながったりすることがあります。パフォーマンス同様、コストと両立を狙い優先順位を上げましょう。
あくまでも本番アプリケーションにかかるコストを削減する
成長が見込まれる事業なら、ユニットエコノミクスに効く本番環境のコストを削減していきましょう。ユーザー量とともに増加する部分です。
開発環境コストは割合としては低く、エンジニアの人数がドライバーになります。開発環境費用の削減ばかりやっていても本末転倒です。
難しいことに手をつけず、簡単なことばかりしても大きな成果はあがりません。覚悟を決め、アプリケーションのソースコード、アーキテクチャにも手を入れていきましょう。
前段から改善する
前段を改修し、後段のリクエスト数を下げることができれば、てこを効かせた大きなコスト削減が見込めます。後段の改善の必要性も下がります。ユーザーに近い方から改善しましょう。
後段を改善する
上記とは逆に、依存関係の一番奥を改善すれば、コンシューマーとなる部分全てをまとめて改善できることが期待できます。プラットフォームAPI部分のDBクエリが例です。
かんたんなもので影響が少ないものからやる
改善の勢いをつける意味で効果的です。ただし、これだけをやってないかは定期的に確認しましょう。
見えづらいところにも手をつける
初回の記事で記載した通り、サーバレスではコストが詳らかになります。
一方、コストが可視化できていると、その部分だけが削減対象になる傾向にあります。人間は見えているところを掃除するのに熱心なためです。TCOを削減したいなら、例えば共通費用のような按分しづらいよくわからない部分にも手を付けていきましょう。大きな成果は難しい取り組みから生まれます。
予実管理と予予分析
月次でのトラッキングで、締め日からしばらく時間かかってからレポートを眺めることが一般的です。推移確認としてはよいのですが、異常検知としては遅く、確認する時点でコスト増の事象が過ぎ去っていることがあります。終わったことを指摘しても無意味です。
起きた瞬間に検知できるようにしましょう。AWS Cost Anomaly Detection が便利です。
徹底してコストを削減するフェーズではコスト予測機能を駆使し、月次より短いサイクルで予定の金額と予測側の差異を確認しましょう。
組織構造を変える
- 最終的にはアーキテクチャがコストを決めます
- コンウェイの法則から、組織構造がアーキテクチャを決めます
- したがって、組織構造がコストを決めます
依存関係の深い部分にあるチームをどう扱うかがポイントです。人数もシステムも肥大化する傾向にあります。経営から見たロジスティクスもそうですが、最後段に前段からのしわ寄せが集中します。
除外事項
この記事では非本質的なコスト改善は除いています。例えばReserved InstanceやSavings Plan、契約による割引はプロダクトの改善とは無関係に発生するためです。もちろんRIのカバレッジが低いなら上げていきましょう。RDSならインスタンスファミリも揃えましょう。
結語
大きくコストを下げたいなら、AWSはもちろん、顧客理解、開発者理解、プロダクト理解が必須です。まずは可視化と共通理解から進めましょう。
文責: 高木
