【ITニュース解説】Node.js Healthtech Event Alerts After Email and SMS Timeouts (Cron Status Reconciliation)

システムエンジニアを目指す初心者が、Node.jsのような環境でメールやSMSによるイベント通知システムを構築する際、特にヘルスケア分野のように確実な通知が求められるシステムで、「タイムアウト」という問題に直面した時の適切な対処法について解説する。この解説は、多くのシステムに共通する信頼性の高い設計原則を提供する。

一般的なシステムでは、メールやSMSの送信はAPIを呼び出し、その応答を待つことで完了する。しかし、このAPI呼び出しが途中で応答を返さずタイムアウトした場合、送信が本当に失敗したのか、それとも外部サービスには到達したが応答が返る前に接続が切れただけなのかが区別できない。この記事では、この「タイムアウト」を単純な「失敗」と見なすべきではないと強く主張している。タイムアウトを無条件に失敗と判断して再送信すると、実際には成功していたメッセージが二重に送られてしまう可能性がある。逆に、無条件に成功と判断すると、実際には送信されていないメッセージを見逃し、重要な情報が届かないリスクがある。特に、間違ったアドレスへの送信失敗を放置することは、必要な情報が届かないだけでなく、システムの無駄なリソース消費にもつながる。

この問題を解決するために提案されているのが、「証拠台帳（evidence ledger）」という考え方に基づくモデルである。従来のモデルが「メッセージを送信し、成功か失敗かの一つの結果を記録する」という単純なものであったのに対し、証拠台帳モデルでは、一つの通知処理を複数の独立したイベントに分解し、それぞれを不変な記録として保存する。具体的には、アプリケーション内で通知が必要になった出来事から始まり、特定の受信者へ特定のテンプレートで通知を送るという「不変な通知意図」、実際にメールやSMSチャネルで送信を試みた「チャネル試行」、その試行によって外部のメール・SMSサービスから受け取った「外部ID」、そして外部IDを使って問い合わせて得られたメッセージの「観測結果」（受付済み、配信済み、失敗など）、最終的にその受信者への通知を停止すべきかどうかの「抑制判断」といった一連のステップを個別に記録する。特に重要なのは、送信時に外部IDが取得できた場合、クライアントがタイムアウトしてもそのIDを保持し、後からそのIDを使ってメッセージの状態を外部サービスに問い合わせる「ポーリング」という処理を行うことだ。

このポーリング処理は、Node.jsのcronワーカー（定期的に実行される処理）によって行われることが想定されている。タイムアウトなどで状態が不明なメッセージについて、定期的に外部サービスに問い合わせて、そのメッセージが実際にどうなったのかを確認するのだ。この際、メッセージの状態を明確に分類するための小さな「語彙」を使うことが推奨されている。例えば、「submission_unknown」（送信状況不明）、「accepted」（外部サービスに受け付けられた）、「delivered」（受信者に配信された）、「transient_failure」（一時的失敗）、「permanent_failure」（永続的失敗）、「review_required」（手動での確認が必要）などである。「suppressed」（抑制済み）という状態は、メッセージの配信状態ではなく、「この受信者には今後このチャネルで通知を送らない」という、受信者とチャネルの関係に紐づいた別の情報として管理される。

ポーリングを行う際には、無制限に問い合わせを続けるのではなく、適切な「上限」を設けることが重要だ。例えば、最初は30秒後、次に2分後、10分後、30分後といった間隔でポーリングを行い、それでも最終的な状態が判明しない場合は「要レビュー」として人間の介入を促す。この間隔は、通知の緊急性や外部サービスの制限に応じて適切に決定する必要がある。

受信者の抑制（suppression）についても、慎重な判断が求められる。単に「失敗」という結果が出たからといって、すぐにその受信者を抑制すべきではない。例えば、システムの設定ミス、認証情報の期限切れ、外部サービスの一時的な過負荷など、送信システム側の問題や一時的な問題でメッセージが失敗した場合、それは受信者には全く非がない。受信者を抑制すべきなのは、「permanent_failure」の中でも、メールアドレスが無効であるなど、受信者自身の問題に起因する永続的な失敗が確認された場合に限られる。外部サービスから返される多様なエラーコードを、独自のカテゴリに正規化し、どのカテゴリが抑制のトリガーとなるかを明確に定義することが重要である。

また、メッセージの「テンプレート」（内容）の管理も重要なポイントだ。テンプレートの内容はアプリケーション側で管理し、そのバージョンを明確に記録すべきである。外部のメール・SMS配信サービスは、そのテンプレートを使って実際にメールのMIME形式を構築したり、SMSのセグメント分割を処理したりといった、配信に関する詳細な技術的な部分を担当するという役割分担が理想的である。これにより、どのバージョンのテンプレートでメッセージが送られたかを確実に追跡でき、コンテンツのガバナンスが維持される。

このシステムを実装する際には、複数のcronワーカーが同時に同じメッセージの状態を更新しようとしないよう、データベースの行ロックなどの排他制御メカニズムを用いる必要がある。また、システムの状態が適切に記録され、問題発生時に原因究明ができるよう、ログには試行ID、匿名化された受信者キー、テンプレートのリビジョン、状態の変化、ポーリング回数、正規化された失敗理由などを記録することが推奨される。

この設計は、外部サービスがメッセージの状態を問い合わせるための安定したAPIを提供し、かつその状態情報を十分な期間保持している場合に最も有効である。もしそのような機能が利用できない場合や、ポーリングが高コストになる場合は、標準的な配信レポートや認証済みコールバック（外部サービスからシステムに結果を通知してもらう仕組み）を利用することも検討すべきだが、どのような方法をとるにしても、「証拠台帳」の考え方と「抑制ポリシー」の原則は変わらない。

この解説を通じて、タイムアウトが単なる失敗ではないこと、状態を細かく記録する重要性、そして安易な再試行や抑制が避けるべきリスクであることを理解できたことだろう。これらの原則は、堅牢で信頼性の高い通知システムを構築するための基礎となる。