AWS ログ分析の選択 — Logs Insights vs Athena vs OpenSearch
ログを集めるコストは CloudWatch Logs 削減編で扱いました。この記事はその次の質問、集めたログをどこで分析するかです。結論を先に書くと、たまに調査するときだけ探すログは Logs Insights、S3 に長期保管して SQL で問うログは Athena、常時ダッシュボード・全文検索・アラートが必要なログだけ OpenSearch です。 3 つは競合ではなく照会頻度による層で、すべて OpenSearch に入れる構成がこの領域で最もよくある払い過ぎです。料金は us-east-1 基準です。
一目でわかる比較 #
| 項目 | Logs Insights | Athena + S3 | OpenSearch |
|---|---|---|---|
| データの場所 | CloudWatch Logs | S3 | 専用クラスター・コレクション |
| 課金 | スキャン GB あたり約 $0.005 | スキャン TB あたり約 $5 | インスタンス時間または OCU |
| アイドルコスト | 0(照会時のみ) | 0(照会時のみ) | 常時(ドメイン・OCU の下限) |
| クエリ言語 | 専用文法(+PPL/SQL 対応) | 標準 SQL | クエリ DSL・ダッシュボード |
| 合う頻度 | たまに(調査・デバッグ) | 定期的(レポート・監査) | 常時(ダッシュボード・アラート) |
| レイテンシー | 秒単位 | 秒〜分単位 | ミリ秒(インデックス完了後) |
| 準備作業 | なし | パーティショニング・フォーマット設計 | インデックスパイプライン・容量設計 |
Logs Insights — すでにあるログをその場で #
アプリケーションのログがすでに CloudWatch に入っているなら、調査・デバッグ用途の最初の答えは Logs Insights です。別のパイプラインなしにロググループを選んですぐクエリでき、料金はスキャンした GB あたり約 $0.005 だけです。障害調査のように 1 日数回、数 GB をなめる使い方なら月額は数ドルで終わります。
限界も明確です。料金がスキャン量に比例するため、時間範囲を広く取ったクエリを常時回した瞬間に料金構造が崩れます。 ダッシュボードを Insights クエリで作って 5 分ごとに全ログをスキャンする構成が典型的な失敗です。常時照会が必要になったということはこの層の用途を超えたという合図で、そのときが OpenSearch を検討する時点です。照会の習慣(時間範囲を絞る、ロググループを特定する)は収集削減編で書いたとおりです。
Athena + S3 — 長期保管と SQL の組み合わせ #
ログを長期保管するなら S3 が向いており(収集編の結論)、S3 上で SQL を実行するのが Athena です。スキャン TB あたり約 $5 の純粋な照会課金でアイドルコストがなく、ALB アクセスログ・CloudTrail・VPC Flow Logs のようにもともと S3 に落ちるログはこの組み合わせが事実上のデフォルトです。月次レポート、セキュリティ監査、「先四半期の特定 IP のリクエスト全数」のような質問がこの層の仕事です。
料金を分けるのはスキャン量で、スキャン量を分けるのは保管の設計です。日付・サービスでパーティショニングし、JSON の原文ではなく Parquet のようなカラムナフォーマットで圧縮しておくと、スキャン量が桁で減ります。 同じ質問がパーティションなしの JSON では 200GB をスキャンし($1)、パーティション済みの Parquet では 2GB をスキャンする($0.01)違いです。逆に言えば Athena の料金が痛くなり始めたら、クエリではなく保管フォーマットを先に直します。保管階層自体の料金は S3 ストレージクラス比較の領域です。
OpenSearch — 常時性に固定費を払う層 #
OpenSearch が与えるのはミリ秒の検索、リアルタイムダッシュボード、全文検索、ログベースのアラートです。対価は常時稼働のコストです。マネージドドメインはインスタンス時間課金で、小型の本番構成でも月数百ドルから始まり、サーバーレス(OCU 時間あたり約 $0.24)もコレクションの種類によって最低 OCU の下限があり、月数百ドル水準の下限が生まれることがあります(最新世代のコレクションはアイドル時に 0 まで下がる構成も登場したため、導入時点で確認)。どちらにしても、「照会するときだけ払う」前の 2 層と違って、存在自体にお金が出ていく層です。
だから判断基準は機能ではなく常時性です。運用チームが 1 日中開いておくログダッシュボード、数百 ms 以内に応答すべきログ検索画面、ログパターンベースのリアルタイムアラートのように、常時照会が実際の要件のときだけこの固定費が正当化されます。「あれば良さそうだから」と全ログをインデックスする構成は、収集料金とインデックスコストを二重に払う結果になります。
組み合わせ — 3 つは層として積みます #
実務の構成は 1 つを選ぶのではなく、ログの照会頻度で分けることです。典型はこうです。アプリケーションのログは CloudWatch で受けて調査用に Insights を使い、保持期間が過ぎたら S3 にエクスポートして Athena が監査・レポートを受け持ちます。そのうち常時ダッシュボードが必要なサービスのログだけを OpenSearch にサブスクリプション配信します。こう分けると OpenSearch クラスターのサイズが全ログではなく常時照会のログにだけ比例するようになり、3 層の合計が全量インデックス構成の数分の 1 に下がることが多いです。
選択の手順 #
- 照会頻度でログを分類します: たまに(調査)、定期的(レポート・監査)、常時(ダッシュボード・アラート)の 3 つの枠にログの種類を割り当てます。この分類がそのままアーキテクチャです。
- たまにの枠は Logs Insights で終えます: パイプラインなしですぐ使い、時間範囲を絞る習慣だけ守ります。
- 定期的の枠は S3 + Athena に送ります: パーティショニングと Parquet 変換までが導入で、この設計がスキャン料金の桁を決めます。
- 常時の枠だけ OpenSearch を検討します: 常時照会の要件を文章で書けるときだけ固定費を承認し、インデックス対象をそのログに限定します。
- 境界の移動を定期的に見ます: Insights の料金が大きくなったら常時化の合図なので OpenSearch への編入を、OpenSearch のインデックスのうちダッシュボードで使われないログは S3 への降格を検討します。
まとめ #
- 3 つは競合ではなく照会頻度の層です。たまには Insights、定期的は Athena、常時だけ OpenSearch です。
- Insights(スキャン GB あたり約 $0.005)はパイプライン不要の最初の答えですが、常時照会に使うと料金構造が崩れます。
- Athena(スキャン TB あたり約 $5)の料金は保管の設計が決めます。パーティショニング + Parquet がスキャン量を桁で減らします。
- OpenSearch は存在自体にお金が出ていく層です。常時照会の要件が文章で書けるときだけ、そのログに限定してインデックスします。
- 全ログの OpenSearch インデックスがこの領域最大の払い過ぎパターンです。層を分ければ合計が数分の 1 に下がります。