はじめに
こんにちは、takagi (@tkg_216) です。私が開発運用に携わっている「カミナシ 従業員」では、クラウドサービスとしてAWSを主に利用しています。今年、運用していく中で「これ便利だな」と感じたAWSのモニタリング、オブザーバビリティに関する機能ベスト3を、以下の観点で紹介します。
- 背景や課題、なぜその機能を使おうと思ったか
- どうやって活用したか
- 効果や使ってみての感想
渋くていぶし銀な機能が多いですが、自分たちの環境でも活用できそう！であったり、そんなこともできるんだ〜というような何かしらの発見等があれば幸いです。
(1) S3 Storage Lens
S3 Storage Lens とは AWS が提供する S3 の利用状況をみるためのダッシュボードです。ストレージの合計やGETリクエスト数、ダウンロード済みバイト数などのメトリクスを見ることができます。
背景や課題、なぜその機能を使おうと思ったか
今回、S3 Storage Lens を使おうと思った背景には、S3 の料金が急増したことがあります。Cost Explorer で使用タイプで分析すると DataTransfer-Out-Byte の料金がほとんどを占めていました。DataTransfer-Out-Byte は名前の通り S3 からの転送にかかる料金です。カミナシ 従業員にはチャット機能があり画像を送受信することができます。チャットのトークルームの性質上、「チャットルームの人数 × 1画面に表示する画像数 × 画像送信数」分だけ S3 画像の転送がされるので転送料金がかかりやすい構造になっていました。さらに、トークルームに表示する画像はオリジナルの画質の画像を表示していたため送信時の画質サイズに依存して DataTransfer-Out-Byte が増加するようになっていました。
この対策として、
- トークルームに表示する画像はオリジナル画像を圧縮したサムネイル画像にする
- キャッシュを効かせるようにする
- 送信時に圧縮する
- ストレージやCDNを選定し直す
など、いくつか候補が上がりました。
これらの対策を全てやれば少なからず効果は出ることは予想できるものの、限られた工数の中で必要な効果を出すためにはもう少し詳細な転送量に関するデータが必要でした。
- どの顧客で多く使われているか
- 十分な効果が得られる施策はどこまでか
- チャットでのコミュニケーションという本来の目的と異なる使われ方をしていないか
を決めるための材料を集めるために S3 Storage Lens を使うことにしました。(3つ目の実際の利用状況についてはメトリクスからだけではわからないので CS の方を通してコミュニケーションが必要になります)
どうやって活用したか
S3 Storage Lens を有効化する方法は特別難しいものではありませんでしたが、プレフィックスレベルのメトリクスの取得を設定し忘れていて再設定が必要になりました。これを設定していないとバケット単位でのメトリクスしか見ることができず、今回のようにプレフィックスに顧客IDのようなものが含まれていてプレフィックス毎のメトリクスが見たいケースでは有効化が必要でした。
実際に、S3 Storage Lens で調査をするにあたって今回の DataTransfer-Out-Byte に関係がありそうなメトリクスとして「GET リクエスト」「ダウンロード済みバイト数」がありそれらを見ることで分析を進めました。
GET リクエスト数を分析すると特定の数社が平均的な利用に比べて多くのリクエストを送っていることがわかりました。これらの顧客に対してはどのようにチャットを普段利用しているかをCSの方にヒアリングしてもらい、通常の利用として問題のない使い方をしているか確認していただきました。サービスの使い方としては特別問題のないことがわかったので、あとは先ほど上げた施策のどれを実施するかを決めて実施することにしました。
今回実施した施策は、「トークルームに表示する画像はオリジナル画像を圧縮したサムネイル画像にする」というものでこれを実施することで80%近くコスト削減ができる見込みがありました。そこまでの効果が出れば収益構造上問題ないラインであることが確認できたため施策の実施を進めていきました。 リリース後、以下のように無事に S3 のコストが下がっていくことを確認できました。
本題から逸れるため具体的な構成等については少し触れる程度に留めます。サムネイル画像にする部分としては送られてきた画像を S3 に保存したことをトリガーに Lambda を起動し、サムネイル画像を保存する仕組みを実装しました。あとはそれを画面でサムネイルを表示する機能とオリジナル画像のダウンロード機能を実装しました。構成としてのイメージは以下です。
効果や使ってみての感想
S3 Storage Lensを使わない場合、アプリケーションログから画像の送信頻度や画像の容量などのデータを取得して解析する必要があるのに対して、Storage Lens 機能を有効化するだけで欲しい情報が取れて便利でした。実際に定量的なデータでチーム内外の人とコミュニケーションを取ることができたので話がスムーズになった部分も大きく、施策に対する自信度も持ちやすかったと思います。
今回、S3 のパス階層の浅いところに顧客IDのようなものが含まれていたためプレフィックスでの分析が効果を発揮しました。もし、顧客IDの前に日付などの階層があったら日付毎のメトリクスの分析しか定量データを得られなかった可能性もあり、S3 のプレフィックスを設計する大切さを実感しました。
(2) Amazon CloudWatch Lambda Insights
Amazon CloudWatch Lambda Insights は、サーバーレスアプリケーションの Lambda 関数ランタイムパフォーマンスメトリクスとログを収集および集計できる機能です。
背景や課題、なぜその機能を使おうと思ったか
前提として、Lambda のデフォルトで取れるメトリクスでは、メモリ使用率などのメトリクスを見ることはできず、見るためには Lambda Insights を有効化する必要があります。(1) の施策で作成したサムネイル作成用 Lambda は画像処理をすることもあり、実際のメモリ使用量などのメトリクスが予測しにくいため、Lambda Insights を有効にしてリリース後のメモリ使用率を経過観察するために Lambda Insights を使うことにしました。
補足：Lambda のCPU・メモリに関する設定について事前に最適な設定値を探すLambda Power Tuning (Application Search - AWS Serverless Application Repository) というツールがあります。このツールではある実行条件に対して、CPUとメモリの設定値を変化させていきながらコストや実行時間の最適値を見つけていくものになります。今回はLambdaで処理する画像がユーザー依存であるのでこのツールでの事前最適化に限界があるから、リリースしてから最適化しようという戦略を採用しました。 参考： qiita.com
どうやって活用したか
Lambda Insights を有効化するには、LambdaInsightsExtension の Layer を追加する必要があります。Terraform では以下のように Layer を追加します。
resource "aws_lambda_function" "xxx" { <figure class="figure-image figure-image-fotolife" title="ダッシュボード機能">[f:id:kaminashi-developer:20251222102012p:plain]<figcaption>ダッシュボード機能</figcaption></figure> function_name = "name" (略) layers = [ "arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:34", ] }
参考: Available versions of the Lambda Insights extension - Amazon CloudWatch
設定して Lambda をデプロイすると Lambda Insights の画面からメトリクスを見ることができます。リリース直後は Runtime.OutOfMemory がたまに発生してエラー終了することがありました。メモリ使用量のメトリクスを見ると100%に達することがたまにあり、全体で見ても高めのメモリ使用量となっていました。そのため、メモリの設定値を上げることを意思決定し、経過観察すると Runtime.OutOfMemory の発生がなくなり、安定して稼働するようになりました。
やりたかったこととしてはこれで十分だったのですが、 Lambda Insights を使っていると特定のリクエストからログに飛べる機能を見つけました。下の画像のように特定のリクエストをチャックして「アプリケーションログを表示」を選択すると CloudWatch Logs Insights の画面に検索条件が設定された状態で遷移し、見たいログをすぐに見ることができました。今回使うまではこの機能を知らなかったのですが、AWS のオブザーバビリティ周りの進化を感じました。
効果や使ってみての感想
事前に検証して最適なメモリを割り当てることも大事だと思いますが、実データであるメトリクスを見ないとわからないことも多いのでLambda Insights のコストを許容できるのであればまず入れてみて安定してから外すという選択肢もあるのかなと思いました。Lambda Insights では initDuration(いわゆる起動時間)のメトリクスも取れるのでコールドスタートが気になるようなケースでも活用しやすいものかと思います。
(3) Billing and Cost Management ダッシュボード
2025/09にアップデートされた機能です。 aws.amazon.com
背景や課題、なぜその機能を使おうと思ったか
自分自身は AWS Cost Explorer に多少慣れていて AWS の利用料についてサービス、使用タイプ、API毎などで変化の傾向を見ることに慣れていたが、チームの全員がそうではないという背景がありました。特に、自分たちが開発運用しているプロダクトの健康診断をするサービスレビューの際に AWS のコストをモニタリングしているが Cost Explorer の使い方を覚えたり、みたいものが見れる状態に設定にするのが手間であるという課題がありました。このアップデートにタイムリーに気付くことができ、使えそうだったので試しに導入してみました。
どうやって活用したか
全体の料金については月次の推移、利用料金が変化しやすい AWS サービスについては日次での推移、をウィジェットとして作成しダッシュボードを作成しました。特に、全体の料金については Reserved Instance などの割引を考慮して最も実態に近い値をみたいため詳細オプションとして「純償却コスト」を選択してウィジェットにしました（この辺が手間に感じていたポイントです）。※ 純償却とはリザーブドインスタンス (RI) やSavings Plansなどのコミットメント契約において、前払い料金や月額料金を契約期間全体に均等に分散し、さらに適用される割引も考慮した「実質的なコスト」 を表示する指標です。
効果や使ってみての感想
今までは隔週でやっているサービスレビューの準備に Cost Explorer で画面をポチポチしてからスクショを撮るという作業が必要だったのですがその作業が不要になり、コストをモニタリングする準備をする手間が減り、誰でもモニタリングをしやすい環境に近づいたと思います。サービスレビュー時でない時も機能リリースなどの影響でコストが跳ね上がっていないかを確認する際にも活用しやすいです。ダッシュボードの使い勝手としても期間の選択や、ウィジェットから Cost Explorer への移動ができたり使いやすい機能だと思いました。
このダッシュボードをPDF化して出力する機能が最近発表されたので、API等でエクスポートして自動でレポーティングできるようになるといいなと思います。参考: AWS Billing and Cost Management now supports PDF export and CSV data download for Dashboards - AWS
まとめ
以上、今年使ってみて良かった AWS のモニタリング、オブザーバビリティ機能ベスト3の紹介でした。
個々のAWSサービスについて深くメトリクスなどを見るためには CloudWatch のデフォルトのメトリクスだけでなく、サービスに特化した機能を活用すると良いインサイトが得られることも多くあるのかなと思います。リソースの効率化やコスト最適化をするために設定や対策を手数多く実行することも有効なケースもあると思いますが、定量的に分析し可視化することで効率よく自信を持って運用していくことができるため、さまざまなシーンでモニタリングやオブザーバビリティを生かす余地があるのだと思いました。また、AWS のアップデートを見ているとこのあたりの領域のアップデートも活発なためアップデートをウォッチしたり使ったことのない機能を試すことでモニタリング、オブザーバビリティの武器を増やしていきたいです。
最後に、カミナシではエンジニアを積極的に採用中です。ご興味をお持ちの方、XでのDM、採用ページからのご連絡お待ちしております。
