はじめに

Web サーバー運用のなかで Apache のログ分析は非常に重要です。しかし従来のログ分析方法は多くの課題を抱えています。
この記事では AWS のサービスである CloudWatch Logs Insights を使った Apache ログ分析の方法を検証します。その設定手順から実践的なクエリ、そしてよく議論される S3 + Athena 構成との比較までを解説します。

従来のApacheログ分析とその課題

これまで多くの現場では、Apache のログを分析するために以下のような手順が取られてきました。

  1. 調査対象の各 EC2 インスタンスへ SSH でログインする。
  2. /var/log/httpd/ などのログディレクトリへ移動する。
  3. access_log や error_log に対して grep awk sort wc などのコマンドを駆使して目的の情報を探す。
  4. 必要に応じて複数のサーバーで同じ作業を繰り返す。

この方法はシステム規模が大きくなると様々な課題が顕在化します。従来のログ分析は手間と時間がかかります！

課題項目 具体的な内容
非効率性 複数サーバーへのログインやコマンド入力に多大な手間と時間を要する。
分析の限界 全サーバー横断での集計や複雑な条件での抽出、時系列分析が極めて困難。
スケーラビリティ サーバー台数の増加に調査時間が比例して増大する。
属人化 高度なコマンドラインスキルを持つ特定の担当者しか詳細な調査ができない。
管理の複雑さ ログファイルが各サーバーへ分散し一元管理や長期保管が難しい。
コマンド実行リスク SSH 接続下でのコマンド誤操作によるサービス影響。

ログ分析のモダンな選択肢

AWS を活用することでこれらの課題を解決するモダンなログ分析基盤を構築できます。主に以下の選択肢が考えられます。

1. S3 + Athena 構成

  • 各サーバーのログを Amazon S3 へ集約します。
  • AWS Glue でデータカタログを作成します。
  • Amazon Athena を使用して S3 上のログデータへ SQL でクエリを実行します。
    この構成は柔軟なデータ処理とコスト効率の高い長期保存に優れています。

2. CloudWatch Logs Insights

今回メインで検証するサービスです。

  • 各サーバーのログを Amazon CloudWatch Logs へ収集します。
  • CloudWatch Logs Insights を使用して CloudWatch Logs 内のログデータへ専用のクエリ言語で直接クエリを実行します。
    この構成は 設定の手軽さとリアルタイムに近い分析が魅力です！

CloudWatch Logs InsightsによるApacheログ分析 検証手順

それでは実際に CloudWatch Logs Insights を使って Apache のログ分析を検証していきましょう。

前提条件

  • 分析対象の Apache サーバーのアクセスログ (例: access_log) 及びエラーログ (例: error_log) が Amazon CloudWatch Logs の特定のロググループへ収集されていること。
  • 検証を行う IAM ユーザーまたはロールに CloudWatch Logs への読み取りアクセス権限、CloudWatch Logs Insights の実行権限が付与されていること。

ステップ1: CloudWatch Logs Insightsへのアクセス

  1. AWS マネジメントコンソールにログインします。
  2. サービス検索窓で「CloudWatch」と入力し CloudWatch のコンソールを開きます。
  3. 左側のナビゲーションペインから「ログ」セクションの「ログのインサイト (Logs Insights)」を選択します。

ステップ2: 分析対象ロググループの選択

CloudWatch Logs Insights の画面上部にある「ロググループを選択」ドロップダウンメニューから分析したい Apache のログが格納されているロググループを選択します。

分析対象の Apache ログが含まれるロググループが選択できることを確認できました！

ステップ3: 基本的なクエリの実行とログ形式の確認

まずログが正しく取り込まれておりクエリが実行できることを確認します。

  1. 直近のログを表示
    クエリエディタへ以下のクエリを入力し「クエリの実行」をクリックします。 
    fields @timestamp, @message
| sort @timestamp desc
| limit 20


    最新のログメッセージが正常に表示されることを確認できました！CloudWatch Logs Insights は設定が非常に簡単です！

  2. Apacheログ形式の確認とparseコマンドの準備
    表示された @message の内容から Apache ログの形式（Combined Log Format など）を確認します。CloudWatch Logs Insights で特定のフィールドを抽出するには parse コマンドを使用します。
    例えば Combined Log Format の場合、以下のような parse コマンドで各フィールドを抽出できます。

    parse @message '* - - [*] "* * *" * * "*" "*"' as clientIp, logTimestamp, request, httpStatus, bytesSent, referrer, userAgent

    この parse コマンドを後のクエリで活用します。

ステップ4: 実践的な分析クエリの実行

次に具体的なシナリオに基づいてより実践的な分析クエリを実行してみましょう。基本的なクエリでログの取り込みをすぐに確認できました！

検証項目1: 効率性・一元管理 (直近1時間の全サーバーの総アクセス数)

  • シナリオ: 直近1時間の全サーバーの総アクセス数を確認する。
  • CloudWatch Logs Insights クエリ例: 
    fields @timestamp
| filter tomillis(@timestamp) > 1715767260000
| stats count(*) as total_requests

    1715767260000 の部分は「1時間前」をエポックミリ秒で指定してください（ Epoch Converter などで変換可能)

    単一クエリで直近1時間の総アクセス数を集計できる効率性を確認できました！

検証項目2: 高度な分析（集計 – アクセス上位IPアドレス）

  • シナリオ: 過去24時間でアクセス数が多かった上位10件のIPアドレスを調べる。
  • CloudWatch Logs Insights クエリ例: 
    fields @message
