[レポート] AWS User Group Meetup in Berlin (2019.08.14.) 〜 Athena で生データを扱う

Guten Tag、ベルリンより伊藤です。

昨日、Berlin の AWS User Group Meetup に参加してきましたのでブログを書きます。

AWS からの連絡

イベント情報

2019年9月9日(月)にハンブルグで AWS Community Day があります！

新着情報

• 新しい AWS 中東 (バーレーン) リージョンを発表
  • Dev.IOの発表ブログ
• AWS Lake Formation が一般公開されました。 (データレイクを自動処理にて簡単に作成できるサービス）
  • Dev.IOの試してみたブログ
• GitHubでCloudFormation Public Coverage Roadmap をリリース (CFnのサポート対応範囲のロードマップ)
• Amazon EC2 フリートでオンデマンドのターゲット容量の変更が可能に
• AWS Step Functions がネストされたワークフローのサポートを追加
• Amazon ECS サービスで複数のロードバランサーターゲットグループのサポートを開始

トークセッション: SQL on raw data - Michael Muck (Saxonia Systems)

前半・後半で2つのセッションがありましたが、今回は私用につき前半のみしか参加できませんでした。

now Michael Muck (https://t.co/0SfzW7aFro) from @SaxoniaSystems talks about "SQL - on raw data?!" with Amazon Athena.#AWS #UserGroup #Meetup #Berlinhttps://t.co/iVVUWEjJ1p pic.twitter.com/HZ9lsVWJy2

— Andreas Grimm (@_andreasgrimm) August 13, 2019

Athena とは

• インタラクティブなクエリサービス
• 標準SQLを使用（Presto SQL エンジン、テーブル操作にはApache Hive DDL）
• S3へ直接データ分析（ログファイル、監査ログ、JSON/CSV/Parquet/ORC）
• サーバーレス
• データ読み込みやETLは不要（※）

※ETLは不要だが、実行結果を別のバケットに入れることでETLすることは可能

利用例として、ドイツではBetriebsratにより社員が行う操作を常に追跡・監視してはいけないと定められているため、常に統計や分析を取ることはできないが、保管した監査ログを緊急時に分析するというようなケースを説明していました。

他にも JSON フォーマットでS3バケットに溜め込んでるデータがある場合に、長期的に分析を行うならRedshiftなどテーブル設計から構築することも考えられるけど、短期的に情報が必要な場合に活用できるとのことです。

使い方

対象ファイルには、例えば、ELBアクセスログ、2570ファイル、1TB

• テーブル作成
  • CREATE TABLE（※ AthenaではデータはS3を読み込み、テーブル削除時も元データは残るため、CREATE TABLEテーブルは常にEXTERNAL）
  • SERDEPROPERTIESでデータ構造を指定する（詳細はCREATE TABLEドキュメント）
  • LOCATIONでバケットの場所(パス)を指定
• クエリ実行
  • 30分実行したけどタイムアウトしてしまう可能性もあるので、LIMIT推奨。
  • 15秒〜數十分、サーバーレスでマネージドサービスのため、パフォーマンスの詳細は公開されていない
  • 別タブで同時にクエリ実行が可能

料金

• Athena はスキャンしたデータ量に対してのみ課金
  • スキャンされたデータに基づいて課金されるため、DDLクエリやコンピューティングにはお金が発生しない
  • そのため、タイムアウトしてしまっても課金なし
  • JOINも実行可能だが、すべてのスキャンデータが課金対象となるのでお金がかかる
• 加えて、通常の S3 のストレージ、リクエスト、データ転送料金
  • スキャン対象のS3データの保存方法によって変わる（IAだとアクセスによりお金がかかる等）

詳しくはAthenaの料金ページから。

最適化

• パーティションでスキャン対象のデータを減らす
  • CREATE TABLE 時に PARTITIONED BY で S3 prefix を使ってパーティションを設定（日付など）
  • または、ALTER TABLE ADD PARTITION でパーティションの追加
  • ただしパーティション指定はLambda関数などを使用して自動でやるべし（参考Dev.IOブログ）
  • 参考: Dev.IOのパーティションに関するブログ
• GZIPでデータを圧縮する
  • デモではSELECTにかかる時間はほとんど同じで、2.9GB→397MBに減少
• Apache Parquet のカラムナーフォーマットを使用する
  • デモではさらに小さい18.44MBに
  • STORED AS PARQUET を指定するだけで、SERDEの指定は不要
  • S3 が year=2015/month=1/day=1 のようにHive形式パスだと、MSCK REPAIR TABLE を実行するだけで自動的にパーティション検出してくれる
  • 参考: Dev.IOの試してみたブログによれば、実行時間はCSVの方が速いケースが多いようだが、スキャンデータは削減され利用費に優しいよう

※なお、SELECTで行を1つ指定したからといってスキャンされるデータが減るわけではない。

メリット・デメリット

• Pros
  • データレイクのインサイト
  • 即座のクエリ実行
• Cons
  • S3バージョニングがサポートされていない
  • 既にDWHがある
  • 結果キャッシュなし、2回実行したらそのまま2回分課金される
  • 暗号化していたら同じリージョンのみ
  • ZIPやパーティショニングしていないと、稀にS3のGET制限にかかる可能性がある
  • バケット内のプレフィックスごとに1秒あたり5,500 GET/HEADのリクエスト（上限緩和不可）
  • 発生はごく稀ではあるけれど、現時点ではメッセージなども出ないため結果データが不足していることに気づけない可能性がある...

最適なクエリ実行ができるよう、あらかじめデータ整備はしてS3に保存しておいた方が良い。例えば、DDoS攻撃が発生した時に急ぎで調査する必要があるケースなどを想定して。一方、定期的にクエリ発行や既存でやりたいクエリがあるケースでは、RDSやRedshiftなど通常のDWHを使うことを推奨とのこと。

終わりに

後半のセッションは Elmar Weber 氏による "Using Infrastructure to Drive Culture - How Amboss enabled autonomous teams with the right technology and DevOps" でした。ご紹介だけ。

now Elmar Weber (@weberelm) from https://t.co/U84TvXopZh talks about "Using Infrastructure to Drive Culture - How Amboss enabled autonomous teams with the right technology and DevOps”#AWS #UserGroup #Meetup #Berlinhttps://t.co/iVVUWEjJ1p pic.twitter.com/x6DZWe5eKH

— Andreas Grimm (@_andreasgrimm) August 13, 2019

Berlin AWS User Group Meetup、毎月開催しています。参加は無料です。

今回は Saxonia Systems AG のホストにより、 Hauptbahnhof の近く、川沿いの素敵なオフィスでした。

余談ですが、その Saxonia Systems さんのWebサイトドメインが普通に会社名とかではなく "So geht Software" (ドイツ語で「ソフトウェアとはこうだ」) というのがシャレててちょっと素敵です。

次回は9月17日(火)の予定です！