1. Home
  2. Aws
  3. 瞬時に、柔軟に、そして簡単に。Amazon Athena で行うログ分析

瞬時に、柔軟に、そして簡単に。Amazon Athena で行うログ分析

  • 公開日
  • カテゴリ：Aws
  • タグ：Athena
瞬時に、柔軟に、そして簡単に。Amazon Athena で行うログ分析

contents

    1. ログの分析をどのような手段で実施するか
    2. AWS Athena
    3. 使いやすい上に瞬時にログ分析の環境を用意できる。
    4. 前提とデータの用意
    5. データベース作成
  2. テーブル作成
    1. クエリを実行しログデータを取得する
    2. ログデータの分析
      1. エンドポイントの成功率・エラー率
    3. 複数リソースを用いた分析
      1. ログファイル × CSV ファイル
    4. 瞬時に、柔軟に、そして簡単に。

ログの分析をどのような手段で実施するか

ログの多くはテキストファイルであることが多く、DB に格納されていないことがほとんどです。

しかも、ログファイルは大抵、複数の環境から吐き出されたり、量や時間で分割して出力されたりするため、複数のファイルにまたがっていることがほとんど。

そんな環境下でも、ログ分析の環境を簡単に構築し、柔軟に解析していけるのが、Amazon Athena です。

AWS Athena

AWS Athena は、Amazon S3 に保存されたデータを標準的な SQL を使って直接分析できるインタラクティブなクエリサービスです。サーバーの管理や設定は不要で、数秒でクエリを実行し、結果を取得できます。

https://aws.amazon.com/jp/athena/

使いやすい上に瞬時にログ分析の環境を用意できる。

最初に結論からお伝えしておくと、ログ分析に Athena を用いるのはとてもオススメです。

特に調査や障害など、急にスポットでログ分析が発生した時などは瞬時に分析環境を構築できるため、初動が非常に早くなります。

前提とデータの用意

今回は、ログの分析を行ってみます。

以下のフォーマットを持つ、nginx ライクなログを 1000 行、擬似的に作成しました。API のアクセスログを模しています。

192.168.0.247 - - [2024-02-18 14:56:55] "POST /api/v1/tasks/24361 HTTP/1.1" 201 7101 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36"
192.168.0.142 - - [2024-02-18 14:56:56] "GET /api/v1/messages/20050 HTTP/1.1" 200 2942 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
.
.
.

この access.log を、 S3 のバケットに配置してあります。

データベース作成

まずは、Athena でデータベースを作成します。初期は default になっています。データベースを作成せずに default のまま使うこともできます。

エディターにデータベース作成のクエリを入力し、実行ボタンを押下します。

CREATE DATABASE log_analysis;

実行が成功すると、左メニューのデータベースのセレクトボックスから、log_analysis を選択できるようになります。

テーブル作成

作成したデータベース log_analysis にテーブルを作成していきます。

作成テーブルは、最初に用意して S3 に配置したログのテーブルです。

左メニュー「テーブルとビュー」に「作成」というセレクトボックスがあります。そこから、「S3バケットデータ」を選択します。

「S3 バケットデータからテーブルを作成」という画面に遷移します。ここで必要な入力を行い、テーブルを作成します。

テーブルの詳細セクションでは、テーブル名とその説明を入力します。データベース選択セクションでは、先程作成した log_analysis を選択します。

データセットセクションでは、ログファイルが設定されている S3 のバケット、ディレクトリを指定します。

データ形式セクションでは、ファイル（今回でいうとログファイル）のパースに必要な情報を指定します。

