はじめに
こんにちは。ニフティに新卒で入社して5年目の佐々木です。今回はAWSのサービスの一つであるCloudWatchについてコスト削減を行う方法を紹介します。
以前ご紹介したコスト削減手法ついては、以下のブログ記事をご参考ください。
背景
ニフティではサービス基盤にAWSを活用しており、コスト削減のためにサービスのインフラ効率を追求する取り組みや、有志で取り組んでいる社内でのコスト削減勉強会なども実施しています。
CloudWatchのコスト削減においてのポイントや注意点について簡単にご紹介したいと思います。
この記事の内容
- 触れること
- CloudWatchのコスト削減方法
- CloudWatchのコストを削減する上での注意点
- 実際に試した社内でのコスト削減事例とTips
- 触れないこと
- CloudWatch自体の詳細の説明
- 自社での詳しいインフラ構成（コスト削減が目的のため、今回は一般的なインフラ構成のご紹介に限らせていただきます）
CloudWatchの基本
CloudWatchとは、AWS上で展開されるサービスを監視するサービスです。
CloudWatchのコスト削減
課金形態
サービスの運用にかかるコストを正確に把握するため、いつもの如くAWSの公式をチェックしましょう。
2024年1月現在では主に以下のようになっています。（ap-northeast-1の場合で無料利用枠は除きます）
- ログの収集（データ取り込み）に対する課金
- 例えば「収集 (データインジェスト)」の場合はスタンダードへの配信で0.76USD/GB課金される
- 取り込むログのデータサイズの取り込み量に依存される
- ログのデータの保存に対する課金
- 取り込むログ量だけでなく、ログデータの保存期間や保存先によっても追加で課金対象となる
- 例えば、CloudWatchの「保存（アーカイブ）」の場合は0.033USD/GB課金される
- メトリクスに対する課金
- 最初の 10,000 メトリクスの場合0.30USD課金される
- アラームに対する課金
- アラームが発生した最初の時間からが課金対象
- 例えば「標準解像度メトリクスアラーム」の場合はアラームメトリクスあたり 0.10USD課金される
その他にも課金要素はありますが、主に重要なのはこの3つだと思います。
詳細はこちらのAWS公式の資料をご参考ください。
コスト削減方法
次に、CloudWatchに対する一般的なコスト削減方法をご紹介します。
- ログのサイズの削減
- CloudWatch Logs は基本的には安価でかつ活用場面も多いかと思いますが、ログ量が多くなると保存に対する課金も無視できなくなってきます。
- そのため、まずは大元のログの量そのものを減らす方向で検討すると良いかと思います。
- ログのデータ保存方法の最適化
- 前述した通り、CloudWatchの「収集 (データインジェスト)」の場合は0.033USD/GBですが、S3の「S3標準」の場合は0.023USD/GBなので、データ保存先としてはS3の方がコストメリットが大きいです。
- 監視方法や保存期間などによりますが、リアルタイムでの監視が必要がないデータはS3へ移行し、CloudWatch Logs に保存する期間をその分短く設定するなどの最適化を行うことで、コスト削減の効果が狙えます。
- 実際に削減する際には、ログ保存期間の社内ルールなどと照らし合わせつつ最適な保存方法を検討すると良いかと思います。
- 使われていないメトリクス・アラームの見直し
- こちらも一つあたりの単価は安いので積極的に使いたいところですが、量が多いとそこそこの料金がかかります。
- もし環境ごとや機能ごとなどに個別にアラームやメトリクスなどを定義していた場合は、開発環境で明らかに必要のないアラートを既に使われなくなったメトリクスなどを見直してみても良いかもしれません。
実際に社内で試したこと
ログサイズの削減
担当したサービスでは、バックエンドで定義したAPIのデータ取得のタイミングで、特定のINFOログを生成していました。該当のログでは、接続先のURLやユーザーIDなどのメタ情報を出力しています。
これは、障害等が発生した場合などに、該当のAPIが問題なく動作していることを確認するために必要で、CloudWatch Logs への出力によりログの解析ができるようになっています。
CloudWatchに出力することを想定したINFOログが冗長なものになっていたので、ログ出力時の文言などを調整することでサイズを最適化しました。
また、今回のコスト削減の方針としては、「開発者として必要な情報量は減らさずにコストのみを削減する」といったことを目的としています。
出し分ける必要のないログは1つのログに集約する
削減自体の内容としては非常に簡単に行えました。
一部のログで、単一のリクエストを送るタイミングで複数のINFOログを送信する仕様になっていたため、コスト削減のためこちらを単一のログに集約してみます。
出力する文言としては、分かりやすさを重視するために以下のような形でした。（以下の例では、GoのロギングライブラリであるZapを使用しています）
|
1 2 3 4 5 6 7 8 |
logger.Info("msg", zap.String("id", "XXX-001"), zap.String("body", "接続先URL: "+url), ) logger.Info("msg", zap.String("id", "XXX-002"), zap.String("body", "生成パス: "+filePath), ) |
上記の形だと、個別のログそれぞれに対してタイムスタンプ等の情報が付与されてしまうので、余分にログのサイズに計上されてしまう恐れがありました。
そのため、以下のように1つのログに集約することで、全体のログサイズを削減しました。
|
1 2 3 4 |
logger.Info("msg", zap.String("id", "XXX-001"), zap.String("body", "接続先URL: "+url + " 生成パス: "+filePath), ) |
このような形で、チームメンバーと都度相談しながら出力されるログを必要なものだけに整理することで、結果的にCloudWatch全体の約5%のコスト削減を達成することができました！
学んだ教訓とTips
全体を通しての感想ですが、CloudWatchは気軽に利用できる反面、コストについて考える機会はあまりなかったと感じました。ただ、課金内容を詳しく調べてみると「意外とここで指定したログがかなり料金を食ってるなー」みたいな箇所が割とすぐに分かったので、対処自体はしやすいですし取り組むモチベーションにもつながるのかなと個人的には感じました。
まとめ
今回はCloudWatchのコスト削減方法についてご紹介しました。
重ねてになりますが、現状のコストを分析することで不要なリクエストや課金形態の発見に繋がることがあるので、普段使用しているサービスをCostExplorerなどで確認することが大事だなと思います。
CloudWatchについては、やや課金形態が細かく様々な要因で課金発生することも多いので、サービスの要件とも照らし合わせて要不要を分析しながら改善していけると良いのかなと思います！
他のAWSサービスでもコスト削減事例が思いついたら別のブログ記事にする予定なので、また機会があれば紹介したいと思います！
We are hiring!
ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！
ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！
カジュアル面談も受け付けています！
Tech TalkやMeetUpも開催しております！
こちらもお気軽にご応募ください！