| parse @message "* - -" as clientIp, rest
| filter tomillis(@timestamp) > 1715673900000
| stats count(*) as request_count by clientIp
| sort request_count desc
| limit 10


    IP アドレスごとのアクセス数を集計しランキング表示できる高度な分析能力を確認できました！複雑な集計も Insights クエリで実現可能です！

検証項目3: 高度な分析（フィルタリング – 400番台エラー）

  • シナリオ: 400番台のエラーが発生したアクセスログを確認する。
  • CloudWatch Logs Insights クエリ例: 
    fields @message
| parse @message '* - - [*] "* * *" * * "*" "*"' as clientIp, logTimestamp, method, path, protocol, httpStatus, bytesSent, referrer, userAgent
| filter tomillis(@timestamp) > 1715678700000  
| filter httpStatus like /^4\d{2}/ 
| limit 10



    特定の条件（400番台エラー）に合致するログだけを迅速に抽出できることを確認できました！リアルタイムに近いログ分析が可能です！

CloudWatch Logs Insights と S3 + Athena 構成の比較

ここまで CloudWatch Logs Insights の基本的な使い方と実践的なクエリを見てきました。ここで改めて S3 + Athena 構成との比較をしてみましょう。

比較ポイント CloudWatch Logs Insights S3 + Athena
設定の容易さ ◎ 非常に容易。ログ収集設定があれば即座に利用開始可能。 △ Firehose, Glue Crawler 等の設定が必要。
クエリ言語 ◯ 専用クエリ言語。SQLライクだが学習が必要。 ◎ 標準SQL。多くのエンジニアに馴染み深い。
リアルタイム性 ◎ 高い。数秒〜数分遅れで分析可能。 ◯ Firehoseのバッファ設定による。数分〜十数分。
コスト ◯ スキャンデータ量で課金。ログ保存料はCloudWatch Logs依存。 △ S3保存料, Firehose転送料, Glueクローラ料, Athenaスキャン料が発生。長期保存はS3が安価。
分析機能の柔軟性 ◯ 基本的な集計・フィルタリングは強力。複雑なJOINは不可。 ◎ 高度なJOINやウィンドウ関数も利用可能。
他サービスとの連携 ◯ CloudWatch Dashboardへグラフ追加が容易。 ◎ QuickSight等BIツールとの連携、他データソースとの連携が容易。
長期保存とデータ整理 △ ロググループ保持期間設定。S3ほど柔軟ではない。 ◎ S3ライフサイクルポリシー、Glacier連携、パーティションによる効率化。

両者のメリットデメリットを理解することが大切です！

どちらの選択肢を選ぶべきか？選定のポイント

CloudWatch Logs Insights と S3 + Athena 構成のどちらを選択すべきかは以下のポイントを考慮して判断しましょう。

  • 分析の主な目的:
    • 障害調査やアラート対応などリアルタイム性の高い運用監視が主なら CloudWatch Logs Insights。
    • 定期的なレポーティングや詳細な傾向分析、他データとの組み合わせ分析が主なら S3 + Athena。
  • ログの量と保持期間:
    • 比較的小規模で短期的な分析が中心なら CloudWatch Logs Insights。
    • 大規模なログデータで数年単位の長期保存と分析が必要なら S3 + Athena。
  • チームのスキルセット:
    • SQL の経験者が少ない、あるいは迅速に分析を開始したい場合は CloudWatch Logs Insights。
    • SQL に習熟したメンバーが多く、高度な分析を行いたい場合は S3 + Athena。
  • コスト許容度:
    • 設定や維持のシンプルさを重視し、スキャン量に応じたコストで問題なければ CloudWatch Logs Insights。
    • ストレージコストを最適化し、より細かくコスト管理を行いたい場合は S3 + Athena。
  • 既存のAWS環境:
    • 既に CloudWatch Logs へ多くのログを集約している場合は CloudWatch Logs Insights を試すハードルが低い。
    • データレイクとして S3 を活用している場合は Athena との親和性が高い。

プロジェクトの要件に合わせて最適なツールを選ぶことが重要です！

まとめ

今回の検証を通して CloudWatch Logs Insights が Apache ログ分析において非常に手軽かつ強力な選択肢であることが確認できました。特に設定の容易さとリアルタイム性の高さは大きなメリットです。
一方で S3 + Athena 構成はより複雑な分析や長期的なデータ活用、コスト最適化の面で優位性があります。
ログ分析基盤の選択は日々の運用効率を大きく左右します！それぞれのツールの特性を理解し、ご自身の環境や目的に最適なものを選定してください。
この記事が皆さんのログ分析改善の一助となれば幸いです！

参考ドキュメント

CloudWatch Logs Insights
https://docs.aws.amazon.com/ja\_jp/AmazonCloudWatch/latest/logs/AnalyzingLogData.html

CloudWatch Logs Insights クエリ構文
https://docs.aws.amazon.com/ja\_jp/AmazonCloudWatch/latest/logs/CWL\_QuerySyntax.html

Amazon S3
https://docs.aws.amazon.com/ja\_jp/AmazonS3/latest/userguide/Welcome.html

Amazon Athena
https://docs.aws.amazon.com/ja\_jp/athena/latest/ug/what-is.html

AWS Glue
https://docs.aws.amazon.com/ja\_jp/glue/latest/dg/what-is-glue.html

Amazon Data Firehose
https://docs.aws.amazon.com/ja\_jp/firehose/latest/dev/what-is-this-service.html