SMPPとHTTPの比較：どちらの接続が適しているか

結論をひと言で

送信量が少なく、トラフィックが突発的で、チームがすでにWebエンドポイントを運用しているなら、HTTPから始めてください。トラフィックが一定の流れになったとき、リクエストごとの認証と接続確立のコストが目に見えるようになったとき、または配信レシートを送信と同じトランシーバーセッションで受け取る必要があるときは、SMPPに移行します。多くのプラットフォームは両方を運用しています。送信の流れにはSMPPを、着信のコールバックにはHTTPを使います。

プロトコルは製品そのものではありません。メッセージが届くかどうかを決めるのは、ルート、送信者の登録、端末側のチェックです。SMPPとHTTPは同じメッセージセンターに到達するための2つの方法であり、どちらもうまく運用することも、まずく運用することもできます。

問うべきは、どちらのプロトコルが新しいかではありません。トラフィックの発生ペースに追いついて、チームがどの障害を把握し修正できるかです。午前2時に沈黙したバインドも、午前2時に失敗し続けるコールバックも、どちらも運用上の問題です。自社のツールで診断できるほうを選んでください。

スループットは形に従う

SMPPのバインドは、スループットのレートとウィンドウを割り当てて提供されます。セッションが開いていれば、送信にかかるのはPDUとその応答だけで、新たなハンドシェイクは不要です。そのためSMPPは、持続的な流れに対して効率的で、キャパシティ計画も予測しやすくなります。バインドの数を数え、割り当てを確認し、処理中のリクエストをウィンドウ以内に抑えてください。

HTTPは、接続を再利用すればコストは下がるものの、リクエストごとに認証と接続確立のコストがかかります。キャパシティはバインドのウィンドウではなく同時実行数で決まるため、クライアントは素早くバースト送信でき、その後レート制限やキューに突き当たります。この柔軟性はキャンペーンや少量のアプリケーションに適していますが、クライアントが同時実行数に上限を設けない限り、ピーク時の挙動を見通しにくくなります。レート制限とウィンドウは別の制御です。前者は1秒あたりのリクエスト数を、後者は処理中のリクエスト数を制限します。リクエストごとのコストが目に見えるのは大量送信時であり、1日数千件程度では表れません。

配信レシートと着信が統合方法を決める

SMPPは、配信レシートと着信メッセージを開いているセッション上で届けます。クライアントはそれらを受け取るためにセッションを維持し、各配信レシートを保存済みのメッセージIDと照合し、deliver_sm_resp で応答する必要があります。保護すべきコールバックエンドポイントはありませんが、見守るべきセッションがあります。開いているのに何も届かないバインドは、障害パターンの一つです。

HTTPは、配信レシートと着信メッセージをURLに届けます。受信側は署名を検証し、素早く応答し、イベントを非同期で処理します。よくある障害はコールバックの遅延です。プロバイダーがタイムアウトして再試行し、同じイベントが2回処理されます。冪等性キーと素早い応答は、最適化ではなく統合の一部です。

どの経路で配信レシートが届く場合でも、元のペイロードを保存してください。プロバイダーによる解釈は変わることがあり、サポート案件では元の状態やエラーコードが決め手になることがよくあります。メッセージID、ルート、時刻とともに保存してください。

選択と統合

送信の流れが持続的で、自社でサイズを決められるウィンドウをプロバイダーが割り当て、チームがセッションを運用できる場合は、SMPPを選んでください。セッションの運用とは、バインド管理、キープアライブ、再接続、PDU単位のログです。送信量が中程度で、チームがすでにセキュアなWebエンドポイントを運用しており、コールバックがアーキテクチャに合う場合は、HTTPを選んでください。送信経路と着信経路の担当者が異なる場合は、両方を選んでください。

どちらを選ぶ場合でも、求めるべき資料は同じです。テストルート、スループットの割り当て、配信レシートの形式、エラーコードの一覧、再試行ポリシーです。SMPPの解説ではセッションを、接続ガイドでは本番運用までの道筋を説明しています。

選択した内容は、数値とともに記録してください。ピークレート、バインドごとのウィンドウ、コールバックのタイムアウト、再試行の許容量です。これらの数値のない決定は、単なる好みにすぎません。ピークやチームが変わったときに見直してください。