💘

Notion記事へのいいねの通知頻度をいい感じに変更した話 #TimeTreeアドカレ

2023/12/21に公開

これは 株式会社TimeTree Advent Calendar 2023 の21日目の記事です。
https://qiita.com/advent-calendar/2023/timetree

こんにちは。株式会社TimeTreeで COSO (Chief Organizational System Officer) という、組織OSを作る仕事をやっている @lazy です。

Notion記事へのいいねとその通知について

TimeTree ではNotionに自前のいいねボタンを付けて運用しており、さらにそのいいねを作成者に対してSlackで通知することで、次の記事作成を促進しています。詳しくはこちらを参照ください。
https://zenn.dev/lazy/articles/notion-like-slack-notifier

今回は、その通知頻度をいい感じに変更したよという話です。

というのも、最近までこの通知は1日に1度の通知頻度で運用していました。

これは、利用しているノーコードインフラである make.com の料金体系が処理回数に依存しており、処理数を一旦抑えたテスト運用を始めて以降手を付けられていなかったためです。

ただ、しばらく運用してみて「やっぱりいいねの通知が来ると嬉しいな・・!」「また何か書きたくなるな・・!」と効果を実感していく中で機運が高まり、頻度の変更を行いました。

Before

After


前記事で紹介したText parserを使わない方式に変わっている部分がありますがこの記事では取り上げません。

何を変えたか

元々、トリガーとなるアクションは「毎日13時に、実行タイミングから24時間前を基準に、それ以降に更新されたNotion記事を取得」というものでした。
仮にこの方法のままで実行頻度を1時間ごとに増やそうとすると、深夜も土日も関係なく処理が動き、場合によってはSlackに通知が飛んでしまう事になります。

Slack通知に関してはおやすみモードなどでユーザーが制御できるものでもありますし、それでも問題無いという考え方もありそうですが、どちらかというと処理数が無駄だというところが目に付きます。
ほとんど休日や深夜にいいねされる事は無いと考えられるので、そこではチェックしないほうが処理数を節約できます。

そのため

  1. Schedule settingで平日30分ごとに起動
  2. 2番目の処理に行く前に、8時〜18時以外の時間帯だったら処理を止める
  3. 最終実行日時を取得し、Notionの更新記事の取得開始位置を最終実行日時以降を取得
  4. 処理がすべて終わったら、最終実行日時を記録する

という4つの変更を行っています。
以下はAfterの画像のうち最初の4ステップまでを拡大したもので、変更点はすべてここに集約されています。

こう見るとRouterモジュールから先は並列処理をするように見え、Like付きの記事の取得処理と、最終実行日時の記録の処理が同時に行われそうに見えます。
しかし、Routerの挙動はそうではなく、Like付きの記事の取得以降の処理がエラーで止まったりした場合には、最終実行日時の記録の処理は行われません。

そのため、いいねの通知処理までが正常に行われて初めて、最終実行日時が記録されるということが担保されているようになっています。

これは、何らかのエラーが発生した際のリカバリが次の実行タイミングで行われるようになるという意味で、重要なポイントです。
Beforeでは何らかのエラーが発生した際には手動で送り直さなければ歯抜けになってしまいます。(実際に、Notionとの通信エラーや、APIのレスポンス構造が変わってしまった事などがあり、何度も起こっていました)

今回の通知頻度変更を行うのと同時に、自動リカバリの対応まですることができました。

その結果どうなったか

処理数はこれまでのプランにそのまま収まる形で、通知頻度を向上させることができました。
具体的には、30分ごとにすると処理量は1ヶ月に 5,000 ops程度で、ミニマムである Coreプラン ($10.59/月, 10,000 ops/月)で十分賄えています。

未検証ですが、1分ごとになると毎回 1 opsのチェックだけで10,000 opsは超えてしまうものの、それでも 20,000 ops を超えることはまだなさそうです。
20,000 ops/月であれば$18.82/月ですので、十分検討できる金額感ではないでしょうか。
みなさんもぜひ参考にしてみてください。

あとがき

  1. 2番目の処理に行く前に、8時〜18時以外の時間帯だったら処理を止める

という部分は、Schedule setting の中のAdvanced scheduling内、Time fromとTime to の部分を使えば不要になるのでは・・?とこの記事を書いている途中に気が付きました。(参考)

ここだけで制御できると、さらに処理数が節約できそうですね!

TimeTreeの採用情報

TimeTreeのミッションに向かって一緒に挑戦してくれる仲間を探しています。TimeTreeで働くことに興味がある方はぜひ、Company Deck(会社紹介資料)や採用ページをご覧ください!

TimeTree Tech Blog

Discussion