この記事は、Qiita様主催の、AWS Advent Calendar 2021の9日目として投稿させて頂きました。
AWS Athena というサービスをご存じでしょうか。
簡単に言えば、S3 にアップロードした CSV ファイルに対し、SQL を叩くような感覚でデータ抽出や分析ができるという代物です。
詳しくは適当にググってみてください。
ログ解析を目的に使用されている方もいるようで、実際にその目的でプロジェクトに導入してみました。
しかし、かなりしんどいうえ、全く幸せになれず、最終的には Athena を使用したログ解析をしない方向に決めました。
アクセスログの解析のように、単純に集計したい場合には有効かもしれませんが、時系列が重要なログファイル解析には向きません。
以下、Athena を使っててツライと感じた点です。
一部は、一概に Athena が悪いという内容では無いのですが、導入するうえでは避けられない設定および修正なので、一連の流れとして同列に扱う事にしました。
環境としては、バックエンドは Laravel を使用し、ECS でデプロイしています。
辛い点１：Athena に出力するまでの道のりが遠い
Athena を使用する場合、以下のようにデータを流す必要があります。
標準出力（ECSからの標準出力） → Kinesis → S3
何だかシンプルな構成っぽく見えてしまうが、設定は結構に複雑でややこしい。
まず、標準出力の部分は ECSから Kinesis に流れる所は、FireLens という ECS に内包されたサービス（ログルーター）が必要となり、これを使うと自動でコンテナが追加される。
ここまではいいとして、「Kinesis → S3」の流れは結構難解。
実は直接繋げる事ができないため、AWS Glue というサービスを間に挟む必要があり、色々とややこしい設定が必要となる。
公式サイトによると、「AWS Glueは、分析、機械学習、アプリケーション開発のためのデータの検出、準備、結合を簡単に行える、サーバーレスデータ統合サービスです。 」という事らしいが、ログを出力するためにこんな大げさな仕組みが必要なのかは疑問だ。
また、コンテナからのログ出力設定には firehose という Kinesis のサブサービスみたいなものを触る必要があり、「ログ吐きたいだけなのに、何でこんなにいっぱいサービス触る必要が？」と、妙に苦労を抱えてしまう。
そんな感じでややこしい設定がいくつか必要になると、ミスする部分が出てくるんだけど、どこでミスったのかの判断が極めて難しくなる事が多い。
結構な数のトライアンドエラーを繰り返す必要がある割には、成果は労力に見合わなかったりする。（詳細は後述）
辛い点２：データ抽出設定が面倒
Athena で S3 からデータを抽出する場合、テーブルのスキーマを構築するような作業が必要になるが、これが結構面倒くさい。
S3 に掘り込んだファイルを、ある程度絞り込みできるために定義を整える作業はやっぱり必要で、「雑に S3 にブチ込んだログファイルを、いい感じに抽出できるようにしてみよう」といった考えで進めていると、抽出どころか定義の段階で頭を悩ませる場面が出てくる。
何かいい感じに色々なカラムが標準で使えそうだけど、コンテナイメージIDだのECSクラスターIDだの、よく考えたらログを出力するうえではどうでもいい内容ばかりで、結局は自前で S3 に出力するログフォーマットの定義を整える必要がある。
結局、ロクなキー情報を持たず、出力した内容を like 検索するような定義にしてしまうも、１度定義すると修正が結構面倒なうえ、融通も利きづらい。
独自タグを使いたい場合、Firehouse でデータ変換が必要となったりと、もう何かと面倒な設定が多い。
辛い点３：意図通りにデータを抽出するのが難しい
SQL の select 文を叩くような感覚でデータを抽出するが、調査に使うには難しかったりする。
例えば、こんな点。
order by 句を使用した時、指定した句以外の内容は順番が保証されない
order by を使って並べ替えができるものの、それ以外の項目は元々の順番が保証されない。
なので、実行するたびに内容が変わったりする。
例えば、「LIMIT 50」と打っても、最新の 50件が取れているとは限らず、全ては Athena の気分次第、と開発者の頭を悩ませる挙動をする。（この現象の特定に、非常に時間がかかった）
この現象は、検索対象ファイルが複数にわたる場合、より顕著に表れる。
また、Athena はクエリを実行するたびに課金が発生し、その金額は抽出されたレコード量に比例するという何だか冗談みたいな課金体制のため、LIMIT 句を使って表示するレコード数の上限を設定する事は、ほぼ必須になると言ってもいい。
その必須ともいえる LIMIT 句においての挙動が何とも微妙なので、使う側は妙なバッドノウハウを蓄積させていく必要がある。
ちなみに、AWS に詳しい方に聞いてみたところ、とある案件にて Athena をバッチ処理でブン回す処理を入れていた所、抽出条件が荒かったため、気が付けばウン百万の課金が発生するという被害があったらしいです。
（ユーザが注意しなければならないとかそういう次元でなく、簡単にクラウド破産を誘発してしまうサービスの構造に問題があると思う。）
前後時系列で見れない
エラーの原因となったログを探し当てたとしても、その前後の情報を見る事ができない。
SQL文の構造を考えると、当たり前っちゃあ当たり前なんだけど、どうにかならないのだろうか・・。
エラーなんて、その行さえ特定できればOK、というわけではなく、その前後でどんな風に処理が実行されているかという事が重要になってくる事も非常に多いが、そういった状況に全く対応できないというのは、ログ解析としてはNG越えて致命傷だと思う。
辛い点４：コンソールの使い勝手が悪い
基本、AWS のコンソールを使ってクエリを叩く事になるのですが、結構使いづらい。
世には無数の SQLクライアントソフトがあり、お好みのツールを使われているかと思いますが、使い勝手はそれらに遠く及びません。
作成したSQL文をスニペットとして登録する事が出来るものの、何と編集ができず、できるのは登録と削除のみ。
登録した SQL文を編集するには、削除して、もう一度登録という冗談みたいな操作を強いられる。
SQL文のインポートやエクスポートもできないため、「開発環境で作成したものを、本番環境にも持っていく」といった作業ができず、わざわざ環境ごとに作っていく必要がり、非常に面倒くさい。
ただ、これは 2021年時点で感じている事なので、もしかしたらそのうち改善されてくれるかもしれない。
（個人的には、今後、積極的に使う事は無いけど）
余談ですが、プロジェクト終盤に Athena のコンソールがガラッと変わって非常に戸惑いました。
そして、新しいコンソールにて、過去に登録したSQLを実行すると、なぜかエラーが発生するという怪現象が発生したため、すぐにクラシックコンソールに戻しました。
ちゃんと原因を調査するなり AWSに問い合わせるなりでもやってみた方が良かったんだろうけど、既に Athena を使う事に対して精神の摩耗が凄まじかったので、とりあえず楽な方向に逃げる事にしました。
辛い点５：標準出力への制御が大変なケースがある
Laravel にて、ログを標準出力に出力するには、アプリケーション側にてログ出力設定を変更する必要がある。
単純な機能を使う分には特に苦労をせずに実現できるのだが、スケジューラからジョブを実行する処理がメインとなるアプリケーションの場合、地獄のような辛みが発生する。
具体的には、スケジューラからジョブを実行する場合、「標準出力」の対象は、「ジョブをコールしたスケジューラ」となるようで、通常のやり方では上手く行かない。
そのため、「ログファイルへの出力を標準出力へリダイレクトする」というトリッキーな方法を使う事になる。
当然、アプリケーションのみでは解決できないため、dockerコンテナイメージを作り変えたりする必要がある。
また、その方法を使っても onSuccess や onFailure にて設定したメッセージが上手く出力できなかったりと、なかなかに闇が深い調査を強いられる。
その時の記録がこちら。
【Laravel】Schedule から command を実行する時、標準出力の内容を出力させる（未達成）
かなり時間かけて調べましたが、結局、未解決のままです。
その後、Athena を使っても幸せになる未来が見えなくなったので、必要な場面が出てくるまで凍結。
結論
時系列が重要なログファイルの解析に、Athena は不向き。
使い方次第では出来るかもしれませんが、少なくとも自分には Athena を使って幸せになれる未来を描くことができませんでした。
ちなみに、完全に廃止するまでは、S3に出力されたファイルをダウンロードするというギャグみたいな運用をしていました。
コメント