【レポート】AWS Summit Tokyo 2017:[JapanTaxi] Athena 指向アナリティクス 〜真面目に手を抜き価値を得よ〜 #AWSSummit

2017.05.31

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

aws-summit-tokyo-2017-longlogo 2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『[JapanTaxi] Athena 指向アナリティクス 〜真面目に手を抜き価値を得よ〜』に関する内容をレポートしたいと思います。

(2017/06/16追記:)イベント公式の関連資料及び動画が公開されましたので展開します。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー:
梅田 昌太 様
JapanTaxi Co.,Ltd.
開発部 技術基盤チーム リーダー

セッション概要:
毎月 200 万人のアクティブユーザーをかかえる「全国タクシー」では、Amazon S3 上に保存したアプリケーションログを Amazon Athena で分析し、開発にフル活用しています。S3 をインターフェースとする Athena は手軽に利用でき、他サービスとの連携が容易に行なえます。このセッションでは、Athena のノウハウや実際の利用方法、独自の使い方をご紹介します。

セッションレポート

以下、セッションレポートです。

全国タクシーの紹介

  • 全国タクシー、携帯アプリ
    • タクシー会社が内製
    • 位置情報サービス
    • 移動で人を幸せにする
  • サービス規模
    • 47都道府県
    • 提携タクシー会社=322
    • 提携タクシー台数=3352台
  • その他のサービス
    • パートナー様向けサービス
    • 上部員の方向けアプリ
    • 運行管理
  • サービスの歴史
    • 2011年ローンチ
    • 2016年発のリニューアル(今日のメイン)
    • 深い経緯がありつつ進化
  • インフラの特性
    • ハイブリッドインフラ
    • AWS、Azure、GCP
    • 用途に応じて使い分け
  • JapanTaxi AWS API基本構成
    • Elastic Beanstalk
    • Route 53+ELB+AutoScaling+RDS
    • CloudFront+S3
    • Lambda、SQS、SNS
    • fluentdでログ収集
  • 監視
    • DataDog
    • NewRelic

Athena

  • Athena概要
    • 雑に使えるpresto
    • 課金対象がスキャン量のみ
    • 転送量も気にせず
    • S3がそのままデータソース
    • デートロード不要
    • json,csv,parquet等
    • (parquetは試してはみたけどまだ使っていない)
    • S3資産にそのまま乗れるのが魅力
  • 経験的なEMRとの差
    • マネージドなpresto
    • 前後処理がしたい、ストリーム処理がしたい、ならEMR一択
    • EMRはAthenaではできないことをやる
    • まずはAthenaを検討

ログ運用とAthena

  • 2016年のリニューアル時にログを重視
    • 1人でできることを条件に
    • 早い->道具が揃っている
    • 安い->従量課金
    • 上手い->ハイパフォーマンス
    • 結果、ログはとにかくS3に集約
  • ログ収集
    • OSSのETLツール
    • 安心のEMR
    • リニューアル当時はAthenaが無かった
    • つまりAthenaを意識されたログ収集でなくても問題ない
  • ログ収集方式
    • nginx、rails、.net->fluentd->S3
    • MySQL、MS SQL Server->digdag、embulk->S3
  • データ量
    • 動態情報1.5G/日+app log
    • 5年分
    • 1分とかでだいたいどのクエリも返ってくる

ログ活用

  • UIとして最も手軽な"re:dash"
    • WEBベースのBIツール
    • ブラウザだけで動く
  • Athenaとre:dash
    • 早期からre:dashでサポートされていた
    • IAM発行するだけ
  • ケース1:予約注文の可視化
    • re:dashとAthenaでリアルタイム監視
    • 通常予約と定額枠が別枠だったので統一
  • ケース2:ピークタイム
    • アクセス数とイコールではない
    • digdag -> embulk -> aws cli(athena) -> curl

その他、まとめ

  • 注意事項
    • Location of Input Data Setで例の通りに入力するとエラーになるので注意
  • 今後の期待
    • 東京リージョン
    • UDF
    • output resultをRDBにする等、他の場所に
  • まとめ
    • S3ツールチェーンという巨人の肩に
    • 既存ワークフローの破壊不要
    • SDK、API出た

まとめ

Amazon Athenaの素晴らしい活用事例を詳しくご説明いただきました。とりあえずログをS3に集めてさえおけば、そのログをデータとして活用できる可能性が大きく広がったと思います。資料が公開されれば、更新したいと思います。