Amazon Athena RegexSerDe を利用して CLB ログ / Apache Web のアクセスログを探索する

本日は、Amazon Athena RegexSerDe を利用して CLB / ELB v1 (Classic Load Balancer / Elastic Load Balancing Version 1)のログを探索する方法を紹介します。CLBのファイルフォーマットは Apache Web の アクセスログ と同じ形式なので、ウェブのアクセスログも　CLB　と同様に Amazon Athena で探索することが可能です。

CLB / ELB v1 とは

CLB は、アクセスログを使用して、ロードバランサーに対して行われたリクエストの詳細情報をキャプチャし、Amazon S3 でログファイルとして保存できます。これらのアクセスログを使用して、トラフィックパターンの分析や、ターゲットの問題のトラブルシューティングを行うことができます。

2016年8月にALB（Application Load Balancer）がリリースされるまで、ELBは、CLB（Classic Load Balancer）を意味していました。現在は、ELB のVersion１ が CLB（Classic Load Balancer）、ELB のVersion２ が ALB（Application Load Balancer）をそれぞれ意味します。

CLB は、ウェブブラウザをはじめとするクライアントのトラフィックを複数のアベイラビリティーゾーンの複数の EC2 インスタンス間で分散し、クライアントにとって単一の通信先として機能します。クライアントからのアクセスログは、CLB に対するリクエストの詳細情報をキャプチャし、それをログファイルとして、指定した Amazon S3 バケットに保存します。なお、CLB のアクセスログを有効にするには、アクセスログの有効化 (Classic Load Balancer) を御覧ください。

以降、このアクセスログファイルに対して、Amazon Athena のテーブル定義とログの探索をご紹介します。

CLBのアクセスログ

各ログエントリには、ロードバランサーに対する 1 件のリクエストの詳細が含まれます。ログエントリのすべてのフィールドはスペースで区切られています。ログファイルの各エントリは次の形式になります。

timestamp elb_name client_addrport backend_addrport request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protoc

様々なアクセスログエントリを確認したいので、CLBのマニュアルアクセスログのエントリの例から引用しました。

2015-05-13T23:38:43.945958Z my-loadbalancer 192.168.131.39:2817 - 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:81/ HTTP/1.1" "curl/7.38.0" - -
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001069 0.000028 0.000041 - - 82 305 "- - - " "-" - -
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001065 0.000015 0.000023 - - 57 502 "- - - " "-" ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2

テーブル定義

上記のログファイルのフィールドを、以下の様にテーブルのカラムにマッピングしています。CLB がバックエンドのEC2インスタンスと通信できない場合もクエリできるように、IP と PORT のカラムを別にマッピングしています。

では、これらを順にカラムとして定義します。Amazon Athena は、ログが複数のファイルの場合でも、同じフォルダに配置することで同じテーブル内のデータとしてクエリーを実行できます。

CREATE EXTERNAL TABLE IF NOT EXISTS clb_logs (
request_timestamp string,
elb_name string,
client_addrport string,
client_ip string,
client_port int,
backend_addrport string,
backend_ip string,
backend_port int,
request_processing_time decimal(8,6),
backend_processing_time decimal(8,6),
response_processing_time decimal(8,6),
elb_status_code string,
backend_status_code string,
received_bytes int,
sent_bytes int,
request string,
user_agent string,
ssl_cipher string,
ssl_protocol string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1',
'input.regex' = '([^ ]*) ([^ ]*) (([0-9.]*):([0-9]*)|-) (([0-9.]*):([0-9]*)|-) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) (\\"[^\\"]*\\") (\\"[^\\"]*\\") ([^ ]*) ([^ ]*)[ ]*$'
)
LOCATION 's3://devio2017-handson/07-clblogs/2015/05/13/'
TBLPROPERTIES ('has_encrypted_data'='false');

上記のDDLをテンプレートとして利用する場合、LOCATION に指定するクエリ対象のロフファイルを保存している S3バケット/フォルダ名を変更するだけで、再利用できます。

全てのレコードの全てのカラムデータが参照できることが確認できます。

CLB ログを探索

別のデータにて、CLB ログを探索する例をご紹介します。

CLB毎のリクエスト数

CLBをデプロイすると複数のCLBインスタンスが起動されます。CLBのインスタンス毎に処理しているリクエスト数を参照することができます。

ELB毎のレスポンスコードの出現数

ウェブアプリケーションを運用していると、ウェブサーバーのレスポンスコードが何かによって、障害原因がサーバーとクライアントのどちらであるかを切り分けしたり、更にその出現頻度を把握することができます。下記の例では、レスポンスコードが500番以上、つまりサーバーのエラーレスポンスをCLB毎に集計しています。

リクエスト数をIPアドレス毎に表示

単位時間あたりの IP アドレス毎のリクエスト数の Top10 を表示します。特定のIPアドレスからリクエストが集中的に発生している場合はDoS攻撃の可能性があります。サービス継続に支障をきたす場合は、Network ACL で IP アドレスをブロックするなどの対策が可能になります。

CLB のログを簡単に「速く」「安く」探索するには

ログファイルの検索範囲を限定する

CLBのログは、デフォルトで年月日の階層的なフォルダ構成になっていますので、簡単に期間を限定できます。 例えば、

• 2017年1月1日の場合： s3://<logbacket and folder>/2017/01/01/
• 2017年1月の場合： s3://<logbacket and folder>/2017/01/
• 2017年の場合： s3://<logbacket and folder>/2017/

探索範囲のスコープが明らかな場合は、利用費の削減や応答時間の短縮の観点から探索するログの期間を限定することをおすすめします。

パーティション設定する

CLBのログのフォルダ名や階層は決まっているので、「カラム名なしパーティション」として、パーティションを設定します。上記のテーブル定義に PARTITIONED BY (year int, month int, day int) を追加して、テーブルを再作成した後、ログの検索範囲のパーティションを追加します。恒久的にテーブルを定義して、常ににログを監視したい場合は、パーテイション設定することもご検討ください。パーティションの設定は Scenario 2: Data is not partitioned を御覧ください。

その他

読み込むファイルサイズを小さくするためデータの圧縮がベターですが、CLBのログファイルが既にgzip圧縮済みですのでそのままで構いません。その他、ファイルサイズの最適化やカラムナフォーマットへの変換については、必要に応じて検討してください。

最後に

今回の内容は、Developers.IO 2017 ハンズオンセミナー でご紹介した内容の一部です。Grepのような文字列検索のみならず、カラム間の状態による抽出や集計ができるのは、Amazon Athenaならではの特長です。CLB は "Classic" と言われてもまだまだ現役で使われていることが多いので覚えておいて損はありません。

関連ブログ： Amazon Athena RegexSerDe を利用して ALB ログを探索する