AWS Lambdaの可観測性コストが膨らんでいませんか
サーバーレスアーキテクチャを採用したプロジェクトが本番稼働し始めると、ある問題が浮上することがあります。それが可観測性（Observability）のコストです。
AWS Lambdaのログは、デフォルトでAmazon CloudWatch Logsに送信されます。最初のうちは問題ないのですが、Lambda関数の数とトラフィックが増えるにつれて、CloudWatchのログ取り込みコストが想定外の速度で膨れ上がっていきます。CloudWatch Logsの標準的なデータ取り込み料金は$0.50/GB（US East リージョン）です。1日5TBのログを取り込むシステムでは、1日あたり$2,500、月額$75,000を超えるコストが発生する計算になります。
本記事では、Serverless Frameworkの公式サポートを受けた可観測性プラットフォーム「Axiom」を活用することで、この問題をどのように解決できるのかを解説します。設定はわずか1行のYAMLで完了します。
Axiomとは何か
Axiomは、ログ・メトリクス・トレースを一元管理できるクラウドネイティブな可観測性プラットフォームです。独自のクエリ言語であるAPL（Axiom Processing Language）を搭載しており、大量のイベントデータに対して高速かつ柔軟な分析が可能です。
Axiomの主な特徴をまとめると以下のとおりです。
機能 | 概要 |
|---|---|
APLクエリ言語 | パイプ演算子でデータを連鎖的に処理できる強力なクエリ言語。フィルタリング・集計・時系列分析に対応 |
自動ダッシュボード | AWS Lambdaのログを検出すると、関数ごとのパフォーマンスダッシュボードを自動生成 |
スマートフィルター | Lambda関数名やServerlessプロジェクト単位での絞り込みが1クリックで実行可能 |
モニター・アラート | コールドスタート・エラースパイク・タイムアウトを検知してアラートを発報 |
寛大な無料枠 | 月間500GBのデータ取り込みが無料。小〜中規模のチームは実質無料で利用可能 |
2024年10月にServerless Frameworkとのネイティブインテグレーションがリリースされてから、AWSサーバーレス開発者の間で急速に採用が広がっています。
CloudWatch vs Axiom コスト比較
最も注目すべき差はデータ取り込みコストです。同じ5TB/日のログデータを処理した場合、以下のような差が生じます。
項目 | Axiom | AWS CloudWatch Logs |
|---|---|---|
取り込み単価 | $0.15/GB | $0.50/GB |
日次コスト（5TB） | $750 | $2,500 |
月次コスト（5TB/日） | $22,500 | $75,000 |
月額差分 | $52,500の節約（約70%削減） | |
無料枠 | 500GB/月 | 5GB/月（AWS Free Tier） |
コスト面だけでなく、機能面でも大きな違いがあります。
機能比較 | Axiom | AWS CloudWatch Logs |
|---|---|---|
クエリ言語 | APL（高度なパイプライン処理） | CloudWatch Logs Insights（独自SQL風） |
マルチクラウド対応 | あり（AWS・GCP・Azureなど） | なし（AWS専用） |
ダッシュボード | 自動生成・高度なカスタマイズ | 手動設定が必要 |
データ保持期間 | 柔軟（プランによる） | 設定変更が必要（デフォルト無制限課金） |
サンプリング | 不要（全データ保持推奨） | コスト削減のため採用しがち |
Axiomは「ログを間引いて（サンプリングして）コストを抑える」という旧来の発想とは異なり、すべてのログを取り込んでも低コストを維持できる設計思想で作られています。
Serverless FrameworkでAxiomをセットアップする
Axiomの最大の魅力のひとつが、Serverless Frameworkとの統合のシンプルさです。設定はわずか数ステップで完了します。
ステップ1 Axiomアカウントとトークンを作成する
まずaxiom.coでアカウントを作成します。オンボーディング中にデータセットの作成をスキップしてください（Serverless Frameworkが自動的に最適な設定で作成します）。
ダッシュボードのSettings → API Tokensから新しいAPIトークンを作成し、以下の権限を付与します。
- Ingest
- Query
- Datasets
- Dashboards
- Monitors
作成したトークンを環境変数 AXIOM_TOKEN に設定します。CI/CDパイプラインやローカルの .env ファイルに記述することで、Serverless Frameworkが自動的に読み込みます。
ステップ2 serverless.ymlを設定する
serverless.yml の stages ブロックに observability: axiom という設定を追加するだけです。全ステージに共通して適用する場合は default キーの下に記述します。本番ステージのみに絞りたい場合は production キーの下に書くことも可能です。
この設定を追加してデプロイすると、Axiom側のデータセットが自動作成され、CloudWatch LogsへのサブスクリプションフィルターがLambda関数ごとに設定されます。追加のコード修正は一切不要です。
ステップ3 デプロイして確認する
serverless deploy コマンドを実行するだけです。デプロイ後にLambda関数を呼び出すと、すぐにAxiomダッシュボードでログを確認できます。Axiomは自動的にAWS Lambda専用のダッシュボードを作成します。
より細かい制御が必要な場合は、ステージごとに設定を分けたり、カスタムデータセット名を指定したりすることができます。本番環境と開発環境を明確に分離した運用が実現できます。
APLクエリを使った高度なデバッグ
Axiomの真の強みは、APL（Axiom Processing Language）を使った高度なデータ分析です。APLはパイプ演算子（|）でオペレーターを連鎖させる構造を持ち、SQLよりも直感的にデータを分析できます。
以下はよく使われるAPLクエリのパターンです。
分析目的 | APLのポイント |
|---|---|
エラーが多いLambda関数を特定する |
|
コールドスタートを分析する |
|
実行時間のボトルネックを特定する |
|
特定Lambda関数のログを絞り込む | スマートフィルターから対象関数を選択するか、 |
これらのクエリをベースに、チームの要件に合わせたカスタムダッシュボードを構築することができます。保存したクエリはチームメンバー全員が共有でき、インシデント対応のスピードアップにつながります。
ベストプラクティスと注意点
Axiomを本番環境で活用するうえで、いくつかのベストプラクティスを押さえておくと良いでしょう。
項目 | 推奨アプローチ |
|---|---|
トークン管理 | AXIOM_TOKENはCI/CDパイプラインのシークレット管理（AWS Secrets Manager等）で安全に保管する |
ステージ分離 | productionとdevelopmentで別々のAxiomデータセットを使用し、ログを明確に分離する |
データセット命名 | デフォルトでprod/productionステージは「prod-aws-cloudwatch」という名前になる |
移行タイミング | CloudWatchとAxiomは並行稼働できるため、段階的な移行が可能。まず開発環境から試す |
無効化方法 | serverless.ymlからobservabilityを削除し、AXIOM_TOKENを保持したままデプロイするとサブスクリプションが解除される |
CloudWatchとの共存 | 移行期間中、Lambda関数のログはCloudWatchとAxiomの両方に送信される（コストの一時的な増加に注意） |
まとめ
Serverless Framework × Axiomのインテグレーションは、AWS Lambdaを活用したサーバーレスシステムの可観測性コストを大幅に削減しながら、むしろ可視性を向上させるアプローチです。
ポイントをまとめます。
- CloudWatch Logsと比較して最大70%のコスト削減が期待できます
- 設定はserverless.ymlへの1行追加だけで完了します
- 月間500GBの無料枠があり、小〜中規模チームは実質ゼロコストで試せます
- APLクエリによる高度な分析とAWS Lambda専用ダッシュボードが自動生成されます
- CloudWatchからの移行は非破壊的で、段階的に進められます
サーバーレスアーキテクチャを運用しているチームにとって、今すぐ試す価値のある選択肢と言えます。まずは無料枠の範囲で開発環境に導入してみることをおすすめします。
