Upgrade to Pro — share decks privately, control downloads, hide ads and more …

HerokuでSidekiqを監視する方法を確立した

 HerokuでSidekiqを監視する方法を確立した

2020-02-28 フィードフォース社内技術勉強会のプレゼン資料です。
https://developer.feedforce.jp/entry/2020/03/02/140000

D6c5403c0b6ef2f9fd51910ea38323a3?s=128

Takashi Masuda

February 28, 2020
Tweet

More Decks by Takashi Masuda

Other Decks in Programming

Transcript

  1. HerokuでSidekiqを監視する 方法を確立した
 2020-02-28 @masutaka


  2. 自己紹介
 • 増田貴士(@masutaka)
 • 株式会社フィードフォース
 • EC Boosterの雑用係
 • 最近のマイブームは玄米とビタミンB群とボディクリーム


    • 最近の悩みはドラクエウォークと足底筋膜炎との両立
 https://www.feedforce.jp/ 

  3. ビタミンB群
 • ビタミンB1: 糖質をエネルギーにする
 • ビタミンB2: 脂肪をエネルギーにする
 • ビタミンB6: アミノ酸の代謝に必要


    • ビタミンB12: ヘモグロビンの合成に必要
 • 他、ナイアシン、パントテン酸、葉酸、ビオチン

  4. EC Booster
 国内初のGoogleショッピング広告自動運用ツール
 https://ecbooster.jp/ 


  5. 商品別レポート機能のリリース https://www.feedforce.jp/release/19886/


  6. 商品別レポート機能 広告出稿している商品一覧と詳細情報がわかる機 能。 Google Ads APIをバックグラウンドジョブで呼ぶだけ ではあるが、それだと情報が足りないので、S3 Selectも使って、ジョブ中でJoinしたりしている。 何が言いたいのかというと、時間がかかり得るバック グラウンド処理を含む機能。

  7. EC Boosterの技術スタック
 Heroku App Web Dyno GraphQL Client (apollo-client) GraphQL

    Server (graphql-ruby on Rails) Worker Dyno Chrome (headless mode) chromedriver sidekiq Heroku Postgres Heroku Redis
  8. Sidekiq • Ruby実装のバックグラウンドジョブライブラリ • Webアプリで時間がかかる処理を非同期実行させたり、 定期実行バッチ処理などに使われる https://sidekiq.org/ 


  9. ジョブの遅延とUXの低下 • ジョブが遅延すると、テーブル表示やCSVダウンロード が遅延する • ジョブの遅延がそのままUXの低下に繋がり得る

  10. 監視の必要性 • Sidekiqを監視をしないとジョブの遅延に気づけない • そこまでトラフィックはないのでログを毎日見るという 方法もあるけど...

  11. HerokuでのSidekiq監視の知見が見つか らない。みんなどうしているんだろう?

  12. Slack HerokuJP-UGで聞いてみた https://herokujp-ug.slack.com/archives/C9LRC3M25/p1578381627030100

  13. メトリクス収集 • LibratoのCustom log-based metricsを使えば良さそう • sample#database.size=40.9MB のようなログを出力す るだけで、Libratoが勝手にメトリクスとして記録してく れるスゴい機能

    https://devcenter.heroku.com/articles/librato#custom-log-based-metrics
  14. トリガーはどうしようか? • ApplicationControllerとかにログを仕込む ◦ アクセスがなければメトリクスを収集できないし、多ければ収集しすぎる • Heroku Scheduler ($0/mo) ◦

    最短インターバルが10分なのでダメ • Cron To Go Add-on ($8/mo) ◦ 最短インターバルは1分なのでギリギリ使える。しかし、そのたびにOne-Off Dynoが起動す るのは大げさすぎる • 専用のworker Dynoを起動して、loopでスクリプトを実 行 ($7~25/mo) ◦ 大げさだし、コスト感もダメ • 同じworker Dynoのsidekiq-cronで収集 ◦ 監視対象のキューが詰まっていたら自身が呼ばれない
  15. これは難しい...

  16. 待てよ?以前調べた Ruby Language Metrics収集の 仕組みは使えないだろうか?

  17. 今日のために書きました https://developer.feedforce.jp/entry/2020/02/13/150000


  18. できたーーーー https://github.com/feedforce/heroku-buildpack-sidekiq-metrics

  19. メトリクス収集の仕組み
 Web.1 Dyno(Web.2以降のDynoでは収集しない) /app/bin/sidekiq-metrics (ruby script) /app/.profile.d/ruby-sidekiq-metrics.sh Sidekiq (1) 30秒に1回実行

    (2) メトリク ス 取 得 Worker Dyno (3) 標準出力 Librato (Heroku Add-on) HerokuではLogplexというログ集約エンジンを介し て、各Add-on等にログが送られる
  20. 送っているログ Feb 28 12:26:20 ecbooster app/web.1 sample#sidekiq.default.size=0 sample#sidekiq.get_master_data.size=0 sample#sidekiq.mailers.size=0 sample#sidekiq.product_report.size=0

    sample#sidekiq.slacks.size=0 sample#sidekiq.update_datafeed.size=43 sample#sidekiq.update_master_data.size=0 Feb 28 12:26:20 ecbooster app/web.1 sample#sidekiq.default.latency=0 sample#sidekiq.get_master_data.latency=0 sample#sidekiq.mailers.latency=0 sample#sidekiq.product_report.latency=0 sample#sidekiq.slacks.latency=0 sample#sidekiq.update_datafeed.latency=1577.5242395401 sample#sidekiq.update_master_data.latency=0
  21. 収集されるメトリクス • sidekiq.<キュー名>.size ◦ 各キューにおける待機状態のジョブ数 • sidekiq.<キュー名>.latency ◦ 各キューにおけるジョブの待機時間

  22. 設定したアラート1 • product_reportキューのレイテンシーが30を超えたら Slackに通知(もっと厳しくして良いかも)

  23. 設定したアラート2 • sidekiq.product_report.latencyのメトリクスが送信さ れなくなったらSlackに通知(メトリクス収集のバグを想 定)

  24. かかった費用 • トリガー: heroku-buildpack-sidekiq-metrics ◦ $0/mo ◦ https://github.com/feedforce/heroku-buildpack-sidekiq-metrics • メトリクス収集:

    Heroku Add-on Librato ◦ $21/mo (Nitro plan) ◦ https://elements.heroku.com/addons/librato
  25. 別解 • Sidekiq ProのMetrics ◦ https://github.com/mperham/sidekiq/wiki/Pro-Metrics ◦ $950/year • heroku-buildpack-datadog

    ◦ https://github.com/DataDog/heroku-buildpack-datadog ◦ $15/mo x Dyno number • 高い
  26. 今後の予定? • 各ジョブの実行数や成功数、失敗数等も収集するかも • とは言え、Bugsnagでエラーは把握しているし、sidekiq webでも見られるので優先順位は低い

  27. 感想 • 現在のEC Boosterに見合った監視を実装できたと思う • アプリケーションには何も実装していないため、取り外 しは簡単 • オーバースペックな技術は採用したくなかったので、そ の点は満足した

  28. 落ち穂拾い


  29. よく分からなかったこと • ruby scriptの中でループしたかったが、標準出力がバッ ファリングされてしまい、定期的なログ出力ができな かった • https://github.com/feedforce/heroku-buildpack-s idekiq-metrics/pull/1 •

    $stdout.sync = true はしていたのに。$stdout.flush まで必要だったのかな(未確認)
  30. Heroku Redisのログ形式 2020-02-04T07:53:26.000Z ecbooster-sidekiq-metri-ck0pam app/heroku-redis source=REDIS addon=redis-defined-77910 sample#active-connections=10 sample#load-avg-1m=0.18 sample#load-avg-5m=0.125

    sample#load-avg-15m=0.1 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664264kB sample#memory-free=12350252kB sample#memory-cached=1622852kB sample#memory-redis=507704bytes sample#hit-rate=0.11266 sample#evicted-keys=0 →今回使用したLibratoのCustom log-based metrics形式で出力していたこと を発見した。Heroku Postgresも。
  31. Librato上でRedisの可視化やアラート設定が出来た ※ Heroku PostgresはLibratoに始めからグラフがあるのに、 Heroku Redisは作らないとない

  32. 終わり