NewsPicksの高山です。
今回は、AWSのコストを我々がどのように定点観測しているかを書いていきます。 あわよくば他社さんも事例を広く共有してもらえて業界全体の共有知が増えることに繋がってほしい狙いがあります。
NewsPicksでは過去2年ぐらいかけて地道にコストモニタリングのオペレーションを作ってきました。手法としては、毎週コストモニタリング担当のメンバーで定例ミーティングをして、以下の手順をやりながら議事録にまとめていきます。
毎週のオペレーション
コスト異常検出
コスト異常検出という機能の画面を見て、最近大きく変化したリソースを調査します。
異常検出はメールでも通知していますが、毎週のオペレーションとして一つ一つ詳しく見ていく「トリアージ」をしないと放置してしまうので、コストモニタリングの定例で必ず見るようにしています。
このように影響の大きかった項目を見て、Cost Explorerで表示します。
このように、異常検出された期間を含む2週間分のグラフに直接飛べます。2週間分ではよくわからないことが多いため、必要に応じて期間を延ばします。
誤検出もそこそこありますが、月に1回ぐらいは有用な検出があります。
有用な検出だった場合には関連するチームにエスカレーションして次の定例ミーティングで確認します。
Savings Plansの購入
Savings Plans推奨事項に出ていればCompute Savings Plansを購入します。
Savings Plansにする前はEC2のReserved Instanceを毎年購入していましたが、インスタンスファミリーを跨いで適用することができないなどの制約があるため、現在では最も柔軟なCompute Savings Plansだけを買うことにしています。これによってコストモニタリングで考えることも減り、引き継ぎしやすくなりました。
このタイミングでSavings Plansのカバレッジレポートや使用状況レポートも簡単に確認します。これをやっておくと、変化があったときにすぐに気づくことができます。
DynamoDBのReserved Capacityの購入
Savings Plansと同様にDynamoDBのReserved Capacityも、詳細を気にすることなくカバレッジが低くなったら買うことのできるリソースです。
しかし、DynamoDBのカバレッジは公式で提供されている画面がありませんので、我々の場合はCost Explorerの次の画面を使ってカバレッジを推測しています。紫のOn Demandと緑のReservedの比率や、On Demandがゼロにどのぐらい近いかを見て買うようにしています。
これによって、DynamoDBのProvisioned Capacityに対してどのぐらいをReserved Capacityで購入しているかがわかります。しかしながら、Provisioned Capacityが必要最低限の量になっているかどうかまでは分からないので、改善の余地があります。
毎月のオペレーション
請求書CSVの取り込み
毎月2日ぐらいにAWSコンソールの請求ダッシュボードからCSVをダウンロードすることができます。
このCSVをスプレッドシートに取り込み、ピボットテーブルを作ります。
- ピボットテーブルにする範囲は元のCSV全体
- 行はProductName
- 列は、CostBeforeTax, Credits, TaxAmount, TotalCostのSUM
- フィルタで
RecordType=PayerLineItem,ItemDescriptionが"Sign up charge"を含まない,UsageTypeが"yrAllUpfront"を含まないを追加- 最初のフィルターは親アカウントに結合した請求項目として出すため。後ろの2つは何かのタイミングで追加したのですが、詳細は忘れました。これらを追加することで、請求書のPDFと同じ金額になるようになっているはずです。
これを別シートからVLOOKUPで参照し、前月と比較します。
条件付き書式で前月から$1000以上増加は赤、前月から$500以上増加は黄色、前月から1.5倍以上になったら青のように色分けしています。
ここで色が付いている項目を見て深掘り調査します。
Cost & Usage ReportとQuickSight
Cost & Usage Report (CUR; コストと使用状況レポート) は一言でいうと上記の請求書CSVのすごいやつです。
これを使うには、まず定期的にCURをS3に出力する設定を有効化する必要があります。
CURを使う時にぜひやっておきたい設定が、まずAthenaを使ってCURを分析できるようにすることと、QuickSightからAthena経由で分析できるようにすることです。
こちらのページの手順に従ってCloudFormationを実行すればAthenaからアクセスできるようになります。
QuickSightで可視化できるのは次のようなグラフです。AWSのCost Explorerと何が違うかというと、例えばDynamoDBであれば一つ一つの特定のテーブルにいくらコストがかかっているかが見られる点です。例えばこれはX軸に line_item_usage_start_date 、Y軸に line_item_unblended_cost をプロットして line_item_resource_id でグループ化したものを、 product_servicename=Amazon DynamoDB でフィルタリングしたものになります。
このようなグラフをDynamoDB以外にも主要なサービスについて作っておくと、すぐに異常に気づけたり、調査するときにもCost Explorerに比べると格段に捗ります。
たまにやるオペレーション
Reserved Instanceの購入
RDS, Redshift, ElastiCacheについては毎年特定の時期にまとめてReserved Instanceを買うことにしています。
次の購入時期の数ヶ月前から、インスタンスを変える可能性があるかを主にSREと一緒に確認し、当月に備えます。
Reserved Instanceが切れてから1週間ほどすると「推奨事項」の中に購入すべきReserved Instanceが出てくれますが、この1週間ぶんのコストが無駄なので、事前に次回購入するリソースを出して、切れたらすぐに買うようにしています。
規模の適正化に関する推奨事項
規模の適正化に関する推奨事項は英語だとRightsizingと呼ばれる画面で、EC2のインスタンスを小さいインスタンスに減らせますよとお勧めされる機能です。
以前にこれを見ながらコスト削減余地の大きなリソースについては最適化しましたが、それらが終わった後はほとんど変化することも無くなったので、現在ではほぼ見ていません。
Trusted Advisor
次のような画面です。こちらも以前に重点的に見てあらかた対応した後はほとんど見ていません。
Compute Optimizer
次のような画面です。使いこなせると良さそうですが、現在の我々ではほぼ使いこなせていません。今後の課題です。
まとめ
このように、NewsPicksではコストモニタリングの定例ミーティングを作り、その中で毎週や毎月のオペレーションをこなしています。
毎週同じメンバーで同じグラフを見て、気づいたことはその場でトリアージして、対応が必要なものはチケット化しています。
他社さんで他にやっていることがあれば是非教えてください。
