エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

GCS bucketの利用量をSlackに通知する

この記事はエムスリー SRE がお届けするブログリレーの5日目です。

エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと、筋トレで、このところはNBAがてんやわんやしているのを楽しんでいます (Brooklynの今後の状況が特に気になっています)。

今回は、GCSバケットの利用量を監視して、Slackに通知するジョブを作ったので、その背景と、利用した技術の構成について説明します。

f:id:hsasakawa:20210118162714j:plain
ベッドの下で得意げにこっちを見る犬氏 (かわいい)

GCSの利用量を通知する背景

エムスリーのAIチームでは、pipelineフレームワークとして、Luigi をラップし便利機能を追加したOSSである、Gokartを利用しています。

github.com

Gokartでは、処理をTaskという単位に分け、Taskごとに、その処理結果をGCSなどのオブジェクトストレージに出力しています。 こうすることで、リカバリなどの際にワークフローの途中からジョブを再開できたり、debug時の調査などでタスクの出力を確認できるメリットがあります。 一方で、この記事 などで述べられているように、途中結果のデータが嵩張る問題が出てきています。 実際、Gokartキャッシュを多用している大きなプロジェクトでは、1年間の生成ファイルを見積もりと100TBを超え、ストレージコストを計算したくなくなる状態になっていました (もちろん、これとは別にコストのモニタリングなども実施しているため、実際に多大な料金がかかったわけではありません)。 このデータ量は、要不要を検討し整理するには十分な大きさであると考えます。

この問題に対して、単にデータ量を減らすだけであれば、GCSには lifecycle管理機能 があり、データが生成されてからの有効期間などを設定し、自動的に消したり、ストレージクラスを変更するなどして費用を削減できます。 ただし、現状、この機能は、bucket単位でしかルールを設定できず、例えば、「このprefixを持つデータは、ジョブの最終結果なので残しておきたいが、それ以外は中間ファイルなので、一定期間後消したい」のような用途には対応できなかったり、 そもそも、データを消すということは、Gokartの重要な機能の一つである「機械学習の再現性」を保持する、という機能を打ち捨てることと同義なので、AIチームのプロダクトに一律に適用することは難しい状況です。

そこで今回は、不要ファイルの処理の自動化には踏み込まないこととし、単に利用量の閾値を超えているbucketをSlackに通知するbotを開発し、以降の処理をプロジェクトの開発者に任せることにしました。

技術構成

通知ジョブ自体は、弊社で利用しているGitLabのCI runnerである GitLab CI のschedule job機能を利用し、毎朝走らせるようにしました。 他の選択肢としては、Cloud Run、k8sのcron job、AWS Lambdaなどが挙がりそうです。

Bucketの利用量のスキャンと、通知はPythonで実装しました。以下のような80行程度の小さなスクリプトで完結できます。

コマンド化には、ほぼmain関数を書くのみで引数処理などをやってくれる fire を利用 (86行目) しています。

github.com

そして最大のポイントは、monitoring APIを利用してbucketのサイズを取得していることです。 以下のドキュメントに記載されているように、 gsutil du コマンドなどbucketを直接見に行く処理を実行してしまうと、bucket内部のオブジェクト量などによっては、処理にとても時間がかかってしまいます。 今回はこのジョブのみで、AIチーム全てのbucketを監視することを考えていますので、処理時間も短くしたいです。 厳密な時間計測はしていませんし、bucketの状況にもよるのですが、体感できるほど高速であることを確認しています (リアルタイムにスキャンしているgsutil duに対して、予め記録したデータを返しているmonitoringが速いのは当たり前)。

cloud.google.com

個人的には、このAPIを利用したことがなかったので、今回利用してみたという側面もあったのですが、ほぼログを選別するfilter (70-73行目) を書くだけで所望のデータを取得できるのはとても便利でした。

最後にSlack通知については、公式のpython-slack-sdkを利用しています。 特に変わったことはせず、incoming webhookを利用しているのみですが、1つポイントととしてはbucketへのリンクをポスト内容に追加することで、すぐに中身を確認しに行けるようにしています。

github.com

まとめ

今回は、GCS bucketの利用量のモニタリングと、Slack通知を実装した背景と、使った技術構成について説明しました。 実装と動作確認込みで1時間程度で実現でき、削減効果も大きいことから、なかなかROIのいい取り組みだったのではないでしょうか。 是非、ご自身の環境でもお試しください。

We are hiring!

弊社ではSREおよびチーム内SREを募集しています! 我こそは!という方は是非ご応募ください!

open.talentio.com open.talentio.com jobs.m3.com