ELBとCloudFrontのアクセスログをサーバレスに集約させてみた

ELB、CloudFrontがS3に出力するアクセスログ、LambdaとFirehoseを利用してサーバレスな集約管理を実現する仕組みを紹介します。

#AWS Lambda

#Amazon S3

#Amazon CloudFront

#Amazon Kinesis

#Elastic Load Balancing (ELB)

suzuki.ryo

2018.05.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。

ELB(ALB/CLB)とCloudFrontがS3に出力するアクセスログ、その確認、解析を効率よく行うため、Firehoseを利用して集約する機会がありました。

Lambdaを利用したサーバレスなS3への集約の一例として紹介させて頂きます。

構成図

処理説明

1: S3

ELBのログ格納用となるS3バケットです
ELBのアクセスログ登録(PutObject)先として利用するためのバケットポリシーと、S3のレプリケーション先可能にするための、バージョニング設定を実施しています。
今回、既存のELBなどのログ出力設定の変更を回避するため、既存のアクセスログが出力されるS3バケットにレプリケーション設定を追加。レプリケーション先としてこのS3バケットを指定して利用しました。

2: SNS

1回のS3イベントから複数のLambda処理を実施する可能性や、イベント情報をデバッグ用に取得しやすくするため、Amazon SNSを利用しました。
Amazon SNS、Lambdaへの配信課金は、無料で利用する事が可能です。

3: Lambda

Lambda関数のコードは、CloudFormationのテンプレートにインライン記述できる4000文字制限に収まる実装としました。
Lambda処理のタイムアウト時間は最大(300秒)まで延長。割り当てメモリは256MB、初期値の2倍に設定しました。
今回のFirehose投入を行うLambda関数の実装では、1ログファイルあたり30〜40万レコードが処理上限の目安となります。
ELB(ALB)は5分毎にアクセスログをS3に出力する仕様です。1分あたり10万リクエストを超えるELBのアクセスログを処理する必要が有る場合、前処理としてファイル分割処理を行うLambdaの用意や、AWS Glueなどの利用をご検討ください。

Lamba割当メモリ別の所要時間

ELB(ALB)アクセスログ、6万、30万レコードのファイルを用意、 Firehose投入用Lambda関数の割当メモリ別の所要時間(Duration)を測定しました

Memory Size	6万レコード	30万レコード
256 MB	81秒	(タイムアウト)
512 MB	53秒	269秒
3008 MB	45秒	216秒

Lambda処理内容

SNSのメッセージから、処理対象となるS3のバケット、キーを取得します。
ログの時刻情報として期待するカラムのデータが日付フォーマットに一致しない場合や、カラム数が異常なレコードはエラーレコードとして除外します。
「request」カラムに含まれるURLを「urlparse」モジュールを利用してパースし、解析時に利用頻度の高い「HOST」や「PATH」を事前に抽出します。
「json」モジュールを利用してJSONエンコードを行い、Firehoseに対しバッチ転送を行います。

4: Firehose

今回、出力先はS3のみとしましたが、Amazon Elasticserach Service、Redshiftと連係も可能です。
Firehoseのバッファ時間はELB(ALB)のログ出力間隔にあわせ、300秒としました。
Firehoseの後処理をLambda関数で実装する可能性を想定し、ファイルサイズは一定(50MB)で抑止する指定を行いました。

5: S3

Firehoseの出力先として利用します。
Firehoseの出力先を対象としたイベントを設定し、後処理を行うLambda関数をSNS経由で連係させました。

6: SNS

後処理のLambda関数連係に利用します。

7: Lambda

Firehoseで集約、S3に出力されたログファイルの後処理を実装しました。
FirehoseよりS3に出力されたS3ファイルのキーに含まれる日付情報(「yyyy/mm/dd/HH24」)を、Hiveフォーマット(dt=yyyy-mm-dd-HH24/)に置換し、Athena処理用のS3にコピーします。
Hiveフォーマットのキーを付与する事で、Athenaのスキャン対象を特定期間に限定でき、AWS利用費の抑制が可能になります。

Amazon Athenaのパーティションを理解する #reinvent

Athenaの利用

テーブル作成

JSONに変換済のアクセスログは、テーブル定義のみで利用する事が可能です。
Firehoseの出力日時をLambdaで変換した「dt」を、パーティションとして利用する指定を行います。

ALB用