今回、ログは正規表現でパースするため、このような指定になっています。

  • テーブルタイプ
    • Apache Hive
  • ファイル形式
    • Apache WebServer ログ
  • SerDe ライブラリ
    • org.apache.hadoop.hive.serde2.RegexSerDe
  • SerDe プロパティ - オプション
    • 名前: input.regex
    • 値: ^(\\S+) - - \\[([^\\[]+)\\] "(\\S+) (\\S+) (\\S+)" (\\S+) (\\S+) "(\\S+)" "(.*)"

列の詳細セクションでは、作成するテーブルのカラムを定義します。

  • ip: string,
  • time: string,
  • method: string,
  • uri: string,
  • protocol: string,
  • status: int,
  • bytes_sent: int,
  • referer: string,
  • user_agent: string

注意点は、データ形式セクションでログのパースを正規表現で記載しましたが、正規表現によってキャプチャ（抽出）する数と、ここで指定するカラムの数は同じである必要があります。

このセクション以降はオプションなので今回は設定しません。最下部にある「テーブルを作成」ボタンを押下すると、テーブルが作成されます。

-- DDL
CREATE EXTERNAL TABLE IF NOT EXISTS `mydatabase`.`nginx_logs` (
  `ip` string, 
  `time` string,
  `method` string,
  `uri` string,
  `protocol` string,
  `status` int,
  `bytes_sent` string,
  `referer` string,
  `user_agent` string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  'input.regex' = '^(\\S+) - - \\[([^\\[]+)\\] "(\\S+) (\\S+) (\\S+)" (\\S+) (\\S+) "(\\S+)" "(.*)"'
)
STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://sample-logs/logs/'
;

クエリを実行しログデータを取得する

テーブルが作成されたので、実際にクエリを実行してログのデータを取得してみます。

SELECT 
*
FROM nginx_logs
;

取得できました。SQL を記述してログのデータが取得できるのはとても利便性が高いですね。

iptimemethoduriprotocolstatusbytes_sentrefereruser_agent
192.168.0.2472024-02-18 14:56:55POST/api/v1/tasks/24361HTTP/1.12017101-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.1422024-02-18 14:56:56GET/api/v1/messages/20050HTTP/1.12002942-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
192.168.0.172024-02-18 14:56:57GET/api/v1/users/29621HTTP/1.14016058-Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.1234.5678 Safari/537.36
192.168.0.2432024-02-18 14:56:58PUT/api/v1/orders/49212HTTP/1.12046035-Mozilla/5.0 (Macintosh; Intel Mac OS X 11_5_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.1762024-02-18 14:56:59POST/api/v1/products/15518HTTP/1.12018669-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.1234.5678 Safari/537.36
192.168.0.1442024-02-18 14:57:00GET/api/v1/users/26990HTTP/1.12009565-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.702024-02-18 14:57:01POST/api/v1/users/30991HTTP/1.12017781-Mozilla/5.0 (Macintosh; Intel Mac OS X 11_5_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.2012024-02-18 14:57:02PUT/api/v1/tasks/7064HTTP/1.12047816-Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.1234.5678 Safari/537.36
192.168.0.1662024-02-18 14:57:03GET/api/v1/users/12541HTTP/1.12006082-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.2332024-02-18 14:57:04DELETE/api/v1/products/1588HTTP/1.12045112-Mozilla/5.0 (Macintosh; Intel Mac OS X 11_5_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.9876.54321 Safari/537.36
192.168.0.472024-02-18 14:57:05PUT/api/v1/orders/8586HTTP/1.12047961-Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36

ログデータの分析

SQL でログデータを分析していけるということで、簡単な分析を行ってみます。

エンドポイントの成功率・エラー率

各エンドポイントの成功率やエラー率を算出してみます。

WITH log_with_endpoint_added AS (
    SELECT 
        method,
        regexp_extract(uri, '^/api/v1/\w+') as endpoint,
        status
    FROM nginx_logs
)
, log_with_call_count_added AS (
    SELECT
        method, 
        endpoint, 
        status,
        status / 100 as status_class,
        COUNT(endpoint) as call_count
    FROM log_with_endpoint_added
    GROUP BY method, endpoint, status
)
, number_results_per_endpoint AS (
    SELECT
        endpoint, 
        method, 
        SUM(call_count) as all_count,
        SUM(CASE WHEN status_class = 2 THEN call_count ELSE 0 END) as succeeded_count,
        SUM(CASE WHEN status_class = 4 THEN call_count ELSE 0 END) as client_error_count,
        SUM(CASE WHEN status_class = 5 THEN call_count ELSE 0 END) as server_error_count
    FROM log_with_call_count_added
    GROUP BY endpoint, method
)
SELECT 
    endpoint,
    method,
    all_count as count,
    CONCAT(CAST(ROUND((CAST(succeeded_count as DOUBLE) / all_count) * 100, 2) as VARCHAR), '%') as succeeded_rate,
    CONCAT(CAST(ROUND((CAST(client_error_count as DOUBLE) / all_count) * 100, 2) as VARCHAR), '%') as client_error_rate,
    CONCAT(CAST(ROUND((CAST(server_error_count as DOUBLE) / all_count) * 100, 2) as VARCHAR), '%') as server_error_rate
FROM number_results_per_endpoint
ORDER BY server_error_rate desc
;
endpointmethodcountsucceeded_rateclient_error_rateserver_error_rate
/api/v1/usersDELETE1573.33%20.00%6.67%
/api/v1/productsDELETE2281.82%13.64%4.55%
/api/v1/tasksGET9684.38%11.46%4.17%
/api/v1/ordersGET8885.23%11.36%3.41%
/api/v1/productsPOST5974.58%22.03%3.39%
/api/v1/usersPOST5983.05%13.56%3.39%
/api/v1/messagesGET9588.42%8.42%3.16%
/api/v1/usersPUT3287.50%9.38%3.13%
/api/v1/productsPUT4080.00%17.50%2.50%
/api/v1/productsGET8879.55%18.18%2.27%
/api/v1/usersGET9178.02%19.78%2.20%
/api/v1/messagesPOST4983.67%14.29%2.04%
/api/v1/tasksPOST5988.14%10.17%1.69%
/api/v1/messagesPUT2982.76%17.24%0.00%
/api/v1/messagesDELETE17100.00%0.00%0.00%
/api/v1/ordersDELETE1894.44%5.56%0.00%
/api/v1/tasksDELETE887.50%12.50%0.00%
/api/v1/tasksPUT3992.31%7.69%0.00%
/api/v1/ordersPUT4082.50%17.50%0.00%
/api/v1/ordersPOST5689.29%10.71%0.00%

SQL でクエリを書けるので、集計などもこうして柔軟に分析を行っていけます。

複数リソースを用いた分析

Athena を使えば、ログファイルを柔軟に分析できることがわかりました。次に、ログファイルだけではなく、別のリソースを掛け合わせて使ってみます。

ログファイル × CSV ファイル

先ほどのログファイルのデータを使って、このアプリケーション API において使われていないエンドポイントを抽出してみます。

新たに、エンドポイントの一覧を収録した CSV ファイルを用意しました。

endpoints.csv

/api/v1/products
/api/v1/orders
/api/v1/users
/api/v1/messages
/api/v1/tasks
/api/v1/bookmarks
/api/v1/friends

表というよりは、エンドポイントの一覧が書き連ねてあるだけの CSV ファイルです。

これを S3 に配置します。

この CSV に対応するテーブルを Athena に作成します。（nginx_logs テーブルを作成したのと同じ要領で、CSV をパースする設定にてテーブルを作成します。）

-- DDL
CREATE EXTERNAL TABLE IF NOT EXISTS `mydatabase`.`endpoints` (`endpoint` string)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES ('field.delim' = ',')
STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://sample-logs/documents/'
TBLPROPERTIES ('classification' = 'csv');

作成した endpoints テーブルを SELECT してみます。

あとは、先程の nginx_logs テーブルのデータにこの endpoints テーブルのデータをぶつければ、使用されていないエンドポイントが抽出できます。

WITH log_with_endpoint_added AS (
    SELECT 
        method,
        regexp_extract(uri, '^/api/v1/\w+') as endpoint,
        status
    FROM nginx_logs
)
, endpoint_used AS (
    SELECT 
        DISTINCT endpoint
    FROM log_with_endpoint_added
)

SELECT 
*
FROM endpoints
WHERE not exists(
    SELECT * FROM endpoint_used WHERE endpoints.endpoint=endpoint_used.endpoint
)
;

こんな風に、様々な形式のデータを取り込み、分析できる柔軟性を Athena は持ち合わせています。

瞬時に、柔軟に、そして簡単に。

AWS Athena は、標準的な SQL を使用してデータにアクセスできるため、SQL のスキルを持つ多くのユーザーにとって親しみやすい環境です。今回は取り上げませんでしたが、notebook の実行も可能なため、SQL の範囲を超えるような分析も行える点も良いです。

また、データのフォーマットに対する柔軟性も高く、JSON、CSV、Parquet、ORC などのさまざまな形式のデータに対応しています。これにより、さまざまなデータソースからのデータを統合して分析することができます。

個人的には、急なログ分析の必要が生じた際に瞬時に分析環境を構築できる点は、非常に心強く、利便性が高いと感じています。

ログなどの分析を行う際は、Amazon Athena を試してみてください。

Author

rito

  • Backend Engineer
  • Tokyo, Japan
  • PHP 5 技術者認定上級試験　認定者
  • 統計検定 3 級