Amazon AthenaでCloudFrontログをSQLで解析する #reinvent #athena

ども、大瀧です。

AWS re:Invent 2016で発表された新サービス『Amazon Athena』。発表以後、弊社ブログエントリでも早速検証エントリが上がってきています。

• Athena ｜ 特集カテゴリー ｜ Developers.IO

AthenaはS3にあるデータに対してアドホックにSQLクエリが発行できるので、標準でS3にログを保存するCloudFrontのログデータをAthenaで扱ってみました。

テーブル定義

AthenaにはCatalog Managerというテーブル作成のウィザードが用意されているのですが、カラム定義をGUIで一つずつ選択するためカラム数の多いテーブル定義はしんどいです。今回は管理コンソールのQuery Editorからテーブルを作成するCREATE TABLE文を直接発行し、テーブルを作成しました。構文は以下のドキュメントを参照してください。Prestoの構文に準ずるので、Prestoのリファレンスも参考になるでしょう。

• CREATE TABLE — User Guide

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs_oregon (
  date DATE,
  time STRING,
  xEdgeLocation STRING,
  scBytes INT,
  cIp STRING,
  csMethod STRING,
  csHost STRING,
  csUriStem STRING,
  scStatus INT,
  csReferer STRING,
  csUserAgent STRING,
  csUriQuery STRING,
  csCookie STRING,
  xEdgeResultType STRING,
  xEdgeRequestId STRING,
  xHostHeader STRING,
  csProtocol STRING,
  csBytes INT,
  timeTaken INT,
  xForwardedFor STRING,
  sslProtocol STRING,
  sslCipher STRING,
  xEdgeResponseResultType STRING,
  csProtocolVersion STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '	',
  'field.delim' = '	'
) LOCATION 's3://<バケット名>/<ディレクトリ名>/'

エディタに貼り付け、編集したら[Run Query]でSQLを発行します。

画面右下の[Results]タブに「Query successful.」と表示されればOKです。画面左のテーブル一覧に、作成したテーブルが追加されます。テーブル名に右にある目のアイコンをクリックすると先頭10行を表示するSELECT文が簡単に実行できます。

[Result]に以下のように列がパースされていればOKです。[Run Query]のボタン列の右側に実行時間とスキャンしたデータ量が表示されるのも確認しておきましょう。Athenaの課金はデータ量の従量制なので、コスト感を見るために有用です。

SQLの実行

テーブルが準備できたら、あとは様々なSQLを発行しログデータの検索を楽しみましょう。最近CloudFrontはIPv6をサポートしたので、リモートIPの「cIp」列にIPv6アドレスのデリミタである:でLIKEをかけて抽出する以下のSQLを発行してみました。

SELECT * FROM cloudfront_logs_oregon WHERE cip LIKE '%:%';

[Result]タブを見てみると...

良い感じに取り出せていますね！

まとめ

Athenaの利用例として、CloudFrontのログの検索をご紹介しました。CloudFrontが書き出したログを一切加工することなくいきなりSQLが発行できるのには正直驚きました。CloudFrontのログ解析というと、これまではCloudFrontの管理画面のレポートを簡単に見れる一方で、それ以上のことをするためにはログをまとめてダウンロードしてツールにインポートする手間がありました。ダウンロードやインポートなしで扱えるAthenaの手軽さはやみつきになりそうです。

ただ、同じSELECTでも数秒で終わるものが時間帯によって数百秒かかることがあったり、別リージョンのS3バケットを参照しようとすると400 Request Errorが返ってきたりということがあり、実行時のトラブルパターンをある程度ノウハウとして把握しておくのがいいかなと思いました。また、エラーはメッセージが難解な場合があるので、メッセージの後半で案内されているようにQuery IDを添えてAWSサポートに問い合わせることで解決への助言を得られるかもしれません。