この記事は any Product Team Advent Calendar 22日目の記事です。
こんにちは！anyのエンジニアの波多野（@hatamasa1988）です。
アドベントカレンダーもあと少しですね。
今日は自社プロダクトでは避けられないであろう手動ログ出力の運用自動化についての取り組みをご紹介します。
まだ弊社でも撲滅までは道半ばですが、当初の大部分が自動化でき、大幅にコスト削減できました。
苦労しているチームも多いかと思いますので少しでも弊社の取り組みが参考になればと思います。
エンジニアで手動出力していた数多なログ達・・・
プロダクトの運用フェーズでエンジニアが手動で出力するログ、みなさんどうしていますか？
Qastもプロダクト自体の進化や顧客導入が進み、エンジニアで定期出力するログが増え続けていました。
内容は様々ですが、お客様が運用で参考にするデータであったり、内部向けにプロダクトの分析データ（NSMなどはかなり重要なプロダクトの利用指標！）を出力していました。
下記のようなログを定期作業で、しかも手動対応でエンジニアが出来合いのスクリプトを手動で実行し、担当者に渡すためにslackに共有したり、Dropboxに配置したりとかなりの工数が必要になっている状況でした。
- NSMログ
- 月次/週次ログ
- 個社対応ログ
おおよそは上記のようなログが複数個ある状況ですが、月次ログに至っては集計負荷がえげつなく、半日ローカルPCの負荷を高め続け、担当者は他の作業がままならないようなログ出力作業を行っていました。
運用負荷軽減に乗り出す
上記のような状況のため、エンジニアのリソースがかなりかかっていました。このようなログは経験上減るようなものではなく、システムの運用とともに増え続けるものと認識しているため、自分が担当を引き継ぐタイミングで全てのログの内容を見直し、運用負荷軽減へと動きました。
結論：現在のログ出力対応
手動出力していた全8つのログを、現在は2つまで削減することができています！
特にリソースがかかっていた月次顧客利用ログに至ってはリファクタとコンテナ化を行い、4時間→3分以内 と実行時間を大幅に削減。
その他NSMログや月次/週次のログはAWS Batchに実行を移行しました。
また、運用や保守で定期的に必要になるログはRedashを新規に構築し、担当者が欲しいタイミングで出力できるようにしました。
取り組みを一部紹介
取り組みを2つピックアップして紹介しようと思います。
（AWS Batchの話は今回は割愛させていただきます🙇）
ログとスクリプトの解釈し対策を検討
ログの内容が分からなければ手段を講じることができません。全てのログ出力対応をNotionにリストアップしまとめます。
下記のようなテーブルにまとめて全貌を把握します。そこから大部分が自動実行できることが見えてきました。
現状のNotionで申し訳ないですが、当初はもっとありました🙇
また、全てのログ出力がスクリプト化されていたので、一旦全てのスクリプトのコードを読みます。
スマートなやり方ではなく残念な気持ちになられた読者もいるかもしれませんが、これがどのようなタイミングでも一番効果的だと信じています笑
Redashを構築しログ出力を移行
Redashは広く知られてはいますが、念の為簡単に説明しておきます。
下記ChatGPTより
ビジネスインテリジェンス（BI）およびデータ可視化ツールであり、技術者だけでなく、非技術者も含めた全社的なデータ活用を支援するために設計されています。
Redashの主な目的は、データベースやデータウェアハウス、APIからデータを簡単に取得し、そのデータを分析して、グラフやダッシュボードに可視化することです。
今回下記の選定理由でRedashに決定して進めることにしました
- オープンソースで開発も盛んに行われている
- 各社導入していてナレッジも広く展開されている
- Pythonを実行できる（現状ほぼ全てのスクリプトがPythonで作られていた
Redashの利用目的
今回使用するRedashではMySQLへのクエリ発行やPythonスクリプト実行でのデータ取得を行います。
設定されたクエリをビジネス側の担当者が欲しいタイミングで実行させるだけで、いつでも気軽にcsvをダウンロードすることができて、エンジニアとのコミュニケーションや作業時間のオーバーヘッドに伴う双方のコストをなくすこと、かつ今後の組織拡大を視野に入れてスケール可能な仕組み構築を目的としました。
アーキテクチャ
アーキテクチャは下記をTerafformで構築しています
- Redash Server/worker→ECS
- Postgres→RDS
- Redis→Elasticache
アーキテクチャを考える上でこちらの記事を参考にさせてもらいました！
Redash(getredash/redash)は公式に従って簡易的に立ち上げると、一台のEC内部にPostgresやRedisを内包する形になります。
始めはそのデフォルトのアーキテクチャで検証を行ったのですが、パフォーマンスが悪く、大きめのインスタンスを使用する可能性と、今後のスクリプトや利用量に応じたスケール面に不安がありました。
そのため上記の記事でも紹介されているように、それぞれAWSに応じたアーキテクチャとすることにしました。
スクリプトを移行
Redashにスクリプトを移行します。
結論8つあるスクリプトのうち6つを移行することができましたが、今回は実際どれくらいRedashが使われるか、追加でスクリプトの開発が入るかなど運用が読めなかったため、コストをあまりかけずに、ありもののスクリプトをそのまま移行しました。
SQLを実行するだけのスクリプトはすぐに移行できましたが、Athenaから取得するPythonスクリプトが苦戦します。。。
RedashにはAthenaをデータソースとして取得することができるのですが、その設定がうまくできず。
結果PythonデータソースからAthenaを実行するイマイチな手段になってしまったのが心残りです。
Pythonデータソースのクセをハック（非推奨）
RedashでPythonを実行するにはいくつかクセがありました。そのハックを一部紹介します。
関数内でimportしたライブラリが使用できません☠️
mysql.connectorはなぜか使用できません😇
関数からクラス内部で定義している関数を呼び出せない🤮
Pythonデータソースでデータ複雑な処理を実行するのはオススメしません。
今後の展望
推測ですが、BIツールの特性上データソースやAPIから取得したデータを可視化することが責務になるので、上記でハックしたような処理が不要でも実現できるように最小限で設計されているのかもしません。
本来ならばSQLを記載する以外に難しい処理をPythonで書きたい場合は、別途APIサーバーを構築して、そのエンドポイントをRedashから実行。Redashではデータをダウンロードするだけのアーキテクチャを組みたいところです。
月次顧客利用ログをリファクタし大幅にコスト削減
ログ取得で一番のボトルネックはこのスクリプトだったのでリファクタの過程を紹介しようと思います。
試行錯誤しているスレ
簡単に説明すると、Athena, BigQueryから全顧客の行動ログを取得し、データ編集し、csv出力を行うスクリプトです。
その過程でpandasやmultiprocessing.Poolで並列実行してローカルPCのパフォーマンスをぶん回して出力処理を行うスクリプトです。
正確な時間は記録できていませんが、半日ローカルPCを拘束してしまう処理でした。
落とせるデータをビジネス側と調整
プロダクトや顧客データの場合要件を削減するのは難しかったり、ユーザー目線が必要ではありますが、社内向けであれば削減がコスパが一番よければ真っ先にやるのが吉です。
不要な過去データを取得しすぎていたので、それをビジネス側にヒアリングし、取得期間を必要最低限に削減をしました。
毎回全顧客を対象として出力していた個社ログもこのスクリプトでは必要ではないことが判明したため出力の仕方を検討しました。
ロジックのリファクタリング
このスクリプトでは4つのログを出力していて、ロジックでそれぞれのログ出力が密結合していました。
特に個社ログと全顧客ログと性質が異なるログが一括で出力されている部分がボトルネックになっており、まずはこの2つのスクリプトに分解しました。
個社ログのRedash移行
ビジネス側にヒアリングした結果、個社ログは毎月全社分出力する必要はないので、個社ログはRedashに移行しました。Redashにすることにより担当者が欲しいタイミングで取得できるようなったのでログの利便性も向上してビジネス側もエンジニアもみんなハッピーです！
この時点でスクリプトは4時間→10分ほどになりました。
また、何年も前からあるスクリプトのため、当時よりも最適なデータソースがあることが判明しました。
最適なデータソースから取得することにより、処理が簡略化できその分Athenaからデータを取得するオーバーヘッドを減らすことができました。
（弊社のログのデータソースは歴史的経緯もあり複数個に分かれてしまっており、今でも移行対応中です）
最適なデータソースから取得しロジックをリファクタすることで10分→3分ほどになりました。
実行環境をコンテナ化
今までは一人のエンジニアが属人的にログ取得をしてくれていたため問題にならなかったのですが、実行環境をローカル環境に直接構築していたため複数の手順が必要になっていました。
これが他の担当者に引き継ぐ際にうまく環境構築できずに引き継ぎに時間がかかっていたので、
今回、それをコンテナ化し、コンテナでスクリプト実行できるように用意しました。
結果docker composeのコマンドひとつで環境が立ち上がり、即ログ出力することができるようになり、環境構築のオーバーヘッドもなくなり、UXが格段に向上しました。
今後の展望
実は今回ご紹介した月次顧客利用ログについては、ビジネス側より取得対象顧客を設定した上で実行する運用フローもありAWS Batchで自動実行まではできませんでした。
今後は取得対象顧客の設定も含めてシステム化し、ビジネス側で実行できるように構築したいです。
Redash（取得対象顧客の設定）→API（バッチ実行をキック）→非同期バッチ処理→Dropboxに配置
のような感じでしょうか。
最後に
手動出力ログを撲滅する道のりの一部をご紹介しましたが、まだまだエンジニア業務の自動化、効率化は始まったばかりです。エンジニアは顧客以外にも大きな価値を生み出せることが楽しいところかと思います！
最後に月次顧客利用ログのリファクタを終えて、技術の価値を呟いたtimesを紹介して終わりたいと思います。
エンジニアチームの採用が加速していく中で、チームの生産性を最大化するためにも自動化できるものはとことん進めていきたいので、運用面での取り組みにも力を入れていきたい方はぜひカジュアル面談などからよろしくお願いします！
Discussion