CREATE EXTERNAL TABLE IF NOT EXISTS alb_logs
(
type string,
timestamp string,
elb string,
client_port string,
target_port string,
request_processing_time float,
target_processing_time float,
response_processing_time float,
elb_status_code string,
target_status_code string,
received_bytes float,
sent_bytes float,
request string,
user_agent string,
ssl_cipher string,
ssl_protocol string,
target_group_arn string,
trace_id string,
domain_name string,
chosen_cert_arn string,
matched_rule_priority string,
client string,
target string,
request_method string,
request_uri string,
request_http_version string,
request_uri_scheme string,
request_uri_host string,
request_uri_path string
)
PARTITIONED BY (dt string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<Athena用S3バケット名>/firehose/alb_logs/'
;

CLB用

CREATE EXTERNAL TABLE IF NOT EXISTS clb_logs
(
timestamp string,
elb string,
client string,
client_port string,
backend string,
backend_port string,
request_processing_time float,
backend_processing_time float,
response_processing_time float,
elb_status_code string,
backend_status_code string,
received_bytes float,
sent_bytes float,
request string,
user_agent string,
ssl_cipher string,
ssl_protocol string,
request_method string,
request_uri string,
request_http_version string,
request_uri_scheme string,
request_uri_host string,
request_uri_path string
)
PARTITIONED BY (dt string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<Athena用S3バケット名>/firehose/clb_logs/'
;

CloudFront用

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs
(
timestamp string,
date string,
time string,
x_edge_location string,
sc_bytes float,
c_ip string,
cs_method string,
cs_host string,
cs_uri_stem string,
cs_status string,
cs_referer string,
cs_user_agent string,
cs_uri_query string,
cs_cookie string,
x_edge_result_type string,
x_edge_request_id string,
x_host_header string,
cs_protocol string,
cs_bytes float,
time_taken float,
x_forwarded_for string,
ssl_protocol string,
ssl_cipher string,
x_edge_response_result_type string,
fle_status string,
fle_encrypted_fields string
)
PARTITIONED BY (dt string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<Athena用S3バケット名>/firehose/cloudfront_logs/'
;

パーティション情報更新

テーブル作成直後や新たに追加されたパーティションを解析対象とする場合、「MSCK REPAIR TABLE」を実行します。

MSCK REPAIR TABLE alb_logs

MSCK REPAIR TABLE clb_logs

MSCK REPAIR TABLE cloudfront_logs

解析

Athenaのコンソールなどを利用し、SQLによるアクセスログ解析が可能になります。
「target」「backend」など、カラム名が異なる項目を利用しない解析では、SQLの流用可能です。

エラー応答の抽出

ELBがHTTP応答500番のステータスコードを戻したログを抽出します

SELECT *
FROM alb_logs
WHERE dt< '2018-05-16-15' and dt>='2018-05-14-15'
and elb_status_code like '5%'
order by timestamp
limit 10;

指定した期間の5XX応答が確認できました。

高負荷発生源の疑いのある接続元の抽出

EC2応答時間(target_processing_time)の長い接続元IPアドレス(client)、UserAgentを抽出します

SELECT
sum(target_processing_time) as total_processing_time
, count(1) as request_count
, SUBSTR(timestamp,1,13) as date_time
, client
, user_agent
FROM alb_logs
WHERE dt< '2018-05-16-15' and dt>='2018-05-13-15'
and request_uri_host = 'dev.classmethod.jp'
and user_agent like '%bot%'
GROUP BY user_agent, client, SUBSTR(timestamp,1,13)
order by sum(target_processing_time) desc
limit 10

指定した期間、UserAgentでBotを名乗る接続では、高負荷は発生していなかった事を確認できました。

AWSコスト

1日500万リクエストのELBアクセスログ、AWS東京リージョンのFirehose、Lambdaで利用した場合、1日あたりの費用は0.202USDの計算になりました。
多くの環境でAWSコストを圧迫する事なく利用できる可能性が高いと思われます。

内訳

Firehose

0.108($)
取り込みデータ、1GBあたりの単価は「0.036 USD」で計算
0.108($) = 3(GB) × 0.036($)

Lambda

無料枠は無い前提で計算しました。
0.0193364 ($)
Firehose連係用実行時間
0.0188032($)　= 4520000(ミリ秒) × (0.000000208 / 100):(1ミリ秒価格USD) × 2 (Lambda割当メモリ128→256増強分)
Athenaコピー用実行時間
0.000314($)　= 0.0188($)　= 151000(ミリ秒) × (0.000000208 / 100):(1ミリ秒価格USD)
Firehose連係用リクエスト
0.0001714($) = 857回 × (0.20($) /　 1000000):(1回リクエスト単価)
Firehose連係用リクエスト
0.0000478($) = 239回 × (0.20($) /　 1000000):(1回リクエスト単価)