はじめに
Pub/Sub において、push 型のサブスクリプションを利用すると、サブスクリプションと紐づいたアプリケーションにPub/Subからデータが送信されます。
そのアプリケーションでダウンタイムが発生するメンテナンスを行う場合、push 型のままだと以下のようなリスクが考えられます。
- 配信の再試行数が上限に達した場合、メッセージが失われる
- 再試行が繰り返されることによる処理の重複が発生
このリスクを回避するために Pub/Sub サブスクリプションの設定を一時的に pull 型に切り替え、Pub/Sub とアプリケーションの連携を一時停止する方法を採用しました。
この方法により、Pub/Sub トピックから供給されるメッセージを失うことなくメンテナンスを安全に進めることができました。
本記事ではその具体的な手順を紹介します。
対象
- Pub/Sub の push サブスクリプションを利用してアプリケーションにデータを配信するシステムを運用しているエンジニア
- メンテナンス中にメッセージのロストや重複処理を防ぎたい方
手順
サブスクリプションの設定を push から pull に変更する
まず、Pub/Sub サブスクリプションの設定を pull 型に変更して Pub/Sub とアプリケーションの連携を一時的に停止させます。
サブスクリプションの編集画面から対象のサブスクリプションを選び、配信タイプを pull に変更したら「更新」ボタンを押して設定を反映させます。
後で設定を戻すので、エンドポイント URL やサービスアカウント等の設定情報をメモしておくとよいです。
サブスクリプションの設定を pull に設定後、メッセージがキューに溜まっていることを確認
配信タイプを pull にすると、サブスクライバー側からのリクエストがない間は、サブスクリプションに供給されたメッセージはキューに溜まっていきます。
サブスクリプションの詳細画面を開いて ACK 処理されていないメッセージ数が増加していることを確認します（後述の画像参照）。
メンテナンスを行う
この間、Pub/Sub からの push 配信が停止しておりメッセージが配信されないため、安全にメンテナンスを行うことができます。
メンテナンスが完了したら次の手順に進みます。
サブスクリプションの設定を push に戻す
サブスクライバー側のメンテナンスが終わったら、再びサブスクリプションの編集画面を開いて変更した設定を元に戻します。
元に戻した設定が間違っていないか確認できたら「更新」ボタンを押して設定を反映させます。
未処理のメッセージが正常に送信されているか確認
サブスクリプションの設定を push 型に戻したら、キューに溜まっているメッセージが全て処理され、以下の画像のようにサブスクリプションの指標から、全てのメッセージが ACK 処理されていることを確認します。
キューに溜まっているメッセージが送られているか確認
全てのメッセージが処理されていることが確認出来たら、サブスクライバー側のログを確認してメッセージのロストが発生していないか確認します。
まとめ
Pub/Sub サブスクリプションの配信を一時的に pull 型にしてサブスクライバー側のメンテナンスを行う方法について解説しました。
pull 型にすることでメッセージが一時的にキューに溜まるため、メッセージを保持しながら安全にサブスクライバーのメンテナンスを行うことが可能なのでぜひ参考にしてみてください。
最後まで読んでくださってありがとうございました。
appendix