harapeko-relay 中継パターン：直接送れない制約をどうつないだか
ツール工房.ai では、子ども向けイベントの週次通知をはじめ、いくつかの通知を定期的に送っています。送信元はクラウド上で動く自動化の処理なのですが、ここで一つ大きな制約にぶつかりました。
クラウドの自動化から、自分で用意した送信用の入口へ、直接データを送れない場合がある、ということです。設定やサービス側の制約の関係で、想定していた入口にどうしても届きませんでした。正直、細かい仕組みを完全に理解できているわけではありませんが、とにかく「そのままでは届かない」という状況でした。
この壁をなんとかするために組んだのが、「中継の置き場を挟むやり方」と私が呼んでいる構成です。この記事では、エピソードよりも中身の考え方、つまり「何を中継ファイルに書くか」「経由が増えることの代償をどう受け止めるか」「失敗をどう追えるようにするか」を中心に書いてみます。
なお、そもそもなぜ通知用の置き場を別に切り出したのか、という背景はGitHub リポジトリを用途で分けた話で書いたので、ここでは繰り返しません。また、中継した先で実際に通知を送る入口そのものの作り方は、メール通知を Cron で送る仕組みに切り出してあります。この記事はあくまで「直接送れない経路を、中継でどうつなぐか」という一点に絞ります。
中継の全体像
流れ自体はわりと単純です。
- 自動化の処理が、通知内容をまとめたファイルを作る
- そのファイルを専用の GitHub リポジトリに送る
- ファイルが送られたことを、GitHub 側の自動処理が検知して読み込む
- 読み込んだ内容を、自分で用意した送信用の入口に渡す
- 送信用の入口が、メールなどの形で通知する
肝は、3〜4 が「最初の自動化処理の外」で起きている点だと思っています。自動化の処理そのものは送信用の入口に届かなくても、GitHub へファイルを置くことはできる。なので「届く相手（GitHub）」と「届けたい相手（送信用の入口）」のあいだに、両方に手が届く中継役を一つだけ置く、という発想です。
中継ファイルに何を書くか
このやり方で一番考えたのは、中継ファイルの中身でした。送る側（自動化）と、それを拾う側（見張る仕組み）が、このファイルだけを頼りにやり取りするので、ここに過不足があると詰まってしまいます。
私の場合、ファイル名に通知の種類が分かる名前を入れ、中身には送信に必要な情報を一通り入れています。
- 通知先
- 件名
- 本文
- 追加情報（差分の概要など）
意識したのは、拾う側ができるだけ判断しなくて済むようにすることです。見張る仕組みの側で「これは誰宛だっけ」「件名はどうしよう」と考え始めると、処理が二箇所に散らばってしまう気がしました。送る内容は作る側で確定させて、中継ファイルには「そのまま送信用の入口へ渡せばよい形」を書く。見張る仕組みはファイルを読んで渡すだけ、という役割分担にしています。
ファイル名に名前を入れているのは、複数の通知が同じタイミングで走っても衝突しにくくするためです。ここを固定名にしてしまうと、立て続けに通知が来たときに上書きが起きるかもしれません。通知の種類ごとに別名のファイルが積み上がっていくほうが、後から見返すときにも分かりやすいと感じています。
経由が増えることの代償
中継を挟むと、当然うれしくない面も出てきます。素直に直接送るのに比べて、構造が一段ややこしくなるからです。
- 遅れが増える：自動化 → 置く → 検知 → 転送 → 送信、と段が多いぶん、即時とは言えません。ファイルを置いてから実際に届くまでに、見張る仕組みが動き出すまでの待ち時間が乗ります。
- 記録の履歴が増える：通知のたびに置き場へ記録が積まれていきます。放っておくと履歴が通知ファイルで埋まっていきます。
ここは割り切りどころでした。私の用途は「自分宛に少量の通知を届ける」もので、秒単位の即時性は要りません。週次のイベント更新が少し遅れて届いても困らない。むしろ後で書くように、記録が積み上がることを履歴として活かす方向に振りました。即時性が必要な用途なら、そもそも中継を挟まない経路を探したほうがいい、という線引きだと思っています。
失敗をどこで追えるようにするか
中継のやり方で一番気を使ったのが、ここでした。経路が長いと、届かなかったときに「どこで止まったのか」が分からなくなります。自動化がそもそもファイルを送っていないのか、見張る仕組みが動かなかったのか、送信用の入口で落ちたのか。区別がつかないと、調べるたびに全経路を端から疑うことになってしまいます。
そこで、各通過点で「通った跡」が残るようにしました。
- 自動化が、いつ・どの名前のファイルを送ったか
- 見張る仕組みが、いつそのファイルを拾って転送を試みたか
- 送信用の入口が、いつ受信したか
この三点が別々に見られると、切り分けがかなり楽になります。たとえば「記録はあるのに見張る仕組みのログがない」なら検知側、「見張る仕組みは転送したのに送信用の入口の記録がない」なら入口側、と当たりがつきます。中継ファイルが記録として残ること自体が、最初の通過点のログを兼ねてくれているのも、このやり方の地味な利点なのかなと思っています。
逆に言うと、ここのログを整えずに中継のやり方を組むと、長い経路が裏目に出ます。直接送るより追いかける点が増えるぶん、最初から「各点に跡を残す」前提で考えておくのがよさそうだ、というのが正直な実感です。
どこまで使い回せるか
この構成は、通知の中身に縛られにくいのが強みです。「直接送れないものを、GitHub を挟んで届ける」という骨格さえ同じなら、流すデータを差し替えるだけで別の通知にも使えます。実際、子ども向けイベント通知で整えたあと、いくつかの用途に当てはめています。
- デプロイ完了の通知
- データ更新の差分通知
- 月次チェックリストの通知
どれも「自動化が送信用の入口へ直接届かない」という同じ制約を、同じ中継の形で扱っています。新しい通知を足したいときは、中継ファイルを作る処理を一つ用意すればよいので、追加のハードルがかなり下がりました。骨格を一度固めておくと、後がずいぶん楽になるタイプの仕組みらしいな、と感じています。
制約から、別のよさも見えてきた
直接送れないと最初に気づいたときは、正直めんどうだなと思いました。けれど中継を挟む形にしてみると、通知が記録として履歴に残るという、思っていなかった副産物がありました。
「いつ何を通知したか」が GitHub 上に並ぶので、後から確認するのが楽です。本来は制約に対応するための工夫だったものが、結果として運用上の見通しを良くしてくれた格好です。
個人開発では「直接できないから諦める」を最後の手段にしておくと、こういう別のつなぎ方が見つかることもあるのかもしれない、と今は思っています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